»IT失敗学の研究2つの意味でたいへんタメになった。ひとつめは、破綻プロジェクト事例集として。ふたつめは、「くれない君」の言い訳の反面教師として。「動かないコンピュータ」と不条理プロジェクト日経コンピュータの「動かないコンピュータ」なら比較的単純なストーリーだ。さまざまな要因で初期の目的を達成できなかったプロジェクトだからだ。予期しない不具合や無謀な計画が原因なのだが、通常これらは事態を収拾するための「火消し」が続き、なんらかのエンディングがある。本書「IT失敗学の研究」は違う。曰く「最初から動かす気がなかったし、動くはずもなかった」「どうみても計画に合理性がなかった」「危ない危ないと思っているうちに破局を迎えた」...といった不条理プロジェクト集だからだ。したがって、「動かないコンピュータ」というエンディングすら迎えない。見ても不可能なのに、予算がつくからとムリに存続させるプロジェクトや、検収・納品→動かしてみて大問題→責任者ケツまくり脱兎といったプロジェクトなど、より生々しい例が沢山載っている(Σが最たるものだが、残念なことに入ってなかった)。本書は30ものプロジェクト破綻例を、以下の3つの観点から切りこんでいる。実力不足のベンダーなるほど、本書によると、プロジェクト破綻原因は、ユーザー、(ユーザーの)情報システム部、ベンダーと3者に分類できるらしい。「ユーザー」が原因の破綻プロジェクトには、こんなのがある。ユーザーが無責任な行政だった例。選挙のスローガンとして「ITによる行政の効率化」を掲げたが、いざ当選したら、単に職員へのPC配布にとどまった。税金でベンダーが肥え太っただけ。「効率化」について議会で追及されたら「IT環境の整備」として目的がすり替えられた...情報システム部が情けない例。扱いしない例外ルート)がゴソっと抜けていて、要求仕様すら挙がっていなくて、「聞いてないよ!」と叫ぶ(でも随意契約なのでケツまくれない)事例←これは本当に痛いが、沢山見かけるあらあらまあまあ沢山ある。cost)は文字通り、埋没した原価であって、サルベージそのものがムダな運用コストを積み上げることになる。過去の投資を盾に存続にこだわる連中にはサンクコストを「見える化」してやりゃいいとか...貴重な気づきが得られた。「くれない君」の逆襲しかしだ、読んでいるうちに次第に不快になってきた。いや、破綻プロジェクトを見せ付けられたからではない。行間に潜む「書き手」の言い訳が鼻についたからだ。一度、本書の切り口を見てみよう。実力不足のベンダーこの3者のどこにも、無能なPM、無責任な営業、ダメSEが入っていないことを注意しておきたい。本書を書いた人が相当するからだ。確かに「PMにもっとコミュニケーションスキルがあれば」だとか「SEが感情的になりすぎて」といった言い訳がましい記述は出てくるが、経営者やベンダーを無能呼ばわりしているワリには、PMやSEは「優秀な」連中しか出てこない。本当か?優秀なPM・SEが投入されたにもかかわらず、プロジェクトは破綻した。理由を書く人は、当然自分に責が及ばないように書く。ヒューマンファクターを挙げ、自己の能力不足へ疑いが及ばぬように書く。○○しなかった経営陣が悪い、△△すべきだったベンダーが悪い、□□してくれなかった情報システム部が悪い...へへっ、わたしにはよく聞こえるよ、ボクは悪くないんだ!○○してくれなかったからんだ!ボクのせいじゃないんだモン!という叫びが。いう連中が書いた記事なんだなー、と行間読みながらニヤニヤ。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。