--- title: "納品とは？システム開発の成果物・検収との違いと契約別の扱いを解説" url: "https://www.issoh.co.jp/column/details/13460/" published: 2026-07-11 updated: 2026-09-08 categories: ["Webシステム"] publisher: "株式会社一創" --- # 納品とは？システム開発の成果物・検収との違いと契約別の扱いを解説 「納品」という言葉は、物販なら商品を届けることを指します。ところがシステム開発では、中身も手続きも別物です。渡すものはプログラムだけでなく設計書や運用手順まで含み、渡した後には発注者が合否を判定する検収という工程が待っています。ここを曖昧にしたまま契約を結ぶとどうなるか。完成したはずのシステムが受け入れられず、支払いも止まります。この記事では、納品の意味を成果物・納品物・検収と切り分けたうえで、請負と準委任で扱いがどう変わるか、2026年1月に施行された取引ルールで支払期日の考え方がどう変わったかまで、発注者の目線で整理します。 ## まとめ：納品の意味と成果物・検収との違いをシステム開発で整理 納品は受注者が成果物を引き渡す行為、検収は発注者がその中身を仕様どおりか確かめる行為で、動かす主体が逆です。システム開発では、納品しただけでは取引は終わらず、発注者の検収が完了して初めて報酬の支払いや契約不適合責任の起算へ進みます。何を納品物とするか、どんな状態を合格とするかは契約と仕様書で決まるため、ここが曖昧なまま進めると検収でもめます。 実務でつまずきやすいのは、成果物と納品物の混同と、検収基準の未定義の2点です。成果物は各工程で生まれる中間物まで含み、納品物はそのうち契約で渡すものに絞られます。合格ラインを受入テストの形で契約前に決めておけば、納品後の押し問答は起きません。加えて2026年1月1日からは、下請法を改正した[中小受託取引適正化法（公正取引委員会）](https://www.jftc.go.jp/partnership%5Fpackage/toritekihou.html)が施行され、対象取引では検査の有無を問わず受領日起算で支払期日を定める必要が生じました。検収が長引けば支払いも後ろへずれる、という従来の感覚だけでは足りません。自社のシステム開発で納品範囲と検収条件を詰めたい場合は、[一創の基幹システム開発](https://www.issoh.co.jp/service/business%5Fsystem/core%5Fbusiness/)で要件定義から納品・検収までの進め方を相談できます。 ## 納品とは何かと成果物・納品物・検収との違いを言葉の意味で整理 まず用語を切り分けます。納品・成果物・納品物・検収は現場で混ざって使われがちですが、主体とタイミングが違うため、契約書での定義がずれると後工程で衝突します。 ### 納品の意味は受注者が契約で定めた成果物を引き渡す行為を指すこと 納品とは、受注者が契約で約束したものを発注者へ引き渡す履行行為です。物販なら商品の受け渡し、システム開発なら完成したソフトウェアと関連資料の提供を指します。ここで押さえたいのは、納品があくまで受注者側のアクションだという点です。納品した時点では「渡した」だけで、発注者がそれを受け入れたかどうかは別の話になります。契約書では「納品」を、成果物を所定の方法・場所・期日で引き渡すことと定義し、納期と引き渡し方法をセットで書いておきます。 ### 成果物と納品物の違いは発注者へ引き渡す範囲に絞られるかどうか 成果物は、プロジェクトの各工程で生み出される作業の産物すべてを指します。要件定義書、設計書、ソースコード、テスト仕様書、議事録まで幅広く含みます。一方、納品物は成果物のうち契約で発注者へ引き渡すと決めたものだけです。つまり成果物のほうが広く、納品物はその部分集合になります。社内向けの検討メモや途中版のたたき台は成果物ではあっても納品物には含めない、という切り分けが典型です。契約書に「納品物一覧」を明記し、成果物のどれを渡すのかを確定させておくと、後から「あの資料も出して」という追加要求と有償対応の線引きがしやすくなります。英語のdeliverableやoutputとの対応関係は[成果物・納品物・outputの違いを整理した記事](https://www.issoh.co.jp/column/details/10021/)で確認できます。 ### 納品と検収の違いは引き渡す側と受け入れて確認する側で主体が逆 納品と検収は、続けて起こるが主体が正反対の工程です。納品は受注者が渡す行為、検収は発注者が受け取った納品物を仕様どおりか確認し、合否を判定する行為を指します。検収で発注者が合格と判断して初めて、取引上は「受け入れ完了」となり、報酬の支払い義務が確定するのが一般的な流れです。検収には期間が設けられ、その間に発注者が受入テストを行って不具合を洗い出します。納品日と検収完了日は別の日付になる点、そして支払いの起点は多くの場合で検収完了である点は、資金繰りの面でも押さえておきたいところです。検収日の数え方や受入検査との使い分けは[検収とは何かを解説した記事](https://www.issoh.co.jp/column/details/17274/)に詳しくまとめました。 ### 納品完了と受入完了を契約書で書き分けるときの条項の組み立て方 もめる案件の契約書を読むと、納品と受入が同じ条文に溶けている例が目立ちます。分けて書くなら、納品条項には「引き渡す物・引き渡す方法・期日」を、受入条項には「検査の期間・合否の判定方法・不合格時の手順」を書きます。ひな型として手元に置きたいのは、[IPAの情報システム・モデル取引・契約書（第二版）](https://www.ipa.go.jp/digital/model/model20201222.html)です。第二版は2020年12月22日に公表され、受託開発と保守運用、パッケージやSaaS利用を対象にした契約書が収録されています。自社の契約書とモデル契約を条文単位で突き合わせると、検査期間や合格みなしの規定が抜けている箇所が見つかります。条文を一から書き起こすより、公開されているひな型との差分を埋めるほうが早く仕上がるはずです。 ## システム開発の納品物の種類と工程ごとに作成するドキュメント一覧 システム開発では「何を納品するか」が案件ごとに変わります。プログラムだけを想像しがちですが、実際にはソースコード・実行環境・各種ドキュメントが束になって納品物を構成します。 ### ソースコードと実行環境を含む成果物としての納品物の代表的な中身 納品物の中心は、稼働するシステム本体です。具体的には、ソースコード一式、ビルド済みの実行モジュール、データベースの定義や初期データ、サーバーの構成情報などが含まれます。最近はコンテナ設定や環境構築の手順を含めて渡し、発注者側で再現できる状態にする形が増えました。ソースコードを納品物に含めるか、著作権や利用範囲をどう扱うかは契約で定めます。ここを決めずに進めると、保守を別会社に頼みたくなったときにソースが手元になく動けない、という事態を招きかねません。納品形態（記録メディアかリポジトリ経由か）も併せて契約に書いておきます。 ### 要件定義書から運用手順書まで工程別に作成する主なドキュメント システム開発のドキュメントは、工程に沿って積み上がる構造です。上流から順に、要件定義書、基本設計書、詳細設計書、テスト仕様書とテスト結果報告書、そして運用・保守のための操作手順書や運用手順書が並びます。これらのどこまでを納品物とするかは案件の性質で変わり、内製の保守を前提にするなら設計書まで一式で渡す、運用委託まで任せるなら運用手順を厚くする、といった調整をします。ドキュメントの粒度や様式は、発注者が受け入れ後に自走できるかを基準に決めるのが実務的です。仕様書と設計書・要件定義書の役割分担は[仕様書の位置づけを解説した記事](https://www.issoh.co.jp/column/details/13200/)で確認できます。 | 区分 | 納品物の例 | 主な用途 | | -------- | -------------- | -------- | | プログラム | ソースコード・実行モジュール | システムの稼働 | | 環境・データ | DB定義・構成情報 | 再現と移行 | | 上流ドキュメント | 要件定義書・設計書 | 仕様の根拠と保守 | | 品質記録 | テスト仕様書・結果報告 | 検収の判定材料 | | 運用ドキュメント | 操作手順書・運用手順書 | 受入後の自走 | ### 納品物一覧と受入テスト項目を発注前に埋めるための記入テンプレート 納品物一覧は、文章で書くより表の形で埋めたほうが漏れに気づきます。下は契約の別紙にそのまま貼れる粒度で組んだひな型です。納品物ごとに「形式」「合格の判定方法」「判定する人」を埋めていき、空欄が残った行がそのまま検収でもめる候補になります。受入テスト項目は業務シナリオ単位で並べ、入力と期待結果を1行ずつ書き切ります。 ``` ▼別紙A 納品物一覧（記入テンプレート） No,納品物,形式,合格の判定方法,判定者,納品期日 1,ソースコード一式,Gitリポジトリ,ビルドが通ること,開発責任者, 2,実行モジュール,ZIP,検証環境で起動すること,情シス担当, 3,要件定義書,PDF,承認済み版と一致すること,業務部門長, 4,テスト結果報告書,PDF,重大欠陥が0件であること,品質責任者, 5,運用手順書,PDF,手順どおり運用できること,運用担当, ▼別紙B 受入テスト項目（記入テンプレート） No,業務シナリオ,入力,期待結果,判定,実施日 1,受注登録,商品A×10件,受注番号が発番される,, 2,在庫引当,在庫5件で受注10件,不足分が警告表示される,, 3,締め処理,月末日付で実行,当月売上が確定する,, 4,権限制御,一般権限で単価変更,操作が拒否される,, 5,連携,会計側へ日次送信,送信件数が一致する,, ``` この2枚を発注前に埋めておくと、見積の前提もそろいます。逆に、「合格の判定方法」列が全行空欄のまま契約を結んだ案件は、検収で発注者と受注者の言い分が食い違いがちです。見積書と納品物一覧の対応が取れているかを確かめる観点は、[システム開発の見積もりを発注者視点で解説した記事](https://www.issoh.co.jp/column/details/13443/)にまとめています。 ## 請負契約と準委任契約で変わる納品・検収と報酬支払いのタイミング 同じ「開発を任せる」でも、契約類型が請負か準委任かで、そもそも納品・検収という概念の重みが変わります。報酬がいつ確定するかも異なるため、発注前に押さえておく箇所です。 ### 請負契約は成果物の完成と検収完了で報酬支払いが確定する仕組み 請負契約は、仕事を完成させて成果物を引き渡す義務を負う契約です。[民法（e-Gov法令検索）](https://laws.e-gov.go.jp/law/129AC0000000089)では632条が請負を定め、633条が報酬を目的物の引渡しと同時に支払うものと定めています。したがって納品と検収がそのまま契約の核になります。受注者は約束した成果物を完成させて納品し、発注者が検収して合格を出すと報酬請求権が確定する、という流れです。完成しなければ原則として報酬は発生しないため、受注者は「完成」の定義、つまり何をもって検収合格とするかを契約前に握っておく必要があります。検収後に見つかった不具合は、559条を介して準用される562条以降の契約不適合責任の問題として扱われるのが原則です。検収を起点とした責任の考え方は[瑕疵担保責任と契約不適合責任を解説した記事](https://www.issoh.co.jp/column/details/13211/)で確認できます。 ### 準委任契約は業務の遂行が対象で成果物の検収より作業報告が中心 準委任契約は、成果物の完成ではなく業務の遂行そのものを対象にする契約です。善良な管理者の注意を尽くして作業する義務を負い、成果物が仕様に合わないこと自体を根拠に検収不合格として報酬を拒む建て付けにはなりません。報酬は稼働工数や期間に応じて支払われる形が中心で、月次の作業報告が納品物に近い位置づけになります。ただし、民法648条の2が定める成果完成型のように、一定の成果の達成を条件に報酬を払う設計もあります。どちらの契約類型を選ぶかで納品・検収の意味合いが変わるため、[準委任契約と請負・派遣の違いを整理した記事](https://www.issoh.co.jp/column/details/13187/)で全体像をつかんでおくと発注判断を誤りません。 ### アジャイル開発の準委任でスプリントの成果を確認していく進め方 反復して開発を進める案件では、最終納品を一度だけ迎える組み立てが合いません。IPAは[アジャイル開発版のモデル契約](https://www.ipa.go.jp/digital/model/agile20200331.html)を2020年3月31日に公表しており、そこでは「あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく」、業務の遂行自体に対価を払う準委任契約を前提に置くと明記されています。この立て付けだと、契約上の「納品」に相当するのは、期間の終わりに現時点の動くソフトウェアと関連資料を引き渡す行為です。合否の確認はスプリントごとのレビューで積み上げる運びになるため、末端に長い検収期間を置く必要は薄くなります。反復型を選ぶなら、成果を確認する会議体・確認する範囲・引き渡す資料の粒度を、契約の別紙で先に決めておきます。 ## 2026年1月の取適法施行で支払期日が受領日起算に変わる納品実務 納品と検収を語るうえで、2026年に変わった取引ルールを外せません。下請法の改正法が2026年1月1日に施行され、法律名が中小受託取引適正化法（通称は取適法）へ変わりました。改正の内容は[中小企業庁の改正ポイント説明会](https://www.chusho.meti.go.jp/keiei/torihiki/kaiseihou%5Fsetsumeikai.html)のページに資料がまとまっています。 ### 検査の有無を問わず受領日から60日以内に支払期日を定める義務 公正取引委員会が公開しているリーフレットには、支払期日を定める義務として「検査をするかどうかを問わず、発注した物品等を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定めること」と書かれています。支払遅延や減額があった場合の遅延利息は年率14.6%で、取引に関する記録は2年間の保存が求められます。ここで効いてくるのが「検査をするかどうかを問わず」という一文です。対象となる取引では、検収に時間がかかっているという理由で支払期日を60日より後ろへ置くことはできません。 ### 検収が長引く案件で発注者と受注者が先に握っておく取り決めの中身 この規定を踏まえると、発注者側で先に決めておくのは検収体制の確保です。受領から60日という枠の中で受入テストを終える段取りが組めないなら、納品を機能単位に分割して段階的に受領する、あるいは検収の実施支援を受注者の作業範囲に含める、といった設計へ切り替えます。受注者側で残すのは、注文書や発注書への受領日と支払期日の記載です。発注書と注文書の使い分けや保管の扱いは、[発注書と注文書の違いを解説した記事](https://www.issoh.co.jp/column/details/15446/)で確認できます。なお適用の対象は事業者の資本金や取引の内容で決まるため、自社の取引が該当するかは公正取引委員会の資料で個別に当たってください。 ## 発注者が納品と検収でつまずかないために契約前に固めておく条件 ここは判断の章です。玉虫色を避け、発注者が納品・検収でもめないために何を契約前に決めるべきかを条件付きで言い切ります。納品トラブルの多くは、合格基準の曖昧さと検収体制の不足から生まれます。 ### 検収の合格基準を受入テストの形で契約の前に文書化しておく条件 検収でもめないための第一条件は、合格基準を受入テストの形で契約前に決めておくことです。「仕様どおり」という言葉だけでは、発注者と受注者で想定がずれます。主要な業務シナリオを何本か選び、入力と期待結果を一覧にした受入テスト項目を契約書か仕様書に添付しておくと、検収は「その項目が通るか」の客観判定に変わります。逆に、受入テストを用意せずに納品を迎えると、発注者の主観で合否が動き、検収がいつまでも終わりません。発注者側にテスト実施の人員を割けない事情があるなら、受入テストの設計と支援まで受注者へ委ねる範囲を契約に含めておくのが現実的です。何を合格とするかの根拠は仕様書に集約されるため、仕様の詰めが検収の速さを決めます。 ### 検収期間と不合格時の対応・支払い条件を契約で決めておく必要性 第二条件は、検収期間と不合格時の扱いを数字と手順で決めておくことです。検収期間を「納品から2週間」などと区切り、その期間内に発注者が受入テストを終える、と定めます。期間を決めないと、発注者が確認を先延ばしにして支払いが宙に浮き、受注者の資金繰りを圧迫しかねません。不合格の場合は、受注者が修正して再納品し、再検収する手順と回数の上限を書いておくと、無限の手直しを避けられます。支払い条件は検収完了を起点にするのが基本ですが、取適法の対象取引では受領日起算60日の枠が上に乗ります。開発期間が長い案件では着手金・中間金・検収後の残金と分割し、双方のリスクを分散する設計が無難です。契約類型の選び方そのものは[委託契約の選び方を整理した記事](https://www.issoh.co.jp/column/details/13189/)が参考になります。 ### 納品後の保守体制まで含めて発注の範囲を決めるときの判断軸と手順 第三条件は、検収合格の先にある運用を誰が担うかを、発注の段階で決めておくことです。検収が終わればシステムは業務で回り始め、障害対応や法改正への追随が発生します。ここを決めずに納品を迎えると、設計書は手元にあるのに直せる人がいない状態で止まります。判断の目安は、社内に該当技術の担当者が1名でも常時いるかどうかです。いるなら設計書と運用手順を厚めに受け取って内製へ寄せ、いないなら保守運用を含めた契約にして窓口を一本化します。切り替えの余地を残したいなら、納品物にソースコードと構成情報を必ず含め、保守の契約は年単位で見直せる形にしておくのが安全です。保守を外部へ委ねる場合の会社選びは、[システム運用保守の会社選びを解説した記事](https://www.issoh.co.jp/column/details/16402/)で条件をそろえられます。発注者は「納品されれば終わり」ではなく、検収体制と運用体制まで含めて発注準備を整えるのが、結果として早く安く仕上げる近道です。 ## 納品とは何かとシステム開発での納品物・検収に関するよくある質問 システム開発の発注・受注の現場で問われやすい論点を、5つの質問にまとめて答えます。 ### 納品と検収の違いは何ですか？ 主体が逆です。納品は受注者が成果物を発注者へ引き渡す行為、検収は発注者が受け取った納品物を仕様どおりか確認して合否を判定する行為を指します。納品しただけでは取引は完了せず、発注者の検収が合格して初めて受け入れ完了となり、報酬の支払い義務が確定するのが一般的な流れです。納品日と検収完了日は別の日付になります。 ### 成果物と納品物はどう違いますか？ 範囲が違います。成果物は各工程で生まれる作業の産物すべてを指し、要件定義書や議事録、途中版のたたき台まで含みます。納品物はそのうち契約で発注者へ引き渡すと決めたものだけです。成果物のほうが広く、納品物はその一部にあたります。何を納品物とするかは契約書の納品物一覧で確定させておくと、後の追加要求と有償対応の線引きがしやすくなります。 ### システム開発の納品物には何が含まれますか？ 案件によりますが、稼働するソフトウェア本体（ソースコードや実行モジュール）、データベース定義や構成情報、要件定義書・設計書などの上流ドキュメント、テスト仕様書と結果報告、運用手順書などが代表例です。どこまでを渡すかは契約で定めます。とくにソースコードを含めるか、著作権や利用範囲をどう扱うかは、後の保守体制を左右するため発注前に決めておきます。 ### 納品書とは何のために発行する書類ですか？ 納品書は、受注者が納品物を引き渡したことを示す証憑です。何をいつ納めたかを記録し、発注者側の受け取り確認や経理処理の根拠になります。システム開発では、納品書に納品物一覧やバージョンを添えて、検収の対象を明確にする使い方をします。納品書の発行と検収の合格は別の手続きで、納品書を出したことが検収合格を意味するわけではありません。取適法の対象取引では、取引の記録を2年間保存する義務があるため、納品書と受領の記録は捨てずに残します。 ### 検収が終わらないと支払いは受けられないのですか？ 請負契約では、検収完了を支払いの起点とするのが一般的なため、検収が終わらないと残金の請求が進みにくくなります。ただし取適法の対象取引では、検査の有無を問わず受領日から起算して60日以内に支払期日を定める義務があり、検収の長期化を理由に支払期日を後ろへずらすことはできません。開発期間が長い案件では、着手金・中間金・検収後の残金に分けて、検収前にも一定の入金がある設計にするとリスクを抑えられます。 ## 関連記事 - [検収とは？検収日の意味・受入検査との違いと取適法60日ルールを解説](https://www.issoh.co.jp/column/details/17274/)：受領日起算60日の数え方と受入検査の位置づけを確認できます - [deliverable（デリバラブル）とは？意味・読み方と成果物・納品物・outputの違い](https://www.issoh.co.jp/column/details/10021/)：英語表記での成果物と納品物の対応関係を整理できます - [準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説](https://www.issoh.co.jp/column/details/13187/)：契約類型で納品・検収の意味が変わる点を整理できます - [発注書と注文書の違いとは？同じ書類か・使い分け・印紙・保管まで解説](https://www.issoh.co.jp/column/details/15446/)：取引で交わす発注書と注文書の違いや保管の扱いを確認できます - [仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点を解説](https://www.issoh.co.jp/column/details/13200/)：検収の合格基準となる仕様書の位置づけがわかります - [瑕疵担保責任とは？契約不適合責任への改正とシステム開発契約での扱い](https://www.issoh.co.jp/column/details/13211/)：検収後に見つかった不具合の責任の扱いを確認できます --- 出典: [納品とは？システム開発の成果物・検収との違いと契約別の扱いを解説]()（株式会社一創）