まえがき
この「振る舞いからみんなで考える要求開発」（以降は、WDDと呼ぶ）を2023年の春頃に着想を得て、2023年の今時期に体系をまとめました。システム開発のPoCで活用し実践してきました。
良質な要求（曖昧性や矛盾を排除した）を書き、早期にシミュレーションすることで、求められている価値を実現、提供できるかを、ユーザーに確認してもらうことを目指したのが、着想のきっかけでした。
WDDは、共通理解をチームメンバー全員が早期に獲得することで、建設的な議論による要求の質向上と、設計、実装、テスト時に、ハイレベルな共通理解を持って仕事に集中することを狙った要求開発のやり方になります。
早期に共通理解を獲得することによる不具合防止、手戻り負荷削減の効果は、PoCである一定の成果を得ることができました。
昨今のLLMを活用したエージェント型生成AIの台頭により、質の高い要求を生成AIに渡すことで、より良いコーディング、プロダクト開発ができるのではないかと考えています。
（7/3の開発生産性カンファレンス2025でAutifyの近澤さんも発表の中で、質の高い要求について触れられていました。）
日の目を見ることはなかったので、ここで供養させてください。
指摘や疑問点があれば、FBもらえると嬉しいです。
この記事はNot生成AI、考案者が四苦八苦して得られた経験をまとめた知識体系です。
指摘を下さった、チームメンバーとN先生、F先生に感謝申し上げます！
着想のきっかけはこちらの思想から
要求定義段階が最も低コストで不具合を除去し、逆に最も不具合を混入しやすいため。
https://qiita.com/boxdatehakobon/items/22df2b358e9beb1ffd40
◇目次
・名前の由来
・特徴
・WDDの約束事
・WDDの進め方
◇名前の由来
ブレインストーミング(※1)と活発な議論を参加者のアイディア発想のトリガとして要求開発を進める手法のこと。
ワイガヤ駆動開発（Wai Gaya Driven Development）と名付けられている。
◇特徴
〇アイディアをオープンに！
開発者が頭の中で実践している曖昧さを含んだ想像を、BDD（Behaivor Driven Development）とブレインストーミングの手法を組み合わせて、対話と簡素なモデリングを使い表現できる。
開発に関わるメンバー（開発者、QA、ビジネス）が、アイディアについて議論することを最も重要と考えているフレームワークである。
〇開発者の頭はいつもアイディアで一杯！
多くの開発者が頭の中で、たくさんのアイディアを考え、下図のように仕様書やプログラミングに反映させている。
開発者が、頭の中に抱えているアイディアの種は、整理整頓されているわけではない。
しかし、この整理されていない、開示されていない状態では、開発を属人化させてしまう可能性がある。
属人化された開発アイテムは、開発中に様々な問題を引き起こす可能性がある。
プロジェクトの進捗、品質に大きな影響を与え、ビジネスに多大な影響を与える可能性も考えられる。
【参考】
属人化とは？意味やデメリット、解消方法をわかりやすく解説
〇頭の中のアイディアを開示しよう！
WDDは、開発の初期段階（Sprint0もしくはSprint1）で実施することで、開発に関わるメンバーの作成する対象のシステム・サービスへの理解、認知を高めることができる。
これは、WDDを通して、システムのBig Pictureについて、メンバー同士で議論を行うためである。
WDDは、Big picture thinking(※2)の思考方法をベースとしている。
写真には、写真一枚としての全体と写真を構成するいろいろな詳細な情報の両方が含まれている。
全体には、風景などのたくさんの情報の組み合わせがある。
逆に、詳細とは、下図でいう塔に窓がある情報のようなもの。
（デジタル画像でいうと、最小は1bit）
システムやサービスにおいても、引いて見ると一つのように見えるものでも、近くで見るとたくさんのものが組み合わさってできている。
開発の写真（＝開発対象）を見るために、抽象度の高い情報から低い情報まで、共有していることが重要であり、WDDはその活動を支援することが狙いである。
また、WDDはマインドマップとBDDのアイディアを使用した、ワークショップ形式の開発フレームワークである。
アイディアの発散と収束をメンバー全員の英知を持ち寄り行うことで、高い抽象度から低い抽象度まで、幅広く共通理解（共感と納得）を獲得することができる。
ワークショップを通じて、共通の解像度の尺度を獲得し、適宜解像度のピントを合わせられるようになることも目的である。
システム設計の階層感は、「自由」に考えることを重視している。
これは、開発初期段階では、人によって、詳細に見えていること、見えていないことが混在している状態である。
このことを表現し、様々な情報を共通に理解することを支援するため。
全体と詳細がごちゃ混ぜ状態になっているからこそ、何を優先し何を捨てるかの判断材料にもできる。
アジャイル開発のプロダクトバックログと親和性が高いと考えている。
〇品質についても議論しよう！
WDDは開発対象に求める品質についても、共通理解を獲得することを支援する。
これは、製品・サービスには、いろいろな品質（性能だったり、早い提供、故障が少ないなど）が付随している。
「品質の相対性（※３）」を議論する場とする。
Big pictureと同じで、開発する製品、サービスにおける品質も「人」や「場面」によって異なる考えが含まれている。
開発に携わるメンバーの持っている品質のイメージを棚卸し、どんな品質を実現することで、世の中に価値を提供できるか議論する。
〇誰に、どんな価値を届けるか？
常にユーザーのことを考え、ユーザーのペインの解消、嬉しさになるように、たくさんのアイディアを考え出すこと。
考えを発散させ、届ける価値の120%を考えよう。POやステークホルダー、ユーザーインタビューを通じて、必要なものを決めよう！
必要なものを必要なだけ作れることに、チームメンバーのベクトルを揃える。これも共通認識として、チームで共有しよう。
◇WDDの約束事
・システムズ設計（設計行為）をしないこと（あくまでも要求のアイディア獲得がメイン）
・アイディアを創発すること
・互いに尊重し対話すること
・相手のアイディア（話）を傾聴すること
・質よりも量を重視すること
・ファシリテータはローテーションすること
◇WDDの進め方
〇準備編
★人を集める
この手法（WDD）は、BDD（Behavior Driven Development）の要素も使用している。
そのため、この手法を使ったMobワークを実践する際は、以下のロールの人が必ず参加していること。
▪ロール
ドメインエキスパート/ビジネスメンバー
開発するシステム・サービスをよく知るエンジニア（もしくは、ビジネス側としてのエキスパート）を指す
QAエンジニア（テストエンジニア）
プロジェクトに参加している、品質やテストの評価に対して責任を持つエンジニアを指す
（QAだけが品質やテストに強い責任を持つ、プロジェクトに参加する全てのメンバーがプロダクトの品質に責任を持つことを強く求める）
開発エンジニア（システムズエンジニア / ソフトウェアエンジニア）
プロジェクトに参加している開発エンジニア
設計行為（要求設計やシステム設計、ソフトウェア設計）に対して責任を持つエンジニアを指す
▪場を準備する
場作りは、Mobエンジニアリング※に準拠する。
参加者全員の対話によって、設計対象についてアイディアを広げていく。
多人数が、同時にアクセスできるように対話の場を準備する
・対話の場
オフライン：参加するメンバーが一堂に集まりやすい場所を選定すること
オンライン：オンラインミーティングの作法に従うこと（内職厳禁）
▪事前情報
Mobエンジニアリングするための入力情報となるものは用意しておく。
・ユーザーニーズ（必須）
（潜在的に）ユーザーが求めているコトを考え、書く
1ユーザーとして、困りごと、便利になることを真剣に考える
適宜、ユーザーニーズを獲得するいろいろな手法を活用する
・ユースケース図（必須）
ユーザーニーズに付随するモノ、抽象度の高いユースケース図であること
ユーザー、設計対象となるシステム、影響を与えるものの3つを書き出す
・ユースケースシナリオ（ユーザーストーリー）（あると良い）
ユースケース図に補足的に記載するユースケースシナリオがあると共通理解が促進する
ユースケースシナリオの主語は、ユーザーであること
〇やり方編
★使う手法
・ブレインストーミング
https://www.utokyo-ipc.co.jp/column/brainstorming/
・BDD
https://circleci.com/ja/blog/how-to-test-software-part-ii-tdd-and-bdd/
★考え方
・得られるアイテム
WDDのワークショップ（主に対話を通じて）を行うことで獲得できる5つのアイテム
・ユーザーストーリー
・アチーブメントクライテリア（達成基準）
・テスト観点
・テスト仕様
・システム（ステークホルダー）要求
・各アイテムについて
| アイテム | 内容 |
|---|---|
| ユーザーストーリー | ユーザーニーズやユースケースシナリオから、ユーザーが実現したいコトに関して発生する動作（行動、操作など）を切り出したモノ |
| アチーブメントクライテリア | ユーザーストーリーを実現・達成するために必要な条件 |
| テスト観点 | アチーブメントクライテリアを満足したことを確かめるためのテストのアイディア |
| テスト仕様 | テストのアイディアを実現するためのテスト内容（Given、When、Thenでテストケースを作成する） |
| システム（ステークホルダー）要求 | 要求はテストと表裏一体であるので、得られたテスト仕様から要求が得られる |
・各アイテムの関係性
各アイテムの関係性は、以下のようになる
★図の書き方
・図の起点（一番左端）には、ユーザーの要望を書く
アイディアの起点とする
抽象度が高いモノであることが望ましい
例えば、ユーザーが欲しいコトを書く
深夜に運転するのぐ億劫なため、運転中に眠っていたい
・右方向に詳細化していく
絵を右側に拡張していく
・レーンに記載する内容
右側１列目
ユーザーが実現したい要望の手順を切り出し、ユーザーストーリとして記載する
ユーザーストーリーの文法に従う
「Who」として、「What」したい、なぜなら「Why」だから
（＜ユーザー/顧客＞として＜XXXを達成したい＞、なぜなら＜理由＞だからだ）
主語は、Who＝ユーザー＝ドライバーに固定する
右側２列目
一つのユーザーストーリーに対して、受け入れ基準、テスト要求、システム要求の三つを記載する
上から受け入れ基準、テスト要求、システム要求の順に記載する
右側２列目
受け入れ基準、テスト要求のID（識別できれば良い）、システム要求の詳細を記載する
右側３列目
テストの気になるポイント（テスト要求）、テスト仕様を導くGherkinのガイドワードを記載する
BDDのGherkinは固定ワード、必ず同じ文言、同じ並びで記載すること
右側４列目
Gherkinに沿った、テスト仕様を記載する
ガイドワードに想起され、かつテスト要求を満たす内容を考える
・上から下はユーザーが実現することを行う際の手順の流れを表す
ユーザーが、要望を実現するためにシステムを操作する流れに沿って、アクションが上から下に流れるように、ユーザーストーリーを並び替える。
・受け入れ（達成）基準を考える
QAがWhat ifの視点で、ユーザーストーリーに対して気になる点を列挙していく
抽象度はユーザーストーリーと同じくらいを心がける
・受け入れ基準からテストで気になるポイント（テスト要求）を列挙する
受け入れ基準を満たす（分解する、構成する）、テストで気になるポイントを列挙する
ここでは、「要求に対して」、「仕様に対して」などの階層感は気にしない（列挙することを優先、階層感の分類は後）
BDDのテストは振る舞いベースなので、機能要求とは異なる。
振る舞いには、機能要求と非機能要求（振る舞いには、品質特性が含まれそう、特にユーザビリティ）が含まれていると考えられるため、テスト要求空間を特定するのは難しいので、システム要求確定後にテストの機能要求ベーステストの作成やテストのリファクタリングで、特定・分類を行う。
・気になるポイント（テスト要求）からテスト仕様を考える
Gherkin（Given、When、Then）を使用する
ガイドワードに沿って、テスト対象の振る舞いを考える
3Amigosが協力して、考えるところ
相手への敬意を忘れず、アイディアを刺激し合うことを忘れないこと
テスト仕様があれば、テスト手順を考えてテストコードにするだけ
Stimulusやシステムモデリングツールでテストできると思われる
（応用としては、Stimulusでオブザーバーとし、テスト駆動による開発ができる）
システム設計時の、glossaryをWDDのドキュメントから導出する
テスト仕様が沢山のglossaryを含むことになる、ここから次の設計段階に使えるものを抽出する
（WDD用のテンプレートあり）
・テスト要求、テスト仕様からシステム（ステークホルダー）要求を考える
BigPictureは大きいので、システムは車とか、（車を含む）交通システムとかをイメージする
ユーザーストーリーからテスト仕様を駆動させ、システム要求に落とす
要求記述は、EARSを使用すること
SysMLの要求図やUSDMのような、要求の階層（空間）感を視覚的に捉えやすいものと、親和性が高い。
（モデリングツールを使えば、要求の集散、アロケートは楽になる想定）
〇気を付けること
★効率について
Mobエンジニアリングはフロー効率を意識すること
https://qiita.com/suzuki-hoge/items/18ba37a10502416d0d60
https://qiita.com/hirokidaichi/items/f59e611772c02f2e74ee
★属人化を防ぐ
Mobエンジニアリングをしているから、属人化に陥らないは勘違い
参加メンバーのバラつきがある状態であるので、Mobワークの中でベテランに仕事が偏るなど容易に発生する
（通常の仕事のように、出来る人に仕事が集まってしまう状態と同じ）
バラつきを前提とし、気を配りながらMobingすることを忘れないこと
Appendix
※１．ブレインストーミング
ブレインストーミングとは、一種のアイデアを生み出す「集団発想法」手法であり、複数人で会議の際にアイデアを出し合ってブレストを活用して、アイデアや発想の整理する事をメインとして活用されている。
引用元： ブレストとは？ ブレインストーミングの意味とやり方や４原則の完全解説
※２．Big picture thinking
「大局的思考（ビッグピクチャーシンキング）」とは、物事の細部に焦点を当てるのではなく、全体をとらえて長期的な可能性や目標を思い描くことを意味している。
引用元： 知っておきたい「大局的思考」のベネフィットとテクニック ── 海の向こうからオピニオン その107
Reaching the “Big Picture” In Testing and Quality
※３．品質の相対性
ソフトウェアの価値を判断する「誰か（人）」や、その人が利用する「場面」が、ソフトウェアの品質を決めるということです。ワインバーグ氏はこれを「品質の相対性」と呼んでいます。
引用元：連載ALM（1）ソフトウェアの価値を考慮した開発ができているか？