システム開発を外注するとき、多くの担当者が抱えているのは「うちのプロジェクトは大丈夫だろうか」という漠然とした不安です。社内で過去に失敗した話を聞いていたり、他社が数千万円かけて使われないシステムを作ったという噂を耳にしていたりすると、自分が同じ道を辿るのではないかと落ち着かなくなります。稟議を通した本人であればなおさらです。
先に結論をお伝えします。システム開発の失敗は、納期の超過、予算の超過、品質の不足、そして「完成したのに使われない」の4つの形で表に出てきます。そして原因のほとんどは、開発会社の技術力ではなく、要件の合意のしかた、決める人の置き方、悪い情報が伝わる経路という3点に集約されます。いずれも発注側が手を出せる領域です。この記事では、よくある失敗事例に共通する構造を整理したうえで、進行中に兆候を見抜く方法と、崩れかけたプロジェクトの立て直し方までをまとめます。
この記事のポイント
- 失敗は納期・予算・品質・使われないの4つの形で表面化する
- 原因の大半は要件の合意・決裁者の不在・報告ルートの3点に集約される
- 出回っている失敗率の数字は出典が曖昧で自社の判断には使えない
- 兆候は週次報告の言葉づかいと課題管理表の動き方に先に出る
目次
システム開発の失敗事例に共通する原因
失敗事例を集めて読んでいくと、業種も規模もバラバラなのに、崩れ方がよく似ていることに気づきます。ここでは個別のエピソードではなく、繰り返し現れる構造のほうを見ていきます。自社のプロジェクトに当てはめながら読むと、どこが薄いかが見えてくるはずです。
失敗と呼ばれる状態は4つある
まず言葉の定義を揃えます。「失敗した」と言われるとき、実際には次の4つのどれかが起きています。
| 形 | 起きていること | 発注側が最初に気づく場面 |
|---|---|---|
| 納期の超過 | 予定した稼働日に間に合わない | テスト工程の開始が後ろにずれる |
| 予算の超過 | 追加費用の見積もりが次々に出てくる | 仕様変更が有償か無償かで揉め始める |
| 品質の不足 | 不具合が収束せず稼働判定ができない | 受入テストで同じ画面から何度も差し戻す |
| 使われない | 稼働したが現場が旧来のやり方に戻る | 稼働3か月後の利用率が上がらない |
このうち4つ目が厄介です。納期も予算も守り、不具合も出ていないのに、現場が使ってくれない。契約上は何の問題もないので誰も責任を問われませんが、投資としては完全な失敗です。私の感覚では、発注側が一番後悔するのはこのパターンです。前の3つは進行中に痛みを感じるので手を打てますが、4つ目は稼働してから静かに判明します。
そして重要なのは、この4つが独立していないことです。品質が足りないと差し戻しが増えて納期が延び、納期が延びると人件費が積み上がって予算が超過します。最初の綻びがどこで生まれたかを遡ると、たいていは着工前の合意に行き着きます。
要件の合意が言葉のまま終わる
最も多い原因は、要件が言葉のレベルで合意されたまま設計に進んでしまうことです。「使いやすい画面にしてください」「今の業務がそのまま回るようにしてください」といった依頼は、発注側にとっては十分に具体的なつもりでも、開発会社から見れば無数の解釈が成り立ちます。
ありがちなのは、承認フローの認識違いです。発注側は「部長が承認する」と言い、開発会社は1段階の承認機能を作ります。ところが実際の業務では、金額が一定を超えると役員承認が加わり、部長が不在なら代理承認が発生し、差し戻しの履歴も残す必要がある。この差は要件定義書に「承認機能」としか書かれていなければ絶対に埋まりません。テスト段階で発覚し、設計からやり直しになります。
防ぎ方は難しくありません。要件を「誰が」「どういう条件のとき」「何をして」「その結果どうなる」という粒度まで割ることです。文章にすると面倒に見えますが、この粒度まで書けていれば開発会社は金額を出せます。逆に言えば、開発会社が金額を出せない要件は、まだ合意できていない要件です。要件定義の段階でどこにつまずきやすいかは、要件定義が失敗する原因と発注側でできる対策で詳しく整理しています。
決める人が決めていない体制
2つ目は体制の問題です。プロジェクトが止まる理由の多くは、技術的な難所ではなく「決めてくれる人がつかまらない」ことにあります。
典型的なのは、現場の担当者だけが打ち合わせに出ている構図です。開発会社から「A案とB案のどちらにしますか」と聞かれても、その場では答えられない。持ち帰って上長に確認し、上長がさらに他部署に確認し、2週間後に回答が返ってくる。この間、開発会社は手を止めるか、推測で進めるかの二択を迫られます。推測で進めれば手戻りになり、止めれば納期が押します。
もう一つの型が、窓口の多重化です。営業部門と管理部門がそれぞれ別に開発会社へ要望を伝え、内容が食い違ったまま両方が実装される。あるいは後から伝えたほうだけが通り、先に伝えた側が「聞いていない」と怒る。開発会社にとっては、誰の指示が正なのか分からない状態です。
この2つを避けるには、着工前に決裁者を1人決めて名前を出し、窓口を1本にすることです。決裁者は必ずしも役員である必要はなく、その場で判断できる権限を持っていればかまいません。重要なのは、開発会社が「この人に聞けば決まる」と分かっていることです。
悪い報告が上がらない仕組み
3つ目は、あまり語られない論点です。失敗したプロジェクトを後から振り返ると、遅れの兆候はかなり早い段階で現場に出ていたのに、発注側の決裁者まで届いていなかったというケースが少なくありません。
週次の進捗報告が「順調です」「おおむね予定どおりです」という言葉で埋まり続けるのは、順調だからとは限りません。開発会社の担当者が、社内で問題を認めたくない、あるいは発注側に伝えると責められると感じている場合も、報告はきれいになります。悪い情報ほど、伝えるコストが高いのです。
発注側にできるのは、悪い報告を出しても損をしない場を作ることです。具体的には、進捗会議で「今週うまくいかなかったことはありますか」と明示的に聞く時間を取る、課題管理表に未解決のまま残っている項目を一緒に読む、といった運用です。私が現場でよく見るのは、課題管理表の更新が止まった時点がプロジェクトの転換点になっているケースです。項目が増えなくなったら、解決したのではなく、書かなくなったのだと疑ったほうが安全です。
失敗率の数字はそのまま使えない
ここで、検索していると必ず目に入る「失敗率」について触れておきます。「システム開発の失敗率は47%」「約7割が計画どおりに完了していない」といった数字が、多くの記事で引用されています。
正直に書きますが、これらの数字を自社の判断材料に使うことは私はおすすめしません。調査ごとに「失敗」の定義が違い、対象となるプロジェクトの規模も業種も揃っていないためです。納期が1日でも遅れたら失敗と数えている調査と、中止になったものだけを失敗と数えている調査では、当然まったく違う数字が出ます。引用元をたどると有料記事や出典表記のない孫引きに行き着くことも多く、検証ができません。
数字を見るなら、自分で条件を確認できる一次情報にあたるほうが役に立ちます。たとえば独立行政法人情報処理推進機構がまとめたソフトウェア開発分析データ集では、実際のプロジェクトから集めた工数や工期の分布が公開されています。事業終了に伴い2022年版が最新となっている点には注意が必要ですが、自社が提示された見積もりの工期が実績の分布と比べて無理をしていないかを見るには使えます。「他社も半分は失敗しているらしい」という話より、自分のプロジェクトの数字を実績分布と突き合わせるほうが、判断にはるかに効きます。
システム開発の失敗を発注側が防ぐ進め方
ここからは打ち手の話に移ります。原因が分かっても、実際に手を動かす順番が分からなければ意味がありません。発注前、進行中、崩れかけたときの3つの局面に分けて整理します。
発注前に決めておく3つのこと
着工前に固めておくと後が楽になるのは、次の3つです。どれも技術の話ではないので、情シスの専任者がいない会社でも準備できます。
- 決裁者を1人決め、名前と権限範囲を開発会社に伝える
- 今回やらないことを文書にして、双方で確認する
- 検収の合格条件を、契約前に具体的な文章で書いておく
2つ目の「やらないこと」は、意外に効きます。要件定義書はやることを書く文書なので、書かれていない機能の扱いが曖昧になりがちです。将来的に追加する予定のもの、今回は手作業のまま残すもの、他システムとの連携で今回は対象外にするものを明示しておくと、後から「当然入っていると思っていた」という衝突が減ります。
3つ目の検収条件は、揉めたときに唯一の拠り所になります。「業務が問題なく回ること」といった書き方では判定できません。どの業務シナリオが通れば合格なのか、残っていてよい不具合の程度はどこまでか、といった水準まで書いておきます。要件の抜けは自分たちだけで点検すると見落としやすいので、第三者の観点を借りるのが現実的です。追加費用・手戻りを防ぐ要件定義書レビューシートでは、発注前に確認しておきたい項目を一覧にしています。
進行中に現れる失敗の兆候
着工後は、数字が悪化する前に言葉と運用に兆候が出ます。次の表は、私が現場で「これが出たら一度立ち止まる」と考えている組み合わせです。
| 見えている兆候 | 裏で起きている可能性 | その場で聞くとよい質問 |
|---|---|---|
| 課題管理表の新規登録が止まる | 課題を記録せず口頭処理に切り替えている | 今週クローズした課題はどれですか |
| 報告が抽象的な言葉に変わる | 数字で報告できない状況になっている | 完了した画面数は予定に対して何本ですか |
| 担当者が静かに入れ替わる | 体制が縮小、または社内で問題化している | 体制表の更新版をいただけますか |
| テスト期間だけが短縮される | 前工程の遅れを後工程で吸収している | 短縮した分の品質はどう担保しますか |
どれも責める必要はありません。むしろ、早い段階で穏やかに聞くほど開発会社は答えやすくなります。目的は犯人探しではなく、まだ手が打てるうちに実態を共有することです。工程ごとに発注側が何を確認すべきかは、システム開発の工程と流れの記事で工程別に整理しています。
立て直しは追加費用の前に行う
それでも遅れが表面化することはあります。このとき発注側がやりがちなのが、開発会社から出てきた追加費用の見積もりに、内容を確かめないまま応じてしまうことです。稼働日が迫っていると、お金で解決したくなる気持ちは分かります。ただ、原因を特定しないまま人を増やしても、たいていは事態が悪化します。
順番としては、支払いを決める前に次の3つを確認します。第一に、遅れているのがどの工程かを特定すること。設計が終わっていないのか、実装が滞っているのか、テストで不具合が収束しないのかで打ち手はまったく違います。第二に、遅れの原因が発注側の回答待ちにあるのか、開発会社の見積もり誤りにあるのかを切り分けること。ここが曖昧なまま追加費用の話に入ると、双方が納得できません。第三に、稼働範囲を削る選択肢を検討することです。全機能を予定日に出すのを諦め、業務が回る最小限で稼働させて残りを次期に回すほうが、傷は浅く済みます。
そのうえで、契約や責任の線引きが問題になる局面では、契約形態そのものに起因する落とし穴もあります。請負と準委任のどちらで契約しているかによって、遅れの責任の所在も追加費用の扱いも変わってきます。この部分は受託開発でよくある失敗パターンのほうで契約面から整理しています。
