「アート・オブ・プロジェクトマネジメント」読書感想文（その2）

　これは、いわゆるHow to本ではない。プログラミングやテストと同様に、「こんなときは」→「こうする」なんて一問一答形式で答えられるような代物ではない。著者が、マイクロソフトInternet Explorerの開発プロジェクトで直面した問題と、それにどう取り組んできたかが書いてある。まさに宝の山。

■PMにとっての最重要ツール

　プロジェクトは常に一度きりのもので、過去に類似プロジェクトはあっても、同じものは無い。やるたびに変化する不思議のダンジョンのようなものに、どのように取り組んでいけばよいのか ―― 誰もがブチあたるこの難題に対し、著者はとてもシンプルな方法で考える。同様に、本書を著す際に、この方法を適用している。つまり、

　　1.　「重要な話題」に、焦点をあてる
　　2.　「重要な順」に、実行する

　この方法・順番で本書は構成されている。重要な話題から順を追って説明されている。なんだあたりまえじゃないかというツッコミは、わたしも同意。しかし、本書ではこの方法にいたるまでずいぶん考え抜いたことが分かる。

　激しく突き詰めると、PMにとって最重要ツールは優先順位が書かれたホワイトボードだ、と言い切ってもいい。ただ、そのツールにノイズが入ったり、ツールしか見なくなったり、ツールを上手く使えなかったりすることが問題なんだろう。ちょいと飛ぶが、13章でとても重要なことを言っている。

　優先順位づけによって、ものごとが成し遂げられる。特に、あなたが「ノー」という時に、ものごとが成し遂げられる

　おっと先走りすぎた。ここでは、「PMって何なの?」という観点から書かれた1章に絞る。

■アート ―― 技芸と呼ぶ理由

　お題の「アート・オブ・プロジェクトマネジメント」から察するに、なんだかテクニカルな話なんだろうなぁ… と思っていたが、あにはからんや、想像を大幅に裏切ってくれた。「プロジェクトマネジメントは芸術である」（p.13）という理由は、プロジェクトマネージャは"適切な状況下で適切な態度をとる本能"を求められるからだという。

　その具体的な態度を、トム・ピーターズ「完璧なプロジェクトマネージャの追及」/"Pursuing the Perfect Project Manager"[参照]から引いている。

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

　状況に応じこれらの"態度"を使い分けるのがミソで、このバランスを上手くとるには、直感や経験が必要だという。確かに。わたしなんざ「相手」によってこれらを使い分けている。気に入った相手や、（その行動を採っても）許される相手、ひどい場合はその日の気分によって態度を変えている（←これは、悪い例なのでマネしないように）。

　メンバーとの距離ではなく、状況に応じて最適な"態度"を採る、こりゃ確かに「技芸」の域だね。ただ、安心してほしいのは、こうしたバランスの取れた人材が見つかることはめったにないそうな。それでも自分の"態度"を一歩引いた観点で観察し、フィードバックすることの重要性は薄れないだろう。

■ホワイトボード地獄

　プロジェクトの極意は、優先順位リストを作成し、ひとつひとつ消していくことだ、ということは大昔どこかで聞きかじった。たぶんWBSのことを指していたんだと思う。

　そのサルマネの結果、お題の地獄に陥ったことがある。つまり、作業リスト、成果物リスト、課題リスト、バグリスト、プロセスチャートをホワイトボードに緻密に書き出し、リストに埋め尽くされた「作戦室」にこもっていたんだ。著者もInternet Explorer 4.0のプロジェクトで似たようなことをやっていたらしい。ただ、彼はわたしよりも優れたボスに恵まれていたようだ。

　最初のうちはプロジェクトが順調に進んでいたため、上司は私が何をやっているのか気付いていませんでした。しかし、私がチームよりもチェックリストとプロセスに時間を割いていることを知った時、大きな赤旗（警告サイン）を振ったのです。

　ある日、彼は私の部屋に入り、室内のすべての壁に貼られた、滑稽なほど巨大なチェックリストと表を見た後、私を座らせてドアを閉めました。そして、「スコット君、こういったものも悪くないが、君のプロジェクトってーのは君のチームそのものなんだよ。チェックリストではなくチームをマネジメントするんだ。このチェックリストがチームのマネジメントに役立つなら、それは素晴らしいことだ。しかし、君のやり方ではすぐにチェックリストのマネジメントをするために君のチームを使うことになるだろう」と言ったのです

　PMはプロセスや方法論に注力するのではなく、チームに注力するべき ── わたしを含め、プロジェクトに関わる全員に太文字でこの事実を伝えたいですな。ある開発プロセスの甲乙をケンケンゴウゴウと議論していた自分が情けない。ついでに○○という手法が一番などと放言していた自分も恥ずかしい。XPでもRUPでもagileでもwaterfallでも、何だって一緒、何のためのプロセスか? を考えなしに適用することは恐ろしい。この観点に立って、著者が根本から考えた結果は10章「メンバーの邪魔をしない方法」にある。そのうちここでも考察しよう。