■ 1. 場当たり的なAI導入の限界
- 個人最適の頭打ち:
- 約1年前、Microsoft DigitalはほとんどのIT組織と同様に場当たり的にAI変革を始めた
- エンジニアは進化途上のツールを独学で習得し、個々の開発者は確かに速くなった
- しかし成果はそこで止まり、個人の生産性向上はチームの生産性向上につながらなかった
- 問題はツールではなくプロセス:
- 従来のソフトウェア開発ライフサイクルは人間同士の引き継ぎを前提に作られている
- 引き継ぎが発生するたびに意図のギャップが生じる
- 経営層からの問い:
- 最初から人間とAIエージェントの協働として設計するならライフサイクルはどうなるか
■ 2. 仕様駆動開発(SDD)への転換
- SDDの定義:
- 仕様をソフトウェア開発ライフサイクルの主要成果物として扱うAIネイティブな開発手法
- コード、ドキュメント、プロンプトではなく、生きた仕様を唯一の真実の源とする
- 実装開始前にビジネス上の意図と受け入れ基準を仕様が捉える
- 得られた成果:
- コード生成の高速化、テストの加速、アイデアから実装までの移行がかつてなく速くなった
- Frontier Firmへの一歩:
- 人間が監督と方向付けを担い、AIツールがタスク実行を担う働き方への前進
- Microsoftは自社をCustomer Zeroと位置づけ、顧客が自組織で学び活用できるモデルを示す
■ 3. シフトレフトによる効果
- 要件フェーズへの前倒し:
- 批判的思考と協働を要件定義フェーズへ移すことで曖昧さを解消しエッジケースを洗い出す
- 早い段階で全員の合意を形成し、後工程の混乱を劇的に減らす
- 期待される効能:
- ステークホルダーの早期整合、手戻りの削減、AIコーディングエージェントのより効果的な活用
- ビジネス目標との明確な結びつきを維持できる
- velocityとvectorの両立:
- velocityは開発の速さ、vectorは進む方向を表す
- 方向のない速度は高くつく混乱にすぎず、vibe codingで痛い目に遭って学んだ
- SDDはvelocityとvectorの両方を与える
■ 4. AI時代に仕様が重要な理由
- 従来の仕様の問題:
- 従来は仕様を計画文書として扱っていた
- 開発開始後は要件の変化や実装詳細の変更ですぐに陳腐化する
- 生きた成果物への転換:
- 仕様はプロダクトと共に進化し続ける生きた成果物になる
- PM、エンジニア、アーキテクト、デザイナー、テスター、AIエージェントの共通参照点となる
- 意図の保持という競争軸:
- AIツールは大量のコードを高速生成できるが、明確な指示とガードレールに依存する
- 意図を一貫して伝えられないチームでは、速度向上がばらつきと手戻りの増加を生むだけになる
- AI時代に最良の開発チームとは、最も多くコードを生成するチームではなく意図を保持できるチーム
■ 5. SDDを支える5つの柱
- 真実の源としての仕様:
- 仕様が全ステークホルダーにとって唯一の権威ある参照先となる
- 生きた実行可能な成果物:
- 仕様はプロジェクトと共に進化し、コードおよびテストと同期し続ける
- 複数のステークホルダーによって共同執筆される
- AIによる自動化:
- AIコーディングエージェントがコードの生成、テスト、検証を担い開発と生産性を加速する
- 人間による検証と協働:
- 自動化はSDDの中核だが、仕様のレビュー、要件の洗練、成果の検証には人間の専門性が不可欠
- 予測可能性と測定可能性:
- 進捗の追跡と成果の測定を可能にし、予測可能性を高める
■ 6. SDDのワークフロー
- 仕様作成の起点:
- 開発者とPMがビジネス目標、ユーザー要件、エッジケース、受け入れテストを捉えた仕様を作る
- 仕様はバージョン管理され、プロジェクトの進行に合わせて継続的に更新される
- 静的なドキュメントではなく、ライフサイクル全体の主要な意思決定を導く
- 前提となるconstitution:
- 仕様作成の前に、アーキテクチャ原則、ガバナンス要件、セキュリティ基準、開発上の制約を全員で合意する
- constitutionの策定は個人作業ではなくチーム全体の活動とする
- これにより従業員とAIエージェントが同じ事実と同じ文脈から作業できる
- GitHub Spec Kitによる6段階:
- ビジネス課題と期待成果の定義
- 曖昧さと未解決の問いの明確化
- 技術的な実装計画の作成
- 追跡可能なタスクへの分解
- 要件と計画の整合性の検証
- ソリューションの実装とテスト
- トレーサビリティ:
- 各段階が仕様の上に積み上がるため、実装判断をビジネス要件まで遡って辿りやすい
- コード優先の従来手法より追跡が容易になる
- 仕様は同一リポジトリでバージョン管理し、追跡を助け混乱を避ける
- エージェントと人間の分担:
- AIエージェントが仕様を強化し、そこからコード、テスト、ドキュメント等を生成する
- エンジニアは意図の検証、出力のレビュー、要件の洗練に集中する
- 仕様の粒度設計:
- SDDの効果的な導入は適切にスコープされた仕様に依存する
- 小さく焦点の絞られた仕様はレビューと検証が容易で、一括ではなく漸進的な構築を可能にする
- チームが成熟するにつれ適切な粒度を学び、大きな要件を複数の仕様に分割することが品質と意図保持の鍵となる
■ 7. 役割ごとの変化
- 最大の変化は行動様式:
- 既存の役割は旧来のライフサイクルと密結合していたため、変更や新設が必要になった
- 仕様は開発を支える文書ではなく、開発を駆動する成果物になった
- この意識の転換こそがSDDを機能させる
- リーダーシップ:
- 成功はもはや開発activityだけでは測れない
- 実装前の明確さ、整合、協働を評価する環境を作る必要がある
- 曖昧さの解消と期待値の文書化に早期に時間を投じることが、後工程の高コストな手戻りを減らす
- SDDは個人が回避できる任意のプロセスではなく標準の働き方になったとき最大の価値を出す
- 今日から使うと決めて始まるものではなく、意識の転換と学習曲線を伴い、導入は意図的でなければならない
- 開発者:
- 長年染みついた、要件から実装へ素早く移る働き方を断ち切る必要がある
- SDDではコードを書く前に、成功の定義を含め問題を完全に理解することが最初の一歩となる
- すぐにコーディングへ飛び込みたくなる習慣を変えるのは非常に難しかった
- エージェントがタスクを完全に理解してから着手させる必要がある
- SDDは自分のためではなくエージェントのために思考を明確化させる、人間優先ではなくエージェント優先の解法である
- エンジニアは要件の洗練、エッジケースの特定、計画の評価、AI出力の検証により多くの時間を使う
- 役割は全行のコードを書くことから、実装が意図を正確に反映しているかの確認へ移った
- プログラム/プロダクトマネージャー:
- ステークホルダー管理、優先順位付け、ロードマップ策定という従来責務は継続する
- 変わったのはライフサイクル全体を通じた当事者性の度合いである
- PMは仕様のスチュワードとなり、成功基準の定義、曖昧さの解消、ビジネス要件の文書化を担う
- 優先順位が実装中も可視であり続けるよう確認する
- 仕様はステークホルダー間の共有契約であり、チーム全体の共通の真実の源となる
- PMは計画と優先順位付けの責任者にとどまらず仕様のオーナーとなり、システム全体の起点となる
- 仕様が正しければ、あとはすべて所定の位置に収まる
- アーキテクト:
- 開発プロセスを統べるガードレールを設定する
- SDDの最初の活動の一つがconstitutionの定義であり、その作成と維持を担う
- アーキテクチャ上の判断が前倒しされるため、コードレビューやテストではなく実装前に問題を発見できる
■ 8. 今後の展望
- 目指すシステム:
- SDDはMicrosoftで進化を続けているが、既にAIネイティブエンジニアリングの重要要素と見なされている
- ビジネス要件から実装へ作業が移る間、意図を保持し続けるシステムを目指す
- エージェント高度化との関係:
- AIコーディングエージェントが高性能になるほど、明確な仕様の価値は高まる
- 要件を定義し、ガードレールを設け、意図の共同所有を維持できるチームが有利になる
- 品質やガバナンスを犠牲にせずAI支援エンジニアリングをスケールできる
- 意図の保持という本質:
- 人間が方向性、判断、説明責任を担い、AIが実行を加速するFrontier Firmの働き方への重要な一歩
- コードを生成することではなく意図を保持することが、速度とビジネス成果の両立を可能にする
- PMの権限拡大:
- SDDはPMにこれまでなかった権限を与える
- アイデアからプロトタイプへ進み、顧客やリーダーに見せてフィードバックを得るまでが格段に速くなる
- それを一度体験したチームは価値創出と新しいアイデアの生成を続け、学びの上に積み上げていく
■ 9. 導入にあたっての指針
- 仕様を真実の源とする:
- 静的なドキュメントではなく、プロジェクトと共に進化する生きた成果物として扱う
- 実装前に曖昧さを解消する:
- 要件、制約、エッジケース、成功基準の特定に前もって時間を投じる
- 明確なオーナーシップを割り当てる:
- PM、アーキテクト、開発者、デザイナーがそれぞれ仕様の維持に重要な役割を果たす
- アーキテクチャのガードレールを早期に定める:
- コード生成の前にガバナンス、セキュリティ、設計原則を定義する
- AIは判断の代替ではなく実行の加速に使う:
- 出力の検証とビジネス意図との整合確認には人間の専門性が不可欠であり続ける