プログラミングやテストと同様に、「こんなときは」→「こうする」なんて一問一答形式で答えられるような代物ではない。Explorerの開発プロジェクトで直面した問題と、それにどう取り組んできたかが書いてある。■PMにとっての最重要ツールプロジェクトは常に一度きりのもので、過去に類似プロジェクトはあっても、同じものは無い。誰もがブチあたるこの難題に対し、著者はとてもシンプルな方法で考える。同様に、本書を著す際に、この方法を適用している。「重要な順」に、実行するこの方法・順番で本書は構成されている。重要な話題から順を追って説明されている。なんだあたりまえじゃないかというツッコミは、わたしも同意。本書ではこの方法にいたるまでずいぶん考え抜いたことが分かる。激しく突き詰めると、PMにとって最重要ツールは優先順位が書かれたホワイトボードだ、と言い切ってもいい。そのツールにノイズが入ったり、ツールしか見なくなったり、ツールを上手く使えなかったりすることが問題なんだろう。飛ぶが、13章でとても重要なことを言っている。優先順位づけによって、ものごとが成し遂げられる。あなたが「ノー」という時に、ものごとが成し遂げられるおっと先走りすぎた。ここでは、「PMって何なの?」という観点から書かれた1章に絞る。思っていたが、あにはからんや、想像を大幅に裏切ってくれた。「プロジェクトマネジメントは芸術である」(p.13)という理由は、プロジェクトマネージャは"適切な状況下で適切な態度をとる本能"を求められるからだという。Manager"[参照]から引いている。状況に応じこれらの"態度"を使い分けるのがミソで、このバランスを上手くとるには、直感や経験が必要だという。わたしなんざ「相手」によってこれらを使い分けている。気に入った相手や、(その行動を採っても)許される相手、ひどい場合はその日の気分によって態度を変えている(←これは、悪い例なのでマネしないように)。メンバーとの距離ではなく、状況に応じて最適な"態度"を採る、こりゃ確かに「技芸」の域だね。安心してほしいのは、こうしたバランスの取れた人材が見つかることはめったにないそうな。それでも自分の"態度"を一歩引いた観点で観察し、フィードバックすることの重要性は薄れないだろう。■ホワイトボード地獄プロジェクトの極意は、優先順位リストを作成し、ひとつひとつ消していくことだ、ということは大昔どこかで聞きかじった。WBSのことを指していたんだと思う。そのサルマネの結果、お題の地獄に陥ったことがある。作業リスト、成果物リスト、課題リスト、バグリスト、プロセスチャートをホワイトボードに緻密に書き出し、リストに埋め尽くされた「作戦室」にこもっていたんだ。4.0のプロジェクトで似たようなことをやっていたらしい。彼はわたしよりも優れたボスに恵まれていたようだ。最初のうちはプロジェクトが順調に進んでいたため、上司は私が何をやっているのか気付いていませんでした。私がチームよりもチェックリストとプロセスに時間を割いていることを知った時、大きな赤旗(警告サイン)を振ったのです。ある日、彼は私の部屋に入り、室内のすべての壁に貼られた、滑稽なほど巨大なチェックリストと表を見た後、私を座らせてドアを閉めました。「スコット君、こういったものも悪くないが、君のプロジェクトってーのは君のチームそのものなんだよ。チェックリストではなくチームをマネジメントするんだ。このチェックリストがチームのマネジメントに役立つなら、それは素晴らしいことだ。わたしを含め、プロジェクトに関わる全員に太文字でこの事実を伝えたいですな。ある開発プロセスの甲乙をケンケンゴウゴウと議論していた自分が情けない。ついでに○○という手法が一番などと放言していた自分も恥ずかしい。考えなしに適用することは恐ろしい。この観点に立って、著者が根本から考えた結果は10章「メンバーの邪魔をしない方法」にある。そのうちここでも考察しよう。ある日、彼は私の部屋に入り、室内のすべての壁に貼られた、滑稽なほど巨大なチェックリストと表を見た後、私を座らせてドアを閉めました。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。