前回の動かないコンピュータ・フォーラムでは，「動かないコンピュータ経験は役立つか 」と題して，システムに関連する自らの失敗体験を，その後のシステム開発プロジェクトに教訓として生かしているかどうか，あるいはどう生かすべきかについて尋ねました。このテーマに対して，100件を超すご意見をいただきました。ありがとうございました。
前回と今回のフォーラムの内容は，日経コンピュータ10月17日号の特集「その後の動かないコンピュータ」にも生かしました。最新号をはじめとした日経コンピュータは，こちらのページからお求めいただけます。よろしければご覧ください。
失敗経験を生かせない
本題に入ります。前回のフォーラムの結果で，記者は強いショックを受けました。「動かないコンピュータ経験は，その後の御社のIT戦略やシステム開発・運用に生きていますか」とお伺いしたところ，「生きている」という回答が全体の27％に過ぎなかったことです。これに対して，「生きていない」という回答は38％に達しました。
一方で，自らが動かないコンピュータを経験されたという方は，回答者全体の80％を超えました。ご意見をいただいた方の大半は動かないコンピュータを経験されているわけです。当事者としてはつらく，企業としての業績に悪影響を与える経験をしたにもかかわらず，4分の1強しかこの体験を生かすことができていないのです。
実際に自らが動かないコンピュータ経験を教訓にできなかったという方のご意見も多数あります。このご意見はユーザーかベンダーかを問いません。
システムに問題があるという事実そのものが隠蔽される。ひどい場合はそのシステムの存在自体がなかったことにされる。結果として，携わった関係者だけしか教訓を得ない。かつ成功の経験は派手に宣伝されるが失敗の経験は議事録にすら残らない。
失敗を失敗として認めず，すべてベンダーへ責任転嫁した結果，ベンダーのみ悪者となり，失敗内容が公開されていない
システムインテグレータとして自社や顧客のさまざまな案件（自分がかかわったものも，そうでないものも含め）を見てきたが，すべての失敗プロジェクトは反省されることがなかった。反省会のようなものを形式上開いても，二度と起さないことにコストをかけようという意識はほとんどなく，次にどう売るかという話になりがちだ。または，担当の配置転換で終わらせてしまう。もちろん失敗の責任をどう取るかという話は人事評価の問題として存在するが，それと切り離した形でプロジェクトの評価を行うことがない。それが，教訓を次に引き継げない大きな理由だと思える。
今回私が参画しているプロジェクト以前にも，同様な失敗プロジェクトは数件あったが，失敗プロジェクトの原因分析を（おそらく意図的に）避けているから。
「事実そのものが隠蔽される」，「失敗を失敗として認めず」，「（おそらく意識的に）避けている」といったことは，すべて重要なご指摘でしょう。このほかに記者の経験では，実態としては失敗プロジェクトなのにもかかわらず，成功だと判断している例もあります。最近の話ですが，ある失敗事例を成功事例としてベンダーが大々的に広告したケースがありました。
まず失敗プロジェクトを失敗と認め，これを客観的に分析しなければ教訓を得られないのは当然のことです。プロジェクトの推進者や当事者が責任を取ることを避けたいのは分かりますが，長い目で見れば隠蔽体質にはマイナスの面しかないでしょう。
少し本題からずれるかもしれませんが，みなさんは「失敗知識データベース」というWebサイトがあるのをご存じでしょうか。科学や技術に関連するさまざまな分野の事故や失敗の事例を掲載したうえで，その内容を分析してデータベース化しているものです。システム開発プロジェクトについても，失敗を公表してデータベース化する試みがあってよいのではないでしょうか。このアイデアについては以前，このフォーラムで提案された方がいらっしゃいました。動かないコンピュータを減らすためには，真剣にこのアイデアを検討すべきかしれません。
上流工程の失敗に対する悔恨
もちろん，「動かないコンピュータ」経験を教訓として生かしているというご意見もいただいています。どのご意見も実際に動かないコンピュータを経験された方のものであり，強い説得力があります。
このフォーラムでも何度となく指摘がありましたが，上流工程をいかに正しく進めるかが重要だという教訓を何人もの方からいただきました（引用部分は前半が教訓であり，後半が教訓の元となった動かないコンピュータ経験です）。
