「来週、納品物の検収をお願いします。こちらが成果物一覧です」——開発ベンダーからそう言われたとき、内容を見て即答できる発注者は意外と多くありません。要件定義書、基本設計書、詳細設計書、テスト仕様書……。一見もっともらしい一覧表に対し、「これで全部揃っているのか」「自分の会社の案件で、本来あるべきドキュメントが抜けていないか」を判断するのは簡単ではないからです。
特に、IT 部門ではない事業部門の担当者が発注を任されているケースでは、「専門用語の連続でチェックしようがない」「とりあえず OK したら、後から運用保守でドキュメントが無くて困った」というトラブルがしばしば発生します。実際、システム開発のトラブルの多くは「最初にどの成果物を納品物として合意するか」を曖昧にしたまま走り出すことに起因します。
そこで本記事では、システム開発で一般的に作成される 成果物・ドキュメントの種類を工程別に網羅的に解説 します。各工程で「どんな名前のドキュメントが」「何のために」「どんな内容で」作られるのかを、発注者目線で平易に整理しました。
さらに、検収・納品時に発注者が確認すべき項目を チェックリスト形式 にまとめました。この記事を読み終えるころには、ベンダーから提示された成果物一覧を見て「この項目が足りない、追加してほしい」と具体的に交渉できるようになっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム開発の成果物とは何か（定義と目的）
「成果物（deliverable）」とは、システム開発の各工程で作成される ドキュメント・プログラム・各種ファイル の総称です。最終的にシステムとして動くソースコードはもちろん、その前段階で作られる要件定義書・設計書・テスト結果報告書、プロジェクト管理に使った課題管理表なども含まれます。
「成果物」と「納品物」の違い
混同しやすい言葉に「納品物」があります。両者は似ていますが、契約上の意味が異なります。
用語 | 意味 |
|---|---|
成果物 | プロジェクトの過程で作られる すべてのアウトプット（社内資料・中間ドラフト含む） |
納品物 | 成果物のうち、契約に基づいて発注者に正式に引き渡されるもの |
つまり、ベンダー社内で作成された設計書のドラフトや議事録は「成果物」ではあっても、契約書に明記されていなければ「納品物」にはならない、というケースがあります。「成果物 ≒ 納品物」と思い込まないこと が、検収トラブル回避の第一歩です。
なぜ成果物の種類を知る必要があるのか
発注者が成果物の種類と役割を理解しておくべき理由は3つあります。
- 検収基準を事前に合意できる: 「どの成果物が納品されれば検収 OK とするか」を契約段階で握れる
- 運用・保守フェーズで自走できる: 設計書やテスト仕様書が手元にあれば、別ベンダーへの引き継ぎや機能追加にも対応しやすい
- トラブル時の証拠になる: 後から「言った／言わない」になったとき、要件定義書や議事録が判断材料になる
逆に、これらを知らないまま「ソースコードだけ納品されたが、設計書もテスト結果も無い」状態で検収すると、後の改修コストが跳ね上がります。
工程別の主要成果物一覧（要件定義〜運用保守）
ウォーターフォール型のシステム開発では、一般的に以下の工程で成果物が積み上がっていきます。まずは全体像をつかんでください。
工程 | 代表的な成果物 |
|---|---|
企画・要求定義 | RFP（提案依頼書）、見積書、提案書、契約書 |
要件定義 | 要件定義書、業務フロー図、機能一覧 |
基本設計（外部設計） | 基本設計書、画面設計書、画面遷移図、ER 図、API 一覧 |
詳細設計（内部設計） | 詳細設計書、モジュール設計書、データベース定義書 |
開発（実装） | ソースコード、実行モジュール、コーディング規約 |
テスト | テスト仕様書、テスト結果報告書、バグ管理表 |
リリース・運用保守 | 操作マニュアル、運用手順書、保守要件定義書 |
なお、IPA（情報処理推進機構）が公開する「共通フレーム（SLCP-JCF）」では、ソフトウェアの構想から廃棄までの各工程の作業内容と用語が標準化されており、ベンダーとの認識合わせの参考になります。アジャイル開発の場合は工程の区切りが緩くなりますが、本質的に作るべきドキュメントの種類は大きく変わりません。
開発工程そのものをもう少し詳しく知りたい方は、システム開発工程の流れもあわせてご覧ください。
要件定義フェーズの成果物（要件定義書・業務フロー図等）
要件定義は「何を作るか」を決める工程です。ここでの成果物が曖昧だと、後工程すべてに影響します。
要件定義書
- 主な内容: システム化の目的、業務要件、機能要件（実装する機能の一覧）、非機能要件（性能・セキュリティ・可用性）、制約条件
- なぜ必要か: 発注者とベンダーの「作るもの」の合意書になるため。検収時に「これは要件外です」と言われないための 最後の砦 です
要件定義書のフォーマットや記載粒度については、要件定義書テンプレートで詳しく解説しています。
業務フロー図
- 主な内容: 現行業務（As-Is）と新業務（To-Be）の流れを図解したもの
- なぜ必要か: テキストだけでは伝わりにくい「人とシステムの役割分担」を可視化し、要件の抜け漏れを発見できるため
機能一覧
- 主な内容: 実装する機能を表形式で一覧化したもの（機能 ID・機能名・概要・優先度など）
- なぜ必要か: 開発スコープの「全体像」を一目で確認でき、見積もり精度の根拠にもなる
設計フェーズの成果物（基本設計書・詳細設計書・画面設計書等）
要件定義で決まった「何を作るか」を、技術的に「どう作るか」へ落とし込む工程です。基本設計と詳細設計の違い をここで押さえましょう。
基本設計書（外部設計書）
- 主な内容: ユーザーから見える部分の設計（画面レイアウト、画面遷移、入出力項目、帳票仕様、外部システム連携）
- なぜ必要か: 発注者がレビューできる 最後の設計書 だから。ここで合意した内容がそのまま画面・機能に反映される
詳細設計書（内部設計書）
- 主な内容: プログラム内部の設計（クラス構造、関数・モジュールの処理ロジック、データベースの物理設計、エラーハンドリング）
- なぜ必要か: 開発者が実装するための「施工図」にあたる。後の保守・改修時にも参照される技術ドキュメント
基本設計書は「家の間取り図」、詳細設計書は「電気配線や水道管の施工図」とイメージすると分かりやすいでしょう。両者の役割と違いについては、基本設計書・詳細設計書の書き方で詳しく整理しています。
画面設計書・画面遷移図
- 主な内容: 各画面のワイヤーフレーム、入力項目の仕様、画面間の遷移ルート
- なぜ必要か: 発注者がイメージしやすく、要件齟齬を発見しやすい成果物。UI レビューの主役になる
ER 図・データベース定義書
- 主な内容: テーブル一覧、各テーブルのカラム定義、テーブル間のリレーション
- なぜ必要か: データ構造はシステムの土台。後から別システム連携やデータ抽出を行う際に必須となる
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
開発フェーズの成果物（ソースコード・テスト仕様書等）
実装工程で生み出される成果物です。「コードだけあれば良い」と思いがちですが、それは誤解です。
ソースコード
- 主な内容: プログラミング言語で記述されたシステム本体のコード一式
- なぜ必要か: システムの実体そのもの。Git リポジトリごと納品してもらうのが基本 で、コードの所有権・著作権の取り扱いは契約書で明記する必要があります
ソースコードの納品形態（ZIP か Git リポジトリか、コミット履歴を含むか）はトラブルになりやすいポイントです。事前に「Git リポジトリへのアクセス権を含む形で引き渡し」と契約に明記しておくと安心です。
コーディング規約・README
- 主な内容: 命名規則、ディレクトリ構成、ビルド・起動手順
- なぜ必要か: 別の開発者が引き継ぐ際の必須資料。これが無いと、コードはあっても動かせない・保守できない、という事態になる
単体テスト仕様書・単体テストコード
- 主な内容: 個々の関数・モジュールに対するテスト項目とテストコード
- なぜ必要か: 品質の自動検証の仕組みとして機能する。継続的に改修していくシステムでは特に重要
テストフェーズの成果物（テスト結果報告書・バグ管理表等）
テスト工程は「品質の証拠を残す」工程です。発注者が検収判断するための直接的な根拠になります。
テスト仕様書
- 主な内容: 単体テスト・結合テスト・総合テスト・受入テストそれぞれのテスト項目、入力データ、期待結果
- なぜ必要か: 「何をテストしたか」が後から検証できる。再リリース時の回帰テストにも再利用できる
テスト結果報告書
- 主な内容: テスト実施日、合格／不合格件数、未解消バグの一覧、テストエビデンス（画面キャプチャ・ログ）
- なぜ必要か: 検収判断の根拠そのもの。この報告書が無いまま検収に進むのは避けるべき です
バグ管理表（課題管理表）
- 主な内容: 検出されたバグの一覧、重要度、対応状況、解消日
- なぜ必要か: リリース後に発生した不具合が「テスト時に既知だったか」を判別する重要な記録になる
受入テスト関連資料
- 主な内容: 受入テスト計画書、受入テスト結果報告書、検収書
- なぜ必要か: 発注者自身が業務シナリオで動作確認する「最終関門」の記録。受入テストの進め方は受入テスト・検収の進め方ガイドで詳しく解説しています
納品時に必ず確認すべき成果物チェックリスト
ここまで紹介した成果物のうち、発注者として納品時に必ず確認すべき項目 をチェックリスト形式でまとめました。検収前に、ベンダーから提示された納品物一覧と照らし合わせてください。
必須カテゴリ1: 仕様を残す書類
- 要件定義書（最終版）が納品リストに含まれているか
- 業務フロー図 / 機能一覧 が含まれているか
- 基本設計書（画面設計・帳票設計含む） が含まれているか
- 詳細設計書 / データベース定義書（ER 図） が含まれているか
- 設計書が 最新の実装内容と一致 しているか（古いまま放置されていないか）
必須カテゴリ2: コードと動作環境
- ソースコード一式 の納品形態（Git リポジトリ／ZIP）が契約書に明記されているか
- Git リポジトリの アクセス権限の譲渡 または引き渡しが含まれているか
- README / 環境構築手順書 が含まれており、別の開発者でも起動できる状態か
- コーディング規約 が文書化されているか
- サードパーティライセンス・OSS の 利用一覧（SBOM） が提示されているか
必須カテゴリ3: 品質を証明する書類
- テスト仕様書（単体・結合・総合・受入） が含まれているか
- テスト結果報告書 に合格件数・未解消バグの状況が記載されているか
- バグ管理表 が共有され、リリース時点の既知の不具合が一覧化されているか
- テストエビデンス（画面キャプチャ・ログ）が保存されているか
必須カテゴリ4: 運用・保守に必要な書類
- 操作マニュアル（エンドユーザー向け） が用意されているか
- 運用手順書（バックアップ・障害対応・監視設定） が用意されているか
- 保守契約・SLA（サポート対応範囲・対応時間）が文書化されているか
- サーバー・ドメイン・SaaS など インフラのアカウント情報の引き渡し方法 が決まっているか
契約・権利に関する確認事項
- 著作権・知的財産権 の帰属が契約書に明記されているか（発注者帰属／共有／ベンダー帰属）
- 検収条件（合格基準）が定量的に決まっているか
- 瑕疵担保期間（契約不適合責任の期間） が契約書にあるか
このチェックリストの中で「無い」「曖昧」と気づいた項目があれば、検収を進める前にベンダーに追加・明文化を依頼してください。検収後に「実は無い」と発覚すると、追加費用が発生するか、最悪の場合は永遠に手に入らなくなります。
まとめ
本記事では、システム開発で作成される成果物・ドキュメントの種類を工程別に整理しました。要点を振り返ります。
- 成果物 ≠ 納品物: 契約書で「納品物」として明記されたものだけが、正式に引き渡される
- 工程ごとに役割が異なる: 要件定義書は合意書、設計書は施工図、テスト結果報告書は品質の証拠
- 発注者は最低限の体系を理解しておく: 専門用語のままベンダーに丸投げせず、種類と役割をざっくり押さえる
- 検収前にチェックリストで確認: 仕様書類・コード・品質書類・運用書類の4カテゴリで抜け漏れを点検する
成果物の種類を知ることは、単なる豆知識ではありません。それは 「何が納品されないと、後で自社が困るか」を見抜くための判断基準 です。プロジェクトの最初に納品物リストを丁寧に握っておけば、検収時の「ドキュメントなし・コードのみ納品」のような事故はほぼ防げます。
関連記事
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
