なぜプロジェクトマネジメントが機能しないのか 29 マトリクス組織

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

マトリクス組織の難しさ

本記事の第２７、２８回では、
不確実性に対する対策プロセスとして、
アーキテクチャーに関する、以下の２つをお話ししました。

・シンプルなアーキテクチャーはリスク顕在化時の対応バッファになること
・アーキテクチャーのシンプル化検討は不確実性の早期排除につながること

いずれも費用をかけずに、またビジネスメリットを大きく損なうことなく
コストを削減できるお買い得なプロセスですが、
効果的に機能している状況を、あまり見かけたことがありません。

なぜならば、
全体最適と部分最適のバランスがとれた組織設計がとても難しいためです。

もちろん
全体最適が部分最適に優先されるべきですが、
機能別組織の場合、横串を通す横断的機能は設定しにくい、
あるいは、設定できても機能しにくいという特徴があります。

例えば、
サービスアーキテクトやシステムアーキテクトは、
社内のサービスやシステムのアーキテクチャー全体がカバー範囲ですが、
残念ながら、それぞれの要素の組織に対する直接の指揮権を持ちません。

いわゆる
ＣｘＯも役員級の横串機能ですが、
前述のサービスアーキテクトやシステムアーキテクト同様、
機能別の縦割り組織の部門やメンバーに対する直接の指揮権、
いいかえると人事評価権を持たないため、機能しにくい状況となります。

具体的には、
責任範囲の部門やメンバーにとっては、縦割り組織ないの仕事が
最優先（あたまりえですが💦）のため、
横串のマネジメント機能からの指示は、優先順位が下がります。

表面上は言うことを聞いているように見えても
実態はほとんど推進されないのはこのためです。

横串のマネジメント機能との観点では、
プロジェクトマネージャーもＰＭＯも同様です。

では、
どうすればこうした状況を解決できるのでしょうか。
「可視化」がひとつのヒントになりますが、こちらは
　今後の記事の中で触れていこうと思います。

いずれにしても、
こうした縦割組織と横串組織のマトリクス組織の運用は、
経営学においても、社会科学においても、
古今東西、運用が難しいとされており、いまだに解決の難しい領域です。
（組織論も専門とする私にとってはとても興味のある領域です）

プロダクトマネージャー

さて、
こうした横串マネジメント機能である
アーキテクトやプロジェクトマネージャー、ＰＭＯに対して、

最近では、
プロダクトマネージャー、あるいはプロダクトオーナー、
（以下、ＰО）と呼ばれる新たな役割をみかけるようになってきました。

プロジェクトの規模が大きくなってきたため、
プロジェクトマネージャーだけではなく、プロジェクトを構成する各要素、
例えば、特定のサービスを提供する機能単位で管理者（ＰО）が配置される
ことが増えてきました。

ＰОは、担当するサービス範囲に責任を負います。すなわち、
ＰОは、横ぐし機能ではなく、縦ぐし機能の組織の代表です。

しかも、
プロジェクトマネージャーとアーキテクトとＰОの機能は、
範囲がだぶるため、責任や権限の所在が曖昧になります。

曖昧な状態だと
事案のたびにそれぞれの間の関係を整理するか、もしくは、
何もせずに放置するか、のどちらかになります。

大抵の場合、
放置され、ものごとは決まらなくなります。

組織の課題が原因で、
プロジェクトマネジメントが機能しないことはよくあります。涙

次の記事（３０回）
↓