開発の基本概念

ドキュメント駆動開発どきゅめんとくどうかいはつ

仕様書ドキュメント設計テスト駆動開発アジャイルAPI仕様

ドキュメント駆動開発について教えて

簡単に言うとこんな感じ！

「まずドキュメントを書いてから、コードを書く」開発スタイルだよ！設計図を先に完成させてから家を建てるイメージで、仕様書や設計書が”正解”になるから、認識のズレが起きにくいんだ。

ドキュメント駆動開発とは

ドキュメント駆動開発（Document-Driven Development、DDD） とは、コードを書く前に仕様書・設計書・APIドキュメントなどを先に作成し、そのドキュメントを開発の中心に据える開発手法です。「コードを書いてから仕様書を追記する」という後追い型のアプローチとは真逆の発想です。

ビジネスの現場でよくある「発注した内容と出来上がったシステムが全然違う…」という問題の多くは、関係者の認識がバラバラなまま開発が進んでしまうことが原因です。ドキュメント駆動開発では、最初にドキュメントで合意を取るため、そのズレを早期に発見・修正できます。

発注する側の視点でも重要で、ドキュメントが揃っていれば「何を作るか」「どんな動きをするか」を確認できるため、ベンダーへの発注・検収の基準としても活用できます。ドキュメントが”設計図”かつ”契約書”的な役割を果たすのです。

ドキュメント駆動開発の進め方

ドキュメント駆動開発は、大きく以下のステップで進みます。

ステップ	内容	成果物の例
1. 要件をドキュメント化	何を作るかを言葉で定義する	要件定義書、ユーザーストーリー
2. 設計をドキュメント化	どう作るかを図や表で定義する	設計書、画面仕様書、DB設計書
3. APIをドキュメント化	外部との接続仕様を定義する	OpenAPI仕様書（Swagger）
4. レビューと合意	関係者全員でドキュメントを確認・承認する	レビュー記録、承認済み仕様書
5. 実装	ドキュメントをゴールとしてコードを書く	ソースコード
6. ドキュメントを更新	変更があれば先にドキュメントを修正する	最新版仕様書

覚え方：「設計図→建築」の家づくりモデル

家を建てるとき、設計図なしで大工さんに「なんとなくオシャレな家にして」とは言いませんよね。ドキュメント駆動開発はまさに「設計図（ドキュメント）を完成させてから建築（コーディング）を始める」考え方です。設計図があれば施主（発注者）も「これで合ってる？」と確認できます。

ドキュメントの種類と役割

要件定義書 — 「何を実現したいか」をビジネス言語で記述
機能仕様書 — 「システムがどう動くか」を詳細に記述
API仕様書（OpenAPI等） — システム間の接続ルールを定義
画面設計書（ワイヤーフレーム） — 画面の構成・動線を視覚化
テスト仕様書 — 何をもって「完成」とするかの基準を定義
運用マニュアル — リリース後の使い方・管理方法を記述

歴史と背景

1970年代〜 ウォーターフォール開発が主流となり、フェーズごとに成果物（ドキュメント）を作成する文化が根付く。ドキュメント重視の開発スタイルはこの頃から存在した
2001年 「アジャイルソフトウェア開発宣言」が発表され、「包括的なドキュメントよりも動くソフトウェアを」という価値観が広まり、ドキュメントを軽視する風潮も生まれた
2000年代後半 アジャイルの普及とともに「ドキュメントがないと引き継ぎや発注ができない」という現実的な問題も顕在化し、両者のバランスを取る考え方が模索される
2010年頃〜 REST APIの普及に伴い、OpenAPI（旧Swagger） のようなAPI仕様を先に書いてから実装する「API First」手法が広まり、ドキュメント駆動の考え方が再評価される
2015年頃〜 「README駆動開発」や「ADR（アーキテクチャ決定記録）」などドキュメントを開発プロセスの中核に置く軽量な手法が注目される
現在 AIツールによってドキュメント作成コストが下がり、ドキュメント駆動開発の実践がより現実的になってきている

他の開発手法との比較

ドキュメント駆動開発は、他の開発手法と対立するものではなく、組み合わせて使うものです。

手法	ドキュメントの位置づけ	主なアウトプット
ドキュメント駆動開発	最初に書く・開発の中心	仕様書→コード
テスト駆動開発（TDD）	テストコードが仕様を表現	テストコード→実装コード
ウォーターフォール	フェーズごとに成果物を作成	要件→設計→実装→テスト
アジャイル（スクラム）	最小限のドキュメントで素早く動く	ユーザーストーリー→動くソフト
API First	API仕様書を最初に書く	OpenAPI仕様→フロント・バック実装

API Firstとの関係

API First（APIファースト） は、ドキュメント駆動開発の考え方をAPI開発に特化させたアプローチです。フロントエンドとバックエンドの開発チームが、OpenAPI（Swagger）形式のAPI仕様書を先に合意してから、それぞれ並行して実装します。発注者の立場では「どんなデータをやり取りするか」が事前に確認できるので、後から「そんな機能なかったの？」となるリスクが大幅に下がります。

規格・仕様	内容
OpenAPI Specification（OAS）	REST APIを記述するための標準フォーマット（旧Swagger）。API First開発のデファクトスタンダード
RFC 7231	HTTP/1.1のセマンティクスとコンテンツ。API仕様書の基礎となるHTTPメソッドの定義