システム開発の納品物とは？成果物との違い・工程別一覧・注意点を解説

システム開発における納品物は、プロジェクトの成果を確認するために重要なドキュメントです。

各工程の納品物を明確にしておけば、プロジェクトのゴールや進捗を把握しやすくなる上、発注側と開発側の”ズレ”を解消しやすいというメリットがあります。

今回の記事では、システム開発の納品物の概要、成果物との違いを紹介します。

さらに、工程別の納品物一覧や、納品物を管理する際の注意点なども解説するので、ぜひ参考にしてみてください。

関連記事：システム開発の工程（流れ）とは？主な開発手法や手順の基礎知識│専門用語のまとめ 

1.システム開発の納品物は「顧客に納品するもの全て」を指す

そもそもシステム開発における納品物とは、「顧客に納品するもの全て」のことです。

ただし、発注するクライアント、開発会社が共に満足のいくクオリティの納品物へと仕上げるには、お互いの密接なコミュニケーションが重要となります。

例えば、要求定義の段階で必要となる「提案依頼書（RFP）」は、一般的に発注側のクライアントが作成しなければなりません。

開発会社任せにするのではなく、発注側のクライアントが管理すべきポイントを押さえながらプロジェクトを進行させることで、より高いクオリティの納品物が期待できるでしょう。

ここからは、納品物と成果物の違いや、Webシステムにおける仕様書の重要性について紹介します。

1-1.納品物と成果物の違いとは

納品物と混同されやすい言葉の一つが「成果物」ですが、両者には違いがあります。

というのも、納品物が「顧客に納品するもの全て」を指すのに対し、成果物は「プロジェクトの成果、もしくは証拠に当てはまるもの」を指しているためです。

成果物の種類は、主に以下3つに分類できます。

・中間成果物

・最終成果物

・受領物

中間成果物とは、”最終成果物を制作する過程で生まれる成果物”のことです。

一方、最終成果物は、”プロジェクトとして最終的に制作を目指している成果物”のことを指します。

なお、最終成果物に関しては、プロジェクト完了後も必要に応じて参照・更新されます。

しかし、一般的に中間成果物は、プロジェクト完了後に参照されることはありません。

また、プロジェクト達成にあたり、”クライアントなどから貸与・支給された成果物”のことを受領物といいます。

このように、成果物は目的別に定義づけることが可能であり、納品物にはこれらの成果物全てが含まれています。

1-2.Webシステムは仕様書が重要

Webシステムにおける仕様書は、”Webシステムとして到達すべき要求”が網羅されていることが特徴です。

つまり、最終成果物（ゴール）として在るべき姿が示されているという点で、仕様書は重要なドキュメントといえるでしょう。

また、Webシステムの開発を進めるうえで、開発に携わるスタッフ・ステークホルダーと仕様書を共有することは大切なポイントです。

なぜかというと、明確なゴールが示された仕様書を共有することで、プロジェクト工程全体の”認識のズレ”を解消し、誤りのないプロジェクトを進行しやすくなるためです。

2.【工程別】システム開発の納品物一覧

続いて、システム開発における納品物を一覧で見ていきましょう。

なお、今回は上流工程から順番に開発を進める”ウォーターフォール開発”に則った納品物をご紹介します。

ちなみにウォーターフォール開発とは、「要件定義→設計→開発」など、複数の工程を段階的に進めていく開発手法のことです。

工程ごとに分担して開発を進められる点はメリットですが、前工程の成果物に問題があると、後工程での“戻り作業”が発生する可能性もあります。

それに対し、仕様変更へ柔軟に対応できる開発手法を“アジャイル開発”と呼び、開発工程を小さな単位ごとに繰り返し実行する点が特徴です。

一般的に、ウォーターフォール開発は大規模な開発で用いられ、アジャイル開発は小規模な開発で用いられる傾向にあります。

上記のようなウォーターフォール開発の特徴も踏まえた上で、ぜひ以下の内容を参考にしてみてください。

2-1.企画・要求定義

この工程における企画とは、業務課題の解決にむけて発足された”システム開発のプロジェクトそのもの”を指しています。

要求定義の作業では、企画に基づいた上で、システム開発としての具体的な要求へまとめていきます。

なお先述したように、要求定義のインプットで用いる「提案依頼書（RFP）」は、基本的にクライアント側が作成します。

提案依頼書には、以下のような内容が含まれます。

・システムへの要求・ニーズ

・依頼する範囲

・予算・納期

・自社の体制・役割

・提案依頼事項など

なお、上記に挙げた提案依頼書の内容をまとめる際は、受注側と発注側の双方がどのスコープ（範囲）を対応するのか、明確に定義づけておくことが大切です。

というのも、プロジェクトを成功へ導くには、受注側と発注側における目標・認識をしっかりと共有しておく必要があるためです。

それぞれが対応するスコープを曖昧な状態にしていたり、企画・要求定義の段階での詰めが甘かったりすると、後工程でのトラブルや開発工数がかさむ原因にもなり得るため注意しましょう。

開発会社は、提案依頼書の内容をもとに提案書を作成し、概算見積書と共にクライアントへ提出するのが一般的です。

関連記事：アジャイル開発とは？メリット・デメリットやプロセス手法も合わせて解説！ 

2-2.要件定義

次に、要件定義の工程では、インプットに要求定義を使用した上で”要件定義書”を作成します。

要件定義書は、システム開発を請け負う会社側が制作します。システムを使って実現する業務を決めたり、システムとして可・不可の機能を決めたりするため、システム開発における方向性を定める重要な工程といえるでしょう。

場合によっては、システム開発に必要な納期や予算のバランスを考慮し、クライアント側の要求を全て盛り込むのが難しいこともあります。

そのため、お互いに満足のいく要件定義へと仕上げるには、密なコミュニケーションを取りながら、妥結点を見出すことが大切です。

なお、要件定義書には以下のような内容が含まれます。

上記の中でも、システム要件は、システム開発の方向性を決める重要な成果物となります。

というのも、システム要件では”システム化するもの／しないもの”に関する選別を行なうためです。あらかじめクライアント側が優先順位を決めておくことで、より満足度の高いプロジェクトを実現しやすくなるでしょう。

2-3.基本・詳細設計

まず、基本設計の工程では、要件定義書をもとに「システム設計」や「機能設計」などの”基本設計書”を作成します。

基本設計書の主な内訳は、以下となります。

一般的に、クライアント側が開発工程に関われるのは、基本設計工程までとされています。

そのため、基本設計書に対して”認識のズレ”がある場合は、クライアント側がしっかりとフィードバックして修正を促すことが大切なポイントです。

次に、詳細設計の工程では、上記の基本設計書をもとに、プログラマーに対する指示書である”詳細設計書”を作成します。

詳細設計書の主な内訳は、以下となります。

実際にプログラムの開発・実装を行なう際は、複数のプログラマーがそれぞれのモジュール開発を担当するのが一般的です。

その後、「モジュール→サブシステム結合→システム構築」のステップを踏むため、詳細設計工程の段階で「単体・結合テスト設計」が行なわれる流れになっています。

2-4.各種テスト

仕様書、設計書に沿ってプログラムを構築後、要件定義を満たしたプログラム動作が可能か確かめるために、各種テストを実施します。

プロジェクトによってテストの実施単位は異なりますが、テストに関わる一般的な成果物は以下の3つです。

・単体テスト実施報告書

・結合テスト実施報告書

・総合テスト実施報告書

単体、結合テスト工程の結果によっては、開発・実装工程にさかのぼった上で、プログラムの修正が必要となります。

また、総合テストは”システムテスト”とも呼ばれ、要件定義に沿ったシステム開発が実現できているか確認するために重要な工程です。

総合テストの主な内訳は、以下となります。

・確認テスト：プログラムの挙動や連携を確認する

・評価テスト：セキュリティや障害時の耐性などを評価する

・負荷テスト：大きな負荷をかけてもパフォーマンス・耐久性に問題ないか確認する

このように、各種テストを実施した成果物として”実施報告書”がまとめられます。

関連記事：システム開発の結合テストとは？実施する手法や方式＆ポイント3選を解説

3.システム開発の納品物管理における注意点とは

ここからは、システム開発の納品物を管理する際に、注意しておきたいポイントを2つ紹介します。

3-1.納品物管理のルールを決めておく

まず1つ目の注意点は、納品物管理のルールを決めておくというものです。

納品物は、”プロジェクトの成果を証明するもの”であるため、事前にしっかりとしたルールを取り決めておくことが大切です。

ルールの例としては、以下の項目が挙げられます。

・バージョンの管理方法

・フォルダの名付けルール

・データのフォーマットなど

・文字や図に関する表記の統一

特に、「文字や図に関する表記の統一」に関しては、先述したWebシステムにおける仕様書と同様、認識のズレを招かないために重要なポイントです。

万が一、同じプロジェクト内で“表記のゆれ”が発生してしまうと、認識違いによってシステム開発の作業が滞るばかりか、作業の後戻りへ繋がるおそれもあります。

例えば、ソースコード（プログラミング言語を用いたプログラムの設計図）の中に「追加」と「新規作成」の表記が混在していた場合は、どうなるでしょうか。

その場合、記述したメンバー自身は違いを把握できても、他のメンバーには正しく伝わらない可能性が高いといえます。

そのため、後工程でのトラブルなどを防ぐためにも、プロジェクトメンバー全員が共有できるルールをしっかり決めておくことが大切なのです。

ルールの策定・変更を行なった際は、メンバー間でしっかりと共有するようにしましょう。

3-2.最終成果物を明確にしておく

2つ目の注意点は、最終成果物を明確にしておくことです。

というのも、最終成果物を明確にすることで、プロジェクトにおける目的をはっきりと可視化できるためです。

また、最終成果物をしっかりと定義するには、おのずと各工程で発生する成果物を定義づけることも必要となります。

成果物を明確にすることで、以下のようなメリットが期待できます。

・クライアント・開発会社間で、工程進捗や制作内容を共有できる

・システム開発の抜け漏れを防ぎやすい

・アウトプットの品質を一定に保てる

特に、工程進捗や制作内容が共有しやすくなるという点は重要です。なぜなら、クライアントと開発会社間における”擦り合わせ”がスムーズにできることで、最終成果物の品質も担保しやすくなるためです。

とはいえ、システム開発における要件・ニーズを満たした上で、迅速にプロジェクトを遂行するには、経験豊富な外部のサポートが必要なケースも少なくありません。

経験豊富なエンジニアと事業開発者を有しているDeFactoryであれば、システム開発全体の伴走が可能です。

スムーズなシステム開発を実現したいという方は、ぜひ一度ご相談ください。

4.まとめ：「システム開発」に関する支援を承ります

システム開発における納品物は、「顧客に納品するもの全て」を指すため、成果物とは違いがあります。

また、成果物としては「提案書」や「要件定義書」、「基本設計書」など工程ごとにさまざまな種類があります。

特に、各種テスト検証後の「実施報告書」は、要件定義に沿った機能を持っているか確認した証にもなるため、重要な納品物といえるでしょう。

DeFactoryでは、アイディア着想、ユーザーヒアリング、テストマーケティング、アジャイル・MVP開発と、プロダクト開発における立ち上げ支援を全力サポートいたします。

また、経験豊富なエンジニアと事業開発経験者で、開発だけでなく事業設計から「一気通貫」した伴走を行ないます。

事業開発や立ち上げを検討しているご担当者様がいましたら、問い合わせページから資料請求や無料相談などお気軽にご連絡くださいませ。

【DeFactoryの3つの特徴】

・最短14営業日程度で納品

・事業構築力、スピード、高品質を実現する体制

・キャンペーンにより事業構想フォローを無料実施