システム開発プロジェクトが失敗すると聞くと、技術力の不足やエンジニアのミスを思い浮かべる人が多いかもしれません。しかし実際に失敗したプロジェクトを振り返ると、原因の多くは技術そのものではなく、その手前にあります。何を作るかが曖昧なまま進んだ、決めるべき人が決めなかった、伝えたつもりのことが伝わっていなかった。要件・意思決定・コミュニケーションのどこかが欠けていたことが、後になって大きな手戻りや予算超過、使われないシステムという形で表に出るのです。
裏を返せば、発注側が初期にいくつかの手を打つだけで、失敗の多くは予防できます。目的と範囲を言葉にする、判断する人と判断の期限を決める、途中の成果物を早く見る、変更のルールを先に決める。どれも特別な技術を必要としない、発注側の仕事です。
この記事は、これからシステム開発を発注する事業責任者や、進行中のプロジェクトに不安を感じている担当者に向けて書いています。失敗の典型的な形と原因、失敗に向かうプロジェクトに現れる兆候、発注側が打てる予防策、つまずき始めたときの立て直し方までを、チェックリストと手順で具体的に整理します。
システム開発の「失敗」とは何か：3つの形
一口に失敗といっても、その形はいくつかに分かれます。どの形の失敗を防ぎたいのかを意識しておくと、打つべき手がはっきりします。
なお、ここで言う失敗には、プロジェクトが途中で中止になるケースも含まれます。中止は最も大きな損失に見えますが、見込みのないまま続けて損失を広げるより、早めに中止や方向転換を判断したほうがよい場合もあります。問題は中止そのものより、判断が遅れることです。
一つ目は、予算やスケジュールの大幅な超過です。開発の途中で追加の作業が次々と発生し、当初の見積もりや公開予定日を大きく超えてしまう形です。最も目に見えやすい失敗で、発注側と開発会社の関係が悪化するきっかけにもなります。
二つ目は、完成したものが期待と違うという形です。予定どおり完成したものの、現場が想定していた動きと違う、必要な機能が足りない、使いにくいといった問題が、受入テストや公開後に明らかになります。修正には追加の費用と時間がかかります。
三つ目は、完成しても使われない、成果が出ないという形です。システム自体は要件どおりに動いていても、現場の業務に定着しない、事業の成果につながらないというものです。予算もスケジュールも守られているため、失敗として認識されにくいのが厄介な点です。
この3つの形はつながっています。要件が曖昧なまま進めば期待と違うものができ、その修正で予算が超過し、無理に合わせた結果、使いにくく定着しないシステムが残る。根っこにある原因に手を打つことが、どの形の失敗も防ぐ近道です。
失敗の原因は技術より「要件・意思決定・コミュニケーション」にある
失敗の原因を、発注側が手を打てるかどうかの観点で整理します。
| 原因の領域 | 典型的な状態 | 結果として起きること | 発注側が打てる手 |
|---|---|---|---|
| 要件 | 目的が曖昧、範囲が決まっていない、例外が書かれていない | 期待と違うもの、追加費用、手戻り | 目的と範囲、範囲外を言葉にする |
| 意思決定 | 決める人が不在、判断が遅い、後から覆る | 開発の停止、スケジュール遅延 | 決裁者と判断の期限を決める |
| コミュニケーション | 伝えたつもり、記録がない、途中の確認がない | 認識のずれの発見が遅れる | 決定事項の記録、早い段階での確認 |
| 計画と期待値 | 楽観的な期間、社内工数の未確保、予備の不在 | 確認の遅れ、余裕のない判断 | 社内の時間と予備を計画に入れる |
要件の欠落：何を作るかが曖昧なまま進む
最も多い原因が要件の曖昧さです。「業務を効率化したい」という目的のまま開発に進むと、開発会社は分からない部分を自分たちの解釈で埋めるしかありません。特に、業務の例外、管理者が使う機能、データの移行、権限の違いといった部分は、発注側が書かない限り伝わりません。
もう一つの典型は、範囲が膨らみ続けることです。要件を議論する中で「これもあったほうがいい」という要望が積み重なり、当初の目的に必要な範囲を大きく超えていきます。何を作らないかを決めないまま進めると、プロジェクトは終わりが見えなくなります。要件を言葉にする方法は要件定義書の書き方で解説しています。
意思決定の欠落：決める人がいない、決めたことが覆る
開発の途中では、仕様の細部、優先順位、変更の可否など、発注側が決めなければならないことが次々に出てきます。決める人が明確でない、決裁者が多忙で判断が後回しになる、担当者が決めたことを後から上位者が覆す。こうした状態が続くと、開発会社は作業を止めて待つか、仮の判断で進めて後でやり直すかのどちらかになります。
特に危ないのは、プロジェクトの終盤になって初めて決裁者が成果物を見て、方向性そのものを覆すケースです。それまでの作業の多くが無駄になり、予算もスケジュールも大きく崩れます。
コミュニケーションの欠落：伝えたつもり、聞いたつもり
打ち合わせで話したことが、議事録に残っていない。口頭で伝えた変更が、開発会社の担当者の間で共有されていない。社内用語の意味が、開発会社には別の意味で伝わっている。こうした小さなずれが積み重なり、完成間際に大きな認識の違いとして表に出ます。
途中の成果物を見る機会がないことも、ずれの発見を遅らせます。動く画面を最後まで見ないまま進むと、期待と違うことに気づくのは受入テストの段階になり、修正の手間は最大になります。
計画と期待値の欠落：楽観的な前提で始める
期間を短く見積もりすぎる、発注側の担当者が通常業務と兼務で時間を確保していない、予算に余裕がまったくない。こうした楽観的な前提で始まったプロジェクトは、小さなつまずき一つで崩れます。予備がなければ、必要な修正すら判断できなくなるからです。
期待値のずれも見落とせません。発注側は「この予算で全部できる」と思い込み、開発会社は「初回はここまで」と考えている。あるいは、公開すればすぐに業務が楽になると期待していたのに、実際には移行期間に手作業が増える。こうした期待値の違いを最初にすり合わせておかないと、予定どおりに進んでいても「失敗した」という評価になってしまいます。何が、いつ、どの程度実現するのかを、関係者の間で具体的に合意しておくことが大切です。
失敗に向かうプロジェクトに現れる兆候
失敗はある日突然起きるのではなく、早い段階から兆候が現れています。次のような状態に気づいたら、手を打つタイミングです。
- 定例会で「確認中」「検討中」の項目が毎回増えていき、減らない
- 開発会社からの質問への回答が、何日も返せていない
- 動く画面をまだ一度も見ていない、または見たが誰も触っていない
- 「その件は前に話したはず」というやり取りが増えている
- 決裁者がプロジェクトの状況を把握していない
- 仕様の変更や追加が口頭で了承され、記録が残っていない
- 進捗の報告が「順調です」だけで、具体的な完了状況が分からない
- 現場の担当者が打ち合わせに参加しておらず、要件の確認ができていない
- 公開日だけが決まっていて、そこから逆算した計画がない
これらの兆候の多くは、発注側が自分で気づける状態です。開発会社の進め方に原因があるように見えても、実は発注側の回答の遅れや決定の曖昧さが引き金になっていることも少なくありません。兆候を見つけたら、誰かを責める前に、未決定事項の一覧と回答待ちの質問の一覧を作ってみてください。どこで流れが止まっているのかが、それだけでかなり見えてきます。
発注側が初期に打てる予防策の手順
失敗を予防するために、発注側がプロジェクトの初期に行うべきことを手順として示します。
- 目的と成功の基準を一文にする：何のために作るのか、何が実現すれば成功なのかを、決裁者と合意して書き出します。判断に迷ったときの拠り所になります。
- 範囲と範囲外を決める：初回に作る機能を必須のものに絞り、今回は作らないものを明記します。範囲外の一覧は、要望が膨らんだときの歯止めになります。
- 体制と役割を決める：窓口の担当者、決裁者、業務の情報を出す現場の担当者を決め、それぞれが使える時間を確保します。
- 判断のルールを決める：誰が何を決めるのか、質問への回答期限、決裁者の判断が必要な事項の扱いを決めて、開発会社と共有します。
- 変更のルールを決める：仕様変更や追加の要望が出たときに、内容、理由、費用と期間への影響を確認し、誰が判断するかを決めておきます。変更への対応は開発途中の仕様変更にどう対応するかでも解説しています。
- 途中の成果物を見る機会を組み込む：動く画面を定期的に見せてもらう日程を最初に決め、決裁者と現場の担当者も確認に参加します。
- 記録の方法を決める：決定事項、課題、変更を記録する場所と形式を決め、開発会社と共有します。
- 予備を持つ：予算とスケジュールに、想定外の事態に対応するための余地を残しておきます。
これらの手順は、どれも開発が始まる前、遅くとも開発の初期に行うものです。後から整えようとすると、すでに生じたずれを解消する手間が加わります。
小さく作って早く見る
予防策の中でも特に効果が大きいのが、6番目の「途中の成果物を見る」を徹底することです。すべての機能を作り終えてから確認するのではなく、主要な画面や業務の流れを一つずつ動く形にして、その都度確認していく進め方にすると、認識のずれが小さいうちに見つかります。
この進め方は、要件を最初に完璧に固めることが難しい新規事業や、現場の使い勝手が成否を分ける業務システムで特に有効です。動くものを見ると、文書では気づかなかった要望や不要な機能がはっきりします。範囲の大きなシステムでも、最初に作る部分を絞り、確認と改善を繰り返すことで、終盤に方向性が覆るリスクを抑えられます。
定例会を「決める場」にする
定例会が進捗の報告を聞くだけの場になっていると、決めるべきことが次回に持ち越され続けます。定例会の議題には、毎回「今回決めること」を明記し、決裁が必要な事項は決裁者が参加する回に集めます。決まったことはその場で記録し、参加者全員で確認してから終えるようにすると、伝えたつもり・聞いたつもりのずれも減ります。発注側の管理の進め方は発注側のプロジェクト管理でも詳しく扱っています。
架空の例：終盤で方向性が覆りかけたケース
ここで、仕組みを理解するための架空の例を紹介します。ある会社が、営業担当が外出先から顧客の情報を入力できるシステムの開発を始めました。窓口は営業企画の担当者で、要件定義も担当者と開発会社の間で進められました。
開発が終盤に差しかかったころ、営業部門の責任者が初めて画面を見て、「入力項目が多すぎて、外出先では誰も使わない」と指摘しました。担当者は管理側の分析に必要な項目をすべて入れていましたが、責任者が重視していたのは、現場が短時間で入力できることでした。目的の優先順位が、担当者と責任者の間でそろっていなかったのです。
この会社は、開発会社と相談して、入力項目を必須と任意に分け、外出先では必須項目だけを入力できる画面を追加することにしました。全面的な作り直しは避けられましたが、追加の費用と公開の延期が発生しました。振り返ると、手順の1番目にある目的と成功の基準を決裁者と合意していれば、また手順の6番目にある途中の確認に責任者が参加していれば、もっと早くずれに気づけたはずでした。
この会社は次のプロジェクトから、開発の開始前に決裁者と現場の代表者を交えて目的の優先順位を確認する場を設け、主要な画面ができた段階で必ず現場の担当者に触ってもらう日程を計画に入れるようにしました。追加の会議は増えましたが、終盤の大きな手戻りはなくなったといいます。
すでにつまずき始めたときの立て直し方
兆候に気づいたとき、またはすでに遅れや予算超過が起きているときは、次の順番で立て直しを図ります。
現状を事実で把握する
立て直しの第一歩は、責任の所在を探すことではなく、状況を共有することです。まず、何が完了していて、何が残っているのか、未決定の事項は何かを、開発会社と一緒に洗い出します。「順調」「遅れ気味」といった印象ではなく、機能ごとの完了状況と、未決定事項の一覧という事実で把握することが出発点です。
範囲を絞り直す
残りの作業をすべて予定どおりに終えることが難しい場合は、目的に照らして範囲を絞り直します。初回の公開に必須の機能だけを残し、それ以外は次の段階に回す判断です。手作業で補える部分は、当面手作業で運用する選択肢もあります。絞り直した範囲と、次の段階に回した機能は一覧にして関係者で合意し、公開日と予算の見通しを改めて共有します。
判断の滞りを解消する
未決定の事項がたまっている場合は、決裁者が参加する場を設け、まとめて判断します。判断を先送りにすると、立て直しの計画そのものが立てられません。
進め方を変える
コミュニケーションの問題が原因であれば、定例会の頻度や参加者、記録の方法を見直します。開発会社の体制に問題がある場合は、担当者の変更や体制の強化を相談します。どうしても立て直せない場合は、依頼先の変更も選択肢になりますが、引き継ぎには相応の手間がかかるため、まず現在の体制での立て直しを検討します。依頼先の変更については開発会社を途中で変更するにはで解説しています。
よくある失敗と予防のチェックリスト
よくある失敗と避け方
- 目的を共有しないまま開発会社を選ぶ：選定の段階から目的と範囲を伝えていないと、各社の提案も見積もりもずれます。準備の段階で目的を言葉にしましょう。
- 担当者に任せきりで決裁者が関わらない：終盤で方向性が覆る原因になります。決裁者には途中の確認に参加してもらいます。
- 現場の担当者を巻き込まない：業務の例外や使い勝手の問題は、現場にしか分かりません。要件定義と受入テストに現場を参加させます。
- 変更を口頭で済ませる：記録がないと、何が合意された仕様なのか分からなくなります。変更は必ず記録します。
- 開発会社の「順調です」を鵜呑みにする：具体的な完了状況と、動く画面で確認しましょう。
- 予備を持たずに始める：想定外は必ず起きます。予算とスケジュールに余地を残しておきます。
予防のチェックリスト
- 目的と成功の基準を、決裁者と合意した言葉で書いているか
- 初回の範囲と、範囲外の一覧が決まっているか
- 窓口の担当者、決裁者、現場の担当者が決まり、時間を確保しているか
- 誰が何を決めるか、質問への回答期限が決まっているか
- 仕様変更の判断のルールが決まっているか
- 動く画面を確認する日程が組み込まれ、決裁者も参加するか
- 決定事項、課題、変更の記録方法が開発会社と共有されているか
- 予算とスケジュールに予備があるか
よくある質問
Q. 失敗の責任は開発会社にあるのではないですか？
開発会社に原因がある失敗もありますが、要件の提供、判断、確認は発注側にしかできない仕事です。どちらに責任があるかを議論するより、双方が役割を果たせる体制を最初に作るほうが、失敗を防ぐうえで効果的です。
Q. 要件をしっかり固めれば失敗は防げますか？
要件を固めることは大切ですが、それだけでは十分ではありません。開発の途中でも判断が必要な場面は出てきますし、実際に動くものを見て初めて気づくこともあります。要件の固め方と同じくらい、途中で確認し判断する仕組みが重要です。
Q. 小さなプロジェクトでも同じ対策が必要ですか？
規模が小さくても、目的と範囲の明確化、決裁者の関与、途中の確認は必要です。ただし、文書の量や会議の頻度は規模に合わせて軽くしてかまいません。目的と範囲を1枚にまとめ、週に一度動くものを見て判断する、という程度の仕組みでも、大きな行き違いは十分に防げます。
Q. 進行中のプロジェクトが危ないと感じたら、まず何をすべきですか？
まず開発会社と一緒に、完了したこと、残っていること、未決定の事項を事実で洗い出します。そのうえで、決裁者を交えて範囲と優先順位を見直すのが立て直しの第一歩です。
Otsumuに相談できること
社内に目的と範囲を整理できる担当者がいて、決裁者が途中の確認にも関われる体制が組めるなら、この記事の予防策を実行するだけで、失敗の多くは防げます。小さく始めて途中で確認を重ねる進め方は、外部の力を借りなくても取り入れられます。
一方で、何を作るべきかの判断に自信がない、社内に開発の進め方を知る人がいない、進行中のプロジェクトがすでにつまずいていて立て直しの方針が立たない、といった状況では、事業と開発の両方を理解する第三者が入ることで、判断の滞りがほどけることがあります。
Otsumuは、自らも事業を手がける立場から、目的から逆算して必要な機能に絞り込み、構想から開発・運用・改善までを一気通貫で担当しています。AIを活用した開発で少人数・短期間に動くものを見せられるため、途中での確認と判断を重ねながら進められます。システム開発のページでは種類別の進め方を紹介しており、事業の方向性から見直す必要がある場合は新規事業開発コンサルティングとして伴走することもできます。
進行中のプロジェクトの状況整理だけでもご相談ください。まずは30分の無料相談で、現在の状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01