The Model vs フライホイール｜BtoB営業フレームワークの設計思想と使い分け

The Modelとフライホイール、それぞれの基本構造と成り立ちを解説します。2つのフレームワークの設計思想における根本的な違いを解説します。

「The Modelを導入して分業体制は整った。しかし、部門間の壁が厚くなり、顧客体験が分断されている気がする」「海外のSaaS企業はフライホイールという概念を使っているが、The Modelとどう違うのか」——こうした問いを抱える営業責任者・経営者が増えています。

BtoB営業の世界には、組織設計の土台となる2つの代表的なフレームワークがあります。The Model（福田康隆氏提唱）とフライホイール（HubSpot提唱）。本記事では、スペック比較ではなく設計思想の違いを掘り下げ、自社に最適なフレームワークの選び方と組み合わせ方を解説します。

本記事は「The Modelの限界と次世代営業組織｜分業体制のサイロ化を超える進化モデル」シリーズの一部です。

この記事でわかること

The Modelの課題や次世代営業組織の設計に関心があるBtoB営業責任者・経営者に向けた記事です。

• The Modelとフライホイール、それぞれの基本構造と成り立ち — TheModelの基本構造：TheModelの本質は「営業を科学する」ことにあります。
• 2つのフレームワークの設計思想における根本的な違い — 2つのフレームワークの違いは、機能の違いではなく思想の違いです。
• それぞれが最も力を発揮する企業フェーズ・事業特性 — フライホイールは、HubSpotが2018年に提唱した顧客を中心に据えた循環型成長モデルです。
• 「The Model + フライホイール」のハイブリッド設計の考え方 — 多くの成熟企業にとって、最適解は「どちらか一方」ではなく両方の要素を組み合わせたハイブリッド設計です。
• フレームワーク実装の基盤としてのCRMの役割 — どちらのフレームワークを選択するにしても、MA・SFA・CS機能が統合されたプラットフォーム型CRMが実装基盤として不可欠です。

本記事を通じて、CRMを営業の武器に変えるための実践的なアプローチが見えてきます。「ツールを入れたけど活用できていない」と感じている方にこそ、読んでいただきたい内容です。

The Modelの概要

The Modelは、BtoB営業プロセスをマーケティング → インサイドセールス → フィールドセールス → カスタマーサクセスの4つの機能に分業し、各部門がKPIで管理される営業組織モデルです。福田康隆氏がSalesforce Japan時代の経験をもとに体系化し、著書『THE MODEL』（2019年）で日本のBtoB企業に広く浸透しました。

The Modelの基本構造：

The Modelの本質は「営業を科学する」ことにあります。各部門のKPIを数値で管理し、ボトルネックを特定して改善サイクルを回す——属人的な営業から再現性のある組織営業への転換を可能にしました。

The Modelが力を発揮するフェーズ：

• 新規顧客の獲得が成長の主エンジンである時期
• 営業プロセスが属人的で、分業による効率化余地が大きい組織
• SaaS/サブスクリプション型ビジネスの立ち上げ〜急成長期

フライホイールの概要

フライホイールは、HubSpotが2018年に提唱した顧客を中心に据えた循環型成長モデルです。従来のファネル（漏斗）モデルが「見込み客を上から下に落としていく一方通行」であるのに対し、フライホイールはAttract（惹きつける） → Engage（関係を深める） → Delight（感動させる）の3フェーズが循環し、顧客の成功が新たな顧客を呼び込む構造を描きます。

フライホイールの成長ドライバーは摩擦の排除です。部門間の情報断絶、煩雑なプロセス、サポート遅延など、顧客体験を阻害する「摩擦」を減らせば減らすほど、フライホイールの回転速度が上がり、成長が加速します。

フライホイールが力を発揮するフェーズ：

• 既存顧客からのアップセル・紹介が収益の柱になる成熟期
• 市場が成熟し、新規獲得の効率が低下している事業環境
• 顧客の口コミ・紹介が購買意思決定に大きく影響する業種

設計思想の根本的な違い

2つのフレームワークの違いは、機能の違いではなく思想の違いです。

重要なのは、どちらが正しいかではなく、自社の事業フェーズにどちらがフィットするかです。 急成長期にはThe Modelの実行力が不可欠ですし、成熟期にはフライホイールの顧客中心思想が成長の鍵になります。

ハイブリッド設計の考え方

多くの成熟企業にとって、最適解は「どちらか一方」ではなく両方の要素を組み合わせたハイブリッド設計です。

ハイブリッドの設計原則：

1. 分業は維持しつつデータを統合する — The Modelの分業体制は残しつつ、CRMを統一データ基盤として全部門が同じ顧客情報にアクセスできる状態を作る
2. 部門別KPIの上位に全体収益指標を設定する — 各部門KPIは維持しつつ、NRR・LTV・顧客満足度といった全体指標を経営レベルで追加する
3. 受注をゴールと起点の両面で捉える — The Modelの受注ゴール思想に加え、受注後の顧客成功→紹介→新規リードというフライホイールの循環を意識した設計を組み込む

実際には、SmartHRやfreeeのような日本のSaaS企業も、The Modelの分業体制を基盤としつつ、カスタマーサクセスを起点とした顧客コミュニティやアドボカシー施策を展開しています。これはハイブリッド設計の実践例と言えます。

CRMの役割：フレームワーク実装の基盤

どちらのフレームワークを選択するにしても、MA・SFA・CS機能が統合されたプラットフォーム型CRMが実装基盤として不可欠です。

The Modelでは部門間の引き渡しを正確に管理するためにCRMが必要であり、フライホイールでは顧客データの一元管理と摩擦の排除にCRMが必要です。そして、ハイブリッド設計では両方の要件を同時に満たすCRMが求められます。

HubSpotはフライホイール提唱元として、CRM・Marketing Hub・Sales Hub・Service Hubを統合プラットフォームとして提供しており、The Modelの分業管理とフライホイールの顧客中心設計の両方を1つのシステムで実現できます。

CRMで実現するThe Model vs フライホイール

The Model vs フライホイールを実務に落とし込むには、CRMツールの活用が不可欠です。詳しくは「SFA導入で営業組織はどう変わる？導入メリットと成功のための5つの条件」で解説しています。

このテーマに関連する記事はセールスマネジメントカテゴリで網羅的にまとめています。

あわせて読みたい

• 営業フォーキャストの精度を上げる方法｜パイプラインデータに基づく売上予測の設計と運用
• 営業が入金状況を確認できる仕組みの作り方｜販売管理×会計連携で部門の壁をなくす | StartLink
• 販売管理とは？業務フロー・システム化のメリット・選び方を基礎から解説

まとめ

The Modelとフライホイールは対立するフレームワークではなく、補完関係にあります

押さえておきたいポイントは以下の通りです。

• The Modelは「分業と効率化」、フライホイールは「顧客中心と循環成長」——それぞれの設計思想を理解したうえで、自社の事業構造・成長フェーズ・組織の成熟度に合わせて組み合わせるのが現実的なアプローチです
• まずは現在のThe Model運用における「摩擦」を可視化し、CRMのデータ統合から着手することが、ハイブリッド設計への第一歩になります

よくある質問（FAQ）

Q. The Modelとフライホイールは対立するフレームワークですか？

対立ではなく補完関係にあります。The Modelは営業プロセスの実行効率を高め、フライホイールは顧客体験と循環成長の設計思想を提供します。多くの企業では、The Modelの分業体制を維持しつつフライホイールの顧客中心思想をレイヤーとして重ねる設計が有効です。

Q. フライホイールを導入するにはThe Modelを捨てる必要がありますか？

捨てる必要はありません。分業体制はそのまま活かしつつ、CRMのデータ統合・全体収益指標の追加・カスタマーサクセス起点の施策を段階的に取り入れることで、自然にハイブリッド設計へ進化できます。

Q. フライホイールの「摩擦」とは具体的に何を指しますか？

部門間の情報断絶（引き継ぎ時にコンテキストが失われる）、煩雑なプロセス（顧客が同じ情報を何度も伝える）、サポート遅延、ナレッジの属人化など、顧客体験を阻害するあらゆる要因です。CRMでの情報一元管理は、摩擦を排除する最も基本的な打ち手になります。

Q. 小規模な企業でもフライホイールは有効ですか？

有効です。少人数で顧客との距離が近い組織は、自然にフライホイール的な動きをしていることが多いです。むしろ、成長に伴いThe Modelを導入する際に、フライホイールの思想を最初から組み込んでおくことで、後からサイロ化を解消する手間を防げます。

Q. CRMの選定はフレームワークの選択に影響しますか？

大きく影響します。部門ごとに別ツールを使っている状態では、The Modelの引き渡し管理もフライホイールの摩擦排除も困難です。将来の組織進化を見据えて、MA・SFA・CS機能が統合されたプラットフォーム型CRMを選定することが、フレームワーク実装の前提条件です。