納品物とは？システム開発で受け取るものと確認の実務
納品物とは、契約に基づいて受注者(開発会社など)から発注者へ引き渡される成果物のことです。システム開発では、プログラムだけでなく、設計書、テスト結果、運用手順書などの文書類も納品物に含まれます。
トラブルの多くは、「何が納品されるのか」を契約時に具体化していないことから起こります。
本記事では、システム開発の納品物の種類、納品物一覧の作り方、受け取るときの確認手順、権利面の注意点を発注者向けに解説します。
なお、契約の型(請負・準委任)によって納品物の位置づけが変わる点は、準委任契約の成果物と報酬の実務で詳しく整理しています。
システム開発の納品物の種類
代表的な納品物を、役割ごとに整理します。案件によって必要なものは変わるため、この表は「全部を要求すべきリスト」ではなく、検討の抜けを防ぐためのチェック表として使ってください。
| 分類 | 納品物の例 | 何のために受け取るか |
|---|---|---|
| 動くもの | プログラム(ソースコード)、実行環境の設定、リリース済みのアプリ・システム | 業務で使うため。将来の改修の土台 |
| 設計・仕様の記録 | 要件定義書、設計書、画面・帳票の一覧 | 何を作ったかの合意の記録。引き継ぎの土台 |
| 品質の記録 | テスト計画・結果、既知の不具合一覧 | 何を確認済みかを知る。受け入れ判断の材料 |
| 運用のための資料 | 操作手順書、運用・障害時の手順、環境構成図 | 自社または別会社で運用を続けるため |
| 管理情報 | アカウント・権限の一覧、利用している外部サービスの一覧 | 契約・名義・費用の管理を引き継ぐため |
表の中で見落とされやすいのは管理情報です。ドメイン・サーバー・外部サービスの契約が開発会社名義のままだと、契約終了時に業務が止まる原因になります。名義と支払いの一覧は、納品物として必ず受け取ってください。
どこまで文書を求めるかは、費用とのバランスで決めます。文書化にも工数がかかるため、「読む人がいない資料」を要求するより、引き継ぎと運用に本当に必要なものへ絞る方が合理的です。何を作るかの決め方は要件定義の進め方と書き方も参考にしてください。
納品物一覧を契約の別紙にする
納品物をめぐる揉め事を防ぐ最も効果的な方法は、納品物の一覧を契約書の別紙として特定することです。一覧には、名称、形式(ファイル形式・媒体)、提出時期、提出方法(どこに格納するか)を書きます。
このとき、次の3点を意識してください。第一に、「ソースコード一式」のような曖昧な書き方を避け、対象の範囲(自社向けに開発した部分か、開発会社の既存部品を含むか)を明確にします。第二に、途中版の扱い(打ち合わせ資料や検討メモを含むか)を決めます。第三に、納品後の修正(不具合対応)で更新された場合に、最新版を再納品する条件を決めます。
また、開発が長期にわたる場合は、最後に一括で受け取るのではなく、工程の区切りごとの中間納品(設計書の時点でのレビューなど)を計画に入れると、認識のずれを早期に発見できます。中間納品の対象と時期も、同じ別紙で決めておきます。
一覧の作成は発注側から叩き台を出して構いません。開発会社側の標準の納品物一覧がある場合は、それを起点に自社の運用に必要なものを追加・削除する形でも構いません。むしろ、発注側が「引き継ぎと運用に何が必要か」を考えて叩き台を作る過程自体が、抜けの発見につながります。
受け取るときの確認手順
納品物は「受け取った」だけでは確認したことになりません。次の手順で確認します。
第1に、一覧との突合です。契約別紙の一覧と、実際に受領したものを1対1で照合します。第2に、開けるか・読めるかの確認です。ファイルが破損なく開けるか、手順書が自社の担当者に理解できる内容かを確認します。第3に、動くものの確認です。プログラムは、動作する環境とセットで初めて意味を持ちます。「データやコードはあるが、動かし方が分からない」を防ぐため、環境構成と起動・リリースの手順が納品物に含まれているかを確認してください。確認には期限を設けます。誰が・いつまでに・何を確認するかを、納品予定日が決まった時点で社内に割り当ててください。受け取ったまま確認せずに放置すると、不足や不具合の指摘が遅れ、修正の交渉が難しくなります。第4に、確認結果の記録です。確認した日付・担当・指摘事項を残し、指摘の修正期限を合意します。
第5に、受領後の保管です。納品物の保管場所(社内のどこに置くか)、アクセスできる人、バックアップを決めます。受け取ったのに誰も場所を知らない、というのは引き継ぎ時によくある事故です。
なお、この確認と、契約上の「検収」の関係は契約の型によって変わります。請負では検収が報酬支払いの前提として明確に位置づけられる一方、準委任では確認行為の意味を契約書で定義しておく必要があります。詳細は準委任契約の成果物と報酬の実務を参照してください。
権利と再利用の注意点
納品物を受け取ることと、それを自由に使えることは、自動的には一致しません。ソースコードや設計書の著作権などの権利の帰属、自社での改変や別会社への開示(改修を他社へ依頼する場合)の可否は、契約書の定めによります。
契約前に、「契約終了後、別の会社に改修を依頼できるか」「開発会社の既存部品・外部ライセンスが含まれる場合、その利用条件はどうなるか」を確認してください。ここが曖昧なまま納品を受けると、実質的にその開発会社しか触れないシステムになります。個別の契約の法的判断は、弁護士等の専門家への確認が必要です。
また、納品後に不具合が見つかった場合の対応(修正の範囲と期間)がどう定められているかも、納品前に確認しておくべき点です。期間や条件は契約によって異なるため、検収完了の日付とあわせて記録を残してください。
納品後の保守を誰が担うかも、納品物の要求内容に影響します。保守を開発会社に任せ続けるか、自社や別会社へ移す可能性があるかで、必要な文書の水準が変わるためです。保守の費用と範囲の考え方は保守費用の考え方で解説しています。
納品物に関するFAQ
ソースコードは必ず納品してもらえますか？
自動的には決まらず、契約によります。納品物にソースコードが含まれるか、権利の帰属と利用範囲がどう定められているかを、契約前に確認してください。開発会社の既存部品や外部のライセンス部品が含まれる場合、その部分の扱いは別になることがあります。
納品物の形式に決まりはありますか？
法令で一律に決まっているものではなく、契約で定めます。実務では、自社で開ける形式か、将来の担当者が読めるか、更新が続く文書は編集可能な形式かを基準に指定してください。
納品後に不足が見つかったらどうすればよいですか？
契約別紙の一覧に載っているものであれば、一覧を根拠に提出を求めます。一覧にないものは追加の依頼(場合によって追加費用)になるため、だからこそ契約時の一覧化が重要です。受け取り時の確認記録があると、話がこじれにくくなります。
納品物の設計から発注の準備を支援します
ノーコード総研では、ノーコードやAIを活用した業務システムの受託開発をご相談いただけます。開発のご相談の際は、納品物と引き継ぎ資料の範囲も、運用の計画に合わせて最初から一緒に設計します。
費用の全体像はシステム開発費用の内訳も参考に、まずは開発後に誰がどう運用するかを書き出して、ノーコード総研に相談することから始めてみてください。