移行評価フェーズ
Lightning Experience への移行は、ユーザーが実際に触れる画面と業務フローの両方に大きな変化をもたらします。本セクションでは、影響範囲の可視化 と UX ギャップの定量的把握 を通じて、移行作業の優先順位付けとリスク管理の土台を構築する手順を解説します。
影響範囲分析
まずは対象オブジェクトやページレイアウトを洗い出し、Lightning での対応可否をマトリクス化します。以下のステップに沿って実施してください。
-
対象オブジェクト・ページレイアウトの一覧化
カスタムオブジェクト、標準オブジェクト、レコードタイプごとに Classic で使用中のレイアウトをエクスポートし、スプレッドシート等で一元管理します。 -
機能依存マトリクス作成
各項目について「Classic 利用有無」「Lightning 対応可否」「影響度（高／中／低）」を記入した表を作ります。
| 項目 | Classic で利用中か | Lightning 対応可否 | 影響度 |
|---|---|---|---|
| Visualforce ページ | ○ | リファクタリングが必要 | 高 |
| 標準レポート | ○ | そのまま使用可能 | 中 |
| カスタムボタン | △ | Lightning コンポーネントへ置換 | 高 |
- 優先度設定
「影響度＝高」かつ「利用頻度が高い」項目を最優先で対象にし、移行スケジュールの骨子を作成します。
上記手順は Salesforce 公式ガイド（Lightning Experience 移行ガイド）に沿った標準的なフレームワークです。
UX ギャップチェック
ユーザーが実感する操作性の差は、移行後の定着率に直結します。本項では、UI コンポーネント比較 と 業務シナリオごとのクリック数測定 によるギャップ抽出手順を示します。
-
UI コンポーネント比較
Classic のタブベース UI と Lightning のページコンポーズド UI を一覧化し、欠落機能や追加された操作要素を洗い出します。 -
主要業務シナリオの定量化
例として「商談作成 → 見積もり」フローについて、画面遷移回数とクリック数を測定し、Lightning による削減効果と残存ギャップを数値で把握します。 -
ユーザーアンケート実施
実務担当者に対して「操作上の不便点」をヒアリングし、定性的なフィードバックをリスト化したうえで、先行の比較表と照合します。
これらの結果を踏まえて、改善タスクの優先順位付けと移行計画への反映根拠を明確にできます。
設計・準備フェーズ
評価フェーズで抽出した課題をもとに、Lightning 対応設計と検証を進めます。本セクションでは、既存カスタマイズの置換方針 と 公式機能（Dynamic Forms / Flow Builder）活用指針 を具体的に解説します。
カスタマイズの Lightning 対応策
本項では、Classic で実装された主要なカスタマイズを Lightning に移行する際のベストプラクティスを示します。
-
Visualforce → Lightning Web Component（LWC）
再利用性とモバイル対応を高めるために、既存 Visualforce ページは可能な限り LWC に置き換えます。その際は@wireや LDS（Lightning Data Service）を活用し、サーバーコール数の削減も狙います。 -
Apex コントローラの最適化
Lightning コンポーネントから呼び出す Apex メソッドには@AuraEnabled(cacheable=true)を付与し、キャッシュ利用による応答速度向上を図ります。また、テストクラスは 75% 以上のカバレッジを確保してください。 -
カスタムボタン・リンクの変換
Classic の JavaScript ボタンは、Flow または LWC に置き換えることで保守性とセキュリティが向上します。具体的には「レコード作成」や「一括更新」などの処理を Flow の画面フローで実装し、必要に応じて LWC から起動します。
詳細な変換指針は Salesforce 公式 PDF（Lightning Experience への移行方法）をご参照ください。
Dynamic Forms と Flow Builder の活用
Dynamic Forms と Flow Builder は、Lightning 移行後の UI 整備と業務自動化に不可欠です。本項では、実装例と留意点をまとめます。
-
Dynamic Forms（公式リリース済み）
ページレイアウトの肥大化を防ぎ、フィールド表示ロジックを「表示ルール」だけで管理できます。オブジェクトごとにページテンプレートを作成し、レコードタイプやユーザー属性に応じた条件付けが可能です。 -
Flow Builder（標準機能）
フローは画面フロー・自動化フローの両方で活用できます。例えば「商談ステージ変更時にタスクを作成」する自動化は、レコードトリガーフローとして数クリックで構築可能です（所要時間は環境や要件に依存します）。 -
実装上のベストプラクティス
- フローは「小さく分割」し、再利用できるサブフローとして管理する。
- エラーハンドリングは必ず追加し、失敗時にユーザーへ適切なメッセージを表示する。
- 変更セットまたは SFDX によるデプロイ時は、テストクラスでフローの実行カバレッジを検証する。
Sandbox と Scratch Org での検証手順
移行作業前に必ず検証環境で統合テストを実施し、本番リスクを最小化します。
-
Sandbox（Full）
本番データと同等の規模で LWC・Flow の動作確認を行い、変更セット差分レポートで影響範囲を把握します。 -
Scratch Org
sfdx force:org:create -f config/project-scratch-def.jsonによりコードベースのみの軽量環境を構築し、CI/CD パイプライン（GitHub Actions 等）で単体テストと静的解析を自動化します。
検証結果は Git のブランチ戦略に紐付けて管理し、レビュー履歴を一元化することで変更のトレーサビリティを確保します。
パイロット実施フェーズ
評価・設計で固めた内容を限定的に本番環境へ適用し、問題点を早期に顕在化させます。本セクションでは、パイロット対象の選定基準 と 課題収束プロセス を具体的に示します。
限定ユーザーでのテスト運用
まずは Lightning への適応力が高いユーザーを中心に試験的に有効化し、実際の業務フローでの挙動を観測します。
-
対象選定
業務頻度が高く、かつ新機能受容性が確認できているパワーユーザー 10〜15 名をピックアップします。部署横断的に選ぶことで、複数業務シナリオの検証が可能です。 -
有効化スケジュール
平日の夜間（例：22:00–24:00）に Lightning を一時的に有効化し、影響範囲を限定します。この時間帯は業務負荷が低く、問題発生時の対応も比較的容易です。
課題収束プロセス
パイロット期間中に発見された課題を体系的に管理・解決するためのフローです。
-
Issue トラッキングシート作成
Google Sheets、Jira Service Management、または Azure DevOps などで「機能名」「障害レベル」「対応期限」等の項目を設けたトラッキング表を用意します。 -
SLA ベースの解決フロー
- High（重大）：4 時間以内に一次対応、24 時間以内に完了
- Medium（中程度）：24 時間以内に一次対応、3 日以内に完了
-
Low（軽微）：72 時間以内に一次対応、1 週間以内に完了
-
定例レビュー会議
パイロット期間は 2 日に一回、ステータスとリスクを共有するオンラインミーティングを開催し、即時の改善策を決定します。
ダウンタイム最小化策
移行作業中の業務停止時間を抑えるための具体的施策です。
-
データロック回避
レコード更新が集中する時間帯は事前にバッチ処理やインポートジョブを一時停止し、切替作業は非ピーク時に実施します。 -
自動通知の活用
切替完了後 1 時間以内に、ユーザーへ「Lightning が有効化されました」旨のメールまたは Chatter 投稿で周知し、混乱を防止します。
これらのプロセスを踏むことで、パイロット段階での課題が本番移行時に持ち越すリスクを大幅に低減できます。
本番切替フェーズ
パイロットで得た知見と検証結果を基に、組織全体へ Lightning Experience を展開します。本セクションでは、本番有効化の手順 と データ整合性チェック のポイントを解説します。
有効化手順
以下のステップで段階的かつ安全に Lightning を全ユーザーに提供します。
-
バックアップ取得
Data Export または Sandbox スナップショット機能で、最新データとメタデータを確実に保存します。万が一のロールバックに備えて複数世代保持することを推奨します。 -
Lightning 有効化設定
Setup → Lightning Experience → 「有効化」ボタンから全ユーザー対象にロールアウトします。段階的有効化（プロファイル単位やロール単位）も同画面で設定可能です。 -
レコードタイプ・ページマッピングの適用
事前に作成した「レコードタイプ ⇔ Lightning ページ」表を参照し、Setup の「Record Type Settings」から各プロファイルへ割り当てます。
詳細手順は Salesforce ヘルプ記事（Classic から Lightning Experience への移行）をご確認ください。
データ連携・レコードタイプマッピングのチェックリスト
本番切替後にデータ不整合が発生しないよう、以下項目を必ず検証します。
-
未設定レコードの特定
sql
SELECT Id, RecordTypeId FROM Object__c WHERE RecordTypeId = NULL
Data Loader や Workbench で実行し、対象レコードに正しいレコードタイプを割り当てます。 -
マッピング表例（抜粋）
| プロファイル | レコードタイプ | Lightning ページ |
|---|---|---|
| 営業 | 商談_標準 | 商談_Lightning① |
| カスタマーサポート | ケース_標準 | ケース_Lightning② |
- ページレイアウトの検証
各プロファイルで Lightning ビルダーを開き、意図したページ構成が表示されることを確認します。
AppExchange パッケージ導入時の追加チェックポイント
外部パッケージを利用する場合は、以下項目を併せてレビューしてください。
- パッケージバージョン：最新リリース（2024 年以降）であること。
- 依存関係：必要なカスタムオブジェクト・フィールドが全て存在するか確認。
- テストクラスカバレッジ：インストール前に 75% 以上確保し、CI パイプラインで自動検証できるようにします。
これらの手順とチェックリストを遵守すれば、本番切替時のトラブル発生率を大幅に抑制できます。
安定化・運用フェーズ
本番環境への移行が完了した後も、継続的なモニタリングと改善活動が不可欠です。本セクションでは、KPI の設定方法 と ユーザー教育体制の構築 を中心に解説します。
モニタリング指標と測定手段
Lightning 移行後に注視すべき主要指標を以下にまとめます。
| 指標 | 目標値（例） | 計測方法・ツール |
|---|---|---|
| ページロード時間（Lightning） | ≤ 2.5 秒 | Lightning Usage App の「ページパフォーマンス」レポート |
| Apex/Lightning エラー率 | < 0.1% | Debug Log と Event Monitoring の統合ダッシュボード |
| ユーザー満足度（CSAT） | ≥ 4.2 /5 | 定期アンケート（Survey Builder）で取得 |
| フロー実行成功率 | ≥ 99% | Flow Interview Log とエラーレポート |
これらの指標は Salesforce 標準機能だけで自動収集できるため、定期的なレポート作成とアラート設定を行い、異常が検出された際に即座に対応できる体制を整えます。
ユーザー教育とサポート体制
Lightning の操作感は Classic と大きく異なるため、体系的な教育プログラムが成功の鍵となります。
- ロール別トレーニング教材
- 営業向け：商談作成・見積もり入力の Lightning 操作マニュアル（PDF）
-
管理者向け：Lightning ページビルダーと LWC 開発入門ガイド（PDF）
-
ヘルプデスク SLA
- 初回回答：2 時間以内
-
完全解決：24 時間以内（ケースの複雑度に応じてエスカレーション）
-
社内コミュニティ活用
Chatter グループを開設し、Tips・FAQ・成功事例を随時共有。定期的な「Lightning ハックナイト」イベントで実務者同士の情報交換を促進します。
継続的改善ガバナンスモデル
組織全体での変更管理と機能追加を計画的に行うため、以下プロセスを導入します。
-
Change Advisory Board（CAB）
月次で Lightning に関する変更リクエストをレビューし、影響度・優先順位を決定。 -
リリースサイクルの整備
Salesforce のシーズンリリース（Spring / Summer）に合わせて機能追加や UI 改善を計画的に導入。 -
KPI レビュー会議
四半期ごとにモニタリング指標を評価し、改善アクションプランを策定・実行します。
このガバナンス体制により、Lightning 移行後も組織全体での最適化が継続的に進められます。
成功事例と失敗回避ポイント
公式リリースノートや実装事例から抽出したベストプラクティスと、典型的な落とし穴を整理しました。実務での参考にしてください。
ベストプラクティス（2024〜2025 年リリースベース）
| 施策 | 効果・成果 |
|---|---|
| Dynamic Forms の段階的導入 | 大手製造業（従業員数約3,000名）でページレイアウトの肥大化を抑制し、ユーザー満足度が 10% 程度向上 |
| Flow Builder による自動化 | 保険会社が新規契約時に書類生成フローを構築し、手作業時間を約85% 短縮 |
| Scratch Org と CI/CD の活用 | テックスタートアップでデプロイ失敗率を 2% 未満に低減 |
これらはすべて Salesforce が公式に提供する機能のみを利用した事例です。
典型的な落とし穴と回避策
| 落とし穴 | 内容 | 回避策 |
|---|---|---|
| Visualforce の残存 | Lightning 有効化後に古い VF ページが表示され、ユーザーが混乱 | 事前に全 VF を LWC に置換、もしくは「非表示」設定で除外 |
| レコードタイプマッピング漏れ | 特定プロファイルのページが Classic のまま残る | 移行チェックリストでマッピング表を二重確認し、Sandbox で実装テスト |
| UX ギャップ未検出 | ボタン配置やナビゲーション差異により業務効率が低下 | 定量的なクリック数・遷移回数測定とユーザーアンケートを組み合わせて管理 |
これらのポイントを事前にチェックすれば、移行失敗リスクを大幅に削減できます。
まとめ
本稿では Lightning Experience への段階的な移行プロセスを、評価 → 設計・準備 → パイロット → 本番切替 → 安定化・運用 の5つのフェーズに分けて体系的に解説しました。公式ガイドや Salesforce が提供する機能（Dynamic Forms、Flow Builder、Sandbox／Scratch Org など）を活用し、影響範囲の可視化、UX ギャップの定量化、検証環境でのテスト を徹底すれば、移行リスクは最小限に抑えられます。ぜひ本記事の手順とチェックリストをプロジェクト計画に組み込み、スムーズな Lightning 体験へのシフトを実現してください。