「来週で契約は終了となりますので、最終の成果物一覧をご確認ください」——今のベンダーとの関係が切れる段階でそう言われたとき、渡された一覧を見て「これで本当に全部揃っているのか」を即答できる発注者は多くありません。要件定義書、基本設計書、詳細設計書、テスト仕様書……。一見もっともらしい一覧表に対し、自社の案件で本来あるべきドキュメントが抜けていないかを判断するのは簡単ではないからです。
特に、IT 部門ではない事業部門の担当者が契約終了・ベンダー切替の窓口を任されているケースでは、「専門用語の連続でチェックしようがない」「言われるままサインしたら、次のベンダーに引き継ぐ段階で設計書もテスト結果も無いことが発覚した」というトラブルがしばしば発生します。厄介なのは、この局面では後戻りができない点です。プロジェクト進行中であれば「後日追加でください」と頼めますが、契約が終了し旧ベンダーとの関係が切れてしまえば、足りないドキュメントを追加でもらう手段はほぼ残りません。
そこで本記事では、システム開発で一般的に作成される成果物・ドキュメントの種類を工程別に網羅的に解説します。各工程で「どんな名前のドキュメントが」「何のために」作られるのかを、発注者目線で平易に整理しました。あわせて、契約終了・ベンダー切替のタイミングで発注者が確認すべき項目をチェックリスト形式にまとめています。
この記事を読み終えるころには、ベンダーから提示された最終成果物一覧を見て「この項目が足りない、追加してほしい」と契約終了前に具体的に交渉できるようになっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の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をお送りします。
よくある質問
- 「成果物」と「納品物」を契約書ではどう書き分ければよいですか？
契約書では「納品物一覧」という独立した別表を設け、ドキュメント名・バージョン・形式・引き渡し方法を明記してください。「成果物」という曖昧な総称だけで合意すると、ベンダー社内資料が引き渡し対象外と解釈され、検収後に設計書が手に入らない事故につながります。
- アジャイル開発の場合、設計書などの成果物はどこまで必要ですか？
工程区切りが緩いアジャイルでも、要件定義書・基本設計書相当（画面/API/ER図）・テスト結果・運用手順書は必須と考えてください。本記事の工程別一覧から「最新の実装と一致した最終版を一式残す」ことを契約で握れば、ドキュメント名や作成タイミングは柔軟に調整して構いません。
- ソースコードは Git リポジトリと ZIP のどちらで納品してもらうべきですか？
原則として Git リポジトリでの引き渡しを推奨します。コミット履歴は障害調査や責任範囲の判別に直結する一次資料のため、ZIP のみの納品では運用保守フェーズで実質的に再現不可能な状況に陥ります。契約書に「リポジトリのアクセス権譲渡を含む」と明記してください。
- テスト結果報告書が提出されない／内容が薄い場合はどうすべきですか？
検収を保留し、合格件数・未解消バグ一覧・テストエビデンス（画面キャプチャ・ログ）の追加提出を求めてください。報告書は検収判断の唯一の客観根拠であり、これが無いまま検収すると、リリース後の不具合が「既知だったか」を判別できなくなり瑕疵対応で不利になります。
- 著作権の帰属は発注者・共有・ベンダーのどれにすべきですか？
自社で改修や別ベンダーへの引き継ぎを行う前提なら「発注者帰属」を選んでください。OSS や汎用部品が含まれる場合は完全な発注者帰属が難しいため、「成果物本体は発注者帰属、汎用ライブラリは原ライセンスに従う」という形で SBOM とセットで合意するのが現実的です。
