納期が延び、追加費用の見積もりが届き、ようやく完成したシステムは現場で使われない。システム開発の失敗は、どれか1つではなく、いくつもの問題が重なって起こることがほとんどです。

しかも、その原因の多くはプロジェクトの序盤に仕込まれています。表面化するのはテストや稼働の直前でも、さかのぼると企画や要件定義の段階での判断に行き着くケースが少なくありません。

この記事では、業務システムのシステム開発を任された発注側の担当者に向けて、システム開発が失敗する原因と工程ごとの典型例、発注側ができる予防策、失敗しそうなときの判断基準を解説します。

この記事を読むと理解できること

• システム開発の失敗と判断される4つの状態

• 失敗の原因を発注側・開発側・双方に分けて捉える考え方

• 企画から運用までの工程別に起きやすい失敗

• 要件定義で認識のずれを防ぐための具体的な方法

• 発注側が開発会社任せにせず担うべき役割

• 失敗しそうなプロジェクトを続けるか止めるかの判断基準

システム開発の失敗とはどんな状態を指すのか

システム開発の失敗に明確な定義はありませんが、一般的には品質・コスト・納期のいずれかが大きく崩れた状態か、完成しても導入の目的を果たせない状態を指します。発注側にとっては、後者の「完成したのに役に立たない」状態も同じく失敗として捉えることが重要です。

システム開発の失敗を4つの類型で捉える

失敗の形は、大きく次の4つに分けられます。

前の3つは開発の過程で比較的早く気づけますが、目的の失敗は稼働後に表面化するため、気づいたときには手遅れになりがちです。4つのうち最も損失が大きいのは目的の失敗だと言えます。

システム開発の失敗が連鎖する理由

4つの類型は独立して起きるわけではありません。たとえば要件が曖昧なままシステム開発に入ると、途中で仕様変更が増えてコストが膨らみ、納期を守るためにテストが削られ、品質が下がるという流れがよく見られます。

このように、1つのずれが別のずれを呼ぶのがシステム開発の失敗の特徴です。だからこそ、表面化した症状ではなく、最初のずれがどこで生まれたかを見る必要があります。

システム開発が失敗する原因は何か

システム開発が失敗する原因は、発注側に起因するもの、開発側に起因するもの、双方の間で起きるものの3つに分けると整理しやすくなります。実際には双方の間で起きる認識のずれが最も多く、発注側と開発側のどちらか一方を責めても解決しない点が重要です。

原因を3つに分けて整理する

主な原因を、どちらに起因するかで分類しました。

発注側の原因は、開発会社を選んだ後では修正が難しいものが多くあります。発注前にどこまで準備できるかが、システム開発の成否を大きく左右します。

発注側に起因するシステム開発の失敗

発注側の原因で最も多いのは、目的が曖昧なまま開発を依頼してしまうことです。「今のシステムが古いので新しくしたい」という動機だけでシステム開発を始めると、何を優先し、何を作らないかを判断できません。

もう1つの大きな原因が、意思決定者の不在です。要件の確認や仕様変更の判断のたびに社内調整が必要になると、システム開発は止まり、その間の費用も発生し続けます。

開発側に起因するシステム開発の失敗

開発側の原因としては、要件を十分に理解しないまま見積もりを出すこと、扱いに慣れていない技術を採用すること、テストの計画を後回しにすることなどが挙げられます。

また、発注側の要望をそのまま実装し、業務上の問題点や別の解決策を提案しないことも、結果として失敗につながります。システム開発を担う会社には、作る力だけでなく、要望の背景を確かめる姿勢が求められます。

双方の間で起きるシステム開発の失敗

最も厄介なのが、どちらか一方の責任とは言い切れない認識のずれです。発注側が当然と思っていた機能が要件に書かれていなかったり、同じ言葉を双方が違う意味で使っていたりすることは珍しくありません。

契約形態と開発の進め方が合っていないことも、双方の間で起きる失敗の原因になります。要件が固まっていないのに完成責任を前提とする契約を結ぶと、変更のたびに追加費用を巡る協議が必要になります。契約形態の違いは準委任契約と請負契約の違いで詳しく解説しています。

システム開発の失敗は工程ごとにどう起きるのか

システム開発の失敗は、企画、要件定義、設計・開発、テスト、移行・運用のどの工程でも起こりますが、原因の多くは企画と要件定義で仕込まれ、テストや移行の段階で表面化します。工程ごとの典型例を知っておくと、早い段階で手を打てるようになります。

企画と要件定義で仕込まれる失敗

企画段階で起きやすいのは、解決したい業務課題ではなく、作りたい機能から検討を始めてしまうことです。機能の一覧から入ると、優先順位の根拠がなく、要件が膨らみ続けます。

要件定義では、業務の例外処理や他システムとの連携が漏れる失敗がよく見られます。日常的な業務の流れは要件に書かれても、月末処理や差し戻しなどの例外は担当者の頭の中にしかないことが多いためです。

設計と開発で表面化する失敗

設計・開発の段階では、要件定義で決めきれなかった部分が仕様変更として次々に表面化します。変更そのものは避けられませんが、変更の受け付け方や費用・納期への影響を判断するルールがないと、範囲が際限なく広がります。

また、画面の見た目や操作の流れが開発の終盤まで確認されないと、利用者が初めて触れたときに「想定と違う」という声が上がります。この段階での修正は、設計からやり直しになることもあり、負担が大きくなります。

テストと移行で起きる失敗

テストの段階では、納期の遅れを取り戻すためにテスト期間が圧縮され、不具合を抱えたまま稼働する失敗が起きがちです。特に、実際の利用者が業務の流れに沿って確認する受け入れテストを省略すると、稼働後に問題が噴出します。

移行の段階では、旧システムからのデータ移行の難しさが過小評価されることがよくあります。データの形式や品質の問題が移行直前に見つかり、稼働日を延期せざるを得なくなるケースもあります。

運用段階で発覚するシステム開発の失敗

稼働後に発覚する失敗の代表は、使われないシステムです。操作が分かりにくい、業務の流れに合っていない、旧来のExcel運用のほうが早いといった理由で、現場が新しいシステムを避けるようになります。

この段階の失敗は、開発プロジェクト単体ではなく、業務改革やDX全体の失敗として扱われることもあります。DXの取り組み全体で失敗が起きる構造は、DXが失敗する原因と立て直し方で整理しています。

システム開発の失敗を防ぐために発注側ができることは何か

システム開発の失敗を防ぐために発注側ができることは、目的と優先順位の明文化、要件の見える化、変更管理と判断体制の整備、そして開発会社の選び方の見直しの4つです。どれも開発会社に任せきりにしないための、発注側ならではの役割です。

目的と優先順位を文書にする

発注前に、システム開発の目的、対象となる業務、達成したい状態を文書にまとめます。あわせて、必ず必要な機能、あれば望ましい機能、今回は作らない機能を分けておくと、後からの判断がぶれにくくなります。

この文書は提案依頼書の土台にもなります。開発会社に提案を依頼する際の書き方は、RFPの書き方を参考にしてください。

要件を画面と業務の流れで確認する

要件定義の認識ずれを防ぐ有効な方法は、文章だけでなく、画面のイメージや業務の流れで確認することです。簡単なプロトタイプを使って利用者に操作してもらうと、文章では気づけなかった漏れや誤解が早い段階で見つかります。

FAKEでは、デザインドリブン®の考え方で業務と画面の設計を先に固め、現場に入り込んで業務を観察しながら要件を詰めていく進め方をとっています。画面と業務の流れを先に合わせておくことは、使われないシステムを防ぐうえでも効果があります。

変更管理のルールと判断体制を決める

仕様変更は必ず発生するという前提で、変更の申請方法、影響の評価方法、誰が承認するかを開発開始前に決めておきます。変更ごとに費用と納期への影響を確認する仕組みがあれば、範囲の膨張を防げます。

あわせて、発注側の意思決定者を明確にしておくことが欠かせません。業務部門と情報システム部門の双方が判断に関わり、迷ったときに最終判断を下せる人を決めておくと、開発が止まる時間を減らせます。

開発会社を価格以外の軸で選ぶ

システム開発の依頼先を見積もり金額だけで選ぶと、要件の理解が浅いまま低い金額を提示した会社を選んでしまうリスクがあります。見積もりの内訳、同種の業務システムの開発経験、要件定義やテストへの関わり方を比較することが大切です。

業務への理解や画面設計まで含めて責任を持てるかも重要な判断軸です。比較の観点は業務システム・DXに強い開発会社の選び方で詳しく紹介しています。

受け入れテストの計画を発注側で持つ

受け入れテストは、完成したシステムが業務で使えるかを発注側が確かめる最後の機会です。テストの計画を開発会社任せにすると、仕様どおりに動くかの確認に偏り、実際の業務の流れで使えるかが検証されないまま稼働を迎えてしまいます。

発注側は、要件定義の段階から「どの業務を、どのデータで、誰が確認すれば合格とするか」を決めておきます。月末処理や差し戻しなどの例外も含めたテストの場面を用意しておくと、システム開発の終盤で慌てることが少なくなります。

システム開発が失敗しそうなときはどう判断すべきか

システム開発が失敗しそうな兆候に気づいたら、まず事実を確認し、そのうえで続ける、範囲を縮小する、いったん止めるの3つから選びます。判断を先送りにするほど、費用と時間の損失は大きくなります。

失敗の兆候を早めにつかむ

システム開発の失敗には、事前にいくつかの兆候が現れます。兆候の段階で気づければ、打てる手は多く残っています。要件定義の完了が繰り返し延期される、仕様変更の件数が減らない、進捗報告が「順調です」だけで中身がない、といった状態はいずれも注意が必要です。

開発会社からの報告を待つだけでなく、発注側からも完成した画面や機能を定期的に確認する場を設けると、兆候に早く気づけます。

続けるか止めるかの判断基準

兆候に気づいたら、目的がまだ有効か、残りの範囲で目的を達成できるか、追加の費用と期間が許容範囲に収まるかの3点を確認します。3つとも満たすなら計画を見直して続け、一部しか満たさないなら範囲を絞り、目的自体が成り立たないなら止めることを検討します。

システム開発を止める判断は難しく感じられますが、すでに投じた費用は取り戻せません。これから必要になる費用と得られる効果だけを比べて判断することが大切です。

立て直すときに見直すポイント

続ける、または範囲を絞る場合は、要件の優先順位、体制、契約形態の3点を見直します。特に、当初の契約形態が現在の進め方と合っていない場合は、開発会社と率直に協議する必要があります。

あわせて、仕様書や設計書、ソースコードが発注側の手元にあるかも確認しておきます。必要な資料がそろっていれば、別の開発会社に相談する選択肢も残せます。

まとめ

システム開発の失敗は、品質・コスト・納期の崩れに加え、完成しても目的を果たせない状態を含めて捉える必要があります。原因は発注側、開発側、双方の間の3つに分けられ、中でも双方の認識のずれが最も多く見られます。

工程で見ると、原因の多くは企画と要件定義で仕込まれ、テストや移行の段階で表面化します。発注側は、目的と優先順位を文書にし、要件を画面と業務の流れで確認し、変更管理と判断体制を整え、開発会社を価格以外の軸で選ぶことで、失敗の多くを防げます。

それでも失敗の兆候が見えたときは、続ける、絞る、止めるのいずれかを早めに判断することが損失を抑える鍵になります。

システム開発の失敗に関するよくある質問

システム開発の失敗は発注側と開発側のどちらの責任になりますか

一概には言えません。契約で定めた範囲や役割分担によって責任の所在は変わり、要件の確定や判断が発注側の役割とされている場合は、発注側の責任が問われることもあります。

実務上は、責任の所在を争うよりも、失敗の原因になった認識のずれを早く解消することのほうが重要です。契約時に役割分担と変更時の手続きを明確にしておくことが、トラブルを防ぐ最善の方法です。

システム開発の失敗を防ぐために最も重要な工程はどこですか

最も重要なのは要件定義です。要件定義で決めた内容が、その後の設計、開発、テストのすべての前提になるため、ここでのずれは後工程ほど大きな手戻りになります。

要件定義では、文章だけで合意するのではなく、画面のイメージや業務の流れで利用者と確認することをおすすめします。

アジャイル開発ならシステム開発の失敗を防げますか

アジャイル開発は、短い期間で動くものを作って確認するため、認識のずれに早く気づける点で有効です。ただし、発注側が優先順位を判断し続ける体制がなければ、かえって範囲が膨らむおそれがあります。

開発手法の選択だけで失敗を防げるわけではありません。要件の確定度合いや社内体制に合わせて、進め方と契約形態を選ぶことが大切です。

開発途中で開発会社を変更することはできますか

可能です。ただし、仕様書や設計書、ソースコードの扱いが契約で明確になっていないと、引き継ぎに大きな手間と費用がかかります。

途中での変更を検討する場合は、まず手元にある資料と権利関係を確認し、引き継ぎを受ける会社に現状の調査から依頼するのが現実的な進め方です。

システム開発の失敗事例から学ぶときの注意点はありますか

他社のシステム開発の失敗事例は、結果だけでなく、どの工程のどの判断が原因になったのかに注目して読むことが大切です。同じ症状でも、原因が目的の曖昧さにあるのか、契約形態や体制にあるのかで、自社がとるべき対策は変わります。

また、規模や業種が違っても、要件の認識ずれや意思決定者の不在といった原因は共通していることが多くあります。自社のプロジェクトに当てはめて、同じ兆候が出ていないかを確認する材料として活用してください。