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

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

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

本記事では、形式知（ＰＭＢＯＫ）＋暗黙知（本マガジン過去記事）を「ＱＣＤバランスを確保するために不確実性にどのように対処するか」との観点で再構成し、「Re:プロジェクトマネジメント」としてお届けすることで、ＰＭＢＯＫの知識や技法を、「ＱＣＤバランス」のために、正しく使えるようになることを目指します。

Re:プロジェクトマネジメントの５つの要素

前回の記事（５３回）では、Re:プロジェクトマネジメントの基本的な５つの要素について以下のように述べました。

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

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

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

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

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

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

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

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

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

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

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

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

タスクの全量性と実現性

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

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

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

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

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

タスクの全量性

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

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

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

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

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

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

次の記事（５５回）
↓