3amigosでスリーアミーゴス（実例マッピング）の良さを語り合ってみた🌵
こんにちは、atama plusでプロダクトマネージャー（以下PM）をやっている角尾です。
弊社では、スクラムチームでのプロダクト開発に「実例マッピング」というプラクティスを取り入れています（社内では「サボブラ（サボテン・ブラザーズ）」と呼ばれています）。「サボブラ」を実施するようになってから、ディスカバリーからデリバリーがよりスムーズにつながり、プロダクト開発を進めやすくなりました。
このnoteでは、3amigos（PM、エンジニア、QA）それぞれの視点から見た良さやプロセスに取り入れる中で試行錯誤したことを紹介したいと思います。
サボブラ a.k.a. 実例マッピングとは？
まずは「サボブラ」の概要を簡単に紹介します。
このプラクティスは「BDD（振る舞い駆動開発）」の中で行われるもので、一般的には「スリーアミーゴス（3amigos）」「要件ワークショップ」などの名前でも呼ばれているようです。特にその中でも「サボブラ」は「実例マッピング」という手法をベースにしています。
「サボブラ」では、実現したいことをストーリー/ルール/具体例の観点でMiro上に整理・表現し、PM/エンジニア/QAの3者間で議論しながら認識をすり合わせ、デリバリーできる状態をめざします。
具体的には、チームで議論しながら以下のプロセスを進めていきます。
1. そのフィーチャーで実現したいアウトカムをストーリーの形式で書く。
2. そのストーリーを成立させるために必要なルールを書く。まずはメインルール、次にメインルールだけでは実現できないルール…と徐々に細かくしていく。
3. 各ルールに基づく具体的なケースを書く（ハッピーパス、ハッピーパスが実現できないケース、その他思いつくエッジケース…など）。
4. 出てきた具体例（実際に起こり得るケース）に該当するルールがなければ追加する。
5. 議論中に疑問点が出てきたら付箋に書き出す。その場で話して解消できるものは解消してルール/具体例に昇華する。その場で解消できないものは担当を決めて持ち帰る。
6. ルールと具体例を出し切ったら完了。
このように抽象-具体を行き来しながら必要な観点を洗い出すとともにチームの認識を揃えています。ここまでできたらあとはリファインメントして工数を見積もり、デリバリーに移るという流れです。
ちなみに「サボブラ」と呼ぶようになった由来はこちらの映画です。
参考
もっと詳しく知りたい方は、ぜひ「実例マッピング」などで検索してみてください（以下ブロッコリーさんの資料などでも勉強させていただきました！）
https://speakerdeck.com/nihonbuson/example-mapping
https://speakerdeck.com/nihonbuson/processshiftleft
3amigosでサボブラについて語り合ってみた
「サボブラ」はPM/UX/エンジニア/QAの全員にとって価値あるプラクティスです。ここからは弊社で初めて「サボブラ」を取り入れたHakkenチーム（当時）の3amigos（PM、エンジニア、QA）で久しぶりに集まり、「サボブラ」について語り合ってみた様子をお届けします。
登場人物紹介
🐰 su-kun：めちゃくちゃフレッシュなエンジニア。
🧞♂️ G2：めちゃくちゃ寡黙なのに面白すぎるQA。「サボブラ」の命名師であり伝道師。
🦄 tsunopi-：ごく普通のPM。
サボブラを始めたきっかけ
🦄 tsunopi-：おつかれさまです！このメンバー懐かしいなあ。今日はちょっと「サボブラ」について語りたくて集まっていただきました。
🐰 su-kun：語りたいなと思ってました。語りましょう！
🦄 tsunopi-：まずは「サボブラ」が爆誕した経緯からおさらいしたいんですが、もともとHakkenではG2さんと私の前任者が中心となってBDDを取り入れようとしていましたよね。私がHakkenに来た頃にはすでに始まっていたので聞きたいんですが、あれはどういう課題感があっての取り組みだったんですか？
🧞♂️ G2：「サボブラ」が始まった経緯ですが…、元々のデリバリーの流れでは開発がある程度進んでからテスト設計→レビュー→テスト実施という感じで進めていました。ですが、この流れだと開発からテスト実施までにラグが発生してしまいボトルネック感があると思っていました。テスト設計をもう少し前段に寄せたい意図でディスカバリーとデリバリーの間で「嫁姑」を取り入れ始めました。
🐰 su-kun：「嫁姑」ではUXとQAで仕様のすりあわせをされていたんですよね。
🦄 tsunopi-：当時はGiven-When-Thenの形式で書いた振る舞いを使って認識合わせをされていましたね。その中で「自分が書いた振る舞いを小姑のようにチェックする人がほしい」というUXメンバー（tsunopi-の前任者）の発言から、このプラクティスのことを「嫁姑」と呼び始めたんですよね…たいへんクリエイティブな命名をされるんだなと思いましたね。
🐰 su-kun：しかも、なぜかおふたりとも「自分が嫁だ」とおっしゃっていましたよね。
🧞♂️ G2：この「嫁姑」の導入によって開発とテスト設計を並行して着手できるようになったのはよかったですね。ただ、そのあとエンジニア観点が入ったときに「嫁姑」ですりあわせた仕様通りでは開発に進めないというケースもありました。そうするとそこから仕様変更が必要になり、テスト設計もやり直しで…と後手になってしまっていました。
🐰 su-kun：ちょうどその頃にKissyさん（エンジニア）からの発案で、チームで『The BDD Books - Discovery』の読書会をしました。これがきっかけで「嫁姑」ではなく、エンジニアも含めた3amigosでやってみようとなりましたね。
🦄 tsunopi-：この本、内容もタイミングもめちゃくちゃ良かったですね。この頃ちょうど前任者からの引き継ぎタイミングでしたが、ちょうど複雑めな条件分岐がある施策も考えていて（笑）、実例マッピングの題材としてもやりごたえがありました。実際に1回やってみて、これは良さそうだぞと本格的にチーム活動に取り入れることを決めましたね。
（弊社ではエンジニアを「dev」と呼んでいます）
それぞれの視点から見るサボブラの良さ
🦄 tsunopi-：そんな感じで「サボブラ」をやるようになりましたけど、Hakkenチームはみんなかなり気に入ってましたよね。それぞれにとって嬉しさがあったのでみんな前向きに取り組めていたのかなと思うんですが、嬉しいポイントを語っていただいてもいいですか？
🐰 su-kun：エンジニア視点では、一発で精度の高い振る舞いリストが定義されることにより、後からの要件確認やバグ発生による手戻りを減らせたのがよかったです。後からの確認や手戻りがあるとコミュニケーションコストや返信を待つ時間が発生するので、開発プロセスで無駄な時間が増えてしまいますからね。
また、デリバリーにおいて商用品質のプロダクト開発に着手するためには、価値仮説の検証を主な目的としたディスカバリー時に検討した要件だけでは不十分な場合があります。「サボブラ」はその落とし穴を埋めてくれているなと思います。
🦄 tsunopi-：例えばエッジケースの考慮漏れがあって、開発着手後でも仕様追加せざるを得ないケースとかですね…。
🐰 su-kun：はい。仕様追加によるコード変更は、記憶の復元やエンジンのかかり方の都合上、一回で書き切るより時間がかかってしまいがちですし、前に作った構造が一部無駄になってしまうこともありえるので…。
また別の観点ですが、振る舞い駆動のリズムで開発がスタートするので、そのリズムのままテスト駆動開発をしやすいことも大きなメリットです。自動テストが書かれやすくなり、長期的な品質も向上しました。
🧞♂️ G2：QAからすると「サボブラ」を実施する中でテストケースに置き換えやすいルール群が自然とできるので、テストケース設計が楽になりましたね。仕様もテストに必要な要件も明確になるので、テストとの連携が容易になりました。
みんなで認識を揃えたという点で、信頼しやすいテストケースをもとにテスト駆動的な開発に着手できるのもメリットだと思っています。一方で、実装中に要件が変わる場合もあるので、その際は「サボブラ」のMiroを忘れずに更新する必要はあります。atama plusのQAでは仕様まとめ的な資料をコンフルにまとめているのですが、「サボブラ」のMiroはこの仕様まとめ作成の際にも大いに役立ちます。
🦄 tsunopi-：「サボブラ」の推しポイントが聞けて嬉しいです！PMとしては、ディスカバリーからデリバリーに移るときの文脈共有や認識合わせをどうするとみんなが動きやすくなるかな、というのが毎回頭を悩ませる…というか考えどころではあるのですが、「サボブラ」があると関係者みんなが集まって認識合わせできる機会になるのでありがたいなと思っていました。この場で一気にみんなを巻き込んで、時には詳細要件を一緒に議論させてもらいながら決めていけるので、チーム全体でプロダクトづくりに向き合えている感じも良いなと…。個人的には未経験PMだったのもあり、ここでエンジニア・QAメンバーから意見をもらうことで技術的な観点を漏らさずに済むのが安心感あったしありがたかったです。
試行錯誤とサボブラの進化
🦄 tsunopi-：今では「サボブラ」もかなり板についてきて、プラクティスの形が決まって当たり前に実施していますけど、ここに至るまでにいろいろな試行錯誤もありましたね。
🧞♂️ G2：続ける中で改善を繰り返しながら独自フォーマットが決まっていきましたね。例えば「1ストーリーあたり、ルール・具体例は5個までにする」とか。
🦄 tsunopi-：確かに、最初はめちゃくちゃ付箋を出してましたよね（笑）。当時の自分はプロダクト開発においてめちゃくちゃ初心者だったのもあり、無邪気にやりたいこと・つくりたいものを全部要件に落としてみたらめちゃくちゃ複雑になっちゃったんですよね…。
🐰 su-kun：この施策をきっかけにチームでレトロして「もし具体例が多すぎると感じるなら、ルールが複雑すぎる。もしルールが多すぎると感じるなら、ストーリーが複雑すぎる（チケットが大きすぎるので、分けて開発できる）ということだね」と振り返ったんですよね。それで、ちょうどいい大きさのざっくりの見極め方として、それぞれ付箋がだいたい5枚くらいになるようにしよう、それを超えるなら分割しようという目安と方針を決めました。
🦄 tsunopi-：いま改めてそのときのボード（上）を見てみると、どう考えても付箋多すぎますね（笑）。でも、ある意味こうして複雑さが可視化されるのもいいところだなと思います。見えるからこそ、もっとシンプルにする方法はないかを考えなきゃなって思えるので。
🐰 su-kun：もう一つの振り返りとしては、この場でどこまでHowの話（技術的な議論）をするのかという話もありましたね。エンジニアとしては、具体例を追っていると、つい技術的実現可能性が気になってしまうんですよね…特にエッジケース。
🦄 tsunopi-：ありましたね〜。当初、チーム全員で「サボブラ」していたのもあり、せっかくやるならしっかり認識合わせしたいけど、ミーティングが長くなったときのコストも大きいのでそれは良くないよね、という話をしましたね。The BDD Booksにも「要件ワークショップは30分以内にすることをお勧めします」って書いてあったし…。
🧞♂️ G2：議論した結果としては、「サボブラ」の場では全員で話しておくべきことにフォーカスし、エンジニアだけで話せばよいトピックは別途時間を取る方針で進めることにしようと決めましたね。忘れないように付箋にメモっておいて、「あとで話す」ステッカーをつけておく感じで。
🦄 tsunopi-：そうですね。これでミーティングも長くなりすぎず、うまく回るようになった感じがします。「サボブラ」で何を話しておくと良いかつかめてきたというか。
🐰 su-kun：個人的には「サボブラ」って特に最初は難しくて、結構勇気がいるプラクティスだと思っていて。デリバリーに入る前にがっつり時間を取って認識を合わせるということをやりきれたときに初めて真価が発揮されると思いますし、そこまでドライブし続けることが必要だなと。Hakkenはレトロで「なんかサボブラうまく行かないからやめよう」ではなく「こうやったらうまくいくんじゃないか」という議論ができていたし、絶対ネクストアクションを出すので、毎週のイテレーションの中でどんどんプラクティスが磨かれていったなと思っています。
🦄 tsunopi-：確かに。本に書いてある一般的なプラクティスをそのまま使うというより、自分たちの状況に合わせて進化させるというか、もはや作り上げていくという心意気があったからこそうまくチーム活動に組み込むことができたのかもですね。
🧞♂️ G2：今では「サボブラ」テンプレート（※本note冒頭に掲載したもの）も完成し、全員参加ではなく各職種からブラザー1人ずつでも回せるようになって、真の3amigosになれましたね。So.我々こそが真のサボテン・ブラザーズになったのです。
まとめ
今回は「サボブラ」のプラクティスについて紹介しました。
最初は1チームで始めた「サボブラ」でしたが、じわじわと社内でバズり、今では多くのチームで活用されています（始めた当初は、各所から「サボブラってなんですか…？」と聞かれまくりましたが…笑）。
このnoteが誰かの参考になれば幸いです！
We are hiring!
atama plus では仲間を募集しています。
あなたもサボテン・ブラザーズの一員になりませんか？ご興味を持っていただいた方はぜひ以下をチェックしてみてください〜！