見積もりを取る前に、社内システムの予算を自分で概算する方法

社内システムの予算は「画面数」や「機能数」では決まりません。決めるのは5つの変数——業務フローの複雑さ（例外込み）、連携レベル、データの状態、権限の複雑さ、運用コミットメント——です。見積もりを取る前にこの5変数を自社で概算しておけば、3〜5倍の開きがある金額に困惑する代わりに、すべての見積もりを同じ土俵で比較できます。

TL;DR (Executive Summary)

  • 課題： 社内システムの見積もりが3〜5倍の開きで返ってきて比較基準がない。原因は要件を「画面数」で記述し、コストを生む変数で記述していないこと。
  • 解決策： コスト5変数フレームワーク＋スコープ削減マトリクス＋見積依頼（RFQ）前チェックリスト。
  • 結果： 見積もりの同条件比較が可能になり、項目漏れの「安い見積もり」を見抜け、品質が暗黙に削られる代わりにスコープを意図的に削れる。

私はデリバリーマネージャーとして14年間、見積もりを作る側と査定する側の両方に座ってきました。あまり率直に語られないことですが、見積もりの差の大半は、ベンダーの高い・安いではなく、各社が同じ曖昧な要件から別々の製品を値付けしていることから生まれます。

「ソフトウェア予算」をデリバリーの現場から定義し直す

一般的な定義：予算＝構築契約の金額。現場からの正しい定義：

ソフトウェア予算＝システムのライフサイクル全体の総保有コスト（TCO）——構築、運用、業務変化に伴う改修、そして入れ替え時の撤退コストまで含む。

私が直接デリバリーしてきたプロジェクトでは、最初の3〜4年の運用＋改修コストは初期構築コストとほぼ同額になります。構築は安いが改修が高くつく（あるいはシステムを理解する唯一の人物への依存に陥る）見積もりは、高い見積もりです。

コスト5変数フレームワーク

変数 自答すべき質問 予算への影響
① 業務フロー＋例外 フローはいくつ？各フローに「たまに起きる」例外がいくつある？ 最大——コストは例外に潜む
② 連携レベル 稼働中のどのシステムと通信する？APIはある？ API のないレガシー連携は主機能より高くつくことも
③ データの状態 旧データはどこに（Excel・旧システム）？きれいか？移行は必要か？ 汚れたデータの移行は最も忘れられる項目
④ 権限 ロールはいくつ？多段承認は？一部の人しか見られないデータは？ 承認1段ごとにロジックとテストが1層増える
⑤ 運用コミットメント 1日止まったら何が起きる？夜8時の障害は誰が対応？ インフラ・監視・SLAを決める——安い見積もりが無視する部分

使い方：ベンダーに会う前に、この5つの質問に書面で答えてください。その文書が見積依頼書の別紙となり、すべての見積もりを同一スコープに正規化させる物差しになります。

なぜ「画面数」は間違った物差しなのか

同じ10画面のシステムでも、コストは5倍違い得ます。片方はデータの入力・閲覧だけのCRUD、もう片方は3段階承認フロー、在庫のリアルタイム同期、5年分のExcelデータ移行を含む——という具合です。画面数で値付けするベンダー、あるいは業務例外を聞き返さずに画面数ベースの記述を受け入れるベンダーは、その時点でプロセス成熟度について多くを物語っています。

安い見積もりの3つの罠

  1. ハッピーパスだけの値付け — 順方向のフローだけを計算し、業務例外（「一部返品の場合は？」）はすべて後日の追加請求に。例外は実工数の30〜50%を占めるのが普通です。
  2. データ項目の空白 — 「旧データを取り込む」は簡単に聞こえますが、5年分の非標準Excelはひとつのサブプロジェクトです。データ移行の行がない見積もりは、最終月にセットされた時限爆弾です。
  3. 納品後の記載なし — 保証、障害時の応答時間、小規模改修の費用について沈黙。安い構築価格と引き換えに、ベンダーは運用フェーズでの独占的な値付けポジションを手に入れます。

スコープ削減マトリクス — 概算が予算を超えたとき

概算が予算を超えると、多くの企業は間違った削り方をします。機能数を維持したまま価格を圧縮する——結果、品質が暗黙に削られます（テスト省略、例外処理省略）。正しい削り方はマトリクスに従います。

コア業務 周辺業務
高頻度 例外まで含めて深く作る 最小限版を作る
低頻度 半自動化（人＋ツール） 削る——システム外に置く

原則は、幅（業務の数）を削り、深さ（コア業務の完成度）を守ること。3つの業務をきちんとこなすシステムは本当の価値を生みますが、10の業務を中途半端にこなすシステムは、仕事が詰まる場所を10箇所作るだけです。削る前に、根本の問いも忘れずに：その業務にオーダーメイドのソフトウェアは本当に必要か、既製のSaaSで十分ではないか？

見積依頼前チェックリスト

よくある質問

IT人材がいない会社は、どうやって概算すればいいですか？

5変数フレームワークは、プログラミング知識なしで業務の言葉だけで答えられるように設計されています。業務の流れ、例外、データの所在を記述するだけで構いません。それを技術的な複雑さに換算するのはベンダーの仕事です。あなたの仕事は、全ベンダーが同じ十分に詳細な記述を受け取り、誰も「いちばん安い解釈」をする余地がない状態を作ることです。

予備費はどれくらい確保すべきですか？

旧データの移行や稼働中システムとの連携を含む社内システムの場合、私の経験では構築費の15〜25%が妥当な予備費です。金額より重要なのは使用ルールです。予備費は後から発見された例外にのみ充当し、途中で思いついた新機能には使わない——新機能は別途の優先順位付けプロセスを通すべきです。

数倍の開きがある見積もりを前にどれを信じるべきか分からない方、あるいは自社の要件記述が十分に堅いか確認したい方は、私の業務システム・社内Webアプリへのアプローチをご覧いただくか、課題を共有してください。専門領域と時間的余裕に合う案件であればご返信いたします。