AI駆動開発までの歴史
XPの登場 (How の解決)
硬直化したウォーターフォール型のソフトウェア開発における
壊れやすさとフィードバックの遅さを解消するため生まれたXPは
コードと開発者にとってのコード品質と技術的健全性を取り戻した｡
XPエクストリーム・プログラミング入門(ケント ベック(著)/2000年)
- TDD / CI / ペアプログラミング + ORMの普及(Hibernate等)
Scrum の登場 (What/When の解決)
長大なウォーターフォールでは変化の速度に対応できず､完成しないと失敗に気づけない
という課題を解決する｢変化に適応しながら何を作るかを決め続ける枠組み(スクラム)｣が生まれた｡
The Scrum Guide
- バックログ / イテレーション / レトロスペクティブ + MVCフレームワークの普及
DDD の登場 (What の精密化)
Scrum は What/When を扱うが、What の中身（業務の意味や制約）までは規定しない。
その空白を埋めるために、DDD はドメインモデルという形で What を精密化するアプローチを持ち込みました｡
- XP: 実装品質とフィードバック（How）
- Scrum: 価値の優先順位と適応（What/When）
- DDD: 業務の意味のモデル化（Whatの精密化）
AI駆動開発の登場 (問題顕在化の高速化)
LLM により､実装速度が人間を上回り､リファクタ・テスト生成・既存コード理解が自動化され開発者は書く人から判断する人への移行が始まり､従来は人間の暗黙知で吸収していた仕様の曖昧さが問題として高速に顕在化するようになった。
この流れの中で､顕在化した問題を解決するために
仕様を成果物として固定しそれに基づいて開発することでAI駆動開発を安全に利用したいという認識が共有され始めた。
SDD を成功させるために解決すべき課題
SDD（Spec-Driven Development）自体は新しい発明ではなく昔からある考えだが
ここでは AI が条件を逸脱せず安全に実装を行えるよう､境界条件を効率的に提示する手法が｡
- API / データ / 権限 / 状態遷移 / 不変条件 / 失敗条件 / 業務 / 非機能 など
Spec 記述コスト
Spec を作成し､更新し､整合性を保つ作業は人間の高度な思考と判断が求められるため
メンテナンス性の高い Spec 作成プロセス･構造が必要となる｡
より抽象度の高い｢憲章や憲法｣に｢要求｣を与えて Spec を自動生成させるとか
Spec / プラン / タスク / 実装 それぞれの境界に検証ゲートや
途中での詳細化行程を通過させるなどのプロセス設計によって
再現性(安全性)を保ちながら目的を達成可能となるでしょう｡
どこまで Spec 化するか
AI性能の変化速度が早く処理速度的な適切さは常に変動している｡
変化に強い現実的な粒度の取捨選択が必要となる｡
Spec の陳腐化対策
- 機能追加
- 仕様変更
- 不具合対応などでの実装側の先行 (どちらが正か分からなくなる)
これらの課題はウォーターフォール時代と変わらないものの
Spec と実装の乖離を検知して止める仕組みの自動化が必要となるでしょう｡
仕様逸脱の検知問題
AI は確率的な挙動を示すため同じ Spec を与えたとき同じ結果を返す保証が無い｡
したがって､ Spec からの逸脱を検知するゲート設計が重要となる(自動テスト、E2E、CI)。
組織と役割の再定義
SDD を本気で導入すると PO は優先順位の管理者ではなく仕様の最終責任者に近づく。
これは権限・レビュー・意思決定構造の変更を伴うため、組織によっては調整が必要となる｡
(マイクロサービスと組織構成の問題にも似ている)
AI駆動開発の登場によってソフトウェア開発は書くことから判断することへ重心を移しつつある。この変化は Spec を重視する方向への揺り戻しを生む一方､すべての開発が重厚な Spec を必要とするわけでもない。
何を Spec にして何を Spec にしないかを選ぶ｡
その境界線を自覚的に引けるかどうかが開発者に問われている。