プロダクト開発部の千田です。
チームで「実例マッピング」を実施してみたので、今回はそのことについて記事を書いていこうと思います。 ユーザーストーリーが曖昧なまま開発が進んでいる、ビジネスサイドと開発者の一体感がないなどの課題感があるチームの参考になったら嬉しいです！
前提
基本的にコドモンでは開発を進める際に、ユーザーストーリーを作成します。私が所属するチームでは、機能を開発する際にPdMがカスタマーサポートなどのビジネスサイドのメンバーから要件をヒアリングした後に機能の仕様を整理し、ユーザーストーリーの一覧を作成します。
その後、PdMと開発メンバーでユーザーストーリーの読み合わせをし、ストーリーポイントを付けていました。しかし、この方法には課題がありました。
チームが抱える課題
PdMが事前に作成したユーザーストーリーに対して開発メンバーとの十分な議論ができず、結果的にPdMやビジネスサイドのメンバーと、開発メンバーとの間で認識の齟齬が起きることがありました。
動くソフトウェアがあれば、実際に動かしてフィードバックを得ることができます。フィーチャーフラグを付けて検証用のユーザーだけに公開することも可能です。そのため、MVP(minimum viable product)を意識して、小さくリリースすることでフィードバックサイクルを短くしていましたが、それでも開発中のコミュニケーションコストが高かったです。
そのため、開発者がビジネスサイドとより連携してユーザーストーリーの作成から進めることができないか模索していたところ、実例マッピングに出会いました。
実例マッピングとは
ユーザーストーリーに対して、ユーザーの使い方の具体例を集めることで共通理解を促すワークショップです。エンジニアやPdMだけでなくデザイナーやQA、カスタマーサポートなどさまざまな職種のメンバーが集まって、観点の違う多くの具体例を検討することで、ユーザーストーリーをより明確にしていきます。
テストの文脈では、振る舞い駆動開発(BDD)のプロセスの1つ「発見(Discovery)」フェーズを行うときに使われます。
これから実例マッピングを使おうと思っている人へお伝えしたい日本語情報のリンク集 - ブロッコリーのブログより引用
また、ソフトウェア品質には複数の側面があり、それぞれに異なるテストアプローチが必要です。これらの側面を4つに区分けした図のことをアジャイルテストの4象限と呼びます。
実例マッピングは、この図の左上のビジネスに焦点を当てて開発を進めることでチームを支援します。
アジャイルテストの４象限とスクラムチームとしての活用方法 | Scrum.org より引用
実施方法について
実例マッピングの実施方法は The BDD Books に書かれていますが、私はアルプ株式会社さんのやり方を参考にしました。ざっくり説明しますが、詳細が気になる方はスライドを確認してください。
コドモンではリモートワークのメンバーが多いため、ホワイトボードツールのMiroを使いました。参加者はエンジニア、PdM、QA、デザイナーそしてできればビジネスサイドなど、観点の違うメンバーに参加してもらうのが望ましいです。
実例マッピングは4つの付箋を使います。
そして次の手順で進めました。
赤のQuestionの付箋は開発メンバーが技術スパイクとして取り組んだり、ビジネスサイドのメンバー間で改めて議論をする時間を設けたりと不確実性を解消していきました。
こちらは当時のプロジェクトで実施した時の全体像です。
良かった点
これまではPdMがユーザーストーリーを作成して、エンジニアはそれを確認するだけでしたが、実例マッピングを取り入れることで、ビジネスサイドのメンバーも巻き込んで、ユーザーストーリーの作成段階から一緒に進めることができました。
エンジニアは以前よりもユーザーストーリーについて議論する時間が増え、よりユーザーに寄り添った視点で開発を行えるようになりました。実例マッピングを行うことで、一時的に開発着手までのリードタイムが下がりますが、実装後の手戻りや要件不足による確認の手間が減ったため、全体の速度にはそこまで影響がなかったです。
また、今回のプロジェクトではリリース後の不具合や手戻りはありませんでした。結果的に実装前に十分な議論を重ねて、事前のスパイクで影響調査を行えたため、よい結果を得ることができました。一方で付箋の枚数が多くとても巨大な図になったため、後から参加したメンバーが仕様を把握するのに時間がかかったりと、まだ改善する余地はありました。
まとめ
コドモンのWin Session*1でも実例マッピングが話題になり、実例マッピングを実施するチームが増えています。
実例マッピングのルールはシンプルでとても取り組みやすいです。ユーザーストーリーが曖昧なまま開発が進んでいる、ビジネスサイドと開発者の一体感がないなど課題を感じてる方がいらっしゃいましたら、是非一度実施してみてはいかがでしょうか。
*1:チームごとに成果やがんばったことを発表し讃え合うイベントのこと
