はじめに
株式会社Hajimariが展開するプロパートナーズサービス（フリーランスと企業様のマッチング支援事業を展開しています）を利用していただいている、
稼働者・企業担当者の双方に提供している自社開発の稼働管理ツール【Haijmari Works】のプロダクトオーナーをやっています。
野澤です。
今回は実例マッピングをチームで何回かやってみて、さまざまなことを学びながら、やっと最近チーム内で標準化するところまでやったのでその過程や学んだこと、ステークホルダーの方々の声、実際にどういうルールで実例マッピングをやっていくことにしたのかの紹介ができたらいいなと思っています。
実例マッピングを知らない方のために
参考記事
- https://speakerdeck.com/nihonbuson/example-mapping
- https://speakerdeck.com/nametake/example-mapping-for-2-months
- https://nihonbuson.hatenadiary.jp/entry/example-mapping-collection-of-links
- https://note.com/nametake_alp/n/n5a2d2a3898e4
- https://speakerdeck.com/nametake/example-mapping-review-cycle
- https://aki-m.hatenadiary.com/entry/2020/12/10/235028
- https://note.com/shift_tech/n/ne2b137f7ef29
参考動画
個人的な言語化
実例マッピングはあるユーザーストーリーに対して、具体例から考えていき、
具体例からルール（受け入れ基準、ビジネスルール、要件）を抽出していくワークです。
仕様のバグ（or 要件のバグ）を潰すためのテスト的な意味合いもあります。
例えば、実装終了して本番リリースされた後に、「こういう使い方したらエラーになる」「思ってたのと違った」というようなことが発生すると手戻りが発生します。
そういう手戻りを少なくするためにも、まずは要件を考える段階でテスト（正しい要件になっているか、過不足なく要件が上がっているかを精査）をしていくというような考え方です。
詳しい具体的なワークの進め方などに関しては先ほど挙げた記事、もしくは動画をご覧ください。
あとはこのあとに具体的にどのような進め方で実施するのか（Hajimari Works開発チームバージョン）が書いてあるので、そこを参考にしてみてください。
実例マッピングをやり始めた背景
今までは開発チーム内で要件を決めていき、わからないことがあればステークホルダーの方々に話を聞いて要件を決めていたのですが、
本番リリース後に手戻りが発生したり、本番リリースをした後にもステークホルダーの方々に「思っていた挙動と違った」「この項目もあってほしいです」というような体験をさせてしまっていました。
そこでもっと要件定義の精度を高めていきたいと思った、当時のスクラムマスター（@YUM_3）が実例マッピングを導入しようと提案してくれました。
実際に導入してみて、チームでやり方を標準化するまでの過程
チームで動画を見る
先ほど紹介させていただいた、
https://www.youtube.com/watch?v=Mo-JeOwmhWQ
↑こちらの動画をまずはチームで見ました。
とてもわかりやすく、一番最初にこの動画をチームで見たのは、とても良い一歩目だったのではないかなと思っています。
わかったこと、学んだこと
- 大枠の実例マッピングのメリット
- 大枠の実例マッピングの進め方
- 具体例はテストケースになりうる
- ルールは要件になりうる
動画をもとに一回実例マッピングをやってみる
わかったこと、学んだこと
- 確かに実例は質問形式で書きやすいが、実際に使われるケースの具体的な例も網羅的に挙げておきたいと感じたので、質問形式固定ではなくて具体的な例も記入OKにしたほうが自分のチームにはあっていそう
- ユーザーストーリーの質が話し合いの質に直結する（ユーザーストーリーが抽象的すぎると、話が発散し過ぎてしまったり、どこを目指して話し合いを進めていけばいいのか迷子になる）
- 前提全員でワークをするので、プロダクト独自の概念とかを共有できたり、学びの場にもなった
- ファシリはルールの記述をしないほうが良い。ルールの記述までファシリが担当だと負荷が高い
- 自分が考えてもいないような視点から質問がでてきて、有意義な話し合いができた
一旦数回実例マッピングをやってみる
実際にやってみて経験値を積もう！というフェーズです。
ステークホルダーの方々とも一緒にワークをしたりしました。
この時点では時間がかかり過ぎてしまっている感覚、議論が良くない発散をしてしまっている感覚がありました。
わかったこと、学んだこと
- 他のユーザーストーリーの話をしているなと思ったら、他のユーザーストーリーとして付箋を書き、issueに追加してまた後日話し合いましょう！とすると脱線をしなくて済む
- ステークホルダーの方々に具体例を記述してもらう時に、具体例というよりかはWANTが先行したので、「予想される使われ方、使われ方に対する質問を書いてください」「実際の使われ方や想像した実際の使われ方の具体的な例を書いてください」というふうに具体的にしたほうがスムーズに書いてもらえる
- ステークホルダーの方々と実例マッピングをしていると、ルールが洗練されていく感じがある。自分たちだけでは絶対に気づけなかったなというルールが出てきて、とても有意義さを感じた
- 問いかけをするときはステークホルダーの方々はどう思いますか？ではなく、〜さんはどう思いますか？どうお考えですか？という問いのほうが発言していただける
- 話し合うときはモックや実際の画面を見ながら話し合えると良さそう
- ステークホルダーの方々への質問して大丈夫なのかな？という恐怖心（？）が減った
- 難しいロジックを考える、説明する時にこそ実例で考えるのがかなり有効。ロジックを言葉にして説明しても頭に入らない
発散と収束の概念について知る
先ほども紹介した
https://speakerdeck.com/nametake/example-mapping-review-cycle
↑この記事に出会いました。
この記事に出会って、発散の実例マッピング、収束の実例マッピングと分けて実施すれば良いんだと希望を見出しました。
わかったこと、学んだこと
- 発散、収束の概念
- 発散と収束を一度のワークでぐちゃぐちゃにやってしまっていたからよくなかったのか！
発散と収束の概念について揉める時期
実際に発散と収束を分けて実例マッピングを実施していたのですが、一人一人、発散と収束の基準が違ってきて、発散とは、収束とはみたいなところをチームでかなり話し合いました。
わかったこと、学んだこと
- 人それぞれ発散と収束の基準が違っていて、発散に関する実例マッピングやりましょう！収束に関する実例マッピングをやりましょう！でもごちゃってしまう
- 発散させるにしても時間はしっかりと時間を計ったほうがいい（時間を計らないと無限に話せてしまう...）
- 話し合ってすぐに答えが出なさそうなものはQuestionにする。Questionを有意義に使えれば、実例マッピングをスムーズに進めることができる
一旦数回実例マッピングをやってみる
発散と収束についての話し合いが大枠終わって、お互いが納得いった状態で実例マッピングを実施しました。
このフェーズは今までの実例マッピングの実践やチームでの話し合いで得られたわかったこと、学んだことを実際に身につけていくためのフェーズだったと思います。
しかしこの時点ではいまだに発散と収束に関してはなんかモヤモヤしていたり、実際に実例マッピングのワークに時間がかかっていたりもしていました。
標準化（ルール決め）
動画を見たり、記事を読んだり、実際に実例マッピングを実施してみてうまくいったこと、うまくいかなかったこと、実例マッピング後に実施していた振り返りなどをもとに、Hajimari Works開発チームではこうしていこうというルール決め（標準化）を行いました。
ルール決めをするために復習がてら記事を読み返していると、発散と収束についての理解がまちがえていたことに気づきました。
今までは1ユーザーストーリーごとに発散と収束の実例マッピングを2回やる というような捉え方をしていたのですが、冷静に記事を読んでみると、発散したほうが良い場面と収束をしたほうが良い場面とがあるという話でした。
ですので、1ユーザーストーリーに発散と収束を必ずやるというよりかは、
次に実施する実例マッピングは発散を意識していくのか、収束を意識していくのかを最初に考えたほうが良いということだと理解しました。
ここで発散や収束に対するモヤモヤは無くなりました。
あとは個人的にですが、先ほど紹介した記事全部に目を通し、＋αで
- https://leanpub.com/bddbooks-discovery-jp
- https://leanpub.com/agiletesting-condensed-japanese-edition
この2冊を読み、ルール決め（標準化）に臨みました。
この2冊は実例マッピング周辺の知識や、実例マッピングの具体例ってどんなこと書いていけば良いんだっけ？というような根本的なところから、さまざまなことが書いてあり、とても良かったです（まだ一回読んだだけで、全然身についてはいないと思ってるので、また読み直したい...）。
わかったこと、学んだこと
- 実際の実例マッピングの経験や振り返りから、割とスムーズに標準化できたので、実例マッピングのワークのシートや、振り返りの内容はどこかわかりやすいところに残しておくと、チームでやり方を考える時に便利
- 次に実施しようとしている実例マッピングは発散系が適しているのか、収束系が適しているのかを最初に吟味すると良さそう
- AgileTestingの片鱗（個人）
- BDDの片鱗（個人）
ステークホルダーの方々にワーク後にいただいた声
実際に一緒にワークをしてみて、
- 付箋があると口頭で意見を出したり質問するのが苦手な人も参加しやすくていい
- 毎回のMTGで疑問点を都度解消できているので認識合わせができて助かっています
- 今まではリクエストする→設置してくれた機能が「むむ」というのがあったけど（すみません）こうやって進めるようになって認識のズレがなくなったように思う
というような前向きな声をいただけていて、ありがたいなと感じています。
ステークホルダーの方々とワークをしてみて良かったと思っていること
- 実例やルールがより網羅的に出るようになる
- ワークを進めるごとに実例の解像度が高くなる
- ワークを進めるごとにルールが洗練されていく
- ステークホルダーの方々の視点の意見は学びになる
- ステークホルダーの方々の不安感の解消につながっているのではと思っている
- 開発チームとステークホルダーの方々とのMTGの雰囲気が回数を重ねるごとに良くなっている感じている
実例マッピングを実施する上であったら良いコンテキスト
スクラムに慣れている
スクラムはリソース効率より、フロー効率、
そして1つのスプリントゴールに対してチームで協力し、力を合わせて前に進んでいきます。
実例マッピングもその文脈をついでいると思っています。
開発チーム、ステークホルダーの方々で一緒に力を合わせてルールを明確にしていきます。
実例マッピングだけではなく、スクラムイベントやモブプロやペアプロもなのですが、リソース効率の面だけでみると効率が悪く見えてしまいがちです。
ですので、初めからスクラムに慣れていて、リソース効率ではなくフロー効率の考えが浸透しているチームであれば、実例マッピングは実施しやすく、習慣化しやすいのではないのかなと思います。
ステークホルダーが協力的
これも重要です。
「忙しくて協力できない」「そんなことやってる余裕ない」「全員でMTGするなんて効率が悪い」なんて言われたら、実例マッピングを実施することすら難しいです。
幸いにも自分たちが一緒に実例マッピングを実施しているステークホルダーの方々はとても良い人たちで積極的に協力していただけています。
協力できる関係が前提ないと、実例マッピングは成り立ってないだろうなと感じます。
実際にチームで標準化したルール
実例マッピングのインプットとある程度の実践した時の学び、振り返りをもとにチームでルールを決めました。
まだまだ改善点はあるかと思いますが、Hajimari Works開発チームでは以下のようなルールで実例マッピングを実施していきます。
このルールでの実例マッピング実践経験はまだ少ないですが、実施していく上で改善点出てくれば都度ブラッシュアップしていきたいと思っています。
事前準備
次に実施する実例マッピングは発散系か収束系かをチームで確認します。
発散系
抽象度の高い課題の具体例を集めます。
機能を考える元ネタになっていきます。
その具体例をもとに開発側が機能やデザインを考えます。
実例マッピングする対象のユーザーストーリが抽象的なもの、もしくは課題ベースなものに対して発散系の実例マッピングをします。
あとはユーザーストーリーに対して実現手段が多数考えられそうな場合に発散系の実例マッピングを実施します。
発散系のマッピングの期待する成果は、課題を解決するためのアイデアやユーザーストーリーが多数上がっている状態です。
発散系のマッピング後に、ユーザーストーリー単位で今度は収束系のマッピングをしていくようなイメージです。
収束系
1ユーザーストーリーが明確になっている場合は収束マッピングをします。
収束系のマッピングの期待する成果は、実装できる状態になっていることです。
具体例が網羅的にでていて、その具体例からルールが明確に抽出されている状態を目指します。
開発者がルール（要件）に基づいて実装し、具体例をもとにテストできる状態を目指します。
発散系の実例マッピングの進め方
1. まずはPOがユーザーストーリーに対する概要説明をする
2. 発散系（アイデア出し & ユーザーストーリー分解が終わっていることがゴール）や収束系（ルールを明確化し、実装できる状態までいくのがゴール）かの事前共有。
3. Painの実例を引き出す（5分）
具体的に何が辛いのか、何が良くないのか、どんな時に辛さを感じるのかをステークホルダーの方々からヒアリングしながら書き出します。
4. Painの理解（5分）
何が痛みなのかをチームで理解します。
Painの実例を眺めてわからないことなどあればステークホルダーの方々に聞き、しっかりと痛みを理解します。
5. 具体例を書く時間（5分）
課題を解決できるような想像上の解決策の実例（こうやったら解決できるのでは？）や「こういう機能があったらいいな」というようなことを書いていきます。
あとは「〜する必要はありますか？」というような質問も書いていきます。
実際に具体例を書いてみると、5分は短いですが、この後のタイミングでも実例は増やしていけるので、一旦時間を短く区切って実施してみるのがおすすめです。
6. 抽象的な質問、もしくは先に明確化しておいた方が良いと感じた質問順に並べる
実例マッピングを実施していると、最初にこの質問について考えておくべきだった...と思うことが多々ありました。
ですので、具体例を書いた後に、最初に明確化しておいたほうが良い質問や実例を決めます。
このときに質問や具体例を書いた本人が自主的に申告するようにしてみています。
（これ先に話し合ったほうがいいと思います！というふうに）
7. ルールを抽出 & 都度具体例が生まれる（30分）
具体例の付箋について話し合いながらルールを抽出していきます。
具体例の付箋について話し合っているタイミング、もしくはルールを抽出するタイミングで、また質問や具体例が出てくるかもしれませんが、それは追記をしていってOKです。
時間は30分とってありますが、意外と実施してみると時間がギリギリになってしまいます。（発散系なので余計に）
意識することとしては、すぐに答えが出なさそうなものに関してはquestionを利用し、後回しにして先に議論を進めることです。
そうすることによって時間のロスを防げます。
あとは、あるユーザーストーリーに対して詳しい仕様や要件、ロジックに関するやり取りをしてしまっていたら、それは収束系の実例マッピングでやることなので、また後日話し合いましょう！としてあげると時間を節約できます。
発散系の実例マッピングをしているといつの間にか一つのユーザーストーリーに対して詳しく話してしまいがちなので、気をつけています。
8. ユーザーストーリー分解（10分。次の実例マッピングで収束系ができるように）
ここで出た意見の中でユーザーストーリーに分解をしていきます。
次に収束系の実例マッピングを実施できるようにするためです。
9. 後片付け
実例マッピング終了後、赤が多かったら赤を明確にするためのネクストアクションを明確にします。
1つのルールに複数の緑が紐づいていたら、ルールが複雑なため分割をします。
新しいユーザーストーリーができたらissueとして登録します。
10. 振り返り
実例マッピングのワーク終了後に簡単に良かったこと、悪かったことを振り返ったり、ステークホルダーの方々から感想を聞いたりします。
そして改善していくことなども明確化していきます。
ここまでで発散系の実例マッピングのルールは終了です。
収束系の実例マッピングの進め方
1. まずはPOがユーザーストーリーに対する概要説明をする
発散系の実例マッピングと同じです。
2. 発散系（アイデア出し & ユーザーストーリー分解が終わっていることがゴール）や収束系（ルールを明確化し、実装できる状態までいくのがゴール）かの事前共有。
発散系の実例マッピングと同じです。
3. Painの実例を引き出す（5分）
発散系の実例マッピングと同じです。
4. Painの理解（5分）
発散系の実例マッピングと同じです。
5. 具体例を書く時間（3分。発散系に比べて出てくる具体例の数は少ない想定）
発散系に比べて時間は短めです。
収束系の場合は実際の使われ方や想像した実際の使われ方の具体的な例や質問を書くようにします。
6. 抽象的な質問、もしくは先に明確化しておいた方が良いと感じた質問順に並べる
発散系の実例マッピングと同じです。
7. ルールを抽出 & 都度具体例が生まれる（25分。発散系に比べて具体例の数は少ない想定）
発散系に比べて時間は短めです。
ですが、具体的にやることは発散系と同じです。
8. ルールの確認（3分）
ルールがあっているか、出てきたルールをもとに実際に実装を始められるかどうかを確認します。
9. 後片付け
発散系の実例マッピングと同じです。
10. 振り返り
発散系の実例マッピングと同じです。
すでに見えかけている課題
通常の実例マッピングだと、早く、手軽にというイメージがあるのですが、Hajimari Works開発チームが標準化したものだと結構時間がかかってしまっているので、それが現状課題だと感じています。
最後に
実例マッピングを実施してみて、
要件バグが少なく、手戻りが少なくという部分でのメリットの享受もそうなのですが、
プロダクトや業務領域に対する学習の促進、ステークホルダーの方々に対する安心感の補填、ステークホルダーの方々とのチーム感の醸成など、そういう表向き語られないようなところでもメリットの大きさをとても感じました。
あとは具体例から考えることの有意義さも身に染みました。
チームやステークホルダーを巻き込んで実例マッピングを実施するというところまでできなくても、
具体例を考え、そこからルールを抽出し、実装をする という流れはとても価値のあるプロセスだと思います。
まずは自分で具体例を考え、ルールを抽出、疑問が残ればquestionとして残しておき、POやステークホルダーに質問をしにいく、
そんなところから実例マッピングを始めてみるのが良いのかもしれません。
実例マッピング歴はまだまだ浅いですが、引き続き実施をしていき、今よりももっと実例マッピングの質を上げ、正しいものを正しく作れるようにチームで頑張っていきたいと思います。
スクラムについて
Hajimari Works開発チームでやっているスクラムについて興味がある方は
https://qiita.com/Takashi5816/items/4ba8d6f64b38d4ae033a
↑こちらの記事を読んでいただくと良いかもしれません。
この記事を書いた青木さん（@Takashi5816）は、Hajimariに転職をしてきて、Hajimari Works開発チームで一緒にプロダクト開発をしています。
前職でのスクラムと今のHajimari Works開発チームでのスクラムの違いについてわかりやすく書いてありますのでぜひ興味がある方は読んでみてください！