プライシング
バリューベースプライシングの成否を分ける『価格レバーの同軸性』｜SaaS・コンサル・B2B製造業
同じ機能を売っていても、値上げしたら顧客が離れる会社と、値上げしても離れない会社があります。SalesforceもHubSpotも値上げの歴史を重ねてきましたが、大規模な解約には至っていません。一方で、多くのB2B提案は「競合より安い」に着地して失注します。この差は、提供している価値の大きさではなく、課金する指標——価格レバー——が顧客の成果の伸びと同じ軸に乗っているかどうかで説明できるのではないか、というのが本記事の仮説です。
失注の理由を突き詰めていくと、「提供価値が足りなかった」よりも「課金する指標が顧客の成果とずれていた」ケースの方が根が深いのではないか、というのが本記事の出発点にある問題意識です。価値の大きさそのものよりも、その価値をどの指標で切り取って課金するかという設計の方に、値上げの成否を分ける要因があると考えています。私はバリューベースプライシングの成否を、「提供価値の大きさ」ではなく「価格レバーと顧客成果の同軸性」で決まると考えています。ただし本記事で公開データから検証できるのは、SalesforceやHubSpotのような公開料金ページを持つSaaSの設計までです。コンサルティングやB2B製造業については、個別クライアントの実数値ではなく、価格設計の一般的な構造として扱います。この境界を最初に引いた上で、3つの業界を見ていきます。
前提: 2つの定義
価格レバーの同軸性
課金の単位——価格レバー——が、顧客の成果の伸びと同じ軸に乗っているかどうかを指します。たとえば席数課金でも、顧客の成果（売上や生産性）が実際に席数の増加と連動して伸びるなら「同軸」です。逆に、成果が席数とは別の軸（利用時間や成約率など）で伸びているのに席数で課金していれば、それは「ずれレバー」です。ずれレバーの価格は、顧客にとって「使えば使うほど損」または「使わなくても払う」と感じられ、値上げの説明が効かなくなります。
成果報酬が成立する測定合意
成果報酬型の価格は、何を成果とし、誰が、どの基準で測るかを契約前に固定できるかどうかで成立可否が決まります。固定できないテーマ（成果指標が事後的に解釈でずれる、外部要因の寄与が大きい、測定コストが報酬額に見合わない）では、私は成果報酬型を勧めません。測定合意が崩れた瞬間に、成果報酬は「約束」から「紛争の種」に変わるからです。
全体像: 3業界の価格レバーと同軸性
| 業界 | 価格レバー | 顧客成果との同軸性 |
|---|---|---|
| SaaS（Salesforce/HubSpot） | 席数・コンタクト数・利用量 | 高い（運用対象の拡大＝レバーの増加） |
| コンサルティング | 稼働時間 または 成果連動 | 測定合意が取れる範囲でのみ高い |
| B2B製造業 | 提案価格（一括） | ROIワークシートの入力値合意が前提 |
同軸性が高いほど、値上げは「ベンダー都合の値上げ」ではなく「顧客自身の成長に伴う支払い」として受け止められます。以下、各業界を見ていきます。
SaaS: 課金指標が顧客の運用対象と同軸になっている構造
Salesforce: 機能別ティア設計
SalesforceのようなCRMは、導入規模・運用統制・連携要件ごとにプラン差分を設けることで、顧客価値に応じて単価を上げています。重要なのは価格表そのものではなく、「どの運用課題を解決するプランなのか」を段階的に分けている点です。
| 価値レベル | 想定顧客 | 解放される価値 | 価格設計の意図 |
|---|---|---|---|
| 導入初期 | 少人数チーム | 顧客情報の一元管理 | 初期導入の障壁を下げる |
| 標準運用 | 部門で使い始めた組織 | レポート、自動化、権限管理 | 日常業務への定着を促す |
| 全社展開 | 複数部門で運用する企業 | API連携、詳細なワークフロー | オペレーション複雑化に応じて単価化 |
| 高度運用・支援付きプラン | ガバナンス要件が高い大企業 | 専任支援、高度管理、拡張性 | 失敗コストの回避価値を価格に反映 |
SalesforceとHubSpotの公開料金ページ（本記事末尾の参考リソース参照）を見比べると、両社に共通するのは、下位ティアと上位ティアの差が「機能の数」ではなく「課金単位が何に連動して増えるか」で説明されている点です。下位ティアでは基本機能へのアクセスそのものが価値の中心になっている一方、上位ティアに上がるほど、席数やコンタクト数といった課金単位が顧客側の運用規模（管理するユーザー数、扱うデータ量、連携先の数）と直接紐づいていく構造になっています。
顧客が上位プランへ移行するのは、「便利そうだから」ではなく「現場の運用要件が増えたから」です。席数課金は、席数が増えるほど顧客側の運用対象（管理するデータ、承認フロー、統制範囲）も実際に増える構造になっている限りにおいて、同軸レバーとして機能します。
HubSpot: 無料導線と利用規模連動
HubSpotのようなgo-to-marketツールは、無料または低額で導入を始めてもらい、運用が複雑になる段階で自動化・レポート・ガバナンス機能に課金する構造を取ります。ポイントは「機能が多いから高い」ではなく、「顧客が成果を出し始めるほど管理対象が増える」ことを価格レバーにしている点です。
| 導入段階 | 顧客の状況 | 主な価値訴求 | 価格レバー |
|---|---|---|---|
| 無料・試用段階 | 初めてCRMやMAを触るチーム | 初期設定のしやすさ、早い成果 | 導入障壁を最小化 |
| 小規模運用 | 少人数で案件や配信を管理 | テンプレート、基本自動化 | ベース料金や席数 |
| 成長フェーズ | リード数や部門連携が増加 | 高度な自動化、分析、権限管理 | 利用量と機能束の両方を課金対象に |
| 全社展開 | 複数部門で共通基盤化 | 監査性、統合、支援体制 | 契約規模と支援範囲を反映 |
この型が機能しやすいのは、利用開始のハードルと成長後の運用複雑性が同じ指標（コンタクト数・利用量）でつながっているからです。無料導線で獲得した顧客が、成果を出すほど自然にレバーを踏み、有料化・上位化していきます。
コンサルティング: 成果報酬は測定合意が命
コンサルティングでは、稼働時間だけで価格を決めるより、顧客が得る成果に一部連動させたほうが価値を説明しやすい案件があります。ただしこれは「成果報酬型の方が優れている」という話ではありません。測定合意が取れるかどうかで、選ぶべき価格モデルが変わるという話です。
| 項目 | 従来の時間課金 | 成果報酬型 |
|---|---|---|
| 価格基準 | コンサルタントの時給 | 実現される成果（売上増、コスト削減） |
| 顧客のリスク | 高い（成果不問） | 低い（成果連動） |
| コンサルのリスク | 低い（時間保証） | 高い（成果未達なら報酬減） |
| 成立条件 | 測定合意が不要 | 何を成果とし誰がどう測るかを事前固定できること |
成果指標の例としては、売上増加なら基準期間からの増分に料率を掛ける、コスト削減なら合意した削減額の一部を成果報酬にする、プロジェクト成功なら固定報酬にマイルストーン達成ボーナスを組み合わせる、といった設計があります。いずれも共通するのは、プロジェクト開始前に「何をもって成果とするか」「誰がどの基準で測るか」を明文化しておくことです。これができない案件——外部要因の寄与が大きい、測定コストが報酬額に見合わない、事後的に解釈が割れやすい——では、私は成果報酬型を勧めません。ベースフィー中心の時間課金に、成果達成時のボーナスを添える程度にとどめるべきだと考えています。
私自身の判断基準としては、成果報酬型を提案する前に「測定合意が事前に固定できるか」を必ず自問すべきだと考えています。外部要因の寄与が大きいテーマや、成果の定義が事後的に解釈で揺れうるテーマでは、たとえ成果報酬の方が説明が魅力的に見えても、時間課金にボーナスを添える設計に留めるべきです。測定合意という前提条件を飛ばして成果報酬を導入すると、プロジェクトの終盤になって「何を成果と数えるか」を巡る対立が表面化するリスクの方が大きいというのが、この記事全体を通じての立場です。
B2B製造業: ROIワークシートは価値を顧客の数字に翻訳する装置
B2B製造では、製品仕様や競合価格だけでなく、現場改善による経済効果を顧客と共同で試算すると、価格プレミアムを説明しやすくなります。ただしこのアプローチが機能するのは、ワークシートに入れる入力値（現状コスト、削減率）について顧客と合意が取れている場合に限られます。合意が取れなければ、回収期間の数字自体が説得力を持ちません。
以下は自動溶接ラインを自動化する際の試算例です。数値は説明用の入力例であり、実際の商談では顧客ごとに現状コストを個別に確認する必要があります。
| 項目 | 式 | 入力例 |
|---|---|---|
| 現状の年間コスト | 人件費 + 手直し + 停止時間コスト | 600万円 |
| 導入後の年間コスト | 保守費 + 教育費 + 想定停止時間コスト | 100万円 |
| 年間削減額 | 現状の年間コスト − 導入後の年間コスト | 500万円 |
| 投資回収期間 | 提案価格 ÷ 年間削減額 | 2.4年（提案価格1,200万円の場合） |
同じ構造は計測機器にも当てはまります。検査装置であれば、年間生産個数・不良品1個あたりの損失・改善前後の不良率差から年間削減額を算定し、回収期間で価格を説明します。いずれの場合も、価格を正当化しているのは製品スペックではなく、顧客自身の数字に翻訳された経済効果です。
ROIワークシートが機能するかどうかを分けるのは、ワークシート自体の精緻さではなく、入力値の前提（現状コストの算定方法、削減率の根拠）について商談の早い段階で顧客と合意を作れるかだと考えています。前提が擦り合っていない状態で回収期間の数字だけを提示すると、議論は「その数字は本当か」という検証合戦に陥りやすく、逆に入力値そのものを顧客と一緒に埋めていくプロセスを踏めれば、商談の焦点が価格の妥当性ではなくROIの実現可能性に移っていくはずです。
再ソート: 失注は「価値不足」ではなく「レバーのずれ」か「測定合意の欠如」
3つの業界を、価格レバーの同軸性が高い順に並べ替えると、見え方が変わります。
- SaaS（同軸性が最も高い）: 課金指標（席数・利用量）と顧客の運用対象拡大が同じ軸で動く。値上げの説明コストが低い。
- B2B製造業（条件付きで高い）: レバー自体は一括価格だが、ROIワークシートの入力値に顧客が合意している限り、回収期間という顧客の軸に翻訳されている。合意が崩れると同軸性も崩れる。
- コンサルティング（測定合意が前提）: 成果報酬型は理論上もっとも同軸性が高くなりうるが、測定合意という前提条件が最も脆い。合意なきまま成果報酬を導入すると、同軸どころか紛争の種になる。
この並べ替えから言えるのは、失注や値上げ拒否の原因を「提供価値が小さかった」に帰着させるのは早計だということです。多くの場合、原因は価格レバーが顧客の成果と別の軸で動いているか、成果や入力値についての測定合意が事前に取れていないかのどちらかにあります。
私が新規案件で最初に確認すること
価格モデルを設計する前に、まず価格レバーと顧客の成果が同じ軸で動くかどうかを確認する。これが同軸なら値上げの説明コストは低く、ずれているなら先に構造を直さない限りどんな価値訴求も効かない、というのが私の立場です。加えて、成果報酬型を検討する案件では、測定合意を契約前に固定できるかどうかを判断基準にしています。固定できないなら、たとえ成果指標が魅力的でも成果報酬型は選びません。
データと同軸性という枠組みは、価格を脅しの道具にするためのものではなく、読者自身が次の提案で価格レバーをどこに置くかを判断するための材料として使ってもらえればと思います。
関連記事
本記事は「事例数を盛らず、公開情報から設計原理を読む」という手法をusage-based-pricing-successと共有しています。同記事はAWS・Stripe・Twilioの公開料金ページから従量課金の成立条件を読み解いており、本記事の価格レバーの同軸性という概念の先行例にあたります。また、価値の受け取り手が曖昧なまま価格設計を進めてしまう典型的なつまずきについてはバリューベース価格の実装ガイドで扱っています。ROIワークシートの理論的な裏付けはevc-analysis-guideの参照価値・差分価値・切替負担のフレームに接続しています。
参考リソース
- Salesforce公式: Pricing Plans
- HubSpot公式: Pricing
- Thomas Nagle: The Strategy and Tactics of Pricing
- McKinsey: Value-Based Pricing in B2B Markets
本記事はネクサフローのプライシングシリーズの一部です。
