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

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

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

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

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

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

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

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

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

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

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

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

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

成果物と納品物の違い

成果物は、各工程を進める中で制作されるものや内容を説明するために作られるドキュメント類のことです。設計書や工程の管理に使用した管理表、報告書、システムのソースコードなど各工程を進める上で使用したもの・できたものすべてが成果物にあたります。

システム開発における納品物とは、納品される成果物（システムそのものやマニュアルなど）を指します。そのため、納品物も成果物の一部といえます。

システム開発の工程で作成したものすべてを成果物、その成果物の中でクライアントに納品するものだけが納品物とイメージするとわかりやすいかもしれません。

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

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

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

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

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

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

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

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

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

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

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

提案書・見積書

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

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

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

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

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

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

システム要件

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

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

機能要件

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

非機能要件

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

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

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

WBS（Work Breakdown Structure）

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

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

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

受け入れテスト設計書

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

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

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

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

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

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

システム設計

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

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

機能設計

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

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

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

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

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

開発方針・ルール

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

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

単体・結合テスト設計書

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

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

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

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

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

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

※無料でダウンロードできる中小企業向けシステム開発の進め方をご用意しています。こちらもあわせてご活用ください。

システム開発依頼前にチェック！ 中小企業向けシステム開発の進め方をまとめました。
無料でダウンロードする

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

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

開発中に各種成果物を受け取るメリット

システム開発で成果物を受け取るメリットは、主に以下の4つです。

以下で各項目の詳細を解説します。

開発にかかわる工程の進捗を確認しやすい

工程ごとにできる成果物を受け取ることで、進捗状況を具体的に確認できます。工程が進むごとに成果物が増えていくので、社内のシステム開発の知識がない方に進捗状況を説明する場合にも資料として役立つでしょう。

また、意図したものと違う機能やモジュールを開発していたり、必要な機能が抜けていたりした際に早期発見しやすくなる効果にも期待できます。

開発会社との間に認識の違いがないか確認できる

工程ごとに成果物を確認することで、要求している通りのシステムを開発してもらえているかを確認しやすくなります。

システム開発に詳しい人材が自社に居ない場合は、最初に作成した書類上の情報だけでは具体的なイメージが難しいため、認識のズレが発生しがちです。提出された成果物を工程ごとに確認することで、必要な機能がなかったり、要求と違う機能を開発してしまったりした場合でも早めに気付く効果に期待できます。

工程ごとに品質を確認しやすい

工程ごとに成果物を受け取ることで、開発の品質に問題がないか工程ごとにわけてチェックしやすくなります。工程ごとの成果物を受け取らない場合、トラブルが発生した際にどの工程で問題があったのかがわかりにくくなってしまいがちなので注意が必要です。

開発するシステムの品質をあげるためにも工程ごとに開発の品質をチェックして、不安があれば次の工程に行く前に確認しましょう。

保守・運用や修正時の資料になる

システム開発の際に受け取った成果物は、保守や運用、システムの修正をする際の資料として役立ちます。受け取っていない成果物があると、システム開発の外注に関わった人が退職した場合にシステムの内容を説明できる人が居なくなってしまいます。

また、将来ほかの会社にシステムを改修してもらおうと考えたときに、開発時に作成した設計書や仕様書などのドキュメント類を要求されることがあります。そのため、システム開発の過程で制作した成果物もきちんと受け取って、必要なときに確認できるように管理することが大切です。

開発中に各種成果物を受け取るデメリット

システム開発で成果物を受け取るデメリットは、主に以下の3つです。

以下で各項目の詳細を解説します。

専門用語が多いと読み解く手間がかかる

システム開発に携わる技術者が成果物を作成するため、システム開発の知識がないと読みにくいドキュメントになっていることがあります。そのような場合に、開発会社の担当者に説明をしてもらったり、自分で読むための知識をつけたりする手間が発生してしまいます。

成果物の提出が遅いことがある

システム開発の納期が短かったり、開発会社の人的リソースがギリギリだったりする場合は、成果物の提出が遅くなってしまうことがあります。開発が予定より遅れている場合は、無くても開発作業を進められる説明用のドキュメント類の作成が後回しになってしまうケースもあるでしょう。

そのため、成果物の提出が遅れてしまい、成果物から間違いや認識のズレを見つけても実際の工程が進んでしまっていることがあります。そうなると成果物による確認作業があまり意味のないものになってしまうかもしれません。

また、ドキュメント類の作成自体にも工数がかかるため、他の作業のリソースを奪ってしまう可能性があることも頭に入れておきましょう。

変更があった場合に管理の手間がかかる

システム開発の途中で仕様変更があったり修正があったりすると、仕様書や設計書などのドキュメント類も修正や作り直しをしなければなりません。

作り直して再度受け取った場合には、同じような成果物がいくつもできてしまうことになります。そのため、どの成果物が最新のものかがすぐにわかるように管理する手間が発生します。管理がずさんだと、ほかの関係者が古いドキュメントを確認してしまってトラブルになることもあるでしょう。

同じような成果物が複数ある場合は、どれが最新のドキュメントかを関係者に共有するようにしましょう。

システム開発で成果物を管理する際のポイント5つ

成果物を管理する際のポイントは主に以下の5つです。

以下で各ポイントの詳細を解説します。

必要な成果物をリストにまとめる

システム開発のプロジェクトで受け取る成果物を工程ごとにわけてリストアップすると管理しやすくなります。

また、工程ごとに管理していればプロジェクト全体のうちのどのあたりまで開発が進んでいるのかがわかりやすくなる点もメリットです。

各成果物の詳細を確認する

各工程で重要な成果物がどれかやその成果物の目的、内容などをきちんと確認しながら管理しましょう。

成果物の内容をきちんと把握せずにただ受け取って保管するだけにしてしまうと、開発している内容に間違いがあっても見過ごしてしまうかもしれません。どの成果物が何を確認するためのものかを把握して、ただしく開発工程が進んでいるかを確認することが大切です。

どのように管理するかを決める

成果物を誰がどのように管理するかを決めましょう。管理をするためのルールが定められていないと、関係者がそれぞれ勝手に操作をしてしまい、トラブルの原因になってしまいます。例えば、ファイル名の付け方がバラバラでどれが最新のファイルかわからなくなってしまうケースが考えられます。

最低限、ファイル名の決め方に関する規則（命名規則）や保存場所、管理表の更新、バージョン管理などのルールは作成しておきましょう。

成果物を社内で共有できる体制にする

成果物は、社内で共有できる体制にしましょう。最低でも開発プロジェクトにかかわるメンバーには共有しないと、プロジェクトの円滑な進行ができないおそれがあります。

例えば、受け取った成果物が修正されていることを知らずに古い情報を参照し、誤った内容の資料を作成してしまうかもしれません。

システム開発プロジェクトの関係者が常に最新の情報を確認できるように共有しておきましょう。

成果物の管理体制を修正・改善する

成果物を管理する中で問題があった点や改善できる点があれば、修正・改善をしましょう。次回以降のシステム開発をスムーズにできます。

また、特に問題が発生していなくても開発終了後に振り返って良かった点や悪かった点、改善できる点を振り返ることも大切です。振り返った内容をまとめて共有することで、システム開発やシステム開発の外注に関するノウハウを自社に蓄積できます。

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

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

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

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

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

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

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

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