16人日の開発が2時間で終わった — 設計書の完成度が開発速度を決める
16人日が 2 時間になった
「設計書を書く時間って、もったいなく感じませんか？」
私もずっとそう思っていました。設計書を書くくらいなら、その時間で実装してしまった方が早いのではないか、と。
でも、最近ちょっとした事件がありました。
新しい個人開発プロジェクトで、人が手作業でやれば 16 人日 かかる規模の実装を、AI 駆動開発（Claude Code）で 約 2 時間 で終えてしまったのです。
最初は「AI ってすごいな」で片付けかけたのですが、よくよく振り返ってみると、本当に効いていたのは AI の賢さではありませんでした。事前に書いておいた設計書の完成度 こそが、開発速度の上限を決めていたのです。
なぜ 2 時間で終わったのか
AI 駆動開発を続けていると、AI には得意・不得意がはっきりあることが見えてきます。
| 作業 | AI の得意度 | 条件 |
|---|---|---|
| コードを書く | 得意 | 何を書くか明確であれば |
| テストを書く | 得意 | 何をテストするか明確であれば |
| アーキテクチャを決める | 苦手 | 選択肢が多すぎると迷う |
| データモデルを設計する | 苦手 | ビジネスルールの理解が必要 |
ひとことで言うと、AI は「実装」が得意で「判断」が苦手 なのです。
ということは、こうも言えます。
AI に「判断」をさせなければ、AI は最速で動く。
私が今回用意していた設計書（DESIGN.md）は、3,500 行・20 セクションのボリュームでした。中身としては、こんな要素を事前に決め切っています。
- 技術スタック（何を使うか）
- アーキテクチャ（どう構成するか）
- データモデル（テーブル定義）
- API 設計（エンドポイント一覧）
- 権限制御（誰が何をできるか）
- 画面遷移（どの画面からどの画面へ）
AI が考える余地を、意図的にゼロまで削った。 そう振り返ったとき、2 時間という結果にも納得がいきました。
曖昧な設計書 vs 完成度の高い設計書
「設計書はある」と「設計書として機能している」は、実はかなり違うものです。
| 観点 | 曖昧な設計書 | 完成度の高い設計書 |
|---|---|---|
| 技術選定 | 「React を使う」 | 「Next.js 15 App Router + shadcn/ui + Prisma 7 + PostgreSQL 16」 |
| データモデル | 「ユーザーとプロジェクトがある」 | テーブル定義書（カラム名・型・制約・インデックス） |
| API | 「CRUD を実装」 | エンドポイント一覧（パス・メソッド・リクエスト/レスポンス型） |
| 権限 | 「管理者と一般ユーザー」 | RBAC マトリクス（ロール × リソース × 操作） |
| 画面 | 「一覧と詳細」 | 画面遷移図 + 各画面のコンポーネント構成 |
曖昧な設計書を渡したときの AI の反応は、想像以上に正直です。実装のたびに「これはどうしますか？」「ここはどう解釈すれば？」と質問してきます。
このラリーが、開発速度を一気に落とします。
逆に、完成度の高い設計書を渡したときは、AI は質問せず、淡々と実装を始めて、そのまま完了まで走り抜けてくれました。
設計書は「開発時間の前払い」
「設計書を書くのに時間がかかるのが、そもそも嫌なんだよ」という気持ちは、私自身もよく分かります。書いている最中に、心のどこかで「この時間で動くもの作れるんじゃない？」とささやく声がするんですよね。
ただ、最近の私はこの感覚をちょっと書き換えました。
設計書に費やした時間は「消費」ではなく「前払い」だ という見方です。
| アプローチ | 設計 | 実装 | 合計 |
|---|---|---|---|
| 設計なしで実装 | 0 時間 | 手戻り含めて 20 時間 | 20 時間 |
| 設計書を先に書く | 4 時間 | 2 時間（手戻りなし） | 6 時間 |
設計書があると、開発中の手戻りが目に見えて減ります。とくに AI 駆動開発の場合、設計書の完成度が そのまま開発速度の上限 に直結する感覚があります。
エンジニアにとっての設計書
エッセンシャル思考の記事 でも書きましたが、「何をやるか」を見極めることが何より重要だと、私は感じています。設計書は、まさにこの「何をやるか」を言語化したものに他なりません。
別の角度から言うと、モチベーションの記事 で触れた「個人の継続行動を仕組み化する」話と、設計書はちょうど対になっています。
- 個人の継続 → 自分のための仕組み化
- 設計書 → プロジェクトの判断を仕組み化
設計書さえあれば、開発者（人間でも AI でも）はその場のモチベーションや個人の判断に頼らず、設計書通りに実装するだけで品質が担保される。それは、ものすごく安心できる状態だと思います。
さいごに
設計書の完成度を上げる作業は、地味で面倒に映ります。私もいまだに、書き始める前に毎回ため息をついています。
それでも、開発速度の上限を引き上げる方法は、結局ここしかない というのが、いまのところの私の結論です。
16 人日が 2 時間になったのは、AI が速かったからではありません。設計書が AI に「考えさせなかった」から です。
では、具体的にどんな項目を書けば「完成度の高い設計書」になるのでしょうか。次の記事で、実際の 20 セクション構成をベースに整理しています。よかったら覗いてみてください。
AIが迷わず実装できる設計書の書き方 — 20セクション・3,500行の構成を公開（4月25日に公開）
関連記事
- AIが迷わず実装できる設計書の書き方 — 20セクション・3,500行の構成を公開 — 完成度の高い設計書の具体的な作り方
- 「テスト工程が消滅した」— AI駆動開発 vs 従来開発を全工程で比較してみた — AI 駆動開発の実績データ
- 「エッセンシャル思考」と「エフォートレス思考」— 何をやるかと、どうやるかの両輪 — 「何をやるか」を見極める思考