システム開発を外部の会社に依頼する際、成果物として扱うのはシステム本体だけではありません。要件定義書や設計書、テスト結果報告書など、システム開発に必要なドキュメントや、その後の保守に必要な書類も、一般的には成果物として扱われます。
ただ、初めて開発を外注する場合は、「どんなドキュメントが必要なのか」「そもそも何のためにあるのか」はイメージしにくいかもしれません。
この記事では、初めて開発を外注する担当者様向けに、「システム開発の成果物とは何か」という基礎から、工程別の成果物一覧、プロジェクトのタイプごとの具体例、そして発注側が知っておきたい管理・検収のポイントまでを解説します。
自社が依頼するプロジェクトでどんな成果物が必要になるのかをイメージし、開発会社と齟齬なくコミュニケーションを取るための参考になれば幸いです！
システム開発における成果物とは？
システム開発の成果物とは、開発の各工程で作成されるドキュメントやプログラムの総称です。まずは基本として、混同しやすい「納品物」との違いから見ていきましょう。
成果物と納品物の違い
まず混同しやすいのが「成果物」と「納品物」です。
成果物とは、開発の各工程で作成されるドキュメント・プログラム・各種ファイルなど、一般的には開発に付随するすべてのデータを指します。納品物は、そのうち契約にもとづいて発注者へ正式に引き渡されるものだけを指します。
つまり、開発中に作られた成果物のすべてが手元に来るわけではありません。何を納品物として受け取れるかは契約次第なので、この違いを理解しておくことが、後々のトラブル回避にもつながります。
| 成果物 | ・開発の各工程で作られるアウトプット全般（社内確認用も含む） ・要件定義書、設計書、ソースコード、テスト結果報告書、課題管理表など |
|---|---|
| 納品物 | ・契約で「引き渡す」と定めた成果物を指す ・要件定義書、設計書一式、操作マニュアル、ソースコード（契約による）など |
なぜ成果物が必要なのか
成果物は、単なる作業の記録ではありません。プロジェクトを成功させるために、次のような役割を担っています。
- 💡 成果物が果たす主な役割
-
- 認識合わせ：発注者と開発会社が「作るもの」の完成イメージを共有する
- 進捗・品質の可視化：各工程で何がどこまでできたかを確認できる
- 手戻りの防止：前工程の内容を文書化しておくことで、後工程でのズレや作り直しを防ぐ
- 引き継ぎ・保守：担当者が変わっても、運用・改修を続けられる
実際、IPA（情報処理推進機構）も、要件定義で決めきれなかった内容が後工程で手戻りにつながり、工期の遅延や工数の増大を招く大きな原因になると指摘しています。そのため、成果物（ドキュメント）の品質向上が重要とされています。
成果物の種類はプロジェクトによって異なる
大切なのは、成果物の種類や数はプロジェクトによってまちまちだということです。開発の規模、契約形態、そして採用する開発手法によって、作られるドキュメントは変わります。
たとえば、工程をきっちり区切って進めるウォーターフォール型では各工程で網羅的にドキュメントが作られますが、短いサイクルで開発を繰り返すアジャイル型では、ドキュメントの粒度やタイミングが柔軟になります。
ただし、アジャイルであっても要件定義書・設計書相当（画面／API／ER図）・テスト結果・運用手順書といった本質的なドキュメントの必要性は大きく変わりません。
「工程が緩いから成果物は少なくて当然」と考えずに、最終版を一式残してもらう約束を契約時に取り決めておくことが重要です。
【一覧表】工程別・成果物の種類と役割
まずは全体像をつかむため、ウォーターフォール型を例に、工程ごとの代表的な成果物と発注側での活用ポイントを一覧にまとめました。
| 工程 | 代表的な成果物 | この成果物でわかること・活用ポイント |
|---|---|---|
| 企画・要求定義 | RFP（提案依頼書） | 開発の目的ややりたいこと、予算感を整理したドキュメント。発注者側で制作する場合も多い |
| 要件定義 | 要件定義書、業務フロー図、機能一覧、非機能要件定義書 | 「何を作るか」を確定させる。発注側が最も念入りに確認すべき成果物 |
| 基本設計（外部設計） | 基本設計書、画面設計書、画面遷移図、ER図、API一覧 | 画面や操作の見た目・使い勝手を発注側の目線で確認できるデータ・書類 |
| 詳細設計（内部設計） | 詳細設計書、モジュール設計書、テーブル定義書 | 内部の作り込みを規定する。主に開発会社内で使う技術資料 |
| 開発（実装） | ソースコード、実行モジュール、コーディング規約 | システムそのもの。保守や乗り換えのため納品範囲を要確認 |
| テスト | テスト計画書、テスト仕様書、テスト結果報告書、バグ管理表 | 要件どおり動くかを検証した証跡。検収の根拠になる |
| リリース・運用保守 | 操作マニュアル、運用手順書、移行計画書、検収書 | 実際の運用や、社内への展開・引き継ぎに使う |
※表は横スクロールできます
これらのほかにも、プロジェクト全体を通してWBS（作業分解構成図）・課題管理表・議事録といった管理用の成果物が随時作成されます。
開発手法による成果物の違い
同じシステム開発でも、採用する手法によって成果物の作られ方は変わります。代表的なウォーターフォール型とアジャイル型を比べると、次のようなイメージです。
| ウォーターフォール型 | アジャイル型 | |
|---|---|---|
| 成果物の作られ方 | 工程ごとに網羅的に作成し、都度確定させる | 短いサイクルで必要な分を作成し、更新を重ねる |
| ドキュメントの粒度 | 詳細・大量になりやすい | 柔軟。最小限に絞られることもある |
| 発注側の注意点 | 各工程の区切りで内容をしっかり確認する | 最終版のドキュメント一式を残す約束を契約で握る |
開発工程ごとの成果物と役割
ここからは、各工程でどんな成果物が作られ、それぞれどんな意味を持つのかを、発注側の視点を交えて見ていきましょう。
1. 企画・要求定義
プロジェクトの入り口となる工程です。自社が「なぜ・何を実現したいのか」を整理し、開発会社に伝えるための書類が中心になります。
| 主な成果物 | 役割 |
|---|---|
| RFP（提案依頼書） | 発注側が「実現したいこと・予算・納期」を整理して開発会社に提示する書類 |
| 企画書・提案書 | 開発会社側が解決策や進め方を提案する書類 |
| 見積書 | 費用・期間・体制の見積もり。依頼先を比較する材料になる |
この工程の成果物は、発注側が主体的に用意する（あるいは開発会社と一緒に固める）ものが多いのが特徴です。ここが曖昧だと後工程すべてに影響するため、丁寧に作り込みましょう。
2. 要件定義
「何を作るか」を確定させる、システム開発で重要な工程のひとつです。ここで作られる要件定義書は、以降の設計・開発・テストすべての土台になります。
| 主な成果物 | 役割 |
|---|---|
| 要件定義書 | システムに必要な機能・業務要件をまとめた最重要ドキュメント |
| 業務フロー図 | 現状（As-Is）とあるべき姿（To-Be）の業務の流れを可視化 |
| 機能一覧 | 実装する機能を漏れなくリスト化したもの |
| 非機能要件定義書 | 性能・セキュリティ・可用性など「動きの質」を定義 |
要件定義書は専門用語が多くなりがちですが、発注側が内容を理解・合意できる状態にすることが肝心です。「読んでもわからないからお任せ」にすると、完成後に「思っていたものと違う」という事態を招きがちです。
💡要件定義で定義すべき項目については、次の記事も参考にしてください。
システム設計・構築を始める前に！要件定義フェーズで定義すべき3つのこと
Shinnosuke Koike
3. 基本設計（外部設計）
要件定義をもとに、ユーザーから見える部分（画面・操作・帳票など）を具体化する工程です。発注側が完成イメージを確認しやすい成果物が多く出てきます。
| 主な成果物 | 役割 |
|---|---|
| 基本設計書（外部設計書） | システム全体の構成や機能の仕様をまとめたもの |
| 画面設計書・画面遷移図 | 各画面のレイアウトや、画面間の移動の流れを示す |
| ER図 | 扱うデータ同士の関係を図で表したもの |
| API一覧 | 外部システムとの連携仕様を整理したもの |
画面設計書や画面遷移図は、発注側が「使い勝手」を具体的にイメージできる貴重な成果物です。開発着手の前に具体的な完成イメージの認識を揃えるためにも、重要な工程といえます。この段階で違和感があれば、遠慮なくフィードバックしましょう。
4. 詳細設計（内部設計）
基本設計を、プログラムに落とし込めるレベルまで細かく規定する工程です。主に開発会社の内部で使われる技術資料が中心になります。
| 主な成果物 | 役割 |
|---|---|
| 詳細設計書（内部設計書） | プログラムの内部構造や処理ロジックを規定 |
| モジュール設計書 | 機能を構成する部品（モジュール）単位の設計 |
| テーブル定義書 | データベースの表の構造を定義したもの |
詳細設計書は専門性が高いため、発注側がすべてを読み解く必要はありません。ただし、保守・改修やなんらかの事情で他社への乗り換えが必要になった際に備えて、納品物に含めてもらうことを検討する価値があります。
5. 開発（実装）
設計書にもとづいて、実際にプログラムを作る工程です。システムそのものにあたる成果物が生まれます。
| 主な成果物 | 役割 |
|---|---|
| ソースコード | システムの動作を記述したプログラム本体 |
| 実行モジュール | 実際に動作する形式に変換されたプログラム |
| コーディング規約 | コードの書き方を統一するためのルール |
ソースコードの著作権や納品範囲は、契約によって扱いが大きく分かれる部分です。将来の内製化や他社への保守移管を見据えるなら、ソースコードの納品と権利の扱いを契約時に必ず確認しておきましょう。
6. テスト
作ったシステムが要件どおりに正しく動くかを検証する工程です。ここで作られる成果物は、検収の根拠となる重要な証跡になります。
| 主な成果物 | 役割 |
|---|---|
| テスト計画書・テスト仕様書 | どういう観点・条件でテストするかを定めた書類 |
| テスト結果報告書 | テストを実施した結果をまとめた報告。検収の判断材料 |
| バグ管理表 | 発見された不具合と、その修正状況を管理する一覧 |
テスト結果報告書は、「品質が担保されているか」を発注側が確認するための成果物です。バグ管理表とあわせて、重大な不具合が残っていないかをチェックしたうえで検収に進みましょう。
7. リリース・納品・運用保守
完成したシステムを実際の環境に導入し、運用を始める工程です。運用や社内展開に使う成果物が納品されます。
| 主な成果物 | 役割 |
|---|---|
| 操作マニュアル・運用手順書 | 実際の利用者・運用担当者が使うための手引き |
| 移行計画書 | 既存データや旧システムからの切り替え手順を定めたもの |
| 検収書 | 納品物が要件を満たしていることを発注側が確認・承認する書類 |
操作マニュアルや運用手順書は、システムを社内に定着させ、担当者が変わっても運用を続けるために欠かせません。誰でも運用できる状態かという観点で確認しましょう。
【ケース別】プロジェクトに応じた成果物の例
前述のとおり、成果物はプロジェクトのタイプによって変わります。ここでは、イメージをつかんでいただくために、代表的な2つのモデルケース（説明用の想定例）で「どんな案件でどんな成果物が出るか」を紹介します。実際の案件では、契約内容や規模によって内容が変わる点にご留意ください。
モデルケース1：業務システムをスクラッチで新規構築する場合
社内の基幹業務を効率化するため、ウォーターフォール型で数千万円規模の業務システムをゼロから開発するようなケースです。
| 前提 | 中〜大規模／ウォーターフォール型／多くの部署が利用 |
|---|---|
| 主な成果物 | 要件定義書、業務フロー図、基本設計書、詳細設計書、ER図、テーブル定義書、テスト仕様書・結果報告書、操作マニュアル、運用手順書、移行計画書、ソースコード など |
| ポイント | 各工程の成果物が網羅的にそろう。関係部署が多いため、業務フロー図や操作マニュアルの完成度が定着のカギになる |
このケースでは成果物の点数が多くなるため、後述する「管理ルールの整備」が特に重要になります。
モデルケース2：Webサービス・アプリをアジャイルで開発する場合
新規事業として、まず必要最小限の機能（MVP）を素早くリリースし、改善を重ねていくようなケースです。
| 前提 | 小〜中規模／アジャイル型／スピード重視で仕様を柔軟に調整 |
|---|---|
| 主な成果物 | プロダクトバックログ（要件リスト）、画面設計、API仕様、ソースコード、テスト結果、運用手順書 など（各スプリントで更新） |
| ポイント | ドキュメントは軽量になりがち。だからこそ「最終版を一式残す」約束を契約で明確にしておく |
アジャイルは柔軟さが魅力ですが、その分「ドキュメントが最新の実装と食い違う」「後から誰も仕様を説明できない」といった事態が起きがちです。開発中から成果物の最終化ルールを決めておくと安心です。
発注側が知っておきたい成果物の管理ポイント
成果物は、受け取って終わりではありません。適切に管理・活用してこそ価値が生まれます。とくに発注側で成果物をめぐるトラブルは、次のようなトラブルにつながることがあります。
- 納品される成果物を契約前に取り決めていない
- 内容を確認せずに受け取り、後で不足に気づく
- ファイルが担当者の個人フォルダに散らばり、所在不明になる
- 成果物一覧を契約時に確定：何がいつ納品されるかを明文化
- 内容をレビューして検収：受け取り時に過不足と品質を確認
- 保管・管理ルールを整備：置き場所と担当を決めて一元管理
こういったトラブルを避けるために、発注側で確認しておきたいポイントを4つ紹介します。
必要な成果物を契約・見積時に洗い出す
「どの成果物を納品物として受け取るか」は、契約の段階で開発会社とすり合わせておきましょう。
ソースコードや詳細設計書など、保守や乗り換えに関わる成果物は、納品範囲と権利の扱いを見積書・契約書に明記してもらうことが大切です。後からトラブルになるリスクを防げます。
各ドキュメントの内容をレビューして検収する
成果物は受け取るだけでなく、内容を確認したうえで検収することが重要です。
とくに要件定義書とテスト結果報告書は、発注側が主体的に目を通すべき成果物です。専門的で判断が難しい場合は、社内の情報システム部門や、第三者の専門家にレビューを依頼するのも有効です。
保管場所・管理担当・バージョン管理を決める
納品された成果物が個人のPCやメールに埋もれてしまうと、いざというときに探せません。
共有ストレージなどに保管場所を一元化し、管理担当者とバージョン管理のルールを決めておきましょう。「どれが最新版か」がわかる状態を保つことが、後の改修をスムーズにします。
社内での運用・更新ルールを決める
システムは納品後も改修や機能追加が続きます。成果物（とくに設計書やマニュアル）を最新の状態に更新し続けるルールがないと、実物とドキュメントが食い違い、やがて誰も内容を把握できなくなります。
属人化を避けるためにも、更新の責任者やタイミングを決めて運用しましょう。
システム開発の進め方や失敗の防ぎ方をより詳しく知りたい方は、あわせて次の記事もご覧ください。
システム開発工程・流れを基本からわかりやすく解説
クドウ
【プロが解説】システム開発で陥りがちな失敗事例7選と対策方法
Akemi
よくある質問
Q: 成果物と納品物の違いは何ですか？
成果物は開発の各工程で作られるドキュメントやプログラムのすべてを指し、納品物はそのうち契約にもとづいて発注者へ正式に引き渡されるものだけを指します。すべての成果物が納品されるとは限らないため、何を受け取れるかは契約で確認しましょう。
Q: 成果物やソースコードの著作権・所有権は誰のものですか？
契約内容によって異なります。とくにソースコードの著作権は、開発会社に帰属するケースと発注側に譲渡されるケースがあります。将来の内製化や他社への保守移管を考えるなら、契約時に権利の扱いと納品範囲を必ず確認してください。
Q: アジャイル開発でもドキュメント（成果物）はもらえますか？
もらえます。アジャイルは工程の区切りが緩くドキュメントが軽量になりがちですが、要件・設計・テスト結果・運用手順といった本質的な成果物の必要性は変わりません。最終版を一式残してもらう約束を契約で握っておくと安心です。
Q: すべての成果物を納品してもらうべきですか？
必ずしもすべてが必要とは限りません。ただし、要件定義書・設計書・テスト結果報告書・操作マニュアルなど、運用や保守、将来の改修に関わる成果物は受け取っておくのがおすすめです。自社の運用体制に合わせて、必要な成果物を選びましょう。
Q: 成果物の品質はどう確認すればよいですか？
要件定義書は「作りたいものと合っているか」、テスト結果報告書は「重大な不具合が残っていないか」という観点で確認します。専門的で判断が難しい場合は、社内の情報システム部門や第三者の専門家にレビューを依頼するのも有効です。
まとめ
ここまでお話ししてきたように、システム開発の成果物には、要件定義書や設計書、テスト結果報告書、操作マニュアルなど、各工程で作られるさまざまなアウトプットがあります。
その種類や数はプロジェクトの規模・契約・開発手法によって変わりますが、各成果物の役割を理解し、必要なものを契約時に取り決めて、受領後に適切に管理・検収することが、発注を成功させるうえで欠かせません。
成果物の意味と活用方法を理解しておけば、開発会社とも齟齬なくコミュニケーションを取れ、「思っていたものと違う」といった失敗を防げます。この記事を参考に、自社のプロジェクトに必要な成果物をぜひイメージしてみてください。
システム開発の依頼先選びに不安がある方は、次の記事もあわせてご覧ください。
プロ厳選おすすめシステム開発会社22社│選び方・費用も解説
Shinnosuke Koike
システム開発の依頼先選びや進め方に不安がある方は、専門家に相談しながら進めるのがおすすめです。
