なぜプロジェクトマネジメントが機能しないのか 30 曖昧な権限と判断

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

異なる目的と判断の難しさ

第２９回で、
プロジェクトマネージャー、アーキテクト、ＰＯの役割が重複する。
と述べましたが、実はそれぞれの目的が以下のように少しずつ異なります。

プロジェクトマネージャーの目的
・プロジェクトの便益の最大化（短期的な視点）

アーキテクトの目的
・アーキテクチャーの便益の最大化（長期的な視点）

プロダクトオーナー（ＰＯ）
・プロダクトの便益の最大化（中期的な視点）

もちろん、目的が異なるため、
事案によっては、トレードオフが発生します。

例えば、次のような場合にトレードオフが発生します。
・プロジェクト要件に応えようとすると、アーキテクチャーが複雑になり、　
　長期的な柔軟性が損なわれ、コストがかかるようになってしまう。
・複数プロダクトを含む全体アーキテクチャーをシンプルにすると、
　機能配置上、恩恵のあるサービスと負担が増えるサービスがでてしまう。
・各プロダクトの都合にあわせると、全体として機能が整合せず、
　プロジェクト要件が実現できない。

トレードオフが発生した場合、
アーキテクチャーの決定は誰の判断事項でしょうか。

一見、
アーキテクトの判断事項のようにみえますが、

実は、
各プロダクトの範囲内についてはアーキテクトの権限がおよびません。

したがって、
結果的に、実は全体における機能配置についても、
アーキテクトは権限を十分に発揮することができません。

では、
アーキテクチャーの決定は、誰の判断事項なのでしょうか。

実際には、
明確に判断プロセスは定義されていることはなく、
多くの場合、なりゆきで、３社の合議となります。

具体的には、
３社が参加している打ち合わせで決定され、
議事録をもって、決定となるパターンが多いです。

では、
この場合、議論の叩き台となる案を合議の場に
提示するのは誰でしょうか。

多くの場合、
叩き台を誰が作成するとの明確なプロセスの定義はありません。

現実には、
心あるＰＭ、もしくはアーキテクト、もしくはＰＯが作成します。
多くの場合、スキルセットが一番近いアーキテクトが作成します。
（アーキテクトがいない場合は、ＰＭが作成するしかありません
　なぜならば、ＰＯは全体の一部しか担当しないので。。。涙）

補足ですが、
早い段階で何らかの叩き台がでてくれば、良い方で、
多くの場合、互いに様子見で、案がでてくることはありません。

とはいえ、
プロジェクトマネジメントの目的である
不確実性の早期排除、との観点でみれば、早め早めに叩き台は
作成されるべきです。

ＰＭＯの介入

本記事では、幾度か述べてまいりましたが、
前述のように、問題の原因が組織の特徴にある場合、

原因は、組織設計に問題があるので
関係するリーダーや担当者の能力や精神的ながんばりでは解決できません。

ちなみに、
状況にもよりますが、スキルセットがあえば、
ＰＭＯがＰＭに代わって作成するというやり方もありです。
（アーキテクトやＰＯから白い目でみられますが、
　プロジェクトにおける問題解決に必要であればやむを得ません）

ＰＭＯは、
最初から正しい叩き台を作成することは難しいですが、
多少あやまったものであっても、状況を可視化して土俵にあげると、
不思議なもので、アーキテクトやＰＯから、

「ここは間違っている」
「これではなくて、こうしたやり方の方がよいと思う」
「必要な情報はここにあるので、参考にするように」
　などと、いろいろと助け舟がでてきます。

　ありがたいことです♫（笑）
（ＰＭＯが火中の栗を拾うのは相当勇気が入りますが💦）