見出し画像

実例マッピングを2ヶ月実施してみた話

Shogo Nameki

こんにちは、アルプ株式会社でQAエンジニアをやっている nametake です。

アルプのQAチームは開発プロセスの中に入って、プロセス全体で品質を改善する活動をしています。

そこでは、アジャイルテスティングの考え方に則り、要件定義の段階から品質を向上できないか考える活動を続けてきました。

その中で、BDDの方法論の一つである実例マッピングを2ヶ月近く運用してきたので、今回はその感想や溜まった知見を記事にしていこうと思います。

アルプの課題と実例マッピング

私がアルプでQAエンジニアになってから半年ほど経つのですが、その間はずっと品質プロセスの改善を進めてきました。

一定のプロセス改善は進んだのですが、一方でCSメンバーのリリース前確認で発見される不具合や要件漏れや、それすらも通り抜けてしまう不具合もまだ発生していました。

特に、リリース前確認で見つかっているパターンは、社内に情報があったにもかかわらず開発側にそれが反映できていなかったということになります。

そのあたりを解決するため、The BDD Books にも書かれていた実例マッピングを試してみることにしました。

実例マッピングそのものに関しては The BDD Books はもちろん、翻訳者であるブロッコリーさん(@nihonbuson)の以下のスライドがめちゃくちゃわかりやすいのでそちらを参照してみてください。

社内での実施方法

この2ヶ月で実例マッピングを以下のように実施してきました。

  • 実施は以下のタイミング(すべてでやったわけではないです)

    • 要件定義前のヒアリングに近い段階

    • 仕様ドキュメント完成後

    • 受け入れ要件ドキュメント完成後

  • 対象は以下

    • 固まりきっていないフィーチャーやドメインモデル

    • 受け入れテスト要件のドキュメントやデザインラフのようなレビューをしたいもの

  • 参加者は開発チームの当事者と要件のヒアリング対象になる人

  • 人数は3~6人

    • 内訳はQAエンジニア+フィーチャーの担当者+ビジネスサイドの人+開発エンジニア

  • 時間は内容に応じて30~45分

The BDD Books 等ではどちらかというと開発チーム内で完結させていましたが、以前の記事で紹介した課題を解決するためにもCSが持っている情報を開発に反映させたかったため、CSメンバーにも参加してもらっています。

また、まだ固まり切っていない要件定義の段階でも実施したため、当社プロダクトのドメインに対する専門知識をもっているドメインエキスパートやSalesメンバーにも参加してもらいました。

良かったところ

要件定義の漏れが発見できる

意図通りではあるのですが、これはやってみて一番実感した部分です。

実例マッピングをやる前も要件定義のドキュメントをレビューはしていたのですが、読み合わせという形だとドキュメント自体の整合性に引っ張られてしまう傾向があります。

実例マッピングは問を立てることに特化したワークショップのため、要件の整合性ではなく具体的な問を満たしきれるのか、ということを効率的に検証することができました。

また、ビジネスサイドも巻き込んでいたことで、かなり顧客に近い視点で問を出すことができました。

手軽に実施できる

実例マッピングは2ヶ月で20回以上実施したのですが、それだけの数できたのはとにかく手軽にやれることに尽きます。

やることもシンプルで実施時間も短いため、開催部分だけQAチームでハンドリングしてしまえば参加者の負担も少なく数をこなすことができました。

フィーチャーの状況を把握できる

モデリングや要件定義の前後に行なっていた実例マッピングでは、その対象が現在どこまで煮詰まっているのかが可視化され非常にわかりやすく確認できました。

煮詰まっていないものを対象にした実例マッピングでは、明らかにルールが増え過ぎたり、1つのルールに大量の実例が紐ついたりと、以下のスライドの解説そのままの形になっていきます。

そのため、開発に入れるかどうかを簡易に判断する材料として役立ちました。


機能完成前からビジネス側が機能の詳細を把握できる

要件定義の実例マッピングにビジネス側のメンバーが参加することで、ビジネス側が開発前から機能の詳細について把握できるようになるというのも大きなメリットでした。

共通知が事前に作られているため、リリース後に発生する対応についてビジネス側が早めに準備できたり、その準備の内容についても質問が減ってコミュニケーションコストが下がっていきました。

また、落としてはいけない要件を手前で指摘できる機会があることもメリットになっていたようです。

ビジネス側がプロダクトにコミットできる

これは少し予想外だったのですが、実例マッピングはビジネス側からの評判が非常に良い取り組みになっています。

このあたりを軽く聞いてみたところ、「今までもヒアリング自体はされていたが、そこから開発が終わって機能に触れるようになるまで時間がかかっていた。それが実例マッピングがあることで開発中の機能に関わることができ、プロダクトに対してこちらがコミットできていると実感できるのでそれが楽しい」という意見を頂きました。

アルプのビジネス側のメンバーがプロダクト指向の方が多いというメリットを、プロダクトに直結できる取組になったのは大きかったと思います。

実例マッピングのコツ

実例マッピングをそこそこの数やったことで、良いパターンと良くなかったパターンが出揃ってきました。

そのあたりが一定コツとしてまとまってきたので、この記事でそれも一緒に書いておこうとおもいます。

会社の開発の進め方や取り組んでいるドメインによって変わってくる部分もあるとは思いますが、もし自分の会社で取り組むときの参考になれば幸いです。

問を立てやすいフィーチャーにする

これはどんな議論に置いても大事だとは思いますが、実例マッピングでは参加者が問を立てやすいように一定の具体性を設けるほうがいいかもしれません。

例えば、

  • 「ディスカウントの実例を挙げる」ではなく「今までにヒアリングや導入で経験した契約に対してのディスカウントの付け方」

  • 「インポートのエラー画面の操作の実例を挙げる」ではなく「IT操作に明るくないオペレーターが操作をする」

のように、実際の経験を掘り起こしたりペルソナを設定したりすることでよりよい問が出やすくなる傾向がありました。

実例マッピング対象のスコープを明確にする

こちらもどんな議論でも重要ですが、特に社内で区切られているスコープを最初に明示することで、議論が発散しづらくなります。

アルプではビジネス側も巻き込んでDDDで開発を進めており、境界づけられたコンテキストの概念が浸透しているため、実例マッピング中に挙げられた例が対象としているコンテキストではない場合、早い段階で参加者がスコープ外という認識として議論が進んでいきました。

結果として、対象のものについての実例が集まる流れができるため、実例マッピングの問の質は上がっていく傾向がありました。

時間を区切る

ファシリテーター側のテクニックその1です。

The BDD Booksの紹介の中でも実例マッピングは集中力の観点から短時間で終わらせることが推奨されています。

実際、複数の題材について連続して実例マッピングを開催したことがありましたが、後半はやはり集中力が落ちてしまいました。

アルプでは全体の時間を題材に応じて30~45分の時間を確保し、

  1. 目的と題材の共有の時間(1~5分)

  2. 最初に議論無しで具体例を挙げる時間(2~4分)

  3. ルール化しつつ議論する時間(20~35分)

  4. 全体を俯瞰して見る時間(3分)

のような配分で行っています。

実例マッピングのルール化の協力を求める

ファシリテーター側のテクニックその2です。

実例マッピングを実際にやってみたとき、ファシリテーターだけが実例マッピングのルールのポストイットを更新し続けるのは非常に難しいという実感がありました。

また、ドメインモデリング等のドメイン知識が必要な場合はQAチームの人間だけでは専門性が足りず、ルール化し続けるのが難しいことがありました。

そこで私は、実例からルールを作る作業を参加者に手伝ってもらえるように冒頭でお願いするようにしてみました。

そうすることで、高い精度でルールが作られるようになり、かつ進行もスムーズになっていきました。

議事録もポストイットとして追加する

ファシリテーター側のテクニックその3です。

実例マッピングをしていると、会話の最中に特定の実例に対して補足が多くなっていく瞬間があります。

そのときに、よく「例えば」という単語が出てくるのですが、それこそが捕まえるべき実例だったりします。

実例を書き込むときに気をつけてもらっても、短い時間の中だと端折ったり自分の中で抽象化された形でポストイットに書き込んでしまうため、そういった単語は聞き逃さず、かつ実例として残すようにすることで後で見返したときに精度の高い実例が残ります。

参加者のロールの調整

実例マッピングは、要件定義前から実装着手までのどこで行うかによって参加者の必要なロールが変化するのを感じました。

アルプでは開発の大雑把な流れは以下の様になっています。

  1. 要件定義 or ドメインモデリング

  2. ユースケース定義

  3. デザインレビュー

  4. 実装着手

傾向として前半の要件やドメインに近いほどSales・ドメインエキスパートの比重を高くし、後半になるにつれて開発エンジニアやQAエンジニアの比重を高くすると、良い問が上がりやすい傾向がありました。

CSの方は顧客の要望から画面の使われ方まで全体を把握しており、高い精度の問を出していただけるので、アルプではどの段階でも時間が合えば参加してもらっています。

全員でQA(Question Asker)

実例マッピングを運用してみて、よかった点と社内で溜まったコツを紹介してきました。

最近のQAの1つの解釈として、「QAは良き質問者(Question Asker)である」という話がありますが、実例マッピングは参加者全員を良き質問者にできるため、非常に高い効果が出やすいワークショップだと思います。

もちろん、効果的に回すためには準備や会社特有の事情の考慮、参加者の協力は必要ですが、そこに力を入れるだけの価値がありました。

良かったところの項目にも書いたとおり、気軽に実行できてかつ効果を感じられたため、チームの協力を得やすかったこともあり、2ヶ月で合計で20回以上行いました。

実例マッピングのFigjam

アルプでは開発・ビジネス側関係なくプロダクト指向が強い組織のため、導入は非常に容易でした。

一方で、継続していくには誰かが音頭を取り続ける必要もあると思っています。
効果を実感できる部分も大きかったため、今後も実例マッピングを使い倒していこうと思います。

アルプではQAエンジニアを募集しています

実例マッピングを使い倒して行きたいとは思っていますが、もっとチームに深く関わったり、QA視点での問の精度を上げたりと、まだまだやりきれていないことがあります。

そのためにも、アジャイルテスティング文脈でQA活動を一緒にやってくれる方を探しています。

もしこの記事を見てアルプに興味が出た、もしくは話を少しでも聞いてみたいという方は、お声がけください。


この記事が気に入ったらサポートをしてみませんか？