こんにちは。asken Androidエンジニア兼品質管理の高津です。
今回は医療事業部で実例マッピングをやってみた話です。 この記事は、ソフトウェアテスト Advent Calendar 2023 の12日目です。
実例マッピングとは
実例マッピングとは、
- ユーザーストーリー
- ルール(=要件)
- ルールに関連する実例
- 疑問
の4種類をそれぞれ異なる色の付箋に書き出し、マッピングすることで、ユーザーストーリーのルールを明確にするための会話を短く、強力に生産的にするためのシンプルでローテクな方法です。
Matt Wynne氏が発明した方法で、Matt Wynne氏の許可を得てブロッコリーさんが翻訳された実例マッピングの紹介がこちらです。 The BDD Books - Discoveryにも記載があります。 実例マッピングの詳細はぜひそちらをご参照ください。
なぜ実例マッピングをやることにしたのか
要件定義の速度と品質の両方を改善したかったからです。
以前に社内でアジャイルテスト勉強会を実施し、要件定義でもテストを実施できることや実例マッピングの紹介をしていました。
ブロッコリーさんが作成された事例から学ぶ実例マッピングのやり方で実例マッピングの対象範囲に要件定義が含まれていたこともあり、要件定義で実例マッピングをやってみることにしました。
実例マッピングを実際にやってみた
一部のメンバーがThe BDD Books - Discoveryをざっと読んだり、実例マッピングの紹介記事を読んだところでまずは実際にやってみよう、となりました。
実例マッピングはMiroを利用して実施しました。Miroには”Example Mapping”というそのままのテンプレートが用意されています。便利ですね。
同じMiroのボードに事前に検討していたペルソナや対象ストーリーの関連資料を用意してくれていたため、情報の不足なく実例マッピングを実施することができました。
実際の手順は以下の通りです。
- 実例を参加者全員で一斉に書き出し
- 細かな異常系も含めて思いついたものは全て書く
- KJ法でグルーピングや並べ替えを行い実例を整理
- 実例のグループに対応するルールの抽出
実施後、参加メンバーから「自分にはなかった視点での実例が見つかり、結果仕様の漏れを検出することができた」というフィードバックを得ることができ、参加者全員が実例マッピングに対して効果を感じられました。
ただし、想定以上に時間がかかってしまいました。不慣れだったこともありますが、ファシリテートで解決できそうな気配を感じました。
実例マッピングのやり方を改善しよう
「改善のために参考図書を読み直そう」ということで、The BDD Books - Discoveryの2章と3章を確認し、意見交換する読書会を有志で実施しました。
自分たちで実例マッピングを体験した上で、書籍を改めて読み直すことで気づけるポイントがいくつもありました。
読書会の結果、以下の手順を適用することが決まりました。
- まず正常系の実例とルールを検討する
- 1つのルールごとに検討を進めていく
- 要件定義時点での品質を優先するため、詳細な異常系は網羅できていなくてもOK
- 設計や実装段階でコミュニケーションをとり、詳細を詰める
改善したやり方で実例マッピングをやってみた
手順を改善して実例マッピングをやってみた結果、作業時間が短縮されました。
現在検討している要件は、みんな明確にイメージできていないものを具体化していくタイプです。
そのため、誰かに実例の場合にどうなるのかを回答してもらってルールを抽出する方法では解決しません。
まずは根幹となる正常系に関する認識を合わせた後、異常系に関してを一つずつ検討していくことが現在のチームには合っていました。
詳細な異常系の洗い出しをスコープ外にすることで、短時間で全体像を把握しやすくなりました。
まとめ
実例マッピングにより、仕様の漏れを要件定義段階で潰すことができました。また、参加メンバーの仕様理解と共通認識を持つことができたことも大きな成果です。
実例マッピングの結果、作られるもののフォーマットは大体同じだと思いますが、対象やチームによって最適なやり方は様々です。
短時間で漏れのない仕様を策定できるように、書籍やブログ記事を参考にして自分たちに合ったやり方を模索していきましょう。
積極採用中です
askenではエンジニアを募集しています。 よろしくお願いします。
