システム開発を外注して納品を迎えるとき、「何を受け取れば正解なのか」が分からず、動くシステムだけ受け取って終わりにしてしまう発注者は少なくありません。ですが、後から保守を別会社に頼みたくなったり、トラブルで責任を問いたくなったりしたときに、設計書やソースコードが手元にないと動けなくなります。受け取るべきものを取りこぼさないことが、納品時にいちばん大事です。
結論から言うと、受託開発では動くシステム本体だけでなく、要件定義書・設計書・ソースコード一式・テスト結果・各種マニュアルなど、工程ごとに生まれた成果物を納品物として受け取るのが基本です。しかも、これらは契約の納品物に明記しておかないともらえないことがあります。この記事では、受託開発で受け取るべき納品物と成果物の一覧を工程別に整理し、成果物と納品物の違い、検収で見るべき観点、そして納期遅れを防ぐ発注側の進め方までを解説します。
この記事のポイント
- 納品物は動くシステムだけでなく、要件定義書・設計書・ソース・テスト結果・マニュアルまで
- ソースコードや設計書は契約の納品物に明記しないともらえないことがある
- 検収は「合格」して初めて納品扱い。何をもって合格かを事前に決めておく
- 「みなし検収条項」があると、確認しないまま合格扱いになるので注意
目次
受託開発で受け取るべき納品物と成果物の一覧
受託開発の納品物でつまずくのは、「システムが動けば完成」と考えてしまい、後から必要になる書類やソースを受け取り損ねるからです。まずは成果物と納品物の違いを押さえ、工程ごとに何を受け取るべきかを整理しましょう。
成果物と納品物の違い
よく混同されますが、「成果物」と「納品物」は指す範囲が少し違います。成果物は、開発の各工程で生み出される中間・最終のアウトプット全般（要件定義書、設計書、ソースコード、テスト結果など）を指します。納品物は、そのうち契約にもとづいて最終的に発注者へ納めるものを指します。
発注者にとって大事なのは、「作られた成果物のうち、どれを納品物として受け取るか」を決めておくことです。開発会社の内部では設計書やテスト結果が作られていても、契約の納品物リストに入っていなければ、手元に渡されないまま終わることがあります。成果物と納品物のズレが、後の「もらえなかった」を生みます。
もう一つ知っておきたいのが、納品物の「形式」です。同じ設計書でも、編集できるWordやExcel、図が編集できる形式でもらうのか、PDFの読み取り専用でもらうのかで、後の使い勝手がまったく変わります。将来自社で改修・更新することを考えるなら、編集可能な形式（元データ）で受け取れるかも、契約前に確認しておくとよいでしょう。「PDFはもらえたが元データはもらえず、更新できない」というのは、地味によくある取りこぼしです。
工程別に受け取るべき納品物
受託開発では、工程ごとに次のような成果物が生まれます。発注者としては、原則これらを納品物として受け取れるようにしておくと、運用・保守や将来の移管で困りません。
| 工程 | 主な納品物 | 発注者にとっての用途 |
|---|---|---|
| 要件定義 | 要件定義書 | 何を作るかの合意・検収の基準 |
| 設計 | 基本設計書・詳細設計書 | 改修・保守時に中身を追える |
| 実装 | ソースコード一式・実行ファイル | 他社への移管・自社での改修 |
| テスト | テスト仕様書・テスト結果報告書 | 品質の証拠・不具合時の確認 |
| 納品・運用 | 操作マニュアル・運用手順書・環境情報 | 現場で使う・運用を引き継ぐ |
この表はあくまで代表例で、案件によってはインフラ構成図、データベース定義書、API仕様書、アカウント・パスワードなどの環境情報も重要な納品物になります。自社のシステムを「別の人が引き継いで運用・改修できる状態」にするには何が要るか、という視点で必要な納品物を洗い出しておくと、抜けが減ります。開発会社に「保守・移管に必要な一式をください」と伝えるだけでも、渡してもらえる範囲が変わってきます。
特に重要なのがソースコードです。ソースコードは、開発費を払っていても契約の納品物に明記していないと受け取れないことがあります。将来的に別の会社へ乗り換える、自社で改修する、という可能性が少しでもあるなら、ソースコード一式を納品物に必ず含めておきましょう。要件定義書がどんな項目で構成されるかは、要件定義書テンプレート（Word形式）を見ると、受け取るべき中身の具体イメージがつかめます。
なぜ全部もらっておくべきか
「動けばいいから書類はいらない」と考えると、後で必ず困ります。理由は3つです。第一に、運用・保守で自走できること。設計書やマニュアルがあれば、社内で運用したり、別の会社に保守を頼んだりするときにスムーズです（納品後の保守をどう契約するかは受託開発の保守を解説した記事も参考になります）。第二に、将来の移管に備えられること。開発会社を変える・自社で引き取るとき、ソースと設計書がないと引き継ぎ自体ができません。第三に、トラブル時の証拠になること。仕様どおりに作られたかを、要件定義書やテスト結果で照らし合わせられます。
これらは、開発会社が倒産・撤退したときにも効いてきます。納品物として平時から受け取っておけば、いざというときにシステムを守れます。権利やソースコードの扱いを契約でどう決めるかは、受託開発の契約で発注者が確認すべきことをまとめた記事で詳しく整理しています。
逆に言うと、これらを受け取らないまま運用に入ると、開発会社に依存し続けるしかなくなります。ちょっとした修正でも毎回その会社に頼むしかなく、費用や納期の主導権を握られやすくなる、いわゆるベンダーロックインの状態です。納品物をきちんと受け取ることは、単なる書類集めではなく、「発注者が主導権を持ち続けるための保険」だと考えると、優先度が上がるはずです。すべてを完璧に読み解けなくても、まず手元に揃えておくことに意味があります。
受託開発の納品物を取りこぼさない検収と納期
受け取るべき納品物が分かったら、次はそれを「正しく受け取る」段階、つまり検収と納期の管理です。ここを発注側が押さえておかないと、確認不十分のまま合格扱いになったり、納期が延びたりします。
検収とは何を確認する工程か
検収とは、納品されたシステムや成果物が、契約・仕様どおりにできているかを発注者が確認する工程です。重要なのは、検収に合格して初めて「納品された」とみなされ、開発会社への報酬支払いの条件になる、という点です。つまり検収は、発注者が品質を担保できる最後の関門です。
スムーズに進めるコツは、「何をもって合格とするか」を発注前に決めておくことです。要件定義書をもとに検収チェックリストを用意し、確認する項目・手順を仕様書に盛り込んでおくと、認識のズレが起きにくくなります。検収を含む発注全体の流れは、受託開発の流れと各工程で発注者がやることを解説した記事もあわせて読むと、どの段階で何を確認するかが見えてきます。
検収で見るのは「動くかどうか」だけではありません。要件定義書に書いた機能が全部そろっているか、想定した業務の流れが最後まで通るか、例外的な操作やエラー時の挙動はどうか、といった観点まで確認します。実際に使う現場の担当者にも触ってもらい、「日常業務で本当に回るか」を見てもらうと、開発側の動作確認では気づけないズレが見つかります。逆に、担当者一人がざっと触るだけの検収は、リリース後に「現場で使えない」が噴き出す典型パターンです。
みなし検収条項に注意する
契約書に「みなし検収条項」が入っていることがあります。これは「納品後◯日以内に、具体的な理由を示して不合格の通知をしなければ、検収に合格したものとみなす」という規定です。開発会社側が検収の長期化を防ぐための一般的な条項ですが、発注者にとっては注意が必要です。
この条項があると、忙しくて確認を後回しにしているうちに、期限が過ぎて自動的に合格扱いになってしまうことがあります。合格扱いになれば報酬支払い義務が発生し、後から不具合を見つけても交渉が不利になります。みなし検収条項がある場合は、検収期間が現実的な長さか（数日では短すぎることも）を確認し、納品されたら期間内に必ずチェックリストで検収する体制を組んでおきましょう。
この条項自体は、検収がずるずる延びて報酬が支払われないのを防ぐためのもので、開発会社にとって理不尽な要求ではありません。発注者側で対処すべきは「無くす」ことより「回せる体制にする」ことです。納品予定日を事前に共有してもらい、その週は検収担当者の時間を確保しておく、検収項目は納品前に固めておく、といった段取りをしておけば、みなし検収条項があっても不利にはなりません。納品されてから慌ててチェックリストを作り始めるのが、一番危ない進め方です。
納期遅れを防ぐ発注側の進め方
納期は、開発会社任せにすると守られないことがあります。発注側でできる予防策は、まず契約で納期と報酬、遅延時の責任範囲を書面に明記しておくこと。口頭の「いつ頃までに」では、遅れたときに何も言えません。
さらに効くのが、最終納品を待たずに中間成果物を確認することです。要件定義書、設計書、という区切りで途中のアウトプットを受け取り確認しておけば、認識のズレや遅れの予兆を早く察知できます。「完成してから初めて中身を見る」と、ズレていたときの手戻りが大きく、結果的に納期も費用も膨らみます。区切りごとに確認する進め方が、納期遅れと品質トラブルの両方を防ぎます。
納期遅れの予兆は、進捗報告の「歯切れの悪さ」に出ます。「だいたい順調です」しか返ってこない、中間成果物の提出が遅れる、質問への回答が曖昧、といったサインが続くときは要注意です。発注側からは、定例で進捗を数字（完了した機能の割合など）で共有してもらう、遅れそうなら早めに教えてもらう、という取り決めをしておくと、いきなり納期直前に「間に合いません」と言われる事態を減らせます。発注者が適度に関与し続けることが、丸投げによる遅延を防ぐ一番の方法です。
よくある質問
- Q. 受託開発ではソースコードは必ずもらえますか？
- A. 自動ではもらえないことがあります。開発費を払っていても、契約の納品物にソースコードを明記していないと渡されない場合があります。将来の改修や移管に備え、ソースコード一式を納品物に含めると契約で明記しておきましょう。
- Q. 納品物として最低限もらうべきものは何ですか？
- A. 動くシステム本体に加え、要件定義書・設計書・ソースコード一式・テスト結果・操作/運用マニュアルが基本です。特に設計書とソースは、保守や他社への移管で必須になります。契約前に納品物リストとして合意しておくと安心です。
- Q. 検収はどれくらいの期間で行うべきですか？
- A. システムの規模によりますが、実際に操作して主要機能を一通り確認できる現実的な期間が必要です。契約に「みなし検収条項」がある場合は、その期間内に検収を終えられるよう、チェックリストと体制を事前に準備しておきましょう。
- Q. 設計書やマニュアルは編集できる形式でもらえますか？
- A. 自動ではありません。PDFの読み取り専用で渡され、元データ（Word/Excel等）はもらえないことがあります。将来自社で更新したいなら、編集可能な形式で受け取れるかを契約時に確認しておきましょう。
