Skip to main content
Loading...
Skip to article
  • Qualtrics Platform
    Qualtrics Platform
  • Customer Journey Optimizer
    Customer Journey Optimizer
  • XM Discover
    XM Discover
  • Qualtrics Social Connect
    Qualtrics Social Connect

参加者ファイルのインポート準備 (EX)


Was this helpful?


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The feedback you submit here is used only to help improve this page.

That’s great! Thank you for your feedback!

Thank you for your feedback!


ヒント:このページの最初のセクションでは、参加者をエンゲージメント、ライフサイクル、パルス、アドホック従業員調査の各プロジェクトにアップロードするためのファイル要件について説明します。ただし、このページの残りの部分では、Pulse、Lifecycle、または Ad Hoc Employee Research には適用されない階層固有のファイル要件についても説明していることに注意してください。それぞれの詳細については、「 Employee Experienceプロジェクトのタイプ 」を参照してください。

参加者ファイルの準備について

Employee Experienceプロジェクトに参加者をインポートする際は、いくつかの重要な点に留意してください。たとえば、すべてのインポートに以下の列が必要です。

  • 名: 従業員の名。
  • 姓: 従業員の姓。
  • メール: 従業員のメールアドレス。この詳細が最も重要です。電子メールは、各参加者のユーザー名として、またはディレクトリにすでに存在するユーザーを覚えておくための手段として機能します。
    注意: 参加者ファイルの電子メールフィールドを空白のままにすると、個人情報を入力するためのプレースホルダとして、UniqueID@BrandID.fake という形式を使用して人工電子メールが生成されます。生成されるメールは仮想メールであるため、メールが有効なアドレスに更新されるまで、EX配信は参加者に送信されません。参加者をアップロードする際にメールアドレスを含める必要があるため、組織にSSOがある場合はこの動作は適用されません。
  • UniqueIdentifier:会社が望む識別子で参加者を指定します。内部数値 ID からユーザー名まで、EmployeeID 列の繰り返しに使用できます (ただし、これが組織内で一意であり、他のプロジェクトでは誰とも共有されない場合に限ります)。
    ヒント:詳細については「一意の識別子」サポートページを参照してください。
ヒント:組織でSSOを使用している場合、参加者をプロジェクトにアップロードする前に、[ユーザー名]の列がSSOのユーザー名属性と一致するディレクトリに参加者をアップロードしてください。

エンゲージメントプロジェクトを作成する場合は、CSV/TSVファイルに含める参加者データのメタデータまたはカスタム列に影響するため、プロジェクトに適切な階層を選択していることを確認してください。たとえば、親 – 子階層ファイルには社員 ID とマネージャー ID の列を含める必要がありますが、レベルベースの階層ファイルには異なる Level 列を含める必要があります。このページの階層ごとに含める必要があるメタデータを参照します。

ヒント:プロジェクトに複数の階層がある場合がありますが、メタデータフィールドは階層の生成にのみ使用できます。たとえば、「マネージャID」を使用して最初の階層を構築する場合、そのフィールドを使用して2番目の階層を構築することはできません。

最初に正しいメタデータを含め忘れた場合は、それで問題ありません。参加者のメタデータは、リンクされたセクションの手順に従ってファクトの後にいつでも更新することができます

ヒント:ファイルをアップロードする準備ができたが、方法がわからない場合は、 このページの指示に従って階層ファイルを設定したら、「参加者の追加」サポートページに進みます。
ヒント:どのタイプの階層が人事データに最適かは不明ですか?階層基本概要ページで、オプションの基本比較を確認します。

親子階層の参加者のインポート

親子階層は、最も一般的に使用される種類の階層です。これらは、HR データが書式設定されているために従業員 ID の一覧および各従業員が報告するマネージャがある場合に最適なオプションです。

ここをクリックして、親子階層のテンプレートにアクセスします。

必要なメタデータ

親子階層を作成するには、次の 2 つのメタデータ列を含める必要があります。

  • EmployeeID: 参加者の従業員 ID です。ランダムに生成された新しい ID を作成するのではなく、会社の人事部門が内部的に割り当てた ID を使用することをお奨めします。
  • ManagerID: 参加者のマネージャーの従業員 ID です。

例: 下の画像では、John Doe の EmployeeID は 1 であるため、EmployeeID カラムは 1 になっています。Jill Davis、Sammy External、Joseph Miller は John Doe に直接レポートするため、ManagerID カラムには 1 と表示されます。

CSV。John Doe の EmployeeID EmployeeID カラムには 1 と表示される。Jill Davis、Sammy External、Joseph Miller ManagerID の各カラムも 1 と表示しています。

ヒント:技術的には、任意にEmployeeIDとManagerIDに名前を付けることができます。たとえば、組織で “従業員番号” という用語が優先される場合、または “QID” のような特別な用語がある場合は、列にこれらの名前を自由に指定してください。重要なのは、親子階層を生成するときに、これらのコンセプトを含めて正しいフィールドに入力することです。

社員とマネージャーの ID を追加する際には、いくつかの重要な点に留意してください。

  • 親 – 子階層の生成時に、データの一意の ID 列を従業員 ID フィールドに使用することができます。この状況では、前の例は以下のようになります。
    以前と同じファイルですが、従業員 ID 列が一意識別子と呼ばれるようになりました。
  • すべての参加者には、一意の従業員 ID も必要です。複数の参加者が同じ ID を共有することはできません。これは、一意の ID と同じにすることができます。
  • すべての参加者にマネージャーが必要です。唯一の例外は、階層に含める会社の最上位メンバー(CEO など)です。この個人が誰の部下にも報告しないことを示すには、manager 列を空白のままにします。
  • 個々の社員の [従業員 ID] 列と [マネージャー ID] 列は同じにできません。従業員は自分自身に報告しません。
  • すべてのマネージャー ID は、社員にリンクし直す必要があります。既存の従業員 ID に対応していないマネージャー ID を持つ参加者は、不明なマネージャーに割り当てられます。不明なマネージャーにユーザーが割り当てられると、そのユーザーの下にある階層のメンバーも破損することに注意してください。この問題を解決するには、データをマニュアルで修正し、階層を再生成する必要があります。
  • 循環ロジックに注意してください。John Doe が Jane Smith に報告し、Jane Smith が Joseph Miller にレポートした場合、Joseph Miller は John Doe に報告できません。あなたのマネージャーのマネージャーを管理することはできません。

オプションのメタデータ

参加者リストのアップロード時に、任意のメタデータを追加することができます。各社員の誕生日から所属事務所の場所まで何でも含めることができる。ただし、親子階層の書式設定に役立つ 2 つのオプションのメタデータがあります。

  • 組織ユニット ID: 組織ユニット ID は、チーム名が変更された場合でも、時間の経過とともに同じチームを識別するのに役立ちます。これは、一意の従業員 ID と同じ目的で使用されますが、従業員ではなくユニットに対して使用されます。安定した組織ユニット ID を含めると、階層データをマニュアルでマッピングする必要がなくなります。ID が認識され、適切にマッピングされます。
    ヒント:同じ名前の別のチームがありますか?または、同じ部署内に別々のチームとマネージャーのレポートが存在しますか。個別の組織ユニット ID 項目を設定することで、同じ組織ユニットテキストを再利用することができます。たとえば、ある営業マネージャは組織ユニット ID 001 で販売というチームを実行し、別の販売マネージャは組織ユニット ID 002 で販売というチームを実行することができます。

    組織ユニット ID は、マネージャが複数のチームに属する場合にも役立ちます。つまり、マネージャが John Doe で、John Doe がチーム A およびチーム B のマネージャである場合は、ユニット ID 項目で自分が属するチームを指定することができます。

  • 組織ユニットの説明: 階層の作成時に、ユニット名が自動的にマネージャに付けられます。組織ユニットの説明設定では、代わりにユニットの名前または説明に基づいてユニットに名前を付けることができます。

組織ユニットの説明は、基本的に、指定した組織ユニット ID に対して指定された名前であり、ユニット別にフィルタリングまたは展開すると、ダッシュボードのユニットのラベルとして表示されます。カラムには必ずしも同じ正確な値が含まれている必要はありませんが、ID は数値ですが、Description は記述です。たとえば、組織 ID 2 の組織ユニットの説明はヨーロッパの部署である可能性があります。

例:下の画像では、John Doe は 2 つの異なるチーム(欧州部門と先導調査)を管理しています。組織ユニット説明列には、これらのチームのうち、3 人の直属の部下が属するチームが指定されます。Jill Davis と Joseph Miller は European Division に所属していますが、Sammy External は Lead Investigation にあります。

John Doe の直属の部下が、同じマネージャーの異なるチームに所属していることを示すために、組織ユニットの説明にさまざまな内容が書き込まれる CSV

ヒント:技術的には、[組織ユニット IDフィールド]と[組織ユニットの説明]に任意の名前を付けることができます。たとえば、組織ユニットの説明の代わりに、Unit NameTeam、または Department 列の名前を付けることができます。重要なのは、これらのコンセプトを含め、親 – 子階層を生成するときに正しい項目に入力することです

レベルベース階層の参加者のインポート

レベルベース階層は、HR データに、階層の上から下まで、従業員が管理する各レベルが含まれている場合に適しています。レベルベース階層では、必ずしも社員のマネージャーを把握する必要はありません。プロジェクトに含める各社員の指揮系統を把握するだけで済みます。このデータ形式は、さまざまなレベル、場所、または職務上の詳細区分に基づいて従業員データを編成する会社によく見られます。

ここをクリックして、レベルに基づく階層のテンプレートにアクセスします。

例:階層では、各参加者がダッシュボードで表示できるデータを管理することができます。たとえば、さまざまな場所に店舗があり、会社の賞を競い、参加者が自分のエンゲージメントダッシュボードを表示できるようにしますが、お互いのエンゲージメントダッシュボードを表示できないようにするとします。場所に基づいて階層を構築すると、後でダッシュボードの役割を構築したり、ダッシュボードのユーザー権限を設定したりするときに、各参加者に表示される場所のデータを制限することができます。

必要なメタデータ

定義する組織のレベルごとに個別の列が必要です。参加者に対して最後に入力されたレベルは、階層における参加者の位置を示します。上位の場合は、通常、第 1 レベル列が入力されますが、残りの列は入力されません。

例: 会社に、米国全体の所在地があるとします。レベル 1 には、事業所があるすべての州が含まれる場合があります。レベル 2 は、これらの事業所がある市区町村です。つまり、テキサス州ダラスのオフィスでは、レベル1がテキサス、レベル2がダラスである。テキサス州のレベル1の別の参加者には、ヒューストンのレベル2があるかもしれない。
レベル 1 がテキサスである参加者を含む CSV。ダラスにレベル2、ヒューストンにレベル2があるものもある。

マネージャーメタデータ

レベルベース階層でマネージャを単位に割り当てる場合は、2 つの異なる方法があります。

  • マネージャ: この列は、参加者がマネージャであるかどうかを示します。参加者は、自分が一覧表示した最下位レベルのマネージャーとして割り当てられます。ほとんどのユーザーは、マネージャーを示すために “yes” を使用しますが、参加者がマネージャーであることを示す列の値が 1 つであれば、”1″、”manager”、または任意の形式を使用することもできます。
    例:以下の図では、Sammy Stanage に対して定義された最下位レベルは、カスタマーサクセスの役割を担っているレベル 1 です。マネージャー列の「はい」は、カスタマーサクセスのマネージャーであることを示しています。一方、Jeff Brown の最後のレベルはエンジニアリング内の従業員エクスペリエンスです。つまり、エンジニアリング部門では、従業員エクスペリエンスレベルの責任者です。
    Jeff Brown のレベル 1 と 2 が入力されているのに対し、Sammy External のレベル 2 は空白の CSV です。
  • マネージャーレベル:マネージャーレベルは、管理している特定のレベルを呼び出すことでマネージャーを特定する手段です。前の例では、同じ値 (“yes”) は参加者がマネージャーであるかどうかを示していますが、Manager Level の場合は、レベルごとに異なる値があります。
    下の画像では、ジェフ・ブラウンの「マネージャーレベル」は、エンジニアリングにおけるレベル 1 のマネージャーではなく、従業員エクスペリエンスにおけるレベル 2 のポジションのマネージャーであることを示す 2 です。
    Jeff Brown のレベル 2 に値があり、マネージャーのレベルが 2 に設定された CSV

オプションのメタデータ

組織ユニット ID: 組織ユニット ID は、チーム名が変更された場合でも、時間の経過とともに同じチームを識別するのに役立ちます。安定した組織ユニット ID を含めると、階層データをマニュアルでマッピングする必要がなくなります。ID が認識され、適切にマッピングされます。これは、一意の従業員 ID と同じ目的で使用されますが、従業員ではなくユニットに対して使用されます。レベルごとに ID を指定できるように、実行するレベルと同じ数の組織ユニット ID を含める必要があります。

例: レベル 1 のユニットは、列組織ユニット ID 1 に対応します。財務はユニット 101、エンジニアリングは 123 などです。来年に階層をアップロードし、Finance を The Penny Patrol に名称変更した場合、同じ ID 101 を割り当てます。これにより、複数年分のエンゲージメントデータをダッシュボードでレポートするために、階層データを手動でマッピングする必要がなくなります。
レベル 1 と組織ユニット ID 1 が強調表示されます。
以下のスクリーンショットでは、レベル 2 のユニットは組織ユニット ID 2 の列に対応しています。Employee Experience エンジニアリングチームはユニット 201 で、Customer Experience エンジニアリングチームは 224 です。
レベル 2 列と組織ユニット ID 2 列が強調表示されます。
ヒント:技術的には、これらのメタデータ列を任意の名前で指定できます。たとえば、階層をロケーションに基づく場合、レベル 1、レベル 2、およびレベル 3 ではなく、国、都道府県/地域、および市区町村という名前の列を含めることができます。重要なのは、これらのコンセプトを含め、レベルベース階層を生成する際に正しいフィールドに入力することです。

スケルトン階層の参加者のインポート

スケルトン階層は、マネージャの ID は把握しているものの、直属の部下は把握していない場合に使用されます。直属の部下の一覧とその上のコマンドチェーンを中心に階層を編成するのではなく、マネージャーとロールアップ先のユニットの一覧を作成します。

ここでは、開始するスケルトン階層の例を示します。CSV/TSVを作成し、各マネージャーを含む行を作成します。スケルトン階層を構築するには、少なくともマネージャ情報が必要です。

マネージャーごとに、マネージャーのメール、および追加する任意の追加メタデータの列を追加します。次に、以下のメタデータを追加する必要があります。

  • 組織ユニット ID: 従業員が管理するユニットの ID。
  • 上位単位 ID: この単位のすぐ上にある単位の ID。これは、従業員の直属ユニットです。
  • 組織の説明:このメタデータはオプションです。これにより、従業員が管理するユニットの名前を作成することができます。チーム名や、マネージャの名前も指定できます。

例: 以下の例では、IT 部門はエンジニアリングがネストされている大きな部門です。John Doe は IT のマネージャであるため、組織ユニット ID 列に 1 と表示され、IT のユニット ID が 1 であることが示されます。Geoff Brown と Jill Davis はエンジニアリングのマネージャであるため、IT がエンジニアリングの親単位であることを示す親組織 ID は 1 です。

John Doe の組織ユニット ID 列に 1 と表示される CSV。Geoff Brown と Jill Davis の親組織 ID は 1 です。

ヒント:参加者ファイルはすでにインポートされていますか?階層の生成の詳細については、「親子階層の生成」サポートページを参照してください。

回答者と回答者の対比回答者以外

回答者は、アンケートに回答できる参加者です。回答者以外とは、アンケートにアクセスできない参加者のことです。一部の参加者を回答者以外にするのは、一部の参加者がダッシュボードの結果を表示したり、組織の階層を検証し、アンケートには記入させないようにする場合に役立ちます。

ヒント:参加の概要ウィジェットと回答率のウィジェットには回答者のみがカウントされます。

追加する参加者がプロジェクトの回答者であるかどうかを判断するには、[回答者]というヘッダーを追加し、次の値のいずれかを使用します。

  • 0 – 回答者以外
  • 1 – 回答者

ファイルに[回答者]列を含めない場合、すべての参加者がデフォルトで回答者として設定されます。

ヒント:[参加者]セクションの検索を使用して、プロジェクトの回答者を見つけることができます。
ヒント:参加者情報ウィンドウで、個々の参加者が回答者かどうかを調整できます。

最大文字とサポートされる文字

警告: 以前に、すべてのメタデータフィールドでフィールド名のスペースが認識されました。大多数のユーザーについて、メタデータフィールド名はスペースを無視するようになりました。つまり、「マネージャー ID」と「マネージャー ID」は、参加者ファイルをインポートする際に同じフィールドとして扱われます。
警告:どのメタデータフィールドにも予約済みの埋め込みデータフィールドと同じ名前を付けないでください。これらのフィールドでは、大文字と小文字が区別されません。

各フィールドの最大文字数

  • 名: 各名に対して 50 文字。
  • 姓: 姓ごとに 50 文字。
  • 電子メール: 各メールに 100 文字。
  • UniqueIdentifier: 一意の識別子ごとに 100 文字。
  • その他すべてのメタデータ: メタデータ名の上限はそれぞれ 90 文字、値の制限は 1000 文字です。

サポートされていない文字

次の文字は、メタデータ名または値のいずれでも使用できません:

|
 &
 ;
 $
 %
< >
 ( ) 
 { } 
 *
 +
 ,
 `

日付などの項目の値にはスラッシュ ( / ) を使用できますが、メタデータ項目名では使用できません。

FAQ

当サポートサイトの日本語のコンテンツは英語原文より機械翻訳されており、補助的な参照を目的としています。機械翻訳の精度は十分な注意を払っていますが、もし、英語・日本語翻訳が異なる場合は英語版が正となります。英語原文と機械翻訳の間に矛盾があっても、法的拘束力はありません。