納品とは？システム開発の成果物・検収との違いと契約別の扱いを解説

納品とは、受注者が契約で定めた成果物を発注者へ引き渡す行為を指します。システム開発では、動くソフトウェアそのものだけでなく、ソースコードや設計書などを含めて何を渡すかが契約で決まり、引き渡したあとに発注者が中身を確かめる検収へ進む流れです。この記事では、納品と成果物・納品物・検収の違いを言葉の意味から整理し、システム開発で実際に渡す納品物の種類、請負契約と準委任契約で変わる納品・検収・報酬の関係、そして発注者が受入基準を契約前に固めるための実務までをまとめます。一般的なビジネス用語の解説ではなく、システム開発を外注・受注する立場に絞って読み解きます。

まとめ：納品の意味と成果物・検収との違いをシステム開発で整理

納品は受注者が成果物を引き渡す行為、検収は発注者がその中身を仕様どおりか確かめる行為で、動かす主体が逆です。システム開発では、納品しただけでは取引は終わらず、発注者の検収が完了して初めて報酬の支払いや契約不適合責任の起算へ進みます。何を納品物とするか、どんな状態を合格とするかは契約と仕様書で決まるため、ここが曖昧なまま進めると検収でもめます。

実務でつまずきやすいのは、成果物と納品物の混同と、検収基準の未定義の2点です。成果物は各工程で生まれる中間物まで含み、納品物はそのうち契約で渡すものに絞られます。合格ラインを受入テストの形で契約前に決めておけば、納品後の押し問答は起きません。自社のシステム開発でこうした納品範囲と検収条件を詰めたい場合は、一創の基幹システム開発で要件定義から納品・検収までの進め方を相談できます。

納品とは何かと成果物・納品物・検収との違いを言葉の意味で整理

まず用語を切り分けます。納品・成果物・納品物・検収は現場で混ざって使われがちですが、主体とタイミングが違うため、契約書での定義がずれると後工程で衝突します。

納品の意味は受注者が契約で定めた成果物を引き渡す行為を指すこと

納品とは、受注者が契約で約束したものを発注者へ引き渡す履行行為です。物販なら商品の受け渡し、システム開発なら完成したソフトウェアと関連資料の提供を指します。ここで押さえたいのは、納品はあくまで受注者側のアクションだという点です。納品した時点では「渡した」だけで、発注者がそれを受け入れたかどうかは別の話になります。契約書では「納品」を、成果物を所定の方法・場所・期日で引き渡すことと定義し、納期と引き渡し方法をセットで書いておきます。

成果物と納品物の違いは発注者へ引き渡す範囲に絞られるかどうか

成果物は、プロジェクトの各工程で生み出される作業の産物すべてを指します。要件定義書、設計書、ソースコード、テスト仕様書、議事録まで幅広く含みます。一方、納品物は成果物のうち契約で発注者へ引き渡すと決めたものだけです。つまり成果物のほうが広く、納品物はその部分集合になります。社内向けの検討メモや途中版のたたき台は成果物ではあっても納品物には含めない、という切り分けが典型です。契約書に「納品物一覧」を明記し、成果物のどれを渡すのかを確定させておくと、後から「あの資料も出して」という追加要求と有償対応の線引きがしやすくなります。

納品と検収の違いは引き渡す側と受け入れて確認する側で主体が逆

納品と検収は、続けて起こるが主体が正反対の工程です。納品は受注者が渡す行為、検収は発注者が受け取った納品物を仕様どおりか確認し、合否を判定する行為を指します。検収で発注者が合格と判断して初めて、取引上は「受け入れ完了」となり、報酬の支払い義務が確定するのが一般的な流れです。検収には期間が設けられ、その間に発注者が受入テストを行って不具合を洗い出します。納品日と検収完了日は別の日付になる点、そして支払いの起点は多くの場合で検収完了である点は、資金繰りの面でも押さえておきたいところです。

システム開発の納品物の種類と工程ごとに作成するドキュメント一覧

システム開発では「何を納品するか」が案件ごとに変わります。プログラムだけを想像しがちですが、実際にはソースコード・実行環境・各種ドキュメントが束になって納品物を構成します。

ソースコードと実行環境を含む成果物としての納品物の代表的な中身

納品物の中心は、稼働するシステム本体です。具体的には、ソースコード一式、ビルド済みの実行モジュール、データベースの定義や初期データ、サーバーの構成情報などが含まれます。近ごろはコンテナ設定や環境構築の手順を含めて渡し、発注者側で再現できる状態にする形が増えました。ソースコードを納品物に含めるか、著作権や利用範囲をどう扱うかは契約で定めます。ここを決めずに進めると、保守を別会社に頼みたくなったときにソースが手元になく動けない、という事態を招きかねません。納品形態（記録メディアかリポジトリ経由か）も併せて契約に書いておきます。

要件定義書から運用手順書まで工程別に作成する主なドキュメント

システム開発のドキュメントは、工程に沿って積み上がる構造です。上流から順に、要件定義書、基本設計書、詳細設計書、テスト仕様書とテスト結果報告書、そして運用・保守のための操作手順書や運用手順書が並びます。これらのどこまでを納品物とするかは案件の性質で変わり、内製の保守を前提にするなら設計書まで一式で渡す、運用委託まで任せるなら運用手順を厚くする、といった調整をします。ドキュメントの粒度や様式は、発注者が受け入れ後に自走できるかを基準に決めるのが実務的です。仕様書と設計書・要件定義書の役割分担は仕様書の位置づけを解説した記事で確認できます。

請負契約と準委任契約で変わる納品・検収と報酬支払いのタイミング

同じ「開発を任せる」でも、契約類型が請負か準委任かで、そもそも納品・検収という概念の重みが変わります。報酬がいつ確定するかも異なるため、発注前に押さえておく箇所です。

請負契約は成果物の完成と検収完了で報酬支払いが確定する仕組み

請負契約は、仕事を完成させて成果物を引き渡す義務を負う契約です。したがって納品と検収がそのまま契約の核になります。受注者は約束した成果物を完成させて納品し、発注者が検収して合格を出すと報酬請求権が確定する、という流れです。完成しなければ原則として報酬は発生しないため、受注者は「完成」の定義、つまり何をもって検収合格とするかを契約前に握っておく必要があります。検収後に見つかった不具合は、契約不適合責任の問題として扱われるのが原則です。検収を起点とした責任の考え方は瑕疵担保責任と契約不適合責任を解説した記事で確認できます。

準委任契約は業務の遂行が対象で成果物の検収より作業報告が中心

準委任契約は、成果物の完成ではなく業務の遂行そのものを対象にする契約です。善良な管理者の注意を尽くして作業する義務を負い、成果物が仕様に合わないこと自体を根拠に検収不合格として報酬を拒む建て付けにはなりません。報酬は稼働工数や期間に応じて支払われる形が中心で、月次の作業報告が納品物に近い位置づけになります。ただし、成果完成型の準委任のように、一定の成果の達成を条件に報酬を払う設計もあります。どちらの契約類型を選ぶかで納品・検収の意味合いが変わるため、準委任契約と請負・派遣の違いを整理した記事で全体像をつかんでおくと発注判断を誤りません。

発注者が納品と検収でつまずかないために契約前に固めておく条件

ここは判断の章です。玉虫色を避け、発注者が納品・検収でもめないために何を契約前に決めるべきかを条件付きで言い切ります。納品トラブルの多くは、合格基準の曖昧さと検収体制の不足から生まれます。

検収の合格基準を受入テストの形で契約の前に文書化しておく条件

検収でもめないための第一条件は、合格基準を受入テストの形で契約前に決めておくことです。「仕様どおり」という言葉だけでは、発注者と受注者で想定がずれます。主要な業務シナリオを何本か選び、入力と期待結果を一覧にした受入テスト項目を契約書か仕様書に添付しておくと、検収は「その項目が通るか」の客観判定に変わります。逆に、受入テストを用意せずに納品を迎えると、発注者の主観で合否が動き、検収がいつまでも終わりません。発注者側にテスト実施の人員を割けない事情があるなら、受入テストの設計と支援まで受注者へ委ねる範囲を契約に含めておくのが現実的です。何を合格とするかの根拠は仕様書に集約されるため、仕様の詰めが検収の速さを決めます。

検収期間と不合格時の対応・支払い条件を契約で決めておく必要性

第二条件は、検収期間と不合格時の扱いを数字と手順で決めておくことです。検収期間を「納品から2週間」などと区切り、その期間内に発注者が受入テストを終える、と定めます。期間を決めないと、発注者が確認を先延ばしにして支払いが宙に浮き、受注者の資金繰りを圧迫しかねません。不合格の場合は、受注者が修正して再納品し、再検収する手順と回数の上限を書いておくと、無限の手直しを避けられます。支払い条件は検収完了を起点にするのが基本ですが、開発期間が長い案件では着手金・中間金・検収後の残金と分割し、双方のリスクを分散する設計が無難です。契約類型の選び方そのものは委託契約の選び方を整理した記事が参考になります。発注者は「納品されれば終わり」ではなく、検収体制まで含めて発注準備を整えるのが、結果として早く安く仕上げる近道です。

納品とは何かとシステム開発での納品物・検収に関するよくある質問

システム開発の発注・受注の現場で問われやすい論点を、5つの質問にまとめて答えます。

納品と検収の違いは何ですか？

主体が逆です。納品は受注者が成果物を発注者へ引き渡す行為、検収は発注者が受け取った納品物を仕様どおりか確認して合否を判定する行為を指します。納品しただけでは取引は完了せず、発注者の検収が合格して初めて受け入れ完了となり、報酬の支払い義務が確定するのが一般的な流れです。納品日と検収完了日は別の日付になります。

成果物と納品物はどう違いますか？

範囲が違います。成果物は各工程で生まれる作業の産物すべてを指し、要件定義書や議事録、途中版のたたき台まで含みます。納品物はそのうち契約で発注者へ引き渡すと決めたものだけです。成果物のほうが広く、納品物はその一部にあたります。何を納品物とするかは契約書の納品物一覧で確定させておくと、後の追加要求と有償対応の線引きがしやすくなります。

システム開発の納品物には何が含まれますか？

案件によりますが、稼働するソフトウェア本体（ソースコードや実行モジュール）、データベース定義や構成情報、要件定義書・設計書などの上流ドキュメント、テスト仕様書と結果報告、運用手順書などが代表例です。どこまでを渡すかは契約で定めます。とくにソースコードを含めるか、著作権や利用範囲をどう扱うかは、後の保守体制を左右するため発注前に決めておきます。

納品書とは何のために発行する書類ですか？

納品書は、受注者が納品物を引き渡したことを示す証憑です。何をいつ納めたかを記録し、発注者側の受け取り確認や経理処理の根拠になります。システム開発では、納品書に納品物一覧やバージョンを添えて、検収の対象を明確にする使い方をします。納品書の発行と検収の合格は別の手続きで、納品書を出したことが検収合格を意味するわけではありません。

検収が終わらないと支払いは受けられないのですか？

請負契約では、検収完了を支払いの起点とするのが一般的なため、検収が終わらないと残金の請求が進みにくくなります。これを避けるには、検収期間を契約で区切り、期間内に発注者が受入テストを終える取り決めを契約に入れておくと安全です。開発期間が長い案件では、着手金・中間金・検収後の残金に分けて、検収前にも一定の入金がある設計にするとリスクを抑えられます。

関連記事

• 準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説：契約類型で納品・検収の意味が変わる点を整理できます
• 仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点を解説：検収の合格基準となる仕様書の位置づけがわかります
• 瑕疵担保責任とは？契約不適合責任への改正とシステム開発契約での扱い：検収後に見つかった不具合の責任の扱いを確認できます