システム開発の費用はなぜブレまくるのかを徹底検証｜失敗プロジェクトに共通する3つの根本原因を解説

システム開発の費用見積もりは、なぜいつも「想定外」になるのでしょうか。追加費用を突然請求された、途中で要件が膨らんだ、完成したシステムが使えなかった――こうした経験をお持ちの方も多いはずです。

本記事では、費用がブレる根本原因を3つのパターンに整理して解説します。発注側・開発側の双方に共通する「構造的な問題」を理解することが、失敗しないシステム開発への第一歩です。

【原因①】「見積依頼から始める」という出発点のミス

仕事の出発点が見積依頼である場合。公共機関の入札や、民間企業における相見積もりがこれに該当します。

国および地方公共団体の契約は原則として入札によらなければなりません。また民間企業による相見積もりは、少しでも有利な条件で取引したい心理も働き、商習慣として強く根付いています。さらに昨今ではWeb上で発注者とシステム開発会社を結びつける市場が広がっており、この状況に拍車をかけています。

しかし製造や建築の分野、あるいは普及商品の発注と比べると、システム開発における発注は大きく勝手が異なります。入札や相見積もりという段取りは、システム開発との相性が非常に良くないのです。

システム開発は、人間が行うプロセスを扱う仕事です。そのプロセスを実際に見ることなく、対象となる組織や働く人たちの状況を詳しく聞くこともなくイメージすることは、現実的には不可能といっても過言ではありません。

その状況でシステム開発会社が提案・見積もりをする場合、現実的な手法は以下の3つに限られます。

• 推測で提案する
• 過去の類似案件を参照して類推する
• 自社製品を提案する

にもかかわらず、見積依頼をすれば応えてくれる業者がいると期待する発注者と、それに応えることを是とする業者。この両者における「美しき誤解」によって悲劇が生まれます。

出発点から波乱要素を含んだ案件において、初回提案や見積もりが暫定であったとしても、いざ契約が交わされると「暫定」という申し送りは静かに忘れ去られます。こうして時限爆弾を抱えた状態でプロジェクトが始まります。検討が進むにつれて推測や過去の経験に基づいた提案の無理が露わになり、当初は妥当と信じられていた見積もりがブレ始め、やがて深刻な状況をもたらすのです。

【原因②】要件定義を「おまけ」扱いしてしまう

「要件定義」とは、そのソフトウェアやシステムに必要な機能や性能を明らかにしてゆく作業のこと。実際の具体的な開発作業を始める前に行う作業のひとつ。また顧客が望んでいる機能や仕様などについて、その概略をまとめた文章・文書を指すこともある。（wikipediaより）

これまでに当社はシステム開発案件の仕切り直しのご相談を数件受けたことがあります。多額の追加費用を求められて頓挫している、要件が固まらず作業が止まってしまっているなど、内容はさまざまです。

そのような相談を受ける中で、ある共通項に気づきました。当時の担当システム開発会社が着手時に出した見積書を見ると、要件定義に割り当てる費用が極端に少ないのです。大雑把に全体を「100」とすれば、要件定義にはせいぜい「5」程度の費用しか割り当てられていません。

見積書には申し訳程度の要件定義費が計上されているだけで、まるで開発作業の「おまけ」として扱われているような印象です。クライアントにとっては、目に見えない要件定義という工程に価値を見出しづらいのは理解できますが、ここを軽視することが後の費用ブレに直結します。

システムを作るという試みは、クライアントにとってそう何度も経験しないほどの大事業です。あれもこれもと要望が出てくる気持ちはよくわかります。しかし、それらを優先付けし、仕分け、抽象化し、単純化するなど、さまざまな手法で整理しなければ「本当はどうすべきか」は見えてきません。クライアントの口から語られるさまざまな要望に輪郭を与えていくプロセスこそが、システム開発最初のヤマ場といえるでしょう。

大まかに、要件定義→設計→開発→テストという工程を経てシステムは完成します。設計以降の工程は「システムを作ること」に向けて存在していますが、要件定義は「システムを作る前の検討」に向けて存在しています。つまり、要件定義はおまけどころか、むしろ比重をかけてしっかり行うべき工程です。ここをおざなりにすると、見積もった作業内容と費用がブレ、システム開発は迷走します。

【原因③】システム開発をビル建設と同じように扱う誤解

ビル建設とシステム開発はどちらも、発注者の要求に沿って設計・組み立てを行う「モノ作り」です。しかし、決定的に異なる点があります。それは、システム開発が人間の仕事のプロセスを補助するために存在しているという点です。

人間の仕事のプロセスには、「AならばX、BならばY」というルールに沿った手続きや条件分岐があります。さらに、まるで身体動作のように言葉では簡単に説明できない「暗黙知」も存在します。それをコンピューターが処理できるよう言語に還元する作業もシステム開発には含まれています。

たとえば「月末の請求処理」を思い浮かべてください。担当者は当たり前のようにこなしていますが、その手順を一から言語化しようとすると、想像以上に複雑なことに気づきます。こうした暗黙知をシステムに落とし込む作業こそが、システム開発の難しさの本質です。

このような特徴はシステム開発という営みのみが備え持つもので、印刷産業・機械製造産業・エネルギー産業など他のあらゆる産業分野には見られません。それゆえ、私たちが普段慣れ親しんでいる仕事の仕方をそのまま当てはめようとすると、プロジェクトはたちまちうまくいかなくなります。

人間が営む仕事のプロセスは、実際に目にしなければうまくイメージできません。私たちの脳は、実際に動く様子を見ずにプロセスをイメージすることが苦手です。さらに仕事のプロセスの8割は習慣的・無意識的に実行されるため、これを言語として表現するには相当の努力が必要です。

この「特異性」を発注者とシステム開発会社の双方が理解してコミュニケーションしない限り、要件定義にいくら時間をかけても取りこぼしや見逃しを防ぐことはできません。こうしてプロジェクト終盤に地雷を踏み、検討漏れが発覚する――これが費用ブレの根本原因です。

こんな資料はいかがですか？

ホワイトペーパー「意思決定の質が、そのままIT投資のリターンを決める」

－ IT導入を成功に導く「マネジメント再設計」 －

IT導入の失敗の本質は、技術ではなく「経営の意思の不在」にあります。

成功する企業はIT導入を”システムの問題”ではなく、経営そのものの再設計と捉えています。「経営の意思をどこに置くか」「それをどのように仕組みへ落とし込むか」——その設計ができるかどうかが、IT投資の成否を決める分かれ道です。本書は、経営の意思を構造として実装し、IT投資を確かな成果につなげるためのマネジメント再設計手法を、8つのステップで体系化しています。

➡今すぐ無料ダウンロード

【本書で得られること】

• 経営者が意思を示し、IT部門と共有するための言語化フレーム
• ベンダー任せにしない発注力の育て方と、成果責任を共有できる伴走体制の設計
• 経営・IT・現場が連動するマネジメント構造の再設計手法
• 属人化を解消し、組織知を育てる「学習する組織」の構築方法

まとめ：費用ブレを防ぐために発注者・開発会社ができること

システム開発の費用を見積もるという作業は、設計者の知識とノウハウを結集させることであり、案件とのあくなき闘いでもあります。人間の顔と個性が一人ひとり異なるように、クライアントの課題も一つとして同じものはありません。組織の数だけ課題があり、唯一無二の正解などないのです。

それでも日々どこかで案件が炎上しています。業界全体でも数多くの失敗が繰り返されてきましたが、一方でその失敗を克服する新たな手法が生まれ続けていることも事実です。現在ではさまざまなテクニカルな見積もり手法が存在していますが、テクニカルなアプローチはそれが有効になり得る環境が整わない限り機能しません。

費用のブレを防ぐために、発注者にできることは「正しい発注の仕方を知ること」です。具体的には次の3点が、プロジェクト成功への土台になります。

• 見積依頼の前に、自社の業務プロセスを整理する
• 要件定義に十分な時間と予算を確保する
• システム開発の特性を理解したパートナーを選ぶ

システム作りをクライアントとシステム開発会社との共同作業と捉え、共通の意識で臨むことが重要です。システム開発会社も課題解決に最後まで伴走する意気込みが必要であり、その意気込みを空回りさせないためには、クライアントの意識改革まで踏み込む姿勢が求められます。

この記事を書いた人について

谷尾 薫

オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。

最新記事一覧

• 経営者向け2026年6月9日技術選定は経営判断である――ITプロジェクトの勝敗を左右する「設計思想」の選び方
• 経営者向け2026年6月9日ITプロジェクトに正解はない。しかし間違いはある ――失敗へ向かう「下りのエスカレーター」と判断の本質
• 経営者向け2026年6月1日IT投資の効果は誰が決めるのか―――ノジマ流経営に見る『現場に任せる判断』
• システム設計2026年5月26日「日本のシステムは恥ずかしい」のか？──食料品減税を巡る本当の論点