Qualtrics Platform
Customer Journey Optimizer
XM Discover
Qualtrics Social Connect

階層の基本概要

階層について

階層の利用により、組織の従業員構造をクアルトリクスにアップロードすることができます。階層は従業員エンゲージメントプロジェクトにおいて重要な機能であり、正しく設定することで、ダッシュボードでマネージャーやユニットごとにデータを表示することができます。

階層は、エンゲージメント、パルス、およびCXダッシュボードに追加できますが、ライフサイクルまたはアドホック従業員調査プロジェクトには追加できません。

CXダッシュボードにおける静的階層 vs. 動的階層

注意：この情報が該当するのは、CXダッシュボードプロジェクトに組織階層を追加する場合のみです。エンゲージメントまたはパルスプロジェクトを使用している場合は、このページの次のセクションに進んでください。

CXダッシュボードに組織階層を追加するには、データセットにユーザーの一意の識別子を含める必要があります。インポートデータプロジェクトにデータをアップロードする場合、各ユーザーの一意の識別子を持つ列をCSVファイルに含めるだけで簡単に実現できます。

しかし、アンケートプロジェクトで作業している場合は、ダッシュボードにマッピングする前に、正しい情報がアンケートに取り込まれていることを確認する必要があります。これを行うには2つの方法があります。

静的階層

静的階層では、階層情報を追加の埋め込みデータとしてアンケート回答データに直接追加できます。つまり、階層情報はアンケートを実施した時点で回答に追加されるため、データを収集した後に階層に調整が加えられた場合、階層の更新は将来の回答データにのみ反映されます。

詳しくは静的階層を参照してください。

動的階層

動的階層では、アンケートの回答そのものではなく、階層をダッシュボードのデータにリンクさせることができます。その結果、階層が変化した場合、それがダッシュボードのデータにも反映されることになります。

回答内の一意の識別子と階層内の一意の識別子を照合することで、階層情報が回答とリンクされます。そうして階層情報はダッシュボードのデータと照合されます。階層が更新されると、自動的にダッシュボードのデータとの照合が行われて動的な更新が実現します。

動的階層を実装するには、まず、階層内のユーザーの一意な識別子と一致する一意な識別子が回答に含まれていることを確認します。詳しくは、動的階層を参照してください。

回答に一意の識別子が含まれている場合、組織階層をCXダッシュボードに追加する手順に従ってください。

データに最適な階層を選択

階層は、親子階層（CX|EX）とレベルベース階層（CX|EX）の2つの主なタイプに分けられます。親子階層とレベルベース階層のどちらを利用しても、従業員リストに基づいて組織構造を生成し、マネージャーを特定することができます。選択する階層のタイプは、会社組織の構造よりも、どのデータを最も便利に利用できるかによって決まります。

親子階層とレベルベース階層の比較

親子階層（CX|EX）は、エンゲージメントプロジェクトで最もよく利用されているタイプの階層で、一般的に設定がより簡単です。親子階層は、各従業員の人事データに一意のIDと従業員のマネージャーのIDが含まれている場合に最も効果的に機能します。

例：スプレッドシートのデータがあり、各行が従業員の1人のデータとなっています。各従業員には、従業員IDの列とマネージャーのIDの列があります。

レベルベース階層（CX|EX）は、CXダッシュボードの階層でより頻繁に利用されます。従業員が所属する各階層（階層トップから従業員本人まで）が人事データに含まれている場合は、良い選択肢となります。レベルベース階層では、必ずしも従業員のマネージャーを把握する必要はなく、プロジェクトに含めたい各従業員の指揮命令系統を把握するだけですみます。このデータ形式は、従業員データを異なるレベル、場所または機能に分けて組織立てている企業でよく見られます。

例：佐藤さんは、営業オペレーションチームのメンバーです。このチームが所属しているのは営業部署で、この営業部署はクアルトリクスの従業員エクスペリエンス製品を販売する部門に属しています。従業員データファイルの佐藤さんの行には、部署の列に従業員エクスペリエンス、部署の列に営業、そして次の列に営業オペレーションと記載されています。

レベルベース階層が親子階層よりも優れている点は、不完全な階層でプロジェクトを実行する場合です。たとえば、会社全体ではなく数チームだけでプロジェクトを運用することもあります。親子階層では、すべての従業員とマネージャーをそれぞれ組織ユニットに配置することで指揮命令系統を決定するため、従業員が欠けるとユニットが壊れたり位置がずれたりする可能性があります。一方、レベルベース階層では、各従業員を一列で定義し、従業員の指揮命令系統を一番上まで示します。指揮系統が含まれているため、従業員が何人か欠けても問題にはなりません。

ただし、マネージャーを定義するには、親子階層の方が格段に簡単です。レベルベース階層でマネージャーとマネージャーにロールアップするデータを特定することも可能ではありますが、そのためにはデータに列を追加し、階層を下にたどってマネージャーが管理するユニットまでマネージャーをコード化する必要があります。

階層が生成される仕組み

クアルトリクスは、裏でどのように階層を構築しているのでしょうか。参加者ファイルをアップロード（CX|EX）する際、各行がそれぞれ異なる従業員を表します。クアルトリクスは、リストを下にたどっていきながら各従業員を特定し、その従業員に付随する情報（マネージャー、組織ユニット、レベルなど）を使って、その従業員が組織のどのユニットに属しているかを判断します。

例：ファイルの最初の行は、従業員「山田花子」の情報となっています。山田さんのIDが「i322」で、山田さんのマネージャーのIDが「i205」の場合、

「マネージャーi205」のユニットを作り、その中に山田さんを入れます。
ファイルをさらに見ていくと、従業員「i205」の名前は「佐藤次郎」であることがわかります。これで、山田さんが所属するユニットは佐藤さんの管理下にあることがわかり、「マネージャーi205」のユニットの名前は「佐藤次郎」に変更できます。
さらに、佐藤さんのマネージャーが誰かを確認し、その情報を使うことで、佐藤さんの管理下にあるユニット、および佐藤さんが所属するユニットを階層の適切な位置に配置することができます。

ファイルは、特に決まった順番（たとえば従業員の最下位から最上位までなど）で記載されている必要はありません。クアルトリクスは、ファイル内の従業員リストを上から下へと順に処理しながら階層を構成していきます。最も重要なのは、階層内の必要な従業員が全員そろっていて、指揮命令系統に循環論理が存在しないことです（たとえば、佐藤さんが山田さんのマネージャーである場合、佐藤さんのマネージャーが山田さんであってはなりません）。

そのほかの階層タイプ

階層には、親子階層とレベルベース階層のほかに2つのタイプがあります。あまり使われることはないものの、プロジェクトによってはニーズにかなう可能性もあります。

スケルトン階層： このオプションは、直属部下がわからない（または直属部下の正体を明らかにしたくない）一方で、誰がマネージャーなのかが分かっている場合に最適です。この階層は、全従業員と従業員が所属するユニットのリストではなく、マネージャーとマネージャーが管理するユニットのリストを中心に構成されるため、親子階層やレベルベース階層とは大きく異なります。
アドホック階層（CX|EE）： アドホック階層は、必要最低限の参加者情報だけで実現できるため、利用しやすいように考えられがちです。しかし、親子階層やレベルベース階層の利点は、参加者データの詳細ファイルを作成（CX|EE）すれば、いくつかの簡単な操作で階層が完成することにあります。一方、アドホック階層では、すべての参加者を適切な階層ユニットに手動で配置し、すべてのマネージャーとユニットを手動で設定する必要があります。この方法は、参加者リストが非常に短い場合を除いて一般的にはお勧めしません。この機能はパルスプログラムとは互換性がありません。