次の方法で共有

組織のデータ ファイルのアップロードを準備する

  • [アーティクル]

高度な分析情報アプリは、既定の設定であるMicrosoft Entra IDまたは管理者がアップロードする組織データ ファイルを使用して、2 つの方法のいずれかで組織データを取得できます。 この記事では、2 つ目のオプションである組織データ ファイルについて説明します。 組織のデータをアップロードする前に、管理者がデータを特定、収集、構造化するために必要な操作を確認するために読み上げました。

組織データ全般については、Viva Insightsと自動的に同期Microsoft Entra IDデータを確認し、高度な分析情報管理者エクスペリエンスの [組織データ] ページの概要については、「Viva Insightsの組織データ」を参照してください。

重要

組織のデータを含む .csv ファイルをアップロードした後は、Microsoft Entra IDを使用してに戻すことはできません。 組織のデータを最新の状態に保つために、.csv ファイルを定期的にアップロードする必要があります。

組織データを準備する

組織データ ファイルの操作を開始する準備ができたら、次のセクションでデータ準備プロセスを説明します。

  1. 分析する傾向を特定する – 職場の効率を向上させるために学習する必要がある傾向を決定します。 これらの傾向を特定した後、使用する組織データをより適切に選択できるようになります。
  2. 含めるデータを把握する – いくつかのデータ属性が必要であり、多くは省略可能です。 オプションの属性の中から、分析目的に最適な属性を選択します。
  3. 組織データのエクスポートを取得する – 管理者にorganizationの人事システムから人事データをエクスポートします。 必要に応じて、分析に必要な場合は、基幹業務データを含めます。
  4. 組織データを構造化する – データを正常に検証するには、最初にアップロードする .csv ファイルに正しく構造化する必要があります。
  5. 組織のデータ ファイルをアップロードする – .csv ファイルの準備ができたら、高度な分析情報アプリにアップロードします。検証と処理の後、分析に使用できるようになります。

手順 1 - 分析する傾向を特定する

抽出する組織データを把握するには、まず、学習する職場の傾向を決定する必要があります。 たとえば、今後の分析では、さまざまな従業員セグメントまたはグループにわたるコラボレーションを調査したい場合があります。 最初にこれらのグループを定義する必要があります。これはさまざまな方法で行うことができます。

  • 組織データ別
  • 組織階層レベル別
  • パフォーマンス、エンゲージメント、またはその他の基幹業務データ別

定義されたグループは、次の分析例で使用できます。

グループ間でのコラボレーション

一般的な分析シナリオは、従業員の異なるグループ間のコラボレーションのパターンを見つけることです。 たとえば、製品マーケティング チームが営業チームとどの程度話しているかを知りたいとします。

母集団をセグメント化するための属性は、次のようなコラボレーションのパターンを定義する際に考慮するのに役立ちます。

  • 職業、関数、規範、ジョブ コードなどのジョブ ファミリまたはロールの属性
  • 人事、財務、営業、マーケティングなどの組織、基幹業務、またはコスト センター
  • organizationで定義されている都市、州、国、地域などの場所属性
  • リモート、フルタイムの従業員、ベンダーなど、仕事を表す属性

これらの属性のほとんどは、人事情報システム内で入手できます。

階層的なコラボレーション

また、organizationの階層を参照してコラボレーション動作のパターンを探すのも一般的です。 また、マネージャーと個々の共同作成者間、およびorganizationの上位レベルと下位レベルの間のコラボレーションを定量化することもできます。

この種の分析では、次の概念が役立ちます。

  • IC またはマネージャー - 従業員が個人の共同作成者かマネージャーか。
  • 組織階層 – たとえば、その従業員のレポート構造の従業員より上のすべてのマネージャーの名前。各マネージャーは、個別の属性として格納できます。
  • レイヤー – たとえば、階層 0 が会社のトップ リーダーである組織階層での従業員の位置。
  • スパン – たとえば、従業員に割り当てられた直接レポートの数。
  • レベル – シニア マネージャー、VP、ディレクター、CVP など。

これらの属性のほとんどは、人事情報システムにも存在します。

コラボレーション、エンゲージメント、および成果のデータ

最後に、コラボレーションの行動パターンを従業員エンゲージメント スコアやその他のパフォーマンス成果データに結び付ける方法を検討できます。 このデータには、売上クォータの達成またはパフォーマンス評価が含まれる場合があります。 このデータは、多くの場合、従来の人事情報システムの外部で、個別の人事データ リポジトリまたは基幹業務システムで見つかります。

手順 2 - 含めるデータを把握する

Advanced Insights アプリのすべての機能を利用するには、属性リファレンスで説明されているように、いくつかの必須属性を指定する必要があります。 さらに、最大 100 個のオプション属性を指定して、興味深いカスタム方法でデータをグループ化およびフィルター処理することができます。

組織データの例としては、ジョブ ファミリ、ジョブ ロール、organization、基幹業務などがあります。 このデータは、個々のレベルで高度な分析情報アプリに提供されます。つまり、これらの属性は、データセット内の各ユーザーにコンテキストを提供します。

含める従業員

少なくとも、Viva Insights ライセンスを持つすべての従業員の組織データを含めます。 サブグループ (つまり、社内の特定のターゲット母集団) についてのみコラボレーション データを収集する予定がある場合でも、データアップロードの一部として社内のすべてのユーザーを含める方が良い場合があります。

たとえば、マーケティング担当者が製品開発のユーザーと頻繁にコミュニケーションを取り、アプリにマーケティング organizationに関する人事データのみが含まれている場合、マーケティングが製品開発に費やしている時間を示すレポートを作成することはできません。

すべてのユーザーをorganizationに含めることができない場合、最小限含めるのは、コラボレーション データが収集されているすべてのユーザーです。 この最小値を使用すると、この母集団内のグループ間のコラボレーション パターンを分析できますが、この母集団外のグループ間では分析できません。

ライセンスを持つすべての従業員を含む

組織のデータを最新の状態に維持し、完全に管理するのは管理者の責任です。 このタスクでは、"完了" とは、適切なユーザーを含み、それらのユーザーに適した属性を含むデータという 2 つのことを意味します。

organizationにすべてのライセンスを持つ従業員を含める理由は、組織のデータが不足している場合、アナリストは分析ページでクエリを作成するときに、そのデータによってフィルター処理できないということです。 そのため、データが欠落している従業員は、アナリストが実行する分析から除外されます。

重要

Microsoft 365 管理者が、レポートに含めるすべての従業員にライセンスが割り当てられていることを確認します。 組織のデータ ファイルに従業員を含める場合でも、レポートに表示するにはライセンスが必要です。 ライセンスとレポートの詳細については、「 ユーザーがクエリ結果に表示されたとき」を参照してください。

組織データのアップロードにライセンスを持つすべての従業員を含めることに加えて、 先ほど説明したように、ライセンスのない従業員も含めることをお勧めします。

手順 3 - 組織データのエクスポートを取得する

組織データをフォーマットしてアップロードする前に、1 つ以上のソースからデータを取得する必要があります。 主な情報源は、組織の人事情報システムを管理するチームです。 このチームでは、個々の従業員の人事属性のデータ エクスポートを提供する必要があります。

さらに、アナリストはビジネス成果に関するデータを必要とすることがあります。 その場合は、この情報を含むデータ ストアにアクセスできる基幹業務所有者に問い合わせる必要があります。 たとえば、このデータには次のものが含まれます。

  • 特定の作業グループのパフォーマンス レビュー データ。
  • 人事情報システム外の人事情報から獲得した従業員エンゲージメントのスコア
  • パフォーマンスに対するより多くのビューを提供する売上またはその他のクォータ達成データ。
  • 従業員のアンケートのデータ。

このデータを取得した後は、アプリにアップロードした後に処理を正常に行うために、データを構造化する必要があります。

手順 4 - 組織データを構造化する

エクスポートしたデータを取得したら、正しい形式に構造化します。

必須、予約済みの省略可能、およびカスタム属性を追加する

組織のデータ ファイルに追加できる属性には、必須、予約済みオプション、カスタムの 3 種類があります。

必須

次の属性を列ヘッダーとして指定します。次に示すとおりに、.csv アップロードします。

  • EffectiveDate
    • EffectiveDate 列にすべての行に値があることを確認します。 アップロードに EffectiveDate 列を指定しない場合、データをアップロードした日付が既定の EffectiveDate になります。
  • PersonId
  • ManagerId
  • 組織 (大文字と小文字が区別されます)
予約済みオプション

次の属性は、現在データの計算、フィルター処理、およびグループ化に使用されている属性の予約列ヘッダーです。 特定の Power BI テンプレートによっては、以下の一覧とは異なる属性が必要になる場合があります。

  • LevelDesignation
  • FunctionType
  • HireDate
  • HourlyRate
  • Layer
  • SupervisorIndicator
  • WeeklyBadgeOnsiteDays
  • Location

注:

属性は、ファイル内で任意の順序で指定できます。 ただし、これらの必須属性と予約属性の名前を、新しいカスタム属性の名前として使用することはできません。

カスタム属性

カスタム属性は、データのフィルター処理とグループ化に使用するために定義するその他の属性です。 これらの属性をアップロードすると、アナリストはクエリの作成時にそれらを使用できます。 カスタム属性をアップロードする方法については、「 組織データのアップロード (最初のアップロード)」を参照してください。

注:

  • システムで許可される属性の合計数は 105 で、これには 5 つの必須属性が含まれます。
  • すべての数値フィールド (必須属性 "HourlyRate" など) は"数値" 形式である必要があり、コンマやドル記号を含めることはできません。

ヒント

ファイルの書式設定の詳細については、 ファイルルールと検証エラー に関する記事を参照してください。

.csv エクスポート ファイルの例

有効な .csv エクスポート ファイルのスニペットの例を次に示します。

PersonId,EffectiveDate,HireDate,ManagerId,LevelDesignation,Organization,Layer,Area Emp1@contoso.com,12/1/2020,1/3/2014,Mgr1@contoso.com,Junior IC,Sales,8,Southeast Emp2@contoso.com,11/1/2020,1/3/2014,Mgr1@contoso.com,Junior IC,Sales,8,Southeast Emp3@contoso.com,12/1/2020,1/3/2014,Mgr2@contoso.com,Manager,Sales,7,Northeast Emp4@contoso.com,10/1/2020,8/15/2015,Mgr3@contoso.com,Support,Sales,9,Midwest Emp5@contoso.com,11/1/2020,8/15/2015,Mgr3@contoso.com,Support,Sales,9,Midwest Emp6@contoso.com,12/1/2020,8/15/2015,Mgr3@contoso.com,Support,Sales,9,Midwest

属性の詳細については、「属性リファレンス」セクションを 参照 してください。

手順 5 - 組織のデータ ファイルをアップロードする

ソース .csv ファイルを作成した後、[データ ハブ] または [データ接続] タブの [組織データ] ページから高度な分析情報アプリ>アップロードできます。

組織データを初めてアップロードする場合は、「組織データの アップロード (最初のアップロード)」を参照してください。 初めてではない場合は、「 組織データのアップロード (後続のアップロード)」を参照してください。

データが正常にアップロードされると、アプリはより多くの検証と処理を実行してプロビジョニングを完了します。

組織のデータ .csv ファイルをアップロードする頻度

少なくとも月に 1 回は従業員データをアップロードして、データを最新の状態に保ち、分析に関連するようにすることをお勧めします。 従業員データのアップロードが成功するとすぐに、更新されたデータをユーザーがアプリで分析情報として表示できるようになります。

特定の期間にわたるデータを提供します。

既定では、Viva Insightsには、測定された従業員の会議データとメール データが 1 年間含まれます。 組織データは、アップロード ファイル内の各行に関連付けられた有効日をViva Insightsするために提供されます。

現在の日付の時点で人事情報システムから組織データのポイントインタイム エクスポートを行うと、その単一時点の従業員の人口の画像が表示されます。 プロビジョニング中のデータの再現性を最大限に高めるには、過去 13 か月間の組織データ エクスポートを指定する必要があります。 このデータは、1 つのファイルまたは一連のファイルで指定できます。

実際の動作を次に示します。 測定された従業員ごとに、13 行の個別の行が作成されます。 これらの各行には、データがプルされた各月の有効日が含まれます。 各月の有効日が不可能な場合は、1 つの時点を指定できます。 その場合は、有効日を現在の月の最初の日 (1 年前) に設定します。 たとえば、プロビジョニングが 2020 年 10 月に発生した場合、すべての行の有効日を 2019 年 10 月 1 日に設定する必要があります。

従業員コラボレーション アクティビティは、コラボレーション アクティビティの日付より前の最新の組織データ スナップショット (EffectiveDate に基づく) にマップされます。

高度な構成 - 対応する処理用の EntraID を検索するように電子メール アドレスを構成する

Viva Insightsは、電子メール アドレスを使用して、対応する処理用の EntraID を検索します。 この高度な構成では、各メール アドレスの EntraID を取得するために使用する日付Viva Insights選択できます。

オプション 1: EffectiveDate

適用される場合: データ ソースは、EffectiveDate によるメール アドレスの変更を追跡します

EffectiveDate は、特定の属性値が従業員に適用される日付です。 この属性は、異なる EffectiveDate を持つ同じ属性の別のレコードが指定されるまで適用されます。 EffectiveDate がアップロードされていない場合、アップロードの日付が既定として使用されます。

シナリオ

  1. データ ソースは、EffectiveDate によってメール アドレスの変更を追跡します。
  2. 電子メール アドレスが BoSmith@contoso.com から EntraID "A" の BoJames@contoso.com に変更されました。 この変更は、EffectiveDate を使用して HCM システムに記録されます。

例:

  1. 2024/04/14: 電子メール アドレスが BoSmith@contoso.com から EntraID "A" の BoJames@contoso.com に変更されました。 この変更は、HCM ソース システムに記録され、EffectiveDate 04/14/2024 の BoJames@contoso.com の新しい行が記録されます。

  2. これは、2024 年 4 月 15 日に HCM ソース システムからエクスポートスナップショット。

    Personid EffectiveDate 組織
    BoSmith@contoso.com 04/01/2024 甲乙丙
    BoJames@contoso.com 04/14/2024 甲乙丙

  3. 2024/04/16: スナップショット日付にエクスポートされたファイルは、Viva Insightsにアップロードされます

    • [詳細設定] で [EffectiveDate] を選択します

    • これにより、メール アドレスの変更が、アップロードされたファイルで提供される対応する EffectiveDate によって追跡されます。

      • 2024 年 4 月 1 日から 2024 年 4 月 14 日まで、 BoSmith@contoso.com を使用して EntraID "A" をフェッチします
      • 2024 年 4 月 14 日から、 BoJames@contoso.com を使用して EntraID "A" をフェッチします

      EffectiveDate を使用して一定期間にわたってデータを提供する方法の詳細を確認してください。

オプション 2: 日付を選択する

適用される場合: データ ソースがメール アドレスの変更を追跡しません。 選択した日付のメール アドレスは、過去のすべての日付に使用されます。

  1. 最近データをエクスポートした場合は、今日の日付を選択します。
  2. それ以外の場合は、古い日付を選択します。

シナリオ 1

  1. データ ソースはメール アドレスの変更を追跡せず、最近データをエクスポートしました。
  2. E メール アドレスが EntraID "A" に変更され、履歴データ全体の新しいメール アドレスが "A" と一致するようにします。

例:

  1. 2024/04/14: 電子メール アドレスが BoSmith@contoso.com から EntraID "A" の BoJames@contoso.com に変更されました。

  2. スナップショット 2024 年 4 月 15 日に HCM ソース システムからエクスポートされます。

    Personid EffectiveDate 組織
    BoJames@contoso.com 04/01/2024 甲乙丙

  3. 2024/04/16: スナップショット日付にエクスポートされたファイルは、Viva Insightsにアップロードされます。

  4. ドロップダウンから [2024/04/16 ] を選択します

    • これにより、2024 年 4 月 16 日 (例: BoJames@contoso.com) のメール アドレスを使用して、過去のすべての日付の EntraID "A" をフェッチできます。

シナリオ 2

  1. データ ソースはメール アドレスの変更を追跡せず、最近データをエクスポートしませんでした。
  2. EntraID "A" のメール アドレスが変更され、履歴データ全体で古いメール アドレスが "A" と一致するようにします。

例:

  1. スナップショット 2024 年 4 月 20 日に HCM ソース システムからエクスポートされます。

    Personid EffectiveDate 組織
    BoSmith@contoso.com 04/01/2024 甲乙丙

  2. 2024/04/25: 電子メール アドレスが entraID "A" の BoSmith@contoso.com から BoJames@contoso.com に変更されました。

  3. 2024/05/10: スナップショット日付にエクスポートされたファイルは、Viva Insightsにアップロードされます。

    • 2024 年 4 月 25 日または 2024年 5 月 10 日ではなく、ドロップダウンから [04/20/20/2024] を選択します。
    • これにより、2024 年 4 月 20 日 (例: BoSmith@constoso.com) のメール アドレスを使用して、過去のすべての日付の EntraID "A" をフェッチできます。

部分的なデータ インジェストを有効にする

部分的なデータ インジェストを有効にするには、[ 有効な行のアップロード] を選択し、無効なデータを含む行を除外します。 この設定では、有効な値を含む行のみがアップロードされ、エラーが原因で取り込まれていない行に対する警告が表示されます。 この設定は既定ではオフになっています。

属性リファレンス

このセクションには、高度な分析情報アプリにアップロードされた組織データ ファイルで使用する属性に関する情報が含まれています。

注:

Viva Insightsのデータを Microsoft 365 の組織データ機能と共有する場合、次に示す属性の一部が共有されます。 ただし、Microsoft_を含む属性は、Viva Insightsでは使用できません。 Microsoft 365 の組織データの詳細については、こちらをご覧ください。

注:

"SiteDays" フィールドが "WeeklyBadgeOnsiteDays" になりました。 詳細については、次の表を参照してください。

マップされたフィールドViva Insights 説明 データ型 値の例 必須または予約済み
PersonId 従業員レコードの一意識別子。 従業員のプライマリ SMTP アドレスまたはメール エイリアスを指定できます。 電子メール joe@contoso.com 必須1
ManagerId 従業員のマネージャーの一意の識別子。 マネージャーのプライマリ SMTP アドレスまたは電子メール エイリアスを指定できます。 CEO の場合、これは空白のままにできます。 電子メール sally@contoso.com 必須
組織 従業員が属する内部organization。 より実用的な分析情報を得る場合は、一意の組織が少なすぎるか、または多すぎるのを使用しないでください。 String Financial Planning and Analysis 必須
EffectiveDate
  • 特定の属性値が従業員に適用される日付。 この属性は、異なる EffectiveDate を持つ同じ属性の別のレコードが指定されるまで適用されます。 EffectiveDate がアップロードされていない場合は、アップロード日が既定で使用されます。
  • 管理は、DateTime_MM/DD/YYYY または DateTime_DD/MM/YYYY として DataType を選択できます。
  • 選択した Datatype が DateTime_MM/DD/YYYY である場合は、MM/DD/YYYY、MM/DD/YYYY、さらに "time"、MM-DD-YYYY、MM-DD-YYY、YYYY-MM-DD などのテキストがサポートされます。
  • 選択した Datatype が DateTime_DD/MM/YYYY である場合は、DD/MM/YYYY、DD/MM/YYYY、"time"、D/MM/YYYY、D/MM/YYY、DD-MM-YYYY、DD-MM-YYY、YYY-DD-MM などのテキストがサポートされます。
  • 選択した Datatype が DateTime_MM/DD/YYYY または DateTime_DD/MM/YYYY である場合、2012 年 3 月 14 日水曜日がサポートされます。2012 年 3 月 14 日。2012 年 3 月 14 日;または 14-Mar-12。
    		•  DateTime 12/31/2021 必須2
    LevelDesignation organization内の従業員の経験、管理レベル、または年功序列を表すレベル。 より実用的な分析情報を得る場合は、一意の LevelDesignation 値の使用が少なすぎるか、または多すぎるのを避けてください。 String Director 予約済み 3
    FunctionType 従業員が実行するジョブ関数。 より実用的な分析情報を得る場合は、一意の FunctionType の使用が少なすぎるか、または多すぎるのを避けてください String Finance Management Reserved
    HireDate
  • 従業員が雇用を開始した日付。 従業員が複数の雇用日を持っている場合は、最新の雇用日を使用することをお勧めします。
  • 管理は、DateTime_MM/DD/YYYY または DateTime_DD/MM/YYYY として DataType を選択できます。
  • 選択した Datatype が DateTime_MM/DD/YYYY である場合は、MM/DD/YYYY、MM/DD/YYYY、さらに "time"、MM-DD-YYYY、MM-DD-YYY、YYYY-MM-DD などのテキストがサポートされます。
  • 選択した Datatype が DateTime_DD/MM/YYYY である場合は、DD/MM/YYYY、DD/MM/YYYY、"time"、D/MM/YYYY、D/MM/YYY、DD-MM-YYYY、DD-MM-YYY、YYY-DD-MM などのテキストがサポートされます。
  • 選択した Datatype が DateTime_MM/DD/YYYY または DateTime_DD/MM/YYYY である場合、2012 年 3 月 14 日水曜日がサポートされます。2012 年 3 月 14 日。2012 年 3 月 14 日;または 14-Mar-12。
    		•  DateTime 12/31/2021 Reserved
    HourlyRate 従業員の給与は、時給 (米ドル) として表されます。 倍精度浮動小数点数 25.25 Reserved
    Layer 組織階層内の従業員の位置。organizationのトップ リーダーからの距離として表されます。 たとえば、CEO はレイヤー 0 です。 より実用的な分析情報を得る場合は、一意のレイヤーの使用が少なすぎるか、または多すぎるのを避けてください。 整数 2 Reserved
    SupervisorIndicator IC (個人共同作成者)、Mngr (マネージャー)、または Mngr+ (マネージャーのマネージャー) としての従業員のマネージャーの状態。 String IC Reserved
    WeeklyBadgeOnsiteDays 従業員が会社のメイン作業サイトから働く週あたりの平均日数。 0 ~ 7 の数値にする必要があります。 WeeklyBadgeOnsiteDays は、バッジ データやその他のソース (たとえば、従業員がオンサイトで働く予定の日数を示す人事システムのタグ) に基づいて作成できます。 倍精度浮動小数点数 4 Reserved
    Location 従業員のオフィスの場所。 String Burbank Reserved
    CountryOrRegion  従業員が働いている国または地域。  String Japan Reserved
    My_Custom_attribute
    (例: Campus)    		 作成する属性 String West N/A (カスタム)4

    1. 必須フィールドを含める必要があります。 各必須フィールドには、各行に空白以外の値が必要です。

    2. アップロードに EffectiveDate 列を含めない場合、アップロード日は既定の EffectiveDate になります。

    3. これらの予約フィールドを含める必要はありません。 ただし、使用する場合は、これらの列名を保持します。

    4. カスタム属性を含める必要はありません。 ただし、追加する場合は、必要な属性または予約済み属性と同じ名前を付けることはできません。

    属性のメモと推奨事項

    一部の属性は、母集団のサブセットにのみ存在します

    含める属性を選択すると、1 つのorganizationに対して一部の属性値が設定される場合がありますが、他の属性値は設定されません。 たとえば、アップロードに売上organizationにのみ適用される売上クォータ達成データが含まれている場合、このデータを使用して、営業外の従業員をフィルター処理およびグループ化することはできません。

    多すぎる一意の値

    属性の一意の値が多すぎて、グループ化やフィルター処理に使用できる場合があります。 たとえば、ジョブ関数またはコードがあまりにも狭く定義されている場合は、グループ全体の役に立つビューが得られない可能性があります。 属性に何百もの一意の値があり、値ごとの母集団グループが小さい場合、属性は役に立たない可能性があります。

    少なすぎる一意の値

    逆に、有用なフィルター処理のために属性が広く定義されている場合があります。 たとえば、organizationが米国に完全に存在し、従業員ごとの人事レコードに常に米国と等しい国コードが含まれている場合、その属性は役に立ちません。

    冗長な属性

    一部の属性は、同じデータを表し、分析のために不要な冗長データを提供する場合があります。 たとえば、人事データには、従業員のコスト センター ID とコスト センター名の両方が含まれる場合があります。 どちらも同じ情報を少し異なる形式で表しているため、"わかりやすい" 名前の情報のみを含めます。

    基幹業務データ

    人事データとは異なり、基幹業務データの場合、データのアップロードの一部として社内のすべてのユーザーを含める必要がない場合があります。 分析するシナリオを把握すると、決定に役立ちます。 たとえば、Sales organizationの従業員間で、エンゲージメントが低い従業員と比較して、エンゲージメントが高い従業員間でコラボレーション パターンを比較するとします。 より広範なコラボレーション パターンを特徴付けることができるように、すべての従業員の人事データが必要ですが、スコア値を使用して特定のレポート出力をグループ化およびフィルター処理するため、Sales organizationの従業員のエンゲージメント スコア データのみが必要です。