呼び名は沢山あれど、振り返ったとき、ああすればよかった、こうすればよかったという反省や後悔(?)は、これまた沢山ある。「なんであのとき、SOSをださなかったのか!なんで問題を放置したんだ!」...過去のプロジェクトを眺めたとき、問題点はいくらでも出てくる。携わった人の数だけ出てくるだろう。それにもかかわらず、これから出くわしたとき、どうすればよいかは、分からない。どんな問題に遭遇するか分からないから。プロジェクトが特殊性、一時性をもつように、それにまつわる問題も同様に、特殊性をもつ。これは、本当だろうか?確かに、プロセス、方式、メンバー、リソース、ビジネス環境によって問題の原因は違って見えるかもしれない。それは、プロジェクトで顕在化する問題は人に因るからだ。システムは人がつくるもの。システム開発の問題は、人の問題。これは、デマルコ著「デッドライン」[参照]で気づかされたが、本書ではもっと体系立てて、4つの切り口で捉えている。・バードビュー(鳥瞰・俯瞰)・コミュニケーション(情報と意思の伝達)・エモーション(相手を思いやる気持ち)・フィードバック(後悔でなく反省)この4つの視点から、プロジェクト失敗の症状と原因を見通している。ともすると、どれかに拘泥しがちだが、バランスよく配分されている。この視点を使えば、PMだけでなく、誰でもプロジェクトのヘルスチェックができ、症状の裏側にある本当の原因を探ることができる。)を悪者にしてしまえば済む、という落とし穴が待っている。この姿勢は見習いたい、というか見習うべき(→わたし)。デスマ対策を謳った書籍は多かれど、開発現場の視点からここまで明快に解き明かした本はないだろう。失敗プロジェクトから「脱出」したり、「間違いだらけ」と論評したりする本は、それなりに参考になるものの、「ボクのせいじゃないモン」という言い訳がこうばしい。その一方で、本書からは「人の問題」≒「それは自分の問題かもしれない」と謙虚に向き合おうとしている。プロジェクトが火に包まれるとき、本どころではない。寝る時間どころか、うんこしている時間すらないんだぜ!だから、そうなる前に読んでおきたい。仕事に追い詰められると、正気が保てなくなる。「おまえのバグだゴルア!」と殴りあうこともある(わたしじゃないよ!)、あるいは、「わびるならそこで死んでみろ!」と顧客に罵倒されることもある(わたしじゃないよ!)。悪臭にまみれて殺伐とした中、くじけそうなとき、本書は心の支えになってくれるかもしれない。根性論は禁物なんだけど、再読することで勇気がわいてくるかも。いうわけで、いまのうちに読むのが吉。[やまざきの「あせらず、くさらず、一歩づつ」]火事プロ本、順調に売れているようで、ありがとうございます。購入に踏み切れない方々、最後の(いや、たぶん思い出したらまたすると思うけど一応区切りとして)お知らせ&告知です。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。