2024/03/11
システム開発の中には、事前に立てた計画通りに開発が進まず、プロジェクトが失敗してしまうケースも少なくありません。
2018年に、ある企業が行なったシステム開発のプロジェクト成功率の調査では、成功率は「52.8％」となりました。
2008年の調査結果「31.1％」よりも上回っているものの、いまだに2回に1回は失敗していることになるのです。
本記事では、システム開発で陥りがちな失敗事例とその原因、システム開発で失敗しない対策方法について解説します。
目次
｜システム開発における失敗とは？
システム開発の失敗について明確な定義はありませんが、システム開発が成功したかどうかを判断する基準には、QCDが順守されているかという点があります。
QCDとは、下記の頭文字をとった、物作りに重要な3項目をまとめて指すものです。
・Quality（品質）
・Cost（コスト）
・Delivery（納期）
このQCDを基準に、自社のシステム開発が成功したのかどうかを考えましょう。
｜システム開発のほとんどが失敗している
ビジネスにおけるIT活用の重要性から、近年では多くの企業がシステム開発に取り組んでいます。
特に、十数年前に構築された、レガシーシステムの刷新は「やらなければいけないとは思っているが、なかなか一歩が踏み出せない」といった企業も少なくありません。
その理由を裏付けているとも言えるのが、プロジェクトが成功する割合を算出したデータです。
「企業IT動向調査報告書 2021―ユーザー企業のIT投資・活用の最新動向」によると、500人以上の企業の場合、予定通りの工期で終わったプロジェクトは15.8％、予定通りの予算でおさまったが24.3％、品質に満足しているという回答は18.1％という結果がでています。
「成功」の定義をQCD（品質・予算・納期）の順守とする場合、これを全て満たしている企業はかなり少ないことがわかります。
また、大規模な国際調査である Standish Group による CHAOS Report では、成功率は31%となっており、システム開発の7割が失敗していることになります。
｜システム開発におけるリスク
システム開発を進めるうえで、リスクを把握しておくことは重要です。綿密に計画を立てたプロジェクトでも、完成形が見えない状態で「手探りで進めるシステム開発」には、リスクがつきものです。
システム開発におけるリスクは、大きく分けて下記の3種類に分けられます。
| リスク | 内容 |
| 認識的リスク | 発注側と開発側で認識がズレたまま開発が進むリスク |
| 金銭的リスク | 開発の途中で予算が不足してしまうリスク |
| 技術的リスク | 技術的に機能の実装が難しくなるリスク |
それぞれのリスクについて、詳しくみていきましょう。
｜認識的リスク
システム開発における大きな壁は、コミュニケーションギャップによる「勘違い」のリスクです。
たとえば、「業務管理システム」と聞いて思い浮かべるシステムは千差万別です。そのため、各々のイメージを明確な形で共有するのは困難です。
発注側と開発側でイメージが異なれば、それ以降の認識も齟齬が生まれやすく、誤った方向に進んでしまう可能性が高まります。早期に誤認を正さないと、見当違いの機能実装のために工数を無駄に割いてしまいかねません。完遂後に発覚した「誤認」をリカバリーするためにはコスト・工期を増やさなくてはならず、結果としてプロジェクトを失敗に追い込む要因になります。ダメージが大きい分、優先して回避すべきリスクです。
｜金銭的リスク
システム開発でトラブルになりやすいのが「開発費の算出」です。
システム開発は「まったく新しいものを作る」という特性上、正確な費用を割り出すのが難しいという問題があります。
たとえば、「外部企業にシステム開発を発注しよう」と検討する場合、詳細が決まらない状態で開発費を算出しないように注意が必要です。
開発が始まった後に「やっぱりこの機能も欲しい」となれば、システムの仕様を変更するたび、開発費や開発期間が雪だるま式に膨らみかねません。加えて、決定事項が二転三転すれば、現場スタッフのモチベーションにも影響するでしょう。
｜技術的リスク
企画段階では開発可能に思われても、技術的に実装が困難なケースに直面することがあります。
また現代では、IT技術が高度になるにつれて「システム構築技術の複雑化」が著しい時代です。動作に様々な要因が絡むようになり、新しい技術を採用したシステムがクライアント側で「動かない」と報告されるケースもあります。
開発中に「実装が困難」と判断された場合、クライアントと交渉をして機能を調整する必要があります。
｜システム開発が失敗する原因と対策方法
ITプロジェクト実態調査2018によると、成功率は年々改善されているものの、失敗の原因は今も昔もかわらないという結果がでています。では、その変わらない失敗の原因とはどのようなものなのでしょうか？
ここでは、現場でよくある失敗談をふまえ、その原因と対策方法までをまとめています。
｜目的が曖昧なまま開発をスタートさせた
失敗原因の中でも代表的なものが、プロジェクト開始時の準備不足です。
関係者の間で「どんなシステムを作りたいのか」、「そのシステムを使ってどんなことをしたいのか」といった目的の情報を共有できなければ、理想とは異なるシステムが完成してしまいます。
このように、発注側と開発側のコミュニケーション不足の根底には、発注側にはシステム開発について高い理解度を有する人がいないこと、開発側は目先の納期やコストに気を取られてしまうことが、大きく影響していると言えるでしょう。
準備の不足で開発が失敗してしまう点を考慮すれば、開発初期は発注側と開発側でコミュニケーションの量を増やすことが重要です。また、発注側もある程度のシステム開発に関係する知識を身に付けておけば、踏み込んだコミュニケーションもとりやすくなります。
｜要件定義が不十分
要件定義が明確なプロジェクトほど、納期やコストは当初の予定通りに進みます。
逆に要件定義が不十分であれば、プロジェクト途中で大きな仕様変更が起こりやすく、結果としてプロジェクトが失敗に終わる傾向があります。
要件定義が不十分になる原因は、開発側が発注側の要望をそのまま受け入れて開発してしまうことが多いです。開発側は、「なぜその機能が必要なのか」という観点で要望を検証し、要件を決めていくことが開発を成功へ導く近道になります。
なお、発注側も開発側に任せっきりになり、細かいチェックを疎かにしてしまわぬよう留意しましょう。機能が必要である背景を説明するなど、齟齬を防ぐためにできることもあるはずです。
要件定義は、課題や要望を把握しシステムの内容を具体化する非常に重要なステップです。
後工程で要件の追加や変更が頻発して手戻り作業の発生を防ぐためにも、発注側と開発側がしっかりとコミュニケーションをとる必要があります。
｜コミュニケーション不足
プロジェクト進行中に最も重要視すべき点は「コミュニケーション」です。
国内・海外問わず、「伝えたいことを正しく伝える」にはお互いの努力が必要です。正しい情報が正しく伝わらないと間違った認識のまま開発が進んでしまう恐れがあり、そうなると成果物が仕様とはかけ離れていたり、修正を何度も繰り返す必要が出てきたりとリスクが大きくなります。
このような悪循環にならないためにも、発注側と開発側のコミュニケーションの問題点を事前に把握し、定期的な進捗管理でプロジェクト完了率を確認し合いながら、開発を進めていくようにしましょう。
｜見積もりが不明瞭
システム開発が失敗する原因は、「見積もりの曖昧さ」によるものも多くあります。
たとえば、スパイラル型の開発手法を採用すると、修正するたびに開発の工程をやり直すことになります。その分、質の高いシステムは出来上がったとしても、想定していた予算を大幅に超えてしまい、結局プロジェクトが破綻することもあるのです。
いわゆる金銭的リスクに該当しますが、これももともとは認識のズレや誤認によるものです。
システム開発の性質上、見積もりにズレが生じるのは仕方ないことですが、要望が確定してから見積もりを算出する、追加や上乗せ要望があれば見積もりを再設定する、などを行うことでギャップを小さくできます。
｜迅速かつ柔軟に対応できる体制が構築できていない
開発要件に対して、しっかりと体制を組んでいたつもりでも、急な仕様変更が生じて失敗してしまった経験はありませんか？
要求が頻繁に変わる可能性がある場合は、仕様変更を予測して、最初から対応しやすい設計や体制にしておく必要があります。
言われた通りの開発ではなく、要件定義から設計・開発までを自律的に動けるように、お互いに協力し、常に連携を意識することが大切です。
｜テストを軽視してしまう
システムに何か問題があった場合、日本は「作った側に問題がある」と考える傾向が強いため、テスト工程を省略してしまったり、確認すべき事項を確認しないままテストが終わってしまったり、結果として不具合を見逃してしまうことがあります。
テスト条件やテスト観点を曖昧にせず、確認したい内容は何なのか、確認すべき結果が出力されるまでの作業手順や期待値、合格ラインなどをしっかりとテストケースでチェックしましょう。
｜プロジェクト管理者のスキル不足
プロジェクトを進める上では、プロジェクトマネジャーの能力や経験が成果に大きな影響を与えます。
必要な人員を配置する、要件や仕様の変更があった場合のスケジュール管理、市場変動リスクの管理など、プロジェクトマネジメントはやるべき仕事がたくさんあります。また、ステークホルダーとのコミュニケーション不足により、プロジェクトの方向性が乖離するなどもよくある失敗例です。
プロジェクト推進において十分なマネジメントスキルがある人物かどうかは、必ずおさえておきましょう。
｜とあるヘルスケアITシステムの失敗事例
ここまではシステム開発のよくある失敗例を紹介しましたが、最後にとあるヘルスケアITシステムを構築するプロジェクトで起きた失敗事例について解説します。
《開発概要》
・開発費用：700万円
・開発期間：6ヶ月
結果的に、システムは稼働したものの、導入後にさまざまな問題が発生し、システムの大幅な修正が必要になりました。なぜこのようなことが起こったのか、その要因を紹介します。
｜要因：要件定義不足
比較的大きな病院グループが患者管理システムの改善のため、新しいITシステムを導入する計画を立案。
しかし、要件定義の段階で、患者のデータ保護に関する問題や既存のシステムとの連携、日々の業務プロセスの中での使用方法など、重要な要素が見落とされていました。
要件定義が不十分なまま、開発をスタートし、そのままシステム導入まで進めてしまったため、リリース後にシステムの大幅な修正が必要になり、結局予算もオーバーしただけでなく、正常にシステムを稼働できたのもリリースから3ヶ月経った頃になってしまいました。
これは、発注側の準備不足と開発側が発注側の要望をそのまま受け入れて開発をしてしまったことで生じた失敗事例です。
｜成功のポイント
このような事例を成功させるためには、要件定義のプロセスに十分な時間とリソースを割くことが重要です。
要件定義はシステム開発の初期段階で行われるため、その後のプログラミングに非常に大きな影響を及ぼします。顧客が必要とする機能や要件について、事細かに確認することが大切です。
｜まとめ：発注側と開発側のコミュニケーションを徹底する
システム開発における失敗原因の多くは、発注側と開発側のコミュニケーション不足によるものです。
これを改善するためには、まずは意識的にコミュニケーションの量を増やすことが重要です。
相手の言っていることを「理解した」と思っても、自分の言葉でまとめてから先方にお伝えし、認識にズレがないか確認することが重要でしょう。
成功率がたとえ80％でも10%でも、100％でない限りはプロジェクト予算や人々の労力が無駄になっているという事実には変わりがありません。
ITプロジェクトは、経営やマネジメントに直結します。失敗の原因に1つでも当てはまったら、一つひとつ課題をクリアにしながら開発を成功へと導きましょう。
《関連記事》開発がうまくいかない。そのポイントと対処方は？