顧客管理システムの見積もりは、なぜ最初に確定しないのか

2026年8月31日

「見積もり、上がっています」

CRMやSFA（営業支援システム）の導入をお手伝いしていると、この報告を事業者さんと一緒に受ける場面があります。

そのとき、口には出さないけれど頭をよぎるものがあると思います。この会社、大丈夫だろうか。乗せられているんじゃないだろうか。

言いにくいことだと思うので、こちらから書きます。ほとんどの場合、それは特定の会社の問題ではありません。今日はその構造の話です。

金額が動く場所は、決まっています

先に、いちばん知りたいところから書きます。

段階	何をするか	期間の目安	金額
① 提案・RFPの段階	超概算の見積もりが出る	—	幅がいちばん大きい
② 要件定義	業務を聞き取り、要件を確定させる	規模により2か月〜半年	かかった分で精算
③ 正式見積もり	開発工程の金額が確定する	—	ここで動きます
④ 開発	確定した金額・内容で作る	—	原則、動きません

動くのは、③の一か所です。

「途中でずるずる上がっていく」というイメージを持たれることがありますが、実際はそうではありません。上がるとしたら、要件定義が終わった直後の一回。そこを過ぎれば、原則として金額は動きません。

契約の形（準委任と請負）については別の記事に書いたので、ここでは繰り返しません。

会計ソフトなら、先に金額が出せます

では、なぜ①の段階で金額を確定できないのか。

会計と顧客管理を並べてみると、違いがはっきりします。

会計は、勘定科目の持ち方に細かい違いはあっても、目的もやるべきことも各社で大きくは変わりません。締めて、出す。ゴールが同じです。だから、深く聞き込まなくても大枠が読めます。

顧客管理や営業支援は、そうはいきません。

「受注を増やしたい」「顧客満足度を上げたい」——目的の言葉は、どの会社も同じです。けれども、そのために何を指標にして、どう動くのかは、会社ごとにまったく違います。それはもう、その会社の戦略そのものだからです。

同じ「CRMを入れたい」というご依頼でも、中身は一社ずつ別物になる。顧客管理は、聞かないと分からない領域なのです。

競争領域と、非競争領域

この違いには、業界で使われている言い方があります。競争領域と非競争領域（協調領域とも言います）です。

会計、給与計算、経費精算、資産管理。このあたりは、どの会社も同じ法律や制度のもとでやっています。会社法があり、税法があり、インボイスがあり、電子帳簿保存法がある。やるべきことの大枠が、会社の外側で決まっている。 だから標準に合わせやすいし、合わせたところで競争力は落ちません。ここが非競争領域です。

顧客管理や営業のやり方には、そういう外側の決まりがありません。どこにも書かれていないので、その会社が自分で決めるしかない。 そして、決め方が他社と違うことが、そのまま強みになります。ここが競争領域です。

見積もりの話に戻すと、こうなります。

非競争領域は、聞く前から答えの大枠が外にある。 だから読めます。

競争領域は、聞かないと情報そのものが存在しない。 その会社の中にしかないので、聞き終わるまで金額が出せません。

「うちの業務は少し特殊なので」とおっしゃる方がよくいらっしゃいます。けれども顧客管理に関しては、特殊でない会社のほうが珍しいのだと思います。

会計のシステムなら安全、という話ではありません

ひとつ、誤解のないように書いておきます。

会計や基幹システムの入れ替えでも、金額は膨らみます。世の中で大きな問題になったプロジェクトは、むしろ基幹システムのほうが多いくらいです。

ただ、膨らむ理由が違います。あちらは規模の大きさや、長年動いてきた既存システムの複雑さ、現場で積み上がってきた例外の運用。「何を作るのか分からない」から膨らむわけではないのです。

要件を決める作業の重さと、プロジェクトが荒れるかどうかは、別の話です。

では、なぜ先に全部聞かないのか

聞けば分かります。ただ、それには2か月から半年かかります。

提案の前にそれをやるということは、開発会社が半年ぶんの作業を無償で引き受けるということです。受注できるかどうかも分からない段階で、です。どの会社にも、それはできません。

だから「概算を出す → 要件定義をする → 正式な見積もりを出す」という順番が主流になりました。特定の会社の都合ではなく、業界全体がそうなっています。

相見積もりを取り直しても、この構造からは出られません。

金額は下げられます。ただ、概算より下がるわけではありません

正直なところを書きます。

私たちのようなコンサルタントが間に入ると、金額そのものは下がります。 要らない要件を落とす、過剰な作りに気づく、各社の提案の中身を揃えて比べられる形にする。そういうことをしますので、何もしないより確実に安くなりますし、概算と正式見積もりの乖離も小さくできます。 これは自信を持って言えます。

ただ、それとは別の話として——最初の概算より、最終的な金額が下がったケースは、ほとんどありません。

下げた結果が、それでも概算より上。そういうことです。前提が根本から崩れて、実現の方法ごと変わってしまうような、ごく稀な場合を除いて。

私が見てきた範囲では、9割方のプロジェクトで概算より上がります。厳密に数えた数字ではありませんが、実感としてはそのくらいです。

後から出てくるものには、型があります

では、何が後から出てくるのか。並べてみると、いくつかの型に分かれます。

当たり前だと思っていたことが、自社の常識だった。 「パッケージ通りでいいから合わせるよ」と決めていたはずが、動かしてみると「これ、こうなっていないの？」となる。どこの会社でもこうしているはずだ、と思っていたことが、実は業界の慣習だったり、その会社だけのやり方だったりします。ご本人たちに、特殊なことをしている感覚はありません。 けれども、いざ変えるとなると「そこだけは動かせない」。細かいところほど、そうなります。

決済の連携先が入っていない。 カード決済で、いま使っている会社がカバーされていない。連携できるはずだったものが、できない。

「連携」の指すものが、お互いに違っていた。 同じ言葉を使って話していたのに、思い浮かべていた中身がずれていた。

現行のツールを、かなり細かく作り込んでいた。 そして、これがいちばん多いです。事業者さんご自身が思っているよりずっと細かく、いまのツールを設定して使っていらっしゃいます。長く使うほど、そうなります。誰かが必要があって足した設定が、そのまま引き継がれて動いている。だから最初の聞き取りでも出てこないのです。

「ツールに合わせればいい」が通らない場面があります

最近よく聞くのが Fit to Standard という言葉です。業務のやり方をツールの標準に合わせる、という考え方ですね。特にCRMやSFAでは「うちの業務はツールのほうに柔軟に合わせます」「だからカスタマイズは要らないのでは」という話になりがちです。

考え方としては、正しいと思います。さきほどの言い方でいえば、非競争領域では、まさにそのとおりです。 ただ、通らない場面があります。

たとえば会員管理のように、社内の人ではなくお客さま自身が操作するもの。

使う方のITリテラシーが高いとは限りません。今までとやり方が変わって、使いづらくなる。会費をいただいている仕組みであれば、それがそのまま解約の理由になります。

業務を変えるコストを払うのは、社内の人とは限らない。 ここが判断の分かれ目です。この話はまだ書きたいことがあるので、別の記事にします。

引き返せなくなる地点があります

もうひとつ、知っておいていただきたいことがあります。

要件定義が終わった時点で、規模にもよりますが、すでに数百万円から数千万円を投じていることが多いのです。

そこで金額が上がっても、「では他社に」とは、もう言えません。

後戻りできない状態で増額の話を受け取る。だからこそ、あの疑いがいちばん強く出るのだと思います。裏切られたように感じるのは、無理もないことです。

その地点に来る前に、上がる前提で予算を組んでおく。 私が最初にお伝えしているのは、そこです。当初の見積もりの1.2〜1.3倍。あくまで目安ですが、枠さえ取ってあれば「想定内」として受け止められます。

削って帳尻を合わせると、乗り換えた意味がなくなります

費用が上がるのを恐れて、みなさん最後に削って合わせようとされます。

気持ちはよく分かります。ただ、削りすぎると前より手間が増えることがあります。そうなると、何のために乗り換えたのか分からなくなってしまう。

ここは本当にジレンマで、私たちの腕の見せ所でもあります。正直に書くと、終わったあとに「もう少し上手くやれたかもしれない」と思うことは、いまでもあります。

値切りすぎないこと

最後に、費用の話でどうしても書いておきたいことがあります。

開発が始まる前に、値切りすぎないでください。

「これ、赤字じゃないか」と思わせた状態でスタートすると、その関係が半年、1年と続いていきます。作る人たちの気持ちが乗らないまま、長い時間を一緒に過ごすことになる。できれば、気持ちよく終わらせたいのです。

我慢してくださいという話ではありません。納得のいかないところは、ちゃんと言ってください。私はいつも「話し合いの場を設けましょう」「言いたいことは言いましょう」とご案内しています。

そのうえで、開発側にも事情があります。人数を絞って調査せざるを得ないこともありますし、全員を優秀なメンバーで揃えるのも、いまの人手不足では簡単ではありません。「言いましたよね」の行き違いは、どうしても起きます。 そこを責め合っても、プロジェクトは前に進みません。

「1、2、3、はい」で綺麗に片づくものではない。そういうものだと思って進めるのが、いまの私の中での正解です。

ポイント

• 金額が動くのは、要件定義が終わったあとの正式見積もりの一か所。 そこを過ぎれば原則として動きません
• 会計は各社で大きく変わらない。顧客管理は各社で違う。 何を指標にするかは、その会社の戦略そのものだからです
• 非競争領域は、答えの大枠が会社の外にある。競争領域は、聞かないと情報そのものが存在しない。 顧客管理は後者です
• 会計や基幹システムが安全という話ではありません。 あちらが膨らむ理由は規模と既存システムの複雑さで、「何を作るのか分からない」からではありません
• 提案の前に全部聞くと、2か月から半年。 それを無償では持てないので、どこに頼んでも同じ構造になります
• 間に入れば金額そのものは下げられます。ただ、下げた結果でも概算より上になるのが普通です。 見てきた範囲では9割方、概算より上がります
• 後から出てくるのは、自社の常識・決済の連携先・「連携」の解釈・現行の作り込み。 最後のひとつがいちばん多いです
• Fit to Standard が通らない場面があります。 お客さま自身が操作するものは、変更のコストを払うのが社内の人ではありません
• 要件定義が終わると、引き返せません。 その前に、当初見積もりの1.2〜1.3倍で予算を組んでおいてください（あくまで目安です）
• 削りすぎると、乗り換えた意味がなくなります
• 値切りすぎないこと。 ただし、納得がいかないところは話し合いの場を作って伝えてください

ツールの選び方やベンダーさんの比べ方については、CRM・顧客管理ツールを選びたいとベンダーから提案が来たが、比較の仕方が分からないのページにも書いています。