システム開発における成果物とは?要件定義をはじめとした各工程ごとの具体的例

更新日:2020年10月20日 発注カテゴリ: Web制作会社・システム開発会社
システム開発における成果物とは?要件定義をはじめとした各工程ごとの具体的例

業務効率化のためシステム導入を検討、しかしパッケージ製品は業務とミスマッチ。そんな時は業務に合わせたシステムの受託開発を検討するでしょう。システムの受託開発を依頼する際にきちんと決めておきたいのが、各工程の成果物です。「システム開発だからシステムが成果物」で基本的には間違っていません。しかし、最終的なアウトプットであるシステムだけを成果物とした場合、各工程での状況がわからず、中身の不明なシステムが納品されるかもしれません。そんな事態を避けるべく、各工程において成果物を定め、納品/検収後、次工程に進むルールとするのが一般的です。システムにおける成果物の定義と具体例を本記事では解説していきます。

関連する記事

成果物とは

成果物という言葉はもともとあったのですが、現在ではシステム開発のプロジェクトにおいて使うことが多く、意味も変化しているようです。その定義を確認していきましょう。

世間一般における成果物

言葉の通り、作業やプロジェクトを実施した結果、「成果(アウトプット)」として出来上がった「もの」を広く指す言葉でした。特にシステムに関わらずとも、何らかの作業のアウトプットのことを示しています。例:写生においての成果物は絵

システム開発における成果物

昨今、成果物といった際によく使われるのがシステム開発やソフトウェア開発における成果物です。意味はそのままで、システム開発の各工程において一部または全部の作業や工程が完了した際に完成したプログラム、ドキュメント(仕様書、設計書)などを示します。

一般的な広い意味での成果物との違いは、システム開発の各工程において成果物が発生することです。その工程の分け方については次節で説明しますが、プロジェクト全体が完成せずとも、工程として分けられた単位で成果物は逐次発生します。さらに分解していえば、各タスクに対して成果物が出てくると認識しても良いでしょう。

システム開発の工程とは

システム開発は工程を分けて進められます。システム開発全体は、大きくは下記の4工程に分けることができます。

(1)要件定義

システムを利用して実現する業務、業務内でシステムを使って実現すること、実行可能な機能など、システムのできること/できないことを決める工程です。システム全体の輪郭を決める作業とも言え、クライアントとベンダーが参加して進めることが多い工程です。業務を整理、分析して改善を図るため、業務フローなどのドキュメント作成も発生します。

詳しくは、下記の記事でも解説しているのでご参照ください。

(2)設計

要件定義で決めたシステム仕様を、実際にIT技術を用いて構築するために、設計に落とし込む工程です。設計の粒度により出来てくる仕様書、設計書は変わってきます。設計は基本設計、詳細設計といた工程ごとの設計レベルやUI設計、DB設計など対象とする技術ごとの設計書に分けることも多く、ITベンダーなどによって変わります。

(3)プログラミング

設計工程で作った仕様書、設計書にしたがって機能をプログラムで構築する工程です。多くのシステム開発では、システムを機能ごと、またはさらに詳細に分割して、複数人で手分けして構築します。

(4)テスト

プログラミング工程で作成されたプログラムの動作を試験します。設計書、仕様書の通りに動作するか、要件定義で決めた機能が実現されているかを確認していきます。テストについても、プログラミングテスト、結合テスト、システムテスト、運用テストなど種類がありますが、プロジェクトにより実施単位は様々です。

各工程の一般的な進め方は下記の通りです。

  • (1)実施が必要な作業を洗い出す
  • (2)WBS(※)としてドキュメント化
  • (3)WBSの各タスクの成果物設定、スケジューリングを行う。
  • (4)成果物の完成を持ってタスク完了
  • (5)全タスクが完了後、工程完了の判定を実施。問題が無ければ次工程へ進む

※WBS:Work Breakdown Structure。各工程を各担当者の作業レベルまで分解し、一覧化したもの。

成果物と納品物の違いは?

成果物、納品物という言葉の対象はそれぞれのプロジェクトで定義するべきものです。WBSで作業レベルまで落とし込み、そのタスクのアウトプットに定めるものが成果物です。納品物は契約上、各工程の完了時にクライアントに納品すると定めた物になります。

納品物は成果物で構成されるのですが、契約の時点では全ての成果物が洗い出せていないことが多く、概ね納品物は各工程で作られる重要度の高いドキュメントを指定します。成果物の洗い出し完了後、重要なドキュメントが納品物に含まれていないことが判明した場合、クライアントとITベンダー間で話し合い、納品物に追加すると良いでしょう。

反対に成果物の中には、開発の内部資料にあたるような納品する必要のないものもあります。その納品要否は、契約時および各工程での成果物を決める際にクライアントとITベンダー間で話し合って、適宜決定します。

成果物を明確にするメリット

成果物を定めることによりシステム開発の各工程では様々なメリットが生まれます。そのメリットを確認していきましょう。

クライアント、ベンダー間で工程の進捗、作成した内容が共有できる

成果物を定めることで、作業の進捗を具体的な数値として数えやすくすることができます。進捗を数値化することによりクライアント、ベンダーどちらの側からでも進捗状況を可視化することができます。また、成果物が各工程で出来ていくことにより、これまでに決めた要件、仕様を、成果物で確認しながらプロジェクトを進めることができます。成果物に差異があれば、早い段階で認識のずれを指摘することで、クライアント、ベンダー間の認識の共有が図れます。

各タスクのゴールが定まることで、モチベーションを保って作業ができる

クライアント、ベンダーともにスケジューリングされたタスクに対し、成果物が決まることでやらなくてはいけないこととその期限が明確になります。タスクごとにゴールができるため、進む先が見え、モチベーションを高く維持しながら作業できます。

俯瞰してみた場合に、システム開発の抜け漏れが分かりやすくなる

タスクを洗い出し、その成果物を定めることで、工程またはシステム全体の要件定義、設計、開発対象を俯瞰して見やすくなります。全体が見定められることで、抜け漏れに気が付きやすくなり、きめの細かい対応を早い段階で実施することができます。

きちんとしたアウトプットを定めることで、各工程での品質が保てる

各タスクのアウトプットとして成果物を定めることで、タスク内で実施しないといけないこととその実施レベルが一定以上に定まります。これを定めることにより、品質の担保されたアウトプット、およびタスクの実施が期待できることとなります。

プロジェクトの進捗が明らかになり、柔軟な対応が可能となる

成果物を定め、各タスクの完了後に出てくる成果物をチェックすることで作業の完了率とその品質の把握がしやすくなります。例えば工程の途中でも作成完了した成果物を抽出チェックすることで、単純な作成完了による進捗と品質を加味した状況のチェックができ、早い段階でのトラブルのケアが可能になります。

成果物の種類

開発の工程と成果物の代表的なものを例としてあげます。各機能や設計については全体像を見やすくするため一覧化を行い、そのドキュメントも作成しますが、下記の表からは除外しています。

No. 工程 成果物 成果物詳細
1-1 要件定義 要件定義書 現状業務の業務フロー
1-2 システム化後の業務フロー
1-3 システム化範囲を定義
1-4 業務機能一覧
1-5 システム化機能概要
1-6 画面イメージと項目説明
1-7 帳票イメージと項目説明
1-8 バッチ機能概要
1-9 外部連携先IF(インタフェース)定義
1-10 データレイアウト概要
1-11 非機能要件の定義(システム化方式、性能、信頼性、運用/保守、テスト計画etc)
2-1 設計 基本設計書 ハードウェア構成図
2-2 ソフトウェア構成図
2-3 ネットワーク構成図
2-4 画面遷移図
2-5 画面レイアウト項目定義
2-6 画面イベント定義
2-7 帳票レイアウト項目定義
2-8 帳票編集定義
2-9 バッチ処理フロー
2-10 バッチ処理定義
2-11 テーブル関連図(ER図)
2-12 テーブル定義
2-13 ファイル定義
2-14 外部システムIF(インタフェース)定義
2-15 外部システムIF(インタフェース)項目定義
2-16 詳細設計書 画面処理詳細定義
2-17 クラス図
2-18 シーケンス図
2-19 ステータス遷移図
2-20 DB更新項目定義
2-21 ファイル出力定義
2-22 共通処理関数設計
2-23 バッチ処理詳細定義
2-24 プログラミング設計書 プログラミング設計書
2-25 テスト仕様書 テスト工程で使用する設計書
3-1 プログラミング ソース ソースコード一式
3-2 実行モジュール
3-3 システム設定値一覧
4-1 テスト 単体テスト仕様書兼成績書 各プログラムごと
4-2 結合テスト仕様書兼成績書 各機能ごと
4-3 システムテスト仕様書兼成績書 各業務ごと
4-4 運用テスト仕様書兼成績書 運用オペレーションごと
5-1 工程範囲外 WBS
5-2 マスタースケジュール
5-3 各工程のスケジュール
  • 1-1.現状業務の業務フロー
  • 1-2.システム化後の業務フロー

業務フローとは業務の流れを図式化したものです。現状業務を整理分析した業務フローとシステム導入を行った場合に予定している業務フローを、要件定義工程で作成します。これらを並べて確認することで、システムを導入することによる業務の効率化、作業負荷の低減などが明確化されます。

  • 1-3.業務システム化範囲定義

業務全体を図式化し、システム化を実施する対象範囲を線で囲むなどして明確化します。システム化範囲を示すことで、要件の拡散を防ぎます。

  • 1-4.業務機能一覧

画面、バッチ、帳票、IF(インタフェース)といったシステム化対象とする全ての機能を一覧化します。予算に限りがある場合や多段階のリリースを考えている場合は、この一覧に優先順位を付けて構築の要否や順序が検討されることが多いです。

  • 1-5.システム化機能概要

業務機能一覧にあげた機能の実現内容を文章や図で表した物です。特に要件定義の段階では、「何を実現させるか」に焦点を当てた資料を作成します。「どのように」実現するかはこの先の工程でドキュメント化していきます。

  • 1-6.画面イメージと項目説明
  • 1-7.帳票イメージと項目説明

各画面、帳票の見た目と操作、各項目を説明する資料です。WebシステムであればモックHTML、その他であればEXCELで作ったイメージなど可視化することで具体的な形にしておきます。

  • 1-8.バッチ機能概要

バッチ処理で実現する機能について記述します。連携先や入出力ファイル、DBなどインプット、アウトプットはしっかり定めておきたいです。

  • 1-9.外部連携先IF(インタフェース)定義

システム化対象となる業務はほとんどの場合、他の社内外の業務とつながっています。例えば販売業務をシステム化した場合、物が売れたら在庫を発送するために在庫管理システムと連携することになるのは一般的なことといえます。ファイルやソフトウェア、DBなどを経由してシステム間の連携をすることをインタフェースと呼び、そのインタフェース接続先、接続方法、連携するデータ内容を定義する資料は必須となります。このIF定義は連携先のシステム担当者とも共有し、連携可否や項目など検討をする際に不可欠です。

  • 1-10.データレイアウト概要

業務をシステム化する際、各機能ごとにプログラムが分かれる形態を取ることも多いです。機能と機能を連携させるために、データのやり取りをする必要が発生します。そのデータのやり取りを行う際のデータレイアウトを定義する資料です。やり取りする方法がファイル形式になったりDB経由となったりするため、方式とレイアウトを定めておく必要があるのです。

  • 1-11.非機能要件の定義(システム化方式、性能、信頼性、運用/保守、テスト計画etc)

システム全体を通した開発方式やプログラミング言語、フレームワークといったアーキテクト分野や性能、信頼性、運用/保守性能など表立った機能以外に考慮すべき要件を非機能要件といいます。非機能要件を定義し、システム全体の方針や目標値といった重要事項を資料化して、成果物に含めておくと良いでしょう。

  • 2-1.ハードウェア構成図

システムを構成するサーバーやストレージ(記憶領域)、ネットワーク機器や実際のシステム利用を行う端末(PCやタブレット、スマホなど)といったハードウェア機器を定めた設計書です。ハードウェアはシステム開発プロジェクトで一度決定して発注した場合、差し替えには多大なコストがかかってしまうため、気軽に行うことは出来ません。技術者によって、システム構築の実現性とコストの間で最適な組み合わせが検討されて決められています。

  • 2-2.ソフトウェア構成図

システム化した各機能で構成するシステムの全体像を記載する設計書です。物理的な構成を記載するハードウェア構成図やネットワーク構成図とは違い、ソフトウェア(アプリケーション、プログラム)で業務全体を実現するための構成を記載していきます。

  • 2-3.ネットワーク構成図

ハードウェアとLANやWANの間や複数拠点間のネットワークについて全体像を記載する設計書です。ネットワークの構築はシステム構築以外の業者に依頼しなくてはならない部分もあるため、その線引きも記載する必要があります。

  • 2-4.画面遷移図

要件定義で洗い出した各画面の間での遷移を記載する設計書です。実際に利用したユーザから見えるシステムの使い勝手に繋がるドキュメントといえます。

  • 2-5.画面レイアウト項目定義
  • 2-6.画面イベント定義

各画面の設置項目やボタンなどのアクションのイベントを定義する設計書です。各項目には詳細な属性があるため、一項目ずつ定義していく必要があります。例:電話番号の項目は半角数字のみの15桁以下で入力する。

またアクションのイベントは処理の内容そのものを示すため、実現したい機能とそれを実現するロジック(論理)を記載する必要があります。例:商品を選択して、数量を入力したら金額が算出される。金額=商品×数量+税

  • 2-7.帳票レイアウト項目定義
  • 2-8.帳票編集定義

画面と同様、システムから出力される帳票のレイアウトおよび各項目の値の取得元を定める設計書です。

  • 2-9.バッチ処理フロー
  • 2-10.バッチ処理定義

バッチ処理の連携、動作手順を示すフローとその処理内容のロジックの定義を行う設計書です。

  • 2-11.テーブル関連図(ER図)
  • 2-12.テーブル定義

システム化においてデータの保持と格納はほぼ必須となる仕組みです。多くの場合、DBを導入してデータを格納しています。データをどのような単位で持ち、各項目はどんな属性を持っているか、データ間ではどのような関係があるかといったことを定める設計書です。

  • 2-13.ファイル定義

システム開発においては各種のファイルを利用することが多いです。バッチ間の処理の受け渡しやシステム間IFに利用するファイルなどの種類と項目を定義する設計書です。

  • 2-14.外部システムIF(インタフェース)定義

2-15.外部システムIF(インタフェース)項目定義

要件定義で洗い出したシステム間IFについて、各連携先と仕様検討を行い、連携方式、連携の項目について定義した内容を記載した設計書です。

  • 2-16.画面処理詳細定義

画面についての項目やイベントについて、基本設計書の内容よりも詳細に記載した設計書です。データの構造やDBへの問い合わせ、登録/更新/削除などの実装可能なレベルでの記載を行います。

  • 2-17.クラス図

オブジェクト指向での開発時、クラスというプログラムを作成する単位を定める設計書です。クラスの親子関係、メソッド(関数)についても記載します。

  • 2-18.シーケンス図

画面やバッチなどのロジックにおける処理順序を図式化した設計書です。処理が複雑な個所などの記載を行います。

  • 2-19.ステータス遷移図

システム化した業務において、各データの持つステータスを定義した設計書です。例えばECサイトの販売データならば、受注→決済完了→発送完了→着荷といった具合にデータの状態は変わっていきます。

  • 2-20.DB更新項目定義

システム上の機能がDBの登録/更新/削除を行う場合、詳細について記載します。概要をまとめてCRUD図と呼ばれる図式化を行うこともあります。

  • 2-21.ファイル出力定義

システム上の機能で使用するファイルの詳細な定義の設計書です。ファイル形式やエンコードといったファイル全体の定義に関わる情報から、各項目の属性までを定めておきます。

  • 2-22.共通処理関数設計

システム化する機能のうち、共通して登場する機能を共通処理として定め、集約するための設計書です。メンテナンス性他の品質を高め、コスト削減に結びつくこともあります。

  • 2-23.バッチ処理詳細定義

バッチ処理の処理内容を詳細に記載する設計書です。内部的なロジックやバッチの起動方法、周期なども定めます。

  • 2-24.プログラミング設計書

詳細設計工程で作成した設計書を、プログラミング言語に置き換える直前の状態まで落とし込んだ設計書です。具体的な関数名やAPI、変数などについても必要があれば記載していきます。内容が詳細になり、技術者でなければ理解が難しい場合もあり、成果物としては作成するが納品物には含まれないことも多いです。

  • 2-25.テスト仕様書

要件定義から基本設計、詳細設計、プログラミング設計と工程ごとにブレイクダウンしながら作成していった仕様に対し、テストの項目を定めた設計書です。基本的には設計を行った工程に対し、裏返しとなるテスト仕様を作ることが可能です。

  • 3-1.ソースコード一式

プログラミング工程で作成したプログラムコード(ソースコード)および定義ファイルといわれるプログラムで使用する値を規定したファイルです。以降の保守、運用フェーズで改修することも考えて、必ず改変可能な形で受け取ることが必要となります。

※プログラムの著作権、利用権などは契約にてプロジェクトごとに定めます。

  • 3-2.実行モジュール

プログラミングしたソースコードを、サーバーやPCといった実行環境上で動かせる状態にしたものを実行モジュールといいます。言語により拡張子は様々です。

例:windowsアプリの.exeファイルなど

  • 3-3.システム設定値一覧

プログラムから参照する定義ファイルの設定内容および設定方法を記載した設計書です。例えば動作モードの切り替えなどを、プログラムに組み込んだ場合などによく利用されます。

  • 4-1.単体テスト仕様書兼成績書
  • 4-2.結合テスト仕様書兼成績書
  • 4-3.システムテスト仕様書兼成績書
  • 4-4.運用テスト仕様書兼成績書

各設計工程で作成した仕様を満たしているかどうかを判別する、テスト項目を記載した仕様書兼成績書です。単体テスト仕様書はプログラム単位、結合テスト仕様書は機能単位、システムテスト仕様書はシステム上の業務単位、運用テスト仕様書は運用オペレーション単位に作成、テストを行います。また、必要な場合はテストのエビデンス(証拠)も添付します。

  • 5-1.WBS
  • 5-2.マスタースケジュール
  • 5-3.各工程のスケジュール

WBS、マスタースケジュールはシステム構築作業全体に対し、実施しなければならないタスクを洗い出し、スケジューリングしたドキュメントです。各工程ごとの詳細なスケジュールも作成することが多いです。納品物となるかどうかはプロジェクト次第ですが、プロジェクト推進上作成して共有していくドキュメントのため、成果物としては発生してきます。

総括

システム開発における成果物は、システムをどれくらいの細かさで定義して作成していくかにより変わっていきます。境界もあいまいなものも存在するなど、必ずしも全てのドキュメントが全てのプロジェクトで発生するわけではありません。システム開発を発注するにあたっては、どの粒度の設計書までが必要かを認識し、成果物と納品物を明確にすることで、品質とコストのバランスを取る必要があるのです。

Web制作会社・システム開発会社を一括見積もりで発注先を楽に探す

Web制作会社・システム開発会社の案件一覧

Web制作会社・システム開発会社のお見積り案件の一覧です。このような案件に対応したい場合は「資料請求フォーム」よりお問い合わせください。

比較ビズへ掲載しませんか?

カテゴリ一覧

人気記事

Web制作会社・システム開発会社の最新記事

システム開発の相談はこちら

一括見積もりで発注業務がラクラク!

  • 無料一括見積もりで募集開始
  • 複数の業者・専門家から提案が入る
  • ピッタリの一社を見つけよう

不透明な見積もりを可視化できる「比較ビズ」

比較ビズは「お仕事を依頼したい人と受けたい人を繋ぐ」ビジネスマッチングサービスです。
日本最大級の掲載企業・発注会員数を誇り、今年で運営15年目となります。
比較ビズでは失敗できない発注業務を全力で支援します。

日々の営業活動で
こんなお悩みはありませんか?

営業活動でよくある悩み

そのお悩み比較ビズが解決します!

詳しくはこちら
お電話での見積もりはこちら