システム開発の成果物・ドキュメント｜知っておきたい開発工程ごとの成果物を一覧で紹介！

システム開発の成果物は、プログラムとしてのシステム本体。しかし、システムが完成するまでの開発工程では「発注側・開発側の認識のズレを修正するため」「開発チームで情報共有するため」、各種ドキュメントを含むさまざまな成果物が制作されます。

企業・店舗の担当者であれば、プロジェクトを適切に管理して開発をスムーズに進めるためにも、各工程でどのような成果物・ドキュメントが作られるのか、把握しておくことが重要です。

そこで本記事では、ウォーターフォール型システム開発で制作される一般的な成果物・ドキュメントを開発工程ごとに一覧で紹介！最後までご覧いただければ、どのような成果物・ドキュメントを納品してもらうべきなのかも理解できます。

※現在、システム開発の依頼先を探している方はシステム幹事にご相談ください。予算や目的から最適な開発会社を選定させていただきます。相談料などは一切かかりません。

【無料】おすすめのシステム開発会社を紹介してもらう

システム開発における成果物・ドキュメントの役割

◎システム開発における成果物の一覧（ウォーターフォール型の場合）

システム開発における成果物とは、各工程で作成される書類やドキュメントなどを指します。システム開発は細かい工程に分かれており、最終的な納品物以外にも様々な成果物を作成します。
ウォーターフォール型の開発における開発の工程は以下の図です。

ウォーターフォール型システム開発の特徴は、水が上流から下流に流れるように複数の開発工程をステップごとに進めていくこと。そして基本的にひとつの工程が完了してから次の工程に移ること、後戻りがないことです。それぞれの工程で、ドキュメント・プログラムなどの成果物が大量に作られることもウォーターフォール型システム開発の特徴です。

それでは、各工程で作られる成果物はどのような役割を果たしているのか？ひとつは、上流工程の作業結果としてアウトプットされた成果物を、ひとつ下流の工程のインプットとして役立てるため。この際、アウトプットされた成果物が不完全だと、以降の工程すべてに悪影響がおよんでしまいます。

こうした事態を避けるには、各工程のアウトプットが次のインプットとして妥当なものなのか？チェックして判断するためにも、クライアントを含めた関係者間で成果物を共有する必要が出てきます。これこそが、成果物が果たすもうひとつの役割だといえるでしょう。

ウォーターフォール型システム開発の工程例

上の表は、一般的なウォーターフォール型システム開発の工程例です。開発・実装フェーズでは、機能・モジュール（部品）ごとに開発された「プログラム」が成果物となりますが、それ以外の工程では、成果物としてなんらかのドキュメントが作成されると考えていいでしょう。

また、単体・結合・総合テストの結果（アウトプット）が、上流工程である開発フェーズに戻されることはあるものの、ウォーターフォール型の各工程で制作される成果物は、次の工程のインプットとして活用されることが基本です。

※ウォーターフォール型システム開発についてより詳しく知りたい方は、以下の記事も参考にしてください

関連記事：ウォーターフォール型システム開発とは？開発工程・メリット・アジャイル型との違いを解説！

開発工程ごとの成果物：1. 企画・要求定義

業務課題を解決するため、どのようなシステムを開発すべきか、持ち上がった企画（システム開発プロジェクト）をもとに、システムに求められる具体的な要求まで落とし込むのが要求定義です。

要求定義の成果物として挙げられるドキュメントには「RFP（提案依頼書）」がありますが、これは基本的に発注側であるクライアント自身が作成します。

RFPは、複数のシステム開発会社から適正な提案書を得るため、統一されたインプットを提供するためにも有効なドキュメントです。システム開発会社選定後、プロジェクト最初のステップである要件定義のインプットとしても活用されます。

関連記事：RFPとは？システム開発の質を高める提案依頼書の作り方を解説！【サンプルあり】

提案書・見積書

本記事の意図とは若干外れますが、RFPに対する返答としてシステム開発会社が作成する「提案書」「見積書」も、システム開発プロジェクトの成果物といえるかもしれません。

提案書は、クライアントのニーズを実現するシステムの提案、開発会社としての体制・プロジェクトの進め方など、プレゼンテーション中心の提案内容が記載され、概算見積書とともに提出される場合が一般的です。

開発工程ごとの成果物：2. 要件定義

要件定義フェーズでは、要求定義をインプットに分析・検討し、システムで実現すべき要件をドキュメントとしてまとめた成果物である「要件定義書」が制作されます。要件定義書は受託側の開発会社が作成することが基本ですが、プロジェクトの予算・納期とのバランスで発注側のニーズ・要求すべてを盛り込めない場合も。

そのため、最終的な要件を定義するまでには、発注側・受託側で綿密なコミュニケーションを重ね、妥結点を探っていく必要があります。プログラム完成後の総合テスト、納品後の受け入れテスト設計も、要件定義フェーズで策定されます。

関連記事：システム開発における要求定義の重要性｜要件定義との違いや要求定義の実態・改善ポイントを解説！

システム要件

システム要件とは、現状の業務フロー、新規の業務フローとのギャップを踏まえ、システムでどのようにギャップを埋めていくのか、システム開発の方向性を明確にした要件のこと。具体的には、新規業務フローを実現するためにシステム化するもの、しないものを選別していきます。

発注側としては、システム開発の目的・ゴールを達成するために譲れるもの、譲れないものの優先順位を付けていくことが重要です。

機能要件

機能要件とは、開発するシステムに実装するべき機能を、要件として明確に定義すること。具体的には、システムの機能・構造やデータの種類、処理可能な内容など、システムに必要な要件をひとつひとつ定義付けていきます。

非機能要件

非機能要件とは、実装すべき「機能要件以外」で、システムに求められるすべての要件のことを意味します。たとえば、システムが実現すべき処理能力などのパフォーマンス、将来的なトラフィック増加、機能追加に対応できる拡張性、外部脅威に対応するセキュリティなどがわかりやすい例として挙げられるでしょう。

一般的には、情報処理推進機構（IPA）が策定した「非機能要求グレード」6項目をもとに、システムに求められる非機能要件を策定していくケースが多いようです。

参考：情報処理推進機構（IPA）システム構築の上流工程強化（非機能要求グレード）

WBS（Work Breakdown Structure）

WBSとは、システム開発の工程をタスクごとに細分化し、期限と進捗率を表にした構成図のこと。各開発工程のマイルストーン（中間目標）となるドキュメントを含めた成果物と紐付けながら、システム開発プロジェクトに必要な作業を構造化したものです。

スケジュールをグラフで視覚化した工程表（ガントチャート）とともに作成される場合がほとんどであり、システム開発プロジェクトの進行スケジュールを関係者間で共有するために活用されます。

関連記事：システム開発におけるWBSとは？プロジェクト管理の基礎を解説！

受け入れテスト設計書

受け入れテスト設計書とは、プロジェクトの成果物である「システム」納品後に、要件定義で策定されたニーズ・要求が満たされているか発注側がチェックするために活用する設計書のこと。

受け入れテスト自体が「要件定義を満たしているか」確認するためのテストであるため、計画書・仕様書とともに、要件定義フェーズで作成される設計書です。開発会社側の最終確認である「総合テスト」の計画書・仕様書・設計書も作成されます。

関連記事：システム開発の要件定義とは？受託開発における重要性や進め方を解説！

開発工程ごとの成果物：3. 基本設計

基本設計フェーズでは、要件定義書で定められた「システム要件」「機能要件」「非機能要件」をより具体的なレベルまで作り込み、外部から見たシステムの設計図をドキュメントとしてまとめた成果物「基本設計書」を制作します。

システム開発工程に発注側が携われる最後のチャンスであるのも基本設計フェーズ。成果物・アウトプットである基本設計書に的確なフィードバックを与え、開発会社との認識の違いを極力排除しておく必要があります。

システム設計

システム設計とは、要件定義で策定した機能要件（必要な機能）・非機能要件（機能以外の要求）をもとに、どのようなソフトウェア・ハードウェア・ネットワークでシステムを構成するべきなのか、具体的な設計書・構成図に落とし込んでいく作業です。

機能要件はもちろん、要件定義でも触れた可用性（アベイラビリティ）、パフォーマンス、拡張性、セキュリティ、運用性などの非機能要件も満たせるような設計が必要です。

機能設計

機能設計とは、要件定義で定められた機能要件を、より具体的な設計書として作成していく作業のこと。上の表でも挙げたように、画面・帳票・バッチ・データベース・ファイルなどの一覧・レイアウト・遷移図などが作成されます。

関連記事：システム開発の基本設計とは？重要性・発注者としての関わり方を解説！

開発工程ごとの成果物：4. 詳細設計

詳細設計フェーズでは、システムを外部から見た「基本設計書」をインプットに、プログラマーの指示書となる設計図をドキュメントとしてまとめた成果物「詳細設計書」を制作します。具体的な設計書のほかにも、プログラマーのスキル差を解消するための開発方針・ルール策定、単体・結合テスト設計も詳細設計フェーズで実施されます。

関連記事：システム開発の詳細設計とは？プロジェクトの位置付け・役割をわかりやすく解説！

開発方針・ルール

ゼロからシステムを構築するスクラッチ開発には、機能に関する制限が事実上存在しないというメリットがありますが、開発期間の長期化・開発コストの高騰というデメリットが。納期・コストに制限のあるプロジェクトでは、フレームワーク・ライブラリを活用するケースがほとんどです。

こうしたシステム開発プロジェクトの方向性を具体化したものが「開発方針」、そして、プログラマー間のスキル差を吸収する目的で策定される「記述ルール」です。

単体・結合テスト設計書

詳細設計以降のシステム開発工程は、詳細設計書をもとにした「開発・実装フェーズ」に移りますが、その際にプログラマーが活用するのが「クラス図」「モジュール構成図」といった設計図。

このことからもわかるように、プログラムの開発・実装フェーズでは、複数のプログラマーが分割された個々のモジュール開発を担当し、出来上がったモジュールをサブシステムとして結合、さらにサブシステムを結合することでひとつのシステムが構築されます。詳細設計フェーズで単体・結合テスト設計が行われるのはこのためです。

開発工程ごとの成果物：5. 単体・結合・総合テスト

それぞれのテストフェーズでは、成果物・アウトプットとしてテスト実施報告書が制作されます。テスト計画書・仕様書・設計書に従って実施される各種テスト結果に応じ、プログラムを修正するため開発・実装フェーズに工程が戻される場合もあります。

開発工程ごとの成果物：6. 受け入れテスト

受け入れテストの結果としてアウトプットされるのは、最終的に受け入れに合意したという検収書。ただし、万全の体制を整えてミスなく受け入れテストを実施するためにも、テスト計画書・仕様書・設計書はもちろん、「総合テスト実施報告書」もインプットとして納品しておいてもらうことがベストです。

関連記事：システム開発のテスト工程を徹底解説！システムテストと受け入れテストの違い

まとめ：必要な成果物は納品物として指定することを忘れずに

システム開発プロジェクトを適切に管理したい企業・店舗担当者の方に向け、本記事では、ウォーターフォール型システム開発で制作される一般的な成果物・ドキュメントを、開発工程ごとに一覧で紹介してきました。

一般的に、システム開発における成果物の定義、および納品物の定義は、要件定義フェーズで決められますが、本記事で紹介してきた成果物すべてが納品物であるとは限りません。

通常であれば、要件定義・基本設計・総合テストにおける成果物が納品されれば困ることはないものの、将来的なリプレースも含め、どのような成果物を納品して欲しいのか？プロジェクト開始時に、しっかり見極めて指定しておく必要があります。

そうした適切なコミュニケーションと工程を共に進めることができ、自社に最適な開発会社を探している方は、システム幹事にご相談ください。専門のコンサルタントがあなたの要望を丁寧にヒアリングし、予算にあった最適な開発会社を選びます。

コンサルタントのご紹介 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます！
初心者の方でも安心してご相談いただけます。

必ず開発会社に発注する必要はありません。システム開発の相場の情報から最適な会社選びまで無料でサポートします。お気軽にご相談ください。

【無料】プロのアドバイザーにおすすめの開発会社を紹介してもらう