その見積もり、本当に発注側のためですか？-ベンダーの行動原理を読み解く3つの視点-

株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。

御社にこんな状況はありませんか？

• SaaSを導入したはずなのに、気づけば毎月のように追加費用の見積もりが上がってくる
• SIerの見積もりが想定を超えて膨らんだが、なぜその金額なのか腹落ちしないまま稟議を通してしまった
• 支援ファームの提案書は綺麗にまとまっているけれど、「これって本当にうちのためなのか？」 とモヤモヤしている
• 担当者から「ベンダーに振り回されている」という本音がポロっと漏れてくる

一つでも思い当たる節があるなら、今日の話はきっと刺さります。

これ、担当者の能力不足の問題ではないんです。

ベンダーの行動原理と、発注側の期待の間には、構造的なギャップが存在している。

そのギャップを知らないまま発注を続けても、プロジェクトが予算超過したり、現場が疲弊したりするのは、構造上の必然なんです。

実は、ベンダーの利益構造そのものについては以前、こちらの記事でも書きました。

その提案、本当にあなたの会社のためですか？ ― ベンダーに振り回されないために知っておくべきこと

今回は、そこからさらに一歩踏み込みます。

ベンダーの”内側”――ロールごとのインセンティブ、人月単価、稼働率、本社上納金、契約形態、不確実性のコーンといった、“数字と仕組み”のレイヤーまで降りて、見えてくる世界についてお話しします。

正直に言うと、私自身が支援ファーム業界にいた頃に「うわー、これは外に言いにくい話だな…」と思っていた内容も、かなり含まれます。

でも、発注側がこの”内側の数字”を知らないままベンダーと付き合っていると、ずっと不利な取引を続けることになる。

だから、今回は腹を括ってお話しします。

この記事の要点（3行サマリ）

• ベンダーのビジネスモデルはSaaS（ライセンス）型と人月型の2種類で、それぞれインセンティブ構造が根本的に異なる
• SaaS営業はビジョンセリングで大型契約に誘導される構造、人月型は複雑化で工数を膨らませる構造――提案内容はこの収益構造の論理に沿って組み立てられている
• 準委任契約はプロジェクトリスクを発注側が全額負担する仕組み。ハイブリッド契約でリスクを按分し、主導権を取り戻すのが健全

目次

1. 前提：ベンダーのビジネスは、大きく2種類ある
2. 視点①：SaaSベンダーの”ビジョンセリング”という行動原理
3. 視点②：SIer・支援ファームの”人月ビジネス”の内側
4. 視点③：契約形態（準委任／請負）が決める”リスク分担”
5. 3つの視点を踏まえた、発注側のスタンス
6. 担当者は”翻訳者”として孤独になる――だから仲間が要る
7. まとめ・おわりに
8. よくある質問（FAQ）

1. 前提：ベンダーのビジネスは、大きく2種類ある

まず押さえておきたいのは、ベンダーのビジネスモデルは大きく2つに分かれるということです。

• SaaS企業（Salesforce、ServiceNow、SAP、HubSpot、kintone等）＝ライセンスをサブスクリプションで売るビジネス
• 支援ファーム・SIer・SES＝人月（ひと月あたりの人件費）でサービスを売るビジネス

前回記事では「支援ファーム／SIer／プラットフォーマー」という3分類でお話ししました。

今回は収益構造という切り口で大きく2つに束ねて、それぞれの”内側”に切り込んでいきます。

SaaS型 vs 人月型の構造比較

なぜこの分け方が重要か。

それぞれの行動原理が、この2つで根本的に違うからです。

サブスクで売るSaaS企業は「契約してもらうこと」がゴール。

人月で売るSIer・支援ファームは「人を入れる／関わり続けること」がゴール。

表に出てくる提案資料も、スケジュール感も、値引きの仕方も、全部この”収益構造”の論理に沿って組み立てられているんです。

これを知らずに「いい提案ですね」と受け取るのは、ルールを知らずに試合に出るようなものです。

それぞれの内側を、順番に見ていきましょう。

2. 視点①：SaaSベンダーの”ビジョンセリング”という行動原理

The Modelの4ロールはどんなKPIで動くのか？

SaaS企業の営業プロセスは、ほとんどの場合「The Model」と呼ばれる分業体制で動いています。The Modelとは、マーケティング→インサイドセールス→フィールドセールス→カスタマーサクセスの4ロールで分業し、各段階の指標を最大化していく営業組織モデルのことです。

• マーケティング：広告・CM・ウェブで認知を広げる
• IS（インサイドセールス）：電話・メールでアポイントを取る
• FS（フィールドセールス）：訪問・商談・受注する
• CS（カスタマーサクセス）：契約後の利用定着・更新・アップセルを担う

よくあるフレームです。

ここで重要なのは、各ロールのインセンティブが全部違うということなんです。

たとえばISの評価指標は、多くの場合「アポイント獲得数」です。

もちろん各社でチューニングはしていて、受注に繋がったアポの件数や金額が指標に入っている企業もあります。

ただ、素直にアポ数だけで評価されているケースも少なくありません。

すると何が起きるか。

アポイントを取ること自体がゴールになるわけです。

俗に言う「クソアポ」を量産しがちになる。

電話口で「なんか雰囲気悪いな、話を聞いてもらえてないな」と感じた経験、ありませんか？

それ、担当者の性格が悪いわけではないんです。

「アポを取ってナンボ」という評価指標が、そう動かしているだけ。

なぜSaaS営業は大型契約に誘導してくるのか？

次にFS（フィールドセールス）。FSの評価指標は、ほぼ「受注金額」です。

受注”数”ではなく”金額”なんです。

なぜなら、同じ1件の受注でも、月10万円のプランと月100万円のプランでは会社への貢献度がまるで違うから。

ここに「ビジョンセリング」の力学が働きます。ビジョンセリングとは、将来の業務像や事業成果を提示することで大型契約を獲得する営業手法のことです。「御社の未来はこうなりますよ」「このシステムを導入すれば売上が2倍になりますよ」と、夢を見せながら大きな契約をまとめて取っていくスタイルです。

でも、考えてみてください。

発注側からすると、一気に全社展開するのは大きなリスクなんです。

使ったことのないSaaSを、いきなり1,000人規模で展開しますか？

当然、怖いですよね。

本来は、小さくスモールスタートして、現場で回してみて、良さそうならスケールアップする――これが一番安全な進め方のはずです。

ところがビジョンセリングの力学が働くと、「今決めた方がお得です」「パイロット導入より全社導入の方が単価も下がります」 と、大型受注の方向に誘導される。

もちろん、いい営業担当者は発注側の事情を汲み取って、スモールスタートの提案に切り替えてくれます。

でも構造上、FSのインセンティブは”大型受注”に紐づいているので、放っておくと常に大きく売り込みたくなる。

発注側は”真逆のベクトル”と戦っていることを、まず自覚しなければいけません。

図1：The Modelの4ロールとそれぞれのKPI／インセンティブ構造

ハワイ旅行の話――SaaS営業のインセンティブが見えた瞬間

営業個人の受注は、報奨旅行や昇進に直結している――それを痛感したエピソードがあります。

これは、私が以前、事業会社で責任者をしていた頃の話です。

あるSaaSベンダーの営業さんが、ある日ニコニコしながら訪問してきて、こう言ったんです。

「祖川さん、本当にありがとうございます！」

私、「ん？ 何がですか？」と。

「お陰さまでハワイ行ってきました。」

は？

「え、なんでハワイ？」

「いや、毎年一定以上の受注を上げた営業は、ハワイ旅行のインセンティブがあるんです。 祖川さんのところに入れていただいた分が、私をハワイに連れて行ってくれました！」

いやいや、と。

「あなたをハワイに行かせるために、うちはライセンス買ってるわけじゃないですよ」と嫌味は言いました。言いましたとも。

でも、これが**SaaSベンダーの行動原理の”裏側”**なんです。

営業個人にとって、受注はインセンティブ＝ハワイ旅行・報奨金・昇進に直結している。

これはもう会社の仕組みとして組み込まれています。

だから、その営業さん個人が悪いわけではない。

組織としてそう動くように設計されているんです。

それを発注側が理解していないと、「御社のためです」という言葉を100%信じて、フルパッケージを買ってしまう。

SaaS営業の予算達成率はどのくらいか？

さらに言うと、SaaS企業の営業の約半数は予算未達だと言われています。

The Bridge Groupの2024年SaaS AE Metrics Reportによると、2024年にAE（アカウントエグゼクティブ）が予算を達成した割合は51%――裏を返すと、約半数のAEが予算未達ということです。2022年は66%が達成していたので、ここ数年で達成率は明確に下がっています。さらに別の調査では、米国のクラウド営業の達成率中央値は40%台前半まで低下しているという報告もあります（Bridge Group 2024 SaaS AE Metrics & Compensation Benchmark Report）。

つまり、達成者が全体の売上を引っ張り、未達層が常に追い込まれているという構造です。

未達のFSはどう動くか。「とにかく取らなければクビになる」 という圧力の中で営業することになります（特に外資FS）。

そうすると、発注側の状況を細かく見るより、今あるパイプラインのどこから一発当てるかに意識が向く。小さく提案している暇はない。大きく提案して、決めて、予算を達成する。構造上、そう動かざるを得ないんです。

ここまでの話で、SaaSベンダーと付き合う時に発注側が意識すべきことは明確です。

提案を100%信じて受け取らない。

話半分に聞いて、「この人はどのロールで、何のインセンティブで動いているのか」 を常に頭に置きながら商談する。

これだけで、受け取り方がまったく変わります。

3. 視点②：SIer・支援ファームの”人月ビジネス”の内側

なぜSIerは複雑なシステムを提案するのか？

人月ビジネスの本質は、「人を何時間、何ヶ月入れるか」でお金が決まるということ。人月ビジネスとは、投入する人数×月数×単価で対価が決まるサービス提供モデルを指します。

1人を1ヶ月入れて300万円、3人を3ヶ月入れて2,700万円、という計算の世界です。

すると何が起きるか。

「複雑に作るほど工数がかかり、儲かる」 という力学が、構造的に働きます。

発注側からすれば、システムはシンプルであってほしい。

複雑なUI、誰も望んでいないはずです。

シンプルイズベスト。

ところがSIerから提案が来ると、「この機能も必要です」「この自動化も組みましょう」「ここはこう設計しないと拡張性が…」と、作り込む方向に誘導される。

なぜか。

工数を膨らませる方が、受注金額が大きくなるからです。

これも、担当者個人の性格が悪いわけではありません。

ビジネス構造上、そう動くようになっているだけ。

支援ファームの役職別単価と稼働率はどうなっているか？

もう少し具体的に、支援ファーム業界の”数字” をお見せします。

これは私が支援ファームに在籍していた頃に実際にいた世界の話なので、固有名詞こそ避けますが、基本構造はどのファームでも大きく変わりません。

支援ファームの役職別単価と稼働率（チャージ率）を整理すると、こうなります。稼働率（チャージ率）とは、就業時間のうちプロジェクト（＝発注側への請求）に充てる時間の比率を指します。

※筆者が支援ファームに在籍していた頃の実感値および業界相場による。ファームにより変動。

「え、1人あたり月250万〜1,000万払ってるの？」

はい、払ってるんです。5人のチームで半年のプロジェクトを回せば、軽く1億円を超える計算です。

ここからがもっと大事な話です。提案の場ではパートナーやディレクターが出てきて、ロジカルで素晴らしい提案をします。「これは凄そうだ」と発注側は思うわけです。

ところがプロジェクトが始まると、パートナーの稼働は月に1〜2日程度。残りの実務は、ジュニアメンバーが動かします。

「え、あの頼もしそうなパートナー、ほとんど来ないじゃん」となる。

でも、これも構造上の当たり前なんです。パートナーは受注を取るのが主な役割で、デリバリー（実装）の主役ではない。

図2：支援ファームの役職階層と、単価・稼働率の関係

外資系支援ファームと国内系支援ファーム、同じ単価でも何が違うのか？

さらに、外資系支援ファームと国内系支援ファームでは、同じ単価でも中身が違うという話をしておきます。

これ、ほぼ誰も教えてくれないです。

外資系支援ファームは、日本法人の売上の一部を本社（グローバル）に上納金として送る仕組みになっています。ファームによりますが、概ね2割前後と言われています。

※注記：本社上納金の比率は公開財務情報には明示されておらず、業界関係者からのヒアリングをもとにした筆者の推定値です。ファーム・年度・契約形態によって変動します。

つまり、月500万円の単価のうち、100万円ほどは本社にチャージされ、日本法人で動かせるのは400万円分。

一方、国内系ファームはこの上納金が存在しないか、ごく少額です。

にもかかわらず、単価を外資に合わせて同じ500万円で出している国内ファームもある。

これは品質や戦略の問題で合わせているケースもありますが、構造上は2割分の”余白”があるわけです。

値引き交渉の勘所が、ここに埋まっています。

発注側が「御社、国内ファームですよね？ 外資と同じ単価で出されていますが、本社への上納金分の余白があるはずですよね」と踏み込める。

これ、構造を知らないと絶対に言えない一言です。

逆に言うと、構造を知っているだけで、値引き交渉の打ち手が一つ増える。

SIerに最新技術の活用を期待していいのか？

SIerの話に戻します。

私自身がSIerで提案書を書いていた時の、赤裸々な経験談です。

お客様からRFP（提案依頼書）が出てきて、「よし、最新のSaaSや新しいアーキテクチャを組み合わせれば、お客様の課題が一発で解決できるじゃないか！」と思いついたんです。

いけるやん、これ！

WBS（作業分解構造）を組んで、人員計画を引いて、見積もりを出して、社内レビューに持ち込みました。

ところが、レビューの席で上司から一言。

「それ、やったことあるの？」

「ないです」

「プロジェクトリスク高いよね、それ。」

……跳ねられました。

「前例のない組み合わせは、プロジェクトの火種になる」 と。

もちろん、上司の言うことも一理あるんです。

新しい技術は実装リスクがある。炎上すれば赤字になる。

でも、私としては「お客様のためには、この新しい組み合わせの方が絶対に良い」と思っていた。

それが潰される。

この時、私は悟りました。

SIerの社内レビューでは、“お客様の価値”より”自社のリスクと利益”が優先されるということを。

これも担当者が悪いわけではない。

SIerというビジネスの構造上、そう判断せざるを得ないんです。

だから発注側は、「SIerに最新技術の活用を期待する」のは構造的に無理がある、ということを理解しておく必要があります。

SaaS界隈の新機能、AIのアップデート、そういう”尖った技術”を使いたいなら、それは別の座組みで考えるべきなんです。

4. 視点③：契約形態（準委任／請負）が決める”リスク分担”

準委任と請負、どちらを選ぶべきか？

ここからが、今回の記事で一番お伝えしたい話です。

SaaS導入やシステム開発のプロジェクトで、契約形態は大きく2種類あります。準委任契約とは作業そのものに対価を払う契約、請負契約とは成果物の完成に対価を払う契約です。両者の違いを整理するとこうなります。

「準委任の方が安くなりますよ」という甘い提案

結論から言うと、この提案には”プロジェクトリスクの移転”が隠れています。 プロジェクト開始時、多くの場合こういう提案が飛んできます。

【パターンA：よくあるSIer提案のシーン】

SIer「要件定義も終わりましたので、次のフェーズの見積もりをお出ししました」

発注側「ありがとうございます」

SIer「で、ご相談なんですが……次のフェーズ、準委任でやらせてもらえませんか？」

発注側「え、なんで？」

SIer「いや、昨今はSaaSも柔軟に変えられる時代ですし、要件も動きますから。請負でガチガチに縛ると、お互いやりにくいと思うんです。準委任の方が柔軟に対応できますし、単価も若干安くなります。」

発注側「あ、なるほど……確かにその方がお互い良さそうですね」

SIer「ありがとうございます、ではそちらで契約の準備を進めます」

これ、読者の多くが**「うん、そうだね」と言ってしまう**と思います。

私の周りも、ほぼ全員が「なるほど、それでいいよ」と返していました。

でも、私は「いや、それおかしいでしょ」と感じたんです。

なぜか。

不確実性のコーンとは何か？

ソフトウェア開発の世界には「不確実性のコーン」という有名な概念があります。不確実性のコーンとは、プロジェクト初期ほど見積もり誤差が大きく、工程が進むほど誤差が縮まっていく現象を表したモデルで、Steve McConnellの『Software Estimation: Demystifying the Black Art』（2006）で広く知られるようになりました。

McConnellによる具体的な誤差レンジは以下の通りです（Construx Software “The Cone of Uncertainty”）。

つまり、要件定義が終わった段階でも、まだ±1.5倍の誤差は想定内なんです。1億円で見積もったものが、1.5億円になる可能性は、確率論として普通に存在する。

ここで、先ほどの準委任の話に戻ります。

準委任契約にすると、この誤差リスク（＝上ブレした分のコスト）は、全面的に発注側が負担することになります。

工数が膨らめば膨らむほど、ベンダーは人月をチャージし続けられる。

発注側は「予算超過しました、追加予算ください」と経営に掛け合いに走ることになる。

この構造を知らずに「準委任の方が柔軟で安いですね」と言ってしまうのは、“プロジェクトリスクを全面的に引き受けます”と宣言しているのと同じなんです。

図3：不確実性のコーン（McConnell, 2006）――工程が進むほど見積もり誤差が縮まっていく

プロジェクトリスクはどう分担するのが健全か？

じゃあ、どうすればいいのか。私のスタンスはシンプルです。

プロジェクトリスクは、発注側とベンダーで”按分”するのが健全です。

なぜなら、プロジェクトは同じゴールに向かう共同体だから。

発注側だけがリスクを負うのもおかしいし、ベンダー側だけが負うのもおかしい。

全部請負にしろと言っているわけではありません。

柔軟に対応すべき領域は準委任で、固められる領域は請負で、というハイブリッド契約にすればいい。

具体的には、こう打ち返します。

【パターンB：構造を知った発注側の返し】

SIer「準委任の方が柔軟で安くなりますよ」

発注側「ご提案ありがとうございます。ただ、少し整理させてください」

発注側「要件定義は終わっていますよね？ この中で、今後変更が発生しやすい領域と、固まっていて変わる可能性が低い領域、御社の視点で切り分けてもらえますか？」

SIer「あ、はい……」

発注側「固まっている領域は、請負契約で見積もりをお願いします。成果物保証をしていただきたいので。柔軟に対応する領域は準委任で構いません」

発注側「プロジェクトリスクを一方的にうちが背負うのではなく、お互い按分する形で組み直したいんです」

このやり取り、できる発注側は少ないです。

でも、この一言が言えるかどうかで、プロジェクト予算が数千万円変わることもある。

構造を知っているか、知らないかの差なんです。

5. 3つの視点を踏まえた、発注側のスタンス

ここまで、ベンダーの”内側”を3つの視点でお話ししてきました。

• 視点①：SaaSベンダーはロールごとに違うインセンティブで動いている
• 視点②：SIer・支援ファームは人月単価・稼働率・上納金という構造で動いている
• 視点③：契約形態（準委任／請負）によってプロジェクトリスクの分担が決まる

これを踏まえて、発注側が取るべきスタンスはシンプルです。

主導権を握る。

ベンダーから「全体感で提案してください」というオーダーをよく聞きますが、私はいつも思います。

「いや、相手は御社の全体感なんて分からないですよ」 と。

自社のことは、発注側が一番よく分かっているはずなんです。

横の部署の事情、現場の本音、経営陣の期待値、過去プロジェクトの失敗経験。

これ全部、ベンダーは持っていない情報です。

だからこそ、「何を期待するか」を発注側が言語化する必要がある。

これができないと、ベンダーが用意したフレームワークに沿って、ベンダーが主役の商談が進んでしまう。

具体的な打ち手――第三者チェック、同業他社ネットワーク、対案を作る力――については、前回記事で詳しくお話ししています。あわせて読んでいただくと、**構造の理解（本記事）と具体的な打ち手（前回記事）**がセットで揃います。

関連記事：その提案、本当にあなたの会社のためですか？ ― ベンダーに振り回されないために知っておくべきこと

6. 担当者は”翻訳者”として孤独になる――だから仲間が要る

ここで、現場の担当者――特にBizOps、RevOps、情報システム、事業企画の方々に向けて、もう一つお伝えしたい話があります。

ベンダーとの付き合い方の中で、担当者はいつも**“翻訳者”** として動いているんです。

• 経営陣に対しては、数字とビジネスインパクトの言語で翻訳する
• 現場に対しては、「あなたの業務はこう楽になります」という言語で翻訳する
• 横の部署に対しては、他部署の業務との整合性という言語で翻訳する
• ベンダーのエンジニアに対しては、システム要件という言語で翻訳する

全部、言語が違う。

同じ内容を、相手ごとに違う言語で喋り続けているんです。

これ、めちゃくちゃ孤独な仕事です。

なぜなら、同じ目線で喋れる人が社内にいないから。

経営陣は経営の言葉しか理解しない。

現場は現場の言葉しか興味がない。

エンジニアは技術の言葉でしか議論したがらない。

担当者だけが、すべての言語を行き来している。

なぜ多面的に見てくれる仲間が必要か？

ベンダーの提案の”内側”を見破るには、複数の視点が必要です。

経営視点、現場視点、技術視点、契約・法務視点、ファイナンス視点。

これ、1人では絶対にカバーしきれません。

一人で抱え込まないこと――これは、私が支援ファームに在籍していた頃も事業会社時代も痛感してきたことです。

社内の仲間でも、社外のアドバイザーでも、業務委託のプロでも、手段は問いません。

「同じ目線で話せる相手を1人以上確保する」。

これが、ベンダーの構造を見破る最強の打ち手です。

なぜ「改善」の積み上げから始めるべきか？

もう一つ大事なのは、“改善”から始めて信頼を積み上げ、“改革”に乗せていくという順番です。

ベンダーとの契約をいきなり見直す、SIerを入れ替える、SaaSをリプレイスする――こういう”改革”的アクションは、現場の反発を生みます。

まずは小さな改善から始める。

たとえば、「この契約、準委任のここは請負に切り替えませんか？」 という1行の交渉。

「この定例ミーティング、アジェンダをこちらで持ちませんか？」 という小さな主導権の取り返し。

これが積み重なると、発注側の主導権が少しずつ取り戻されていく。

そして信頼が積み上がった段階で、大きな”改革”――契約構造の全面見直し、ベンダーリプレース、BizOps体制の再設計――に乗り出せる。

この順番を間違えないこと。

泥臭い”改善”の積み上げなしに、いきなり”改革”は成立しません。

7. まとめ・おわりに

今回は、ベンダーの”内側”を3つの視点でお話ししました。

• 視点①：SaaSベンダーはロールごとにインセンティブが違い、ビジョンセリングの力学が働く
• 視点②：SIer・支援ファームは人月単価・稼働率・上納金という構造で動き、「複雑に作るほど儲かる」宿命がある
• 視点③：契約形態（準委任／請負）によってプロジェクトリスクの分担が決まり、“お互い按分”が健全

ベンダーの構造を知ることは、相手を敵視することではありません。

むしろ、対等なパートナーシップを築くための前提条件です。

そして、発注側にとってこの**“構造を翻訳し、主導権を取り戻せる状態を設計する”職能**こそが、BizOpsの価値なんです。

BizOpsは、経営・現場・技術・契約を行き来する翻訳者であり、同時にプロジェクトの主導権を握り直せる数少ない存在。

だからこそ、BizOpsの”育成”と”仲間づくり”が、これからの経営の差別化要因になっていくと私は確信しています。

次回は、この「担当者が孤独にならないための組織設計」について、もう少し踏み込んでお話ししたいと思います。

8. よくある質問（FAQ）

Q1. 準委任と請負、どちらを選ぶべきですか？

A. 二者択一ではなく、ハイブリッドが健全です。要件が固まっている領域は請負（成果物保証あり）、仕様変更の可能性が高い領域は準委任で組むのが基本。準委任一本だと工数膨張リスクを発注側が全額負担する構造になります。

Q2. SIerに最新技術の活用を期待してよいですか？

A. 構造上、難しいです。SIerの社内レビューでは前例のない技術構成は「プロジェクトリスク」として跳ねられやすく、自社の利益とリスクが優先される傾向があります。尖った技術活用は、別の座組み（スタートアップ、フリーランス、社内開発）で検討するのが現実的です。

Q3. ベンダーの値引き交渉で効くポイントは？

A. 大きく3つあります。①外資系の本社上納金（約2割）の余白、②役職別の稼働率配分（パートナーは実際は月1〜2日しか入らない）、③契約形態の切り分け（請負と準委任のハイブリッド化）。これらを論点化すると、根拠ある交渉ができます。

Q4. SaaSベンダーの「全社展開で単価が下がる」提案は信じていいですか？

A. 慎重に。FS（フィールドセールス）のインセンティブは受注金額に紐づいているため、大型契約への誘導は構造的なものです。スモールスタートで現場検証してからスケールするのが安全です。Bridge Group調査でAEの約半数が予算未達という現実を踏まえると、達成圧力下の提案であることも頭に置く必要があります。

Q5. BizOps担当者として、まず何から始めればよいですか？

A. 「改革」ではなく「改善」から始めてください。契約条項の一部見直し、定例ミーティングの主導権、見積もり根拠の説明要求――小さな主導権の取り返しを積み上げ、信頼ができたところで大きな構造改革に進むのが王道です。

無料相談のご案内

ベンダーの見積もりが妥当か判断できない、契約形態の切り分けを一緒に整理したい、社内にBizOpsの視点を持つ人材を育てたい。そんな経営者・責任者の方は、お気軽にご相談ください。

現場に入って一緒に整理するところから始めます。初回のご相談は無料です。

お問い合わせはこちら

これまでの支援実績はこちら

参考文献・出典

• The Bridge Group (2024) SaaS AE Metrics & Compensation Benchmark Report (blog.bridgegroupinc.com)
• Steve McConnell (2006) Software Estimation: Demystifying the Black Art, Microsoft Press (Construx Software解説)
• 支援ファーム単価・稼働率・本社上納金は筆者の業界経験に基づく推定値