システム開発の納品物一覧｜ソースコード以外に受け取る成果物

システム開発の納品物は、ソースコードだけではありません。この記事では、一般的な納品物を種類ごとに整理し、ソースコード以外に受け取っておきたい成果物と、契約前・検収時の確認点を説明します。発注後に「運用できない」「次の担当に引き継げない」と困らないための材料として、お使いいただけます。

システム開発の納品物とは何か

納品物とは、開発の契約にもとづいて、開発会社から発注する側へ引き渡される成果物の総称です。動くソフトウェアそのものに加えて、設計書、テストの結果、操作や運用の手順書、各種アカウントの権限なども含まれます。

ここで押さえたいのは、「動くシステムが手元にある」ことと「自分たちで運用や改修ができる」ことは別だという点です。画面が動いていても、データがどう保存されているか、どの手順で公開しているか、どのサービスのアカウントを使っているかが分からなければ、担当者が替わったときや開発会社を変えるときに行き詰まります。

納品物の範囲は契約書と見積書で決まる

納品物として何を受け取れるかは、開発会社の好意ではなく、契約書・見積書・仕様書などに書かれた内容で決まるのが基本です。書かれていないものは、納品後に求めても対応してもらえないことがあります。

また、契約の種類によっても考え方が変わります。一般に、請負契約は成果物の完成を目的とし、準委任契約は業務の遂行を目的とします。準委任契約では成果物の完成そのものが約束されないことが多いため、どの資料をいつ納めるのかを、あらかじめ書面で決めておくことが大切です。契約形態の違いは、受託開発とは？メリット・デメリットと依頼の流れ・契約の違いで整理しています。

システム開発の納品物一覧

システム開発で納品されることの多い成果物を、種類ごとにまとめます。すべての案件で全部が必要になるわけではありません。開発の規模や段階に応じて、どれを受け取るかを選びます。

種類	主な成果物	何のために受け取るか
要件・仕様	要件定義書、機能一覧、業務フロー図、画面遷移図	何を作る約束だったかを確認する
設計	システム構成図、DB設計書（ER図・テーブル定義書）、API仕様書、画面設計書	中身の構造を理解し、改修や引き継ぎに備える
実装	ソースコード、設定ファイル、利用ライブラリの一覧	システム本体を保有し、改修できるようにする
環境・公開	環境構築手順書、デプロイ（公開作業）手順書、環境変数の一覧	別の人でも同じ環境を再現できるようにする
テスト	テスト計画、テストケース、テスト結果報告書、不具合の一覧	どこまで確認され、何が残っているかを知る
運用	操作マニュアル、運用手順書、障害時の対応手順、バックアップと復旧の手順	納品後の日常運用と緊急時に備える
アカウント・権限	サーバーやクラウド、ドメイン、外部サービスの管理者権限、証明書	開発会社に依存せずシステムを管理できるようにする
権利・ライセンス	著作権の取り扱いの記載、オープンソースのライセンス一覧	事業で使い続けるための権利関係を確認する

この表のうち、ソースコード以外の行が、発注後に見落とされやすい部分です。次の章で、特に確認したいものを順に見ていきます。

ソースコード以外で受け取りたい6つの成果物

1. 設計書（DB・画面・API）

ソースコードだけを渡されても、全体の構造をつかむには多くの時間がかかります。設計書があれば、どこに何があるかを短時間で把握できます。

特に重要なのはDB設計書です。DB（データベース）は、顧客情報や取引履歴といった事業の資産が入る場所で、後から構造を変えるのは大きな作業になります。テーブルの項目と意味が分かる形で残っていれば、別の会社が引き継ぐ際にも、集計や機能追加を検討しやすくなります。新規事業でのデータの持ち方は、新規事業のデータ設計｜最初に決めたい5つの持ち方も参考になります。

API仕様書は、外部のサービスや別のシステムと連携する場合に必要です。APIとは、システム同士がデータをやり取りするための窓口のことです。決済や会員管理などを外部サービスと連携させている場合、どのサービスとどう接続しているかが分かる資料は欠かせません。

2. 環境構築・公開（デプロイ）の手順書

システムは、ソースコードがあるだけでは動きません。動かすための環境（サーバー、データベース、各種設定）を用意し、ソースコードを公開する作業が必要です。この一連の手順が書かれた資料がなければ、開発会社の担当者がいないと更新も復旧もできない状態になります。

あわせて、設定値や外部サービスの接続に使う情報（環境変数）の一覧も確認します。パスワードやAPIキーといった秘密情報は、資料に直接書き込むのではなく、安全な方法で受け渡すことが前提です。何が必要で、どこで管理されているかが分かれば足ります。

3. アカウントと管理者権限

見落とされやすいのが、サーバーやクラウド、ドメイン、アプリ配信のアカウント、外部サービスの契約などの名義と権限です。開発会社のアカウントの中でシステムが動いている場合、契約が終わると使い続けられなくなる恐れがあります。

確認したいのは次の点です。

• サーバーやクラウドの契約名義と管理者権限が、発注した側にあるか
• ドメインや証明書の管理者が誰になっているか
• 決済や通知など外部サービスのアカウントが、発注した側のものになっているか
• 管理者が複数人で共有され、一人の退職で操作できなくなる状態になっていないか

4. テスト結果と既知の不具合の一覧

「テストしました」という報告だけでは、どの範囲が確認されたのかが分かりません。テスト項目と結果、そして納品時点で残っている不具合や制約の一覧を受け取っておくと、納品後の対応を整理しやすくなります。

AIによるテストの自動生成が広がっていますが、何を確認するかの判断は人の役割です。任せる範囲と人が見る項目の考え方は、AIのテスト自動生成｜任せる範囲と人が見る確認項目にまとめています。

5. オープンソースのライセンス一覧と権利関係

現在のシステム開発では、オープンソースのライブラリを多く組み合わせて作るのが一般的です。これらにはそれぞれ利用条件があり、事業での使い方によっては注意が必要な場合があります。利用しているライブラリとライセンスの一覧があれば、事業を広げる場面や、他社との提携・譲渡の場面でも確認しやすくなります。

ソースコードの権利の扱いも、契約で決めておく項目です。一般に、契約に定めがなければ、開発会社が作成したソースコードの著作権は開発会社に残ります。代金を支払えば自動的に移るわけではないため、譲渡するのか、利用許諾にとどめるのかを契約書で確認します。詳しくはソースコードの著作権譲渡｜費用を払っても自動では移らないをご覧ください。

6. 運用・保守の資料

納品後は、日々の運用と、不具合が起きたときの対応が始まります。操作マニュアル、障害時の連絡手順、バックアップとデータ復旧の手順があると、担当者が替わっても運用を続けられます。

保守を開発会社に任せる場合でも、どこまでが保守の対象で、何が追加の開発になるのかの線引きは、契約で確認しておきたい点です。システム開発の保守契約｜納品後の対応範囲の確認点で、確認項目を整理しています。

契約前と検収時に確認したいこと

契約前に見積書・契約書で見る点

納品物は、後から交渉するよりも、契約前に書面にしておくほうが確実です。見積書や契約書では、次の点を確認します。

• 成果物の名称が具体的に書かれているか（「設計書一式」だけでなく、どの設計書かが分かるか）
• 提出の形式（Word、PDF、図のデータ、Gitのリポジトリなど）が決まっているか
• 納品時点の最新の内容に更新されているか
• 提出の時期（開発の途中か、完了時か）
• 納品後に仕様が変わったとき、資料の更新が誰の作業になるか

見積書の読み方は、システム開発の見積もりの違い｜金額より先に見る前提と範囲で詳しく扱っています。

検収では中身が使えるかを確かめる

検収とは、納品されたものが契約した内容を満たしているかを、発注側が確認して受け入れる手続きです。資料が「ある」ことだけでなく、「使える」ことまで確かめるのが要点です。

• 設計書の内容と、実際の画面・DBの構造が一致しているか
• 手順書を見て、開発に関わっていない人でも環境を再現できるか
• 受け取った管理者権限で、実際にログインして操作できるか
• 不具合の一覧に、合意した内容と食い違いがないか

特に手順書は、実際に別の担当者に読んでもらい、その通りに作業できるかを試すと、不足が早く見つかります。検収の進め方はシステム開発の検収とは｜納品時の確認項目と進め方で整理しています。

新規事業では段階に合わせて決める

新規事業では、事業の方向が途中で変わることも珍しくありません。最初からすべての資料を厚く求めると、仕様が変わるたびに更新の手間が増え、開発の進みも遅くなります。

たとえば、検証の段階では、画面の構成、主要な機能、データの持ち方が分かる資料を中心に受け取り、事業の見通しが立った段階で、運用や保守の資料を整える進め方もあります。大切なのは、「今回はどこまでを受け取り、どこからを次の段階にするか」を、開発会社と合意しておくことです。プロトタイプから本開発に進むときの引き継ぎの考え方は、MVPから本開発は作り直し？引き継げる部分と見直す点も参考になります。

AI駆動開発での納品物の考え方

AIを使った開発では、設計書やテスト項目をAIが自動で作る場面が増えています。資料づくりの負担が下がる一方で、発注側が確かめたい点も少し変わります。

資料があるかより、最新かどうか

AIが生成した資料は、書かれた時点では整っていても、その後の改修で実装とずれる可能性があります。資料の数よりも、納品時点のシステムと内容が一致しているかを確認することが大切です。AIでの設計書づくりの注意点は、AI設計書の自動生成は可能？後から困らない残し方で説明しています。

保守・権利・情報の扱いも確認する

AIが書いたコードでも、納品後に人が保守できる状態であることが前提です。引き継ぎや改修で確認したい点は、AI生成コードの保守は可能か｜引き継ぎと改修の確認点にまとめています。また、AI生成コードの権利の扱いはAI生成コードの著作権｜事業で使う前の確認点で、開発中に事業のアイデアや機密がAIにどう扱われるかは生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアで触れています。

どのAIツールを開発に使ったのか、どんな条件で利用しているのかを、必要に応じて開発会社に確認できる状態にしておくと、後の判断がしやすくなります。

まとめ

システム開発の納品物は、ソースコードに加えて、設計書、環境構築と公開の手順書、アカウントと管理者権限、テスト結果、ライセンスと権利の情報、運用資料などで構成されます。ここまで見てきた要点を整理します。

• 納品物の範囲は契約書と見積書で決まるため、成果物の名称・形式・時期を契約前に書面で確認する
• 設計書（特にDB設計書）、手順書、アカウント権限は、引き継ぎや開発会社の変更に備えるうえで要になる
• 検収では、資料が「ある」ことではなく、別の人が使って環境を再現できるかまで確かめる
• 新規事業では、事業の段階に合わせて受け取る範囲を決め、次の段階で整える
• AI駆動開発では、資料の量よりも、実装との一致と保守のしやすさを確認する

納品物の確認は、開発が終わる直前ではなく、進め方を決める最初の段階から始めておくと、後からの手戻りを減らせます。開発全体の進め方については、システム開発の外注｜メリット・デメリットと失敗しない進め方もあわせてご覧ください。

JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる進め方をとっています。納品後も、業務に合わせて育て続ける伴走型の技術支援を行っています。受け取りたい成果物の範囲を含め、開発の進め方に迷うときは、JustFitのサービス紹介もご覧ください。