freeeの開発情報ポータルサイト

チームで実例マッピングをやってみた

こんにちは freee会計のQAエンジニアをしているsugenoです。
freee QA Advent Calendar 2024 - Adventar 5日目です。

私が所属する開発チームで、実例マッピングを作ってチーム内での要件整理/検討を行ったのでその取り組み内容について書いていこうと思います。
そもそも実例マッピングとは、ストーリーをルールと例に構造化して要件を明確にする手法で 今回はV字モデルでいうと要求定義/要件定義/基本設計の部分を範囲として実施してます。

V字モデルでいうと
V字モデル
引用元:https://speakerdeck.com/nihonbuson/example-mapping?slide=11

実例マッピングの進め方

参加メンバーはPM・デザイナー・Eng・QA

1.ストーリーを決める

ユーザーがシステムをどのように使用するかストーリーを決めていきます。

2.全員で実例を書き出す

具体的にユーザーがどういう動作をするかなど考えて書き出します。
例えば、画面リロードしたらどうなる?や再度ボタンを押したらどうなる?などストーリーに対しての具体的な挙動を書き出していきます。

3.実例に対してルール(=受け入れ条件)を考える

実例を満たすための受け入れ条件を書き出す、実例に対する受け入れ基準を明確に定義することで、システムや機能が期待どおりに機能しているかどうかを判断できるようになります。

4.調査必要な部分は別の付箋で記載する

実例や受け入れ条件に関連する調査が必要な情報がある場合、別の付箋でポイントを特定し追加の調査として持ち帰り検討します。

実例マッピングの例です
実例マッピングの例

実例マッピングの注意点

全網羅する必要はない/細かいところに偏らない

全体を網羅し過ぎると時間がかかり過ぎる可能性があり、適度な粒度で網羅し、細かいケースに偏らず重要なポイントに集中を議論すること。

実例は具体的に書く

実例を話す中でこの考慮合わせて必要など議論できる為、具体的なユーザーケースを記載していくこと。

実例マッピングは必ず実施する必要はない

毎回の案件で毎回必要かと言われるとそうでもない、新規機能なのでイメージが湧きづらい場合や複雑なものや条件が様々あるものには効果的と感じました。

実例マッピングが終わったあと

Tシャツサイズで見積もり

最後に実例マッピングである程度出し切れたら受け入れ条件から対応必要なところを書き出し、Tシャツサイズで見積もりをしました。
Tシャツサイズ見積もりは、初期見積なので大体のの規模がわかればOKです。

Tシャツ見積もりの例です
Tシャツ見積もり

やってよかったこと

チーム全体でさまざまなケースやパターンを考慮し、実際の運用や影響について実装する前に検討することが重要だと感じました。
具体的な実例を提示することで、多角的な視点で要件の検討などできることがとてもよかったです。
実例マッピングを通じてプロジェクトのスコープを整理し、効果的で簡潔なアプローチが見えてきて、EngやQAを含むチーム全体での共通理解がある状態のため スムーズに案件が進められたように思います。

おわりに

実例マッピングを初めて体験してみて、テスト分析のプロセスで共通理解を築けたおかげで、コミュニケーションやテスト設計が驚くほどスムーズに進んだ印象を受けました。
チーム全体の連携が強化され、効率的で効果的なプロジェクト進行できるようになっていきそうと感じました。今後もこのようなアプローチを積極的に活用していきたいと思います。

明日は、QAエンジニアのnori-sanが「QAエンジニア リモート・オフィス環境 2024」について記事を書いてくれます。
お楽しみに〜!良い品質を〜