【完全ガイド】旧世代CRM (SugarCRM・vTiger・Dynamics CRM旧版・Notes/Domino) からモダンCRMへの移行戦略

本記事は、Oracle Siebel CRM を10〜15年運用してきた企業で、本社／グループから「Salesforce か Dynamics 365 への統一を検討しろ」と打診され、1〜2年以内に「移る／延命する／統合しない」の三択を経営に答える必要が出てきた情シスの責任者を読者として書きました。営業部門への説明資料、Oracle との価格交渉、移行費の概算、Open UI 延命の落としどころ——意思決定に必要な材料を、コンサル的な抽象論ではなく、Siebel と Salesforce の具体的な仕様レベルで整理します。

1. 「1〜2年以内に決める」が現実的なリミットになっている理由

Siebel CRM は Oracle が継続提供しており、Innovation Pack（IP）も毎年リリースされ続けています。「製品が消える」わけではありません。それでも1〜2年で決断が必要になる理由は次の3つです。

① Oracle Premier Support の年額更新。Siebel の Premier Support は通常、ライセンス価格の22%前後で、毎年の更新時に見直し交渉が走ります。「来年も払うのか、移行費に振り替えるのか」を経営が問うてきます。
② IE モード／旧 ActiveX 系 UI の限界。Siebel の High-Interactivity（HI）クライアントは IE 依存で、Edge IE モードの段階的廃止と社内端末更新の波で、現場が事実上 Open UI に移らざるを得なくなります。Open UI 移行自体に1年級の工数がかかるため、「Open UI で延命するか、いっそ Salesforce に移るか」が同じテーブルの議論になります。
③ Siebel 開発者の社内・社外双方の枯渇。eScript／Workflow Process／Business Service／EIM／Siebel Tools を扱える人材は、新規供給がほぼ止まっており、改修1件あたりの単価が上がっています。

つまり「サポートはまだある」が「人と画面とサポート費の3点で持続困難」というのが、現場が直面しているリアルです。

2. Siebel で「実際に詰まる」5つの場面

移行検討で経営に説明する材料は、「サポート切れ」より「業務がもう前に進まない」事例の方が効きます。代表的な5つを挙げます。

1. 新規キャンペーンを打つたびに、Marketing モジュールへ画面追加が必要。Web フォームから Siebel への取り込みに毎回 EAI／Workflow の改修が走り、リリースまで2〜3カ月かかる。
2. 営業のスマホ対応。Siebel Mobile／Open UI Mobile はあるが、UX が現代のSFAアプリと比較して厳しく、現場が個人の Excel／LINE／Notes に逃げている。
3. Service Request の SLA 計算を変えたいだけで、Workflow Process と eScript の両方に手を入れる必要があり、試験工数が膨らむ。
4. 個人情報保護法・GDPR の「忘れられる権利」対応。Siebel の S_CONTACT／S_PARTY 周りに散らばるデータを安全に削除するスクリプトの保守自体が負担。
5. BIツール（Tableau/Power BI）からの参照。Siebel Analytics（OBIEE）以外からの直接参照に苦労し、夜間バッチでDWHに吐き出す構成のままになっている。

このうち2つ以上が「直近12カ月でクレームになっている」場合、移行プロジェクト立ち上げの根拠は十分です。

3. 三択の整理：移る／延命する／統合しない

議論を発散させないため、最初に三択をテーブルに置きます。

多くの企業で現実解になるのは「A を3年計画で進めつつ、移行完了までは B で延命」というAB併用です。Cは「将来Aに移す前提のつなぎ」として明示しないと、永久に併存します。

4. Salesforce にそのまま移せるもの・移せないもの

「Siebel の機能は Salesforce で全部できますよね」という打診に、現場が一番苦しむ場面です。実態は次のような棲み分けになります。

そのまま移せる（Fit が高い）

Account（取引先）／Contact（取引先責任者）／Opportunity（商談）／Activity（活動）／Case（ケース／SR）の5標準オブジェクトは、Siebel の S_ORG_EXT／S_CONTACT／S_OPTY／S_EVT_ACT／S_SRV_REQ と概念的に直対応します。標準項目の8〜9割は写像可能です。

仕様レベルで設計し直しが必要

Position 階層（営業ポジション・組織）：Siebel の Position は人ではなく「役割」で、人はそこに割り当てられる構造ですが、Salesforce はユーザーと Role/Territory の組み合わせです。Enterprise Territory Management で再設計するのが定石です。
Party Data Model（S_PARTY 中心）：法人・個人・部門・世帯（Household）を Party で抽象化する Siebel の構造は、Salesforce では Person Account／Account-Contact Relationship／Account Hierarchy で組み直すことになり、データモデルの議論が最も時間を取ります。
Assignment Manager（自動割当）：Salesforce では Assignment Rules＋Flow＋Apex の組み合わせで再構築します。Siebel の細かい優先度ルールほど、Apex で書くしかなくなります。

原則そのまま再現しない方が良い

eScript（Server Script／Browser Script）：機能単位で要件を書き起こし、Apex／Flow／LWC で作り直すのが現実解です。「移植」ツールはあっても、デバッグ性とメンテナンス性が悪くなります。
Workflow Process／Business Service の連鎖：Salesforce の Flow は単一フロー思想なので、Siebel の「Workflow から Business Service を呼んでさらに Workflow を呼ぶ」構造は、整理しないと再現できません。

5. Open UI 延命を選ぶ場合の落としどころ

Bを選ぶ場合、最低限やるべきは次の3つです。

① HI から Open UI への完全移行。IE 依存を断ち、Edge／Chrome で動く構成にする。これだけでも数千万〜1億円規模の工数が出るプロジェクトです。
② Innovation Pack の追従。Siebel ドキュメントで最新IPの内容を確認し、Premier Support 適用範囲を保つ。
③ 「3年で Salesforce 等に移す」明文化。Bを選ぶ瞬間に Aへの移行ロードマップを引かないと、5年後にもう一度同じ議論をすることになります。

BをAへの「時間稼ぎ」と割り切るなら、Open UI 投資は必要最小限のリブランディング・性能改善に絞り、機能追加は止める判断が合理的です。

6. データ移行の地雷：S_PARTY と監査ログ

Siebel→Salesforce の本番データ移行で、ほぼ確実に詰まるのが次の3点です。

① S_PARTY 起点の権限・可視性：Siebel は「Position が見える」モデル、Salesforce は「Owner / Role Hierarchy / Sharing Rule」モデル。誰が何を見えるかのマッピング表を、Position 単位で全件作る必要があります。これだけで2〜3カ月の工数です。
② S_ACT_EMP_EVT などの活動履歴：1取引先あたり数百〜数千件の活動履歴を持つ顧客では、Salesforce の API 呼び出し数・ストレージ単価・レコード件数上限が直接効きます。「直近3年＋過去はBigQuery／Snowflake にアーカイブ」が現実的な落とし所です。
③ 監査・変更履歴：Siebel の S_AUDIT_ITEM 相当の履歴を Salesforce の Field History／Field Audit Trail に持ち込むかは、保管要件と追加費用（Field Audit Trail は別ライセンス）で決めます。

移行ツールは MuleSoft や Data Loader＋EIM のCSV エクスポートが定番ですが、本質的な工数はツールではなく上記3点の仕様調整に消えます。

7. カスタム機能の「捨てる勇気」を経営に握ってもらう

Siebel の長年のカスタム資産は、移行プロジェクトの工数の大半を生む要因です。Fit-to-Standard の名のもとに「移植しない」と決める判断は、現場ではなく経営が引き受ける必要があります。経営に提示すべきは次のような表です。

「全部移す」と「全部捨てる」の中間の具体的な削減率を経営に出させることが、移行費の見積もりを現実的なレンジに収める鍵です。

8. 3年TCOの実数試算（5,000ユーザー・グローバル想定）

経営に出す資料の核心です。Salesforce 公式の料金ページに記載のリスト価格をベースに、5,000ユーザーで試算した目安を示します（為替・割引・追加製品で振れます）。

注意点：Salesforce のリスト価格は大規模契約での割引交渉余地が大きいのが実態で、5,000ユーザー規模なら20〜40%の割引が出ることも珍しくありません。経営に提示する金額はリストではなく、Salesforce ／パートナーから取得した実見積を必ず使ってください。

9. 18カ月プロジェクトの典型スケジュール

5,000ユーザー規模・Siebel カスタム中量級での目安です。「12カ月でやれ」と言われたら範囲を切り詰めるしかなく、「24カ月かけたい」と言われたら現場の集中力が持ちません。

段階リリースをする場合、Service モジュール先行 → Sales 後の順が安全です。Sales のオーナーシップ／可視性の議論を Service 立ち上げ後の知見で固めると、合意形成が速くなります。

10. 失敗事例から逆算する「やってはいけない3つ」

Siebel→Salesforce で大きく傾いたプロジェクトの共通パターンは次の3つです。いずれも一次情報での具体額は伏せますが、当初予算の1.5〜2倍、期間で6〜12カ月の遅延が起きています。

① 「全カスタムを移植」を初期スコープに入れた。300本のeScript／Workflow を全部 Apex／Flow に書き直す試算で予算が組まれ、実装フェーズで「これは廃止できる」が後出しになり、合意のやり直しで遅延。
② Position 階層を Salesforce の Role に直訳した。3,000ポジション・10階層の Siebel 構造をそのまま Salesforce Role にしたため、画面表示が遅延し、SOQL の Sharing 計算で詰まる。Territory Management に組み直しで4カ月の追加工事。
③ 「データは全件移行」を本社命令で固定した。10年分の活動履歴を持ち込み、Salesforce のレコード上限・ストレージ追加費・API 制約に直撃。Big Object／外部DWHアーカイブの設計で4カ月遅延。

これらは「優秀なSI」を選んでも起きる失敗で、意思決定権者がスコープを早期に絞る覚悟でしか防げません。

11. 1〜2年で決断するなら、いまやる3アクション

意思決定までに、現場として今四半期から始めるべきは次の3つです。

① カスタム資産の棚卸しを今期中に終える。eScript／Workflow／Business Service／I/F の本数と、直近12カ月の改修頻度・問い合わせ件数を集める。これが移行費の根拠になります。
② Open UI への移行可否と費用を別件で見積もる。Bの「延命費」を出すと、A（移行）の見積もりが「比較対象あり」で経営に通りやすくなります。
③ Salesforce／Dynamics 365／Oracle CX の3社からアセスメント提案を取る。Siebel 互換性、データ移行、業界テンプレート（Salesforce Industries 等）への対応で各社の濃淡が出ます。1社見積もりだけで決めると交渉力が出ません。

3アクションを揃えると、経営への「移る／延命する／併存する」の三択提案を、根拠付きで1ページにまとめられます。Siebel 移行は10年に1度の意思決定なので、ここの準備に半年かける価値は十分にあります。