Re:プロジェクトマネジメント 55

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

Re:プロジェクトマネジメント

本マガジンの５０回以降では、
プロジェクトマネジメントの目的を明確に「ＱＣＤバランス」とし、アプローチをＰＭＢＯＫのような複雑なものではなく、「いかにＱＣＤをバランスさせるか」というシンプルな問題として再定義（Re:プロジェクトマネジメント）することで、ＰＭＢＯＫの知識や技法を、正しく使えるようになることを目指します。

何をもってＱＣＤはバランスするのか

前回の記事（５４回）では、
ＱＣＤはPMの「よし、いける❗️」という実感をもってバランスすると述べました。ずいぶんと、アナログなアプローチです💦

では、そもそも、
Ｑの何と、Ｃの何と、Ｄの何が、均衡すれば、ＱＣＤがバランスしたと言えるのでしょうか。

実は、
ＰＭＢＯＫには、明確で具体的な説明はありません。

ＰＭＢＯＫで説明されているのは
「品質管理、コスト管理、スケジュール管理は重要な要素で、互いに影響があるので、統合的に管理しましょう」というところまでです。

それぞれの要素に関する具体的な
管理方法などは説明がありますが、それぞれをまたがったバランスの確認方法については、具体的な説明はありません。

では、
みなさまは、どのような均衡を確認することでＱＣＤのバランスを確認しているのでしょうか。ＰＭとして、ＰＭＯとして、何をもってＱＣＤがバランスしていることを見極めているのでしょうか。

「ただなんとなく…バランスしているような気がする…」からでしょうか。
　あるいは「計画レビューで承認されたから…」からでしょうか。

実は、
ＱＣＤバランスの見極めにあたっては、関連する５つの誤解を改め、それぞれの要素の位置付けを正しく理解することが必要です。
１）ＱＣＤバランスの誤解
２）Ｑの誤解
３）リソースの誤解
４）リスクの誤解
５）スコープの誤解

補足：ＰＭＢＯＫにおけるバランス要素
バランスさせるべき要素について、ＰＭＢＯＫでは、初版でスコープ、スケジュール、コスト、品質の４つが挙げられていましたが、次の2000年版ではリスクを加えて５つとなり、第３版（2004）では、品質、スコープ、タイム、コストの４つに戻り、第４版（2008）になると、スコープ、品質、スケジュール、予算、資源、リスクを列挙した上で「ただし、これらの要素に限定されない」と他の要素にも含みを持たせています。

ＰＭＢＯＫにおいても、バランスさせるべき要素に混乱が見られ、状況は複雑に映りますが、後述する理由により、実はシンプルな枠組みでのアプローチが可能です。

いっけん複雑に見える問題でも、構成する要素の関係を丁寧に紐解いていくことで、取り組むべきポイントが可視化されます。そして、大抵の場合、それはシンプルなことですが、そこに辿り着くまでの構成要素の組合せパターンの試行錯誤には相当の労力が必要です（問題解決あるある 笑^ ^;）

https://www.jstage.jst.go.jp/article/spm/2012.Spring/0/2012.Spring_348/_pdf/-char/ja

再考:プロジェクトマネジメントの基本的な５つの要素について以下のように述べました。

アプローチ
プロジェクトマネジメントは、ＰＭＢＯＫのような複雑なフレームよりも、問題解決というシンプルなフレームによるアプローチの方がわかりやすい。

問題
プロジェクトマネジメントを問題解決とした場合、全ては３つに収斂する。
１．いかに不確実性を早期に検知するか
２．いかに課題を解決余力内に収めるか
３．いかにＱＣＤバランスを維持するか

不確実性
プロジェクトマネジメントで扱うべき不確実性は、ＰＭにとっての不確実性。（他のメンバーの不確実性はあまり扱う意味がない）

ＱＣＤバランス
ＰＭの「よし、いける！」という実感こそがＱＣＤバランスの達成条件。

前回（５３回）では、

「よし、いける！」という実感

そもそも、
どのような条件が整えば「よし、いける！」と実感するのでしょうか。

自明ですが、
プロジェクトの不確実性は、プロジェクト完了まで存在します。そのため、プロジェクトに不確実性が残っている間は、「よし、いける！」とは思えないのであれば、ＱＣＤは最後までバランスしないことになります。

そのため、
プロジェクトにおける不確実性を仮に１００とすると、不確実性が１００から０の間のどこかの段階でＰＭは「よし、いける！」と思える瞬間がなければ、そのプロジェクトのＱＣＤは一度もバランスしないことになります。

それは、
残る不確実性が１００から５０に減った時でしょうか。あるいは１００から３０くらいまで減った時でしょうか。そもそも不確実性がもともと１００であることを、何を持って知り得るのでしょうか。

とはいえ、
ＱＣＤをバランスさせるためには、
ＰＭがどこかの段階で「よし、いける！」と実感する必要があります。それがプロジェクト成功の前提条件となるからです。

実際には、
プロジェクトにおける全ての不確実性がなくならなくても、不確実性のある部分に対して、ある程度の前提を置くことでＰＭが「よし、いける！」と実感することができます（このあたりは、少しずつ説明していきます）

では、
どのような条件が整えばＰＭが「よし、いける！」と実感することができるのでしょうか。

タスクの全量性と実現性

実は、
「よし、いける！」という実感は、ＰＭが、プロジェクトのスコープ、すなわちタスクの全量性とその実現性を理解して、納得したときにはじめて「よし、いける！」と実感することができます。

逆にいうと、
タスクの全量性に対する不安があると「よし、いける！」とは思えませんし、もし、タスクの全量性に納得感があっても、その実現性に不安があると、やはり「よし、いける！」とは思えません。

具体的にいうと、
それぞれの要素に対する納得感は、ＷＢＳの縦と横に対する次のような納得感と言い換えることができます。

全量性：タスクが全量であることに対する納得感（ＷＢＳの縦）
実現性：タスクのリードタイムと関係性の納得感（ＷＢＳの横）

では、
どうすればＰＭはタスクの全量性と、それぞれのタスクのリードタイムと関係性に対して納得感を持つことができ、「よし、いける！」と実感することができるのでしょうか。

タスクの全量性

そもそも、
どうすれば、ＷＢＳのタスクの全量性を確保できるのでしょうか。

このあたりは、
他のプロジェクトマネジメント関連の書籍や記事にも説明があるので、あまり詳細には触れませんが、まずは最終スコープとなる成果物全体を定義し（個人的にはポンチ絵でスコープ全体を定義するとが多いです）、全体を構成する要素にわけていって、途中から成果物からタスクに変えていきます。

少し余談ですが、
要素をわけると必ず分離された要素同士の結合品質を確認するタスク（いわゆる結合試験）が発生するので、漏れることのないよう注意が必要です。

特に、
別れた要素のそれぞが別々のチームや部門、あるいは異なる委託先の場合、結合試験がそれぞれの領域でタスクとして定義されていない、あるいは、結合試験はタスクとして定義されているものの、事前の調整タスクが定義されていないことが多いので注意が必要です。

実は、
大抵のプロジェクトでは、各領域が最初に示す結合試験の時期は合わないことが多く、その事前の調整タスクは定義されていないことがほとんどです。（プロジェクトマネジメントあるあるです ^ ^;）（次号に続きます💦）

追伸：抽象的な内容が多くなってきており、
暗黙知を十分に言語化できていない可能性があります💦
・〇〇〇の部分が何言ってるかわからない。
・〇〇〇はこの理解でよいあっているのか。
・〇〇〇は間違い。
　こういうことではないのか。等、
お問合せは、コメントかこちら（ＤМ）から頂けると幸いです。
お気軽にどうぞ→https://note.com/think_think_ab/message