「見積もり3倍、納期2倍」になったシステム開発の"犯人"を探せ
- 開発部
- 6 日前
- 読了時間: 6分
更新日：4 日前
こんにちは！株式会社雲海設計の技術部です。
「当初の見積もりは500万円だったはずが最終的に1500万円に。半年で終わるはずのプロジェクトが1年経ってもまだ終わらない…」
これはシステム開発の現場で決して珍しくない「事件」です。
実際、開発経験者への調査では納期に関するトラブル・失敗が「よくある／時々ある」と答えた人が7割超、予算に関するトラブル・失敗も半数近くにのぼります。
さらに別の調査では「問題の根本要因」は要件定義（55%）・設計（51%）など前工程に集中しています。
なぜこのような「事件」が繰り返されるのでしょうか？
この記事では読者の皆様に「探偵」になっていただき、システム開発プロジェクトを破綻させた「犯人」を一緒に突き止めていきたいと思います。現場に残された証拠（データ）を元に、5人の容疑者を徹底的に洗い出していきましょう。
事件現場：A社・新顧客管理システム開発プロジェクト
被害状況：見積もり3倍、納期2倍
当初の見積もり：500万円 / 6ヶ月
最終的なコスト：1500万円 / 12ヶ月
事件の概要
Excelでの顧客管理に限界を感じ新システム導入を決意。しかしプロジェクトは迷走し、予算と納期が大幅に超過。現場は疲弊し経営陣は頭を抱えている。
一体、誰がこのプロジェクトをここまで追い詰めたのでしょうか？
容疑者たちのリスト
私たちの捜査線上に浮かび上がったのは以下の5人の容疑者です。
彼らは皆、システム開発の現場で頻繁に目撃される常習犯でもあります。
容疑者A：曖昧な"要件定義"
容疑者B：気まぐれな"仕様変更"
容疑者C：丸投げ体質の"発注者"
容疑者D：楽観的な"開発者"
容疑者E：未知なる"技術トラブル"
一人ずつ、証拠を元に取り調べていきましょう。
容疑者A：曖昧な"要件定義"
最初の容疑者はプロジェクトの出発点に潜む「曖昧な"要件定義"」です。
彼はふんわりとした理想論や「いい感じに」「適切に」といった言葉を巧みに使い、プロジェクトの土台を脆くします。
【証拠物件1】
予算トラブルの原因として最も多かったのは仕様が曖昧なのに予算だけ決まっていた
【証拠物件2】
ITプロジェクトの炎上原因の過半数が要件定義と設計に起因する
【犯行手口】
「とりあえず顧客管理がしたい」という曖昧な要望のままプロジェクトを開始させ、後から「やっぱりこんな機能も」「あのデータも見たい」といった追加要求を誘発します。最初に何をどこまで作るかが決まっていないため、ゴールが無限に広がり予算と納期を蝕んでいくのです。
容疑者B：気まぐれな"仕様変更"
次に怪しいのはプロジェクトの途中で現れる「気まぐれな"仕様変更"」です。
彼は「やっぱりこっちの方が良い」という鶴の一声で積み上げた設計をいとも簡単に覆します。
【証拠物件】
納期トラブルの原因として最も多かったのは要件や仕様の変更が多かった
【犯行手口】
開発が進んだ段階で「ボタンの色を変えてほしい」といった軽微な変更から「管理画面の構成を根本から見直したい」といった大規模な変更まで、悪びれもなく要求します。一度の変更は小さく見えても、積み重なることで開発チームの工数を圧迫し、気づけばスケジュールは火の車。まさに"デスマーチ"への片道切符です。
容疑者C：丸投げ体質の"発注者"
3人目の容疑者はプロジェクトの当事者であるはずの「丸投げ体質の"発注者"」です。
「プロに任せるよ」という聞こえの良い言葉を盾に、プロジェクトへの関与を放棄します。
【証拠物件】
納期トラブルの原因として発注者の判断・返答が遅れた、発注者から非現実的な納期を指定された
【犯行手口】
開発チームからの仕様確認の連絡を放置したり重要な判断を先延ばしにしたりすることで、プロジェクトの進行を妨害します。また、システム開発の難易度を理解しないまま「このくらい明日までにできるでしょ？」と無茶な要求を突きつけ、現場の士気を著しく低下させることもあります。
容疑者D：楽観的な"開発者"
意外かもしれませんが、プロジェクトを推進する側の「楽観的な"開発者"」も容疑者の一人です。
「できます、やります」という威勢の良い言葉で安請け合いし、後になって自分の首を絞めます。
【証拠物件】
納期トラブルの原因として開発側のスケジュール見積もりが甘かった、予算トラブルの原因として開発側の工数の見積もりが甘く赤字になった
【犯行手口】
新しい技術への挑戦意欲や「できない」と言いたくないプライドから、リスクを考慮しない楽観的な見積もりを提示します。しかし開発の過程で予期せぬ問題に直面し、結果的に約束した予算や納期を守れなくなるのです。
容疑者E：未知なる"技術トラブル"
最後の容疑者は誰のせいでもないように見える「未知なる"技術トラブル"」です。
彼はライブラリのバグや特定の環境でしか発生しない不具合など、予測不能な姿で現れます。
【証拠物件】
納期トラブルの原因として想定外の技術的トラブルが発生した
【犯行手口】
順調に進んでいるように見えたプロジェクトを、突如として停止させます。原因の特定に時間がかかり、解決策が見つからない場合はプロジェクト全体が暗礁に乗り上げる危険性をはらんでいます。
判決："真犯人"は誰だ？
さて、5人の容疑者を取り調べてきましたが"真犯人"は特定できたでしょうか？
お気づきの方も多いかもしれませんが、この事件の"真犯人"は特定の誰か一人ではありません。
多くの場合、これらの容疑者たちが共犯関係となりプロジェクトを破綻させているのです。
曖昧な要件定義（容疑者A）が、気まぐれな仕様変更（容疑者B）を誘発し、
丸投げ体質の発注者（容疑者C）が楽観的な開発者（容疑者D）の甘い見積もりを鵜呑みにし、
そこに未知なる技術トラブル（容疑者E）が追い打ちをかける…
これこそが「見積もり3倍、納期2倍」という悲劇が生まれる典型的なシナリオです。
事件の再発を防ぐために
では、どうすればこの悲劇的な事件の再発を防げるのでしょうか？
それは特定の犯人を吊し上げるのではなく、容疑者たちが生まれる土壌そのものをなくすことです。
対策 | 具体的なアクション |
1. "見える化"を徹底する | 業務フロー図や画面遷移図を作成し「何を作りたいのか」を 関係者全員が具体的にイメージできるようにする。 |
2. 小さく始めて、育てる | 最初から完璧な100点のシステムを目指すのではなく、 まずは60点で良いのでコアとなる機能をリリースし、 ユーザーの反応を見ながら改善を繰り返す。 |
3. コミュニケーションを仕組み化する | 週に一度の定例会議を設け、進捗、課題、決定事項を必ず 記録・共有する。疑問点はすぐに聞けるチャットツールなども活用する。 |
4. パートナーとして伴走する開発会社を選ぶ | 発注者と開発会社という関係ではなく、同じゴールを目指す「パートナー」としてリスクや課題を率直に指摘し、一緒に 解決策を考えてくれる会社を選ぶ。 |
システム開発は家づくりに似ています。
どんなに腕の良い大工がいても、曖昧な設計図では良い家は建ちません。
そして建築の途中で「やっぱりリビングを広くしたい」と言えば、追加の費用と時間が必要になるのは当然です。
株式会社雲海設計ではお客様の「作りたいもの」を明確にするための徹底したヒアリングと見える化を重視しています。私たちは単なる開発会社ではなく、お客様のビジネスを成功に導くパートナーとして、プロジェクトの最初から最後まで伴走します。 参考資料 [1] PR TIMES『システム開発における納期／予算トラブルの実態調査（開発経験者107名）』, 2024年, （納期・予算のトラブル経験、および原因内訳の箇所）, https://prtimes.jp/main/html/rd/p/000000114.000070711.html
[2]FNNプライムオンライン『ソフトウェア開発の失敗要因に関する調査（要件定義55%・設計51%）』, 2025年, https://www.fnn.jp/articles/-/963346
コメント