Salesforce全社展開ロードマップ設計 | CIOのためのフェーズ別戦略と組織設計

#「部門導入」と「全社展開」は別のプロジェクトである

「営業部門でSalesforceがうまくいったから、次はマーケティング部門にも展開しよう」。この発想自体は正しいのですが、部門導入の延長線上に全社展開を置くと、多くの場合、途中で行き詰まります。

この記事はCIO、IT部門長、VP of Salesなど、Salesforceの全社展開を起案・推進する立場の方向けです。 導入済み環境の課題改善はSalesforce導入が失敗する7つのパターンを、CoE組織の構築手順はCoEフレームワークをご参照ください。

部門導入と全社展開の違いは、規模の違いではなく、プロジェクトの性質の違いです。

部門導入は「最適化」のプロジェクトです。 単一部門の業務プロセスをSalesforceに実装し、その部門の生産性を向上させることが目的です。ステークホルダーは限定的で、意思決定は比較的速い。データモデルもその部門の業務に最適化すればよい。

全社展開は「標準化と統合」のプロジェクトです。 複数部門のプロセスを横断的に標準化し、データを統合し、組織全体としての可視性と効率性を実現することが目的です。ステークホルダーは全社に広がり、部門間の利害調整が必要になる。データモデルは全社の要件を満たす汎用的な設計が求められる。

部門導入の成功体験をそのまま全社に横展開しようとすると、部門ごとにサイロ化したSalesforce環境が乱立する結果になります。全社展開は、導入プロジェクトではなく、組織変革プロジェクトとして位置付ける必要があります。

#全社展開を阻む3つの構造的障壁

#障壁1: 組織サイロ

各部門が独自のKPI、プロセス、用語体系で運営されている状態です。営業部門の「商談」とCS部門の「案件」が実質的に同じものを指していても、部門ごとに異なるオブジェクトで管理されているケースがあります。

組織サイロの解消には、全社共通のビジネス用語辞書（Business Glossary）の策定と、部門横断のプロセスオーナーの任命が必要です。CIOは技術的な統合だけでなく、組織的な統合のスポンサーとしてこの問題に関与する必要があります。

#障壁2: データの断絶

部門ごとに導入されたSalesforceは、それぞれ独自のデータモデルを持っています。取引先の定義、商談のステージ設計、カスタムフィールドの命名規則が部門ごとに異なると、データの横断的な分析が不可能になります。

さらに深刻なのは、Salesforce外のデータとの断絶です。マーケティング部門のMAツール、CS部門のサポートシステム、経理部門の請求システムとSalesforceの間でデータが分断されていると、顧客の全体像を把握できません。

#障壁3: プロセスの非標準化

同じ「商談管理」でも、事業部ごとにプロセスが異なるケースが一般的です。ある事業部はステージを5段階で管理し、別の事業部は8段階。ある部門は金額を受注時に確定し、別の部門は見込み段階で入力する。

これらの非標準化は、それぞれの部門にとっては合理的な理由がある場合が多いです。全社展開では、「統一すべきプロセス」と「部門固有に残すプロセス」を見極める設計力が問われます。

#フェーズ設計の方法論

全社展開は、以下の3フェーズで設計します。各フェーズに明確なゴールとGo/No-Go基準を設定し、フェーズゲートで進捗を評価するアプローチが重要です。

#フェーズ1: パイロット（3〜6か月）

目的: 全社展開の設計仮説を検証する。

パイロットは「小さく始める」ための段階ではなく、「全社展開の設計を検証する」ための段階です。したがって、パイロット部門の選定基準は「最も導入しやすい部門」ではなく、「全社展開の成功に最も影響する部門」であるべきです。

パイロットで検証すべき項目:

• 全社共通のデータモデルが実務で機能するか
• 標準化したプロセスが現場の業務に適合するか
• 教育プログラムの有効性
• 技術的なアーキテクチャの妥当性

Go/No-Go基準の例:

• ユーザー定着率80%以上
• データ入力率90%以上
• 主要KPIの改善傾向が確認できること

#フェーズ2: 部門展開（6〜12か月）

目的: パイロットで検証した設計を複数部門に適用し、部門間連携の課題を解消する。

部門展開の順序は、ビジネスインパクトと導入難易度のマトリクスで優先順位を付けます。

各波の展開後にレトロスペクティブ（振り返り）を実施し、次の波に教訓を反映します。

#フェーズ3: 全社統合（12〜24か月）

目的: 部門別に展開したSalesforceを全社プラットフォームとして統合し、横断的な可視性と自動化を実現する。

このフェーズでの主要課題は以下の通りです。

• データ統合: 部門間のマスターデータの統一、重複排除
• レポート統合: 全社横断ダッシュボードの構築
• プロセス連携: 部門をまたぐワークフローの自動化
• ガバナンス確立: 全社的な変更管理、リリース管理の体制構築

#部門展開の優先順位付けフレームワーク

部門展開の順序を決定する際、以下の4つの評価軸でスコアリングします。

1. ビジネスインパクト（重み: 40%）

• 売上への直接的な影響度
• コスト削減の期待値
• 経営戦略との整合性

2. データ連携価値（重み: 25%）

• 既存展開部門とのデータ連携による追加価値
• 顧客360度ビューへの貢献度

3. 組織レディネス（重み: 20%）

• 部門長のスポンサーシップ
• チェンジマネジメントの受容度
• ITリテラシー

4. 技術的複雑性（重み: 15%）

• 既存システムとの連携要件
• データ移行の複雑さ
• カスタマイズ要件の規模

各軸を5段階で評価し、重み付き合計スコアの高い部門から展開することで、投資対効果の高い順序で進められます。

#全社統合フェーズのアーキテクチャ設計

#マルチオーグ vs シングルオーグ

全社展開における最も重要なアーキテクチャ判断が、Salesforceの組織（オーグ）構成です。この判断は後からの変更が極めて困難であるため、初期段階で慎重に行う必要があります。

シングルオーグ（推奨）

全社で1つのSalesforce組織を共有するアーキテクチャです。

メリット:

• データの一元管理と横断的なレポーティングが容易
• ライセンスコストの最適化（共有可能）
• 統合的なガバナンスが実現しやすい
• 顧客の360度ビューが自然に構築される

課題:

• 部門間の要件調整が必要（カスタマイズの衝突リスク）
• リリース管理の複雑化（全部門への影響を考慮する必要）
• 権限設計の複雑化（部門間のデータアクセス制御）

マルチオーグ

部門・事業部ごとに別々のSalesforce組織を持つアーキテクチャです。

メリット:

• 部門ごとの独立性が高い
• リリースの影響範囲が限定的
• 規制対応（データの物理的分離）が容易

課題:

• データの横断分析に別途統合基盤が必要
• ライセンスコストが重複する
• 組織間のデータ連携が技術的に複雑

原則としてシングルオーグを推奨し、マルチオーグは法規制やM&Aなど明確な理由がある場合にのみ選択すべきです。

#統合パターンの設計

全社展開では、Salesforceと外部システムの統合パターンも重要な設計要素です。

• リアルタイム統合: 即時性が必要なデータ連携（例: 受注データ→請求システム）
• バッチ統合: 大量データの定期同期（例: マスターデータの夜間バッチ）
• イベント駆動統合: 特定のイベントをトリガーとした連携（例: 商談ステージ変更→通知）

MuleSoft、Dell BoomiなどのiPaaS（Integration Platform as a Service）の導入判断も、全社展開の初期段階で行うべきです。

#リソース計画と体制設計

#内製 vs SI vs ハイブリッド

全社展開のリソース計画は、短期のプロジェクトコストではなく、3〜5年のTCOと組織のケイパビリティ計画で判断すべきです。

内製（自社開発）

• 適するケース: 長期的にSalesforceを戦略的プラットフォームとして活用する企業
• 投資: Salesforce開発者・管理者の採用・育成（1〜2年で戦力化）
• 利点: ナレッジの蓄積、俊敏な変更対応、長期的なコスト効率

SI（外部委託）

• 適するケース: 初期導入を迅速に進めたい企業、社内にITリソースが不足する企業
• 投資: プロジェクトごとの委託費用
• 利点: 専門知識の即時活用、他社事例の知見、リソースの柔軟な調達

ハイブリッド（推奨）

• 戦略・設計・コアカスタマイズは内製チームが担当
• 大規模な開発プロジェクトや専門性の高い領域はSIに委託
• SIからのナレッジトランスファーを計画的に行い、段階的に内製比率を上げる

#全社展開の推進体制

CIOを最終責任者とし、以下の体制を構築します。

• プログラムマネージャー: 全体の進捗管理、部門間調整、経営報告
• ビジネスアナリスト（部門別）: 各部門の要件定義、プロセス設計
• テクニカルアーキテクト: 全社のアーキテクチャ設計、技術標準の策定
• チェンジマネジメントリード: 教育計画、コミュニケーション計画、定着支援
• データアーキテクト: データモデル設計、データ品質管理

全社展開の各フェーズで共通する成功要件は、CRMにデータが蓄積されることです。どれだけ優れたアーキテクチャを設計しても、現場がデータを入力しなければ全社展開の価値は実現しません。aileadのような対話データAIプラットフォームを活用し、商談の対話データがSalesforceに自動連携される仕組みを整えることで、展開先の部門で即座にデータが蓄積され、定着率と展開速度を大幅に向上できます。400社以上の導入実績を持つaileadの詳細は、デモでご確認ください。

#まとめ

Salesforceの全社展開は、部門導入の延長ではなく、独立した組織変革プロジェクトとして設計すべきです。3つの構造的障壁（組織サイロ、データの断絶、プロセスの非標準化）を理解した上で、パイロット→部門展開→全社統合の3フェーズで段階的に進めます。

アーキテクチャ判断（マルチオーグvsシングルオーグ）は初期段階で行い、体制設計は3〜5年のTCO視点で内製・SI・ハイブリッドから選択してください。各フェーズのGo/No-Go基準を明確にし、フェーズゲートで進捗を評価する仕組みが、全社展開を計画通りに進める鍵になります。

#関連記事

• Salesforce導入が失敗する7つのパターンと対策
• Salesforce CoE（Center of Excellence）の作り方
• Salesforceが定着しない原因と解決策
• SalesforceでRevOpsを実現する方法