階層の基本概要

階層について

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

階層は、エンゲージメント、パルス、および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」の場合、

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

そのほかの階層タイプ

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