「前に作ってもらったシステムなのに、なぜ追加開発のたびに調査費用がかかるのか」。外部のベンダーにシステム開発を発注している方なら、一度はこの疑問を抱いたことがあるのではないでしょうか。改修や保守を依頼するたびに見積もりに「現状調査費」が乗り、当初の想定を超える費用が積み重なっていく。その違和感の正体をたどっていくと、多くの場合「ドキュメントが残っていない、または更新されていない」という一点に行き着きます。
ドキュメントが残っていなければ、開発を担当する側もシステムの中身を調べるところから始めるしかありません。これは外注先が手を抜いているというより、引き継ぐべき情報が形になって残っていないために起きる、構造的な問題です。コードを読めない発注者にとっては、何が原因で費用がかさんでいるのかさえ見えにくく、ただ言われるがままに調査費を支払い続けることになりがちです。
この問題を解決する鍵は、ドキュメントの整備を「外注先がやってくれるもの」と考えるのをやめることにあります。ドキュメントが残らないのは、その作成や更新を相手の善意や開発文化に任せてしまっているからです。逆に言えば、発注者の側が「どの書類を・いつ・どの状態で納品させるか」を契約と検収という仕組みに組み込めば、ドキュメントは確実に手元に残ります。
本記事では、まず「ドキュメント駆動開発とは」何かを非エンジニアの方にも分かる言葉で整理したうえで、ドキュメントが残らないことで発注者にどんなコストが発生するのかを具体的に見ていきます。そのうえで、契約書・検収条件にドキュメント要件をどう盛り込むか、最低限こだわるべきドキュメントは何か、発注者として整備をどう主導すればよいかを順に解説します。コードが読めなくても、ドキュメントを守らせる仕組みは発注者自身の手で作れます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ドキュメント駆動開発とは何か
ドキュメント駆動開発とは、コードを書くことより先に、あるいはコードと一体で、仕様書や設計書といったドキュメントを整え、それを開発の中心（基準）に据える進め方を指します。英語では Documentation Driven Development（DocDD）と呼ばれ、近年は仕様駆動開発（Spec Driven Development／SDD）という言い方も広がっています。
ドキュメント駆動開発の基本的な考え方
通常のイメージでは、開発とは「まずコードを書き、動くものを作る」作業です。ドキュメント駆動開発はこの順序を意識的に変え、「何を作るか」「どう作るか」を文書として先に固め、その文書に沿ってコードを実装していきます。文書がブレなく整理されていれば、実装した結果が当初の意図とズレにくくなり、後から「言った・言わない」のトラブルも起きにくくなります。
ポイントは、ドキュメントを「コードのおまけ」ではなく「開発の主役の一つ」として扱う点にあります。コードは動けばよいというものではなく、何のために・どんな仕様で作られたのかが文書として残って初めて、後から人が理解し、引き継ぎ、直していけるものになります。
エンジニア向けの文脈との違い
ドキュメント駆動開発という言葉は、もともとエンジニアの間で語られることが多い概念です。とくに最近は、AI にコードを生成させる際、先に仕様を文書化しておくことで AI の出力を安定させる、といった文脈で語られることが増えています。
ただ、発注者にとって重要なのは、こうした開発手法の細かな違いではありません。発注者の立場で押さえるべき論点はただ一つ、「開発が終わったときに、成果物として何が手元に残るか」です。動くシステムだけが納品され、その中身を説明する文書が一切残らなければ、次に何かしようとするたびに中身を調べ直すことになります。逆に、仕様書や設計書がセットで残れば、それは将来にわたって使える資産になります。
つまり発注者から見たドキュメント駆動開発とは、「ドキュメントを、システムと並ぶ正式な納品物として受け取る」という発想だと理解しておけば十分です。
発注者から見たメリット
ドキュメントを開発の中心に据えることは、発注者に三つの具体的なメリットをもたらします。
一つ目は、認識ズレの防止です。「こういうものを作ってほしい」という発注者の意図が文書として固まっていれば、完成したものが想定と違う、というすれ違いを減らせます。
二つ目は、検収の基準になることです。何をもって「完成」とするかが文書で定義されていれば、納品されたものがその通りにできているかを確認できます。判断のよりどころができるわけです。
三つ目は、引き継ぎのしやすさです。仕様書や設計書が残っていれば、別のベンダーに乗り換えたり、社内で内容を確認したりする際に、ゼロから調べ直す必要がなくなります。
これら三つはいずれも、ドキュメントが「あって当然の成果物」として残ることが前提です。だからこそ発注者は、ドキュメントを受け取れる状態を自ら作っておく必要があります。
ドキュメントがないと発注者に何が起きるか
ドキュメント駆動開発のメリットは、裏を返せば「ドキュメントがないと何が起きるか」を考えると一層はっきりします。ここでは、ドキュメントの不在や未更新が発注者にもたらす具体的なコストを、実際に直面しやすい痛みに沿って見ていきます。
追加開発・保守のたびに発生する再調査コスト
最も分かりやすいのが、冒頭でも触れた「現状調査費」です。仕様書や設計書が残っていない、あるいは古いまま更新されていないと、追加開発や保守を担当する側は、まず現状のシステムがどう動いているかを調べるところから始めなければなりません。
この調査作業には当然、人の時間がかかります。コードを一行ずつ追って構造を把握し、どこをどう変えれば既存機能を壊さずに済むかを確認する。本来であれば一度作ったときに文書化しておけば不要だったはずの作業が、改修のたびに繰り返し発生します。「前に作ったのに、なぜまた調べる費用がかかるのか」という疑問の答えは、まさにここにあります。
しかも、この調査費は一度きりではありません。ドキュメントが残らない限り、次の改修でも、その次の改修でも、同じように発生し続けます。一回あたりは数十万円規模でも、システムの寿命を通じて積み上がれば、当初の開発費に匹敵することすらあります。
属人化 ― 特定のベンダー・担当者しか中身を知らない状態
ドキュメントが残らないことのもう一つの弊害が、属人化です。システムの中身を理解しているのが、開発を担当した特定のベンダー、あるいはその中の特定の担当者だけ、という状態に陥ります。
この状態では、発注者は実質的にそのベンダーに依存せざるを得ません。担当者が異動・退職したり、ベンダー自体が事業を縮小・廃業したりすれば、システムの中身を知る人が誰もいなくなる、というリスクを抱え込むことになります。文書として残っていれば組織の資産になるはずの知識が、特定の個人の頭の中だけに留まってしまうのです。
引き継ぎ・ベンダー変更の失敗とベンダーロックイン
属人化が進むと、ベンダーの変更も難しくなります。別のベンダーに乗り換えようとしても、新しいベンダーはシステムの中身が分からないため、引き継ぎに膨大な調査時間を要求します。その見積もりが高額になれば、「結局、今のベンダーに頼み続けるしかない」という状況に追い込まれます。これが、いわゆるベンダーロックインです。
価格や対応に不満があっても乗り換えられない。発注者にとって不利な交渉条件を抱えたまま、長期的に付き合わざるを得なくなります。ドキュメントの不在は、目先の調査費という形だけでなく、こうした交渉力の喪失という形でもコストを生みます。
なぜドキュメントは更新されないのか
ここで一度立ち止まって考えたいのは、「なぜドキュメントは残らない、あるいは更新されないのか」です。
一つの理由は、ドキュメントが「作って終わり」になりがちだからです。初回開発時に仕様書を作っても、その後の改修で実際のシステムだけが変わり、文書が古いまま放置される。結果として、文書はあっても実態と食い違い、使い物にならなくなります。
そしてより根本的な理由は、ドキュメントを更新する責任が、どこにも明確に定められていないことです。「誰が・いつ・どこまで更新するか」が契約にも取り決めにも書かれていなければ、それは誰の仕事でもなくなります。開発側にしてみれば、明示的に求められていない作業に手間をかける理由はありません。ドキュメントが残らないのは、多くの場合、関係者の怠慢ではなく、責任の所在が仕組みとして決まっていないことの帰結なのです。
だとすれば、解決策も見えてきます。ドキュメントの作成・更新を、相手の善意や心がけに期待するのではなく、契約と検収という仕組みの中に組み込んで「やらざるを得ないこと」にしてしまえばよいのです。
契約書・検収条件に盛り込むべきドキュメント要件
ここからが本題です。ドキュメントを確実に手元に残すには、「お願い」ではなく「契約上の義務・正式な納品物」として扱うことが欠かせません。発注者がコードを読めなくても、契約書と検収条件を整えることはできます。具体的にどう組み込むかを見ていきましょう。
なお、本記事で示す契約の考え方や記載イメージは、発注者が要件を整理するための一般的な指針です。実際の契約条項として有効かどうか、自社の取引に適した文言かどうかは、弁護士など専門家への確認を推奨します。
ドキュメントを「納品物」として契約に明記する
第一歩は、契約書や発注仕様の中で、ドキュメントを成果物（納品物）として明記することです。
多くのトラブルは、契約上の納品物が「システム一式」とだけ書かれ、ドキュメントが含まれているのかどうか曖昧なまま進むことに起因します。動くシステムだけが納品対象で、仕様書や設計書はあくまで「あれば」という扱いになっていると、文書が残らなくても契約上は問題なし、ということになりかねません。
これを防ぐには、納品物の一覧に、システム本体と並べてドキュメントを具体的に列挙します。たとえば「要件定義書」「基本設計書」「運用保守マニュアル」といった形で、どの文書を納品物に含めるのかを書類名のレベルで明示するのが理想です。何を含めるべきかは後ほど整理します。
検収条件にドキュメントの提出・更新を組み込む
納品物に明記するだけでは、まだ足りません。実効性を持たせるには、検収条件にドキュメントを組み込むことが効果的です。
検収とは、納品されたものが契約通りにできているかを発注者が確認し、問題なければ受け入れる手続きです。この検収の合格条件に「定められたドキュメントが提出されていること」を含めておきます。言い換えれば、ドキュメントが提出されていなければ検収は完了しない、という建て付けにするわけです。
検収が完了しなければ、通常は支払いも保留されます。つまり「ドキュメントを出さなければ支払われない」という状態を作ることで、開発側にとってドキュメントの提出が、後回しにできない必須の作業になります。善意に頼らず、仕組みとして提出を促す力が働くのです。
保守・追加開発契約での更新義務の定め方
ここまでは主に初回開発の話ですが、本当に重要なのは保守・追加開発のフェーズです。なぜなら、ドキュメントが実態と食い違っていく最大の原因は、改修時に文書が更新されないことだからです。
そこで、保守契約や追加開発の契約においても、「変更を加えた場合は、関連するドキュメントを変更内容に合わせて更新する」ことを成果物・義務として定めておきます。改修のたびに、変更後の仕様を反映した文書が提出される建て付けにすれば、ドキュメントは常に最新の状態に保たれます。
この更新義務も、初回開発と同じく検収条件と結びつけておくと実効性が高まります。「改修は完了したが、ドキュメントは更新されていない」という状態を検収不合格として扱えるようにしておけば、更新が確実に行われるようになります。
記載文言のイメージと専門家確認が必要な点
実際の契約にどう落とし込むか、イメージを持っておくと発注者として要望を伝えやすくなります。考え方としては、おおむね次のような要素を契約・発注仕様に含めることになります。
- 納品物の定義に、システム本体とあわせて具体的なドキュメント名を列挙する
- それぞれのドキュメントについて、提出時期と提出形式（編集可能な形式かどうか等）を定める
- 検収の合格条件に「所定のドキュメントが提出・更新されていること」を含める
- 保守・追加開発では「変更に対応したドキュメント更新」を成果物・義務に含める
ただし、これらをどのような文言で契約書に記載すれば法的に有効か、また自社の取引慣行や相手との力関係に照らして妥当かは、ケースによって異なります。前述のとおり、具体の契約文言については弁護士など専門家への確認を強く推奨します。本記事はあくまで、発注者が「何を求めるべきか」を整理するための指針として活用してください。
最低限維持すべきドキュメントの種類
契約や検収でドキュメントを要求するとき、「では具体的にどの文書を求めればよいのか」が次の疑問になります。理想を言えば多くの文書が揃っているに越したことはありませんが、現実には発注者が優先してこだわるべきものに絞って考えるのが実践的です。ここでは、発注者が読んで何を確認でき、これがないと将来どう困るかをセットで整理します。
なお、システム開発では工程ごとにさまざまな成果物が作られます。各工程で作成される文書の種類と役割については、システム開発の成果物・ドキュメントとは？工程別の種類と納品時チェックリストでまとめています。
何を作るかを示すドキュメント
まず押さえたいのが、「何を作るか」を定めた文書です。代表的なものが要件定義書と仕様書です。
要件定義書は、そのシステムで何を実現したいのか、どんな業務をどう支援するのか、という目的やゴールを記したものです。仕様書は、それを実現するために具体的にどんな機能が必要かを定めた文書です。
発注者がこれらを読めば、「このシステムは何のために、何をするものなのか」を確認できます。これがないと、追加開発の際に「そもそもこの機能は何のためにあったのか」が分からず、変更の影響範囲を判断できなくなります。発注者が中身を理解するうえでの土台となる文書であり、最優先で残すべきものです。
どう作ったかを示すドキュメント
次に重要なのが、「どう作ったか」を示す文書です。設計書、システム構成図、API・データ仕様などがこれにあたります。
設計書や構成図は、システムがどんな部品で構成され、どうつながって動いているかを示します。API 仕様やデータ仕様は、システムが外部とどうやり取りするか、どんなデータをどう持っているかを定めたものです。
これらは技術的な内容を含むため、非エンジニアの発注者がすべてを理解するのは難しいかもしれません。それでも、こうした文書が「存在しているかどうか」は確認できます。これらが揃っていれば、別のベンダーが引き継ぐ際の調査時間を大幅に減らせます。逆にこれがないと、先ほど触れた再調査コストや属人化が、まさにこの部分で発生します。
運用・引き継ぎのためのドキュメント
三つ目が、日々の運用や将来の引き継ぎのための文書です。運用保守マニュアルと変更履歴がこれにあたります。
運用保守マニュアルは、システムを動かし続けるために必要な操作や、トラブル時の対応手順を記したものです。変更履歴は、いつ・どんな改修を・なぜ行ったかを記録したものです。
とくに変更履歴は、改修を重ねるシステムにおいて見落とされがちですが、価値の高い文書です。過去の変更の経緯が分かれば、新たな改修が過去の判断と矛盾しないかを確認でき、トラブルの再発を防げます。
優先順位 ― 発注者が最低限こだわるべきもの
すべてを完璧に揃えるのが難しい場合、発注者が最低限こだわるべきは次の順序で考えると整理しやすくなります。
- 要件定義書・仕様書（何を作るか） ― これがないと、システムの目的そのものが分からなくなります。最優先で残します
- 設計書・構成図・API/データ仕様（どう作ったか） ― 引き継ぎ時の調査コストを左右する中核。技術文書ですが「存在の有無」は必ず確認します
- 運用保守マニュアル・変更履歴（運用・引き継ぎ） ― 継続的な運用と将来の改修の安全性を支えます
判断の軸は、システムの規模そのものよりも「将来、追加開発や引き継ぎが発生する可能性があるか」です。長く使う見込みのあるシステムほど、これらの文書が残っているかどうかが、後々のコストを大きく左右します。これらの一覧は、検収時に「揃っているか」を確認するチェックポイントとしても使えます。
発注者がドキュメント整備を主導する進め方
契約と検収で仕組みを整えるのに加えて、発注者が日常的にどう関わるかも、ドキュメントを残すうえで大切です。コードを読めなくても、ドキュメントの有無と更新状態を確認することは誰にでもできます。ここでは、発注の流れに沿って、発注者が主導するための関わり方を時系列で見ていきます。
発注・見積もり依頼の段階で要件として伝える
最も効果が大きいのは、いちばん最初、発注や見積もりを依頼する段階でドキュメントの要件を伝えることです。
開発が始まる前、あるいは見積もりを取る時点で、「納品物には仕様書・設計書・運用保守マニュアルを含めてほしい」「改修時にはドキュメントの更新も含めてほしい」と明確に伝えます。これを最初に伝えておけば、ベンダー側もその作業を見込んで見積もりや計画を立てられます。
後から「ドキュメントも出してほしい」と追加で要求すると、追加費用や調整が発生しがちです。発注前に要件として組み込んでおくのが、結果的にもっともスムーズで、費用面でも有利になります。複数社から見積もりを取る場合、ドキュメントの扱いを各社がどう提案してくるかは、ベンダーの姿勢を見極める材料にもなります。
開発中 ― マイルストーンごとに中間提出を求める
開発が始まったら、すべてが完成してからまとめてドキュメントを受け取るのではなく、節目（マイルストーン）ごとに中間的な提出を求めるのが効果的です。
たとえば、要件定義が固まった段階で要件定義書を、設計が終わった段階で設計書を確認する、といった具合です。こうすることで、文書が最後に慌てて作られる（あるいは作られないまま終わる）事態を防げます。また、早い段階で発注者が文書を確認すれば、認識のズレもその時点で発見でき、後戻りの少ない開発につながります。
ここでも、発注者がコードを読める必要はありません。「定めた文書が、定めたタイミングで出てきているか」を確認するだけでも、整備を前に進める力になります。
検収・保守 ― 更新を継続させる仕組みとして回す
最後に、検収と保守のフェーズです。検収の際は、システムの動作確認だけでなく、ドキュメントが約束どおり揃っているかを検収項目として確認します。前のセクションで整理したドキュメントの一覧が、そのままチェックリストとして使えます。
そして保守フェーズに入ってからが正念場です。改修のたびにドキュメントが更新されているかを確認し、契約に定めた更新義務がきちんと果たされているかを見ていきます。ここで気を抜くと、せっかく初回に整えたドキュメントも、改修を重ねるうちに再び実態とずれていきます。
大切なのは、ドキュメントの整備を「一度きりのイベント」ではなく「改修のたびに回り続ける仕組み」として捉えることです。契約に更新義務を組み込み、検収のたびに確認する。この仕組みが回り続けている限り、ドキュメントは最新の状態に保たれ、将来の再調査コストや属人化のリスクを構造的に抑えられます。
よくある質問（FAQ）
ドキュメント駆動開発と要件定義は何が違うのですか？
要件定義は、開発の工程の一つです。「何を作るか」を最初に固める作業を指します。一方、ドキュメント駆動開発は、要件定義を含むさまざまなドキュメントを開発全体の中心・基準に据える「考え方（進め方）」です。要件定義が開発の入り口の一場面だとすれば、ドキュメント駆動開発は、入り口から完成・運用まで一貫してドキュメントを軸にする姿勢、と整理すると分かりやすいでしょう。
ドキュメントを契約で義務づけると、開発費は上がりますか？
短期的には、ドキュメントの作成・更新の手間が見積もりに反映され、費用が上がる場合があります。ただし、本記事で見たように、ドキュメントがないと追加開発・保守のたびに再調査費が繰り返し発生し、引き継ぎの失敗やベンダーロックインといったコストも生まれます。これらを長期的に積み上げると、初回にドキュメントを整えておくほうが、システムの寿命全体では費用を抑えられるケースが少なくありません。目先の金額だけでなく、将来発生し続けるコストと比較して判断することをおすすめします。
すでに開発済みでドキュメントがないシステムはどうすればいいですか？
すでに動いていてドキュメントがないシステムでも、後から整備することは可能です。現実的なのは、次の保守や追加開発を依頼するタイミングで、「今回の改修にあわせて、現状の仕様書・設計書も作成・整備してほしい」と要求する方法です。既存システムの中身を文書に起こす作業には一定の費用がかかりますが、それ以降の改修コストを下げる投資と考えられます。一度にすべてを整備するのが難しければ、改修する範囲から少しずつ文書化していく進め方もあります。
小規模な開発でもドキュメントは必要ですか？
必要かどうかは、開発の規模そのものよりも「将来、追加開発や引き継ぎが発生する可能性があるか」で判断するのが実践的です。小規模でも長く使い、改修を重ねる見込みがあるなら、ドキュメントの価値は十分にあります。その場合でも、すべてを揃える必要はなく、最低限「何をするシステムか（仕様）」と「どう運用するか（運用手順）」だけでも残しておけば、将来の助けになります。
ドキュメントを要求するとベンダーとの関係が悪くなりませんか？
検収条件や成果物を明確にすることは、必ずしも関係を悪くするものではありません。むしろ、何を・いつ・どの状態で納品するかがはっきりすれば、ベンダー側も「言った・言わない」のトラブルを避けられ、認識のズレを防げます。これはベンダーにとってもメリットです。最初から要件として誠実に伝え、双方が納得したうえで進めれば、ドキュメントの整備はむしろ健全で長続きする関係づくりにつながります。
まとめ ― ドキュメントは善意でなく仕組みで残す
ドキュメント駆動開発とは、仕様書や設計書といったドキュメントを開発の中心に据える進め方であり、発注者にとっては「システムと並ぶ正式な納品物としてドキュメントを受け取る」という発想です。
ドキュメントが残らないのは、その作成・更新を外注先の善意や開発文化に任せてしまっているからです。だからこそ、相手の心がけに期待するのではなく、契約書の納品物・検収条件・保守契約の更新義務という仕組みに組み込むことで、ドキュメントは確実に手元に残ります。再調査費の繰り返しや属人化、ベンダーロックインといったコストは、この仕組みづくりによって構造的に抑えられます。
発注者として今日から踏み出せる第一歩は、次の発注や見積もり依頼の場面で、ドキュメントを納品物・検収条件に含めるよう明確に伝えることです。コードが読めなくても、ドキュメントを守らせる仕組みは発注者自身の手で作れます。ドキュメントは、善意ではなく仕組みで残しましょう。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
