ソフトウェアエンジニアリング史から読み解くAI駆動開発の現在地
■ソフトウェア開発の歴史は「カオスと工学」のせめぎ合いだった
黎明期のソフトウェア開発では、コードそのものが仕様であり、暗黙知で回る世界がありました。システムが小さく、関係者も少なければ、それでもなんとか成立します。ところが規模が拡大し、関係者が増えるにつれて、暗黙知は破綻します。納期遅延、品質問題、コミュニケーション不全が顕在化し、いわゆる“ソフトウェア危機”が起きました。 そこから、ウォーターフォール的な工学化が進みます。曖昧さを減らし、工程を分け、レビューや品質管理を導入する発想です。後にその反動として、重厚長大な文書主義へのアンチテーゼとしてアジャイルが生まれました。ここで重要なのは、どちらが正しいかではありません。歴史的には常に、複雑さに対してどう秩序を与えるかが課題だったのです。
■アジャイルの成功が、仕様不要を意味したわけではない
アジャイルはしばしば“ドキュメント不要”と誤解されます。しかし本来は、更新可能で、価値に直結し、軽量だが意味のある仕様を重視する思想でした。ところが現場によっては、仕様軽視や属人的な会話依存へ傾き、ソースコードが唯一の真実になってしまうケースもありました。 この歪みは、AI時代にそのまま拡大再生産される危険があります。
■AIは、かつての「コード＝仕様」のカオスを再来させる
生成AIやAIエージェントは、驚くほど速くコードを生み出します。しかしその速さは、理解や合意形成の速さと一致しません。ここに大きな断絶があります。人間が理解しきれていない仕様を、AIは実装してしまう。しかも見た目にはそれらしく動く。この状態は、1960年代的な“コード＝仕様”のカオスを、さらに高速に再来させるものです。 本来、ソフトウェア工学は、なぜそう作ったのか、どう検証したのか、誰が責任を持つのかを明確にするために発展してきました。AIはその工程を不要にするのではなく、むしろ重要性を高めます。 経営者にとって見逃せないのは、ここで生まれる問題が技術的負債だけではない点です。属人化、再現性欠如、監査困難、品質事故、保守コスト増。いずれも収益性や事業継続性に直結する問題です。
■SDDは、AI時代に再発明された“工学の再起動”である
仕様駆動開発は、AI時代に突然現れた概念ではありません。アジャイルの浸透とともに埋もれていた“仕様の価値”が、AI時代に再評価されたものです。重要なのは、昔の重いドキュメントへ戻ることではありません。AIに委譲できるように、要求、制約、受け入れ条件、設計意図を、更新可能で実装可能な形にすることです。 これは、企業開発において極めて合理的です。仕様が整えば、AIが動きやすくなり、レビューも通しやすくなり、複数人・複数拠点でも認識を揃えやすくなります。結果として、手戻り率の低減、保守性の向上、教育コストの抑制にもつながります。
■AI時代の競争力は、コード生成量ではなく設計力で決まる
今後、単純な実装速度の差は埋まりやすくなります。誰でもAIを使えるからです。差がつくのは、どれだけよい仕様を書けるか、どれだけよいガードレールを設計できるか、どれだけ検証を組み込めるかです。 つまり、競争優位の源泉は、コードを書く力の一部から、設計・統制・品質保証へ移っていきます。
■AIが速いからこそ、先に仕様を定義しなければならない
AIは、十分に曖昧な指示でも、一定水準のコードを返してきます。この“それっぽさ”が、AI活用の最大の魅力であり、同時に最大の罠でもあります。人間であれば、曖昧な要件に対して途中で確認を入れたり、手が止まったりします。AIは止まらず、進めてしまいます。 だからこそ、AIを活用する開発では、要求、制約、設計意図、受け入れ条件を先に定義することが重要になります。何を作るのかだけでなく、何をしてはいけないのか、どこまでが許容範囲なのかを、AIが扱える形で明示する必要があります。 ここでいう仕様は、重厚長大な文書を指しません。変更可能で、実装と検証につながる、生きたSpecです。これがあることで、AIはより安定して動けます。
■AIへの指示品質が、そのまま成果物品質になる
AI時代の開発では、プロンプトの巧拙だけでなく、要求定義や設計粒度、受け入れ条件の明確さが成果物に強く反映されます。つまり、曖昧な組織は曖昧な成果しか出せません。 この点で、SDDはAI活用の前提能力とも言えます。
■CI/CDと品質ゲートは、AI時代の“自動ブレーキ”である
AIが生成する実装を本番で扱うには、自動検証が不可欠です。CI/CDは単なる自動化パイプラインではなく、AIが出した成果物をふるいにかける品質ゲートになります。テスト、Lint、脆弱性診断、規約チェック、依存関係の検査などを通じて、AIの出力が基準を満たすかを機械的に判定することができます。 ここで大切なのは、AIの善意や“賢さ”に期待しないことです。AIはあくまで高性能な実装主体であって、責任主体ではありません。守られないコードを自動で止める仕組みがあるからこそ、開発速度を上げても品質が崩れにくくなります。 営的に見ると、これは品質事故の予防だけでなく、レビュー工数の平準化、属人的判断の削減、拠点間の品質ばらつき抑制にもつながります。
■AIを信じるのではなく、通すべき関門を信じる
AI導入で成熟した組織は、“AIをどこまで信用するか”を議論しません。代わりに、“どの条件を満たした成果物だけを進めるか”を定義します。これは非常に重要な発想転換です。個人の経験や勘に頼るのではなく、ルールに通したものだけを流す。そこに再現性が生まれます。
■最後に責任を持つのは、やはり人間である
AIが実装を担っても、責任まで引き受けてくれるわけではありません。最終的に成果物を承認し、リリースし、利用者への説明責任を持つのは人間です。この前提は、AI時代でも変わりません。 だからこそ、エンジニアの役割は低下するのではなく、むしろ高度化します。単純な作業者としての価値は一部AIに代替されても、開発全体を俯瞰し、設計し、検証し、品質と安全を担保する人材の重要性は増していきます。 PM、PL、テックリード、アーキテクト、QA、情シス責任者にとっては、自分たちの職能を“管理”ではなく“統制設計”として再定義する局面です。現場エンジニアにとっても、コードを書く力に加え、仕様を構造化する力、レビュー観点を持つ力、改善サイクルを回す力が、次の市場価値になります。