IT失敗学の研究

　2つの意味でたいへんタメになった。ひとつめは、破綻プロジェクト事例集として。ふたつめは、「くれない君」の言い訳の反面教師として。

「動かないコンピュータ」と不条理プロジェクト

　日経コンピュータの「動かないコンピュータ」なら比較的単純なストーリーだ。さまざまな要因で初期の目的を達成できなかったプロジェクトだからだ。予期しない不具合や無謀な計画が原因なのだが、通常これらは事態を収拾するための「火消し」が続き、なんらかのエンディングがある。『IT失敗学の研究』は違う。曰く「最初から動かす気がなかったし、動くはずもなかった」「どうみても計画に合理性がなかった」「危ない危ないと思っているうちに破局を迎えた」…といった不条理プロジェクト集だからだ。

　したがって、「動かないコンピュータ」というエンディングすら迎えない。どう見ても不可能なのに、予算がつくからとムリに存続させるプロジェクトや、検収・納品→動かしてみて大問題→責任者ケツまくり脱兎といったプロジェクトなど、より生々しい例が沢山載っている（Σが最たるものだが、残念なことに入ってなかった）。

破綻プロジェクトの事例集

　本書は30ものプロジェクト破綻例を、以下の3つの観点から切りこんでいる。

　　　　1. 無責任なユーザー経営者
　　　　2. 頼りなき情報システム部
　　　　3. 実力不足のベンダー

　なるほど、本書によると、プロジェクト破綻原因は、ユーザー、（ユーザーの）情報システム部、ベンダーと3者に分類できるらしい。例えば「ユーザー」が原因の破綻プロジェクトには、こんなのがある。

• ユーザーが無責任な行政だった例。選挙のスローガンとして「ITによる行政の効率化」を掲げたが、いざ当選したら、単に職員へのPC配布にとどまった。税金でベンダーが肥え太っただけ。「効率化」について議会で追及されたら「IT環境の整備」として目的がすり替えられた…
• 情報システム部が情けない例。通信コストを下げるためにシステム更改をしたいのだが、元のシステムの通信方式の見積もりの甘さが露呈して、責任問題となってしまうため、言い出せないでいる事例
• 現場の声を無視し、ユーザーの言うとおりに作ったら、非効率コスト増となることは目に見えているのだが、ベンダーとしては儲かるので、良心はちょっと傍へどいてもらって受注する、という事例
• レガシー更改プロジェクトで、テストまでトントン拍子に行ったけど、準正常系ルート（exception 扱いしない例外ルート）がゴソっと抜けていて、要求仕様すら挙がっていなくて、「聞いてないよ！」と叫ぶ（でも随意契約なのでケツまくれない）事例←これは本当に痛いが、沢山見かける

　あらあらまあまあ沢山ある。勉強になったぞ。例えば、役所相手のプロジェクトは、「隠し仕様」「3年でメンバー交代」などで、役所プレミアムを受注額に上乗せしておくべきだとか、サンクコスト（sunk cost）は文字通り、埋没した原価であって、サルベージそのものがムダな運用コストを積み上げることになる。だから過去の投資を盾に存続にこだわる連中にはサンクコストを「見える化」してやりゃいいとか…貴重な気づきが得られた。

「くれない君」の逆襲

　しかしだ、読んでいるうちに次第に不快になってきた。いや、破綻プロジェクトを見せ付けられたからではない。行間に潜む「書き手」の言い訳が鼻についたからだ。もう一度、本書の切り口を見てみよう。

　　　　1. 無責任なユーザー経営者
　　　　2. 頼りなき情報システム部
　　　　3. 実力不足のベンダー

　この3者のどこにも、無能なPM、無責任な営業、ダメSEが入っていないことを注意しておきたい。なぜなら、本書を書いた人が相当するからだ。確かに「PMにもっとコミュニケーションスキルがあれば」だとか「SEが感情的になりすぎて」といった言い訳がましい記述は出てくるが、経営者やベンダーを無能呼ばわりしているワリには、PMやSEは「優秀な」連中しか出てこない。本当か?

　優秀なPM・SEが投入されたにもかかわらず、プロジェクトは破綻した。理由は? 理由を書く人は、当然自分に責が及ばないように書く。あるいは予めヒューマンファクターを挙げ、自己の能力不足へ疑いが及ばぬように書く。○○しなかった経営陣が悪い、△△すべきだったベンダーが悪い、□□してくれなかった情報システム部が悪い…へへっ、わたしにはよく聞こえるよ、ボクは悪くないんだ！○○してくれなかったからんだ！ボクのせいじゃないんだモン！という叫びが。

　そういう連中が書いた記事なんだなー、と行間読みながらニヤニヤ。どうしてそんなことが分かるかって? そりゃ、叫んだことあるからに決まってるでしょー