アート・オブ・プロジェクトマネジメント(1)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

作者: Scott Berkun,村上雅章
出版社/メーカー: オライリー・ジャパン
発売日: 2006/09/07
メディア: 単行本（ソフトカバー）
購入: 20人クリック: 361回
この商品を含むブログ (186件) を見る

1章プロジェクトマネジメントの簡単な歴史

歴史から学ぶ3つの教訓

ソフトウェア開発という範疇にとらわれずに，エンジニアリングプロジェクトという歴史のなかのさまざまな事例調査によって得られた重要な教訓が次の3つです．

プロジェクトマネジメントとソフトウェア開発は神聖な芸術ではない
作業をよりシンプルな視点から見ることで，よりパワフルに，より集中できるようになる
シンプルは簡単ということではない

1つめは，エンジニアリングを難しくするものの核心の大半は実はそんなに変わっていなく，プログラミング言語や開発方法論すべてにおいて，その独特の部分と何かから派生した部分をという双方の観点で考えることができるということです．

2つめは，視野狭窄に陥ることなく，作業をシンプルな視点から定期的に見直すことで，有益な比較ができ代替案を考えられるようになるということです．シンプルとは，禅でいう初心，オープンマインドという考え方で，心を空っぽ(空の器)にして考えてみるようなことだと思います．

3つめは，一流の人たちは，本質を｢シンプル｣かつ｢難しいもの｣として理解しているということです．リーダーシップやマネジメントも難しいものの，その本質はシンプルなこと，つまり

特定の目標に向かって特定の方法でものごとを成し遂げるだけ

なのだそうです．

プログラムマネージャ

マイクロソフトでは，エンジニアリングの取り組みとマーケティング/ビジネスの取り組みとのすり合わせを考える上で，リーダーシップ役と調整役という2つの役割の必要性に気付きました．この2つの役割を併せ持った新しい役割は，｢プログラムマネージャ｣と呼ばれるようになったそうです．

こういった特殊な作業をこなす人物は，プログラマとともに作業し，彼らからの尊敬を得るだけの技術的な素地を持っているだけではなく，製品完成までの多様な作業にあたることのできる才能を備え，かつ，それらの作業に対する興味を持っている必要があります．こういった役割を担う人物は，仕様書の記述，マーケティング企画のレビュー，プロジェクトスケジュールの立案，チームの指揮，戦略の立案，バグ/欠陥の優先順位付け，士気の鼓舞，誰かが(ちゃんと)作業できていない場合のフォローといったさまざまな作業を苦もなくやり遂げる必要もあります．

マネージャに技術的な素養(実務能力)が必要かどうかという議論は頻繁にされ，どっちの意見もそれなりに根拠はあるのでしょうが，僕は，マネージャといえども技術的な素養をもっているべきだという上記の意見に賛成です．このプログラムマネージャという役割ですが，僕なりの解釈はこんな感じです．

プログラムマネージャ＝技術的な素養＋ビジネスの知識＋リーダーシップ

バランス感覚

優れたPMが職務を全うする上で，｢バランスの取れた態度｣が必要と説明し，トム・ピーターズ - ｢Pursuing the Perfect Project Manager｣のエッセイを引用しています．

プロジェクトマネージャは，こういった態度の存在に気付くだけではなく，適切な状況下で適切な態度を取るという本能を磨いておく必要があるわけです．そしてこういった考え方から，プロジェクトマネジメントは芸術であるという考え方が生まれるのです．

エゴ/非エゴ
独裁/委譲
曖昧さの許容/完全性の追及
口頭/文書
複雑さの容認/簡潔さの支持
焦り/忍耐
勇気/恐れ
信者/懐疑論者

この領域の話は，とても定性的であり，人間性といってしまえばそれまでかもしれません．先天性なのかはたまた後天性なのかで意見がわかれる部分でもあり，こういったバランス感覚というか本能を鍛えることが，本当にできるのかもよくわかりません．でも，たしかに優秀なPMといわれる人は，こういったバランス感覚が優れれているのは確かですよね．僕の周りをみてもやはりそう感じます．

自分がうまくバランスできているかは自分自身ではわかりかねますが，無意識にこういった判断をしていることは事実です．そこで僕はよく周りの人に意見を聞くようにしています．こまめなフィードバックを積極的にかけているのです．｢さっきの判断はどうおもった？｣｢指示の粒度は適切だったかなぁ？｣｢こうも考えた末にこうしたんだけど，どう思う？｣などと聞きます．賛成意見よりもむしろ反対というか自分はこう思ったといった意見を重要視するのがポイントです．貴重なメンバーの本音が聞けて，自分の偏りがちなバランス感覚を正常に保つのには，結構役に立ちます．

プロセスと目標を取り違える

役割を定義すれば組織化はできます，またチェックリストを使えば作業の進行を支援することはできます，しかし，役割分担やチェックリスト自体が目標になるわけではないということです．プロセスと目標を取り違えることは，マネジメントにおける大罪の1つですと述べており，Scott Berkun 自身も，実際にそういったことをしてしまったことをエピソードで書いています．

ここで非常に重要な示唆が述べられています．

プロジェクトマネージャは，プロセスや方法論に注力するのではなく，チームに注力するべきなのです．
計画や追跡システムは，チームがプロジェクトの目標を達成するために役立つものでなければならず，邪魔をするものであってはならないのです．

これ，はまりがちですよね．よろしくないことに，いったんはまるとメンバーはそれを敏感に察知して，｢また意味無いことやってるよぉ｣という意識が蔓延しさらにPMとメンバーが乖離していくという，悪循環に陥ってしまいます．これプロジェクトが崩壊する典型ですね．

価値を生み出す

プロジェクトマネージャはチームのメンバーともっとも長い時間を過ごしているという事実から，PMが何かに注力する場合，何かを表明する場合，何かに熱狂する場合，成功できるだけの有能さを持ち合わせている場合，他のメンバー全員も同じように振舞う可能性が高くなると書かれています．また，PMの喜怒哀楽は，会う人すべてに影響を与えます．PMがプロジェクトにもたらすものは，良きにつけ悪しきにつけ，チームに伝染していくのですとも書かれています．

これは，本当に気をつけておかなければならないことだと身をもって実感します．よく楽観的なリーダーは成功するという話を聞きますが，それと同じことですね．簡単なプロジェクトはあまりないとは思いますが，困難なプロジェクトであれば特に，PMの苦悩や迷いが周りに伝播しやすく，それがメンバーの不安を煽り失敗へとつながっていくと感じます．

また，PMはプログラマ部隊を戦場に導くことのできるカリスマ性を有した，恐れを知らないヒーローであれと主張しているのではなく，こう言っています．

チームメンバーの宿題を手伝ってあげたいと純粋に思い，それがうまくいくように懸命に努力するだけで十分なのです．
つまるところ，誰も傷つけず，チームに正しく関与している限り，よいものを作り上げるということだけを考えていればよいというのが，私の信じている核となるアイデアです．

参考文献

｢禅へのいざない｣
｢The CHAOS Report｣ http://standishgroup.com/sample_research/
｢人はだれでもエンジニア - 失敗はいかにして成功のもとになるか｣
｢コード・ブルー - 外科研修医救急コール｣
｢人月の神話｣
｢10日で学ぶMBA｣