2025年10月03日·1 分
マーク・ベニオフとセールスフォース：SaaS CRMからサブスクリプション・ユーティリティへ
マーク・ベニオフとSalesforceがSaaSのCRMを普及させ、企業ソフトをサブスクリプション型のユーティリティへと変えた仕組みと、その意味を学びます。
マーク・ベニオフとSalesforceがSaaSのCRMを普及させ、企業ソフトをサブスクリプション型のユーティリティへと変えた仕組みと、その意味を学びます。
Salesforceの創業物語は、企業がソフトウェアを購入・運用・拡張する方法がどう変わったかを示す具体例として有用です：インストールして維持する一回払いの製品から、サブスクリプションで利用し継続的に改善されるサービスへと移行しました。
この記事はCRMをレンズにしています。CRMが華やかだからではなく、収益に近い場所にあるからです。リード、商談、顧客履歴を追うシステムが採用しやすく、最新の状態を保ちやすくなると、営業やサポート、レポートのスピードが変わります。
マーク・ベニオフが果たした役割はCRMの発明ではありません。ウェブ経由でCRMを提供すること、サブスクリプションで価格設定すること、アップグレードをベンダー側が集中して扱うこと——これら初期の選択の組み合わせが重要でした。タイミングも良かった：職場でのインターネット接続が普通になりつつあり、企業はコストの高い遅いソフトウェア導入にうんざりしていました。
平易な言葉で以下がわかります：
サブスクリプション・ユーティリティは、箱入りのツールというより電気のように振る舞うソフトです：所有するのではなく、確実にアクセスします。可用性とセキュリティ、継続的な改善を期待し、ベンダーがインフラ、アップデート、スケーリングを裏側で運用します。
顧客関係管理（CRM）ソフトは、企業が顧客とのやり取りの“生きた記録”を保持する場所です——顧客が誰か、何が話されたか、何が約束されたか、次に何をするべきか。CRMは単なるデータベースと表現されがちですが、顧客はもっと実践的な目的のために買います：取りこぼしを減らし、責任を明確にすることです。
営業チームはCRMでパイプラインを追跡します：リード、商談、ステージ、次のアクション、想定クローズ日。担当者はアカウントを見て、通話やメールをログし、フォローアップを設定し、記憶や散在したメモに頼らずに済みます。
サポートチームはケースと対応を管理します。顧客が連絡すると、サポートは過去の問題、購入履歴、会話を確認できるため、顧客が繰り返し説明する必要が減ります。
マーケティングチームはCRMのデータを使ってターゲットを分割し、どのキャンペーンが実際に収益に影響を与えたか（クリックだけでない）を測定します。
従来型のインストール型CRMは通常、サーバーの購入、導入のスケジューリング、変更ごとのIT依存を意味しました。アップグレードは大きなイベントで、カスタマイズを壊すリスクがあるため遅延することが多く、結果的にチームは古いバージョンに取り残され、データ品質の問題やプロセスの不一致が生じました。
リーダーは可視性を求めます：正確な予測、コンバージョン率、信頼できるレポート。
現場の担当者は使いやすさを求めます：高速なデータ入力、必須項目の少なさ、明確な日次のやることリスト。
管理者やITは制御を求めます：予測可能な権限、クリーンなデータ規則、常に最新に保つために絶え間ないメンテナンスを必要としないシステム。
良いCRMは、これらの仕事を楽にしつつ「CRMを更新すること自体が仕事になる」ことを避けます。
SaaS（Software as a Service）は、ブラウザやアプリを通じてアクセスするソフトで、ベンダーがサーバー、ストレージ、セキュリティパッチ、アップグレードを運用します。ユーザーはログインして製品を使い、かつては自社オフィスや管理していたホスティング契約にあった裏方の仕事をプロバイダが担います。
インストール型ソフト（古いモデル）はDVDプレーヤーを買うようなもの：あるバージョンに対して前払いし、自分のマシンにインストールし、アップグレードは別途購入やプロジェクトになります。多くの企業は追加ハードウェアやバックアップ、IT時間も購入して管理しました。
サブスクリプションソフトは電気やジム会費のようなものです：定期的に支払い、常に最新のサービスを利用します。価格は通常ユーザー単位の月額/年額で、機能やストレージごとに階層があることもあります。
SaaSは数日で稼働することが多く、導入までの時間が短い。コストも分散されて予測しやすく、大きな「アップグレード週末」が来ることはありません。どこからでもサインインできる点は、外出の多い営業やサービスの仕事にとって重要です。
SaaSは摩擦が全くないわけではありません。インターネットに依存するため帯域や接続の問題が影響します。一部の業界にはデータ居住要件があり、データの保存場所を制限することがあります。またベンダーロックインのリスクもあります：データ、ワークフロー、統合が一つのシステムに収まると、乗り換えコストは高くなるため、エクスポート、API、契約条件を早期に確認する価値があります。
Salesforceは、重要な業務でホスト型ウェブアプリケーションを信頼する流れとともに成長しました。ソフトウェアの箱を買ってサーバーにインストールし、数年おきにアップグレードする代わりに、ブラウザからログインしてすぐに価値を得られるようにしたのです。
有名な「No Software（ソフトウェアをなくそう）」というメッセージは単なるマーケティング演出ではなく、日常の痛みに訴えました。従来のCRMプロジェクトは長い導入サイクル、ITチケット、バージョンの衝突、立ち上げ時点で既に時代遅れに感じられるシステムのトレーニングを意味しました。ウェブ配信のCRMはよりシンプルな道を約束しました：
これらはCRMを多月にわたるIT案件にしたくないリーダーにとって重要でした。営業四半期の途中でも採用可能なツールが求められていたのです。
初期のSalesforceは、営業チームがすぐに認識することにCRMを位置づけました：リード管理、商談追跡、フォローアップの維持、予測レポート。展開を軽量に保つことで「最初の勝利までの時間」を短くしました。担当者は活動のログを開始でき、マネージャーは長い導入を待たずにパイプラインレポートを見られました。
このウェブで提供されるCRMへの初期の賭けは、業務用ソフトが製品よりサービスのように振る舞えるという期待を生みました：どこからでもアクセスでき、すぐに始められ、最新を保ちやすいということです。
Salesforceは単にCRMをインターネットに置いただけではありません——ソフトの設計と運用方法を変えました。重要なアイデアはマルチテナンシーと、アップデートを通常の継続的なサービスとみなすリリースプロセスです。
マルチテナントクラウドでは、多くの顧客が同じ基盤（同じ“建物”）上で稼働しつつ、それぞれの顧客の情報は分離された“ロックされた部屋”のように保たれます。配管や配線は共有しますが、ファイルは共有しません。
この設計は、プロバイダが数千の微妙に異なるインストールを管理する代わりに一つの標準化されたシステムを運用できるため重要です。
ベンダーが単一のコアシステムを運用すると、次が可能になります：
この効率性は通常、顧客あたりの運用コストを下げます。さらに重要なのは、機能の出荷が速くなることです：新しい機能をサービス全体に対してロールアウトでき、各社が個別にアップグレードをスケジュールして実行するのを待つ必要がありません。
従来のインストール型ソフトでは痛みを伴うアップグレードが頻繁に発生しました：ダウンタイム計画、ITプロジェクト、互換性チェック、再トレーニング。継続的なアップデートにより、顧客はバージョンを買い替える代わりに段階的に改善を受け取り、CRMは内部的な大規模マイグレーションなしに最新の状態を保てます。
マルチテナンシーが機能するにはセキュリティが組み込まれていることが前提です：顧客間の強い分離、各組織内の細かな権限、誰がデータを見たり変更したりエクスポートできるかの明確な管理。共有環境では、信頼は機能ではなく基盤です。
SalesforceはCRMソフトを売っただけでなく、継続的なサービスを売りました。その変化によりサブスクリプションが魅力的になった理由は単純です：予測可能性。収益が毎月または毎年更新されると、企業は採用、インフラ、製品投資をより少ない不確実性で計画できます。
顧客にとってもサブスクリプションは購入会話を変えました：大きな前払の資本支出ではなく運用費となり、予算化しやすく、価値が出ていなければ停止しやすくなります。さらに重要なのは、チームが迅速に開始できることです。ウェブ配信と標準化された展開により、数週で稼働できることが多く、四半期単位の導入を待つ必要がありません。
サブスクリプションビジネスは更新にかかっており、それがベンダーを契約後の活動に集中させます：
サブスクリプションのフライホイールは4つの連鎖する動きと考えられます：
活性化が改善されると更新が容易になり、更新が強いと拡張が自然に増えます。そうしてソフトはユーティリティのように感じられるようになります：常にオンで、定期的に更新され、価値が出る分だけ支払うものとして。
「製品」CRMは固定の機能セットを与えます：取引先、連絡先、商談、レポート。一方「プラットフォーム」CRMはより大きなものを追加します：新しいプロセスを一から作らずに済むような、共有サービス上にアプリを作れる仕組みです。
オフィスの一室を買う代わりにビルを借りるようなイメージです。標準のCRMルームは使えますが、新しい部屋を追加するための配管、セキュリティ、メンテナンスも提供されます。カスタムアプリは同じ環境上でCRMデータ、UI、権限と共存します。
現代のわかりやすい並列は「チャットで作る」系のツールです。例えば、Koder.aiはチャットインターフェースでウェブ、バックエンド、モバイルアプリを作れるvibe-codingプラットフォームです（ウェブはReact、バックエンドはGo＋PostgreSQL、モバイルはFlutter）。これはCRMの代替ではありませんが、CRMsにしばしば必要な周辺ワークフローアプリ（受付フォーム、承認ツール、軽量ポータル、統合ヘルパー）を素早く作れる点で適しています。特にソースコードのエクスポートが重要な場合に有用です。
多くのCRMプラットフォームは以下のような繰り返し使える原始部品で構成されています：
ポイントは目新しさではなく一貫性です。これらのビルディングブロックが共有されると、カスタムアプリはコアCRMと同じログイン、レポート、モバイルアクセス、管理コントロールを継承します。
標準のCRM機能は販売を扱います。プラットフォーム機能はあなたの会社が実際にどう動くかを扱います：パートナープログラム、コンプライアンス手順、サービスのエスカレーション、更新、オンボーディング、社内のリクエスト。すべてのプロセスを「商談」やスプレッドシートに無理やり押し込むのではなく、業務の流れに合わせてモデル化できます。
リセラーをオンボードする必要があると想像してください。Partner Applicationというカスタムオブジェクトを作り、会社名、担当地域、納税番号、リスクスコア、ステータスのようなフィールドを追加します。
次に承認フローを追加します：Status = “Submitted” のとき、法務 → 財務 → パートナーマネージャーに回す。承認されたらERPにパートナーを作成するAPI呼び出しをトリガーし、CRMは自動的にトレーニング用のフォローアップタスクを作成します。
これがプラットフォームの約束です：CRMは単なるツールではなく、構築するための基盤になります。
CRMは「ただのソフト」になり得ますし、他の企業や顧客自身が機能を拡張するハブにもなり得ます。後者がエコシステムです。
Salesforceの場合、エコシステムには以下が含まれます：
これらのグループは傍観者ではありません。多くの企業が採用できる再利用可能なソリューションを作り出し、一社限りのカスタム作業にとどめません。
顧客はより速いセールスサイクル、クリーンなデータ、より良いレポーティングといった成果を欲しがります。マーケットプレイスモデルは実績あるアドオンを選ぶことでそれを速く実現させます。
パートナー側の利点は配布経路です。各案件をゼロから始める代わりに、プラットフォームを既に採用している買い手に到達でき、課金やトライアル、レビューが意思決定を助けます。
AppExchangeはビジネスソフトの「アプリストア」のようなものです。企業はCPQ、電子署名、サポートツール、業種特化のワークフローなどのアドオンを探して、摩擦を減らしてインストールし、CRMデータに紐づけたまま使えます。
マーケットプレイスが機能すると、通常以下が見られます：
結果として、CRMはベンダー一社がすべての機能を作るのを待たずに、ビジネスに合わせて成長します。
CRMが有用であるかは中の情報次第です。問題は顧客データが一か所にまとまっていないことです：営業メールはOutlookやGmailにあり、請求はERPや会計ツールにあり、サポート履歴はヘルプデスクにあり、マーケティング活動は別の場所で追跡されています。これらのツールが更新を共有しないと、どの数字が「正しい」のかでチームが揉め、顧客は継ぎ目を感じます。
多くの会社は意図せず「複数の真実」を作ってしまいます。営業がCRMで電話番号を更新し、サポートは別の番号をチケットに持ち、経理は請求に紐づく別の連絡先を持っている——その結果は重複作業、受け渡しミス、信頼できないレポートです。
統合はシステム同士が制御された方法で会話することを可能にします。APIは他のアプリが読み書きできるドアとルールの集合です——たとえば「リードを作る」「アカウントを更新する」「最新の請求状況を取得する」など。コネクタはその仕事を既製のリンクとして包装し、ゼロから始める必要を減らします。
統合が適切に設定されると、CRMはシステム・オブ・レコードになります：人々が現在の顧客プロファイルをCRMで信頼し、他のツールは専門的な役割を続けます。
CRMがメール、請求、サポート、分析とつながると、それは単なる「営業ツール」ではなくワークフローハブになります。乗り換えは接続の再配線、データの移行、チームの再トレーニング、ダウンタイムのリスクを伴うため困難になり、CRMは置き換えにくくなります。
企業が「エンタープライズ対応」と言うとき、通常意味するのは一つです：何千人ものユーザー、機密データ、厳格な社内ルールを安全に運用でき、変更ごとにカスタムプロジェクトになることを避けられること。
まずセキュリティは日常的な利用を念頭に設計されていなければなりません。強力な認証オプション、明確な権限モデル、偶発的なデータ露出を減らすための保護が必要です。
次にコンプライアンスはロゴではなく再現可能なコントロールの問題です：誰がアクセスできるか、どうやってアクセスが付与されるか、後で証明できるかどうか。
大規模運用では「管理者コントロール」が製品そのものです。ロールベースアクセス制御（RBAC）は職務に応じて権限を割り当てられるようにし、営業担当、マネージャー、サポート担当、契約社員などが必要な情報だけを見られるようにします。
監査はミスや争点が起きたときに重要です。良いシステムは主要なイベント（ログイン、権限変更、データエクスポート、設定編集）を記録し、問題を速やかに調査しステークホルダーに説明できるようにします。
継続的なアップデートの背景には変更管理があります。エンタープライズは変更をテストする方法、設定を変更できる人の制限、組織のプロセスに合わせた機能の段階的展開手段を必要とします。
サブスクリプション・ユーティリティは稼働していることが期待されます。稼働率に加えて、企業購買者はインシデント時の明確な情報を求めます：何が起きたか、誰が影響を受けているか、現在の状況、再発防止策。透明な更新は混乱を減らし信頼を保ち、顧客が自社の対応を調整するのに役立ちます。
Salesforceは単にCRMを売っただけでなく、そこに他社が拡張できる場を作りました。エコシステムは参加者が増えるほど価値が複利的に積み上がるため、堀（競争優位）になり得ます。
健全なマーケットプレイスはシンプルなループを作ります：アプリとパートナーが増えるほど製品が有用になり、より多くの顧客を引き寄せ、より多くのビルダーを惹きつけさらに多くのアプリが生まれる。時間が経つと、買い手は「単なるCRM」ではなく「このCRMで何ができるか」を評価し始めます。
プラットフォームの深さは関係性も変えます。企業のセールスプロセス、顧客データ、自動化、ダッシュボード、サードパーティツールがすべて一つの環境にあると、置き換えは週末だけで終わる作業ではありません。コストはライセンスだけでなく、再教育、統合の再構築、蓄積された知見の移行にも及び、乗り換えコストを高め顧客の存続期間を延ばします。
エコシステムは拡張を自然にします。チームはコアCRMから始め、マーケティング、サービス、分析、業界向けパッケージを追加するかもしれません。あるいはCPQ、契約管理、データ補完、サポートのアドオンといった専門アプリを追加するかもしれません。プラットフォームはメニューになり、追加製品やアプリでアップセルが起きます。
エコシステムは裏目に出ることもあります。組織がアプリを蓄積するほど管理作業が増え、パフォーマンスが低下し、ユーザー体験がばらつく可能性があります。アプリの品質は均一ではなく、セキュリティ実践、サポート、長期的なメンテナンスに差があります。
信頼を維持するにはプラットフォーム運営者が厳格なガバナンスを必要とします——認定基準、レビュー手続き、権限コントロール、悪質な行為者への対処を明確にしないと、堀が複雑さの増大に変わり顧客の不満を招きます。
CRMは「ただのソフト」のように感じられることがありますが、収益予測、顧客履歴、ワークフローの意思決定がそこに住み着くと本質が変わります。良い選択はブランド名ではなく適合性にかかっています。
以下の4つの質問から始めてください：
次にライセンス価格を超えて管理者の時間、トレーニング、統合、マーケットプレイスアプリの有料分まで予算を圧迫テストします。
複数のカスタムワークフローを作る可能性がある場合は「ビルドの面積」も評価してください：CRMプラットフォーム内で拡張するのか、アプリを購入するのか、独立した内部ツールを構築するのか。構築するチームはしばしば迅速な反復とコントロールを求めます—例えばソースコードのエクスポート、信頼できるデプロイ、ロールバックが可能かどうかを見ます。（Koder.ai はソースコードのエクスポート、デプロイ/ホスティング、カスタムドメイン、スナップショット、ロールバックをサポートしており、CRMエコシステムにカスタムの伴走アプリを含める場合に有用です。）
社内での製品ローンチのように扱ってください：
マーケットプレイス（AppExchangeスタイル）からアプリを選ぶ際は次を確認してください：
古いスプレッドシートを再現したくなる誘惑は強いです。まずはコアワークフロー（リード→商談→顧客）から始め、人々が基本を使いこなした後で複雑さを追加してください。
Salesforceの物語は3つのレバーが組み合わさったものとして覚えやすいです：SaaS配信、明確なCRMカテゴリへの集中、プラットフォームエコシステム。SaaSは配布とアップグレードの摩擦を減らしました。CRMは「やるべき仕事」を明確にしました（関係を管理し、収益を予測し、販売を調整する）。プラットフォームとマーケットプレイスはコアを待たずに顧客とパートナーが拡張できることで価値を何倍にもしました。
モデルが健全に回ると、ソフトは一回買いの製品よりも信頼できるサービスのように振る舞います：サブスクして、継続的に改善され、あなたが運用する他のすべてとつながり、予測可能な管理で運用される。ベンダーは継続収益を得て継続的な改善に投資し、顧客は最新のシステムを手に入れ、パートナーは端っこを埋め、統合は重複入力を減らします。時間が経つと、その製品は単なるアプリではなく日常のオペレーティングレイヤーになります。
契約する前に設計図を厳しく問いただしてください：
実務的な追加質問：CRMの周辺にある“エッジワークフロー”をどれだけ早く構築（または再構築）できるか？ プラットフォーム内で拡張するか、マーケットプレイスから買うか、Koder.aiのようなツールでカスタムアプリを作るかに関係なく、ソリューションまでの速度とガバナンス（エクスポート、デプロイ、ロールバック）はCRMの機能一覧と同じくらい重要です。
さらに調べたい場合は /blog を参照するか、サブスクリプション設計が総コストに与える影響を確認するには /pricing をご覧ください。
「サブスクリプション・ユーティリティ」は、所有するものではなく安定的にアクセスするソフトウェアを指します。定期的に支払い、可用性やセキュリティを期待し、ベンダーがインフラやパッチ、スケーリングを運用しつつ継続的な改善を提供します。
CRMは顧客とのやり取りや次に取るべきアクションの“生きた記録”です。チームはCRMを、受け渡し漏れを減らし、責任を明確にし、パイプライン追跡やケース履歴、レポートを通じて収益活動を可視化するために“使います”。
オンプレミスのCRMはサーバーや長期の導入作業、変更のたびにITに依存する必要があることが多いです。アップグレードはカスタマイズを壊すリスクがあり、大掛かりなプロジェクトになりがちで、結果として古いバージョンに取り残され、プロセスやデータ品質がばらつきます。
SaaSはベンダーがホスティング、セキュリティパッチ、アップグレードを管理するブラウザやアプリ経由で利用するソフトウェアです。
主な違い：
マルチテナンシーとは、多数の顧客が同じ基盤インフラを共有しつつ、各顧客のデータは論理的に分離されている設計です。プロバイダが標準化されたコアを一元管理でき、バグを一度直せば全員に反映され、新機能を個別の顧客ごとにアップグレードさせる必要がなくなる点で、速度とコストに影響します。
継続的アップデートは顧客体験を大きく変えます。顧客側の“アップグレード期”が減り、計画的な移行やダウンタイム、互換性チェックの負担が軽くなります。代わりに、テストや権限管理、リリースコントロールなどのチェンジマネジメントが重要になります。
プロダクト型CRMは決められた機能（取引先、連絡先、商談、レポート）を提供します。プラットフォーム型は再利用可能なビルディングブロック（カスタムオブジェクト、オートメーション、セキュリティモデル、APIなど）を提供し、オンボーディング、更新、コンプライアンスといった固有のプロセスを同じ記録系の中でモデル化できる点が違います。
マーケットプレイス（AppExchangeのような）は、検証済みのアドオンや導入支援を提供して価値を高めます。
導入前に確認すべき点：
統合はシステム間の情報のやり取りを制御された形で可能にします。CRMをシステム・オブ・レコードにするには、以下を決める必要があります：
実務的チェックリスト：
成果と採用を優先し、最初から過度にカスタマイズしないこと。
実行可能な手順：
詳細比較は /blog、コスト検討は /pricing を参照してください。