Agile testing condensedで紹介されている実例マッピングを実施してみたので、やってみた感想です。
↓Agile testing condensedを読んだ感想をまとめた昨日の記事
実例マッピングを使った動機
自分が今回実例マッピングを実施した案件に対して持っていた、
- 仕様が複雑で不透明な部分が多そう、という漠然とした不安がある
- 顧客との会話を特定メンバーが実施してしまい、理解度が個々人で偏っている
という課題にマッチするのではないかと思って、試してみることにしました。
実施方法
- 2人で実施(+途中から実例マッピング実施中に1人合流)
- 以下の流れで実施
- チェックイン(なぜ実例マッピングをやるのか確認、ブロッコリーさんの記事を一緒に読む) 30分
- 実例マッピングを実施 30分
- 実例マッピングやって分かったことをふりかえり 15分
やってみて効果を実感したこと
議論が発散しなかった
仕様の検討会を普段開くと、疑問が出てくるにつれて論点がずれたり話が発散しがちになるのですが、実例マッピングでは、「今の話は疑問だから赤の付箋に書き出して後で議論しよう」とか「今の会話で新しいルールが見つかったから青の付箋に書きだそう」など、話の整理がしやすかったです。
議論の途中で別のことが気になりだす⇒議論が発散する、というパターンは自分たちのチームにありがちなので、個人的には実例マッピングの効果を一番実感した部分でした。
例を用いて会話で理解度促進
実際の例に基づいた会話をすることで、お互いに理解がずれている点が分かってチームメンバーの理解度促進に繋がりました。
今回実践した時は出ませんでしたが、本に書いてあった、実例マッピングを通して価値の発見が生まれる、という意味も良く分かりました。
また、理解が促進したことで、PBIの受入条件を書きやすかったです。(実例マッピング実施後は、自分とチームメンバー二人のどちらともPBIを書ける状態になりました)
付箋の数でフィードバックが貰える
フィードバックが貰えることで、感情の共有がしやすかったです。
「青の付箋が多くなってきたから別のユーザーストーリー切らない？」とか、付箋の量という定量的なデータを基に会話ができたので、何となく不安だけど言語化できず苦しむ、みたいな時間がなくて良かったです。
無知の無知が減った
開発案件の性質も絡んでくるので一概に実例マッピングのお陰なのかは分からないのですが、これまで要件定義書を作ってきた時と比較すると、無知の無知が大分少なかったです。
普段要求検討をすると、要検討事項が3～4つ位出るのですが、今回は9つ出ました。仕事を進めていくにつれて、大体10個位の要求検討事項がいつも出るので、仕様検討段階で大分洗い出せたのでは...？と期待しています。
これからの課題
全体的に良かったことが多く、現状だと中々課題が思いつかないのですが、強いて言うなら...と思いついた課題を挙げてみます。
付箋に書きだすのが大変
会話が活発になる分、会話内容を整理して言語化して付箋に書きだすという作業が結構大変でした。
今回は2人だったので何とか書き出せたのですが、3人以上になると、記事にもあるようにファシリテーターを置けべきだと思いました。
実例マッピングやりたいから実例マッピングする、にならないようにする
実例マッピングというよりプラクティスや新しい技術を導入する時の課題ですが、何で実例マッピングするのかという所が、置いてきぼりになりやすい点に注意したいと思いました。*1
全体を通しての感想
個人で数回実践して手応えは掴んでいたものの、ペアで実施するのには正直不安もありました。
が、実際にやってみると自分が予想していなかった所でも効果(感情の共有がしやすかったなど)が出て、普段チームで作業するのが嫌いなメンバーも様子を伺いに来て積極的に議論に参加してくれたので、嬉しかったです。
自分たちのチームは開発志向が強いメンバーが多く、要求検討とかは皆参加したがらない傾向にあったのですが、今回は積極的に参加してくれたので、良かったです。
今後も実践してみて、気が付いたことを溜めて、どこかのタイミングで記事にしたいと思います。
