システム開発の成果物一覧｜工程ごとのドキュメントと発注者が受け取るべき納品物
「見積書の納品物の欄に『基本設計書』『テスト結果報告書』と並んでいるが、何がどこまで必要なのかわからない」「開発会社を変えるときに、手元に何が残っていればよいのか知りたい」。システム開発の成果物は種類が多く、名前も会社によって違うため、発注者にとって確認しにくい項目のひとつです。
この記事では、システム開発の成果物とは何かを定義したうえで、工程ごとの主な成果物を一覧にまとめ、発注者が必ず受け取っておきたいもの、契約前に確認すべき点を解説します。
- システム開発の成果物とは、各工程で作られ、発注者に確認・納品されるドキュメントやプログラムのことです。
- 主な成果物は、要件定義書・基本設計書・詳細設計書・ソースコード・テスト仕様書と結果報告書・操作マニュアル・移行計画書です。
- 将来の保守や開発会社の変更に備え、要件定義書・基本設計書・ソースコード・環境の構成情報は必ず受け取っておきましょう。
- どの成果物を納品対象にするか、著作権をどう扱うかは契約書と見積書で事前に決める必要があります。
目次
システム開発の成果物とは
システム開発の成果物とは、開発の各工程で作られ、発注者が内容を確認したり、納品物として受け取ったりするドキュメントやプログラムのことです。完成したシステムそのもの（プログラム）だけでなく、要件をまとめた文書、画面や帳票の設計書、テストの記録、利用者向けのマニュアルなども成果物に含まれます。
成果物には大きく2つの役割があります。1つは、工程の区切りで「次に進んでよいか」を判断する材料になることです。もう1つは、稼働後の保守や改修、開発会社の変更のときに、システムの中身を正しく引き継ぐための記録になることです。
なお「成果物」と「納品物」は同じ意味で使われることもありますが、厳密には、開発の途中で作られる成果物のうち、契約で引き渡すと決めたものが納品物です。社内の作業用メモのように、成果物であっても納品されないものもあります。
関連記事システム開発の工程一覧｜要件定義の次の工程・略語（SDEM）・工程表の作り方
工程ごとの成果物一覧
一般的なウォーターフォール型の開発での、工程ごとの主な成果物は次のとおりです。会社や案件の規模によって、まとめたり省略したりすることがあります。
工程ごとの主な成果物
| 工程 | 主な成果物 | 発注者の関わり方 |
|---|---|---|
| 企画・構想 | システム化計画書、RFP（提案依頼書） | 発注者が作成（開発会社が支援することも） |
| 要件定義 | 要件定義書、業務フロー図、機能一覧、非機能要件一覧 | 内容を一緒に作り、承認する |
| 基本設計（外部設計） | 基本設計書、画面一覧・画面レイアウト、帳票レイアウト、データ項目一覧、外部連携仕様 | 業務に合っているかを確認し、承認する |
| 詳細設計（内部設計） | 詳細設計書、処理仕様書、データベース設計書（テーブル定義） | 主に開発会社が作成。納品対象かを確認する |
| 製造（実装） | ソースコード、実行プログラム | 納品対象と受け取り方法を確認する |
| テスト（単体・結合・総合） | テスト計画書、テスト仕様書、テスト結果報告書、不具合一覧 | 結果報告と残っている不具合を確認する |
| 受入テスト | 受入テスト項目表、受入テスト結果、検収書 | 発注者が実施し、検収する |
| 移行・リリース | 移行計画書、データ移行手順書、操作マニュアル、運用手順書 | 社内の準備と合わせて確認する |
| 運用・保守 | 環境の構成情報（サーバー・ドメイン・アカウント）、保守報告書、変更履歴 | 受け取り、社内で保管する |
上流工程の成果物
要件定義書は、システムで何を実現するか、どこまでを対象にするかを文書にしたもので、後の見積もりと受入テストの基準になります。基本設計書は、画面・帳票・データ・外部連携など、利用者から見える部分の仕様をまとめたものです。この2つは発注者が承認する成果物で、承認後に内容を変えると、以降の工程のやり直しになり追加費用の対象になりやすくなります。
関連記事基本設計とは？要件定義の次の工程｜成果物と発注者が確認すべきポイント
製造・テスト工程の成果物
製造工程の成果物はソースコードです。テスト工程では、何をどう確認するかを書いたテスト仕様書と、その結果をまとめた結果報告書が作られます。発注者がテストの細部まで確認する必要はありませんが、総合テストの結果報告と、未解決の不具合の一覧は受け取って目を通しておきましょう。
関連記事受入テスト（UAT）の進め方と検収のチェックポイント
発注者が必ず受け取っておきたい成果物
すべての成果物を受け取る必要はありませんが、次のものは、稼働後の保守や改修、開発会社の変更のときに欠かせません。契約時に納品対象として明記しておくことをおすすめします。
- 要件定義書：システムが「何のために、何をするものか」の基準。改修の判断や、別の会社への引き継ぎで最初に必要になる
- 基本設計書（画面・帳票・データ項目）：業務と画面の対応がわかる資料。操作の問い合わせや改修の見積もりに使う
- データベース設計書：データの持ち方がわかる資料。データ移行や他システムとの連携で必要になる
- ソースコード一式：最新版を、ビルドや配置の手順とあわせて受け取る。リポジトリの管理権限を発注者が持つ形が理想
- 環境の構成情報：サーバー、クラウド、ドメイン、外部サービスの契約者とアカウントの一覧。発注者名義での契約が望ましい
- 操作マニュアル・運用手順書：担当者が変わっても使い続けるための資料
契約前に確認したい3つのポイント
請負契約では、決めた成果物を完成させて納品する責任が開発会社にあります。準委任契約（成果完成型を除く）では作業そのものへの対価となるため、成果物の扱いをより明確にしておく必要があります。
関連記事請負と準委任の違い｜派遣との違い・システム開発での使い分けと注意点
アジャイル開発の場合の成果物
アジャイル開発では、短い周期で設計・製造・テストを繰り返すため、ウォーターフォール型のように工程ごとの文書をそろえるとは限りません。代わりに、機能の一覧と優先順位（プロダクトバックログ）、周期ごとの完成した機能、必要最小限の設計資料などが成果物になります。それでも、データベースの設計や環境の構成情報、ソースコードは、保守のために残しておく必要があります。
関連記事ウォーターフォールとアジャイルの違い｜発注側の選び方
よくある質問
- システム開発の成果物と納品物の違いは何ですか？
- 成果物は各工程で作られるドキュメントやプログラム全般を指し、そのうち契約で発注者に引き渡すと決めたものが納品物です。作業用の資料のように、成果物でも納品されないものがあります。
- 小規模な開発でも設計書は必要ですか？
- 小規模な開発では、基本設計書と詳細設計書をまとめるなど簡略化することがあります。ただし、画面とデータ項目の一覧、ソースコード、環境の構成情報は、規模にかかわらず残しておくと保守や改修で困りません。
- 開発が終わった後から成果物を受け取ることはできますか？
- 契約で納品対象になっていない成果物は、追加の費用や交渉が必要になることがあります。後から受け取るのは難しい場合もあるため、契約前に納品対象を一覧で確認しておくのが確実です。
- 設計書がない既存システムはどうすればよいですか？
- 既存のプログラムやデータベースを解析して、現状の設計書を作り直すことができます。改修やリプレイスの前に、現状調査として依頼するのが一般的です。
まとめ
システム開発の成果物は、要件定義書から設計書、ソースコード、テストの記録、マニュアルまで、工程ごとに作られます。工程の区切りの判断材料であり、稼働後の保守や引き継ぎの記録でもあります。要件定義書・基本設計書・ソースコード・環境の構成情報は必ず受け取れるよう、納品対象と著作権の扱いを契約前に決めておきましょう。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
