PMBOK、ITIL、CMMIなど、ITプロジェクトマネージメントには、実に様々な（そして重厚な）手法が用いられています。とても複雑なプロジェクトというものを、きれいに体系化しているし、使いこなすことができれば、失敗プロジェクトなんてありえないような気にもなります。

しかし残念ながら、使いこなせている人やチームを*私は*みたことがありません。一般的に、本来の作業（システム構築）とはかけ離れたところで、莫大な工数をかけてしまう。ひどいときには、ソレによる作業の遅れを、またマネージメント手法で乗り越えようとして、負のスパイラルに陥ります。策に溺れるとは、こういうことですね。

これらの手法を否定はしません。でも、（従来のスタイルの）プロジェクトマネージャという１人の人間に求めるには、あまりにも責任過多なのです。

それは誰もが感じていることでしょうが、なぜか、目をつぶってしまうケースが多いように思います。

めちゃくちゃ端的な例を。

PMBOKで推奨しているＷＢＳ。
ＷＢＳとは、システム構築のための作業内容を極限まで詳細に分割して洗い出す作業のことで、スケジュールを作るための、一番オオモトになる資料です。

アレを書くことができるプロジェクトマネージャは、まずいません。
ＷＢＳを書くときは、ある程度の設計イメージが出来上がらないと、作業の詳細分割なんてできませんし、個々の作業がどれくらいの時間を要するのかも、おそらく経験者でなければわかりません。
じゃあ、PMに「技術力をつけろ」とでも言うのか？あるいは、プログラマに「PMをやれ」とでも言うのか？

PMは、プロジェクトのスケジュールを引く、という、一番最初のところで途方にくれているのです。

そこで、PMはどうするか？選択肢は３つ。

• １．だれかにWBSを作らせる
• ２．エイヤーで適当なスケジュールを引いてしまう
• ３．WBS作成会議を開催する

１．をやった時点で、PMの存在理由が消滅するような気がします。
２．をやった時点で、プロジェクトの失敗が確定します。
３．が一番正しい方法のような気がします。但し、その会議でかかった費用や時間も、ちゃんと計算してくださいね。それがWBSというものですから。

・・・別にPMいじめをしてるわけではありません。
こういう矛盾というか「PMという役割の限界」に目をつぶるな。と言いたいのです。

再び、スポーツにたとえます（前回も読んでみてください）。
スポーツのフォーメーションは、作戦板（ホワイトボードと磁石のアレ）の上で練られます。それをやる人は当然、監督です。

WBSの本質は、作戦板に似ています。
人数、個人スキル、フレームワーク、製品、相手の出方などを綿密に計算して、勝つために最高のフォーメーションを作る。
この作業をやるのは、監督であるITアーキテクトです。

PMの仕事は、金額や納期、人材やベンダーの問題を調整して、ITアーキテクトが出した作戦にコミットすることです。
この時点で、技術サイドとマネージメントサイドに、ぞくっとするほどの一体感が生まれる。

マネージメント側も、技術側も、お互いが自分の役割・権利を理解しあうことが大切だと思います。そういうパートナーを探してみては。
企業も、マネージメント一辺倒の教育ではなく、ITアーキテクトを育てる投資が必要なのではないでしょうか。

（どっちも一人でできる！という方は、どうぞ突き進んでください。）

役割が逆、
「PMが書いたWBSをアーキテクトがレビュー」なら、どうでしょう。

・・・一発でミゾができるでしょうね。
良くても、膨大な手戻り作業が待っています。

結果的に、公開スケジュール（たてまえ）と内部スケジュール（ほんね）の帳尻あわせに翻弄する、なんていうことになるのです。

まったくもって、無駄な作業です。