システム開発の成果物・ドキュメント|知っておきたい開発工程ごとの成果物を一覧で紹介【2024年最新版】

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

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

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

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

システム開発の費用相場や依頼時の注意点については、こちらにまとめています。あわせて参考にしてください。

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

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

目次
  1. 1. システム開発における成果物・ドキュメントの役割
  2. 2. ウォーターフォール型システム開発の工程例
    1. 2-1. 開発工程ごとの成果物:1. 企画・要求定義
    2. 2-2. 開発工程ごとの成果物:2. 要件定義
    3. 2-3. 開発工程ごとの成果物:3. 基本設計
    4. 2-4. 開発工程ごとの成果物:4. 詳細設計
    5. 2-5. 開発工程ごとの成果物:5. 単体・結合・総合テスト
    6. 2-6. 開発工程ごとの成果物:6. 受け入れテスト
  3. 3. まとめ:必要な成果物は納品物として指定することを忘れずに

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

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

システム開発の工程

成果物

作成担当者

企画・要求定義

RFP(提案依頼書)

発注者

要件定義

要件定義書

開発会社

基本設計

基本設計書

開発会社

詳細設計

詳細設計書

開発会社

単体テスト

単体テスト実施報告書

開発会社

結合テスト

結合テスト実施報告書

開発会社

総合テスト

総合テスト実施報告書

開発会社

受け入れテスト

検収書

開発会社

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

ウォーターフォール型

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

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

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

【無料】システム開発の依頼について相談する

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

開発フェーズ

概要

企画・要求定義

業務課題を解決するシステムを企画

システムに求めるニーズ・要求を定義

要件定義

要求定義をもとに、実現可能なシステム要件に落とし込む

基本設計

要件定義をもとに、システムの見える部分を具体化・設計(外部設計)

詳細設計

基本設計をもとに、プログラミングに必要な設計書を作成(内部設計)

開発・実装

設計書をもとにプログラム・機能を開発・実装

単体テスト

機能・モジュール単位で開発されたプログラムをテスト

結合テスト

単体テストの完了したモジュールを結合してテスト

総合テスト

システムとして出来上がったプログラムを総合的にテスト

受け入れテスト

完成したプログラムが要件を満たしているか、?発注側でテスト

リリース

検収を経てシステム稼働・リリース

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

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

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

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

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

企画・要求定義の成果物

成果物の中身

RFP(提案依頼書)

システム開発の目的

 

会社概要・組織体制・業務内容

 

現状の課題・達成したい理想の姿(業務要件)

 

システムに求めるニーズ・要求(要求定義)

 

プロジェクトに対する自社体制・役割

 

依頼したい範囲(ソフトウェア・ハードウェアなど)

 

予算・納期

 

提案依頼事項(提案して欲しい内容)

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

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

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

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

提案書・見積書

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

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

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

要件定義の成果物

成果物の中身

概要

要件定義書

システム概要

どのようなシステムを開発するか?

 

全体図

ソフトウェア・ハードウェアで

構成される全体の構成図

 

業務フロー図

As-Is(現状)

To-Be(新規)業務フロー図

 

システム要件・納品対象

システム化対象を明文化した文書、納品物一覧など

 

機能要件

画面・帳票・バッチ・データ・

外部インターフェース要件など

 

非機能要件

可用性、性能・拡張性、運用・

保守性、移行性、セキュリティなど

 

総合・受け入れテスト設計図

テスト計画書・仕様書・設計書など

 

WBS

(Work Breakdown Structure)

システム開発プロジェクトの

開発工程構成図

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

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

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

システム要件

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

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

機能要件

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

非機能要件

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

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

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

WBS(Work Breakdown Structure)

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

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

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

受け入れテスト設計書

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

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

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

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

基本設計の成果物

成果物の中身

概要

基本設計書

システム設計

ハードウェア・ソフトウェア・

ネットワーク構成図、

システム機能構成図など

 

画面設計

画面一覧、レイアウト・遷移図、

入出力項目、アクション定義図など

 

帳票設計

帳票一覧、レイアウト、

入出力項目、編集定義図など

 

バッチ設計

バッチ処理一覧、処理フロー図、

定義書など

 

データベース設計

テーブル・ファイル一覧、ER図

テーブル・ファイル定義、CRUD図

 

ファイル設計

ファイル一覧、レイアウト図など

 

外部インターフェース設計

外部インターフェース一覧、

レイアウト図など

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

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

システム設計

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

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

機能設計

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

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

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

詳細設計の成果物

成果物の内容

概要

詳細設計書

クラス図

システムを構成するクラスの

関係を示す静的な資料

 

モジュール構成図

各機能の処理に必要な処理を

モジュールごとに示す静的な資料

 

アクティビティ図

ユーザー操作・システム処理の

流れがわかる動的な資料

 

シーケンス図

クラス・オブジェクト間のやり取りを

時間軸に沿って表した動的資料

 

IPO(処理機能記述)

入力・処理・出力の流れを表した

動的資料。バッチ処理など

 

開発方針・ルール

ライブラリ・アルゴリズムの指定、記述ルール書など

 

単体・結合テスト設計

単体・結合テストの計画書・

仕様書・設計書など

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

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

開発方針・ルール

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

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

単体・結合テスト設計書

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

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

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

単体・結合・総合テストの成果物

概要

単体テスト実施報告書

テスト結果をチームで共有し、必要に応じて修正

結合テスト実施報告書

テスト結果をチームで共有し、必要に応じて修正

総合テスト実施報告書

確認・評価・負荷・性能テストの結果を網羅的に記載

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

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

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

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

【無料】システム開発の依頼について相談する

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

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

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

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

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

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

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

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

Q. システム開発の流れは?

システム開発の流れは「?見積もり」「?契約」「?要件定義」「?基本設計」」です。それぞれの詳しい内容は記事内で紹介していますので、ぜひご覧ください。

Q. システム開発の成果物・ドキュメントにおける注意点は?

システム開発の成果物・ドキュメントにおける注意点は必要な成果物は納品物として指定することを忘れないことです。詳しくは記事をご覧ください。