← エピソード一覧に戻る Episode 158 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― Enterprise らしさは何で決まるのか
タカシ
皆さんこんにちは、タカシです。今日は SaaS プロダクトのエディション設計です。Free、Pro、Enterprise と名前を並べても、高い版に何を積むべきかを間違えると、売上も利用定着も両方崩れます。
ミカ
ミカです。ありますね。上位版ほど何でも入れて、下位版は我慢させる設計になりがちですけど、それだと現場が価値を感じる前に止まりそうです。そもそも edition 設計って pricing と何が違うんですか。
タカシ
pricing はいくらで売るか、packaging は何を束ねるか、edition はその束をどの顧客成熟度に割り当てるかです。つまり価格表の見た目ではなく、誰にどの運用レベルを提供するかを決める設計なんですね。
ミカ
なるほど。同じ機能を増やす話でも、個人が使い始める版と、IT 部門が全社導入する版では仕事が違うわけですね。今日はその境界をどう引くかを具体例で整理したいです。
Chapter 2 基本 ― 各 edition には仕事がある
タカシ
OpenView は、各 package には revenue generation における job が必要だと整理しています。SaaS の edition でも同じで、 entry は価値体験、growth はチーム運用、enterprise は統制という役割が曖昧だと、機能表だけが肥大化します。
ミカ
つまり『何を外すか』より先に、『この edition は誰を成功させる版か』を決めるんですね。そうしないと営業は値引きに逃げやすいし、プロダクトはどこに何を置くか判断できなくなりそうです。
タカシ
その通りです。さらに大事なのは、協業や定着を生む機能まで上位版に閉じ込めないことです。OpenView は、 engagement や collaboration を増やす機能を閉じると、拡張売上と継続率を自分で削ると指摘しています。
ミカ
分かります。上位版に上がる前に、そもそも使われなくなると意味がないですもんね。最近だと SSO も昔ほど超上位機能ではなくて、導入候補に残るための前提っぽくなってきていますよね。
タカシ
まさにそこです。SSO はもはや check-the-box 要件に近づいていて、本当に premium が取りやすいのは SCIM、監査ログ、権限の細分化、複数 IdP、導入支援のような運用統制の複雑さを吸収する機能群なんです。
Chapter 3 具体例 ― 良い境界線は管理と利用の段差を分ける
ミカ
Notion は分かりやすいですね。2026 年 4 月時点で Business は 1 ユーザー月 20 ドルで、SAML SSO、private teamspaces、細かな権限がある。一方 Enterprise は個別見積で、SCIM、監査ログ、SIEM や DLP 連携まで入ります。
タカシ
ここが大事で、Notion は共同作業を成立させるラインと、全社統制を成立させるラインを分けています。現場の利用を止めずに、IT と security が必要とする運用要件は別の edition で受ける構造です。
ミカ
Linear も似ています。Business は年払いで 1 ユーザー月 16 ドルで、private teams や guests、Insights、Zendesk や Intercom 連携まで入る。でも Enterprise になると SAML and SCIM、audit log、IP restrictions、domain claiming が追加されます。
タカシ
そうですね。Linear はチーム利用の拡張と、組織横断の統制を別物として切っています。上位版の価値が『もっと多くの機能』ではなく、『複雑な導入とガバナンスを壊さず回せること』になっているのが重要です。
ミカ
Jira や HubSpot も似た匂いがありますね。Jira は automation 上限が Free 100、Standard 1,700、Premium は paid user あたり 1,000、Enterprise は unlimited。HubSpot Sales Hub Enterprise は 150 ドル席に加えて 3,500 ドルの onboarding fee まであります。
タカシ
その二つは典型例です。Jira は scale と governance を、HubSpot は custom objects や advanced permissions、team hierarchies のような運用複雑性を monetization している。上位版ほど『管理の器』を売っているわけです。
Chapter 4 失敗 ― Enterprise を例外処理の箱にしない
タカシ
よくある失敗の一つ目は、競合と同じ tier 名を置いて安心することです。Free、Pro、Enterprise と並んでいても、誰を成功させる版なのかが曖昧なら、結局は案件ごとの例外運用に流れていきます。
ミカ
二つ目は、 visible value まで Enterprise に閉じることですね。共有や連携まで閉じると、現場が『欲しいから社内で押す』状態が生まれない。PLG だとその時点でアップグレードの推進者を失いそうです。
タカシ
OpenView は、Figma の sales pipeline の 95% が既存ユーザーベース由来だと紹介しています。つまり enterprise 購買でも、 end user が欲しいと思う差分がないと社内稟議は進みにくい。管理者価値だけでは片手落ちなんです。
ミカ
あと Enterprise を何でも受ける箱にするのも危険ですよね。顧客ごとに特注権限や特別条件を足していくと、見た目は 1 edition でも実態は別製品の集合体になって、開発も CS も苦しくなります。
タカシ
その通りです。edition 設計は例外処理の受け皿ではなく、例外を減らすための標準化です。会社規模だけで切るのでもなく、導入体制、権限構造、監査要求、運用負荷の段差で切るほうが実務では再現性が出ます。
Chapter 5 クロージング ― edition の役割を一文で言えるか
ミカ
明日からやるなら、各 edition について『誰向けか』『何を成功させる版か』『どこで次に上がるか』を一文で書くのがよさそうですね。機能表を埋める前に、その版の仕事を言語化する感じです。
タカシ
その上で、活性化を生む機能と統制を支える機能を分けて棚卸しし、上位版の差分を機能数ではなく運用複雑性の吸収で定義する。この順番で考えると、SaaS のエディション設計はかなり強くなります。今回はエディション設計でした。ではまた次回。