【成果物一覧】プロジェクト立ち上げ～終結までに作成される成果物を一覧化しました

こんにちは。わさお(@wasataka)です。

今回はプロジェクト立ち上げ～終結までに作成される成果物を解説いたします。

特にシステム開発プロジェクトを想定しておりますので、参考にしていただければと思います。

なお、プロジェクトのプロセスはPMBOKと同様、以下の5つのプロセス群で整理しております。

1.立上げ

2.計画

3.実行

4.監視・コントロール

5.終結

1.立上げプロセス群

1-1.プロジェクト立上げ

フィージビリティ・スタディ

プロジェクトを立ち上げるべきか、実現可能かどうかの事前調査のこと。

• ROI
• リスク調査

ビジネスケース（プロジェクト企画書）

プロジェクト立上げを検討するための企画書。プロジェクトとして投資するかどうか経営者が判断する材料が記述される。

• 市場の需要
• 組織のニーズ
• 顧客要求
• 技術進歩
• 法的要件
• 生態系への影響
• 社会的ニーズ

SOW（作業範囲記述書）

プロジェクトの仮のスコープを定義するもの。ステークホルダー間で認識合わせを行うために使われる。

• ビジネスニーズ
• 主要な成果物
• スコープ
• 戦略

RFI/RFQ

顧客がベンダー企業に対して、情報提供や見積もりを依頼するためのドキュメント。

RFP

顧客がベンダー企業に対して、どのようにプロジェクトを行うのかという提案を依頼するためのドキュメント。

覚書/合意書/契約書/提案書

顧客とベンダー企業間でお互いの合意事項を明確にするための成果物。MOU、MOA、LOI、NDA、契約書、提案書などがある。

プロジェクト憲章

プロジェクトオーナー（スポンサー）の承認を得て発行される成果物。プロジェクト憲章が承認されることでプロジェクトマネージャーに正式に権限が与えられる。プロジェクト憲章という独立した成果物ではなく、プロジェクト企画書やプロジェクト計画書にマージされることもある。

• プロジェクトタイトル
• プロジェクトの目的や妥当性
• プロジェクトの目標と達成基準
• ハイレベルな要求事項
• ハイレベルなマイルストン・スケジュール
• ハイレベルなコスト見積り
• ハイレベルなプロジェクト方針
• ハイレベルな前提条件
• ハイレベルな制約条件
• ハイレベルなリスク
• プロジェクトの承認要件
• プロジェクトマネージャの指名
• プロジェクト憲章の承認者あるいはスポンサーの氏名

ステークホルダー登録簿

プロジェクトのステークホルダーの立ち位置を明確にするための成果物。特にネガティブな意見を持つステークホルダーに注意しないといけない。

• ステークホルダー名
• 影響力
• 関心度
• 対応計画
• 主なコメント
• コミュニケーションのポイント

2.計画プロセス群

2-1.プロジェクト計画策定

プロジェクト計画書

プロジェクト計画書はプロジェクトの基本方針をまとめたもの。ビジネスケースやプロジェクト憲章をインプットにし、プロジェクト計画書を作成する。

• プロジェクトの背景・目的
• 要求事項
• プロジェクトスコープ
• マスタスケジュール
• プロジェクト体制図
• 成果物
• プロジェクトの完了基準
• コミュニケーション計画（RACI・会議体・エスカレフロー・課題管理方法など）
• リスクマネジメント計画
• リソース計画
• トレーニング計画
• 予算計画（予算取得フロー・予備費など）
• 品質計画
• 変更管理計画
• 調達計画
• 移行計画（システムリリース計画、サービスリリース計画など）

WBS

プロジェクトの目標の達成に必要なすべての作業を抽出し、階層構造で表したもの。見積り作成と進捗管理を目的にWBSは作成される。

サービスレベル契約書（SLA）

サービスを利用する側と提供する側で取り決めたサービスレベルに関する合意文書。

3.実行プロセス群

3-1.業務要件定義

サービス仕様書

サービスのためのシステム開発を行う場合はサービス仕様書も必要になります。

どのようなサービスなのかが初めて見るでも分かるようにしましょう。

技術仕様書

システム開発以外の技術要素がある場合は、技術仕様書も作成しましょう。

業務フロー

業務フローは、関係者とタスクを時系列で整理したものです。

業務フローの中で対象システムがどのように関わってくるかを見える化するために、業務フローは必ず作成しましょう。

要件定義を行うにあたって、まず始めに作成したい成果物です。

なお、業務フロー図の作成方法については下記記事を参考にしていただければと思います。

業務要件一覧

業務要件一覧は、業務側の目線で必要な要件を一覧化したものです。

システムの受け入れ条件基準の一つに、業務要件一覧を全て満たしていることが挙げられますので、必要な要件を抜け漏れないよう作成しましょう。

非機能要件定義一覧

非機能要件定義をとりまとめたもの。

画面要件定義書

画面要件定義書は、システム画面の部品や機能を定義したものになります。

システム要件定義の際に作成する場合もありますので、業務側とシステム側でどちらが作成するかをあらかじめ決めておきましょう。

3-2.システム要件定義

システム開発計画書

機能要件一覧

機能要件一覧は、システム目線での機能を一覧にしたものです。

システムテストの合格基準として、機能要件を全て満たしていることが挙げられます。

こちらも必須の成果物になります。

非機能要件一覧

非機能要件一覧は、機能要件以外でシステムに盛り込むべき要件をまとめたものです。

非機能要件一覧は下記6つの観点で作成します。

1.可用性

2.性能・拡張性

3.運用・保守性

4.移行性

5.セキュリティ

6.システム環境

なお、非機能要件一覧の作成方法については下記記事を参考にしていただければと思います。

テーブル定義書(項目定義書)

テーブル定義書は、システムに必要な項目を定義したものです。

詳細の書き方は以下の記事でまとめておりますので、参考にしていただければと思います。

3-3.基本設計(外部設計)

ユースケース分析

概念モデリング

画面設計

外部システム I/F設計

バッチ設計

帳票設計

データベース論理設計

3-5.詳細設計(内部設計)

画面レイアウト

帳票レイアウト

ER図

ネットワーク構成図

機能設計書

機能設計書は、機能ごとに処理を記述するものです。フローチャートや画面・帳票の詳細項目の説明をします。

物理データベース仕様

3-6.開発・製造(プログラミング)

プログラムの流れ図

3-7.システムテスト

システムテストについては、以下のようなものが代表例として挙げられます。

・単体テスト
・結合テスト
・総合テスト

詳細は下記の記事でまとめておりますので、参考にしていただければと思います。

3-8.受入テスト

受入テスト計画書

受入テスト計画書は、受入テストを必要十分に実施するために作成します。

受入テストの目的、スケジュール、スコープ、内容、準備、役割分担、開始/終了基準、連絡体制などを定義します。

なお、受入テスト計画書の作成方法は下記を参考にしていただければと思います。

受入テスト仕様書

受入テスト仕様書は、テスト当日のシナリオ、判定基準、テストデータなどを定義したものです。

受入テストメンバーは開発者以外で実施しますので、誰が見てもテスト実施出来るような内容・書き方にします。

なお、受入テスト仕様書は下記を参考にしていただければと思います。

3-9.システムリリース

リリース計画書

リリーススケジュール

システムごとのリリーススケジュール。時間単位まで記載するべき。

作業判定

開始判定→1次判定→切戻判定→リリース完了判定の順番で進めていく。

体制

リリース作業時の体制。NG時のエスカレフローは特に念入りに整理する必要がある。

3-10.サービスリリース（業務リリース・稼働判定）

ユーザー研修計画書

移行計画書

システム稼働判定表

システム稼動判定表はシステムリリース及び業務リリースをしても良いかの判定基準をまとめたものになります。

システム側と業務側の責任者がGOサインを出す根拠として必要になります。

具体的な判定基準としては、移行完了率、受入テスト完了率、ユーザー研修実施率などがあります。

詳細は下記の記事に書き方などをまとめておりますので、参考にしてみてください。

3-11.運用・保守

初期流動計画書

システムリリース直後はトラブルや問い合わせが多く発生します。

そのようなときの対応方法、運用体制、連絡フローなどを事前に計画するために初期流動計画書を作成します。

システムリリースから通常の運用体制に引き継ぐまでの期間を初期流動期間と定めます。

詳細は下記の記事にまとめておりますので、参考にしてみてください。

運用手順書

運用手順書は通常の運用・保守対応の手順をまとめたものになります。

開発と運用でメンバーが異なることも多いため、初めて見た人でも運用出来るような内容にします。

4.監視・コントロールプロセス群

4-1.プロジェクトマネジメント

課題管理表

リスク管理表（リスク登録簿）

• 事象
• 区分
• 発生確率
• 影響度
• スコア
• 方針
• 対策
• リスクトトリガー

変更管理表（変更ログ）

プロジェクトに関する変更を伴う場合の管理表。

コスト管理表（予算管理表）

プロジェクトに関するコスト・予算の管理表。

チェックシート

プロジェクト品質に関する項目のチェックシート。品質管理のために用いる。

回帰計画

変更実施後に何らかの不具合が生じた場合に備えて、再び変更前の状態に戻すための計画。

5.終結プロセス群

5-1.クロージング

教訓

プロジェクトで得た様々な情報を後続プロジェクトに活かすための情報。一般的にKPT(Keep=今後も維持すべき点、Problm=問題点、Try=挑戦したいこと）の観点でまとめる。

プロジェクト完了報告書

プロジェクトが完了したことを関係者に報告するための成果物。プロジェクトの目的・KPIに対する達成度合いを記載する。

【参考】おすすめの書籍

発注者側目線でシステム開発をまとめた本です。

【参考】おすすめの動画

システム開発における注意点などがまとまっておりますので、参考にしていただければと思います。

オンライン研修動画サービスの「Udemy」では成果物の作成方法に関する研修動画がいくつかあります。

個人的には下記の『手を動かして学ぶITプロジェクトの資料作成！システム開発のドキュメンテーション技術と成果物テンプレート』講座がおすすめですので、成果物作成に関して、勉強したい方は是非視聴してみてください。

【公式サイト】Udemy

まとめ

いかがでしたでしょうか。

今回はシステム開発における各種成果物について整理致しました。

↓↓このブログが少しでもお役に立ったならば、応援クリック頂けると嬉しいです！↓↓