修羅場シミュレーション「間違いだらけのシステム開発」
燃えるプロジェクトに投下され、火消し&延焼抑止に奔走し、落ち着いたころに引き抜かれ、次へ… そのたびに、心労で胃痛になるか、ストレス食いで太るか。
失敗プロジェクトなら、必ず現場がゾンビ化するとは限らない。腐敗は脳（上層部）から始まり、皮膚の内側（見えないところ）で進行する ←これかなり重要
たとえば、問題なくリリースまで至るが、一銭たりとも支払われなかったとき。次 ver.で費用は見てやるからさ、それまでにこの要件を「追加」として扱わないで作ってよ… というパターン。承諾しないPMは疎まれ、事情を知ったメンバーは総替え（あるいは脱出）する。そして、次の人にお鉢がまわってくる―― いっさいの事情を聞かされずに、警告すらされないまま。さあ、修羅場のはじまりだ …
…なんてね、知人の話だよ（棒読み）。
「間違いだらけのシステム開発」では、そんな笑えない知人の話がたくさんある。どいつもこいつも生々しい。読んでるこっちも胃が痛くなってくる。
それを、事情を知らずに引き継ぐとか…
それでも、達成が困難だからといって役割を放り出すことはできない。ピッチャーの球が速いからこのイニングは出ない、なんて許されないことと一緒。ITプロジェクトの失敗事例を徹底的に収集した「IT失敗学の研究」（レビューは[ココ]）と偉い違う。「失敗したのはボクのせいじゃないモン！」という書き手の被害者意識と対照的に、さすがコンサルタント、冷静に非情に分析している。対策もロジカルに納得できるものばかり… なんだが、なんかこう、「熱」が伝わってこない。
どうしてなんだろう、と考え考え読むうちに、思い当たる→「一人称」がないんだ。つまり、「私なら」や、「私の場合」で書かれる打ち手がなく、徹頭徹尾べき論に閉じて書かれているんだ。おそらく執筆者（たち）のキャリアと、今の顧客を考慮してこうなったんだろう。あるいは、一人称で書くと辛いこと思い出してしまうからか?
だから、読んでるこっちは「そのとおりだ」とは思っても、「わたしが」どうしていいか分からない。具体化は各自でってことになる。
- 開発プロセスを標準化しましょう
- ステークホルダー間の調整を密にして死角を作らないようにしましょう
- 情報システム部門がイニシアチブをとってプロジェクトマネジメントしましょう
そんなことは知ってるってば！批評家になって、間違いだらけと指摘するのはいいけれど、書いてるアンタがどうあがいたのかを教えてくれ！その体験談こそが宝なんだよっって叫びながら読む。
システム開発の落とし穴は、たくさんある。しかも、分かりやすくある。そこあることが予め充分に承知してる。分かっていながら落ちるんだ。こんなこと書くと「そこにあるの知ってて落ちるなんてバカぁ? 」と思われるかもしれない。そう、確かにその通り。
それでも、そこにあることが分かってても落ちるのが、システム開発の罠なんだ…というシンプルな事実を再認識させてくれる。いかにもありそうな落とし罠で、誰でも一度や二度三度と陥ったことがあるはず。
しかし、どんな罠（裏事情）か分かって落ちるのが幸せか、知らずに火だるまになるのが幸せかというと―― これ読んで予めシミュレートしておいた方がいいに決まってる。そういう疑似体験（覚悟ともいう）ができる本として、これは非情に非常に価値がある一冊だ。
ただ、一点だけウソがある。それは、どんな残酷物語でも、ラストでは頑張ってやりおおせました、めでたしめでたし… で終わってるとこ。ウソつけ～ そのモデルとなったプロジェクトが、本当はどういう結末を迎えたのか… いや、やめておこう、知りたくない。知らないほうが幸せなのかもしれない。
| 固定リンク
コメント