システム開発が失敗する原因と対策

日本のシステム開発の成功率は年々上がっています。定期的に行われるITプロジェクト実態調査によると、2008年の調査では成功率が3割、2018年の調査では成功率が5割といわれています。成功率が上がっているとはいえ、いまだプロジェクトの半数が失敗している状況です。

https://business.nikkei.com/atcl/opinion/15/100753 /030700005 /

また、失敗の理由は15年前から変わらずという調査結果も出ています。悪い見方をすれば同じ失敗を繰り返しているともとれますが、良い見方をすればよくある失敗例を知り、気をつけるべきポイントを抑えればシステム失敗を防ぐ対策が打てるともいえます。

そこでこの記事では、システム開発が失敗する原因とよくある失敗例についてまとめました。また、システム開発の失敗を防ぐにはどのようなことに気をつけたらよいか考えました。この記事がお役に立ちましたら幸いです。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

よくある失敗例

システム開発のよくある失敗例を3つ紹介します。

1.いつまで経ってもシステムが完成しない

システム開発が失敗したといえる代表例として、納期を過ぎてもシステムが完成しない、いつ完成になるのかがわからない、という状態が挙げられます。

いわゆる、プロジェクトが炎上している状態です。プロジェクトが炎上してしまうと、いつ完成になるのかがわからないうえに、スケジュールが伸びて予定よりコストがかさんでしまったり、残業まみれになってしまったりと負のループが生まれてしまいます。

ここでは、いつまで経ってもシステムが完成しない原因をさらに分解して解説します。

解決できない問題が発生している

技術的に困難な課題に直面しており、仕様どおりの機能を作成できない問題が発生している状態です。開発者側の原因であることが多いです。具体的にはプログラムの難易度が高く、アサインされているエンジニアのスキルレベルとミスマッチの状態であることが挙げられます。

また、他のシステムとの連携処理があり、連携先のシステムに問題があったり、連携先のシステムの仕様が不明確であるなどの状態が発生していることもあります。

仕様変更が発生しつづけている

顧客側の要望が何度も変更になり、そのたびにプログラムの修正が発生している状態です。これは要件定義、設計のフェーズに問題があるといえます。正しく要件を反映した内容になっていないため、仕様変更が多く発生してしまいます。

また、仕様変更が発生した場合のスケジュールや費用への影響が、発注者側と受注者側で適切に合意が形成されていないケースも散見します。発注者側では変更が発生しても予定通りのスケジュールで、費用も追加無しだと思っているが、受注者側では変更が発生する場合スケジュールが変更になる、費用も追加になるという認識である場合です。

これらが両者間で合意できていない状態が起きると、スケジュール通りに物事が進行しなくなってしまいます。

データ移行に問題が発生している

旧システムのデータを新システムに移行する際に、データのフォーマットが合わずデータ移行に失敗してしまうことがあります。

データ移行が伴うプロジェクトは、新システムの設計時に旧データのデータ移行が必要な範囲を明確にし、データ移行が必要なものについては新システムの設計として移行を前提に設計する対応が必要となります。

2.完成したシステムがイメージしたものと違う

システムが納期までに完成したとしても、顧客側のイメージしていたものと違った場合は成功とはいえません。

要件定義・設計書の内容と違う

開発者側の問題です。設定したはずの要件定義や設計書と違うということは、ドキュメントに沿って正しく開発が進んでいない状態です。コミュニケーションがうまくいっていないときに起こりやすい傾向にあります。

コミュニケーションを取るのが難しい、多重下請け構造や海外発注(オフショア開発)を行っている場合に起こりやすい問題です。

要件定義・設計書がない、または記載内容と要望が違う

同じく開発者側の問題です。ドキュメントを作成していないと何が正しいかがわからないため、作る側も検収する側もどのような状態になっていればOKか判断ができません。完成の条件が決まっていないため、永遠に完成しない可能性がある恐ろしい状態です。

後付けでもいいので完成状態をドキュメント化して、完成状態を明確にすべきだと考えます。

3.開発したシステムが現場で利用されなかった

システムを作ったにも関わらず、まったく使われないという事態もよく起こるシステム開発失敗例です。

そもそも必要のない機能を作成している

主に発注者側の問題です。本当に必要な機能かどうか、受注者側にヒアリングをしておくべきだと考えます。特にシステムをリニューアルする場合に発生しやすい問題です。「現在のシステムにあるから作っておく」としてしまうと、この問題に陥りやすくなってしまいます。

何を目的に、何を解決するためにこの機能を作るのか、を考えば解決できる問題です。

現場の仕事の仕方を変えたくないという抵抗勢力がある

これもシステムをリニューアルした後によくある問題です。システムがリニューアルすることによって仕事の進め方が変わる場合、新しい操作を覚えたり、慣れているやり方を変えたりしたくない方がいます。この問題は、発注者側の責任者がリーダーシップを持って、システムの活用を根気よく啓蒙してゆく必要があります。

この時に、システムに対してナンセンスな要望や苦情が出ることがありますが、中には正当な意見もあります。システムを使いたくないから言っている意見なのか、本当に改善を考えた上で言っている意見なのかをよく見極める必要があります。

完成したが重くて使えない/完成したが頻繁にエラーで使えなくなる

開発者側の問題です。運用で想定されるデータ量、アクセス数を想定したシステム設計やインフラ設計になっていないことが原因です。

受注者側に技術力があり、かつ単純ミスであればすぐに修復できますが、そうでない場合は解決できない、解決にとても時間がかかるといった状況に陥ることになります。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム開発が失敗する原因(顧客側)

なぜシステム開発は失敗してしまうのでしょうか。顧客側（発注側）とシステム会社側（受注側）にわけて原因と、対策を紹介します。

要件提示ミス

現場の声を反映した要件提示ができていないことが、システム開発失敗に繋がってしまいます。発注者側で実際にシステムを使用する人を巻き込んで、システムの要件を洗い出せていないことが原因である場合が多いです。
また、受注者側からもこのような状態であると感じた場合は、発注者側に現場担当者も含めての検討を促す必要があります。

発注をする前の準備を怠らず、要件を洗い出して明確にしておくことで失敗を防ぐことができます。

開発対象選定ミス

前述の「そもそも必要のない機能を作成している」の項にあるとおり、機能を作る目的を考えずに「現在のシステムにあるから作っておく」としてしまうと、使わない機能を作成することになってしまいます。

システム開発の目的は何かを明確に考え、本当に必要な機能かどうかシステム会社にも相談するように心がけると、不要なシステムを開発せずに済みます。

仕様策定時の考慮不足

前述の「仕様変更が発生しつづけている」の項にあるとおり、顧客側の要望が何度も変更になって修正が頻繁に発生してしまうと、スケジュール通りにプロジェクト進行ができず、システム完成がいつになるかわからなくなってしまいます。

仕様変更をするとスケジュールにも変更が生じることを念頭におき、要件定義・設計のフェーズをしっかりと固めきってから開発に臨みましょう。

特定人物によるプロジェクト進行の妨げ

システム業者に対して的外れな指摘・必要のない報告や、管理指標情報の要求（風向ではない箇所のバグ発生率や、エビデンス結果の提出を無償で要求）など、特定の人物に起因する理由でプロジェクトの進行の妨げが起きる場合がまれにあります。

原因としては、顧客側のSE・システム担当の能力不足が理由となることが多い傾向にあります。このような事態が起きた場合、システム会社側が顧客側に相談して対応してもらうことで解決します。

システム開発が失敗する原因(システム会社側)

システム会社側が原因の失敗と対策を紹介します。

見積もりミス

前述の「解決できない問題が発生している」に関連する事項ですが、工数見積もりが間違っており、さらに技術的に困難な課題があると、予定のスケジュール内で完了しない原因となります。

技術調査が必要な場合、技術調査を実施したうえで裏付けのある状態で見積もりを作成しましょう。
また、外部システムとの連携やデータ移行は不確定要素が多いため、工程に余裕をみておくマネジメントが必要です。

変更管理ミス

スケジュールや仕様の変更に対する合意がないまま進行すると、スケジュール通りに進行しない、予算不足で必要なエンジニアが確保できないといった問題につながります。

仕様変更が発生した場合のスケジュールと費用への影響を正しく顧客側に伝え、合意を形成するようにしましょう。

技術調査不足

技術調査とは、エンジニアがシステムを実装する際に使用したい技術を事前に調査したり、どの技術を採用したら実装可能かを調査したりすることです。

技術的に難易度が高い、実績がない機能が含まれる場合、社内のエンジニアを巻き込んで事前に技術調査を行いましょう。それでも不確定要素がある場合、顧客にも十分説明を行ったうえで、スケジュール・費用の説明をしましょう。

技術力不足

自社のスキルに合わない受注は断りましょう。会社として新分野へのチャレンジとする場合であれば、スケジュールには余裕を見て、開発予算も自社として、新分野へのチャレンジとしてロスを許容できる範囲を社内でもしっかり握りましょう。

オフショア開発での失敗

マネジメントミスに関連する事項ですが、最近、準委任契約でのラボ型と称するオフショア開発の失敗による開発・保守移管の相談が多く見受けられるようになりました。

ラボ型オフショア開発とは、海外の固定メンバーの案件専用チームを一定期間、一定予算で抱え込んで開発を進める方法です。平たくいえば、お客様専属の開発チームをベトナムなどの海外に用意して開発します。

安価でシステムを作れるため人気がありますが、コミュニケーションがうまくとれないなどの理由で失敗してしまい、時には全然希望と違うシステムが納品されて、作り直しせざるをえないという事例が発生しています。

実際の開発費用・期間をまとめた資料を無料で差し上げます。資料請求はこちら>>

システム開発の失敗を防ぐ対策

前述した対策の他に、システム開発の失敗を防ぐために抑えておきたいポイントをまとめました。

ドキュメントを残しましょう

ドキュメントが無いと失敗した場合、何が正しいかがわからず言った・言わないの空中戦になります。必ずドキュメントを作成し、発注者側・受注者側で共有し、記載内容に合意が取れている状態にしましょう。

変更管理を発注者側、受注者側で合意を持って進めましょう

変更を依頼する側も、受ける側も「変更するのだから何かしらスケジュール、費用に変更が発生する」という前提で考えましょう。その中で、プロジェクトの進行フェーズによっては現時点であれば変更は予算内、スケジュール内で吸収可能という判断があることがありますが、必ずしもこの判断にならないことを両社が認識しましょう。

技術力、実績のあるシステム会社を選びましょう

技術力不足が原因とならないように、過去実績や受注側の開発体制(下請けに丸投げしていないか)などを確認し、受注側が責任をもって仕上げてくれる安心材料を集めて発注しましょう。