← エピソード一覧に戻る Episode 159 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― Enterprise 要件は機能表ではない
タカシ
皆さんこんにちは、タカシです。今日は SaaS プロダクトにおけるエンタープライズ要件です。現場は欲しがっているのに、情シス、法務、調達で止まる。この壁をどう越えるかを整理します。
ミカ
ミカです。ありますよね。営業から見ると大型案件が見えているのに、SSO はありますか、監査ログはありますか、請求書払いできますか、で会話が急に重くなるやつです。
タカシ
そうなんです。Enterprise 要件は大企業向けに機能を足す話ではなく、全社導入に耐える条件を整える話です。認証、監査、データ所在、契約運用まで含めて初めて稟議の土俵に乗ります。
ミカ
今日は、その中でも何が導入前提で、何が上位版としてお金を取りやすい複雑性なのかを分けて見たいです。ここが混ざると、何でも Enterprise に積んでしまいそうです。
Chapter 2 基本 ― 入口は SSO、本番は運用統制
タカシ
まず整理すると、Enterprise 要件は三層あります。認証と権限、監査と統制、インフラと契約運用です。SAML SSO や SCIM、監査ログ、data residency、SLA、invoice 対応まで一連で見られます。
ミカ
SSO があれば一安心、ではないんですね。むしろログインの入口を越えただけで、その後の入退社反映や権限の細かさ、監査の証跡まで見られると。
タカシ
その通りです。OpenView も、SSO は今や評価に残るための check-the-box 要件に近いと述べています。差が出るのは、SCIM、監査ログ、細かな管理者権限、sandbox、契約運用の整備です。
ミカ
つまり、使う人の便利さより、組織として安全に増やせるかが問われるわけですね。現場担当者の熱量だけでは押し切れないのが Enterprise の面白さでもあり難しさでもあります。
タカシ
SaaStr Podcast でも Truework の Ryan Sandler が、Enterprise 顧客は業界をまたいで似た要件を求めると話しています。SSO、権限管理、監査ログ、詳細レポート、change management。この並びはかなり普遍的です。
Chapter 3 具体例 ― 何が前提で何が上位差分か
ミカ
Notion は分かりやすいですね。2026 年 4 月時点で Business は 1 メンバー月 3,150 円で、SAML SSO、private teamspaces、domain verification が入る。でも Enterprise になると SCIM や audit log、SIEM イベントが乗る。
タカシ
加えて Notion Enterprise は、Notion AI 利用時の zero data retention with LLM providers も打ち出しています。AI 時代の Enterprise 要件は、権限だけでなく生成 AI まわりのデータ扱いまで広がっているわけです。
ミカ
Linear も同じ構図ですね。Business は年払いで 1 ユーザー月 16 ドルだけど、Enterprise では invoice と PO、SAML and SCIM、granular admin controls、IP restrictions、audit log、custom terms、uptime SLA が入る。
タカシ
ここが重要で、売っているのは単なる追加機能ではありません。情報システム、法務、購買が扱える運用パッケージそのものです。つまり Enterprise とは、組織の複雑さを引き受ける版だと捉えると分かりやすいです。
ミカ
Slack も学びがあります。Business+ でも data residency や全メッセージ export はある一方、Enterprise+ で audit logs、DLP、legal holds、Discovery API、custom roles、domain claiming が加わるんですよね。
タカシ
しかも Slack は、data residency があってもメンバープロフィールや一部の分析データはリージョン外に保存されうると明記しています。ここを説明できないと、逆に trust を失う。表面の機能名だけでは足りません。
ミカ
Atlassian も似ていますね。Jira Enterprise では unlimited automation、IP allowlisting、multiple IdP、audit logs があり、sandbox は Premium と Enterprise で使える。全部を最上位に閉じない設計です。
Chapter 4 失敗 ― 1 社の要望で別製品にしない
タカシ
よくある失敗の一つ目は、SSO を入れた時点で Enterprise-ready だと思うことです。実際には、SCIM、監査ログ、権限粒度、データ所在、障害時の責任分界まで見られます。入口だけでは通りません。
ミカ
二つ目は、1 社の大口案件に引っ張られて特注化することですね。権限モデルや監査項目を案件ごとに積み増すと、Enterprise 版じゃなくて顧客別製品の集合体になってしまいます。
タカシ
三つ目は、調達と法務を後回しにすることです。invoice や PO、MSA、DPA、SLA、セキュリティ質問票の返答が遅いだけで、現場は欲しくても案件は閉じません。プロダクト以外の整備が売上に直結します。
ミカ
sandbox も軽く見ないほうがよさそうです。本番前に設定変更や連携を試せないと、導入担当は怖くて前に進めない。change management は意外とプロダクト要件なんですね。
Chapter 5 クロージング ― 要件を三層で棚卸しする
ミカ
明日からやるなら、自社の Enterprise 要件を、認証と権限、監査と統制、インフラと契約運用の三層で棚卸しするのがよさそうです。前提条件と上位差分を混ぜないことが第一歩ですね。
タカシ
その上で、営業資料に書く機能名ではなく、実際の挙動と制約まで説明できる状態にする。これができると Enterprise 要件は重荷ではなく、値付けと勝率を上げる武器になります。今回はエンタープライズ要件でした。