【PMBOK第７版】デリバリー・パフォーマンス領域について解説
プロジェクト・マネジャーとして、プロジェクトを成功させるためにはどこに注目したらよいのでしょうか？
プロジェクトマネジメントのガイドラインであるPMBOK第７版では、「プロジェクトの成果を効果的に提供するために不可欠な、関連する活動」をプロジェクト・パフォーマンス領域と呼び、以下の８つの領域に注目しています[1]PMBOK第７版「プロジェクトマネジメント知識体系ガイド」、７頁。。
- ステークホルダー
- チーム
- 開発アプローチとライフサイクル
- 計画
- プロジェクト作業
- デリバリー
- 測定
- 不確かさ
プロジェクトは様々な要素が影響して成否が決まりますが、これら８つに注意をすることで、プロジェクトの成功率を大きく高めることができます。
今回は８つのパフォーマンス領域の１つである「デリバリー・パフォーマンス領域」について解説していきます。
プロジェクトの価値を実現するための活動
PMBOK第７版では、デリバリー・パフォーマンス領域を「プロジェクトが達成を目指したスコープと品質の提供に関連する活動と機能を扱う」領域と定義しています[2]PMBOK第７版、80頁。。この定義のとおり、このパフォーマンス領域は「プロジェクトでどのような作業・活動をすべきか」を考えるスコープ・マネジメントと、求められる品質の達成を目指す品質マネジメントの２つで成り立っています。
デリバリー（delivery）は「配達」や「引き渡し」と訳されますが、プロジェクトマネジメントでも同様に、クライアントやユーザーにプロジェクトで生み出した製品・サービスを引き渡すことを指します。その引き渡しの際に「必要な機能がなかった」「要望していた品質を満たしていない」ということが無いように、デリバリー・パフォーマンス領域の活動を実施していきます。
作業範囲（スコープ）のマネジメント
プロジェクトで求める製品・サービスが形になったとしても、「必要とする機能が開発されていなかった」「実施すべき工程を実施していなかった」ということがあってはなりません。PMBOK第６版では、プロジェクトで生み出そうとしている製品・サービスを実現するために、どのような作業が必要になるかを「プロジェクト・スコープ・マネジメント」という活動で考えてきました。PMBOK第７版では、プロジェクト・スコープ・マネジメントの活動が、デリバリー・パフォーマンス領域の活動に含まれています。
必要な作業を漏らさず実施するために、以下の２つの活動を行います。
- 要求事項の収集
- スコープの定義
ここからはこれら２つの活動について解説していきます。
要求事項の収集
準備として、ユーザーを始めとするステークホルダーの要求事項を収集していきます。たとえばソフトウェア開発であれば、開発するソフトウェアで何をしたいのか、どのようにプロジェクトを進めたいのかをヒアリングし、その情報をまとめていきます。これらの要求事項は、後から解説するプロジェクトの品質を考える上でも大切です。
要求事項の収集方法については、下記の記事もご参照ください。
https://ssaits.jp/promapedia/concepts/collect-requirements.h...要求事項をまとめる際は以下の点に気をつけていきます[3]PMBOK第７版、83頁。。
- 明確さ：要求事項の解釈方法が１つである
- 簡潔さ：要求事項が手短に記述されている
- 検証可能：要求事項が満たされていることを検証する方法がある
- 一貫性：矛盾する要求事項がない
- 完全性：一群の要求事項は現在のプロジェクトまたはプロダクトのニーズ全体を表す
- 追跡可能性：各要求事項は一意の識別子によって認識できる
これらの情報をまとめる手法として要求事項トレーサビリティ・マトリックスがあります。要求事項トレーサビリティ・マトリックスは、要求事項を整理するだけでなく、その後の内容の変化やプロジェクト中に追加された要求を整理する上でも役に立ちます。
要求事項トレーサビリティ・マトリックスについては、下記の記事もご参照ください。
スコープの定義
要求事項が収集できたら、各要求を満たすためにどのような作業が必要かを考えます。それらの作業はワーク・ブレークダウン・ストラクチャー（WBS）としてまとめられます。WBSでは、プロジェクト完了に必要な作業をいくつかの大タスクにまとめて整理します。
このWBSについては下記の記事もご参照ください。
品質のマネジメント
品質コスト
「品質は要求に対する適合である」という考えがあります。この定義が正しければ、収集した要求事項にすべて応えるだけで高品質の成果物が得られそうです。しかし実際には要求に単に応えるだけではなく、不良品を排除したり、プロジェクトのトラブルを回避したりしなければ、高品質の成果物を得ることができません。この不良品やトラブルを排除するために支払うコストを品質コスト（COQ：Cost Of Quality）と呼びます。
品質コストは「予防コスト」「評価コスト」「内部不具合コスト」「外部不具合コスト」の４種類に分類され、それぞれの項目を細分化して記載したチェックシートなどを活用して、製品の品質をチェックしていきます。 予防コストと評価コストは適合関連コスト、内部不具合コストと外部不具合コストは不適合関連コストと呼ばれます。
予防コストとは、プロジェクトによってできた成果物やプロダクト、サービスの品質不良を防止するために投資するコストのことです。
評価コストとはプロジェクトの成果物やプロダクト、サービスが品質不良にならないために評価・テストするためのコストです。
内部不具合コストはプロジェクトの最中にプロジェクト・チームのメンバーに発見された品質不良のために費やすコストのことです。
外部不具合コストは、プロジェクトが終了し、そのプロジェクトでプロダクトやサービスを世に出した後に、顧客やユーザーなどによって発見された品質不良です。
これらの品質コストについては、下記の記事もご参照ください。
変更コスト
品質の高い成果物を得るために、プロジェクト・マネジャーは変更コストに関する知識も持っておく必要があります。
修正や仕様の変更に伴うコストである変更コストは、プロジェクトが進むとともに増加します。
たとえばソフトウェア開発プロジェクトが「要件定義」「設計」「開発」「テスト」「リリース」というプロセスを経て進むとします。変更の影響は要件定義の段階であれば小さく、テストやリリースの段階で発生した変更の影響は甚大です。プロジェクトが進むにつれて変更コストが増える理由は、単に作業の手戻りが発生するというだけでなく、プロジェクトに関わるステークホルダーが時間の経過とともに増えていくことが挙げられます。
プロジェクト・マネジャーは変更コストが大きくなるプロジェクトの後半に変更が入らないようにするために、設計者やエンジニアなどと共に要件定義や設計をするなど、プロジェクトの進行に気を配らなければなりません。
デリバリー・パフォーマンス領域の成果をチェックする
PMBOK第７版によれば、デリバリー・パフォーマンス領域で実施した活動が効果を上げていると、以下のような状態になります[4]PMBOK第７版、92頁。。
- プロジェクトは、事業目標と戦略の推進に貢献する。
- プロジェクトは、立上げの目的である成果を実現する。
- プロジェクトのベネフィットは、計画された期間内に実現される。
- プロジェクト・チームは、要求事項を明確に理解している。
- ステークホルダーは、プロジェクトの成果物を受け入れ、満足している。