Salesforce 導入：費用、期間、失敗の型

Salesforce の導入は、ライセンスの一行として承認され、プログラムとして実行されます。ライセンスの一行は公開されていて、ユーザー単位、月単位で、取締役会の資料でも守りやすい数字です。そのライセンスを誰かが実際に使うシステムに変えるものは、すべてその一行の外側にあります。そして事業計画書の数字が最初の四半期を生き延びるかどうかを決めるのは、その外側の部分です。

Salesforce は英国向けの価格をポンドで公開しています。Sales Cloud Enterprise は年間一括払いでユーザーあたり月額 £140、Unlimited は £280 です。Enterprise を 50 ユーザー分そろえると、フィールドをひとつも設定しないうちから年間 £84,000 になります。その組織を本番稼働させるサービスについての当社の目安は、初年度ライセンス費用の 1 倍から 3 倍で、その範囲のどこに着地するかは偶然ではありません。動かす要因は四つあり、そのうち技術的なものはひとつだけです。

以下でもっとも重要な語は定着です。技術的に正しくても誰も使わないシステムは、部分的な成功ではありません。保守費用の請求書が付いた全損です。

Salesforce の導入にはいくらかかるのか。 ライセンスはたいてい小さいほうの半分です。Salesforce は英国で Sales Cloud Enterprise をユーザーあたり月額 £140 と提示しているので、50 ユーザーなら年間 £84,000 になり、その上に乗る導入サービスについての当社の目安は初年度ライセンス費用の 1 倍から 3 倍です。この倍率を動かすのは、連携するシステムの数、元データの状態、業務のカスタマイズの度合い、そして製品に合わせて自社の業務を変える意思があるかどうかです。

Salesforce 導入に実際に含まれるもの

Salesforce のプログラムには六つの費用項目があり、価格ページに載るのはそのうちひとつだけです。

ひとつめはライセンスで、ユーザー単位、月単位の公開価格です。ふたつめは導入サービス、つまり組織を設定し、設定でできないものを作り、プロジェクトを回すコンサルタントと開発者です。みっつめはデータ移行で、導入のなかの一作業として見積もられながら、それ自体がひとつのプロジェクトのように振る舞います。よっつめは連携で、すでにデータを持っているシステムに Salesforce をつなぐ作業です。いつつめは研修とチェンジマネジメントです。むっつめは継続的な管理で、これは事業計画書に現れることがありません。ほかのすべての請求書が支払われたあとに始まるからです。

ライセンスだけを挙げた事業計画書は、少しだけ間違っているのではありません。よくあるのは 2 倍から 4 倍の間違いで、その差はほぼすべて三番目、五番目、六番目の項目にあります。

ライセンスは小さいほうの数字です

Salesforce の英国向け Sales Cloud 価格は公開されていて、ポンド建てです。

Starter Suite はユーザーあたり月額 £20 です。Pro Suite は年間一括払いで £80 です。英国のミッドマーケットの買い手がたどり着くことのもっとも多い Enterprise は £140 で、Web API が付く最初の階層だからそうなります。Unlimited は £280 で、Full sandbox と Premier Success Plan が含まれます。Agentforce 1 Sales は £440 です。Premier Success Plan を単体で買うと、価格は正味ライセンス料の 30% です。

ここからふたつのことが出てきます。Pro Suite から Enterprise への差はユーザーあたり月額 £60 で、50 ユーザーなら年間 £36,000 です。しかもこの移行は、営業チームが求めた機能ではなく、たったひとつの連携要件によって強制されることが少なくありません。もうひとつ、サポートプランは比率なので、実際に使うサポートの量ではなく、ライセンスの請求額に比例して増えます。

サービス費用とライセンス費用の比率、そしてそれを動かすもの

計画に使える数字は人日単価ではありません。初年度のサービス費用と初年度のライセンス費用の比率です。この比率は、議論に耐えるくらいには安定しているからです。

英国ミッドマーケットの仕事から得た当社の目安の帯は次のとおりです。データがきれいで連携がなく、ほぼ素のままの単一クラウド展開なら、初年度ライセンス費用のおよそ 0.5 倍から 1 倍に着地します。連携が二つか三つあり、カスタムオブジェクトと自動化がほどほどにある典型的な導入なら 1 倍から 3 倍です。レガシーデータを抱え、連携が五つ以上あり、業務のカスタマイズが重いマルチクラウドのプログラムなら 3 倍から 5 倍、ときにそれを超えます。これらは公表された数値ではなく当社の見積もりであり、業界共通の固定比率を示すパートナーには、その出どころを尋ねるべきです。

£84,000 の例に当てはめると、下端は £42,000、中間は £84,000 から £252,000、上端は £252,000 以上です。この幅こそが話の全体です。だいたいライセンスと同じくらい、としか聞いていない買い手は、端から端まで十倍ある範囲の真ん中に錨を下ろしています。

比率を動かす四つの変数

Salesforce のプロジェクトをひとつ上の帯へ確実に押し上げるものは四つしかありません。どのスコープ協議でも、誰かが数字を出す前にこの四つを確定させるべきです。

ひとつめは連携するシステムの数です。ひとつ増えるごとに、別の設計、別の認証情報、別のエラー経路、そして相手のベンダーがリリースを出したときに壊れる別の何かが増えます。連携の費用は足し算ではなく、足し算より少し悪くなります。障害の組み合わせが掛け算で増えるからです。

ふたつめは元データの品質です。量ではありません。品質です。プログラムのなかでもっとも一貫して過小評価される項目なので、あとで詳しく扱います。

みっつめは業務カスタマイズの度合い、つまり目標とする設計が、製品を入れたままの状態からどれだけ離れているかです。

よっつめは、その組織が製品に合わせて自分たちの業務を変えるかどうかです。費用と成否の両方について、これが単独でもっとも強い予測因子ですが、これをスコープに入れる人はほとんどいません。技術評価の場で問われる、人についての問いだからです。

変える意思はスコープの問題です

自社の営業プロセスを Salesforce の商談モデルに合わせる組織は、安く、更新でき、十分に支援されるシステムを手にします。既存の表計算をそのまま Salesforce に再現させようとする組織は、リリースのたびに衝突する高価なシステムを手にします。

ディスカバリーでの手がかりは言葉づかいです。関係者が、私たちのやり方に合わせてシステムを動かしてほしい、と言ったとき、カスタマイズの予算は二倍になろうとしています。本来どう動くはずなのかを見せて、その理由を説明してほしい、と言ったとき、予算は半分になろうとしています。どちらの発言も筋は通っています。安いのは片方だけです。

これを誠実に扱う方法は、値段を付けることです。提案書に数字を二つ置きます。標準モデルの数字と作り込みの数字で、その差額に語らせます。ステージの命名規則が、カスタム自動化と恒久的なアップグレードのリスクとして £18,000 かかると見えた買い手は、たいてい命名規則のほうを変えます。できますよ、とだけ言われた買い手は変えません。

ディスカバリーと、良いディスカバリーが生むもの

ディスカバリーは、案件を取るためにもっとも削られやすく、あとになってもっとも責められる工程です。スライド資料しか出てこないディスカバリーは営業活動でした。四つの成果物が出てくるディスカバリーは工学の作業でした。

ひとつめは業務のマップです。見込み客が売上になるまでの実際の手順の並びを、判断点とその責任者とともに描いたもので、管理職に説明してもらうのではなく、実際の仕事を観察して作ります。

ふたつめはデータモデルです。オブジェクト、項目、リレーション、選択リストの値、そして項目ごとに、それを維持する担当者の名前です。持ち主のいない項目は、誰も入力しない項目になります。

みっつめは連携の一覧です。Salesforce にデータを送る、あるいは受け取るすべてのシステムについて、方向、量、頻度、レコードを結び付ける識別子、そして接続が失敗したときに何が起きるかを書きます。

よっつめは、測定できる完了の定義です。営業チームが Salesforce を使っている、ではなく、その四半期にクローズした商談の 90% に、担当者が設定した完了予定日と金額とフェーズが入っていて、週次のパイプライン会議は表計算を持ち込まずに Salesforce のダッシュボードから進行する、のような形です。

競争入札の場では、ソフトウェア RFP の指針がそのまま当てはまります。各社にディスカバリーから何が出てくるのかを尋ね、成果物を挙げられない相手は外してください。

日程が消えるのはデータ移行です

移行は構築費用の何割かとして見積もられ、その何倍かとして消費されます。原因はひとつの誤解です。チームはレコード件数に対して見積もりますが、移行の工数は元データの品質に比例します。

きちんと保守された一つのシステムから、信頼できる主キー付きで 200 万行を移すなら、丁寧に作業して一週間です。レガシー CRM と地域ごとの表計算三つと会計パッケージに散らばった 4 万行を、共通の識別子なしで、備考欄に十一年分の自由記述を抱えたまま移すなら、二か月かかったうえに本番開始の時点でもまだ間違っています。後者はレコード数が五十分の一で、工数は八倍です。

何かを約束する前に元データを調べる

プロファイリングとは、日付に合意する前に数を数えることです。すべての元システムに対して実施し、提案書の移行の項目に署名される前に実施してください。

項目ごとに空値を数えます。選択リストにするつもりの項目については、値の種類を数えます。国の列に 340 種類の値が入っているなら、それは選択リストではなく清掃作業だからです。候補キーを共有するレコードが何件あるかを数えます。日付、電話番号、郵便番号の書式の揃い方を測ります。担当者もメールアドレスもなく、三年間なんの活動もないレコードを数えます。置いていくと提案したとき、それを守ろうとする人は誰もいないからです。

中規模の資産なら、プロファイリングにかかるのは二日から五日です。プログラムのなかでもっとも安いリスク低減であり、これを飛ばすことが、移行の見積もりが一方向にしか外れない理由です。

重複排除と、プラットフォームが与えるルール

Salesforce には標準の重複管理があり、その制限が設計を形づくります。オブジェクトごとに有効な重複ルールは最大五つ、有効な一致ルールは一つまで持て、複数の重複ルールを使う場合はオブジェクトごとに有効な一致ルールが五つまで増えます。重複ルールひとつが参照できる一致ルールは三つまでです。

数よりも重要な挙動が二つあります。一致キーは、一致の式が適用される前に、比較対象をもっとも可能性の高い重複 100 件に絞ります。ですから本当に近い候補が 100 件を超えるレコードは、最後まで評価されません。そしてルールは、いくつかのよくある経路でそもそも動きません。簡易作成や、Apex による Lead 変換を有効にしていない状態での Lead 変換がそれで、重複ルールを入れている組織に重複が現れるのはこの経路です。

つまり重複排除は移行の作業で、読み込みの前にステージングのデータ上で行うものであり、有効にして忘れておける実行時の機能ではありません。標準ルールは二番目の防衛線です。

external ID と、upsert が insert に勝る理由

移行するオブジェクトにはすべて external ID が必要です。元システムの主キーを保持する、索引付きのカスタム項目のことです。移行設計のなかで単独でもっとも価値の高い判断であり、決めるのに費用はかかりません。

external ID があれば、その項目を使ってレコードを作成するか更新するかを決める upsert が使えます。値が一致しなければレコードが作成され、一度だけ一致すればそのレコードが更新され、二回以上一致した場合は重複ではなくエラーが返ります。これで読み込みが冪等になります。つまり二回流してもデータが倍にならず、つまりリハーサルができます。

細かい点が二つ噛みつきます。external ID による一致が大文字と小文字を区別しないのは、その項目に一意の属性があり、大文字と小文字を区別しない設定が選ばれているときだけです。そうでなければ ABC123 と abc123 は別々のレコードになります。もうひとつ、項目が一意の索引を持たない external ID である場合、読み込みに使うアカウントには、すべてのデータの参照の権限が必要です。

履歴を移すか、役に立つものを移すか

既定の要望は、全部持ってきて、です。ほとんどの場合それは間違いで、しかも三つの別々の意味で高くつきます。

移行の工数がかかります。もっとも古いデータがもっとも汚く、価値に見合わない清掃時間を食うからです。ストレージがかかります。しかもストレージは実在の費用項目です。Enterprise、Professional、Unlimited の組織にはデータストレージ 10 GB に加えてユーザーライセンスごとに 20 MBが割り当てられるので、Enterprise の 50 ユーザーなら合計 11 GB であって、ユーザーあたり 11 GB ではありません。そして定着が損なわれます。死んだレコードだらけのシステムは、検索結果を信用しないよう利用者を訓練するからです。

守れる立場は、進行中と直近のレコードは全部移し、クローズしたレコードは事業が実際に報告に使う期間の分だけ移し、残りは読める形でどこかに保管する、というものです。使い道のない個人データを持ち続けることは、資産ではなく負債です。ですからこの件では、ストレージの議論とコンプライアンスの議論が同じ方向を指します。

設定か、コードか

Salesforce のどの要件も、宣言的な方法か、コードか、その混合で満たせます。そしてこの選択が、その後十年そのシステムを保有する費用を決めます。コードエディタを一度も開かない立場でも、この区別ははっきり持っておく価値があります。

宣言的にすべきもの

宣言的とは、設定で作るという意味です。オブジェクト、項目、ページレイアウト、入力規則、そして Salesforce の視覚的な自動化ビルダーである Flow がこれにあたります。管理者が変更でき、実行環境を Salesforce が持っているのでプラットフォームの更新を生き延び、適切な権限を持つ人には中身が見えます。

Salesforce 自身のレコードトリガー自動化の判断ガイドが、使える閾値を示しています。自動化の密度を三つの軸で測るもので、ひとつのデータ変更で起動する自動化の数、トランザクションあたりのレコード量、そして下流の更新が関連オブジェクトへどこまで連鎖するか、です。密度が低い場合、つまり自動化が十五未満、レコードが 1 件から 200 件のバッチ、下流への書き込みが多くても一回なら、レコードトリガーの Flow にすべきです。

同じガイドは、ここに並ぶどの項目よりも金銭を節約するルールをひとつ示しています。オブジェクトごとに入口をひとつにすることです。同じオブジェクトで Flow と Apex トリガーを混ぜることが、実行順の不具合を恒久化させる原因です。

カスタムコードが正しいとき

密度が中程度なら混成です。Flow が全体を指揮し、重い処理は呼び出し可能な Apex が担うので、順序は目に見えたまま、計算はテストできる場所に収まります。密度が高ければ Apex トリガーそのものです。その段階では、宣言的な道具が、それを作るために設計されていないシステムを作るために使われているからです。

コードが正しいのは、ロジックが本当に複雑なとき、単体テストをきちんと書く必要があるとき、そして同じ処理が複数の入口から呼ばれるので一箇所にあるべきときでもあります。その作業を人員で抱えるのではなく発注するのであれば、当社のソフトウェア開発サービスは、まさにこの境界、プラットフォームが終わり作り込みの工学が始まる場所のためにあります。

用語は動き、古い用語は警告になります

Salesforce は道具を廃止します。廃止済みの道具を前提に書かれた提案書は、それが実際にはいつ書かれたのかを教えてくれます。Salesforce は 2025 年 12 月 31 日に Workflow Rules と Process Builder のサポートを終了しました。既存のルールは動き続けますが、カスタマーサポートも不具合修正もありません。推奨される道筋は、Migrate to Flow ツールを使った Flow Builder への移行です。

それぞれの選択の長期的な費用

宣言的な作りは、構築も変更も安く済みます。その代償は希釈です。文書化されていない Flow が百個たまると、レコードを保存したときに何が起きるかを誰も予測できないシステムになります。

コードは構築が高くつきますが、規模が大きくなったときに筋道を追う費用ははるかに安く済みます。読めて、版を管理でき、テストできるからです。その代償は開発者が必要になることで、Salesforce の開発者もリテイナー契約も持たない組織は、いずれ自社のシステムを変えられなくなります。

もっとも高くつく失敗は、そのどちらでもありません。すべてを宣言的に作ったパートナーが去ったあと、文書も名前のある持ち主もない組織に残されたシステムです。すべて動いていて、何ひとつ安全には変えられません。これは保守されない作り込みソフトウェアと同じ立場で、ソフトウェア保守に実際にかかる費用についての記事で詳しく書いています。

連携と、制限がアーキテクチャを変える理由

連携については、Salesforce 連携の制限と実際の費用の記事で個別に扱っています。ここに置くべき論点は、プラットフォームの制限が設計の入力条件であって、九週目に見つかる運用上の細部ではない、ということです。

形を決めるのは主に二つの制限です。Enterprise Edition の組織における API リクエストの総割り当ては、24 時間あたり 100,000 回に、ライセンス数とライセンス種別ごとの回数を掛けたものを足し、購入した追加分をさらに足したものです。Salesforce ライセンスの場合、その回数は 1,000 です。Salesforce 自身の計算例では、Salesforce ライセンスを 15 件持つ Enterprise 組織が 115,000 リクエストを得ます。この割り当ては組織全体のもので、ユーザーごとではありません。また 20 秒以上かかる同時受信リクエストは、本番では 25 件が上限です。

ふたつめは Apex のガバナ制限で、トランザクションごとに適用されます。SOQL クエリは同期で 100 件、非同期で 200 件、SOQL が取得できるレコードは 50,000 件、DML ステートメントは 150 件、DML が処理するレコードは 10,000 件、ヒープは同期で 6 MB、非同期で 12 MB、CPU 時間は同期で 10,000 ミリ秒に対して非同期で 60,000 ミリ秒です。

これらを無視した設計は、二十件のレコードでの受け入れテストは通り、最初の本物の夜間読み込みで落ちます。それは不具合ではありません。既定値のまま下されたアーキテクチャの決定です。

環境と、sandbox の更新が壊すもの

Salesforce はストレージと更新間隔の異なる sandbox を四種類提供しており、組み合わせを間違えると、あとになって現れる日程上の誤りになります。

Developer sandbox は 200 MB を保持し、一日に一度更新できます。Developer Pro は 1 GB を保持し、こちらも毎日更新できます。Partial Copy は 5 GB を保持し、テンプレートで定義した本番データの標本を複写し、五日ごとに更新できます。Full は本番の複製で、29 日ごとに更新できます。Enterprise Edition には Developer sandbox が 25 個と Partial Copy が 1 個含まれます。Full sandbox は Unlimited と Performance に付属するか、追加購入します。

Full sandbox の 29 日という間隔は、人が手を打つのが遅れる制約です。現実的に唯一の移行リハーサル環境が月に一度しか更新できないので、問題が見つかったリハーサルは、きれいにやり直せるまでに一か月を要します。Full sandbox で二回リハーサルするなら、それは二週間ではなく九週間の枠です。

Developer と Developer Pro の sandbox はメタデータしか複写しないので、開発者が試験用に読み込んだものは更新後に消えます。テストデータは、バージョン管理に置いた再実行できるスクリプトでなければなりません。そうでなければチームは、更新のたびに一日を手作業の作り直しで失います。

リリース管理は change sets かパイプラインか

本番組織で Apex を開発することはできないので、変更はすべて別の場所から始まり、運ばれる必要があります。どう運ぶかは、尾を長く引く決定です。

Change sets は標準の仕組みです。運べるのは設定画面から変更できるものだけで、レコードは決して運べません。同じ本番組織に属する組織どうしのあいだに配布接続が必要で、受信した change set は構成要素ごとではなく全体として配布されます。組み立ては画面をクリックして行うので、差分が取れず、レビューもできず、再現もできません。同じ change set を二人が別々に組み立てれば、中身は違ってきます。

管理者が一人で毎月リリースする小さな組織なら、それで回ります。同じ組織を二人が変更した瞬間に回らなくなります。併合も履歴もなく、何を出したかの記録が誰かの記憶のなかにしかないからです。

代わりになるのはソース駆動のパイプラインです。メタデータを Git に置き、変更を差分としてレビューし、配布はブランチから実行します。用意に数日かかり、リリース管理を記憶に頼る作業から再現できる作業に変えます。作り手が二人以上いるなら、あとで行う改善ではなく構築の一部として扱ってください。

75% のカバレッジ規則は品質の基準ではありません

Apex を本番に配布するには、単体テストが Apex コードの 75% 以上を網羅し、そのテストが通ることが必要です。Salesforce は、カバレッジはテストの有効性を示すが保証はしないこと、そしてテストは挙動を検証すべきであることを明言しています。

これを商業的に読み替えてください。75% は関門であり、関門は攻略されます。何かを検証するためではなく数字に届くために書かれたテストクラスは、通り、配布され、何も捕まえません。パートナーの成果物をレビューするときは、カバレッジが何パーセントかを尋ねないでください。テストメソッドを三つ見せてもらい、検証の数を数えてください。

Salesforce の導入は本番開始ではなく定着で失敗します

システムが本番に出て、プロジェクトが閉じ、請求書が支払われ、八か月後にも営業部長は表計算で予測を回しています。何も壊れていません。それが失敗した Salesforce プログラムのもっともよくある結末で、どの技術指標にも映りません。

経済性は容赦がありません。ライセンス費用は、使われようが使われまいが続くからです。Enterprise の 50 ユーザーが月額 £140 なら、システムが使われていても使われていなくても年間 £84,000 です。ですから定着率が 40% なら、導入費用を何かに配賦する前の段階で、ライセンスだけでおよそ年間 £50,000 が純粋な無駄になります。

定着は、技術チームには直せない唯一の失敗の型でもあります。パートナーは仕様どおりのものを作り、すべての受け入れ基準を満たし、それでも誰も開かないものを残していけます。だからこそディスカバリーでの完了の定義は利用についてのものでなければならず、だからこそ本番開始をもってプロジェクトを閉じたと見なすべきではありません。

定着を動かす実務

定着を確実に動かすものは四つあり、そのどれも研修動画ではありません。

役割ごとの研修を、別々に実施すること。営業担当と営業管理者は、違う理由でシステムの違う部分を使うので、合同の一回では両方とも中途半端になります。役割ごとに、その役割の業務の流れだけを教えてください。

必須項目を少なくすること。報告が成り立つ最小限の項目を選んでそれだけを必須にし、ほかはすべて任意のままにします。必須項目がひとつ増えるたびに、レコードを途中で放棄する理由がひとつ増えます。入力を罰するシステムには、入力が集まりません。

管理者の報告を、そのデータに依存させること。効くのはこれです。週次のパイプライン会議が、部屋に表計算を持ち込まずに Salesforce のダッシュボードから進むなら、データは入力されます。入力しない側の選択肢が、会話から不在になることだからです。管理者が自分用の表計算を持っているなら、CRM は任意であり、それは全員が知っています。

週の時間を割り当てられた、名前のある持ち主を置くこと。委員会ではありません。組織を保有し、管理者権限を持ち、定着で評価され、そのための時間を確保されている一人です。これがない組織は、最初の一か月から傷みはじめます。

失敗の型と、その早い前兆

当社が修復を頼まれる Salesforce 導入の失敗は、その大半が六つの型で説明できます。そしてどの型も、損害が現れるずっと前に前兆を見せます。

壊れた業務をそのまま複製すること。前兆は、望む結果ではなく現行システムを、しかも旧システムの項目名で説明している要件書です。悪い業務を自動化すると、それは速くなり、変えにくくなります。

際限のないカスタマイズ。前兆は、却下がひとつも載っていない変更要求の記録です。Enterprise Edition はオブジェクトあたりカスタム項目 500 個とカスタムオブジェクト 200 個を許します。プラットフォームの制限に届くはるか手前で、誰にも保守できないものを作れるだけの余地があります。

単一の持ち主がいないこと。前兆は、Salesforce は誰のものかという問いへの答えに、と、という語が入っていることです。

全部を移すこと。前兆は、保存期間の判断ではなくレコード件数で定義された移行の範囲です。

テスト環境の規律がないこと。前兆は、選択リストの値だけだから本番で直してしまおう、と誰かが言うことです。

利用ではなく本番開始を測ること。前兆は、最後のマイルストーンが数字ではなく日付になっているプロジェクト計画です。

小規模、中規模、複雑な導入の期間

経過時間と工数は別の問いですが、買い手はこれを混同します。以下は英国ミッドマーケットの仕事から得た当社の目安の帯であり、公表された数値ではありません。

小規模な導入、つまり単一クラウドで最大 25 ユーザーほど、連携は多くても一つ、きれいなデータ源が一つなら、経過は 6 週間から 10 週間、コンサルタントの工数は 20 日から 45 日です。中規模、つまりクラウド一つか二つにまたがる 25 から 150 ユーザーで、連携が二つから四つ、本物の移行がある場合は、4 か月から 7 か月、90 日から 220 日です。複雑なプログラム、つまり 150 ユーザー以上、マルチクラウド、連携が五つ以上、国が複数にまたがる場合は、9 か月から 18 か月、400 日以上です。

この総量の内訳は、ディスカバリーが工数の 10 から 15%、設定と構築が 30 から 40%、データ移行が 20 から 30% で元データの品質が悪ければ急に増え、連携が 10 から 20%、テストと研修とハイパーケアが 15 から 20% です。膨らむ項目は毎回移行です。

経過時間が、工数をチーム人数で割った値を超えるのは、チームのせいではない理由によります。sandbox の更新間隔、受け入れテストに関係者を確保できるか、そして必要な API を持つ第三者を待つ時間です。そのリスクを誰が負うかは契約が決めます。だからこそ固定価格か実費精算かという問いは、CRM の仕事では他の多くの仕事より重みを持ちます。

CRM プログラムにおける英国のデータ保護

CRM は人のデータベースなので、UK GDPR は事実上そのすべてに適用されます。そしてどの導入でも三つの問いが出てきます。

これに DPIA は必要か

ICO の DPIA が必要になる場合についての指針は、第 35 条第 1 項に由来する一般原則、つまり取扱いが人の権利と自由に高いリスクをもたらす可能性が高い場合に DPIA が必要になることを示し、あわせて第 35 条第 4 項に基づく ICO 独自の処理の一覧を挙げています。

そのうち二つは、典型的な CRM 移行に真正面から当たります。データの突合、つまり複数の出所から得た個人データを結合、比較、照合することは、統合の移行がまさに行うことです。大規模なプロファイリングは、Lead と Account のスコアリングを含みます。ICO はまた、厳格な規則ではないとしつつ、多くの場合は欧州の基準のうち二つが組み合わさると DPIA が必要になることを示す、とも述べています。なおこの指針は Data (Use and Access) Act による変更を受けて現在見直し中なので、要約に頼らず原文を確認してください。

データは実際どこにあるのか

Salesforce は世界規模のプラットフォームであり、自社の組織がどのインスタンスで動くかは契約事項であって、思い込みで決めるものではありません。ICO の国際移転についての簡易ガイドは、2026 年 1 月 15 日に最終更新されており、三段階の判定を示しています。その取扱いに UK GDPR が適用されるか、英国外の組織への移転を自分が始めているか、受け手は別の法人か、です。三つとも「はい」なら制限付き移転です。

制限付き移転には、英国の十分性規則か、International Data Transfer Agreement や Addendum、拘束的企業準則といった適切な保護措置か、あるいは例外が必要です。保護措置に依拠する場合、ICO は移転リスク評価を求めます。これは工学の作業ではなく契約のレビューであり、移行のあとではなく前に行うべきです。

導入パートナーは処理者です

パートナーが自社の組織を設定し、自社のデータを読み込み、その認証情報を保持しているとき、彼らは自社に代わって個人データを取り扱っています。ICO の管理者と処理者についての指針がその帰結を定めており、実務上の意味合いは契約上のものです。

文書化された指示、守秘、安全管理、再委託先、監査権、そして契約終了時のデータの削除または返却を含む、書面の合意が必要です。最後の一項が、もっともよく抜け落ちる条項です。自社の顧客データベースの完全な複製を Full sandbox に十一か月置いたままで、それを削除することについて契約に何も書かれていないパートナーは、相手側ではなく自社側に開いたままの責任です。

検討中のパートナーに尋ねること

六つの問いと、会話を終わらせるべき答えです。

ディスカバリーから何が出てくるかを尋ねてください。答えが、業務のマップ、データモデル、連携の一覧、測定できる完了の定義ではなく提案書であるなら、その相手はスコープを切っているのではなく売っています。

元データをどう、いつプロファイリングするのかを尋ねてください。移行の見積もりに合意したあとでプロファイリングを行うなら、その見積もりは当て推量です。

自動化の既定の選択は何かを尋ね、密度の議論が出てくるかを聞いてください。いつも Flow、あるいは、いつも Apex、と答えるパートナーは、道具をひとつしか持っていません。2026 年に Process Builder を指定してくるパートナーは、三年間、廃止の告知を読んでいません。

変更が sandbox から本番へどう運ばれるかを尋ねてください。change sets という答えは、管理者が一人の組織なら受け入れられ、それより大きいものすべてでは警告です。

本番開始後に誰が組織を持ち、それは週に何時間なのかを尋ねてください。答えられないなら、定着は誰の問題でもありません。

契約が終わったとき、相手の sandbox にある自社のデータがどうなるのかを尋ね、その答えをメールではなく契約書で受け取ってください。当社の技術デューデリジェンスの手引きに書いた規律がここでも当てはまります。保証を受け入れるのではなく、主張を検証してください。

答えが Salesforce ではないとき

利用者がおよそ十人未満で、連携の要件がなく、五段階のパイプラインに収まる業務なら、Enterprise のライセンスもその導入も、問題より大きすぎます。もっと安い CRM か、ユーザーあたり £20 の Starter Suite で用は足り、あとから吸収できる費用で入れ替えられます。

本当の要件が、どの製品も対応していない業務の流れひとつだけで、ほかはすでに片付いているのなら、単一のアプリケーションを載せるためにプラットフォームを買っていることになります。これはたいてい、目的に合わせて作るシステムの出番で、当社の受託ソフトウェア開発はその前提から始まります。作るか買うかの判断は、差別化する業務が事業の中核なのか、その周辺の細部なのかで決まります。

誰もそのシステムを持たないのであれば、買わないでください。営業の過程でもっとも言いにくいことであり、無駄をもっとも確実に予測するものです。持ち主のいない CRM は、大きな音を立てて壊れたりしません。ユーザーあたり月額 £140 を払いながら、置き換えるはずだった表計算の複製に、静かになっていきます。

そして目的が CRM ではなく AI エージェントの層であるなら、それは動いている導入を置き換えるのではなく、その上に載ります。採算については、Agentforce に実際にかかる費用の記事で扱っています。

作業の順序

うまくいく順序はこうです。データをプロファイリングし、四つの成果物が出るまでディスカバリーを行い、標準モデルに合意してそこから外れるものすべてに値段を付け、オブジェクトごとに自動化の入口をひとつにして構築し、Full sandbox で移行を二回リハーサルし、役割ごとに研修し、日付ではなく利用の数字が満たされるまでプロジェクトを開いたままにしておきます。

失敗する順序はこうです。契約し、設定し、移行を後回しにし、研修を一度だけ行い、予定日に本番を開始し、プロジェクトを閉じます。

Mecanik が扱うのは、このうちライセンス管理ではなく工学にあたる部分です。実際のプラットフォーム制限に対する連携設計、移行のプロファイリングと道具作り、設定では足りなくなったところの受託開発、そして CRM のデータを顧客の目の前に出すフロントエンドの仕事です。関わり方についてはソフトウェア開発サービスと Web 開発者の採用のページで説明しています。署名する前にパートナーの見積もりについて第二の意見が欲しいのであれば、そのレビューだけのために開発者を依頼することもできます。

よくある質問

英国での Salesforce 導入にはいくらかかりますか。 Salesforce は英国で Sales Cloud Enterprise を年間一括払いでユーザーあたり月額 £140 と提示しているので、50 ユーザーならライセンスだけで年間 £84,000 です。その上に乗る導入サービスについての当社の目安は、ほぼ素のままの展開で初年度ライセンス費用の 0.5 倍から 1 倍、典型的なミッドマーケットの案件で 1 倍から 3 倍、レガシーデータと重いカスタマイズを抱えるマルチクラウドのプログラムで 3 倍から 5 倍です。

Salesforce の導入にはどのくらい時間がかかりますか。 当社の目安の帯は、単一クラウドできれいなデータ、最大 25 ユーザーなら 6 週間から 10 週間とコンサルタント 20 日から 45 日、連携が二つから四つある 25 から 150 ユーザーなら 4 か月から 7 か月と 90 日から 220 日、レガシー移行を伴うマルチクラウドのプログラムなら 9 か月から 18 か月と 400 日以上です。膨らむ工程はデータ移行です。工数がレコード件数ではなく元データの品質に比例するからです。

Salesforce の導入はなぜ失敗するのですか。 ほぼ必ず、本番開始ではなく定着で失敗します。技術的に正しくても誰も使わないシステムは、ライセンス費用が走り続ける全損です。よくある原因は、壊れた業務の複製、際限のないカスタマイズ、名前のある単一の持ち主がいないこと、履歴データを全部移すこと、テスト環境の規律がないこと、そして利用ではなく本番開始を測ることです。

Salesforce は設定で作るべきですか、カスタムコードで作るべきですか。 Salesforce 自身の判断ガイドが、自動化の密度で閾値を定めています。オブジェクト上の自動化が十五未満、レコード 1 件から 200 件のバッチ、下流への書き込みが多くても一回なら、レコードトリガーの Flow にすべきです。密度が中程度なら、Flow が指揮して呼び出し可能な Apex を使う形が合います。密度が高ければ Apex トリガーです。同じオブジェクトで Flow と Apex トリガーを混ぜず、オブジェクトごとに入口をひとつにしてください。

Salesforce の導入に DPIA は必要ですか。 必要な場合が多いです。ICO は、複数の出所から得た個人データを結合または比較することを意味するデータの突合と、大規模なプロファイリングを、DPIA が必要であることを示す処理として挙げており、Lead スコアリングを伴う統合の移行はその両方に当たります。この指針は Data (Use and Access) Act を受けて現在見直し中なので、要約ではなく ICO の現在の立場を確認してください。