見積超過を避けたい企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、追加要件は悪ではなく、管理方法が重要であることを重視して進め方を整理します。
この記事では、基幹システム開発で見積が膨らむ構造的な理由と、膨張を防ぐ具体策を整理します。過去に見積超過を経験した企業と、これから開発を発注する企業の担当者・経営者に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
要件追加は「悪」ではなく、管理方法が問題
開発中に追加要件が出ること自体は正常なプロセスです。現行システムの隠れた仕様が発掘される、テスト中に新たな業務ルールが判明する、利用部門から改善要望が上がる。これらは避けられない事象であり、追加を一切許さないのは非現実的です。問題は、追加要件を管理する仕組みがないまま開発が進むことです。何が追加で、いくらかかり、いつ対応するかを判断するプロセスがあれば、膨張はコントロールできます。
膨張の最大の原因は「着手前の調査不足」
費用膨張の根本原因は、着手前の現行調査が不十分で、開発中に想定外の仕様が次々と見つかることです。現行のシステム・業務・データの実態を開発前に十分に把握していれば、見積に含めるべき範囲が明確になり、後からの発掘が減ります。現行調査に費用をかけることは、見積精度を高めるための最も確実な投資です。開発費の5〜10%を調査に充てても、後の膨張を防げれば何倍にもなって返ってきます。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある膨張パターンの第一は、「ついでにこれも」の積み重ねです。一つひとつは小さな変更でも、積み重なると開発スケジュールと費用に大きく影響します。変更依頼を口頭ではなく書面で受け付け、費用と期間への影響を見積もったうえで採否を判断するプロセスを設けることが、この膨張を止める唯一の方法です。
第二は、帳票と例外処理の過小評価です。帳票の本数と例外処理の複雑さは費用に直結します。見積時にこの二つを具体的に数えていないと、開発中の発掘で費用が跳ね上がります。
第三は、テストと移行の工数を甘く見ることです。開発（作る）の工数だけで見積を組み、テスト（確かめる）と移行（移す）の工数を別物として見込んでいないと、終盤に費用が不足します。テストと移行は開発と同等以上の工数がかかる、という前提で計画してください。
自社で確認できるチェックポイント
見積膨張を防ぐために、契約前に次の点を確認してください。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
膨張防止ならではのチェックポイント
基本のチェックリストに加えて、見積の内訳に現行調査・要件定義・帳票開発・テスト・移行・教育がそれぞれ計上されているか、帳票の本数と例外処理の数が前提条件に明記されているか、変更管理のプロセスが契約に含まれているか、追加費用が発生する条件が明記されているか、そして自社側の作業（意思決定・データ整備・テスト参加）が何を期待されているかを確認してください。これらが曖昧な契約は、膨張を招く構造的な穴を持っています。
変更管理のプロセスは、追加要望を記録し、費用と期間への影響を評価し、優先順位を付けて採否を判断する、という三段階で構成します。このプロセスを持つだけで、「いつの間にか範囲が広がっていた」という事態を構造的に防げます。追加を断るためではなく、追加の影響を可視化するための仕組みです。
膨張を防ぐもう一つの有効な手段は、見積の「バッファ」の扱いを明確にしておくことです。予備費を全体の10〜15%程度見込んでおき、追加要件が発生した場合はこの予備費から充当するルールにすれば、追加のたびに稟議が必要になる事態を避けられます。ただし、予備費は「使い切ってよい枠」ではなく「使わないのが理想」の保険です。この位置づけを関係者で共有しておくことが大切です。
開発中に追加要件が出た際は、「それをやるとスケジュールにどう影響するか」もセットで確認してください。費用は追加予備費で吸収できても、期間が延びて保守切れに間に合わなくなるという事態のほうが深刻なことがあります。費用と期間の両面で影響を評価する習慣を持ちましょう。
延命・部分改善で対応できるケース
膨張リスクを最も効果的に下げる方法は、投資を段階に分けることです。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
第一段階で現行調査と要件定義を契約し、その結果をもとに開発費を精度高く見積もる。この二段階契約は、膨張を防ぐ最も構造的な対策です。第一段階の費用は数十万〜数百万円ですが、この投資で数千万円の本開発の見積精度が大きく上がります。
また、追加要件を「今回の範囲」と「次のフェーズ」に仕分けるルールがあると、膨張を防ぎつつ要望を失わずに済みます。追加をすべて断るのではなく、タイミングを分ける。この考え方が、発注側と開発側の関係を健全に保ちます。
膨張が起きやすい費目は、帳票（追加要望で本数が増える）、例外処理（開発中に発覚する）、テスト（想定より時間がかかる）、データ移行（データの汚れが想定以上）の四つです。この四費目の見積を契約前に特に厳しく確認することが、膨張防止の具体策です。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
膨張リスクの力点は構築方式によって異なります。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージは開発費のコントロールが比較的容易ですが、カスタマイズの追加で膨張するリスクがあります。カスタマイズの上限額を先に決めておくのが対策です。
周辺開発で補うケース
周辺開発では、各段階の範囲を明確にしておかないと、段階のあいだで要件が漏れ、後の段階にしわ寄せが来ます。段階ごとの範囲定義が膨張防止の鍵です。
スクラッチ再構築が向くケース
スクラッチは最も膨張しやすい方式です。変更管理のプロセスを契約に含め、追加要望の影響を都度評価する仕組みを最初から設計してください。
マクティズムの見解
マクティズムの見解として、要件追加で基幹システム開発費が膨らむ理由では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、追加要件は悪ではなく、管理方法が重要であることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
見積膨張の相談では、私たちは自社の見積がなぜその金額になるのかを徹底的に開示するようにしています。内訳と前提条件が透明であれば、追加が発生したときに「何が増えて、いくらかかるか」を双方が納得して判断できるからです。ブラックボックスな見積から膨張が生まれます。透明性こそが最良の膨張防止策だと確信しています。
相談前に準備しておく情報
膨張防止の相談では、過去に見積超過が起きた経験とその原因、今回の見積の内訳と前提条件、変更管理の仕組みの有無が分かると、初回から具体的な対策を提案できます。見積超過の経験がない場合でも、見積の読み解きから支援します。
実務では、契約前に見積の前提条件と変更管理のプロセスを明確にし、開発前診断で膨張しやすいポイント（帳票数・例外処理数・データの汚れ）を事前に把握する流れをおすすめしています。
膨張を防いだプロジェクトは、予算内で完走した達成感と、計画どおりに進められた自信を組織に残します。この経験は次のプロジェクトで生きる最も貴重な資産です。
費用膨張は「起きるもの」ではなく「防げるもの」です。調査に投資し、変更を管理し、前提を共有する。この三つを守れば、見積は計画を守る信頼できる数字になります。
膨張防止は、現行調査への投資、見積前提の明確化、変更管理プロセスの設計、四費目（帳票・例外・テスト・移行）の重点確認、の順です。事前の準備が膨張を防ぐすべてです。
膨張の記録は、次のプロジェクトの見積精度を上げるための最良の教材です。何が追加になり、なぜ当初の見積に含まれていなかったのかを振り返ると、次回は最初から含めるべき費目が見えてきます。膨張の経験を無駄にしないでください。
見積のコントロールに成功したプロジェクトは、関係者の信頼を高め、次の投資への支持を得やすくなります。予算内で完走すること自体が、組織へのリターンの一つです。
予算を守ることは、信頼を守ることでもあります。見積精度を上げる努力は、お客様との関係の質を上げる努力そのものです。私たちはその努力を惜しみません。
膨張を防ぐ最良の投資は、着手前の調査です。調査に100万円かけて、本開発で500万円の膨張を防ぐ。これ以上割のよい投資はなかなかありません。
その調査への投資を、ぜひ最初の一歩にしてください。
見積を守る力は、プロジェクトの信頼を守る力そのものです。その力を、調査と管理の両輪で築いてください。
調査と管理という二つの武器があれば、膨張は必ずコントロールできます。
調査への小さな投資が、大きなプロジェクトの安定を支えます。まずはそこからです。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。過去の見積超過の経験があればそこから、なければ今回の見積の読み解きから始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。二段階契約は膨張を防ぐ最も効果的な構造です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。見積の前提条件と変更管理のプロセスの確認も含めて、一緒に整理します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。見積のレビューだけのご依頼にも対応しています。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。見積への不安をお聞かせください。内訳の読み解き方からお伝えします。
