開発チームの共通認識をプロアクティブに醸成させにいくGiven-When-Thenシナリオ
こんにちは、プログリットMobile Tech LeadのTakahiroです。業務ではiOS、Android、KMPの開発をしています。
本記事では、より良いプロダクトを作る上で欠かせない『チームの共通認識の醸成』をテーマにしました。ご参考になれば幸いです。
この記事のベネフィット
チームで共通認識を持つことは、以下のベネフィットが得られます。
仕様の勘違いによる手戻りが減る
スプリントの見積もり精度が高まる
ユーザー理解が深まる
本記事で書かないこと
Gherkinによるテストシナリオの書き方や、自動テストには触れません。あくまで、後述の参考資料から読み取ったBDDの本質部分にフォーカスします。
参考にさせて頂いた資料
実務に導入する上で、下記の本が大変参考になりました。著者様への敬意を込めて、最初にご紹介させて頂きます（※日本語版もあります）
Formulation: Document examples with Given/When/Then (BDD Books Book 2) (English Edition)
Discovery: Explore behaviour using examples (BDD Books Book 1) (English Edition)
適用できるチーム
アジャイルな組織、アジャイルじゃない組織
エンジニアが多いチーム、PdMやデザイナーが多いチーム
自社プロダクト、クライアントワーク
基本的にはどんなチームでも出来ると思います。何なら『自分ひとりだけ』で小さく始めることも出来そうです。
やり方のサマリー
エンジニアは開発作業を始める前に30分だけGiven-When-Thenを書き
チームメイトとレビューをします（PdM, デザイナー、QA担当なども含め）
共通認識がFixしたら、次の作業ステップへ（見積もりや、設計など）
やることはこれだけです。特別な環境も不要で、何ならテキストエディタで書いてもいいと思います！
スクラムイベントを運営しているならば、スプリントプランニングの前までにRefinementの一部として実施しても良いでしょうし、プランニング後の最初の作業として実施しても良いと思います。
もしアジャイルじゃなくても、週の頭などに今週の作業範囲のシナリオを書けば良いし、チームの協力を得にくければ、まずは1人でトライする事も出来ると思います。
以下、本題として具体的な書き方をご紹介していきます。
シナリオの構造
シナリオは『Title、Given、When、Then、（必要に応じて補足）』の構成がやり易いです。
Title：目的を一言で表現する
理想的には、要件（ビジネスルール）を端的に記述すれば良いですが、難しければ『◯◯機能の正常系！』とかでも良いです。
無理に背伸びせず、理想を求めず、まずは自分たちの言葉で書きましょう！（これがめちゃくちゃ大事）
Given：Contextを記述する
これから行う操作のUser Context（状況や条件）を記述します。
タイトルによって自明な場合は省略しても大丈夫です。
タイトルのスコープに解釈の余地があれば、ここで条件を絞るイメージです
本質的には『ユーザーって、どんな時にこのシナリオになるんだっけ？』と想像してみてください。
When：Actionを記述する
1つのAction（＝ユーザーの操作）を書きます。
この時、無理やりにでも『1つ』に絞るのがポイントです。
その分、Givenが多少汚く、分厚くなっても良いです。
絞る事で、チームの解釈が統一しやすくなります。
Then：Outcomeを記述する
操作結果のOutcome（＝発生する事象）を記述します。
なるべくタイトルのスコープの結果だけに絞ると良いです。
補足項目：自由記述
実装に踏み込んだ事情を記載しても良いです。
まだUIデザインが出来てないとか、サーバーAPIの仕様が決まってないとかでも良いです。
その時々にチームで共通認識を持つために必要な補足を書いておきます。
シナリオの具体例①：本記事のサマリー
実は、本記事で前述の『やり方のサマリー』はチームの振る舞いをシナリオ的に書いていました。
タイトル：開発チームの共通認識をプロアクティブに醸成させにいくやり方のサマリー
Given：エンジニアは開発作業を始める前に30分だけGiven-When-Thenを書き
When：チームメイトとレビューをします
Then：共通認識がFixしたら、次の作業ステップへ
補足：レビューはPdM、デザイナー、QA担当も含めます。次の作業ステップは見積もりや、設計などを想定します。
このレベル感で全然良いと思っていまして、なぜなら『目的は共通認識を醸成させる』事であり、『作法として正しい理想的なシナリオを書くことでは無い』からです。
シナリオの具体例②：DiaTalkのHome画面の振る舞い
もう少し実践に即したシナリオの例をご紹介します。
これは弊社Diatalkアプリを立ち上げた時の画面になります。シンプルに見えますが、裏には様々なビジネスルールが隠されています。
ユーザーの英会話の状態（初めてなのか、途中なのか、一旦終わって次の会話待ちなのか）
サブスクしているのか、してないのか
会話のクレジットが残っているか
サブスクは解約済みだが、クレジットや会話の状態と組み合わせた時に、どう振る舞うのか
こうやって条件を書くだけだと、内容が絡まってよく分からないのですが、これを理路整然と表現するのがシナリオの力です。
恐らく、上記の条件羅列では、読み解く人によって解釈が異なるのではないでしょうか？
以下に実際にシナリオを記述してみます。
具体例①：ユーザーの会話状態ごとの表示
Given：インストール後初めての時
When：Homeを表示すると
Then：サムネイル（大）は表示され、中のプログレスバーは非表示。オススメも無し。
Given：会話の中断中に
When：Homeを表示すると
Then：サムネイル（大）の中にプログレスが表示され、オススメは非アクティブ。
まだ暗黙的な領域はありますが、おおよそ仕様の全体観が表現出来ました。
具体例②：会話を開始できる条件（クレジットと状態と会話状態の組み合わせ）
Given：クレジットが1以上で
When：サムネイル大をタップすると
Then：会話が開始できる
Given：クレジットが0で、中断中の会話は無い時
When：サムネイル大をタップすると
Then：会話は開始できない
補足：クレジット回復の説明ダイアログが表示される
Given：クレジット0で、途中の会話がある時に
When：サムネイル大をタップすると
Then：会話が再会できる
少しだけ注意：本記事のシナリオは、品質保証が目的ではない
繰り返しますが『目的は開発チームの共通認識をプロアクティブに醸成させにいく』です。
もし、きちんと品質を担保しようとすると、本記事でご紹介したシナリオでは全く観点が足りません。QAは、それはそれで専門的な知識に基づいたテスト設計が必要になります。
これを意識せず『じゃあ、QAのシフトレフトとして、開発開始時にQAができるようなシナリオを書こう！』としてしまうと、一気にプロセスが重くなり、この活動は廃れてしまうと思います。
あくまでこの活動は『理解を深める、共通認識を醸成する』が目的です。
明日からシナリオを書いてみよう
ここまで読んで頂いてありがとうございました！本記事に書いたことは、特別な準備もなく、すぐにでも始められると思います。
『とりあえず』やってみて、もし良かったことなどのご感想や、困った事などのご相談があれば気軽にX等でお話しましょう！
カジュアル面談も受け付けておりますので、少しでも弊社にご興味を持たれましたら、お気軽にお申し込み頂ければと思います。
