システム開発の納品物は「動くシステム」だけではありません。 ソースコード、設計書、テスト結果、操作マニュアル、そして権利の扱い——これらを含めて「何を受け取るか」を発注前に決めておかないと、開発が終わってから「設計書がもらえない」「ソースコードは渡せないと言われた」「他社に引き継げない」といったトラブルが起きます。納品物の抜けは、その場では気づきにくく、保守や次の改修、ベンダー変更のときに初めて痛手として表面化します。
本記事は、システム開発を発注する経営者・情シス・発注担当の方に向けて、納品物として受け取るべき成果物を一覧で整理し、検収でチェックすべき点をお伝えします。契約時の検収・瑕疵（契約不適合責任）の考え方は検収・瑕疵対応の読み方、発注全体の流れは初めてのシステム開発外注ガイドにまとめています。本記事はその中でも、**「何をもらうか（納品物）」**に絞ります。
目次
- 結論：納品物は「動くもの」＋「引き継げる資料」＋「権利」
- 受け取るべき納品物の一覧
- 納品物が抜けると、いつ・どう困るか
- 契約形態（請負・準委任）で納品物の扱いが変わる
- クラウド・SaaSを使う開発での納品物の注意点
- 納品物は契約前に決める
- 検収でチェックすべきこと
- 納品物でよくある失敗パターン
- 納品物の「質」をどう見分けるか
- 納品物 確認チェックリスト
- よくある質問（FAQ）
- 納品物・検収の整理で迷ったら
<a id="conclusion"></a>
結論：納品物は「動くもの」＋「引き継げる資料」＋「権利」
システム開発の納品物は、大きく3つの層に分けて考えると抜けが防げます。
- 動くもの：本番環境で動作するシステムそのもの（プログラム、設定）
- 引き継げる資料：設計書、テスト結果、マニュアルなど、後から中身を理解・保守するための書類
- 権利：ソースコードの著作権や利用範囲、成果物を他社に引き継げるかどうか
多くの発注トラブルは、1つ目（動くもの）だけを納品物と考え、2つ目と3つ目を確認しないまま検収してしまうことから起きます。動いているから合格、としてしまうと、後で「保守を別の会社に頼めない」「改修しようにも設計が分からない」という事態になります。納品物は「今動くか」だけでなく、**「将来、自社や別の会社が引き継げるか」**の視点で決めることが重要です。
<a id="list"></a>
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
受け取るべき納品物の一覧
システムの規模や契約によって変わりますが、一般的に確認すべき納品物は次の通りです。すべてが必須とは限りませんが、「要る／要らない」を発注前に判断するための一覧として使ってください。
横にスクロールして確認できます
| 分類 | 納品物 | なぜ必要か |
|---|---|---|
| システム本体 | 実行可能なプログラム・本番環境の構成 | 業務で使うため |
| ソースコード | プログラムの元のコード | 改修・保守・ベンダー変更に必要 |
| 要件・設計書 | 要件定義書、基本設計書、詳細設計書 | 中身を理解し、後で直すため |
| データベース関連 | テーブル定義、ER図、初期データ | データ構造を把握・移行するため |
| テスト関連 | テスト仕様書、テスト結果 | 何をどこまで検証したかを確認するため |
| マニュアル | 操作マニュアル、運用手順書 | 現場が使い、運用するため |
| インフラ・構成情報 | サーバ構成、ネットワーク、アカウント情報 | 運用・移行・障害対応のため |
| 権利・ライセンス | 著作権の扱い、使用ライブラリのライセンス一覧 | 利用範囲・法的リスクを確認するため |
特に見落とされがちなのが、ソースコード・設計書・構成情報・権利です。これらが揃っていないと、そのシステムは「作った会社でしか触れない」状態になり、保守や改修で足元を見られるリスクが生まれます。
<a id="risk"></a>
納品物が抜けると、いつ・どう困るか
納品物の抜けは、開発直後には問題になりません。困るのは、たいてい半年〜数年後です。
横にスクロールして確認できます
| 抜けた納品物 | いつ困るか | どう困るか |
|---|---|---|
| ソースコード | 改修・保守を別会社に頼むとき | 他社が引き継げず、開発元に縛られる |
| 設計書・仕様書 | 機能追加・障害調査のとき | 中身が分からず、調査に余計な費用と時間 |
| テスト結果 | 品質を疑うトラブルのとき | どこまで検証されたか不明で責任が曖昧 |
| 構成情報・アカウント | サーバ移行・障害対応のとき | 復旧やサーバ移行ができない |
| 権利の取り決め | 別用途で使いたい・他社に渡したいとき | 使えない・追加交渉が必要になる |
つまり納品物の確認は、「今」のためではなく、将来の保守・改修・移行の自由を確保するための投資です。ここを検収時に握っておかないと、後から取り戻すのは難しくなります。費用構造とあわせた考え方は中小企業のシステム開発費用ガイドも参考にしてください。
<a id="keiyaku"></a>
契約形態（請負・準委任）で納品物の扱いが変わる
同じ開発でも、契約形態によって「何が納品物になるか」の考え方が変わります。ここを理解しておかないと、契約形態と納品物の期待がずれてトラブルになります。
横にスクロールして確認できます
| 契約形態 | 納品物の考え方 | 注意点 |
|---|---|---|
| 請負契約 | 完成した成果物の納品が前提。納品物リストを明確にしやすい | 「一式」で曖昧にせず、資料・権利まで列挙する |
| 準委任契約 | 労働（作業）の提供が主で、必ずしも完成物の納品を約束しない | 何を成果物として残すかを別途取り決める必要がある |
特に注意が要るのは準委任契約です。準委任は「作業してもらう」契約で、請負のような完成責任・納品義務が前提ではありません。そのため、「エンジニアに常駐で作ってもらったが、設計書やドキュメントが残っていない」ということが起きがちです。準委任で進める場合は、成果物として何を、どの粒度で残すかを作業範囲の取り決めに明記しておく必要があります。「作業はしたが記録は残らない」という事態を避けるためです。
つまり、契約形態を選ぶ段階で、その形態における納品物の扱いを理解し、足りない部分を取り決めで補う。これが納品物トラブルを防ぐ前提になります。
<a id="cloud"></a>
クラウド・SaaSを使う開発での納品物の注意点
近年は、フルスクラッチではなく、クラウドサービスやSaaS、ノーコード／ローコードを組み合わせて開発するケースが増えています。この場合、納品物の考え方が従来と少し変わるため、注意が必要です。
- ソースコードが「一部しかない／存在しない」ことがある：SaaSやノーコードを土台にした場合、従来の意味でのソースコードが渡せないことがあります。この場合は、代わりに設定情報・構成の記録・アカウント権限が引き継ぎの鍵になります。「ソースがないから引き継げない」とならないよう、何を受け取れば別の担当・別の会社が保守できるかを確認します。
- アカウントの所有者が誰かを確認する：クラウドサービスの契約アカウントが開発会社名義のままだと、契約を切ったときにシステムごと使えなくなる恐れがあります。アカウントは発注側名義で持つか、少なくとも所有権を確保しておきます。
- データのエクスポート手段を確認する：将来サービスを乗り換える場合に備え、自社のデータを取り出せる形式・手段があるかを確認します。データを人質に取られる状態を避けるためです。
- 月額利用料と納品物の切り分け：SaaS利用料は「納品物」ではなく継続コストです。初期構築の成果物と、毎月かかる利用料を分けて把握します。
クラウド・SaaSを使う開発では、「ソースコードを受け取る」だけが引き継ぎ条件ではありません。設定・アカウント・データの3点を押さえることが、将来の自由を守る鍵になります。
<a id="contract"></a>
納品物は契約前に決める
納品物をめぐるトラブルの根本原因は、契約時に納品物の範囲が明記されていないことです。「一式」「本システム」といった曖昧な書き方では、何が含まれるかが解釈次第になり、「ソースコードは別料金」「設計書は納品対象外」と後から言われても反論できません。
契約前に、次を明確にしておきます。
- 納品物のリスト：上の一覧のうち、何を納品物に含めるか
- 形式と粒度：設計書はどのレベルまで作るか、マニュアルは誰向けか
- 権利の扱い：ソースコードの著作権は誰に帰属し、どこまで自由に使えるか
- 引き渡しのタイミングと方法：いつ、どのような形で受け取るか
これらは見積もりや提案の段階で確認し、契約書・仕様書に落とすのが原則です。発注前の準備項目としては発注前のRFP・契約準備もあわせて確認してください。
<a id="acceptance"></a>
検収でチェックすべきこと
納品物を受け取る「検収」では、動作確認だけでなく、次の観点でチェックします。
- 契約で決めた納品物が揃っているか：リストと照合し、抜けがないか確認する。
- 中身が実用に足るか：設計書が実態と合っているか、マニュアルが現場で使えるか。形だけの資料でないか。
- 業務要件を満たしているか：動くかどうかだけでなく、当初の業務課題を解決できているか。
- 権利・ライセンスの取り決め通りか：ソースコードや構成情報が約束通り引き渡されるか。
特に重要なのは、「動く＝合格」で検収を通さないことです。動作は最低ラインであり、資料や権利の抜けは動作確認では見つかりません。検収の合格基準を、動作・資料・権利の3面で持っておくことが、後のトラブルを防ぎます。検収基準そのものの決め方は検収・瑕疵対応の読み方を参照してください。
<a id="failure"></a>
納品物でよくある失敗パターン
- 「一式」で契約し、ソースコードが納品対象外だった：改修を別会社に頼めず、開発元に縛られる。
- 設計書が形だけで、実態と合っていない：障害調査や機能追加で結局ソースを読む羽目になる。
- 動作確認だけで検収を通した：資料や権利の抜けに後から気づき、取り戻せない。
- アカウント・構成情報を受け取っていない：担当者交代やサーバ移行で復旧・移行ができない。
- 権利の取り決めがなく、別用途で使えない：作ったシステムを他事業に転用しようとしたら、追加交渉が必要になった。
いずれも、次のチェックリストを発注前・検収前に使えば防げます。
<a id="quality"></a>
納品物の「質」をどう見分けるか
納品物は「揃っているか」だけでなく「使えるか」も重要です。設計書やマニュアルは、形式的に存在していても中身が伴わないことがあります。次の観点で質を見分けてください。
- 設計書が実態と一致しているか：開発中に仕様変更があった場合、設計書が更新されず古いままのことがあります。最新の実装と合っているかを確認します。
- 第三者が読んで分かるか：作った本人にしか分からない資料は、引き継ぎの役に立ちません。社内の別の担当や、別の会社の技術者が読んで理解できる粒度かを見ます。
- マニュアルが現場目線か：開発者向けの用語で書かれたマニュアルは、実際に使う現場では役に立ちません。誰が使うマニュアルなのかを確認します。
- テスト結果に根拠があるか：「テスト済み」だけでなく、何をどうテストして、どういう結果だったかが記録されているかを見ます。
質の低い納品物は、受け取った時点では気づきにくく、いざ保守や改修で使おうとしたときに「使えない」と分かります。検収の場で、**「この資料で、半年後に別の人が引き継げるか」**を基準に質を判断すると、抜けや形骸化を見抜きやすくなります。
<a id="checklist"></a>
納品物 確認チェックリスト
- 受け取る納品物のリストを契約前に決めてある
- ソースコードを納品物に含めているか判断した
- 設計書・仕様書の粒度と対象範囲を決めてある
- テスト仕様書・結果を受け取ることになっている
- 操作マニュアル・運用手順書の対象読者を決めてある
- サーバ構成・アカウント情報の引き渡しを確認した
- 著作権・ライセンスの扱いを契約に明記してある
- 検収を動作・資料・権利の3面で判定する基準がある
- 検収で業務要件を満たすかを確認する予定がある
<a id="faq"></a>
よくある質問（FAQ）
Q. ソースコードは必ずもらえますか？ A. 契約次第です。「一式」といった曖昧な表現だと、ソースコードが納品対象外とされることがあります。改修・保守・ベンダー変更の自由を残すなら、納品物に含めるかを契約前に明確にしてください。
Q. 設計書はどこまで作ってもらうべきですか？ A. 後で誰が使うかで決めます。障害調査や機能追加を想定するなら、実態と合った設計書が必要です。形だけの資料では役に立たないため、粒度と対象範囲を発注時に決めましょう。
Q. 動いていれば検収は合格でよいですか？ A. 動作は最低ラインです。資料や権利の抜けは動作確認では見つかりません。動作・資料・権利の3面で合格基準を持ち、業務要件を満たすかも含めて検収してください。
Q. 納品物が足りないと後から気づきました。取り戻せますか？ A. 契約に明記していなければ、後からの請求は難しいことが多いです。追加費用や交渉が必要になります。だからこそ、契約前に納品物を決めておくことが重要です。
Q. 権利はなぜ確認が必要ですか？ A. ソースコードの著作権や利用範囲が曖昧だと、別用途への転用や他社への引き継ぎができないことがあります。将来の選択肢を狭めないため、権利の取り決めを契約に入れてください。
Q. SaaSやノーコードで作る場合、ソースコードがもらえないと引き継げませんか？ A. 必ずしもそうではありません。SaaSやノーコードを土台にした場合、従来のソースコードが存在しないこともあります。その場合は、設定情報・構成の記録・アカウント権限・データのエクスポート手段を受け取れれば、別の担当や会社でも保守・移行が可能です。「ソースの有無」ではなく「引き継げるか」で確認してください。
Q. 検収の期限が短く、十分に確認できません。 A. 検収期間が短すぎると、抜けや不具合を見つけられないまま合格させてしまいます。契約時に、動作・資料・権利を確認できるだけの検収期間を確保しておくことが重要です。短い場合は、期間の延長や段階的な検収を求めましょう。
<a id="cta"></a>
納品物・検収の整理で迷ったら
システム開発の納品物は、「動くもの」だけでなく**「引き継げる資料」と「権利」**まで含めて、契約前に決めることが重要です。ここを曖昧にすると、開発が終わってから、保守・改修・移行の自由を失うことになります。
GXOは、特定の開発を売り込む前に、受け取るべき納品物の整理と、見積もり・契約に納品物が正しく反映されているかの第三者チェックからご一緒します。
- 受け取った見積もり・契約に納品物が抜けていないか見てほしい → 見積もりセカンドオピニオン
- 発注前の要件・契約準備から相談したい → システム開発・DXの相談
- 検収・瑕疵対応の契約観点を確認したい → 検収・瑕疵対応の読み方
- まず自社のIT・DXの現在地を診断したい → DX成熟度診断
「動くか」より先に「引き継げるか」を確認する。その整理を、契約と検収の前にご一緒します。 [//]: # (strict-audit-extension-20260717)
GXO式「納品・検収・引継ぎ」100点評価表
GXO独自分析では、ファイルの有無ではなく、第三者が再現・運用・改修できるかで採点する。このチェックリストを契約前のRFPと検収時の両方で使う。
横にスクロールして確認できます
| 成果物群 | 配点 | 満点の受入証拠 |
|---|---|---|
| 要件・設計 | 20 | 要件ID、業務、画面、データ、API、非機能の対応 |
| コード・環境 | 20 | リポジトリ、依存版、構築、設定、秘密情報の移管 |
| テスト | 20 | 計画、結果、欠陥、性能、セキュリティ、受入テスト |
| 運用 | 20 | 監視、ログ、バックアップ、復元、障害、SLA、権限 |
| 権利・出口 | 20 | 所有・利用権、第三者部品、契約名義、移行手順、削除証明 |
80点以上かつ重大欠陥0件で検収判断へ進む。60〜79点は条件付き検収ではなく、不足物・修正期限・支払条件を契約に照らして合意する。ソースが起動しない、管理者権限がない、DB復元できない、重大欠陥が残る、契約で定めた成果物が未納なら検収を停止する。この状態での検収は将来の保守・移管に向かない。
納品台帳・検収テンプレート
成果物 / 版 / 保管場所 / 所有者 / 最終更新日：
契約上の納品条件 / 受領日 / 検査者：
再現：新環境構築 / DB復元 / API接続 / ロールバック
欠陥：重大___件 / 中___件 / 軽微___件 / 修正期限
権利：著作権 / OSS / SaaS / ドメイン / クラウド / データ
判定：合格 / 不合格 / 再検査日___
開発費1,500万円の5%を最終検収支払とする契約例なら75万円だが、割合や支払条件は契約で変わる。未納資料の再作成費用が200万円、環境再構築300万円になれば、形式的な検収の方が高い。このGXO計算は相場でなく、受領証拠と将来費用を比較する例である。
一次資料と根拠と検証方法
版番号: GXO-DELIVERABLE-20260717-v1.0。確認日: 2026年7月17日。検証可能性の証拠は契約・成果物一覧・ハッシュ・受入結果・再現ログ・権限・請求である。要件・契約・構成・権利・納期変更を更新条件にする。公式資料の事実とGXOの見解である配点・費用例を分離し、法的効果を保証しない。小規模定型導入は自社チェックできるが、ソース・個人情報・クラウド名義・ベンダー変更が絡む会社は第三者への相談が向く。納品・検収セカンドオピニオンで支払前に確認できる。
