要求仕様があいまい，見積もり手法が確立していない，プロジェクト・マネジメント手法が未成熟・・・。システム構築プロジェクトのスムーズな遂行を阻害する原因は，10年前からあまり変わっていない。失敗の原因が分かっているのに，繰り返すのはなぜだろうか。
そんな思いから，日経システム構築では2004年2月から7月まで「なぜ繰り返すのか 失敗プロジェクト」を連載した。プロジェクトを破たんに導いた責任の所在を明らかにしようという試みで，巻末のモノクロ・ページでの掲載にもかかわらず，たいへんな好評を博した。
連載終了から数カ月。弊誌は数多くの事例記事を掲載しているが，残念ながら状況が好転してきたという雰囲気は感じられない。2年半前のメガバンク誕生時のトラブルのような強烈な印象を残すものは目に付かなくなってきたが，現場レベルでの遅延や予算オーバー，システム障害との闘いはまだまだ続いている。
「日経システム構築」で最近取材した事例から，自動販売機の販売状況管理/需要予測システムで苦労した飲料メーカーA社の話をピックアップしてみる。
A社は，営業所に分散配置しているサーバーの統合を視野に入れ，1億円を投じて最高レベルのスペックを持つWindowsサーバーを購入した。初の基幹系のオープン開発に挑んだが，スケジュールは遅延した。開発中，PHSを利用した通信系で問題が発生。その原因分析と修正に手間取り，本稼働が8カ月遅れてしまったのだ。さらに2年後，十分なスペックを用意していたにもかかわらず，肝心のサーバー統合ができず，UNIXサーバーへ入れ替えざるを得ない状況に陥ってしまった。原因は，予想を上回るデータ増と無計画に別システムを同じサーバー上で稼働させてしまっていたことだった。
A社のサーバー統合失敗のいきさつは，システムの利用者からは見えない。ただ，技術者を主な読者とする弊誌の立場から言えば「とりあえずエンドユーザーが気付かなければOK」と言い切ってしまうのは，少々はばかられる。
プロジェクトは一般的には「納期」「コスト」「品質」を満たせなければ成功とは言えない。加えて，機能要件や性能要件を満たしたとしても保守性の悪いプログラムを作ってしまっていいのか？ 使われずに放置されてしまうシステムを作ってしまっていいのか？ メンバーが日常的に体調を壊したり失踪したりする職場環境でいいのか？ ――そんな思いがいつもある。
手を尽くして困難を乗り越える，または何とか帳尻を合わせる関係者の努力に，いつも頭が下がる思いがする。その一方で，なぜ同じようなケースが繰り返し起こるのか，専門誌の記者として知りたいし，それを媒体を通じて読者の方にフィードバックしたい。挑み甲斐のあるプロジェクトであるほど，100％の満足が現実には不可能としても，その理想にどこまで肉迫できるか。それを継続して追求したい。
今，考えている観点は2つ。
第1に，プロジェクトにかかわった人たちが後から振り返って，そのプロジェクトをどう評価するのか。いわば自己評価を知りたい。これは，プロジェクトの成功/失敗を特に現場の人たちがどのように判断しているかを考えるためである。
第2に，成功/失敗プロジェクトの分岐点を知りたい。「あの時，こうしていれば・・・」という後悔や「あれがあったからこそ・・・」という決断や幸運が，多くのプロジェクトにはあるだろう。そのターニング・ポイントを突き止めたい。それを抽象化していけば，意外とシンプルなところに結論が浮かび上がってくるような気がする。
それを知るための第一歩として，IT Proを通じて以下のアンケートを実施することにした。現場からの声を，編集部に届けていただけないだろうか。いただいたご意見や，今後の取材の結果は，日経システム構築の誌面やIT Proを通じて，皆さんにお伝えしていきたいと考えている。
（尾崎 憲和＝日経システム構築）
【追記：2004年11月26日】 本アンケートの回答受付は締め切らせていただきました。ご協力いただき，誠にありがとうございました。
