【794】まとめ 「現役のPMに贈ること」-23- | キットPM奮闘記 改め キットビジネスアナリスト奮闘記

キットPM奮闘記 改め キットビジネスアナリスト奮闘記

PMの世界からビジネスアナリストへ、キットPM2.0を目指して奮闘中です。BAを超上流とか言いますが、当たり前のようで難しいビジネス要件をどうやればちゃんとまとめられるのか、皆さんとご一緒に考えていきます。

日の蒸し暑さには参ってしまいます。肉体的、精神的なダメージが結構ジワジワと来ています。さすがにこの時期の通勤は辛いですね。さぁ今週もあと二日、頑張りましょう。

 

 
プロジェクト体制の狭間で -4-
 
  前回からプロジェクトにおける体制(プロジェクト)の多層化について考えています。
 
    一つの例として、プロジェクトの主体となる組織とITベンダーによる二重化を上げました。もちろんベンダーはクライアントの目的を共有し、その実現に力を尽くすわけですが、損してまでそれを行うことはありません。昔は「損して得を取る」などと営業主体で無理をするという事もありましたが、今ではそのようなことは影を潜め、利益を基準とする考えになっています。
 
    つまりクライアントのプロジェクトに寄り添いながらも、自社の目的=利益を追い求めることになります。時としてここに軋轢が生じることがあるのは、皆さんご承知の通りです。
 
    この例は分かりやすい構造ですが、これに下請け会社への再発注が絡むとちょっと複雑になっていきます。
 
 
 
    また同じ組織の中でも、業務部門とIT部門でも同じような構造ができ上がります。ここに先ほどのベンダーが絡んで来ると言うのが一般的な構図ではないでしょうか。
 
    この時、この3重から4重におよぶ利害関係が異なるチーム(体制)がそれぞれの思惑で動くことを排除するために、全体を一つのプロジェクトとしてとらえ、マネジメントすることが重要になります。ただ理屈としてはそうなんですが、これがなかなか難しいわけです。最初に述べたように、それぞれの立場での思惑の違い、お金の流れによるパワーバランス、組織の文化的、歴史的な背景などなかなか複雑な要素が絡みあって、必然として出来上がっているのがプロジェクト体制だからです。
 
  もし理想のプロジェクト体制を目指すのであれば、様々なしがらみを排除して権限と情報を一点に集中させ、チームマンジメントでコントロールするということになりますが、やはり難しいですね。
 
  このような状況を避けるための第一の方法は、プロジェクト・スポンサーのリーダーシップの在り方を明確にすることです。またプロジェクトをいくつかに細分化し、プロジェクトマネジメントとプロジェクトの集合体であるプログラムマネジメントを切り離して、体制をつくることが有効になります。
 
 
  今朝は時間的な余裕があまりないので、今日はここまでとします。次回は複雑な体制をどう整理し、よりよい体制を創るにはどうするかを考えていきます。