記事テンプレート

階層を作るためのユーザーファイルの準備について

CXダッシュボードにユーザーをインポートする際、いくつか注意すべき点があります。例えば、すべてのインポートには以下の列が必要である：

• ファーストネーム：ユーザーのファーストネーム。
• 姓：ユーザーの姓。
• 電子メール：ユーザーのメールアドレス。このディテールが最も重要だ。Eメールは各ユーザのユーザ名として、またはユーザ管理ですでに存在するユーザを記憶する方法として機能します。
• Username:組織がSSOを使用する場合、Username列を含める必要があります。このカラムにはEmailカラムと同じ情報を含める必要がありますが、#brandIdは自動的に末尾に追加されるからです。
• 言語：この欄は厳密には任意である。ただし、これを含める場合は、以下のように言語コードを大文字にし、各ユーザーの値を言語コードで入力することに注意してください。

さらに、CSV/TSVファイルに含めるユーザー属性（ユーザーデータのカスタム列）にも影響するため、プロジェクトに適した階層を選択したことを確認します。例えば、親子階層ファイルには従業員IDとマネージャーIDのカラムを含める必要がありますが、レベルベース階層ファイルには異なるレベルのカラムを含める必要があります。

親子階層用のファイルの準備

親-子階層は最もよく使われる階層である。従業員のIDと各従業員がレポートするマネージャーのリストがあるように、人事データがフォーマットされている場合は、これらのオプションが最適です。

ファイルの構築が完了し、階層を構築する準備ができたら、親子階層の生成を参照してください。

必要なメタデータ

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

• 従業員ID：参加者の従業員IDです。新しくランダム化されたIDを作ろうとするのではなく、会社の人事部が社内で割り当てたIDを使うのがベストです。
• マネージャーID：参加者のマネージャーの従業員IDです。

従業員IDやマネージャーIDを追加する際には、いくつか注意すべき点があります：

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

オプションのメタデータ

参加者リストをアップロードする際に、ご希望のメタデータを追加することができます。各従業員の誕生日からオフィスの所在地まで、何でも記載することができる。しかし、親子階層をフォーマットするのに役立つオプションのメタデータが2つあります。

• 組織ユニットID：組織ユニットIDは、チーム名が変わっても、同じチームを識別するのに役立ちます。ITは、従業員ではなくユニットに対して一意の従業員IDと同じ目的を果たす。
  Qtip:同じ名前の異なるチームがありますか？それとも、同じ部署内でチームとマネージャーを別々にレポートさせているのでしょうか？組織単位IDフィールドを別々に設定することで、同じ組織単位説明を再利用することができます。例えば、あるマネージャーは組織ユニットIDが001のSalesというチームを運営し、別のマネージャーは組織ユニットIDが002のSalesというチームを運営することができる。

  マネージャーが複数のチームを統括している場合にも、Org Unit IDは役に立つ。つまり、私のマネージャーがJohn Doeで、John DoeがチームAとチームBのマネージャーである場合、私はユニットIDフィールドでどちらのチームに帰属するかを指定できる。

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

Org Unit Descriptionは、基本的に提供されたOrg Unit IDに対して提供された名前であり、ダッシュボードでユニット別にフィルターまたはブレイクアウトする際にユニットのラベルとして表示されます。IDが数値であるのに対し、Descriptionは説明的なものである。例えば、組織ID2の組織単位の説明は欧州部署である。

レベルベースの階層用のファイルの準備

階層ベースの階層は、従業員がレポートする各レベル（階層の最上位から最下位まで）が人事データに含まれている場合に適しています。レベルベースの階層では、必ずしも従業員のマネージャーを知る必要はなく、プロジェクトに参加させる各従業員の指揮命令系統を知るだけでよい。このデータ形式は、従業員データをレベル別、勤務地別、詳細区分別に整理している企業でよく見られます。

ファイルの構築が完了し、レベル階層を作成する準備ができたら、レベル階層を作成するを参照してください。

必要なメタデータ

定義したい組織のレベルごとに別の列が必要です。参加者の最後に記入されたレベルは、階層におけるその人の位置を示す。上位の選手にとって、これは通常、最初のレベル欄は埋まっているが、残りは埋まっていないことを意味する。

マネージャー メタデータ

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

• マネージャー：この欄は、参加者がマネージャーであるかどうかを示す。参加者は、自分が一覧表示した最下位レベルのマネージャーとして割り当てられます。ほとんどのユーザーは、マネージャーであることを示すために「はい」を使用しますが、参加者がマネージャーであることを示す列の値が1つであれば、「1」、「マネージャー」、または任意の形式を使用することもできます。
  例下の画像では、Sammy Stanageの最低レベルはレベル1で、カスタマーサクセスの役割に就いています。マネージャー欄の「はい」は、カスタマーサクセス全体のマネージャーであることを示している。一方、ジェフ・ブラウンが最後に定義したレベルは、エンジニアリング部門の従業員エクスペリエンスである。つまり、エンジニアリングの中では従業員エクスペリエンスレベルの責任者ということになる。
  
• マネージャーレベル：マネージャーレベルとは、マネージャーを識別するための手段であり、そのマネージャーが管理する特定のレベルを示すものである。前の例では、同じ値(“yes”)は参加者がマネージャーであるかどうかを示しますが、マネージャーレベルでは、レベルごとに別々の値があります。
  例下の画像では、ジェフ・ブラウンのマネージャーレベルが「2」になっています。これは、ジェフが「エンジニアリング」のレベル1のポジションのマネージャーではなく、「従業員エクスペリエンス」のレベル2のポジションのマネージャーであることを示しています。
  

オプションのメタデータ

組織ユニットID：組織ユニットIDは、チーム名が変わっても、同じチームを識別するのに役立ちます。ITは、従業員ではなくユニットに対して一意の従業員IDと同じ目的を果たす。レベルと同数の組織単位IDを含める必要があるため、各レベルにIDを提供できます。

以下のスクリーンショットでは、レベル 2 のユニットが Org Unit ID 2 列に対応しています。従業員エクスペリエンス・エンジニアリングチームはユニット201で、カスタマーエクスペリエンス・エンジニアリングチームは224です。

FAQ