ソフトウェアを二度書かない：仕様駆動開発と書き直しの終わり
ソフトウェアはなぜ常に二度書かれてきたのか。一度は仕様で、もう一度はコードとして。そしてその二度目の執筆がなぜようやく消えつつあるのか。
ソフトウェア開発において、正しく行う場合、ソフトウェアを二度書く必要があります。まずソフトウェアが正確に何をすべきかを説明する詳細な仕様で、次にその仕様を実現するコードとして。しかし厳しい真実があります。これが最初の一度で正しく行われることは稀です。
プロセスはしばしば崩れます。網羅的な仕様を作るには時間がかかり、チームは必要なすべての詳細を前もって集めることが稀だからです。これは欠落、思い込み、そして高くつく修正に繋がります。結果としてプロジェクトは予算を超え、納期を逃し、全員を落胆させたまま残します。
ソフトウェアを二度書くことの隠れたコスト
二度書くことがなぜ必要でありながら稀にうまく行われるのかを理解するために、2 つのフェーズを分けましょう。
1. 一度目の執筆：自然言語による仕様
ソフトウェアを最初に書くとき、コードはまったく書きません。要件、ユーザーストーリー、自然言語で書かれた設計の文書が生まれます。ここでチームはソフトウェアがどう機能すべきか、ユーザーが何をできるか、体験がどうあるべきかを定義します。
しかし問題があります。すべての詳細を書く余裕を持つチームは 1 つもありません。プロダクト担当者はしばしば厳しい納期に収めるために急がなければならず、プロジェクトによっては専門のプロダクトの役割さえありません。粗い線は引かれますが、重要な機能と対話が漏れます。Steve Jobs の有名な言葉に「偉大な製品は 5000 の小さな決定から生まれる」がありますが、ほとんどのプロジェクトでその決定を前もって下していません。後からエンジニアリングによる解釈に委ねられ、それが 2 番目のステップへ導きます。
2. 二度目の執筆：仕様をコードへ翻訳する
仕様が引き渡されると、エンジニアリングがその定義を動くコードに変える責任を負います。しかし一度目の執筆が不完全なとき、欠落を埋めるために想像力を使わなければなりません。思い込みが生まれ、エンジニアリング担当者が技術によく通じていても、製品のビジョンの全体像を持っていないかもしれません。
問題はここで表面に出ます。
- 欠けた詳細が摩擦を生む：プロダクトのチームが重要な機能や用途を定義しなかったとき、エンジニアリングは推測するか即興でやる必要があります。これはしばしば期待に応えない機能を生みます。
- 思い込みが修正に繋がる：エンジニアリングが欠落を埋めるとき、製品のビジョンと矛盾する形で機能を構築しうるため、プロジェクトの後半で大きな修正を招きます。
- 責任のなすり合いが避けられなくなる：納期がずれ予算が膨らんだとき、チームは互いに非難を投げます。プロダクトのチームはエンジニアリングが「理解しなかった」と責め、エンジニアリングは曖昧な仕様を指します。
結果は、逃した納期、超えた予算、満足できない成果へ導く問題の連鎖です。Standish Group の CHAOS の調査は、ほとんどのプロジェクトが予算を超え納期を逃していることを何年も示しています。McKinsey がオックスフォード大学と行った調査は、大規模な情報技術のプロジェクトが予算を平均 45 パーセント、期間を 7 パーセント超え、同時に予想より 56 パーセント少ない価値を届け、大規模な情報技術のプロジェクトの 17 パーセントは会社の存続を脅かすほどうまくいかないことを見出しました。
明らかにこのプロセスの何かが壊れています。
この実践には今や名前がある
ほとんどの人がプロンプトについて議論している間に、業界は 1 つの語で一致しました。仕様駆動開発です。まず要件、制約、成功の基準を書く。その仕様を正しさの源として扱う。エージェントにそれに基づいて構築させる。
GitHub は Spec Kit をリリースしました。AWS は Kiro をリリースしました。BMAD-METHOD、OpenSpec、Tessl がそれぞれ試みました。Martin Fowler がこれについて書きました。収束は偶然ではありません。カテゴリ全体が同時に同じ障害の形を発見したときに起きることです。
そしてその障害の形は上で説明されました。プロンプトから始まるツールは一度目の執筆を完全に飛ばします。直接二度目へ行き、仕様が一度も下さなかったあらゆる決定で推測します。デモには問題なく、製品には破滅的です。
仕様駆動開発は一度目の執筆を廃止しません。それを人間の判断を要する唯一の執筆にします。
新しい一度目の執筆：実際に終えられる仕様
変わったのはこれです。誰も完全な仕様を書かなかった理由は、決して意欲の欠如ではありませんでした。作業が自らを正当化するほど速くなかったのです。最初の作業周期の最初の接触で古びる文書のために何週間もの調査です。だからチームは粗い線を書き、5000 の小さな決定を後から 1 つずつ解釈されて発見されるままにしました。
仕様を用意するのに数か月ではなく数時間かかるとき、計算は逆転します。主題を尽くす余裕が生まれます。機能の要件、視覚の設計、データモデル、境界の場合が、エディタを開く前に集められ、何かを学んだときに直すのが十分に安いのです。
この最後の部分が重要です。安く直せない仕様は、現実が来た瞬間に嘘になります。これはAPI ファーストで構築する背後にある同じ本能です。構造を支える決定を、誰かが画面を書く前によく下すこと。残りはそれに従います。
新しい二度目の執筆：翻訳ではなくコードの生成
仕様が完全であるとき、二度目の執筆は翻訳の問題でなくなります。生成の問題になります。標準的な言語（JavaScript、TypeScript、Python）。標準的なフレームワーク（React、Next.js）。エンジニアリングが既に知る形での本物のコードが、あらゆる決定を既に下した文書から導かれます。
違いはエンジニアリングがより速く働くことではありません。エンジニアリングが一度もエンジニアリングでなかった部分をやめることです。誰か他の人が既に下した決定を機械的に反復することです。
その後で何が変わるか
3 つのことが一緒に変わります。
- 一度目の執筆が終わる：仕様の作業が数か月ではなく数時間で済むとき、チームは小さな決定を前もって下す余裕を持てます。レビューで発見するのではなく。
- 誰も欠落を埋めない：完全な仕様から生成されたコードは、誰かがプロダクトのチームが何を意味したか推測することを要求しません。推測は常に欠陥の源でした。
- 修正が積み上がらなくなる：意図と実装が揃って始まります。以前は書き直しだったものが、仕様の 1 つの変更になります。
ソフトウェアを書くことの未来：自然言語
人がソフトウェアをリリースしてきて以来、仕事はそれを二度書くことを要求しました。一度は自然言語で、もう一度はコードとして。その二度目の執筆は価値のある部分であったことは一度もありません。他に道がなかったから払っていた通行料でした。
これはAI アプリビルダーの次の世代が中心に据える一手です。コードの前の明確さ。アプリを計画として定義し、アーキテクチャを正しく据え、コードがそれに基づいて生成されるのを許す。定義の作業を飛ばす近道ではなく、それをようやくきちんとやる理由です。
今は別の道があります。ソフトウェアは常に一度書かれるべきものでした。
関連する読み物
この実践の完全なガイド：仕様駆動開発。プロンプトから始まる世代がなぜこのステップを飛ばしたかはvibe coding は約束を破ったに、その座を占めたものはvibe coding の次に来るものにあります。
よくある質問
仕様駆動開発とは何ですか。 仕様駆動開発は、コードが生成される前に要件、制約、成功の基準を書き、その仕様を AI エージェントがそれに基づいて構築する正しさの源として扱うことを意味します。2025 年に、プロンプトから始まり定義のステップを完全に飛ばす働き方への直接の応答として現れました。
仕様駆動開発は古典的な要件の文書を書くこととどう違いますか。 文書は同じ考えです。経済は違います。古典的な仕様はかなり高くついたので、チームは粗い線を書き、残りをコードのレビューで発見しました。仕様が数か月ではなく数時間で済み、安く直せるとき、それを終える価値があり、最新に保つ価値があります。
どのツールが仕様駆動開発を支えていますか。 GitHub Spec Kit、AWS Kiro、BMAD-METHOD、OpenSpec、Tessl が名前のある実装で、Cursor はルールファイル経由でより軽い版を支えています。本質的に、仕様がコードにどれだけ密に結びつくかで分かれます。生成を一度動かすのか、コードの横で進化するのか、それとも変更する唯一の成果物なのかです。
仕様駆動開発はチームを遅くしますか。 作業を追加するのではなく移します。仕様に集められる決定は、いずれ誰かが下します。前もって意識的にか、後からエンジニアリングやモデルが推測するときに静かにか、です。後者の道が修正の源です。
コードが仕様から生成されるなら、エンジニアリングはどうなりますか。 誰か他の人の決定の機械的な反復が消えます。アーキテクチャ、トレードオフ、正しさ、そして何を構築しないかについての判断は消えません。これらは常にエンジニアリング担当者を要する部分でした。
