見出し画像

なぜプロジェクトマネジメントは機能しないのか 49 再考④

日本で最初の民間シンクタンクで、プロジェクトマネジメントのコンサルタントとして、ある時はPМ、ある時はPМОとして、お客様と問題解決に取り組んでいます。本記事では、まだPМBОKには書かれていない暗黙知を言語化し、形式知としてお伝えすることにチャレンジしてみようと思います
マガジン:https://note.com/think_think_ab/m/m0e070db46016

プロジェクト内部の「不確実性」とは

第48回(前回)では、
不確実性に対する2つの戦略(プロアクティブ戦略リアクティブ戦略)を説明し、いずれの戦略を採用するかは、不確実性に対してプロジェクトが影響を及ぼすことができるかどうか(不確実性の源泉がプロジェクトの内部か外部か)である。と述べました。

今回は、
プロアクティブ戦略(ウォーターフォールモデル)におけるプロジェクト内部の「不確実性」への対処について深掘りします。

では、
そもそもプロジェクト内部には、どのような「不確実性」が存在するでしょうか。技術的な不確実性やリソースの不確実性など、様々なものがありますが、それらのうち、もっとも重要で、もっとも最初に取組むべき不確実性はどれでしょうか。

それは、
QCDバランスの最初の要(かなめ)となる「スコープ(QCDバランスの「Q」)の不確実性」です。

ちなみに、
ウォーターフォールモデルでは、プロジェクト前半の要件定義工程でスコープ(ユーザのやりたいこと × 技術的に実現できること)を確定する(すなわち、不確実性を排除する)ことでQCDバランスを確保します。

その後、
後工程で発生する課題(🟰 QCDバランスを損なうもの、あるいは脅かすもの)を管理・解決していくことでQCDバランスを確保します。

補足すると、
要件定義工程で確定するスコープは、実現方式(大まかな機能配置とデータの流れ)を決定できる程度の粒度における決定のため、その後の設計工程で詳細化が進むとさまざまな課題(🟰 QCDバランスを損なうもの、あるいは脅かすもの)が必ず発生します。

そのため、
後工程で必ず発生する課題の管理・解決余力(*)を残しておくためにも、要件定義工程完了時にスコープを決定し、QCDバランスを確保することはとても重要です。

*管理・解決余力
プロジェクトで同時に解決に取り組める領域横断(チーム横断)課題は、10〜15個程度が上限です(意外に少ないです:チーム横断の全体週次定例が1時間だとするとこの程度が限界です)。

そのため、
発生した課題はとにかくASAP(できるだけ早く)に解決し、課題の数を10〜15に納め続けることが欠かせません。ちなみに、管理・解決余力を超えてくるとプロジェクトは徐々に瓦解していきます。

スコープの不確実性の原因

では、
スコープの不確実性はなぜ発生するのでしょうか。実は、その原因のほとんどが部門間、担当者間の「認識齟齬」です。

「実は、やりたいことはこういうことだった」
「実は、確認したらこれはできませんでした」
「実は、そんなつもりなかった」
「実は、こういうつもりだった」

などなど、いわゆる「実は」話です。

逆に、
部門間、担当者間の認識齟齬が全くない場合(お互いの考えを全くの誤差なく共有できている場合)、自明ですが、スコープにはほとんど「不確実性」はありません。

しかしながら、
実際には「認識齟齬」は必ず存在します。

対策として、
ウォーターフォールモデルでは、全てのタスク(要件だしや実現性確認、スコープ決定の判断等)をできるだけ早く着手するよう計画し、これらの「認識齟齬」の顕在化タイミングをできるだけ早めることによって「認識齟齬」の早期摘出をはかり、スコープの不確実性を早期に排除します。

補足すると、
「認識齟齬」は以下の3つの理由で発生します。
1)認識合わせの時期が遅い
2)認識合わせの粒度が粗い
3)認識合わせの資料の不備
ウォーターフォールモデルは、このうちの1)を解決しますが、2)3)については、明確な対処策を持っていません(ここは別の機会に説明します)

一方、
アジャイルモデルの場合は、こうした「認識齟齬」に潜む「不確実性」に対してできるだけ早く計画するという概念はありません。

そのため、
ウォーターフォールとアジャイルのいずれのモデルを採用するかの判断にあたっては、自分たちが取り組む「不確実性」の見極めが重要です。

新しいから、流行だから、
などの理由で安易にアジャイルモデルを採用すると、こうした自分たちで主体的に解決できるはずだった不確実性に対処できず、ずるずると残存する不確実性に付き合わされることになるのでご注意ください。

今回の考察を踏まえて、
プロジェクトマネジメントを再考すると以下のようになります。

凡例:
≠ これまでの一般的な(PMBOK的な)解釈、= 再考後の解釈

不確実性に対する対処の順番
≠ なりゆき or リスク管理表で管理し、優先順位を決めて取り組む
= 何よりもまずはスコープの不確実性の排除が最優先
(ここでのスコープとは「ユーザのやりたいこと」×「実現できること」)

スコープの不確実性の原因
≠ ユーザがスコープを明確に決定しないこと
= 部門間、担当者間の「認識齟齬」

認識齟齬(ミスコミュニケーション)の対策
≠ 密にコミュニケーションをとる
= できるだけ早くタスクに着手する計画とする

追伸:抽象的な内容が多くなってきており、
   十分に言語化できていない可能性があります💦
・〇〇〇の部分が何言ってるかわからない。
・〇〇〇はこの理解でよいあっているのか。
・〇〇〇は間違い。
 こういうことではないのか。等、
お問合せは、コメントかこちら(DМ)から頂けると幸いです。
お気軽にどうぞ

https://note.com/think_think_ab/message


この記事が参加している募集

PMの仕事

この記事が気に入ったらサポートをしてみませんか?