失敗例から学ぶ！システム開発の成功の秘訣とは【2024年最新版】

業務効率化に向けてさまざまな情報システム開発が行われていますが、実際にどの程度のプロジェクトが成功しているかご存知でしょうか。

さまざまな統計結果を見てみると、システム開発が失敗する確率は非常に高いことが浮き彫りになっています。それでは、なぜそこまでシステム開発が失敗する確率が高いのでしょうか。

今回は、システム開発でよくある失敗例と、過去に特許庁で起こったシステム開発の失敗事例について詳しく解説していきましょう。

まず、日本企業において情報システム開発のプロジェクト成功率はどの程度なのでしょうか。日経コンピュータはこれまで、情報システム開発プロジェクトの成功率を測るために不定期での調査を行っています。第一回の調査は今から約15年前、2003年に初めて行われました。

1700件以上の回答者から得られた結果は、なんとプロジェクト成功率は26.7%。実に約4分の3のプロジェクトは成功せず、失敗に終わっていたという衝撃の結果が判明することになりました。

その5年後、二回目の調査が行われた際には成功率31.1%。そして2018年に三回目の調査が行われ、プロジェクト成功率は52.8%まで上昇していることが分かりました。しかし、それでも約半分のプロジェクトは途中で頓挫したり、納期や予算の都合から成功に至らなかったりと、さまざまな事情からプロジェクトが失敗に終わってしまう現状があるようです。

また、同社の調査でプロジェクト期間が長ければ長いほどシステム開発の成功率は低下する傾向があることも判明。このような調査結果から、情報システム開発のプロジェクトは成功率が決して高いものとはいえず、多くのプロジェクトが途中で開発を断念せざるを得なかったり、コストや納期が膨らんでしまったりという現状があることが分かります。

そもそもなぜシステム開発は失敗する傾向が多いのでしょうか。システム開発の失敗例としてあるパターンを3つご紹介しましょう。

システム開発において重要なのが要件定義とよばれるものです。要件定義とは、どのようなシステム開発を行うのか、その機能や実装すべき性能を定義したもの。プログラマーなどのエンジニアはこの要件定義をもとに開発を行うため、そもそも要件定義が曖昧であったり必要な機能が定義されていなかったりすると、ユーザーと開発側で認識の齟齬が発生します。

そして当初の要件定義から開発すべきものがどんどん追加されていくと、その分の費用も追加で加算されていきます。あまりにも要件の追加が多くなると当初の予算から大幅に膨れ上がり、膨大な開発コストがかかることからプロジェクト自体が失敗に終わってしまうパターンが多いです。

ビルや家屋の建設とは違い、システム開発は物理的に目に見えて進捗が分かるものではありません。特にシステム開発のオーダーが初めてのユーザーは、システム開発にかかる工数や期間の相場が分からず、無理なスケジュールを要求してくることもあります。

また、ユーザーと対面で仕事を受注する営業も、システム開発にかかる工数を詳細まで把握できておらず、そもそも実現不可能な納期で受注してしまうケースも少なくありません。さらに、要件の追加によってスケジュールにも狂いが生じることも考えられます。このように、システム開発のための十分なスケジュールを想定できておらず、仕様の追加なども加わることによってシステム開発が途中で失敗に終わってしまいます。

費用やスケジュールに狂いが生じるのは、そもそもの要件定義が曖昧であることが根底にあるケースが非常に多いです。特にシステム開発のオーダーが初めてのユーザーに対しては、どのような機能を実装したいのかを細かなところまで詰めなければなりません。

普段の業務で当たり前に行っていることも、システム開発を行ううえでは重要な要件であり、機能の実装には大変な労力が必要とされることも多いです。業務フローや手順を一からトレースし、ひとつひとつの作業内容を書き出していくことで正確な要件定義が可能になるはずです。また、要件定義書が完成した後も、顧客と開発側が綿密に進捗状況を確認しあいながら、密な連携を取り続けることが必要でしょう。

しかし、システム開発が失敗するパターンの多くはこれらができていないケースが非常に多いのです。

ここからは過去にあったシステム開発の失敗事例をもとに検証していきましょう。今回は特許庁のシステム開発失敗事例をご紹介します。

特許審査の業務を効率化するために、特許庁では2004年から基幹系システムの大幅な刷新に乗り出しました。その内容は、これまで2年かかっていた特許審査業務を1年で完了できるように、データベースの一元化やデータ検索機能の強化などを目指すというもの。

要件定義を定めた仕様書は、当時の特許庁情報システムの担当者と日本IBMを中心に作成。しかしその後、仕様書を作成した特許庁の担当者が異動となり、さらにシステム開発を行う事業者として日本IBMではなく東芝ソリューションが落札。当初の予定価格よりも6割以下という99億2,500万円で特許庁は東芝ソリューションへ発注することになりました。

しかし、実はシステム開発の失敗はここからすでに始まっていたのです。

要件定義を作成した特許庁の担当者が異動となった後、なぜか要件定義まで決まっていたシステム開発のプロジェクトは白紙に戻ることになります。

どのようなプロセスと意思決定によってプロジェクトが白紙に戻ったのかは明らかになっていませんが、それまで作成した要件定義はすべて破棄され、現行の業務を残したままでのシステム開発が特許庁から東芝ソリューション側へ提案されます。

東芝ソリューションは当初の要件定義をベースに落札していることもあり、システム開発は難航。その後、特許庁側の当初の担当者がシステム開発の現場に再び戻ってくることとなり、はじめの仕様書通りにシステム開発が続行されることとなりました。

しかし、東芝ソリューションが特許庁の職員へタクシー券を配布していたことが発覚し、関係者が利益供与で逮捕されるという事件が起こります。さらに捜査の過程で特許庁側のシステム開発のキーマンだった担当者が、入札前の段階で東芝ソリューションに情報提供していたことも発覚。その後担当者は異動となり、特許庁はキーマンが抜けた後に開発担当者を増員して対応するも開発の見通しが立たず、結局システム開発は失敗に終わってしまいました。

このシステム開発プロジェクトには、のべ55億円もの税金が投入されたにもかかわらず、結局何ひとつ開発できずに終わってしまったのです。

特許庁のシステム開発プロジェクトの失敗事例から見えてくることは、まずキーマンとなる人物が頻繁に異動していたことと、要件定義を行った企業と開発を行う企業が異なっているという2つのポイントが挙げられます。

さまざまな事情があったことは事実ですが、システム開発の核となるキーマンが途中で異動するということは大きなリスクです。また、要件定義とシステム開発を行う企業が途中で代わってしまうことも通常ではあまり見られない事象といえるでしょう。結果として要件定義を作成した担当者も企業も不在のまま開発を行うこととなりましたが、誰一人としてそれまでの流れを把握していないため、システム開発は一旦白紙に戻さざるを得なかったのではないでしょうか。

さらに、その後もプロジェクトの進捗の遅れを増員で乗り切ろうとするなど、強引に進める姿勢があったことも事実。途中で開発計画の見直しを講じなかったのも、システム開発が失敗に終わってしまった要因といえるでしょう。

今回ご紹介してきたように、情報システム開発のプロジェクトは要件定義が非常に重要です。要件定義が曖昧なままプロジェクトが進んでしまうと、途中で開発費用が膨大に膨らんでしまったり、開発スケジュールが大幅に遅れてしまったりという弊害が起こる危険性もあります。正確な要件定義を作成することは簡単ではありませんが、プロジェクトが成功するか否かは要件定義の正確性にかかっていると言っても過言ではありません。

また、特許庁の失敗事例から見ても分かるように、プロジェクトの途中で開発のキーマンや企業が交代してしまうのも大きなリスクです。やむを得ない場合もあるかもしれませんが、万が一異動しても問題が起きないように万全な組織体制を組んでおくことも重要といえるでしょう。

そして、システム開発のプロジェクトにおいて何よりも重要なのは顧客と開発側の綿密なコミュニケーションにあります。要件定義の段階はもちろんですが、開発途中であっても頻繁に意見を交わし、現在の進捗状況や起こっている問題などを共有しておくことが重要です。

システム開発は開発を行う企業に丸投げをして終了ではなく、あくまでも顧客と開発側が一体となって成功させるという意識を持っておくことが必要といえるでしょう。