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

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

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

Employee Experienceプロジェクトに参加者をインポートする際には、留意すべき重要な点がいくつかあります。例えば、階層の種類に関係なく、参加者をインポートする際には必ず以下の列が必要になります。

• 名：従業員の名。
• 姓: 従業員の姓。

• メール：従業員のメールアドレスです。この詳細は最も重要です。メールアドレスは、各参加者のユーザー名として、または ディレクトリにすでに存在するユーザーを記憶する方法として機能します。

  

  注意：参加者ファイルのメールアドレスのフィールドが空白の場合、個人情報を補完するためのプレースホルダーとして、UniqueID@BrandID.fakeという形式の架空のメールアドレスが生成されます。生成されたメールアドレスは架空のものであるため、有効なアドレスに更新されるまで、参加者にEX配信は送信されません。ただし、所属する組織でSSOを使用している場合は、参加者をアップロードする際に有効なメールアドレスを含めて、ユーザー名が正しく自動生成されるようにする必要があります。

• UniqueIdentifier: 貴社が希望する任意の識別子で参加者を指定します。社内数値ID、ユーザー名、EmployeeID列の繰り返しなど、あらゆるものを使用できます(ただし、組織内で一意であり、他のプロジェクトの誰とも共有されない場合に限ります)。詳細については、一意の識別子のサポートページをご確認ください。

ヒント：組織でSSOを使用している場合は、プロジェクトに参加者をアップロードする前に、SSOのユーザー名属性と一致するUserNameの列を付けて、参加者をディレクトリにアップロードしてください。

ヒント：EXアンケートをSMSで配信する場合は、「Phone number」または「Phone」という名前の列を追加し、電話番号の書式設定ルールに従ってください。

エンゲージメントプロジェクトを作成する場合、CSV/TSVファイルに含める参加者データのメタデータ (カスタム列) に影響するため、プロジェクトに適した階層を選択したことを確認する必要があります。例えば、親子関係の階層ファイルには従業員 ID とマネージャー ID の列を含める必要がありますが、レベルベースの階層ファイルには、さまざまなレベルの列が必要です。このページでは、各階層に含める必要があるメタデータについて説明します。

ヒント：プロジェクトには複数の階層を設定できますが、各メタデータフィールドで生成できる階層は1つだけです。例えば、最初の階層の構築に「ManagerID」を使用した場合、2つ目の階層の構築に同じフィールドを使用することはできません。

最初に正しいメタデータを含めるのを忘れても問題ありません。リンク先のセクションの手順に従うことで、後からいつでも参加者のメタデータを更新 できます。

ヒント: ファイルをアップロードする準備はできていますが、方法がわかりませんか？ このページの指示に従って階層ファイルを設定したら、参加者の追加のサポートページに移動してください。

ヒント: どのタイプの階層が人事データに最適かわからない場合。各オプションの基本的な比較については、階層の基本概要ページでご確認ください。

注意：参加者のインポートで参加者情報（氏名やメールアドレスなど）を更新しても、組織階層のユニット名は更新されません。ユニット名を更新するには、［参加者］タブのユニットインポート機能を使用する必要があります。詳細については、参加者のエクスポートおよびインポートオプション(EX)を参照してください。

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

親子階層は、最も一般的に使用される種類の階層です。人事データが、従業員 ID のリストと各従業員が報告する上司のリストで構成されている場合に最適なオプションです。

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

必須メタデータ

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

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

例： 下の画像では、 ジョン・ドウのEmployeeIDは1であるため、彼のEmployeeID列には1と表示されています。ジル・デイビス、サミー・エクスターナル、ジョセフ・ミラーはジョン・ドウの直属の部下であるため、彼らのManagerID列には1と表示されています。

---

×

close

ヒント： 技術的には、EmployeeID と ManagerID には任意の名前を付けることができます。たとえば、組織が「従業員番号」という用語を好む場合や、「QID」のような特別な用語を使用している場合は、列にこれらの名前を自由につけることができます。重要なのは、親子階層を生成する際に、これらの コンセプトを含め、正しいフィールドに入力することです 。

従業員IDとマネージャーIDを追加する際には、留意すべき重要な点がいくつかあります。

• データの一意の識別子 列は、親子階層を生成する際の従業員IDフィールドとして使用できます。その状況における前述の例は、次のようになります。
   

  

  ---

  ×

  close
• 各参加者には、一意の従業員 ID も必要です。複数の参加者が同じIDを共有することはできません。一意の識別子と同じにすることができます。
• すべての参加者にマネージャーが必要です。唯一の例外は、階層に含まれる会社の最上位メンバー（CEOなど）です。このユーザーが誰にもレポートしないことを示すには、マネージャーの列を空欄のままにします。
• 個々の従業員の従業員IDとマネージャーIDの列が同じにならないようにしてください。従業員が自分自身に報告することはできません。
• すべてのManager IDは、従業員にリンクしている必要があります。マネージャーIDが既存の従業員IDと一致しない参加者は、不明なマネージャーに割り当てられます。不明なマネージャーに誰かが割り当てられると、その人より下の階層のメンバーも壊れてしまうことに注意してください。この問題を解決するには、手動でデータを修正し、階層を再生成する必要があります。
• 循環ロジックにご注意ください。ジョン・ドウがジェーン・スミスに、ジェーン・スミスがジョセフ・ミラーに報告する場合、ジョセフ・ミラーがジョン・ドウに報告することはできません。マネージャーのマネージャーは管理できません。

任意のメタデータ

参加者リストのアップロード時に、任意の追加メタデータを追加できます。各従業員の誕生日からオフィスのlocationsまで、あらゆる情報を含めることができます。ただし、親子階層の形式設定に役立つ2つの任意のメタデータがあります。

• 組織ユニットID: 組織ユニットIDを使用すると、チーム名が変更された場合でも、長期にわたって同じチームを特定できます。従業員固有 ID と同じ目的を果たしますが、従業員ではなくユニットに対して使用されます。安定した組織ユニット ID を含めることで、階層データを手動でマッピングする必要がなくなります。システムが ID を認識し、適切にマッピングします。組織ユニット ID は、マネージャーが複数のチームを管理している場合にも役立ちます。つまり、自分のマネージャーがジョン・ドウで、そのジョン・ドウがチームAとチームBの両方のマネージャーである場合、Unit IDフィールドを使用して、直属の部下がどちらのチームに所属しているかを指定できます。

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

  

  ヒント：組織ユニットの説明は、マネージャーではなく、直属の部下からの情報に基づいて作成されます。

組織ユニットの説明は、特定の組織ユニット ID の名前として機能し、ダッシュボードでユニットによる絞り込みや内訳表示を行う際に、そのユニットのラベルとして表示されます。例えば、組織 ID 2 の組織ユニットの説明は「欧州部署」となります。  各ユニット ID につきユニットの説明は  1 つのみ設定でき、その逆も同様です。同様に、従業員が同じ組織ユニットに所属している場合は、その説明を一致させる必要があります。

例：下の画像では、ジョン・ドウは欧州部署とリード調査という2つの異なるチームを管理しています。組織ユニットの説明列は、彼の3人の直属の部下がこれらのチームのどれに所属しているかを指定します。ジル・デイビスとジョセフ・ミラーはヨーロッパ部署に所属していますが、サミー・エクスターナルはリード調査に所属しています。

---

×

close

例：下の画像では、ジルとジョセフはどちらも「ヨーロッパ部署」に所属しており、その組織ユニットIDは2です。両者の組織ユニットの説明と組織ユニットIDが、それぞれ一致している点にご注目ください。
 

---

×

close

ヒント： 技術的には、組織ユニットIDと組織ユニットの説明のフィールドに任意の名前を付けることができます。たとえば、列の名前を組織ユニットの説明ではなく、ユニット名、チーム、部署などにすることができます。重要なのは、これらの コンセプトを含め、 親子階層を生成する際に正しいフィールドに入力することです。

レベルベースの階層に参加者をインポートする

レベルベースの階層は、階層の最上位から従業員が所属する部署まで、従業員が報告する各レベルが人事データに含まれている場合に適したオプションです。レベルベースの階層では、従業員のマネージャーが誰であるかを必ずしも知る必要はありません。プロジェクトに含まれる各従業員の指揮系統を把握するだけで済みます。このデータ形式は、従業員データを異なるレベル、場所または機能に分けて組織立てている企業でよく見られます。

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

例：階層を使用すると、各参加者がダッシュボードで閲覧できるデータを管理できます。例えば、社内賞をかけてさまざまなlocationsにある店舗が競い合っているとします。この場合、参加者が自分のエンゲージメントダッシュボードは閲覧できても、他の参加者のダッシュボードは閲覧できないように設定したいとします。ロケーションに基づいて階層を構築すると、後でダッシュボードの ロールを作成したり、 ダッシュボードユーザーの権限を設定したりする際に、各参加者が閲覧できるロケーションのデータを制限できます。

必須メタデータ

定義する組織の各階層に対して、個別の列が必要になります。参加者に対して入力された最終レベルは、その参加者の階層内での位置を示します。上位の階層では、通常、最初のレベルの列は入力されていますが、残りの列は入力されていません。

例：貴社が米国内に複数のlocationsを展開しているとします。レベル1には、オフィスが所在するすべての州が含まれる場合があります。次に、Level 2をこれらのオフィスが所在する都市にすることができます。これは、テキサス州ダラスのオフィスにいる参加者のLevel 1がテキサス、Level 2がダラスになることを意味します。Level 1がテキサスである別の参加者のLevel 2は、ヒューストンである可能性があります。
 

---

×

close

ヒント： 技術的には、これらのメタデータ列に好きな名前を付けることができます。たとえば、階層を場所に基づいて作成する場合、列名を「Level 1」、「Level 2」、「Level 3」ではなく、「国」、「都道府県/地域」、「市区町村」などにすることができます。重要なのは、これらの概念を含め、レベルベースの階層を生成する際に正しいフィールドに入力することです。

マネージャーのメタデータ

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

• マネージャー: この列は、参加者がマネージャーであるかどうかを示します。参加者は、自分が一覧表示した最下位レベルのマネージャーとして割り当てられます。ほとんどのユーザーは「yes」を使用してマネージャーを示しますが、「1」や「manager」、または任意の形式を使用することもできます。ただし、列には参加者がマネージャーであることを示す値を1つ設定する必要があります。

  

  例：下の画像では、サミー・スタナゲに定義されている最下位レベルはレベル1で、カスタマーサクセスの役割を担っています。彼の「マネージャー」列にある「はい」は、彼がカスタマーサクセス全体のマネージャーであることを示します。一方、ジェフ・ブラウンの最終レベルは、エンジニアリング内の Employee Experience として定義されています。これは、エンジニアリング部門において、彼が Employee Experience レベルの責任者であることを意味します。
   

  

  ---

  ×

  close

• マネージャーレベル: マネージャーレベルは、マネージャーが管理する特定のレベルを明示することで、マネージャーを識別する手段です。前の例では、同じ値(「yes」)が参加者がマネージャーであるかどうかを示しています。一方、マネージャーレベルでは、レベルごとに個別の値が存在します。

  

  例： 下の画像では、ジェフ・ブラウンのマネージャーレベルは2になっています。これは、彼がエンジニアリングのレベル1の役職のマネージャーではなく、Employee Experienceのレベル2の役職のマネージャーであることを示しています。
   

  

  ---

  ×

  close

任意のメタデータ

組織ユニットID：組織ユニットIDを使用すると、チーム名が変更された場合でも、同じチームを継続的に識別できます。安定した組織ユニット ID を含めることで、階層データを手動でマッピングする必要がなくなります。システムが ID を認識し、適切にマッピングします。従業員固有 ID と同じ目的を果たしますが、従業員ではなくユニットに対して使用されます。レベルと同じ数の組織ユニットIDを含める必要があります。これにより、各レベルにIDを提供できます。

レベルベースの階層では、各レベルに一意の組織ユニット ID 列が必要です。例えば、組織に「Level 1」と「Level 2」の2つのレベルがある場合、組織ユニットID用に2つの列が必要になります。1つは「Org Unit ID 1」で、Level 1に属するすべての人の組織ユニットIDを含みます。もう1つは「Org Unit ID 2」で、Level 2に属するすべての人の組織ユニットIDを含みます。また、組織ユニットのフィールド名を再利用しないように注意する必要があるため、番号を付けることをお勧めします。

例：レベル1のユニットは、列「組織ユニットID 1」に対応します。財務はユニット101、エンジニアリングは123、といった具合です。来年、階層をアップロードして「Finance」を「The Penny Patrol」に名称変更した場合、ダッシュボードで複数年分のエンゲージメントデータをレポートするために階層データを手動でマッピングする必要がないように、同じ ID「101」を付与します。
 

---

×

close

以下のスクリーンショットでは、Level 2のユニットが列「Org Unit ID 2」に対応しています。Employee Experienceエンジニアリングチームはユニット201、Customer Experienceエンジニアリングチームは224です。
 

---

×

close

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

スケルトン階層は、マネージャーはわかっているものの、その直属の部下が不明な場合に使用します。直属の部下やその上にある指揮系統のリストを中心に階層を構成するのではなく、マネージャーとそのマネージャーが属するユニットのリストを作成します。

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

各マネージャーについて、マネージャーの名、姓、メールアドレス、 および追加したいメタデータの列を追加します。次に、以下のメタデータを追加する必要があります。

• 従業員 ID: 従業員が管理するユニットの ID。
• マネージャー ID: このユニットの直属の上位ユニットの ID。これは、従業員が所属するユニットです。
• 組織の説明: このメタデータは任意です。従業員が管理するユニットの名前を作成できます。チーム名やマネージャー名などを指定できます。

例：以下の例では、ITはより大きな部門で、エンジニアリングはその下にネストされています。ジョン・ドウはIT部門のマネージャーであるため、[従業員 ID] 列にはIT部門のユニットIDが1であることを示す「1」が記載されます。ジェフ・ブラウンとジル・デイビスはエンジニアリング部門のマネージャーであるため、両者の [マネージャー ID] は「1」となり、IT部門がエンジニアリング部門の親ユニットであることを示します。

---

×

close

ヒント： 参加者ファイルはすでにインポートされていますか？階層の生成に関する詳しい手順については、親子階層の生成 のサポートページにアクセスしてください。

回答者 vs. 未回答者

回答者は、アンケートに回答できる参加者のことです。未回答者とは、アンケートにアクセスできない参加者のことです。ダッシュボードの結果の閲覧や組織階層の検証は許可するものの、アンケートへの回答は不要な参加者がいる場合、その参加者を未回答者として設定すると便利です。

ヒント：回答状況の概要ウィジェットと回答率ウィジェットでは、回答者のみがカウントされます。

追加する参加者がプロジェクトの回答者であるかどうかは、Respondent というヘッダーを追加し、次のいずれかの値を使用することで指定できます。

• 0 – 未回答者
• 1 – 回答者

ファイルに「回答者」列を含めない場合、新しい参加者はすべて、デフォルトで回答者として設定されます。プロジェクトにすでに参加しているユーザーのステータスは、指定された場合にのみ更新されます。

ヒント：参加者セクションの検索機能を使用して、プロジェクトの回答者を見つけることができます。

ヒント：個々の参加者が回答者であるかどうかは、参加者情報ウィンドウで調整できます。

最大文字数と対応文字

警告: これまで、すべてのメタデータ項目で項目名のスペースが認識されていました。大多数のユーザーにおいて、メタデータフィールド名でスペースが無視されるようになりました。つまり、参加者ファイルをインポートする際に、「Manager ID」と「ManagerID」は同じフィールドとして扱われます。

警告:予約済みの埋め込みデータフィールドと同じ名前をメタデータフィールドに付けないでください。これらのフィールドでは、大文字と小文字が区別されません。

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

• 名：各名について50文字まで。
• 姓: 各姓は 50 文字までです。
• メールアドレス：各メールアドレスは100文字までです。
• UniqueIdentifier: 各一意の識別子につき 100 文字。
• その他すべてのメタデータ：メタデータ名はそれぞれ 90 文字、値はそれぞれ 1000 文字に制限されています。

ヒント: 通常、1 バイトは 1 文字に相当します。ただし、中国語、韓国語、日本語の文字には、最大3バイトになるものがあります。

無効な文字

注意：参加者インポーターではこれらの文字をインポートできる場合がありますが、クアルトリクスプラットフォームの他の部分でエラーが発生する可能性があるため、可能な限り使用しないことをお勧めします。

絵文字などの非BMP文字は使用できません。

また、メールアドレスには全角のアットマーク(＠)を使用できず、標準のアットマーク(@)を使用する必要があります。

一意の識別子に波括弧(例: { および})を含めることはできません。

行、セル、フィールドに波括弧またはバックスラッシュ(\)を含めることはできません。

名、姓、メールアドレス、またはユーザー名に以下の文字は使用できません。

†¬?=;~!&*%{}<>|"\^

ヒント：ベストプラクティスとして、フィールドに関係なく上記の特殊文字を避けることをお勧めします。

制限付きメタデータフィールド名

参加者ファイルにこれらの名前またはプレフィックスを持つフィールドが含まれている場合、これらのフィールドはインポートされず、データはスキップされます。

以下のメタデータフィールド名は使用できません。

finished
q_units
sid
responsesetid
rid
threesixtyid
enddate
auditable
personid
_cacheddate
userid
_recordid
firstname
_recordeddate
lastname
_enddate
email
_startdate
userpassword
_sourceid
password
_sourcemapid
external
_sourcetype
q_primaryunits
uniqueid
uniqueidentifier
loginname

以下のプレフィックスはメタデータフィールド名に使用できません。

ステートメント 
raw_statement 
_