機能開発において、要件の段階でレビューしてもらい問題ないと思っていても要件不足を防げない。機能を開発しリリース間際になって考慮漏れが発覚し手戻りが発生してしまう。。。

このような経験ありませんか？

こういった要件不足・手戻りに悩んでいたところ、実例マッピングという手法を紹介しれたので、実際に行ってみました。

本記事は、実例マッピングを何回か行ってみた上で、気をつけるべきポイントを紹介します。

実例マッピングとは

日本で1番実例マッピングの実践報告をあげていると噂のアルプ株式会社様のスライドがわかりやすいので、下記に抜粋します。

「実例マッピング」は、PM・デザイナー・エンジニア、営業やカスタマーサポートなど、多様な職種のメンバーが協調的に関わり「どんなものを作るべきか？」を明らかにしていく、30分のワークショップです。

https://2022.pmconf.jp/session/QCpMupKf

参加者からファシリテーターを1名選出します。

ワークショップ開始前に今回は何を明らかにしたいのか、ユーザーストーリーの当事者となるペルソナを予め共有します。

ワークショップは以下の通りに進行します。
1. ユーザーストーリーを付箋に書き内容を共有（3分）
2. こういう条件のとき、〇〇はどうなりますか？の形式でExampleを思いつく限り付箋に書く（2分）
3. Exampleを議論しながらRuleを設計し、付箋にまとめていく（20分）
4. 振り返りをしてまとめる（5分）

このワークショップを行うことで、議題に対する決定事項と未決定事項がはっきりします。

次に、実例マッピングを実施してわかったポイントを紹介します。

実例マッピングで押さえておくべきポイント

1. 予めPRDは作成し共有しておく

PRD（製品要求仕様書）は予め用意し共有しておきましょう。

PRDは完璧なものを共有する必要はなく、ターゲットユーザーの想定、問題設定、それに対するプロダクトが提供する価値など、大まかな概要で構いません。

ワークショップ当日のユーザーストーリーの共有だけでは、議論があらゆる方向に発散しがちなので、議論したいポイントや背景を予め共有しておくと良いです。

2. PMとファシリテーターは分けておく

実例マッピングでのPMの主な役割は、Exampleの議論に対する回答になります。

こういう条件のとき、〇〇はどうなってほしい、など回答していく中で、それを付箋にまとめたりタイムキーパーまで行うと、作業中は議論が止まってしまいます。

ファシリテーターはPM以外が担うほうが議論はスムーズに進みます。

PMは当日までにファシリテーターを参加者の誰かに依頼しておくと良いでしょう。

3. ワークショップは繰り返しても良い

実例マッピングはその性質上、いつまでも掘り下げた議論ができてしまいます。

1回のワークショップですべてを決めようとすると、30分できっちり終わるのは非常に稀なケースだと実感しました。

先に紹介したスライドのように、付箋でまとめておけば、次回のワークショップもスムーズに行なえます。

1回のワークショップですべてを決めるよりも、時間厳守で何回か繰り返す方が見落としが減り、質の高いPRDに近づくと、実践して感じました。

4. 似たようなExampleの付箋はグルーピングしておく

Exampleは結構似通ったものが出てくることもあります。

しかし、付箋では似通っていても全く別なケースを意図して書かれていることもあります。

まず似通ったものをグルーピングし、その上で同じことを書いているか確認した上で議論を始めると、見落としや同じ議論の繰り返しが減るでしょう。

議論前にグルーピングを行うことをおすすめします。

5. チームの心理的安全性が担保されていること

このワークショップを行う前提条件になりますが、参加者がしっかり自分の意見を持ち、それを受け入れる土壌がないと、活発な議論は難しくなります。

心理的安全性の担保は非常に難しい問題でもありますが、弊社でもいくつか記事にて取り上げていますので、参考までにどうぞ。

また、対立する意見を出す際は、質問する形で出すとRuleの見落としが減り議論がスムーズに進みます。

議論の進め方や意見の出し方、ファシリテーターの意見の広い方を工夫すると良いでしょう。

まとめ

実例マッピングは、要求に対する見落としを防ぐだけでなく、ワークショップを行うだけで議論の内容を可視化し、議事録の代わりに残しておくことでいつでも振り返られる点が非常に優れています。

一人でPRDとにらめっこしていても始まりません、周りを巻き込みチャレンジすると良いかと思います。