なぜプロジェクトマネジメントが機能しないのか 40 おさらい①

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

プロジェクトマネジメントを機能させるために

＊少し回数が増えてしまったので、
　いったんこれまでの考察を自問的な流れで整理します。

そもそも、
プロジェクトマネジメントとはどのようなときに必要なのでしょうか。

それは、
プロジェクトに不確実性がある場合です。

プロジェクトに不確実性がなければ、
プロジェクトマネジメントが機能しなくても、問題はなく、
むしろ、いかに効率をあげるかがイシューとなります。

では、
プロジェクトにおける不確実性とはどのようなものでしょうか。

それは、
プロジェクトのＱＣＤバランスを脅かすものです。
ＱＣＤバランスを脅かすものでなければ、特に問題はありません。

では、
ＱＣＤバランスを脅かす不確実性とはどのようなものでしょうか。

それは、
Ｑ（スコープ）の不確実性で、具体的には次の３つに関するものです。
・要件（やりたいこと）
・制約（できないこと）
・実現方式（要件と制約を、どうバランスさせ、どう実現するか）

大抵の場合、
要件も、制約も、実現方式も、いずれもあいまいで不確実な状態から
プロジェクトははじまります。

逆に、
要件も、制約も、実現方式も、いずれも明確で決定している場合、
ＱＣＤバランスはＱ（スコープ）が起点で脅かされることはありません。

ちなみに、気になる残りのＣとＤですが、
こちらは、スポンサーとなる外部からの制約条件のため、
プロジェクトマネジメントの機能の影響を及ぼせることは実はありません。

ので、
まずは全力で、Ｑ（スコープ）の不確実性を排除することが
プロジェクトマネジメントの最優先課題です。

では、
スコープの不確実性である要件、制約、実現方式は、
いつまでに決定する必要があるのでしょうか。

それは、プロジェクト前半の要件定義が終わるまでです。

普段、
あまり意識されていることはありませんが、実は、

プロジェクト前半は、
業務フローやデータフローなどを通して、
組織をまたがった横ぐしの調整検討がメインですが、

プロジェクト後半は、
業務や機能ごとにバラバラとなり、
縦割り組織ごとの詳細検討に入りますので、
横ぐし検討の調整事項を残しておくと、決定的に調整負荷が上がります。

また、
プロジェクト後半は、
予算も、リソースも、時間も、余裕がなくなってくるため、
状況によっては、調整が絶望的に難しくなってきます。

では、
どうすれば、プロジェクト前半でスコープ固めができるのでしょうか。

それは、単純ですが、
実現性検討というプロセスを要件定義工程と並行して走らせることです。

実現性検討を
要件定義以降のプロジェクト後半に置いてしまうと、
制約（できないこと）と、要件（やりたいこと）の調整が後になるため、
いつまでもスコープが固まりません。

２つのプロセスを並走させることで、
要件定義完了時にＱＣＤバランスをほぼ確定することができます。

では、
なぜ、多くのプロジェクトにおいて、
これらの２つのプロセスを並走させないのでしょうか。

それは、
部門のメリットが全体のメリットに優先されてしまうためです。

いいかえると
縦割り組織のもつ、組織の脆弱性が原因です。

大抵の場合、
開発部門は無駄なことをしたくないため、
実現性検討のような設計は、要件確定後に、あとまわしにしがちです。

組織としては、
実にあたりまえのふるまいですが、
プロジェクトの不確実性の早期排除との観点では、

余裕のある貴重なプロジェクト前半の間、
不確実性を放置したままとなってしまいます。

では、
実現性検討を要件定義と並走させるだけで、
スコープの不確実性は排除されるのでしょうか。

いいえ、
２つのプロセスを並走させる際には、
実現方式をデザインでき、資料化（可視化）して、
ユーザ部門とシステム部門、双方とコミュニケーションがとれる。
以下の能力を備えた人材の配置が必要です。

・理解力：業務とシステムの両方の言葉が理解できて使えること
・設計力：抽象と具体の両方の概念を理解し、自在に使えること
・表現力：機能とデータという抽象的なものを可視化できること

いいかえると、
「業務 vs システム」、「抽象 vs 具体」という、
　それぞれ対極の関係、すなわち、
　トレードオフの関係の能力の両方をあわせ持つ人材の配置が必要です。

このように、
プロジェクトの不確実性の早期排除、との目的にむけて、
プロセス、組織、人材の３つの要素について、以下の対策があるだけで、
プロジェクトはだいぶ機能するようになります。

・プロセスは、不確実性の早期排除との観点で、前倒しに配置する。
・縦割り組織の脆弱性を理解し、メリットは全体を部分に優先する。
・実現方式検討には、求められる能力をあわせもつ人材を配置する。

逆に、
これらの大きな粒度での対策ができていないと、
プロジェクトマネジメントの機能は大きく損なわれます。

今回のおさらいでは、
プロジェクトマネジメントを機能させるための大きな流れについて、
おさらいいたしました。

前述の対策は、
わかっていてもその実現は、実は大変です。

なぜならば、
その実現には組織的な理解が必要で、
だれか一人が言い出しても、これらの対策は実現されないからです。

また、
対策の実現にあたっては、
まずは、本記事で述べている 不確実性の早期排除、という目的に対する、
プロジェクトメンバーのマインドセットが必要ですが、

まだ、
ひろく形式知として、展開されていないため、
プロジェクトメンバー共通の認識や、共通理解を形成できません。

ですが、
これから携わるプロジェクトにおいて、
前述の対策ができていない部分にプロジェクトのリスクがある、と
理解しておくだけでも、だいぶ行動が変わってくると思います。

今回は、
ＷＢＳや進捗管理、課題管理などのプロセスには触れませんでしたが、
また後の機会におさらいいたします。

次の記事（４１回）