システム開発の成果物とは？押さえておきたい開発工程の流れとドキュメント

システム開発では、各工程でさまざまなドキュメントが作成され、成果物の授受が行われます。ドキュメントとは、提案依頼書・要件定義書・基本設計書などの資料のこと。

プロジェクトを円滑に進めるためには、各工程でどのようなドキュメントが作成され、生活物として納品されるのか把握しておく必要があります。

今回は、システム開発の各工程における「成果物」「ドキュメント」について開発工程の流れとともに解説します。

関連記事：【開発前チェックリスト付】ソフトウエア・アプリ開発におけるMVP開発ガイドブック

1.システム開発における成果物とは？

システム開発における「成果物」とは、開発の各工程で作成される書類やドキュメントのことです。

システム開発の工程、特にWebシステムの開発工程は多岐にわたります。Webシステムはインターネットを通じて多様な端末で利用することが可能なため、あらゆるケースを想定する必要があるのです。

「成果物」という言葉から最終的な納品物を思い浮かべるかもしれませんが、開発途中の段階でも様々な成果物が発生します。

1-1.一般的な成果物とシステム開発における成果物

一般的な成果物とは、作業やプロジェクトを達成した結果、アウトプットとして出来上がるものを指すことが多いでしょう。

しかし、システム開発やWebシステム開発における成果物は、開発の各工程における一部または全部の作業が完了した際の完成したプログラム、システムの仕様書・仕様方法をまとめた資料や説明書ドキュメント（仕様書・設計書）のことを指します。

システム開発では、開発の各工程、場合によっては各タスクで成果物がでてくることもあります。

関連記事:ソフトウェア開発の流れとは？ソフトウェア開発の手法も解説

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

「成果物」と似た言葉に「納品物」がありますが、これらは同一ではありません。

納品物とは、クライアントに納品する全てのものを指します。納品物は最終成果物と考える方も多いと思いますが、そうではありません。

例えば、はじめに作成する設計書なども顧客から納品を求められた場合は「納品物」として扱われることになります。

つまり、中間成果物も、受領物もクライアントから求められて納める成果物は全て「納品物」です。

一方で、成果物はプロジェクトの成果や証拠に該当するもの全般。「最終成果物」「中間成果物」「受領物」の3つに分類できます。

最終成果物とは、プロジェクトで最終的に目指すもの。中間成果物は、最終成果物をつくる過程でできる成果物です。

1-3.成果物・ドキュメントが必要な理由

システム開発のドキュメントの種類には「要件定義書」「詳細設計書」「運用マニュアル」などがあります。これらの文書はシステム開発の工程ごとに必要です。

なぜ、各開発工程に必要となるのでしょうか。

・クライアントとのコミュニケーションのため

成果物・ドキュメントを作成し共有することで、クライアントと円滑な情報共有やコミュニケーションが可能です。

開発を開始する前に、要件定義の段階でシステム開発の詳細を詰めますが、ここで決まった内容を明確に文書に残すことは、後々のトラブル防止にも役立ちます。変更が生じる度に、随時更新して記録を残します。

・工程間のひきつぎのため

開発現場では、開発の最初から最後まで同じ人、あるいは一人の人がシステム構築をすることはまずありません。設計・構築、テスト・検証などそれぞれのフェーズに合わせて適材適所、人材を配置して作業にあたります。

そこで、各工程間での作業の引き継ぎが円滑に行われるためにも、ドキュメントがしっかり作られていることが大切なのです。

・保守・運用のため

システムは、正しく運用されてこそ。しかし、長く運用する間には、担当者が変更になったり、会社を去ることもあるでしょう。

その際、システムの各工程の流れや経緯がドキュメントとして残っていると、全体の流れ、これまでの経緯を把握しやすくなります。

ドキュメントがない場合は、システムの内容から全て見直す必要が生じ、メンテナンスや運用に膨大なコストがかかることになるでしょう。

関連記事：新規事業開発のプロセスとは？5つのステップと３つの成功事例

２.システムの開発工程と成果物

システム開発・Webシステム開発の工程は大きく分けて次の4つです。

①要件定義→②設計→③プログラミング→④テスト

各工程の詳細と一般的な成果物を下記にまとめました。

各工程における成果物について具体的にみていきましょう。

2-1.開発工程①：要件定義

クライアントとシステム開発の開発者側で話し合い、開発するシステムの詳細を決めていく工程です。実際に必要な機能や機能以外のスペック・システムで、できること・できないことなど要件定義の段階で詰めていきます。

業務フローとは、業務の流れを図式化したもの。現状業務を整理したものと、実際にシステムが導入された後の業務フローを要件定義工程で作成。

これを示すことで、システムを導入することによる業務効率化、作業工数の低減など明確に示されます。

要件定義ではシステムの機能だけでなく、予算や人員管理などについても話し合うことがポイント。システム開発プロジェクト全体にも関わってくる部分なので、細かいところまで詰めておくとよいでしょう。

また、着目すべきは非機能要件。非機能要件とは、実装すべき要件機能以外のすべての要件のこと。たとえば、システムが実現すべき処理能力や将来的に機能追加するための拡張性、外部脅威に対するセキュリティなどがそれにあたります。

2-2.開発工程②：設計

要件定義で定めた詳細を元に、設計に落とし込んでいく工程です。設計内容により、仕様書・図・設計書などさまざまなものに細かく分かれます。

下記に一例をあげていますが、プロジェクトの内容やクライアントにより求められる成果物は異なります。

システム開発側で基本設計書を作成し、クライアントに確認しながら詳細を固めていきます。

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

2-3.開発工程③：プログラミング

設計工程で作成した仕様書・設計書に従って、いよいよ機能をプログラムで構築していくフェーズです。システムを機能ごとに詳細に分割し、複数人で手分けして構築するスタイルが一般的です。

プログラムの開発・実装フェーズでは、複数のプログラマーが分割された個々のモジュール開発を担当。

大切なのは誰が見ても分かりやすいものを作ること。見やすさや統一感のある関数を使うなど、一定の規約をつくることもポイントです。

2-4.開発工程④：テスト

テスト工程は、主に単体テスト・結合テスト・システムテスト・運用テストの4つ。

要件定義どおりに動作するかをチェックするため、モジュールごとに単体テストを行います。単体テストをクリアすると、結合テストにより複数のプログラムが連動するかをチェックします。

さらに、システムテストで全てのプログラムが機能するかを確認していきます。

リリースに向けて完成を目指す段階です。耐久性、実際の処理速度等、全体のクオリティを細かくチェックしていきます。

最終的な運用テストでは、開発したシステムが実際の環境下で要件定義通りに正しく動くか否かを確認します。

問題がなければ、リリースへと進みます。

関連記事：新規事業開発を成功に導く2つの手法リーン開発・アジャイル開発とは？

3.システム開発における成果物のメリット・デメリット

各工程における成果物について見てきましたが、成果物を定めることのメリット・デメリットは何でしょうか？

3-1.システム開発成果物3つのメリット

①工程の進捗・作成内容の共有

開発者側とクライアント双方における認識の統一ができます。

進捗に応じた成果物があることで、作業の進捗を具体的な数値として捉えやすくなる面もあります。

また、各工程で成果物ができあがると、これまでに決定した要件・仕様について、実際の成果物を確認しながらプロジェクトを進められます。

万が一、成果物が思ったような状態のものでなかった場合も、早い段階で認識の違いを確認でき、クライアントと開発側で意思疎通を測れるでしょう。

②モチベーションを保てる

プロジェクトが始まる段階で各工程のおよそのスケジュールを立てます。予定通りに進めるための各種タスクの完了は、成果物という目に見える形だと期限が明確です。タスクごとのゴールがわかりやすいと、クライアントと開発側双方が途中で目的を見失うことなく、モチベーションを保ちながら進められます。

③システム開発の抜け漏れ防止

各工程で成果物が定まっていることで、工程あるいはシステム全体の要件定義や設計など全体を俯瞰できます。全体像が把握できると、抜け漏れに気づきやすくなり、結果として早い段階で細かく行き届いた対応ができるのです。

④進捗の明確化による柔軟な対応

各タスク完了後に成果物を定めておくと、成果物の状態で作業の進捗や品質がわかりやすくなります。

例えば、工程の途中でも完了した成果物をチェックできれば、単純な作成完了による進捗と品質の両面から現状を把握できます。早い段階で、万が一に備えたトラブルの予見・回避が可能です。

⑤各工程の品質確保

各工程のタスクを成果物という形に定めることで、タスク内で実施すべきことや実施内容がある一定のレベルに保たれます。

成果物がひとつの目安となり、品質を担保されたアウトプット・タスクの実施を行いやすくなるのです。

3-2.システム開発成果物3つのデメリット

①わかりやすい書類作成の壁

誰にでもわかりやすいドキュメントを作成するのは、簡単なようで意外に難しいもの。開発に関わる技術者の文章は、専門用語が多くなりがちで内容がつかみにくく難解な傾向があります。

また、作業工程ごとにフォーマットが異なっていたり、記述方式が統一されていないこともあるでしょう。

②変更・修正への対応が煩雑

各工程でドキュメントを作成するため、変更が行われた際に、それぞれに修正を反映する必要があります。修正もれがないように注意するとともに、各工程の担当者への情報共有も必須です。最新のドキュメントの周知なども抜け漏れのないようにしなくてはなりません。

③改定と現状のズレ

開発そのものがタイトなスケジュールで行われるケースも少なくありません。システムリリースにあたり、実際の業務優先となった場合、改定が後回しになることも。

するとドキュメントの整備が遅れ、システムの実際の運用とのズレが生じることにつながり、ドキュメントの意味がなくなってしまいます。

これらのデメリットを解消する方法の1つとして、システム開発そのものをアウトソーシングするという手段もあります。

社内で行っている業務を外部の業者に委託するのがアウトソーシングですが、システム開発では「システム開発ほぼ全ての工程を外注」「運用のみ外注」「委託を受けた企業へスタッフが常駐する」などの方法があります。

システム開発をアウトソーシングするメリットは主に次の3つ。

・人材採用・教育等の時間やコスト削減

・人件費の節約

・エンジニアが本来の業務に専念できる

ただし、アウトソーシングすることで「ノウハウや知見が蓄積されない」「情報漏洩のリスク」というデメリットがあることも頭に入れておきましょう。

DeFactoryでは、Webシステム開発における要件定義までであれば最短5営業日で、要件定義〜テストまでのサイクルであれば最短14営業日で行なうことが可能です。経験豊富なエンジニアとマネージャーが支援しますので、システム開発・新規事業開発に不安のある方も安心してお任せいただけます。

問い合わせページから資料請求や無料相談などの申し込みが可能ですので、Webシステム開発や事業立ち上げをご検討中のご担当者様はぜひお気軽にお問い合わせください。

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

今回は、システム開発・Webシステム開発における成果物について、一般的な開発工程ごとにご紹介しました。

システム開発の成果物・納品物の定義は、要件定義の段階で決められることが多いもの。今回ご紹介した成果物のすべてが納品物とは限りません。

クライアントがどんな成果物を望んでいるのか、求めている物は何かをプロジェクト開始時にしっかり話し合って明確にしておきましょう。

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

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

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

【DeFactoryの3つの特徴】
・最短14営業日程度で納品
・事業構築力、スピード、高品質を実現する体制
・キャンペーンにより事業構想フォローを無料実施