火事になる前に読んでおきたい「火事場プロジェクトの法則」

　問題プロジェクト・失敗プロジェクト・デスマプロジェクト ── 呼び名は沢山あれど、振り返ったとき、ああすればよかった、こうすればよかったという反省や後悔（?）は、これまた沢山ある。

　「あの営業連中のコトバを鵜呑みにしなければ…」
　「新技術に手を出す範囲を限定しておけばよかった」
　「もっと顧客に張り付いて仕様を搾り出しておくべきだった」
　「なんであのとき、SOSをださなかったのか！なんで問題を放置したんだ！」
　…

　過去のプロジェクトを眺めたとき、問題点はいくらでも出てくる。おそらく携わった人の数だけ出てくるだろう。

　それにもかかわらず、これから出くわしたとき、どうすればよいかは、分からない。なぜなら、どんな問題に遭遇するか分からないから。プロジェクトが特殊性、一時性をもつように、それにまつわる問題も同様に、特殊性をもつ。したがって、その解決策は、常にその問題専用の解法でしかない ──

　── これは、本当だろうか?

　確かに、プロセス、方式、メンバー、リソース、ビジネス環境によって問題の原因は違って見えるかもしれない。しかし、実際にシステム開発プロジェクトが破綻するとき、どこかで見たような/聞いたような/読んだようなスメルを放つのはなぜだろうか? それは、プロジェクトで顕在化する問題は人に因るからだ。

　システムは人がつくるもの。だから、システム開発の問題は、人の問題。これは、デマルコ著「デッドライン」[参照]で気づかされたが、本書ではもっと体系立てて、4つの切り口で捉えている。

　　・バードビュー（鳥瞰・俯瞰）
　　・コミュニケーション（情報と意思の伝達）
　　・エモーション（相手を思いやる気持ち）
　　・フィードバック（後悔でなく反省）

　この4つの視点から、プロジェクト失敗の症状と原因を見通している。ともすると、どれかに拘泥しがちだが、バランスよく配分されている。この視点を使えば、PMだけでなく、誰でもプロジェクトのヘルスチェックができ、症状の裏側にある本当の原因を探ることができる。

　さらに、「人の問題」とした瞬間、誰か（安請合営業、無理難題顧客、無能上司、技術馬鹿）を悪者にしてしまえば済む、という落とし穴が待っている。しかし、本書では「誰か」を探して非難するよりも、まず自分ができることは何か? を問いかける。この姿勢は見習いたい、というか見習うべき（→わたし）。

　デスマ対策を謳った書籍は多かれど、開発現場の視点からここまで明快に解き明かした本はないだろう。失敗プロジェクトから「脱出」したり、「間違いだらけ」と論評したりする本は、それなりに参考になるものの、「ボクのせいじゃないモン」という言い訳がこうばしい。その一方で、本書からは「人の問題」≒「それは自分の問題かもしれない」と謙虚に向き合おうとしている。

　プロジェクトが火に包まれるとき、本どころではない。寝る時間どころか、うんこしている時間すらないんだぜ！だから、そうなる前に読んでおきたい。仕事に追い詰められると、正気が保てなくなる。「おまえのバグだゴルア！」と殴りあうこともある（わたしじゃないよ！）、あるいは、「わびるならそこで死んでみろ！」と顧客に罵倒されることもある（わたしじゃないよ！）。悪臭にまみれて殺伐とした中、くじけそうなとき、本書は心の支えになってくれるかもしれない。根性論は禁物なんだけど、再読することで勇気がわいてくるかも。

　… というわけで、いまのうちに読むのが吉。