「要求定義がスケジュール通り進まず開発を見切り発車。その結果，1000を超える仕様変更が発生した」――。昨年11月に公開した記者の眼「なぜ繰り返すのか，失敗プロジェクト」のアンケートには，トラブルに直面するシステム構築の現場から多くの声をいただいた。
一部のプロジェクト担当者には取材を了承していただいた。インタビューを通じ，原因や再発防止策の掘り下げを開始したところだ。回答数は640件。協力していただいた方には，この場を借りてお礼申し上げます。
短期開発に耐え切れない
 |
| 図1●最近1年間で構築に関わったプロジェクトでどのようなトラブルを経験しましたか 複数回答。有効回答数は640 |
 |
| 図2●経験したトラブルはどこに原因があるとお考えですか 複数回答。有効回答数は640 |
アンケートには「自由記入欄」も用意した。「ソフトウエア開発は複雑化しているにもかかわらず，社内の分業体制が確立されておらず，不十分なスキルしか存在しない」「プロジェクト・リーダーの言うことがコロコロ変わるために，変更費用がかさんだ」「テスト・フェーズで新たな要件を知るなど意思疎通のまずさが露呈し，次第に『動けば良い』というムードが支配するようになった」――。そこには，プロジェクトがうまく進まないことへの，「悩み」や「怒り」，あるいは「あきらめ」があふれていた。
冒頭の「1000を超える仕様変更」のプロジェクトには続きがある。仕様変更に追われたプロジェクトは，「納期を守るためにテスト期間を圧縮した。しかし，これがあだとなり，プログラム品質が悪化してしまった」。その先には，「無理なスケジュールがたたりモラールが低下，協力会社が離脱，病人も発生した」という結末が待っていた。
数多くの声の中から，特にこのプロジェクトを取り上げたのは，行き過ぎた短期開発の弊害という，最近のプロジェクトが陥りがちな問題が見て取れるからだ。「短期開発の号令」を受け，やむなく「上流工程を短期化」した結果，「仕様変更が多発」する。そのような状況下で納期を死守するために「開発やテストにしわ寄せ」という構図は，多くの失敗プロジェクトに当てはまるのではないか。
成否の分岐点が必ずあるはず
プロジェクトには，成功/失敗の分岐点がいくつもある。先のプロジェクトは，要求定義が固まらないまま「開発を見切り発車」するか否かが最初の分岐点。その後も成功へと舵（かじ）を切れず，失敗が連鎖してしまったと言える。
分岐点のありかはプロジェクトの事情で異なる。「製品・技術の選択」かもしれない，「品質/コスト/納期の優先順位付け」かもしれない，ときには「経営戦略」までさかのぼる必要があるかもしれない・・・。「日経システム構築」では，それを突き止めるコラムを2月号にスタートさせた。「なぜ繰り返すのか失敗プロジェクト 成否の分岐点」がそれだ。このコラムで，先のアンケートに寄せられたトラブルを掘り下げていく。
分岐点を明らかにするために，5つの切り口を考えている。
・コストが超過する「赤字」
・品質が低下する「粗悪」
・導入しても使われない「無用」
・カットオーバーが延期される「遅延」
・プロジェクト・メンバーが体調不良になるなどの「疲弊」
「使われないシステム」をなぜ作るのか
なかでも今，筆者が興味を持っているのは「無用」である。苦労して稼働させたのに「使われない」「いつの間にか使われなくなる」といったシステムは決して珍しいものではない。なぜ，使われないシステムを作ってしまうのか――。3月号の特集記事では理由を探り，そのようなシステムを作らないためのポイントをまとめる予定だ。
「機能不足」「使い勝手が悪い」「遅い」「よく落ちる」など，システムが使われない理由はいくつもある。先にIT Proで公開した，「8割が役に立たないシステムを経験，「目的が不明確」「トップがダメ」「使い手を無視」が理由」では，このタイトルにある3つの原因を挙げる読者が多かった。
使い手を無視といった話は，今回の特集の取材でもよく聞く。ただし，「ユーザーの意見を聞かずに作った」といった単純なものばかりではない。「ユーザーの意見を聞きすぎた」ために，使い手無視につながることもある。典型的なのは，ユーザーの要望，特に操作性に関するものを100％取り入れたために，性能が出ない，メンテナンスがしづらいシステムを作ってしまうケース。ユーザー・インタフェースは望みどおりでも，性能が出ないので，使い勝手が低下した。「ユーザーのため」と考えたことが，「ユーザーにそっぽを向かれる」皮肉な結果を招くこともあるのだ。
使われないシステムをテーマとしたのは，「最近なんでも作り過ぎていないか」と感じていたことが背景にある。作り方の議論が盛り上がるそばで，作る目的が置き去りにされていないだろうか。「早く」作りやすくなってきた今だからこそ，心配になる。
「どう作るか」から一歩だけ戻り，「なにを作るべきか」を問い直す機運は高まりつつある。この3月に設立される，「要求開発アライアンス」はその一例。「要求は開発するものである」というスローガンを掲げ，情報システムの要求開発の体系化を目指している(関連記事)。
「使われないシステム」は，あなたのそばにもあるのではないだろうか。失敗プロジェクトの分岐点をどのように考えるかと合わせて，是非，教えてほしい。
（森山 徹＝日経システム構築）
■本記事へのご意見は以下の「Feed Back!」欄から，または電子メールでiteditor@nikkeibp.co.jpあてにお願いいたします。
