【PMBOK第７版】不確かさパフォーマンス領域を解説
プロジェクト・マネジャーとして、プロジェクトを成功させるためにはどこに注目したらよいのでしょうか？
プロジェクトマネジメントのガイドラインであるPMBOK第７版では、「プロジェクトの成果を効果的に提供するために不可欠な、関連する活動」をプロジェクト・パフォーマンス領域と呼び、以下の８つの領域に注目しています[1]PMBOK第７版「プロジェクトマネジメント知識体系ガイド」、７頁。。
- ステークホルダー
- チーム
- 開発アプローチとライフサイクル
- 計画
- プロジェクト作業
- デリバリー
- 測定
- 不確かさ
プロジェクトは様々な要素が影響して成否が決まりますが、これら８つに注意することで、プロジェクトの成功率を大きく高めることができます。
今回は８つのパフォーマンス領域の１つである「不確かさパフォーマンス領域」について解説していきます。
不確かさパフォーマンス領域とは何か？
プロジェクトには様々な不確かさがあります。たとえば、屋外でのイベントを企画しているとします。イベント当日の天気が晴れかどうかは、その日になってみないとわかりません。しかし、その不確かさを把握し、事前に対策を講じなければ、プロジェクトが失敗してしまうこともあります。
PMBOK第７版の不確かさパフォーマンス領域では、不確かさをはじめ、以下の予測不可能な状態に注目しています。
- 不確かさ
- 曖昧さ
- 複雑さ
- 変動性
- リスク
ここからは、これらの対処法を見ていきます。
不確かさ
PMBOKでは予測不可能な状態を包括して「不確かさ」と呼んでいます。不確かさに対応するために、PMBOKでは以下の対策を紹介しています[2]PMBOK第７版、119頁。。
- 情報を収集する
- 複数の計画・設計・代替案を用意する
- 回復力を養う
曖昧さ
曖昧さには、概念的な曖昧さと状況的な曖昧さがあります。
概念的な曖昧さへの対処法
概念的な曖昧さは理解の欠如により発生します。
たとえばあるプロジェクト・メンバーが「来週にはデザインのモックアップを作ります」という報告をしたとします。この短い報告の中にも「来週というのは具体的にいつを指すのか」「モックアップとはどのような成果物ができるのか」という曖昧さがあります。報告したプロジェクト・メンバーは「来週金曜日くらいにデザインの設計図を提出しよう」と考えているかもしれませんが、「来週の水曜日にはデザイン案ができるだろう」と捉えるステークホルダーもいるかもしれません。
このようなトラブルを回避するためにも、言葉の定義を明確にし、共通のルールなどを設ける必要があります。
状況的な曖昧さ
状況的な曖昧さは状況に応じて成果が変化することにより発生します。
たとえばデザイン案を２つ用意した場合、採用されたデザインでその後のプロジェクトは多かれ少なかれ変化します。その変化が当初予定されていた計画に合致していれば問題はありませんが、計画から外れてしまっては、その後の進行でトラブルが発生してしまうこともあるでしょう。
こうした問題には、以下の対処法があります。
- 反復
- 実験
- プロトタイプ
プロジェクトは段階的詳細化という特性があるので、プロジェクトの開始直後に立てた計画では、進行とともに現状にそぐわない部分もでてきます。
そのため、計画は一度作成したら終わりにするのではなく、反復し、計画を見直すことで状況的な曖昧さを軽減することができます。
また、実験をしたり、プロトタイプを作成したりすることにより、状況的な曖昧さを小さくすることができます。
複雑さ
複雑さとは、人間やシステムの振る舞いや、曖昧さのためにマネジメントが困難なプログラムやプロジェクト、環境を指します[3]PMBOK第７版、120頁。。
PMBOKではこの複雑さの対処法をシステムベース、再構成、プロセスベースという３つに分けて解説しています。
システムベース
システムベースの対処法には、「デカップリング」と「シミュレーション」があります。
デカップリング（切り離し）
デカップリングとは、組み合わされていたもの（カップリング）を切り離すことです。つまり、システムの一部を切り離し、対処しやすい規模にすることで、複雑さに対処します。
シミュレーション
シミュレーション、つまり類似のデータやモデルを用いることでも、複雑さに対処することができます。たとえば、ある商業施設にこれまでになかったお店を出店するとします。そのお店の売上を考えるのは難しいことです。しかし、出店する場所の近くのお店のデータや、似ているお店の消費者の習慣を想定することで、新しいお店の売上を予測することができるかもしれません。
このように類似するデータやモデルを用いることで、一見複雑で対処できそうにない問題に取り組むのがシミュレーションです。
再構成
再構成とは、複雑さを感じているものごとを構築し直すことを意味しています。
たとえば、ブレインストーミングなどで様々な意見を取り入れたり、お互いの悪い影響を打ち消すような構成要素を組み合わせたりして、システムを作り変えていきます。
プロセスベース
プロジェクトの進め方（プロセス）を工夫することにより、複雑さに対処することもできます。
たとえば、反復型や漸進型の開発アプローチを採用することにより、複雑なものごとを徐々に解決することができます。また、何か問題が発生した時に、その機能を制限することで安全に使い続けられるようにする「フェールソフト」を採り入れることも大切です。
さらに、プロジェクトが複雑になる原因に制限の多さも挙げられます。「定期的に報告する」「○○の承認の前に××の部署に確認を取る」など、プロジェクトの進め方に関する制限はステークホルダーに拠ることが多いので、この制限を少しでも緩和・削減するためにも、ステークホルダーのエンゲージメントを高めることも重要です。
ステークホルダーと良好な関係を築くことによって、不信からくる制限などを取り払うことができます。
変動性
変動性が高い環境、つまり急激で予測不可能な変化が発生する環境には、代替案分析や予備を設けることで対応します。
代替案分析については、下記の記事をご参照ください。
https://ssaits.jp/promapedia/method/alternative-analysis.htm...リスク
リスクとは、発生するかどうかが定かではないイベントや状況のことです。「リスク」という言葉は負のイメージがありますが、プロジェクトにプラスの影響を与えるリスクもあります。
これらのリスクを想定し、事前に準備することでプラスのリスクの効果を高め、マイナスのリスクの影響を軽減することをリスク・マネジメントと呼びます。
このリスク・マネジメントについては下記の記事をご参照ください。
不確かさパフォーマンス領域の成果をチェックする
PMBOK第７版によると、不確かさパフォーマンス領域で実施した活動が成果を上げていると、以下のような状態になります[4]PMBOK第７版、129頁。。
- プロジェクトが発生する環境の認識ができる。
- 不確かさを積極的に調査し、それに対応することができる。
- プロジェクトにおける複数の変数の相互依存性を認識することができる。
- 脅威や好機を予測し、問題の因果関係を理解することができる。
- 予測しないイベントや条件からの悪影響がほとんどない、またはまったくない状態でプロジェクトを実行することができる。
- プロジェクトのパフォーマンスと成果を改善する好機が訪れる。
- コストとスケジュールの予備は、プロジェクト目標との整合性を維持するために、効果的に利用される。