先日、PMI東京支部のシンポジウムにパネラーとして招かれ、参加させていただいた。テーマは「PMOはPMクライシスの救世主になれるか」で、PMO組織への期待論が中心だった。参加者は私の他に、Johnson & Johnsonのマーケティング部門の方、そしてUNIYSの方で、司会進行役がIBMの神庭さんである。外資系メーカー・エンジニアリング業界・IT業界それぞれの観点から、興味深い論議になったと思う。
PMOはProject Management Officeの略語である。複数のプロジェクトを統括してマネジメントする専門部署、というほどの意味だが、最近はどうやら流行の3文字略語になってきたらしい。例によって米国で広まりはじめ、すぐわが国にも飛び火した。おそらくシンポジウムの聴衆の中にも、PMOの名刺を持つ方が少なからずいらしたに違いない。 ところでパネル・ディスカッションが進むにつれ、このPMOという組織の位置づけについてのすれ違いが明らかになってきた。それは、簡単に言うとPMOがラインを主導するのか、あるいはスタッフとして支援に徹するのか、その違いである。あるいは、プロマネはPMO部門に所属するのかしないのか、という違いだと言ってもいい。 ちなみに、私の勤務先である日揮は、PMOという名前の組織はない。プロジェクト本部という組織があり、それとは別にエンジニアリング本部という機能別組織(電機・機械・化学・建築・制御・シビル等の設計者集団)がある。プロマネはプロジェクト本部に属して、各案件(プロジェクト)ごとに機能別組織の横串を通すマネジメントを行なう。つまり、典型的なマトリクス型組織である。 マトリクス組織のプロジェクト・チーム員は、機械エンジニアなら機械専門部の部長が上司であり、固有技術はその部長が統率する。プロマネは、管理技術に徹するわけだ。ここでは固有技術と管理技術は独立して、車の両輪となっている。 ところが、IT業界のSIerは、タスクフォース型組織をとる会社が殆どである。タスクフォース型組織では、プロマネはプロジェクト・チーム員の上司に当たる。つまり、固有技術と管理技術の両方を、ある意味では同じプロマネが面倒を見なければならないわけだ。しかも、SIerでは、プログラマ→SE→サブ・リーダ→プロマネ、というようなキャリア・パスが多い。固有技術者が進化して、管理技術のマネージャーになるという、ポケモンの進化論みたいな変身が要求される。 だからこそ、管理技術の中心であるPMOの確立が「救世主」として期待されるのだろう。PMI東京支部は、IT業界の参加者が圧倒的に多い。パネル・ディスカッションのテーマも、その問題意識が反映されたのだろう。 しかし、タスクフォース中心型組織(私はこれを「工務店方式」と呼んでいる)では、プロマネはPMOの所属にはならない。したがって、PMOは必然的に支援型スタッフになる。これで複数プロジェクトを統括管理できるのだろうか? まあ、指揮系統から言ってかなり困難だろう。もし、無理にそうした役割をPMOに期待するとなると、こんどはPMOが『本社』、各プロジェクト・チームが『工場』、みたいな関係にならざるをえない。 その場合、PMOを「頭でっかちの本社組織」にしないための工夫と制限が必要だろう。ひとつの方法は、現場と人を定期的に入れかえることである。つまり、PMO勤務経験をプロマネの必須のキャリア・パスとする。また、プロジェクト実務経験者を、PMOに転属させる。要するに、固有技術と管理技術の『両刀使い』を養成するしかない。 もともとPMBOK Guideの原型は、エンジニアリング業界や航空宇宙業界の出身者が中心になって作られた。こうした業界は機能別組織が発達している。一方、IT業界は、構造的にそういう社内体制になりにくい。米国PMI風の発想が、どうしても日本ですれ違いを生みやすいのはこのためだろう。 私の見るところ、PMO組織の確立がもっとも成功するのは、じつはSIerでも建設・エンジニアリング業界でもない。製造業・流通業における、新製品開発や上市などのプロジェクト管理である。なぜなら、こうした仕事は、必ず複数の機能部門の協力を必要とする。営業企画・研究開発・製品設計・生産技術・購買・マーケティング・物流・・等々である。しかも、こうした仕事は、たいていの場合、「プロジェクト」として位置づけられておらず、単に「案件のバケツリレー」でこなされているからだ。予算についても、スケジュールについても、誰も本当の意味でのコントロールをしていない。 このような縦割り組織において横串を通し、『プロジェクト制』を確立し、効率よく短期間で製品開発・上市を進めていくためにこそ、PMOという部門が役に立つのだ。じじつ私も、最近はこうした製品開発プロジェクトのマネジメント・システム導入をお手伝いすることが増えており、かつその効果が大きいのも見てきている。 PMOは、製品開発にとってこそ「救世主」なのだ。もっとも、まれに単なるプロジェクト・チームをPMOとよんでいるケースもあるようだ。これは遂行と統括マネジメントの区別がされていないのだろう。誤解だと言うべきなのかもしれない。
by Tomoichi_Sato
| 2006-02-08 01:22
| プロジェクト・マネジメント
|
Comments(0)
|
検索
カテゴリ
全体 時間管理術 サプライチェーン プロジェクト・マネジメント 工場計画論 リスク・マネジメント ビジネス 考えるヒント ITって、何? 書評 映画評・音楽評 English articles 思考とモデリング 最新の記事
記事ランキング
著書・姉妹サイト
ニュースレターに登録
私のプロフィル My Profile 【著書】 「世界を動かすプロジェクトマネジメントの教科書」 「時間管理術 」(日経文庫) 「BOM/部品表入門 (図解でわかる生産の実務)」 「リスク確率に基づくプロジェクト・マネジメントの研究」 【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
ブログパーツ
メール配信サービス by Benchmark 最新のコメント
ブログジャンル
画像一覧
|
ファン申請 |
||