「御社の見積もりだけ、なぜこんなに高いんですか」——そう問い合わせた電話口で、開発会社の担当者が一瞬黙り込んだ。3社に相見積もりを依頼した結果、手元にあるのは300万円、800万円、1500万円という3枚の見積書だった。同じ「在庫管理システムを作ってほしい」という依頼に対して、なぜここまで差が生まれるのか。安い方に飛びついていいのか、それとも高い方が安心なのか。判断材料がないまま、机の上で見積書を並べて腕を組む。中小企業の経営者やシステム担当者なら、一度はこの場面に立たされたことがあるはずだ。
この記事は、そんな手探りの発注担当者のために書いている。システム開発の相見積もりで迷子にならないための考え方と、公平な比較を可能にするRFP(提案依頼書)の作り方を、できるだけ具体的に解説する。専門知識がなくても構わない。必要なのは、慣れない領域に踏み込む勇気と、正しい手順だけだ。
見積もり金額がバラバラになる本当の理由
まず知っておきたいのは、見積もり金額の差は「ぼったくり」か「良心的」かの差ではないということだ。多くの場合、各社が見ている前提条件そのものが違う。同じ「在庫管理システム」という言葉から、ある会社はExcelに毛が生えた程度の簡易ツールを想像し、別の会社は複数拠点・複数倉庫を横断するリアルタイム在庫連携システムを想像する。依頼した側が「当然含まれているはず」と思っていた機能が、実は見積もりの範囲外だったというすれ違いは、業界では日常茶飯事だ。
具体的に金額差を生む要因を挙げてみる。
- 機能の範囲(スコープ)の解釈違い。バーコード読み取り、複数拠点対応、外部システム連携などが「入っている前提」か「別途相談」かで数百万円単位の差が出る
- 瑕疵担保責任(契約不適合責任)の範囲。納品後にバグが見つかった場合、どこまで無償で対応するのかが契約書に明記されているかどうか
- 保守運用費用の含み方。初期開発費だけを比較していても、月額保守費が5万円の会社と20万円の会社では5年間の総額が大きく変わる
- 開発体制の違い。大手SIerが元請けとして受けて実際の開発は協力会社に外注する多重下請け構造と、少人数チームが直接開発する体制では、コミュニケーションコストも品質管理の手間も異なる
- 要件定義にかける工数。安い見積もりほど「まず作ってみて、あとで直していく」前提になっていることがあり、逆に高い見積もりは要件定義や設計の工数を厚く積んでいることがある
つまり、300万円と1500万円という数字だけを見て一喜一憂するのは早計だ。それぞれの金額の「中身」が違うのに、見た目の数字だけで並べて比較しているから、判断がつかなくなる。この状態を抜け出す唯一の方法は、発注する側が「比較の土俵」を先に用意することだ。それがRFPである。
RFP(提案依頼書)とは何か、なぜ作ると比較が公平になるのか
RFPとはRequest For Proposalの略で、日本語では提案依頼書と呼ばれる。発注者が「こういう課題があり、こういうことを実現したい」という要求事項を文書としてまとめ、複数の開発会社に同じ条件で提示するものだ。RFPを作らずに口頭やメールで「在庫管理システムを作ってほしいんですが、見積もりもらえますか」とだけ伝えると、各社は自社の解釈で見積もりを組み立てる。その結果が、冒頭のような300万・800万・1500万のバラつきになる。
RFPを用意すれば、すべての会社が同じ前提条件、同じ要求機能、同じスケジュール感を踏まえた上で提案してくる。金額の差が「解釈の違い」ではなく「提案内容そのものの違い」として浮かび上がるようになる。ある会社は要件を満たすために独自パッケージを提案し、別の会社はゼロからのフルスクラッチ開発を提案するかもしれない。その違いが見えて初めて、金額に見合う価値があるのかどうかを判断できる土俵に立てる。
RFPを作る作業は、正直に言えば手間がかかる。日々の業務に追われながら、自社の課題を言語化し、実現したいことを整理する時間を捻出するのは簡単ではない。それでも、この一手間を惜しんで丸投げの依頼をしてしまうと、結局は後になって「思っていたのと違う」という認識のズレに苦しむことになる。RFP作成は、発注担当者が自社の業務を見つめ直し、本当に必要なものを見極めるための重要なプロセスでもある。壁を乗り越えるのは開発会社だけの仕事ではない。発注する側にも、越えるべき壁がある。
RFPに書くべき項目
では実際にRFPには何を書けばいいのか。難しく考える必要はない。以下の項目を、できる範囲で埋めていけば十分な水準のRFPになる。
現状の課題
今どんな業務をどう回していて、何に困っているのかを具体的に書く。「在庫管理が非効率」という抽象的な表現ではなく、「現在はExcelで各拠点の在庫を手入力しており、拠点間の在庫数の反映に半日から1日のタイムラグがある。そのため欠品や過剰発注が月に3〜4件発生している」というレベルまで踏み込む。数字と具体的な場面を入れることで、開発会社側も課題の深刻度と解決すべき優先順位を理解できる。
実現したいこと(要求機能)
課題に対応する形で、実現したい機能を箇条書きにする。すべてを「必須」にするのではなく、必ず実現したい「必須要件」と、できれば実現したい「希望要件」を分けて書くのがコツだ。これにより、開発会社は優先順位をつけた提案がしやすくなり、予算に応じたスコープ調整の相談もしやすくなる。
予算感
予算を隠したがる発注担当者は多いが、これはむしろ逆効果だ。予算を伏せたまま依頼すると、開発会社は「出せるだけ引き出そう」とする提案になりがちで、逆に予算とかけ離れた過剰な提案が出てきて比較にならないこともある。「500万円から800万円程度を想定している」といった幅を示すだけで、各社は身の丈に合った現実的な提案を組み立てやすくなる。
スケジュール
いつまでに稼働させたいのか、繁忙期や決算期など避けたいタイミングがあれば併せて書く。急なスケジュールを要求すると、テストや検証の工数が削られ、品質に影響することも理解しておきたい。
評価基準
提案をどんな基準で評価するかをあらかじめ決めておき、可能であればRFPにも明記する。金額の安さだけでなく、提案内容の的確さ、保守体制、担当者との相性、実績なども評価項目に含める。評価基準を先に決めておくことで、社内での比較検討時に「結局何を優先すべきだったのか」という迷いを防げる。
その他書いておきたい項目
- 現在使用しているシステムや周辺環境(既存の会計ソフトや基幹システムとの連携要否)
- 提案書の提出期限と見積もり有効期限
- 質疑応答の受付方法と期限
- 契約形態の希望(準委任契約か請負契約か)
- 保守運用の希望体制(自社で運用するのか、開発会社に月額で任せるのか)
見積もりを比較するときに見るべきポイント
RFPを配布し、各社から見積もりと提案書が返ってきたら、いよいよ比較の段階に入る。ここでも金額の数字だけを見て判断してはいけない。次の観点をひとつずつ確認していく。
前提条件は揃っているか
同じRFPを渡していても、各社の見積もりの前提が微妙にずれていることがある。「画面数は何画面を想定した見積もりか」「データ移行作業は含まれているか」「テスト工程はどこまで含まれるか」を必ず確認する。前提が違えば金額比較そのものが成立しない。
保守運用体制と費用
初期開発費だけでなく、稼働後の月額保守費、障害発生時の対応時間、システム改修が必要になった場合の追加費用の単価まで確認する。5年間運用することを想定して総額を試算すると、初期費用の安さが逆転することも珍しくない。
追加費用が発生する条件
「仕様変更が発生した場合は別途見積もり」という一文は、ほぼすべての見積書に入っている。問題はその発生条件が曖昧なままになっていることだ。どのレベルの変更までが無償対応の範囲で、どこからが有償になるのか、事前にすり合わせておく必要がある。ここを曖昧にしたまま契約すると、開発途中で「これは追加費用です」という請求が積み重なり、当初の見積もりの倍近い金額になったという相談も少なくない。
担当者の提案の質
金額と同じくらい重視すべきなのが、提案書や打ち合わせでのやり取りの質だ。RFPに書いた課題をきちんと理解した上で、なぜその機能や技術を提案するのかを論理立てて説明できているか。逆にRFPの内容をなぞっているだけで、自社の状況に踏み込んだ提案になっていない会社は要注意だ。長く付き合っていくパートナーとして、こちらの業務を理解しようとする姿勢があるかどうかを見極めたい。
実績と体制
似た業種・規模の開発実績があるか、担当する開発チームの体制(何人がどんな役割で関わるのか)、途中で担当者が変わるリスクがどの程度あるかも確認しておく。特に中小企業の場合、担当者との相性やコミュニケーションのしやすさは、プロジェクトの成否を大きく左右する要素になる。
よくある失敗パターン
相見積もりとRFPの重要性を理解していても、実際の発注では失敗が起きる。よくあるパターンを2つ紹介する。
ひとつは、安さだけで選んで後悔するパターンだ。3社の中でもっとも安い300万円の会社に決めたものの、蓋を開けてみると要件定義の工数がほとんど積まれておらず、打ち合わせのたびに「それは聞いていない」「別途費用がかかる」という応酬が続いた。最終的な総額は当初の見積もりの1.8倍まで膨らみ、納期も3ヶ月遅れた。安い見積もりの裏には、たいてい理由がある。その理由を確認せずに金額だけで決めてしまうと、後になって高くつくことが多い。
もうひとつは、逆に高い会社に丸投げして、身の丈に合わない機能を作られてしまうパターンだ。1500万円の見積もりを出した大手SIerに「専門家だから任せておけば安心」と発注したところ、社員数20名の会社には過剰な、大企業向けの複雑な承認フローや多言語対応機能まで盛り込まれたシステムが納品された。使いこなせる社員がおらず、結局は簡易的な機能だけを使う「宝の持ち腐れ」状態になってしまった。高額な提案が必ずしも自社に最適とは限らない。自社の規模と業務の実態に合っているかを、発注側が主体的に判断する必要がある。
どちらの失敗にも共通するのは、発注側がRFPを作らず、比較の軸を持たないまま「お任せ」で決めてしまったことだ。開発会社に頼るのは悪いことではない。しかし最終的な判断の責任は、発注する自分たちにある。その自覚を持って臨むかどうかが、プロジェクトの成否を分ける。
まとめ
3社から見積もりを取ったら300万・800万・1500万とバラバラで途方に暮れる。そんな場面に立たされたとき、答えは「もっと多くの会社に聞く」ことでも「一番安い会社を選ぶ」ことでもない。答えは、比較の土俵を自分たちの手で用意することにある。RFPを作るという一手間は、面倒に感じるかもしれない。しかしその一手間こそが、自社の課題を見つめ直し、本当に必要なものを見極め、公平な比較を可能にする唯一の道だ。
慣れない発注業務に不安を感じるのは当然のことだ。しかし、その不安と向き合い、一つひとつの項目を埋めていく作業そのものが、良いシステムを作るための第一歩になる。壁を越えるのは開発会社だけではない。RFPを書き、見積もりを比較し、パートナーを選び抜くあなた自身もまた、壁を越えて働く一人だ。この記事が、その一歩を踏み出す助けになれば幸いだ。