失敗プロジェクト─その原因は？─

ITpro

2006.11.24

　筆者は，ユーザー企業のグループ内IT企業の一員として，主にグループ各社向けのシステムの開発プロジェクトに携わってきた。過去に参加したプロジェクトを振り返ると，その成功率はお世辞にも高いとは言えない。

　最近流行のイテレーショナル型開発プロセスや，変更管理，自動化ツールなど，効果が期待できるものを都度採用してきたが，結局は納期の遅延，コストオーバーの憂き目に合うことが多く，抜本的な解決策の必要を感じながらも，明確な答えを見つけられずにいた。筆者が「要求開発アライアンス」と出会ったのはその頃のことである。

プロジェクトはなぜ失敗するのか
＝振り返ると，プロジェクト後半の仕様変更が主要な原因だった

　まずは，プロジェクト失敗の原因について考えてみる。今では常識化しつつあるが，日経コンピュータ（2003.11）のアンケート結果にもあるように，要求仕様の不備は，開発プロジェクトに甚大な被害を与えてしまう（失敗原因の40％）。

　筆者の経験したプロジェクトも例外ではなく，要求仕様の不備がプロジェクトの後半における仕様変更の発生につながり，深刻な事態につながる場合はよくあった。納期まで期間が無い中，要員増強による人海戦術や開発担当者の（尋常でない）時間外労働による対応を余儀なくされ，その影響による品質の低下や手戻りにより，「納期オーバー」や「予算超過」がもたらされる結果となっていた。

　プロジェクトの上流工程で十分な仕様検討を行った上での「明確な仕様変更」であれば，ユーザー側と納期延長や費用追加の交渉も可能となるが，仕様があいまいなグレーゾーンにおける変更の場合は（発注者との力関係もあり），たいていはシステム開発サイドで対応せざるを得なくなってしまう。たとえそれが要求仕様の不備と思われる内容であっても，発見できなかった開発サイドに責任が求められるケースが多いのである（仕様確認不十分や不具合の扱いとなってしまう）。

　特に筆者の会社は，グループ内IT企業ということで，ユーザーサイドには「一を言えば十わかって当たり前」と考える風潮があった（グループ外でも，長い付き合いのある顧客との間には，同様の意識があるのではないだろうか）。

　さらに悪いことに，システム開発のプロジェクトが失敗すると，たいていの場合，システム開発サイドに原因があるとみなされてしまう。プロジェクト後半の仕様変更が失敗の大きな要因だったとしても，開発サイドが一度変更を受け入れてしまった以上，責任は開発サイドにあるとされるのだ。

　このため，理不尽な仕様変更の要求があったとしても，プロジェクト失敗の要因としては追求されず，要求仕様の策定のあり方を見直すといったアクションにはつながらない。その結果，新たな失敗を生むという負の連鎖が続いてしまうのである。

プロジェクト後半の仕様変更＝その原因は？

　ビジネスシステムの構築にはスピードが要求される場合も多い。ビジネスは日々変化するため，ビジネスサイクルは短く，数カ月～1年といったシステムの開発サイクルとのギャップが問題になる場合もあるだろう。

　例えば，ユーザーがシステムが稼働する数カ月から1年以上先の正しい仕様を定義しようとしても，ビジネス環境の予測が困難なため，明確な定義ができないといった場合もあるかもしれない。

　しかし，筆者が経験したプロジェクトでは，背景にあるビジネス自体はそれほど変わっていないように思えた。確かに，組織改革や法改正への対応といった環境変化に因る要件変更は発生していたが，そのような変更は仕様変更として認められやすく，費用追加や納期延長の交渉がしやすく，重大な問題にはつながりにくい。

　やはり，プロジェクトに深刻な影響を与えているのは，後半になって当初の要求定義内容の不備が発見され，修正を余儀なくされるケースといえるだろう。次に，その真の原因について考えてみる。

ユーザーは業務をイメージできなければ，仕様を決められない

　失敗プロジェクトにおける仕様変更の内容とその根拠を調べてみたところ，そもそも要求定義完了時点で決まっている内容があいまいな場合が多いことがわかった。

　仕様が変わるのではなく，最初にはっきり決まっていない仕様が，ユーザーが動作検証をする度に，システム開発サイドの認識との差異として顕在化され，結果として開発者の想定外の仕様変更の要求につながっていた。合意内容自体があいまいであるため，開発サイドもはっきりこれを「仕様変更」と言えず，断れずに不具合として受け入れる結果となっていたのだ。

　では，なぜ，仕様があいまいになるのだろう。筆者の勤める会社はグループ内のIT企業のため，プロジェクトによってはユーザー側の立場で，一緒に作業をすることがある。そんな中，たまたまユーザーの本音を聞く機会があった。

　「機能の一覧と機能仕様書をみても，実際の動くモノを見てみないとよくイメージがわかないし，決められない。わからないまま細かいところまで最初に（仕様を）決めてしまうと，後で業務と合わないことがわかったときに仕様変更になってしまうので，最初に細かいところまでは決めたくない」ということだった。

　また，今まで我々が提示していたドキュメントでは，業務と照らし合わせたとき，その仕様が本当に正しいかどうか判断できず，そのためにあえて最初に要件をはっきり決定しない，という指摘も受けた。

　このように，失敗プロジェクトの主要な原因となる要求仕様の不備は，ユーザーのみの責任ではなく，開発サイドとユーザーの共同作業となる「仕様策定の進め方」そのものに問題があるために生じるようである。

　次回は，失敗プロジェクトにおける，仕様策定の進め方について問題点を分析し，解決のための方策について述べることにする。