Summary
この文書の要点
- AI駆動開発では、実装速度よりも先に文脈の質が成果を左右します。
- CDMはWho、What、Whyの3軸で、要望を実装判断に使える形へ圧縮します。
- ループエンジニアリングにCDMを組み合わせると、速さに方向づけを与えられます。
- CDMは仕様書を厚くするためではなく、開発・レビュー・AI指示の判断基準をそろえるために使います。
AI開発で起きる問題は、速度不足ではなく文脈不足です。
生成AIは、要件の読み取り、設計案の提示、実装、テスト、修正までを短いループで進められるようになりました。開発の初速は大きく上がっていますが、速く作れることと、現場で使われ続けることは別の問題です。
AIは与えられた条件の中で合理的な答えを出します。しかし、利用者の行動、業務上の制約、運用担当者の負担、組織が達成したい成果が明示されていなければ、その合理性は一般論に寄ります。文脈が薄ければ、実装も薄くなります。
その結果、画面は動く、テストも通る、しかし現場では使われないという失敗が速く起きます。AI時代の要件定義では、機能を列挙するだけでなく、AIが判断に使える文脈をどう渡すかが重要になります。
CDM手法は、Who・What・Whyで文脈を定義します。
CDM手法は、開発対象をWho、What、Whyの3軸で捉え、要件整理、設計判断、実装指示、レビュー基準に使う方法です。単なるヒアリング項目ではなく、曖昧な要望を実装可能な判断材料へ変換するためのフレームワークです。
Whoは誰のための仕組みか、Whatはどの業務や行動の流れを支えるのか、Whyはなぜその改善が必要なのかを表します。この3点がそろうと、同じ機能名でも設計すべき体験が変わる理由が見えてきます。
- Who：直接操作する人だけでなく、承認者、管理者、運用担当者、影響を受ける関係者まで見る。
- What：登録、検索、一覧といった機能名ではなく、目的に向かう業務の流れとして見る。
- Why：効率化のような抽象語ではなく、何が減り、何が早くなり、どの状態になれば成功かを見る。
3軸がそろうと、実装の優先順位が変わります。
例えば「申請フォームを作る」という要件があったとしても、申請者の入力負担を減らしたいのか、承認者の判断を早くしたいのか、経理担当者の確認漏れを防ぎたいのかによって、必要な設計は変わります。
Whoが見えていれば、画面密度、説明文、入力補助、権限、通知の出し方を決めやすくなります。Whatが見えていれば、単一画面ではなく、前後の作業や例外処理まで考えられます。Whyが見えていれば、要望が増えたときに初期リリースへ入れるべきか判断できます。
CDMは要件を増やすためのものではありません。むしろ、実装に必要な判断軸へ圧縮するためのものです。何を作るかではなく、どの文脈で判断するかを先に置くことで、過剰な機能追加や方向違いの実装を減らします。
ループエンジニアリングには、方向づけが必要です。
AIがコード生成、実行、検証、修正を繰り返すループエンジニアリングは、明確なゴールと検証条件がある場合に非常に強力です。一方で、ループの評価基準がテスト通過や表示確認に寄ると、現場の価値は置き去りになりやすくなります。
CDMは、AIに正解を直接教えるものではありません。正解を選ぶための基準を渡すものです。Whoによって利用者の立場を、Whatによって業務の流れを、Whyによって目的と避けたい失敗をAIに伝えます。
速度だけでは、間違った方向にも速く進めます。CDMは、AI開発の速度に方向を与えるための軽い設計文書として機能します。
CDMは短く、具体的に、更新できる形で書きます。
CDMの価値は、厚い仕様書を作ることではなく、日々の開発ループで参照できることにあります。そのため、テンプレートは細かくしすぎない方が運用しやすくなります。
最小構成では、主利用者、関連利用者、対象プロセス、現状の課題、達成したい状態、避けたい失敗を押さえます。これだけでも、AIへの実装指示やレビューの精度は大きく変わります。
- Who：主利用者、関連利用者、運用・管理者、影響を受ける人を整理する。
- What：現在の流れ、改善したい流れ、通常時と例外時の操作を整理する。
- Why：解決したい課題、達成したい状態、成功指標、避けたい失敗を整理する。
導入は、小さな開発単位から始めるのが現実的です。
CDMを導入するために、開発プロセス全体を大きく変える必要はありません。まずはAIへ実装を依頼する前に、Who、What、Whyを数行添えるところから始めるのが現実的です。
次に、開発チケットや相談メモにCDM欄を追加します。レビュー時には、実装が定義したアクター、プロセス、ゴールに沿っているかを確認します。プロジェクトが進んで認識が変わった場合は、CDMも更新します。
CDMは一度書いたら固定するものではありません。現場ヒアリング、試作、レビューの中で変わる前提を反映し続けることで、プロジェクトの共通認識として機能します。
CDMにも限界があります。
CDMは、利用者や業務の文脈を整理するための方法です。データモデル、非機能要件、セキュリティ、法務、性能、運用監視などを置き換えるものではありません。重要な設計領域は別途検討が必要です。
また、CDMを書いたとしても、内容が抽象的すぎれば効果は出ません。「社員が業務を効率化するために使う」のような記述では、実装判断にはほとんど役立ちません。短くても、誰がどの場面で何に困り、どうなれば成功かが読み取れる粒度が必要です。
CDMは万能な正解ではありません。しかし、AIに任せる範囲が広がるほど、人間の意図を軽く、具体的に、繰り返し参照できる形にする価値は高まります。
AI時代の要件定義は、AIに渡す文脈の設計です。
CDM手法は、AIの能力を抑えるものではありません。AIが正しい方向へ速く進むための補助線です。人間の意図をWho、What、Whyに分け、実装判断に使える形へ変換します。
AI開発の成否は、AIに何を作らせるかだけではなく、AIにどの文脈で判断させるかによって大きく変わります。CDMは、その文脈をチームとAIの共通言語にするための実践的な方法です。
