パフォーマンス分析のためのイベントログの参照ガイド

この記事で学べることイベントモニタリングに含まれる2種類のログを理解し、パファーマンス分析のために、確認したいケースごとにどのログのどの項目を参照することにより、ボトルネックやチューニングのポイントを確認することができるか理解できます。イベントモニタリングに含まれる2種類のログの違いイベントモニタリングライセンスには、以下2種類のログが含まれます。リアルタイムイベントモニタリング：セキュリティインシデントの発生ログとレコードへのアクセスログイベントモニタリング：イベント発生 / エラー / パフォーマンス分析用のイベントログこの2種類のログの違いの詳細については、以下の記事をご参照ください。イベントモニタリングとはここでは、パフォーマンス分析用のログとしてイベントモニタリングのログを対象に説明しています。​パフォーマンス監視の重要性生産性向上を実現するために導入したせっかくのシステムもレスポンスが悪く利用にストレスがあると利用が促進されない場合があります。パフォーマンスはシステムを利用するにあたって重要な要因です。しかしパフォーマンスは様々な要因で劣化してしまいます。例えば、大量データの取り扱い、データベースのインデックス、冗長なロジックのコード、またお客様環境においてもネットワークやクライアントの環境によってもパフォーマンス劣化が発生します。そのため継続的なパフォーマンスの監視はシステムの導入を成功に導くために重要なポイントとなります。イベントモニタリングによるログの取得多くのイベントログに要求の完了にかかった CPU 時間 (CPU_TIME)が記録されます。また、APEX実行に関するログにはデータベースのパフォーマンスに係る数値(DB_TOTAL_TIME)が記録されます。​パフォーマンスの問題が発生した際は、イベントログから要求の完了に係ったCPU時間とデータベースの処理にかかった時間を比較することで、パフォーマンス上の問題が独自のコードの部分にあるかデータベースレイヤのどちらにあるか、またはクライアント環境に起因するものか判断することが出来ます。​また、大まかに処理に時間がかかった部分を判断した上で、デバッグログの設定をしていただく事でより具体的にどの処理に時間を要したか、効率よく確認をしていく事が可能となります。​ヘルプ : デバッグログの設定取得するべきイベントログファイル以下にパフォーマンスに関する調査において参考となるイベントログファイルおよびその項目について例示をします(表中黄色いハイライト部分は、ログ対象のイベントを特定する項目です)。各イベントログファイルの内容については以下をご参照ください。​SOAP API開発ガイド：EventLogFile でサポートされているイベント種別Lightning ページビューイベント種別Lightning Experience および Salesforce モバイルアプリケーションでイベントが発生したページに関する情報を表します。Lightning ページビューイベントは、ユーザがアクセスしたページ、そのページにユーザが滞在した時間、ページの読み込み時間を追跡します。​Summer ‘22のリリースで、EFFECTIVE_PAGE_TIME_DEVIATION、EFFECTIVE_PAGE_TIME_DEVIATION_ERROR_TYPE、および EFFECTIVE_PAGE_TIME_DEVIATION_REASONの3項目が追加されました。これらの項目によりページのロードに時間がかかる原因の特定が容易になります。​項目名説明​PAGE_URLユーザが開いた最上位の Lightning Experience ページまたは Salesforce モバイルアプリケーションページの相対 URL。ページには、1 つ以上の Lightning コンポーネントを含めることができます。複数のレコード ID を PAGE_URL に関連付けることができます。​EFFECTIVE_PAGE_TIMEページを読み込んでからユーザがページの機能を操作できるようになるまでにかかった時間 (ミリ秒) を示します。実効ページ時間は、複数の要素 (ネットワーク速度、ハードウェアパフォーマンス、ページの複雑さなど) の影響を受けます。60 秒を超える有効なページ時間が検出された場合、この項目の値は null に設定されます。​EFFECTIVE_PAGE_TIME_DEVIATION逸脱が検出されると EFFECTIVE_PAGE_TIME_DEVIATION はtrueを記録します。デフォルト値はfalseです。​EFFECTIVE_PAGE_TIME_DEVIATION_REASONページ読み込み時間の逸脱の理由が記録されます。値の意味についてはLightning ページビューイベント種別からAPI version v55.0以降をご確認ください​EFFECTIVE_PAGE_TIME_DEVIATION_ERROR_TYPEこのフィールドはEFFECTIVE_PAGE_TIME_DEVIATION_REASONにPAGE_HAS_ERRORが記録された場合に入力されます。入力されうる値はCUSTOMまたはSYSTEMとなります。・CUSTOM ： 顧客システムまたはネットワークに起因するエラー・SYSTEM ： セールスフォースに起因するエラーLightning パフォーマンスイベント種別Lightning Experience および Salesforce モバイルアプリケーションのパフォーマンスのトレンドを追跡します。レコードに対するユーザアクションに関する所要時間が把握できます。​項目名説明​UI_EVENT_SOURCEレコードに対するユーザアクション(作成/編集/削除/参照など)。この項目の値は、ユーザのアクションが 1 つのレコードに対して実行されたか複数のレコードに対して実行されたかを示します。たとえば、read は (レコード詳細ページなどで) 1 つのレコードが参照されたことを示し、reads は (リストビューなどで) 複数のレコードが参照されたことを示します。​DURATIONページ開始時刻からの時間 (ミリ秒)。Apex 実行イベント種別実行された Apex クラスに関する詳細が含まれます。​項目名説明​URI要求を受信しているページの URI。​NUMBER_SOQL_QUERIESイベント中に実行された SOQL クエリ数。​IS_LONG_RUNNING_REQUEST要求が実行時間が長い組織の同時 Apex 要求の上限にカウントされるか (true)、否か (false) を示します。​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU使用率にカウントされません。​DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。​EXEC_TIMEエンドツーエンドの Apex 実行時間 (単位: ミリ秒)。​RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。Apex REST APIイベント種別すべての Apex REST API 要求に関する情報を取得します。​項目名説明​​​URI要求を受信しているページの URI。​​​ROWS_PROCESSED要求で処理された行数。​​​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU使用率にカウントされません。​​​DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されているアクティビティ量を示します。​​​DB_BLOCKSデータベースで発生しているアクティビティ量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。​​​DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。​​​RUN_TIME要求にかかった時間 (ミリ秒単位)。​​Apex SOAP イベント種別Web サービス API コールに関する詳細が含まれます。​項目名説明​CLASS_NAMEApex クラス名。クラスが管理パッケージの一部である場合、この文字列にはパッケージ名前空間が含まれます。​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。​DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。​RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。Apex トリガイベント種別組織で起動されたApexトリガに関する詳細が含まれます。​項目名説明​TRIGGER_ID起動されたトリガの 15 文字の ID。​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。​DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。​EXEC_TIMEエンドツーエンドの Apex 実行時間 (単位: ミリ秒)。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。​RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。非同期レポート実行イベント種別非同期レポート実行イベントは、スケジュールされたレポート要求に対して作成されます。このカテゴリには、ダッシュボードの更新、非同期レポート、スケジュールレポート、分析スナップショットが含まれます。​​項目名説明​REPORT_ID実行されたレポートの 15 文字の ID。​ROW_COUNT非同期レポート実行イベントで処理された行数。​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。​DB_BLOCKSデータベースで発生している活動量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。​DB_TOTAL_TIME要求のすべての操作について、データベース処理の待機にかかった時間の集計 (ミリ秒)。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。​RUN_TIME要求にかかった時間 (ミリ秒単位)。要求の値が 5 秒を超える場合、同時長時間実行の Apex 制限により、長時間実行の要求と見なされます。Salesforce/第三者へのリクエストにかかる時間で、HTTPコールアウト、REST/SOAPコールなどが含まれる場合があります。実行時間が長い同時 Apex 制限イベント種別組織の同時実行制限に達した後に Salesforce によって終了された、組織内の実行時間が長い同時 Apex 要求に関する情報が含まれます。確立された Apex コンテキストが 5 秒間実行される要求は、実行時間が長い同時要求の組織の制限に含まれます (非同期要求は制限に含まれません)。実行時間が長い要求数が 10 (組織のデフォルトの制限) を超えた場合、その他の実行時間が長い要求は終了されます。​項目名説明​REQUEST_URISalesforce によって終了された実行時間が長い Apex 要求の URI。継続コールアウトサマリーイベント種別トランザクション中に実行されたすべての非同期コールアウト、その応答状況コード、実行時間、および対象の URL エンドポイントに関する情報が含まれます。​項目名説明​URLコールアウトエンドポイント URL。継続で使用された HTTP 要求数によっては、この項目に最大 3 個のスペース区切り値が含まれる可能性があります。​DURATION合計継続時間 (ミリ秒)。外部のカスタム Apex コールアウトイベント種別Salesforce Connect のカスタムアダプタを介した外部データコールアウトを表します。​項目名説明​ENTITYアクセスされる外部オブジェクトの名前。​ACTIONコールアウトによって実行されるアクション(query/upsert/delete)。​ROWS_FETCHEDコールアウトによって取得された行の数​ROWS結果セットの総レコード数​FETCH_MS外部システムからクエリ結果を取得するのに要した時間 (ミリ秒)。​THROUGHPUT1 秒間で取得されたレコード数。​EXECUTE_MSSalesforce がクエリの準備および実行に要した時間 (ミリ秒)。​TOTAL_MSクエリの準備、実行、およびクエリ結果の取得に要した時間 (ミリ秒)外部の OData コールアウトイベント種別Salesforce Connect の OData 2.0 および OData 4.0 アダプタを介した外部データコールアウトを表します。​項目名説明​ENTITYアクセスされる外部オブジェクトの名前。​ACTIONコールアウトによって実行されるアクション(query/upsert/delete)。​ROWS_FETCHEDコールアウトによって取得されたレコードの数。コールアウトによって取得されたレコードは、大きな結果セットのサブセットである場合があります​ROWS結果セットの総レコード数​FETCH_MS外部システムからクエリ結果を取得するのに要した時間 (ミリ秒)​THROUGHPUT1 秒間で取得されたレコード数。​EXECUTE_MSSalesforce がクエリの準備および実行に要した時間 (ミリ秒)​TOTAL_MSクエリの準備、実行、およびクエリ結果の取得に要した時間 (ミリ秒)レポートイベント種別ユーザがレポートを実行したときの動作に関する情報が含まれます。このイベント種別には、レポートのエクスポートイベント種別のすべての活動とその他の活動が含まれます。​項目名説明​REPORT_ID実行されたレポートの 15 文字の ID。​ROW_COUNTレポートイベントで処理された行数。行数が多く、かつ AVERAGE_ROW_SIZE も大きい場合は、ユーザが詐欺目的で情報をダウンロードしている可能性があります。たとえば、競合他社に転職する前にすべてのセールスリードをダウンロードする営業担当などがこれに該当します。​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。​DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されている活動量を示します。​DB_BLOCKSデータベースで発生しているアクティビティ量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。​DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。​RUN_TIME要求にかかった時間 (ミリ秒単位)。フロー実行イベント種別合計実行時間、インタビューの数、エラーの数などの詳細を含む、実行されたフローに関する情報が含まれます。​項目名説明​FLOW_VERSION_ID実行されたフローバージョンの ID。​FLOW_LOAD_TIMEフローのメタデータの読み込みにかかった時間 (ミリ秒単位)。​TOTAL_EXECUTION_TIMEすべてのフローインタビューの開始と終了にかかった合計時間 (ミリ秒単位)。Wave パフォーマンスイベント種別Analytics パフォーマンスのトレンドを追跡するのに役立ちます。​項目名説明​RECORD_IDTableau CRM オブジェクトの Salesforce ID。​TAB_IDユーザインターフェースの特定の [分析] タブの ID。​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。​RUN_TIME要求にかかった時間 (ミリ秒単位)。​EPT体験ページ時間 (ミリ秒単位)。Visualforce 要求イベント種別Visualforce 要求に関する詳細が含まれます。要求はブラウザ (UI) から実行できます。​項目名説明​PAGE_NAME要求された Visualforce ページの名前。​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。​DB_CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。要求時にデータベースレイヤで実行されている活動量を示します。​DB_BLOCKSデータベースで発生している活動量を示します。この項目の値が高い場合、クエリにインデックスまたは検索条件を追加するとパフォーマンスが向上します。​DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。​RUN_TIME要求にかかった時間 (ミリ秒単位)。コンソールイベント種別Salesforce コンソールのパフォーマンスと使用に関する情報が含まれます。サイドバーコンポーネントで [コンソール] タブが開かれるたびに、コンソールイベントがログに記録されます。それ以外は、Salesforce Classic の場合と同様に、[コンソール] タブが開かれると、通常のレコードの詳細の表示イベントが記録されます。​項目名説明​COMPONENT_IDコンポーネントの 15 文字の ID。​CONSOLE_IDコンソールの 15 文字の ID。​RECORD_IDコンソールに関連付けられたレコードの 15 文字の ID。​CPU_TIME要求の完了にかかった CPU 時間 (ミリ秒単位)。この項目は、アプリケーションサーバレイヤで実行されているアクティビティ量を示します。DMLの実行中には、レコードロックや処理中のレコードのロック解除待ち、apexコードのコンパイルなど、（開発者が制御できない）他の動作が行われます。この時間はすべて、CPU時間にカウントされません。​DB_TOTAL_TIMEデータベース往復処理の時間 (ナノ秒単位)。JDBC ドライバー、データベースへのネットワーク、および DB_CPU_TIME で費やされた時間を含みます。この項目を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤと独自のコードのどちらで発生しているかを判断します。​RUN_TIME要求にかかった時間 (ミリ秒単位)。学習ツールSOAP API開発ガイド：EventLogFile でサポートされているイベント種別ヘルプ : デバッグログの設定トレイルヘッド：Lightning Experience のパフォーマンスの最適化ヘルプ：技術要件とパフォーマンスのベストプラクティスまとめパフォーマンス分析に関するログは、イベントモニタリングのログに記録され、対象のログと項目を確認することにより、パフォーマンス問題がどこで発生しているのか、またどこがボトルネックになっているのか確認することができます。この記事で学べることイベントモニタリングに含まれる2種類のログを理解し、パファーマンス分析のために、確認したいケースごとにどのログのどの項目を参照することにより、ボトルネックやチューニングのポイントを確認することができるか理解できます。​

連載：『営業改革のコンパス～規模に応じたトランスフォーメーションの最適設計～』vol.11

前回Vol. 10 に続いて、上記の図「営業改革プロジェクトの標準的なプロセス」からステップ2 チーム結成・メンバーの選定以降を解説していきます。ステップ2 チームの結成・メンバーの選定 「営業が強い」とされる組織であればあるほど、経営者や営業担当役員など上層部が強い意志を持って、オーナーとして関与しない限り、改革をやり遂げられません。実際、「営業改革を実施する」と号令を発するプロジェクト・オーナーは、経営トップや役員が多いようです。​その後、多くの企業では経営企画部や営業推進部からプロジェクト・リーダーやメンバーが選出され、プロジェクト・チームが作られます。メンバーは専任で選ばれる場合もあれば、兼任の場合もあります。理想的なのはメンバーがプロジェクトに専念できる形ですが、コアメンバーでない限り、兼任メンバーとして各部門長やリーダーが集まり、営業改革の具体的な方向性を議論し、現場浸透を推進する役割を担うことが多いのが実態です。​営業改革のコアメンバーは5名ほどで、10名を超える企業はまれです。なお、兼任者がプロジェクトにかけている工数は、だいたい1週間に6時間程度（2時間×3日、もしくは3時間×2日）で、数カ月続けることが多いようです。この中で、営業業務の調査・整理、営業プロセスの作成やフェーズの定義、トレーニング計画の立案などをおこなっています。​では、具体的にどのような人物がチーム・メンバーに選定されているのでしょうか。プロジェクトや営業現場の経験があるか、ITリテラシーや分析能力はどうかなど、さまざまな選定基準が考えられますが、多数のプロジェクトを見る中で、成功している事例には次のような特徴が見られました。​まず、プロジェクト・リーダーですが、力強く周囲を巻き込んでいくタイプ、淡々と仕事を進めるタイプ、現場に積極的に出ていくタイプ、メンバーの後ろで見守るタイプなど、リーダーシップスタイルそのものは千差万別でした。ただ、共通するのは「絶対に成功させるんだ」という熱い思いを持ち、ブレない強さを持っていること。どのプロジェクト・リーダーも、現場の反発やITシステムのトラブルなどの諸問題に直面したときに、メンバー任せにするといった中途半端な対応をとらず、日々現場で顧客を相手に頑張っている営業担当者の立場で考え、優先順位を決めて行動していました。ステップ3 方針決定、ビジョンやゴールの設定、価値観のすり合わせプロジェクトの重要なポイントとなるのが、「方針決定、ビジョンやゴールの設定、価値観のすり合わせ」です。ここがまさに改革方針の決定段階であり、営業改革をすることで、「具体的にどのような営業スタイルになるのか」「これまでできなかった何が実現できるようになるのか」「自分たちにどのようなメリットがあるのか」を明確にしていきます。​改革方針は企業の置かれた状況によって大きく変わってくるでしょう。プロジェクト発足のきっかけは似たようなものであったとしても、改革の方針や道筋は企業によってさまざまだと思います。基本的な「見える化」と呼ばれる営業現場の透明性の確保については、どの企業も最初にあたりまえのように出てくるキーワードですが、業界内の順位、顧客からの評価、ビジネスモデル、自社特有の営業風土やこれまでの取り組みの歴史によってその後のアプローチは変わってきます。自社の営業はどうあるべきなのか、そのために必要なスキルはなんなのか、数年後の自社の営業像をすり合わせます。まさに新たな営業部門の「価値観」が決められる段階です。​この段階で行ういくつかの施策をご紹介します。​・顧客インタビュー改革の方向性のヒントは顧客にあります。これまで長期にわたって取引をしていただいている顧客や、つい最近取引を開始していただいた顧客、逆に離れてしまった顧客などに、「なぜ自社を選んだのか」「改善点はどこか」「営業に求めることはどのようなところがあるのか」をヒアリングしていきます。​・営業現場のインタビューと業務調査営業現場のインタビューと業務調査の目的は大きく２つ。「業務の実態を把握し、改善点を見つけること」で現在の営業担当者やマネージャーの業務を実態調査、改善策につなげる。「現場のリーダーを見つけること」で改革を進めていく中で力になってくれる候補をリストアップしていきます。​・ビジョン設定を目的としたワークショップ顧客インタビューや営業現場のインタビューと業務調査の後は、あるべき営業の姿や新しい業務フローなどを作る過程に入ります。この段階で現場を巻き込んだワークショップ形式で新しいアイデアを集めることをお勧めいたします。​ワークショップにはたくさんのやり方がありますが、ここでは重要と思われるワークショップをご紹介します。​ワークショップ1：カスタマージャーニーマップワークショップ顧客視点で自社のWebサイトや提案書を見てみると、改善すべき顧客との接点や、スピード感が足りない所などがわかります。営業として顧客に対面する前の段階で、顧客はどのように自社を見ているのかをあらためて見直すきっかけにもなるでしょう。​ワークショップ2：営業プロセスの標準化、フェーズ作成ワークショップ顧客の立場になって自社を見つめた後は、自社の業務フローや営業プロセスについて考えます。「新規顧客と既存顧客」「直接販売と間接販売」などで考慮すべき点があれば、そのフローや注意点を書き出します。その上で案件のフェーズと確認項目を決めます。その内容は営業マニュアルを作成する際に活用し、ある程度の期間実行した後に現場の意見を反映しながら修正していきます。​ワークショップ3：KPIダッシュボード作成ワークショップ営業部門が新しい営業スタイルを実行し、きちんと結果に結びついているかを確認するのがダッシュボードです。いわゆる分析ツールで、経営者向け、営業マネージャー向け、営業担当者向けなどに最適化することができ、目標の達成状況や、抜け漏れなどを確認することが可能になります。​・営業の業務整理、ルールの作成、その他ワークショップの結果を反映した業務フロー図の作成を行います。最終的に、「営業がやるべき仕事とそうでない仕事」「新しい組織構成」などにも踏み込む必要があるでしょう。事例で取り上げた企業では、かなりの割合でこの業務整理を行い、営業から事務作業を減らし、顧客への時間を増やしていました。​次回は、営業改革プロジェクト ステップ④情報プラットフォーム（ITシステム）選定以降について解説していきます。公開は10/18（木）を予定しております。​​著者：田崎純一郎（たさき じゅんいちろう）セールスフォース・ドットコムセールスイネーブルメントシニアディレクター​————————————————完全版eBookをダウンロード提供中本連載『営業改革のコンパス～規模に応じたトランスフォーメーションの最適設計～』第3章（Vol. 10〜13の記事）は、完全版のeBookにまとめています。ぜひ、下記からダウンロードしてお読みください。【 第3章 ダウンロードはこちら 】​Vol. 6～9の記事は第2章の内容になります。第2章のeBookにて完全版を公開しております。ぜひ、下記からダウンロードしてお読みください。【 第2章 ダウンロードはこちら 】​​Vol. 1〜5の記事は第1章の内容になります。eBookにて完全版を公開しております。ぜひ、下記からダウンロードしてお読みください。【 第1章 ダウンロードはこちら 】​連載記事＜第1章＞Vol. 1 営業改革で解決したい課題は何か - 営業組織の規模と営業改革テーマVol. 2 営業マネジメント50人の壁 ― 営業支援システムの導入率からみる営業組織の課題Vol. 3 営業組織の規模によって異なる課題感 ― データの収集と活用Vol. 4 現場が見えなくなる中規模組織Vol. 5 使いこなせていない51名以上の営業組織は「営業案件の可視化やパイプライン管理ができていない」​＜第2章＞Vol. 6 営業活動は不完全情報ゲームVol. 7 営業を“群衆”ではなく“組織”に -情報を使って160時間の使い方を最適化Vol. 8 営業情報は製品中心ではなく「顧客データを中心」にフロントとバックをつなげるVol. 9 作ったものを売る営業から、売れるものを作る会社へ​＜第3章＞Vol. 10 営業改革プロジェクトでは、どんな困難に直面するのか？Vol. 12 情報プラットフォーム（ITシステム）選定 ～ 組織変更の実施、教育・社内トレーニングVol. 13 KPI、データ分析と活用 ～ 定着化と展開​＜関連セミナーご案内＞Salesforceでは、営業改革をサポートするウェブセミナーをご用意しています。あらゆる企業規模・業界において営業マネージャーの方々がどのようにSalesforceを活用すべきかをご紹介します。ぜひご活用ください。https://successjp.salesforce.com/article/NAI-000042

レポート・ドリル（ホーム）

Salesforceのレポートのスキルを身につけるには実践あるのみ。色々なレポートの作り方をマスターできるドリルをご用意しました。これをやればレポートマスター間違いなしです。是非ご活用ください！レポートを表示するレポートの表示を変更するすべての取引先を抽出するすべての取引先レポートの表示列に業種項目を追加する、表示列から評価項目を削除する列を取引先/都道府県（請求先）/作成日の順に並び替える複数行のデータを作成日を基に降順に並び替えるデータを絞り込む検索条件を指定してデータを絞り込む私が担当する取引先を抽出する作成日が今年の取引先を抽出する作成日が2019年1月10日から2019年3月10日の取引先を表示する都道府県(請求先)が東京都の取引先を抽出する都道府県(請求先)が東京都と神奈川県の取引先を表示する電話番号が03から始まる取引先を抽出する都道府県(請求先)が東京都と神奈川県で、電話番号が03から始まる取引先を抽出するレポートの実行画面上で条件に都道府県(請求先)が神奈川県の取引先を追加する検索条件で「または」「かつ」を使用してデータを絞り込む都道府県(請求先)が東京都または電話番号が03から始まる取引先を抽出する都道府県(請求先)が東京都かつ電話番号が03から始まるか、都道府県(請求先)が大阪府の取引先を表示する日付情報を使用してデータを絞り込む過去1週間のうちに更新された取引先を抽出する先月に更新された取引先を抽出する今年に入って更新されていない取引先を抽出する値が空白「である」「でない」条件を使用してデータを絞り込む電話番号が入力されていない取引先を抽出する電話番号に何らかの値が入力されている取引先を抽出する関連レコードの有無によってデータを絞り込む今月作成された活動がある(=紐づく)取引先だけを抽出する活動が1件もない(=紐付かない)取引先だけを抽出するデータをまとめるグループ化してレポートを見やすくする商談の完了予定日ごとにグルーピングする完了予定日と商談所有者で商談をグルーピングする完了予定日ごとにグルーピング後、集計期間を日付から年月形式(yyyy年mm月)に変更するグループ化して集計する完了予定日で年月にグルーピング後、各年月の合計金額を集計する完了予定日とフェーズでグルーピングし、各年月ごとフェーズごとの合計金額を集計する完了予定日で年月にグルーピング後、各年月の受注金額の最大値を集計する完了予定日で年月にグルーピング後、完了商談に占める成立/不成立商談の件数を集計する列を商談所有者、行を完了予定日でグルーピングして商談金額の合計を集計後、レコード件数を非表示にする完了予定日が2018年と2019年の商談を使用し、成立商談(=受注商談)の合計金額を同月比較できるようにグルーピングを工夫する行と列でグループ化する行を商談所有者、列を完了予定日でグルーピングして商談件数を集計する行を商談所有者と成立フラグ、列を完了予定日でグルーピングして商談件数を集計する行を所有者ロールと商談所有者、列を完了予定日と成立フラグでグルーピングして商談件数を集計する列を所有者ロールと商談所有者、行を完了予定日でグルーピングして成立件数と成立金額の合計を集計するグループ化した集計値同士で計算する商談所有者ごとの成約率（=成約商談件数/完了商談件数）を算出する商談所有者とフェーズで商談をグルーピング後、商談の合計金額を集計する。各フェーズの金額が、その所有者の合計金額に占める割合を算出する完了予定日が2018年と2019年の商談を使用し、成立商談(=受注商談)の合計金額の前年同月比を算出するバケット項目を使用して柔軟にグループ化する取引先の都道府県(請求先)を8地方区分にグルーピングする取引先の都道府県(請求先)を関東地方とその他にグルーピングする取引先の従業員が2000名以上を大企業、2000名未満をその他にグルーピングする商談の金額を0-50万/50万-100万/100万-200万/200万以上にグルーピングする商談のフェーズ1/2/3を商談初期、4以降をその他にグルーピングするグラフを使用する作成したレポートをグラフで表示する取引先所有者ごとの取引先件数(=レコード数)を積み上げ縦棒グラフで表示する。また取引先を都道府県(請求先)ごとに色分けする取引先所有者ごとの取引先件数(=レコード数)を縦棒グラフで表示する。また任意の値かつ赤色で基準線を表示する商談所有者ごとの商談件数(=レコード数)を縦棒グラフで表示する。また商談の金額を折れ線グラフとして追加する商談所有者で商談をグルーピングする。また商談の合計金額が50万円以下を赤、100万円以下を黄、それ以上を緑で表示する取引先所有者で取引先をグルーピングする。実行したレポートをダッシュボードに追加するその他の機能を使用する作成したレポートを別名でコピーする取引先所有者で取引先をグルーピングする。実行したレポートを別名保存する作成したレポートをエクスポートする取引先所有者で取引先をグルーピングする。実行したレポートをExcel形式でエクスポートする作成したレポートを定期的にメール配信する取引先所有者で取引先をグルーピングする。実行したレポートが毎週月曜日の午前9時に自分に配信されるように登録する​​レポートドリル（Quip版）はこちら​レポート作成の応用編として『レポートを使いこなす裏ワザ 総集編』が公開されました。同タイトルの人気記事シリーズをわかりやすくまとめた資料です。ぜひお役立てください。

バージョンアップに備えましょう

https://play.vidyard.com/2ws17oUCrGYkdTDs4vJfRv動画で紹介した各リンクは以下よりご確認いただけますSandbox プレビュー（ナレッジ）はこちらCSG公式XアカウントはこちらSalesforceの運用に関する重要なお知らせ（サクセスナビ記事）はこちら新機能Trailblazers分科会「リリースノートと仲良くなろう！読み方のコツ」はこちらオンラインコミュニティ「新機能Trailblazers分科会」へ遷移します。ご利用のSalesforceユーザーID・パスワードによるログインが必要です。「新機能Trailblazers分科会」にご参加いただいていない方は、ログイン後こちらから参加申請をお願いします。この記事で学べること次期バージョンアップに備える方法について知ることができますリリースノートの読み方のポイントを知ることができますSalesforceのバージョンアップって何？みなさまは、Salesforceのバージョンアップ（メジャーリリースと呼ばれる事もあります）について、ご存知ですか？普段の生活で、おそらく頻繁に利用しているインターネットの検索画面やカレンダーの画面などが突然変わる事に気づいた経験はあると思います。それと同じように、Salesforceも定期的に（年3回）バージョンアップ（進化）しています。例えば、2023年6月6日時点のバージョンは、Spring’23 でした。次のバージョンアップ（2023年6月11日）で、Summer'23になります。Salesforceを昔からご利用のお客様は、Classicの画面をご存知だと思います。Classicの時は、画面左上にロゴが表示されていたので、「あ。ロゴが変わった。バージョンが変わったのかな」と気付くこともあったかもしれません。Classicはこんな感じでした。懐かしいですね！Lightning Experienceでは、ログイン後、ホーム画面が表示される前にロゴが表示されるように変わりました。​「知らないうちにバージョンアップが行われているなんて、何事だ！！」と怒らないでください。バージョンアップの日程は、バージョンアップの約1年前からTrust サイトのシステム状況ページ に公開されています。（詳細は、Salesforceのメンテナンスを知ろうをご確認ください）Sandboxプレビューって何？Salesforceには、年3回バージョンアップがあることをご紹介しましたが、じゃあ「どんな新機能が出てくるのか？」「便利になるのか？」「自分たちが使っている機能に影響はあるか？」など、色々事前に知りたいことがあると思います。​システム管理者の方であれば、ユーザから「なんか画面変わりました・・・？」と聞かれて、慌てて調べる・・・という状況は避けたいですよね？​Sandboxプレビューは、本番環境がバージョンアップをする前に、事前にプレビューができるサービスのことです。Sandboxプレビューの詳細については、Sandbox プレビューによる早期アクセス（Trailhead）をご確認くださいプレビューで何するの？じゃあ、プレビューでは、具体的に何ができる/何をすればいいのでしょうか。プレビューに参加する目的バージョンアップでは、新しい機能が追加されたり、既存機能が拡張されたりします。契約している製品に関する情報をリリースノートで確認して、実際の業務で使えそうな便利機能があれば事前に動作確認ができます。使い方の説明動画や資料を作成し、事前にユーザに共有することもできますね！​また、開発をしている組織のシステム管理者の方は、バージョンアップ後に自分たちが開発した機能がきちんと動くか気になると思います。そんな時は、プレビュー対象のインスタンスにSandboxを作成しておく（※）ことで、本番のバージョンアップ前に、お客様が開発した機能の動作の事前検証を行っていただくことができるのです！​（※）Sandboxプレビューの詳細については、システム管理者宛の製品コミュニケーションメールでお知らせします。製品コミュニケーションについては、製品およびサービスに関するお知らせ（ナレッジ）をご確認ください。 Salesforceでは事前検証していないの？Salesforceでは、本番環境のバージョンアップ前に各種テストに加えて、 Apex ハンマーというプロセスによってすべての Apex テストを自動的に実行します。（ハンマープロセスは組織を選択して実行するため、すべての組織で実行されるわけではありません）Salesforceでは、バージョンアップ前に、検出されたすべての問題を修正するよう努めています。詳細は、Apex 単体テストの開始（Trailhead）をご確認ください。お客様によるテストが必要な理由お客様固有の開発がバージョンアップの影響を受けていないか/想定どおりの動作をしているかを確認できるのは、お客様しかいません！テストをする際は、業務をする上で特に重要な機能を優先して確認をすることを推奨します。​テストが必要な開発の例：Apexクラス、トリガ、Visualforceページ、Lightningコンポーネント、外部システムとの連携機能などテストで問題が見つかった場合は、同様の問題が既に報告されていないかをKnown Issuesサイトで確認します。同様の問題が無い場合は、早めに弊社テクニカルサポートへお問い合わせをいただくことで、本番環境がバージョンアップする前に対応ができる可能性が高くなります。​※お問い合わせを頂く際は、事前に、その問題がSalesforceのバージョンアップによるものか、お客様のカスタムコードによるものかの切り分けをしていただけますよう、お願いします。詳細は、お問い合わせをする時のポイント （サクセスナビ）をご確認ください。​さて、開発をしている組織にとって、Sandboxプレビュー期間を活用した事前テストが重要である点について、ご理解いただけましたでしょうか。​ここからは、事前テストをする上で欠かせないリリースノートの読み方についてご紹介します。開発をしていない組織のシステム管理者の方も、リリースノートを参照して、便利な機能がないか確認しましょう！リリースノートの読み方Salesforceのバージョンアップ毎に公開されるリリースノートでは、製品の機能強化や新機能について簡潔に説明しています。リリースノートの種類リリースノートには、HTML 版とPDF 版があります。HTML版：検索や絞り込みで、必要な情報に最短でたどり着くことができます。また、使用される言語はブラウザの設定によって決まります。言語を変更するには、下部にスクロールして [言語を変更] をクリックし、言語を選択します。​PDF版：全体を俯瞰して確認することができます。iPadなどのタブレットにダウンロードして、読書のような感覚でページをめくりながら新しい機能を探したいときにいいですね。​HTML版の場合、以下で絞り込みができます環境Salesforce ClassicLightning ExperienceモバイルエディションEnterprise EditionUnlimited Edition など機能の影響有効（ユーザ）有効（システム管理者/開発者）システム管理者が有効化する必要ありSalesforceに連絡して有効化製品エリアセールスサービス などリリースノートに記載されている機能はすべて自動で使えるようになりますか？いいえ。機能毎に異なります。バージョンアップ直後に自動で（すべてのユーザ、もしくはシステム管理者や開発者のみに対して）有効化されて使えるようになるものもあれば、（ユーザが使えるようにするために）システム管理者が手動で有効化しなければならないもの、機能を有効化するためにサポートへご連絡を頂く必要があるものなどがあります。これらの情報はリリースノートの機能が使用可能になる方法と状況に纏められています。​なお、機能によっては、バージョンアップ（直後ではなく）徐々に機能が有効化されて使えるようになるものもあります。その場合、対象機能のリリースノート詳細画面にその旨記載されます。リリースノートの日本語版リリースノートは、ほぼ毎週のように更新されており、更新内容はリリースノートの変更に追記されます。中にはリリース予定の機能の延期や（リリースノート公開時点では記載がなかった）新機能が追加されたり、機能に関する説明が追加されたりすることがあります。順次翻訳されますが、最新情報は英語のリリースノートを確認するようにしてください。※リリースノートの更新情報は、「Salesforce の運用に関する重要なお知らせ」（サクセスナビ）の中で、重要なものを抜粋してお知らせしていますので、ぜひご覧ください。リリースノートの内容リリースノートは、以下のような構成になっています。Salesforceをご利用中のすべてのお客様に関係する内容（みなさまにご覧頂きたい内容です）サポートされるブラウザSalesforce 全体 など製品/機能毎の内容（ご契約/ご利用中の製品/機能をご確認ください）Analyticsコマースカスタマイズ などリリース更新（みなさまにご覧頂きたい内容です）セキュリティに関する情報を含んでおり、期限が来ると強制的に有効化されるものがあります。リリースノートの使い方リリースノートのボリュームは年々増加しており、そのすべてを確認することは、日々の業務で多忙なシステム管理者のみなさまにとっては難しいと思います。​まずは、上記太字にある（みなさまにご覧頂きたい内容）と（ご契約/ご利用中の製品/機能）について確認をしてください。その際、不明点が出てきたら、弊社テクニカルサポートへお問い合わせいただくことで理解の促進にお役立ていただくことができます。​また、「知らないだけで、何か活用出来る機能は無いか確認したい」という場合は、機能が使用可能になる方法と状況から探して頂くのがお薦めです。機能が使用可能になる方法と状況には、提供予定の機能がリリースノートの構成に沿って纏まっています。そのため、自分でリリースノートを検索しようにも、「どのようなキーワードで検索すればよいかわからない」という方に最適です。一覧から興味のある機能や聞いたことがある機能を見つけたら、リンクをクリックして詳細説明を確認します。そして、「実際に試してみたい！」という時には、プレビュー中のSandboxでテストをすることができます！リリースノートの確認ポイントサポートされるブラウザSalesforceを利用するためにはブラウザが必要です。自社で利用しているブラウザが記載されているか（引き続きサポート対象であるかを）確認します。Salesforce全体すべてのユーザが毎日使っているであろう「検索」や（契約製品関わらず）使うと便利な「Salesforceアンケート」や「Your Accountアプリケーション」といったSalesforceのオススメ機能の更新情報が含まれます。未使用の便利機能が見つかる可能性がありますので、ぜひチェックしてみてください。AnalyticsAnalyticsには、「CRM Analytics」に関する情報だけでなく、みなさまお使いの「レポートとダッシュボード」の情報も含まれます。こちらも必見の内容です。カスタマイズ（コーディング不要な）ポイント＆クリックでカスタマイズできる設定（「Lightningアプリケーションビルダー」など）が含まれます。こちらも多くのお客様にてご利用いただいている（Salesforceとしてもご活用いただきたい）機能に関する情報のため、確認することをおすすめします。開発Lightningコンポーネント、Apex、API、Sandboxなど、開発をしている場合は必見です。この情報と[リリース更新]を元に既存の開発機能に影響するものはないか確認し、テストを行います。モバイルモバイルアプリケーションやMobile Publisherをご利用のお客様はご確認ください。リリース更新特定の時期に強制的に適用される変更や設定変更の情報を記載しており、必読です。セキュリティ・性能・操作性に関わるデフォルト動作の変更や設定変更が含まれるため、[テスト実行]に対応している更新については、事前にSandbox環境で有効化し、その変更が自組織に与える影響範囲の確認をなるべく早めに実施することを推奨します。学習ツールSalesforce リリース準備状況戦略（Trailhead）Advanced Salesforce Release Readiness Strategies（Trailhead）メジャーリリースにおけるテストの考え方（Trailblazer Community）まとめ（チェックリスト）開発をしている場合に、本番環境のバージョンアップ前に、Sandboxプレビューを活用し、事前にテストをすることの重要性を理解しました。リリースノートをすべて確認するのは困難なので、すべてのお客様に共通する内容、現在使用している製品や機能に関する内容、リリース更新を中心に確認しましょう​

Salesforceへ安全にアクセスするために知っておくべき情報〜多要素認証

最終更新日:2022/6/08​昨年来の働き方改革や昨今のウィズコロナ時代のリモートワークの増加など、これまでと違った条件下での業務遂行を必要とされる声をあちこちで伺う機会が増えてきました。​これまでの就業環境と変わることで関心が高まっているのが「 Salesforce への安全なアクセス」。特にサイバーセキュリティに関わる事案やニュースを日本でも目にする機会が増えてきており「安全性と利便性を確立する上で Salesforce で何ができるのか？」そんなご質問も増えてきている実感があります。​そこで今回システム管理者の皆さまに、安全なアクセスを実現するために知っておいていただきたい情報をまとめました。ぜひこちらのサイトを定期的にご確認いただき、安全で安心できる業務環境を構築していきましょう。1.安全なアクセスを実現するための Salesforce とお客様の役割Salesforce に対する安全なアクセスと一言でいっても、その安全なアクセスは製品として何ができるのかなどの「提供されているもの」と、その製品をどう使うのかなど「提供されているものをどう使うか」の視点は欠かせません。この視点を、Salesforce が責任を持って提供すべきものと、お客様が責任を持って確認・判断・実行すべきもの、で表現したのが「Salesforceのセキュリティパートナーシップ」です。Salesforce がその提供する製品において安全なアクセスを実現するための機能を提供し、その機能の利用を判断いただけるような情報を提供し、ある場合にはその機能を標準設定(デフォルト)として提供するなどの提供者としての責任を果たしつつ、お客さまにおいて、それぞれのコンプライアンス基準やセキュリティ基準に準拠した機能を検討・適用・監視・維持していただく活動を通じて、始めて持続的な安全なアクセス環境が実現できる。そんな相互の協力が不可欠な取り組みを表現しています。​2.境界防御の先にあるクラウド時代のセキュリティを考慮する [*2] [*3][*4]昨今のサイバー攻撃の方法の多様化や範囲の拡大の影響を考えると、最新のセキュリティ制御機能の理解と評価がお客さまにとってセキュリティ管理の上で重要性を増していることは間違いありません。特に業務システムのクラウドシフトが進むにつれて、従来の境界防御モデル (Firewall や VPN などで「信頼できる接続」によって社内・社外の境界を設けて、不正侵入や情報漏えいを防ぐモデル)だけでは安全性を担保しきれない環境に変わりつつあります。海外では今年 4 月に米国東海岸の 45％ の住民に燃料を供給するパイプラインの操業がハッキングにより停止に追い込まれる事例が発生し、日本でもランサムウェアや VPN 環境での情報漏えいなど境界防御だけでは防ぎきれない事例が報告され始めています。この「すべてのユーザ・デバイス・アプリケーション・ネットワークが安全と言えず攻撃される可能性がある」状況に対応する「ゼロトラストモデル」が提唱され、それぞれの要素が脅威にさらされている前提でその防御のための対策が注目され始めており、Salesforce ではその対策要素の一つである IAM(Identity and Access Management) の強化を通じてお客さまに安全なアクセス環境を提供する取り組みを推進しており、その具体的な施策として多要素認証 (MFA : Multi Factor Authentication) の適用を利用規約上必須とし、推進しています。 この取組みの重要性は Salesforce とお客さまだけの関係において重要というものではなく「お客さまの顧客」、例えばCommunity Cloud や Commerce Cloud を通じて提供しているサービス利用者にあたる「お客さまの顧客やパートナー」向けにも安全性と利便性を両立したサービスを提供する手段として注目され始めています。​また、多要素認証の推進については Salesforce の外に目を向けても、世間のトレンドとなりつつあります。例えば、先般アメリカではバイデン大統領が 2021/5/12 に連邦政府のサイバーセキュリティ対策として多要素認証及び暗号化を採用する大統領命令に署名をしました。併せて、Google 社が多要素認証のデフォルト化を検討したり、 Twilio 社も必須化のアナウンスを出すなど、海外のトレンドとしては多要素認証のデフォルト化が進んでいます。​スプートニク 日本ニュース 2021年6月8日 通常の過失：職員のミスでコロニアル・パイプラインがクラッキングSecurity Magazine 2021年5月13日 President Biden signs executive order to strengthen U.S. cybersecurity defensesSecurity Magazine 2021年5月10日 Google wants to enable MFA by defaultTwilio BLOG 2020年12月3日 Twilio Account Login Change: Mandatory Two-Factor Authentication​一方、日本においても 経済産業省が全国の企業におけるサイバー攻撃実態や被害事例とりまとめた情報に記載されているようなリスト型攻撃による不正ログイン事案の継続的発生とその対応策としてのセキュリティ強化策の示唆や、“ID・パスワードのみ利用可能な会員制サイトやクラウドメールアカウント等が、流出したID・パスワードのリストを利用した「リスト型攻撃」により不正ログインされる事案が継続的に発生”“ログイン機能に二段階認証や二要素認証を導入することでウェブサイトへのアクセスに関わるセキュリティを強化したり、個人情報の機微度に応じて分割して管理し、データへのアクセス権別に設定するなどのシステム構造の見直しが大切に。”情報処理推進機構の“情報セキュリティ 10大脅威 2021”の組織向けの第2位 標的型攻撃による機密情報の窃取にて指摘されている状況は、3位・4位・8位・10位の脅威と複合して、窃取されたユーザID・パスワードによる不正アクセスリスクは「信頼できるネットワーク環境下」においても増加しており、ログインユーザの保護の簡易かつ効果的な方法の一つとして多要素認証に注目が集まってきています。“企業や民間団体そして官公庁等、特定の組織から機密情報等を窃取することを目的とした標的型攻撃が継続して発生している。攻撃者は新型コロナウイルスの感染拡大による社会の変化や、それに伴うテレワークへの移行という過渡期に便乗し、状況に応じた巧みな手口で金銭や機密情報等を窃取する。”​日本経済新聞 2020年8月24日 記事 VPN脆弱性対応、日本企業に隙「ゼロトラスト」不可欠日本経済新聞 2020年8月25日 記事 VPN情報流出、懸念されるリスクは？経済産業省 2020年6月12日 報告書 昨今の産業を巡るサイバーセキュリティに係る状況の認識と、今後の取組の方向性についての報告書を取りまとめました より 昨今の産業を巡るサイバーセキュリティに係る状況の認識と今後の取組の方向性について（概要版）（PDF形式：1,057KB）情報処理推進機構 2021年3月25日 情報セキュリティ 10大脅威 2021 併せて、弊社の外部ブログにも多要素認証の重要性について記事を投稿させて頂いております。こちらも併せてご参照下さい。​不正ログインを99.9%防止「多要素認証」の重要性 3.現在の利用状況と利用可能なセキュリティ制御機能を理解し評価するSpring’ 22 時点で Salesforce が多要素認証の機能を提供可能な製品は、次の製品を含む、Salesforce Platform 上に構築あれたすべての製品: Sales Cloud、Service Cloud、Analytics Cloud、B2B Commerce Cloud、Experience Cloud、Industries 製品 (Consumer Goods Cloud、Education Cloud、Financial Services Cloud、Government Cloud、Health Cloud、Manufacturing Cloud、Nonprofit Cloud、Philanthropy Cloud)、Marketing Cloud—Audience Studio (旧 DMP)、Marketing Cloud—Pardot、Platform、Salesforce Essentials、Salesforce Field Service、パートナーソリューションB2C Commerce CloudHerokuMarketing Cloud—DatoramaMarketing Cloud—Email Studio、Mobile Studio、Journey BuilderMarketing Cloud—SocialMuleSoft Anypoint PlatformQuip 製品Tableau Onlineです。[*1]他のすべての Salesforce 製品でも積極的に多要素認証の機能の開発に取り組んでおり、他の製品で 利用可能になった時点でリリースノートにてお知らせする予定です。多要素認証やセキュリティ強化の対象となった機能については、各製品のリリースノートやヘルプ記事などを通じてその機能概要の説明や設定方法をご案内しておりますが、特に注力している多要素認証の概要や設定になどに関する情報はウェブセミナーや Trailblazer Community などを通じて英語だけでなく日本語でのガイダンス資料やデモ動画を提供し、お客さまの理解や評価に役立つ情報発信に努めています。参考リソースをご参照いただきご活用いただければと思います。​4.適用・展開を計画する最新のセキュリティ管理と機能をお客さま環境に適用・展開する方法は、「製品機能の理解」「セキュリティ管理の現状把握」「適用タイムラインの決定」を行う事前準備、事前準備に基づいて「特権的ユーザ数の最小化」「パイロットユーザへの適用」「パイロットユーザからの学び」を行う試行段階、試行段階の教訓を踏まえた全社適用に向けた「役員コミュニケーション計画」「ユーザとのコミュニケーション計画」「変更管理計画」を策定するオーソドックスな段階的展開が実行における課題や計画の実現性を高めるうえで望ましいと方法と考えています。この計画に基づいてユーザへの「適用推進キャンペーン」など通じた適用推奨、その適用進捗を確認するため履歴設定やレポートやビューなどの監視設定、設定した監視情報のダッシュボード等を通じた定期的な適用状況監視により計画の進捗確認と適用促進を繰り返す事も不可欠の要素と言えます。これらの適用準備や展開監視を支援するツールとして「セキュリティ管理の現状把握」にはセキュリティ状態チェック機能、「監視設定」や「適用状況監視」には2FAダッシュボードなどがSales Cloud、Service Cloud、Platformなどで利用可能ですので、これらツールを利用することも忘れずに覚えておきましょう。セキュリティ状態チェック（ヘルプ記事）2FAダッシュボード（AppExchange)5.SalesforceへのアクセスにおけるMFA要件 [*2]認証ユーザの認証情報取得への攻撃が昨今さらに強くなっている環境における、安全なアクセスを担保する手段として2022 年2 月より Salesforce へのアクセス時に MFA を要件とする旨のご案内を 2021 年 2 月に配信させていただきました。このアクセス要件は、認証ユーザにおけるセキュリティを複数の認証要素を用いることで担保するソリューションおよび情報を、前述のセキュリティパートナーシップにおけるSalesforceの責任においてお伝えするものです。この MFA 要件は「UI経由でログインする Salesforce の Internal User」を対象(*1)に、Salesforce へのアクセス時に知っている情報 (ユーザ ID とパスワード) 以外の要素での追加認証 (Authenticator や Hardware Key など各個人が持っている情報など) を必須とする内容となっています。​この対象ユーザの UI 経由のログインは、単純に Salesforce のログイン画面 (UI) にユーザ名とパスワードを入力する最もシンプルな形態の場合には、その入力後に持っている情報 (Authenticator や Hardware Key など)を利用して本人を認証する事を意図していますが、複数システムを利用されているお客様においては別システムにおける ID とパスワード認証を経てその認証情報を Token などの形態で Salesforce に連携させることでログインを完結させる SSO(Single Sign-On *2) を利用されるお客様も少なからずいらっしゃいます。この外部での認証情報をもって Salesforce にアクセスされているお客様においても、その外部認証時における多要素認証を実施いただいた上で Salesforce にアクセスいただく (前述のセキュリティパートナーシップにおけるお客様の責任に該当する内容) 事がセキュリティ担保の上で不可欠となりますが、その適用状況(外部認証における多要素認証の適用)に関しては現時点で弊社で判断可能な内容ではございません(*3) ので、弊社にてその準拠状況を監視ならびに制御するもの、できるものではなく、お客様のビジネスにおける安全性確保の観点においてご対応いただきたい内容と考えています。​(*1) 組織外の認証ユーザとなる Experience Cloud の外部ユーザ、Chatter Free や外部 Chatter ユーザ、E-Commerce のユーザ、および認証が発生しないゲストユーザ、システム間連携のために利用される都度 UI ログインが発生しない API やIntegration 用ユーザは必須要件の対象外(*2) Reverse Proxy など代理認証も広義での SSO と定義される場合もありますが、SAML や OpenID Connect などによる外部認証を SSO と定義しており、代理認証は Salesforce への通常の UI 経由のログインとして扱われるため Salesforce 側での MFA が必要(*3) SSO で利用される OpenID Connect は、amr 属性 (Authentication Method Reference) でMFAの利用可否をSpring’21から Salesforce で識別可能。SAML においても将来的に AuthContext 属性によって MFA 適用された SSO を識別可能にする予定考慮事項本ブログは定期的に更新されます。毎月一度は必ずご確認ください。最後にいかがでしたでしょうか。今回ご紹介した Salesforce への安全なアクセスの基本知識については、Trailhead で学習することも可能です。検討の基礎知識の再確認の意味でも、こちらのモジュールを完了させておきましょう。Trailheadで自己学習ユーザ認証 / Identityの基本 / セキュリティの基本​参考リソース [*1]Salesforceのセキュリティの基本（ヘルプ記事）Spring’21 IDとアクセス管理（リリースノート :更新）Salesforce セキュリティガイド（開発者ガイド）Salesforce 多要素認証のFAQ（ヘルプ記事 : 更新[*1] ）Marketing Cloud の多要素認証に関する FAQ (ヘルプ記事)* MFA - Getting Started *（Trailblazer Communityの多要素認証のグループ : 英語）管理者向けガイド多要素認証（MFA）設定マニュアル  (日本語)多要素認証の管理者ガイド（日本語）管理者向けのシステム管理者ガイド (日本語)Admin Guide to Multi Factor Authentication（English）動画Webセミナーの資料と動画（Trailblazer Community へのログイン要）2020年8月28日 開催 より安全にSalesforceにアクセスするための「多要素認証」の設定2020年9月25日 開催 Marketing Cloud 多要素認証 (MFA) の導入と設定Marketing Cloudの多要素認証の設定 (動画解説)多要素認証がアカウントへのアクセスを保護する仕組み (CCで日本語字幕選択可能)Salesforce Authenticator の概要(CCで日本語字幕選択可能)アクセラレータウェブセミナー[オンデマンド・アクセラレータ] Platform: 多要素認証 (オンデマンド録画 : New)資料[JP]Social Studio 多要素認証機能のご紹介信頼性の高いCommerce Cloudの設計 多要素認証の導入 ステップガイド改定[*1] Spring’22 での対応状況を踏まえて更新[*2] 2021年2月にご案内の”【重要】多要素認証への対応のお願い”の送信に基づく追記[*3] 海外の事例を追加 [*4] 弊社公開ブログ記事を追加

データの整理と活用について

👤この文章の対象者👤主に、Marketing Cloud Engagementを使って施策を企画、実行、運用、改善を行なわれる方向けの情報となります。ただし、データ連携に関連する部分はシステム部門の方と連携していただく必要がある場合があります。​​必要な設定が環境に適用されたら、データ連携を行いましょう。Marketing Cloud Engagementにデータを連携する上で最も重要なのが、「コンタクトキー（連絡先キーとも呼ばれます）」です。コンタクトキーを決めたら、連携するデータを整理し、全ての顧客データに対してそのコンタクトキーが関連づけられるようにします。​コンタクトキー（連絡先キー）を決めるコンタクトキー（翻訳ブレで連絡先キーと記載されることもあります。）とは、Marketing Cloud Engagementの中で顧客を特定するもので、全ての顧客に対してユニークな値を設定する必要があります。同じ値を違う複数の人に振り分けることはできません。​コンタクトキーとして貴社でどんな値を利用するか、選択することができます。例えば、基盤システムで使っている顧客識別番号であったり、マイページにログインするためのログインIDのような値であることが一般的です。​以下の図は、メール、モバイルアプリプッシュ(MobilePush)、SMSメッセージ(MobileConnect)を送信するにあたり、それぞれのチャネルで固有のデータテーブルを持ち、顧客（レコード）を管理している例です。「ABC002」というコンタクトキーにより、「Yamada Taro」さんのメールアドレスは「taro@sample.net」であり、DeviceIDは「463ADD312CAE」であり、Mobile Phoneは「818012345678」であることが特定できます。つまり、チャネルを跨いで同一人物を特定することができています。このように、ABC00*のようなコンタクトキーの値を決めるには、今後のチャネルやデータの拡張性を考慮する必要があります。（Emailのテーブルである「All subscribers」では「Subscriber Key」と表記されています。厳密には違うものですが、ここでは簡易性を重視して同じものと捉えていただいて問題ありません）​​​メールアドレスをコンタクトキーにした場合、メールアドレス情報がない顧客（例えばLINEキャンペーンで獲得した顧客など）を登録する際にイレギュラーなコンタクトキーを登録することとなり、データが必要以上に複雑になり、運用にも大きな負荷をかける可能性があります。また、メールアドレスは登録後に変わる可能性もあるため、できる限りメールアドレスではなく企業で管理している値をコンタクトキーに選択したほうが良いとされます。​また、MC ConnectでSales CloudやService Cloudなどと接続をしている場合は、CRM側で採番するSalesforce IDがコンタクトキーとして適用されます。これにより、クラウドを跨いで同一人物を特定することができます。​さらに詳しくコンタクトキーへの理解を深めたい方は以下のリソースをご確認ください。​参考：Marketing Cloud Engagement ポケットガイド (1) - セットアップ編エキスパートコーチング：「データ管理」Salesforce Help: 「Marketing Cloud の購読者キー」Salesforce Trailhead:  「Marketing Cloud Engagement 連絡先管理」Salesforce Trailhead: 「データモデルの設計」データ取り込みから、送信、結果分析までの流れを把握コンタクトキーが決まったら、データの中心核が決まったも同然です！ここから顧客に関係するデータ（例えば、名前、メールアドレス、住所、会員ランク、保持ポイント、購買情報など）や、製品やサービス（製品カタログ、画像URL、価格表など必ずしも顧客に紐づかないデータも）など、必要なデータをMarketing Cloud Engagementに連携する準備を始めましょう。​以下の図は、大まかなMarketing Cloud Engagementの利用の流れです。取り込むデータを決める (Data-In)Marketing Cloud Engagementを使って、1:1コミュニケーションをしたい！という場合には、多くの場合、上図「リスト抽出」にあるように、条件に当てはまる顧客を取り出して、送信対象となる顧客を抽出する必要があります。このため、データを連携する際には、運用を意識してデータを連携する必要があります。​例えば、顧客の過去の購買データを参照して、Aという製品を1000円以上、1年以内に購入した、関西地方の人で、明日が誕生日の人にだけ、特定のメールを送りたいとします。​この時、購入製品、購入金額、最終購入日、居住エリア、誕生日がコンタクトキーに紐づいて特定できるようになっている必要がありますが、すべてがバラバラのデータエクステンションに入っていたら（実際にはそんなことはないと思いますが！）、SQLを書いてデータを繋ぎ合わせる必要があります。これを毎度行うには、担当者のスキルによっては運用に負荷がかかる可能性があります。​これが、もし3つまでのテーブルであったら、SQLを書かなくてもデータフィルターを使ってデータを取得することができ、SQLを書くことのできない方が運用担当になっても、継続することができます。​このように、セグメントなどに使う重要なデータは利用しやすい状態で連携をすることが非常に重要となります。また、最近ではSalesforce Data Cloudのように、Marketing Cloud Engagement外部で抽出をして、Marketing Cloud Engagementに連携するケースもあります。どこで抽出作業をするのが良いかは、データの持ち方や運用方法によって最適解が異なりますので、運用と将来の拡張性を考慮してご検討ください。​データを取り込む方法として、主要なデータインポート方法 及び Salesforce製品連携の方法を以下にご紹介いたします。MC Connect Sales CloudやService CloudなどからCRMデータを連携します。参考本はじめてガイド：3-2 アカウントの設定Salesforce Help: 「同期データソースの実装のベストプラクティス」インポートウィザード (手動) データエクステンションに直接データを手動インポートします。参考Salesforce Trailhead: 「購読者データのインポート」Salesforce Help: 「Marketing Cloud データエクステンションへのデータインポート」インポートアクティビティ（Automation Studioを使った自動化）SFTPにあるファイルを特定の時刻、またはSFTP上の特定の場所にファイルが置かれたら、指定したデータエクステンションにインポートします。参考Salesforce Help: 「外部ファイルを使用したリストまたはデータエクステンションの更新」Data CloudData Cloudで作成したセグメントを有効化して、データエクステンションに取り込みます参考Salesforce Help: 「Marketing Cloud 有効化対象の作成」PersonalizationPersonalizationのデータをデータエクステンションに取り込みます参考Salesforce Help: 「Integrate Personalization with Automation Studio」（英語）APIデータ連携を行うために、RESTとSOAPの両方を用意しています。参考Salesforce Trailhead: 「Marketing Cloud Engagement API」Salesforce Developers: 「Marketing Cloud Engagement APIs and SDKs」本はじめてガイド：3-2 アカウントの設定リストの抽出について、さらに理解を深めたい方はこちらのリソースがおすすめです。オンデマンド動画：「メールのセグメント化の設定と自動化」Salesforce Trailhead: 「セグメンテーションツールの概要」Salesforce Help: 「SQL クエリアクティビティを使用したデータの取得とセグメント化」Salesforce Trailhead: 「SQL を使用したデータのクエリ」Marketing Cloud Engagement上で生成されるデータを把握するMarketing Cloud Engagementで生成されるデータとは、なんでしょうか。それは、主にメールなどを送信した結果データです。例えば、送信したメールの開封数やクリック数、または特定の顧客が開封したメールやクリックしたリンクなどです。その他、様々なログも生成、格納されています。Marketing Cloud Engagementの画面上から確認できるものもあれば、SQLを使って呼び出す必要のあるデータもあります。​以下に挙げたポイントは機能の一部であり、すべてを網羅しているわけではありませんが、それぞれの特色を簡単にご紹介します。まずは、配信結果の確認方法5つをご紹介します。​レポート：施策の結果を日々確認し、報告や改善に使うことができます。複数の送信を1画面で確認可能です。Analytics Builder > Intelligence Report予め用意されたダッシュボードを使って、メール、MobilePushなど複数チャネルからの送信に関するデータを確認することができます。ジャーニーごとにバージョンと送信アクティビティの結果を一元管理することもできます。ピボットテーブルを使って、比較的柔軟にレポートを作成することもでき、カスタム指標などにも対応しています。レポートをスケジュール配信するなどしてエクスポートが可能です。Intelligent Report Advanceではクエリなどで、顧客個別のデータを確認することもできます。Analytics Builder > Reports （2024年4月現在Hyperforce版ではご利用いただけません）テンプレート化（「カタログ」と呼ばれています）されたフォーマットのレポートの抽出条件を選択し画面表示、またはファイルへの出力でデータを確認します。トラッキング：シンプルな画面でメール送信の結果を確認することができます。1画面で1送信の結果を確認します。Email Studio > Email > トラッキング送信ジョブごとに、送信数や各バウンス、到達数、開封数、クリック数、クリックされたリンク一覧などを確認することができます一部のデータにおいて、CSVなどで手動エクスポートすることができます標準トラッキングJourney Builder > Automation Studioクエリをかかずに、Automation Studioの機能を使ってトラッキングデータを抽出し、SFTPへのファイル出力を行います。ファイル形式や含む項目などは予め決まっており、その中で少しカスタマイズをすることができます。さらに自由度の高い形式で抽出を希望の場合は、下記の「データビュー」から抽出します。データビューJourney Builder > Automation StudioクエリアクティビティでデータテーブルからSQLでデータを取得し、データエクステンションに格納します。その後、データエクステンションをSFTPにエクスポートすることができます。複数のデータビューから組み合わせて自由にファイルの構成を行うことができます。API​上記機能について、さらに理解を深めたい方は、以下のリソースがおすすめです。エキスパートコーチング：「レポートとインサイト」Salesforce Help:「Marketing Cloud でのデータ収集のベストプラクティス」Salesforce Help: 「Automation Studio でのデータエクステンションの抽出」Salesforce Trailhead: 「レポートの実行と結果のトラッキング」Salesforce Trailhead: 「Intelligence Reports for Engagement」Salesforce Trailhead: 「SQL を使用したデータのクエリ」続いて、配信した結果からEinsteinが生成したデータや、ログのご紹介です。Einstein Engagement Scoringが生成するデータEinstein（機械学習）が顧客ごとにエンゲージ状況に基づいて各顧客のエンゲージメントスコアを計算し、該当のデータエクステンションに格納します。エクスポートも可能です。Einstein Engagement Scoringについて理解を深めたい方は以下のリソースがおすすめですオンデマンド動画：「Einstein 機能概要」Salesforce Trailhead: 「Einstein Engagement Scoring in Marketing Cloud Engagement」送信ログメール送信時に生成される動的な情報をデータエクステンションに格納することができます。送信ログについて理解を深めたい方は以下のリソースがおすすめですSalesforce Trailhead: 「Marketing Cloud Engagement の送信ロギング」Salesforce Trailhead: 「送信ログを使用したデータの収集」​●   ●   ●​「活用7ステップ」全体に戻りたい場合はこちら

ウェブセミナーシリーズ「Salesforce まずはこれだけ」

「Salesforce のシステム管理者に任命されたが、機能がたくさんあってどこから使い始めたら良いかわからない」「前任者から引き継いだが、現在どういう設定になっているのか把握できていない」​このように日々 Salesforce で業務をしていただく上でお悩みのシステム管理者の方は多いのではないでしょうか。このウェブセミナーシリーズでは、「まず、これだけは抑えて欲しいポイント」をSalesforce サポートエンジニアが解説しています。最新の動画レポート徹底活用術 -初級編-https://play.vidyard.com/giwLMvUTJS4BZh2KCVwZS2​・レポート機能の概要・レポートタイプの選定・検索条件の設定・列/グルーピング項目の設定・デモンストレーション・よくあるお問い合わせ資料はこちら​第1弾：システム運用編https://play.vidyard.com/7UPKKJwG5ZSpyeHFFA7Dfa​・データマネジメントのススメ ・データバックアップのススメ資料はこちら​第2弾：データ活用編https://play.vidyard.com/qSapdwftuiiut3oGfVACCN​・レポート/ダッシュボードの活用 ・レコードアクセス権資料はこちら​第3弾：使いやすさ向上につながる設定https://play.vidyard.com/Q94kaTfYyKoY78pq1mt1zR​・レイアウトのカスタマイズ・Sandbox / 変更セット資料はこちら​第4弾：自動化への第一歩https://play.vidyard.com/F6cfd6saDc5HjbvzVPwVC4​・数式、積み上げ集計、フローの説明 ・デモを使った各機能のユースケースの紹介 ・各機能を使い分けるポイント資料はこちらこれであなたもフローマスター～フロー初心者編https://play.vidyard.com/YftXqUxninBKpEqKNPVFza​・フロー概要・レコードトリガフローのデモ・画面フローのデモ資料はこちらフロー初心者 総まとめ編https://play.vidyard.com/cT1fW2xQBasQJqQCFrEuFC​・フローの概要説明・デモ形式でのレコードトリガフローのご紹介・フローの学習についてロードマップをご紹介資料はこちら​第5弾：メール到達率の向上/レポートについてhttps://play.vidyard.com/RXvkk1tjRvf5DSobCiML43​・なぜ到達率の向上が必要か ・到達率を向上させる方法 ・到達率の確認方法資料はこちら​レポート徹底活用術 -初級編-https://play.vidyard.com/giwLMvUTJS4BZh2KCVwZS2​・レポート機能の概要・レポートタイプの選定・検索条件の設定・列/グルーピング項目の設定・デモンストレーション・よくあるお問い合わせ資料はこちら関連リソース次回以降の開催については日程が決まり次第、イベントカレンダーに掲載いたします。また、テクサポ日本のページでもご案内いたします。​​​