SalesforceのLightning Experience移行は待ったなし!移行計画の立て方と実践ガイド
#Salesforce #移行 #Lightning Experience
目次
- 1. Lightning Experienceが必要な理由
- 1.1 現場が抱えるClassicの課題
- 1.2 Lightning Experienceで変わる日常業務
- 1.3 なぜ今、移行が急がれるのか
- 2. 移行の準備と影響範囲の把握
- 2.1 移行準備の第一歩:Lightning Experience 準備状況チェック
- 2.2 具体的な影響範囲の特定方法
- 2.3 リスク評価のポイント
- 2.4 移行判断のための評価シートの作成
- 3. 段階的な移行計画の立て方
- 3.1 準備フェーズ:土台作り
- 3.2 パイロットフェーズ:小規模での検証
- 3.3 全面移行フェーズ:計画的な展開
- 3.4 移行時の注意点
- 3.5 トラブルシューティング
- 4. まとめ
「Classicの画面は使い慣れているから、今のままでいいんです」「移行の準備をする時間がなくて…」
こうした声をよく耳にします。確かに、日々の業務に追われる中で、システムの移行という大きな変更に踏み切るのは勇気がいることです。しかし、昨今のビジネス環境では、素早い意思決定と効率的な顧客対応が求められています。従来のClassic画面では、これらの要求に十分に応えることが難しくなってきているのです。
Lightning Experience(LEX)は、単なる見た目の変更ではありません。データの可視化、業務プロセスの効率化、モバイル対応など、現代のビジネスニーズに応える機能が凝縮されています。特に、商談管理や顧客データの分析において、その真価を発揮します。
本記事では、現場の管理者の視点から、Lightning Experienceへの移行計画の立て方と、スムーズな移行のためのポイントを解説します。
机上の空論ではなく、実際の移行プロジェクトで得られた知見をもとに、具体的な手順とノウハウをお伝えしていきます。
移行をためらう理由はさまざまかもしれません。しかし、この記事を読み終えるころには、なぜ今、移行が必要なのか、そしてどのように進めていけばよいのかが明確になっているはずです。
Lightning Experienceが必要な理由
あるメーカーの営業部門で起きた出来事です。商談の進捗管理に時間がかかりすぎる、モバイルでの入力が使いづらい、という現場からの声が上がっていました。Classic画面での運用を続けていた結果、営業担当者は顧客先での商談記録入力を後回しにし、週末にまとめて入力する状況が常態化していたのです。
現場が抱えるClassicの課題
Classicインターフェースには、現代のビジネス環境において、いくつかの重要な制約があります。
まず、画面遷移の多さです。一つの商談データを更新するために、複数の画面を行き来する必要があります。これは単に手間がかかるだけでなく、途中で作業が中断されるリスクも高めます。
次に、データの可視化の限界です。商談のステージや金額の推移など、重要な情報が数値の羅列として表示されるため、全体像の把握に時間がかかります。特に管理職にとって、この「見えづらさ」は意思決定の遅れにつながりかねません。
Lightning Experienceで変わる日常業務
ここで、先ほどのメーカーがLightning Experienceに移行した後の変化を見てみましょう。
商談管理では、一つの画面上で必要な情報の確認から、関連するタスクの作成、メール送信まで完結できるようになりました。特に効果が大きかったのは、商談パイプラインの視覚的な管理です。ドラッグ&ドロップで商談のステージを更新でき、その場で次のアクションを記録できるようになったのです。
また、モバイル対応の強化により、営業担当者は商談直後に現場でデータを更新できるようになりました。結果として、データの鮮度が格段に向上し、上長への報告や戦略的な判断がよりスピーディに行えるようになったのです。
なぜ今、移行が急がれるのか
Salesforceは年3回のメジャーアップデートを実施しています。この更新サイクルの中で、新機能の多くはLightning Experience向けに開発されています。つまり、Classicを使い続けることは、最新の機能改善や生産性向上のツールを使えない状態が続くことを意味します。
さらに重要なのは、カスタマイズの観点です。Classic向けに開発されたカスタム機能は、時間が経つほど、Lightning Experienceへの移行時のコストが増大する傾向にあります。これは、単なる見た目の変更だけでなく、ユーザーインターフェースの設計思想自体が異なるためです。
例えば、ある金融機関では、Classic向けに開発した複雑な承認プロセスの改修に、当初の想定以上の工数が必要となりました。早期に移行を決断していれば、段階的な機能移行が可能だったケースです。
このように、Lightning Experienceへの移行は、単なるUIの刷新ではありません。ビジネスの俊敏性を高め、データ活用の可能性を広げる戦略的な取り組みとして捉える必要があるのです。
移行の準備と影響範囲の把握
Salesforce管理者として、移行プロジェクトを成功に導くためには、まず現状の利用状況を正確に把握することが重要です。ある製造業のお客様は、「思いがけないところで問題が発生して、現場が混乱してしまった」と話していました。これは事前の影響調査が十分でなかったことが原因でした。
移行準備の第一歩:Lightning Experience 準備状況チェック
Salesforceには、Lightning Experience移行の準備状況を確認するための便利なツールが用意されています。設定メニューから「Lightning Experience」>「準備状況チェック」を実行することで、現在の組織の状態を確認できます。
このレポートで特に注目すべき点は以下の3つです。
まず、Visualforceページの互換性です。Classic用に作成されたVisualforceページは、そのままではLightning Experienceで正しく表示されない可能性があります。特に、サイドバーやヘッダーを利用しているページは注意が必要です。
次に、カスタムボタンやリンクの動作確認です。JavaScriptを使用したカスタムボタンは、Lightning Experienceでは動作しないことがあります。代替機能の検討が必要になるでしょう。
そして、AppExchangeからインストールしたパッケージの互換性です。古いバージョンのパッケージは、Lightning Experience対応していない可能性があります。
具体的な影響範囲の特定方法
準備状況チェックで全体像を把握したら、次は具体的な影響範囲を特定していきます。以下の手順で進めることをお勧めします。
- 現在利用中の機能の棚卸し 「設定」の「使用状況分析」で、過去3ヶ月程度の期間で実際によく使われている機能やページを確認します。ここで、移行の影響を受ける可能性が高い機能が見えてきます。
- カスタマイズ要素の確認 カスタム項目、ページレイアウト、ワークフロールール、承認プロセスなど、カスタマイズされた要素をリストアップします。特に、複雑なビジネスロジックが組み込まれている部分は入念なテストが必要です。
- データモデルの見直し Lightning Experienceでは、関連リストやルックアップの動作が変わります。複雑な親子関係を持つオブジェクトがある場合、ユーザーの操作性に影響がないか確認が必要です。
リスク評価のポイント
移行に伴うリスクは、大きく「技術的リスク」と「運用面のリスク」に分類できます。
例えば、ある小売業のお客様では、Classic用に開発した在庫管理機能が、Lightning Experienceで動作が遅くなるという問題が発生しました。事前のパフォーマンステストで、この問題を早期に発見し、対策を講じることができました。
移行判断のための評価シートの作成
これらの調査結果をもとに、移行判断のための評価シートを作成します。以下の項目を含めることをお勧めします。
- 影響を受ける機能のリスト
- 必要な対応作業の工数見積もり
- 優先度の設定
- 想定されるリスクとその対策
- 移行スケジュールの概要
この評価シートは、経営層への説明資料としても活用できます。数値やデータに基づいた具体的な説明により、移行プロジェクトの必要性と計画の妥当性を示すことができます。
段階的な移行計画の立て方
成功している移行プロジェクトには、共通点があります。ある商社の事例では、「全社一斉に切り替えるのではなく、部門ごとに段階的に移行したことで、大きな混乱を避けることができた」と聞きます。ここでは、実践的な移行計画の立て方について説明していきます。
移行プロジェクトの3つのフェーズ
移行プロジェクトは、以下の3つのフェーズに分けて進めることをお勧めします。
準備フェーズ:土台作り
まず、移行の土台となる環境を整えます。具体的には以下の作業を行います。
開発環境でのLightning Experience有効化から始めます。この時点で重要なのは、本番環境には一切手を加えないことです。特に、プロファイルやパーミッションセットの設定は慎重に行う必要があります。
次に、最もよく使用される画面から、Lightning Experience用のページレイアウトの調整を始めます。このとき、ユーザーの動線を意識した配置を心がけます。例えば、頻繁に参照される関連リストは上部に配置するなどの工夫が効果的です。
パイロットフェーズ:小規模での検証
パイロット部門の選定が、このフェーズの成否を分けます。以下の条件を満たす部門を選びましょう。
- 業務プロセスが比較的シンプル
- 新しい機能への適応力が高い
- フィードバックを積極的に提供できる
あるメーカーでは、営業企画部門の5名からパイロットを開始し、2週間かけて問題点の洗い出しを行いました。その結果、全社展開時の重要な改善ポイントを事前に把握することができました。
全面移行フェーズ:計画的な展開
パイロットフェーズでの学びを活かし、全社展開を進めます。ここでのポイントは、部門ごとの特性に合わせた展開計画の策定です。
具体的な移行手順とタイムライン
標準的な移行スケジュールは以下のようになります。
1週目:準備フェーズ
- Lightning Experience準備状況の最終確認
- システム管理者向けトレーニング実施
- 移行手順書の作成
2~3週目:パイロットフェーズ
- パイロット部門での運用開始
- 日次でのフィードバック収集
- 問題点の改善対応
4~8週目:全面移行フェーズ
- 部門ごとの順次展開
- エンドユーザートレーニング
- ヘルプデスク体制の確立
移行時の注意点
実際の移行作業では、以下の点に特に注意が必要です。
データの整合性確認
- 移行前後でのレコード件数の確認
- 関連レコードの紐付け状態
ユーザーサポート体制
- 部門ごとのキーパーソン育成
- 質問・要望の収集窓口の設置
- よくある質問集の作成と共有
トラブルシューティング
移行中に発生しやすい問題とその対処方法をまとめておくことで、スムーズな対応が可能になります。
例えば
- ページの読み込みが遅い場合 → コンポーネントの配置や数を見直し
- カスタムボタンが機能しない → Lightning Actionへの置き換えを検討
- レポートの表示がおかしい → Lightning Experienceでの再作成を検討
このように、想定されるトラブルとその対応策を事前に整理しておくことで、実際の問題発生時に迅速な対応が可能になります。
まとめ
Lightning Experienceへの移行は、確かに大きな変更です。しかし、ここまで見てきたように、適切な準備と段階的なアプローチを取ることで、確実に実現できるプロジェクトです。
移行を成功に導くための重要なポイントを振り返っておきましょう。
第一に、現状把握の徹底です。Classic環境での利用状況を詳細に分析し、移行による影響範囲を事前に特定することで、予期せぬトラブルを防ぐことができます。
第二に、段階的なアプローチの採用です。パイロット部門での検証を通じて、実際の運用における課題を早期に発見し、対策を講じることが可能になります。
そして第三に、ユーザーサポート体制の確立です。移行はシステムの変更だけでなく、業務プロセスの見直しも含む総合的な取り組みとなります。
今後取り組むべきステップとしては、
- Lightning Experience準備状況チェックの実行
- 影響範囲の調査と評価シートの作成
- パイロット部門の選定と検証計画の立案
まずはこれらの準備作業から着手することをお勧めします。
Lightning Experienceへの移行は、決して避けて通れない道のりです。しかし、それは同時に、業務効率の向上とユーザー体験の改善という大きな価値をもたらす機会でもあります。
本記事で解説した手順とポイントを参考に、計画的な移行を進めていただければと思います。
<Salesforce>
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています!
>>セミナー一覧はこちら
また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
>>Salesforceについての詳細はこちら
>>Salesforceの導入支援実績はこちらからご覧いただけます!
医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
>>顧客管理(SFA/CRM)のコンサルティングの詳細はこちら