従業員エンゲージメントサーベイの結果は具体的な問題を抽象化したもの。どう扱えばよいか？
こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
従業員の定着、活躍が重要な経営課題になっていることもあり、エンゲージメントサーベイを導入する企業が増えています。
このサーベイの取り扱いで特に気をつけることが必要なポイントがあるのです。それが具体と抽象の意図的な往復です。
従業員エンゲージメントサーベイとは？
従業員エンゲージメントサーベイは従業員エンゲージメントを計測するためのサーベイです。
従業員エンゲージメントは従業員が組織についてポジティブに捉え、共感し、強くコミットして働くような状態です。
詳しくはこちらを参照ください。
このサーベイでは主に
- 定量的なスコア
- 定性的なフリーコメントによるテキストフィードバック
を取得します。
従業員エンゲージメントサーベイに関する具体と抽象
現場には具体的な問題が存在する
サーベイのアンケートへの回答の前提として、各従業員は職場において多様な体験をしています。例えば評価における体験として、評価結果のフィードバックに満足している人もいれば不満な人もいるでしょう。
例えば、評価結果に対する説明に納得感がなかった、評価基準が曖昧で何をすれば評価してもらえるのかわからない、というような 具体的な理由 が存在するでしょう。
サーベイのアンケートを通して問題は抽象化される
具体的に存在していた問題は
- 定量的なスコア
- 匿名化し、そこまで詳細には記載されていないふわっとしたフリーテキスト
に抽象化されます。例えば、評価に関わる設問があった場合、特定部門の評価に対する体験のスコアが低い、という大雑把な課題感であったり、その不満に関して匿名のフリーテキストで記載された「評価に納得できない」のような内容としてフィードバックされてきます。
スコアのみだと問題はかなり抽象化されていますし、フリーテキストはどのくらい詳細に書いてもらえているかに依存します。
サーベイのアンケートを分析する際に問題を具体化する必要がある
エンゲージメントサーベイは組織改善のための取り組みです。
結果をもとに組織改善をすることになるのですが、ここでやりがちなのが
- スコアやコメントの背景にある個別具体的な原因を確認せずに推測で問題を特定したことにして、推測で選んだ問題に対する解決策を実施する
というアクションです。これはかなり当てずっぽうになるので、的中するとは限りません。
そのため、実際は改善対象の問題に対する仮説を立てたら従業員を巻き込んだリサーチによって本当に問題が存在するか確認をする必要があるのです。以下の記事のステップ3「問題の存在確認」の部分です。
存在の確認方法は複数考えられます。例えば
- 1on1
- Employee Journey Map の作成
- グループワーク
- 追加調査アンケート
などです。これらの手法で従業員の生の声を集め、問題の存在を確認します。
※なお、スコア傾向やフリーテキストの内容から推測ベースでも「ほぼ間違いなくあの問題だ」と断定できるケースもあるでしょう。その場合は、存在確認のステップをショートカットしてもよいでしょう
まとめ
この記事の読者は開発関係者が多いでしょうから、ソフトウェア開発に当てはめて考えてみます。
例えば、バグが見つかったとします。エラーメッセージは大枠のエラーの分類だけが記載されていたとします。
このとき、このエラー分類の情報だけをヒントにバグ修正の方針を決め、修正プログラムを実装する。なんなら、バグの解消有無の確認もしない。
それが、
- サーベイ結果の裏にある具体的な問題を確認せずに解決策を実施し、実施結果の確認もしていない
という行為なのではないでしょうか。
開発でいうところのエラーログを確認し、場合によってはデバッガーを利用するなどしてエラー原因を特定し、想定される期待値を確認したらそれを元にテストケースを作成し、テストがエラーになることを確認し、テストが通るような修正をする。こういったプロセスが組織課題の解決にも必要となるのでしょう。もちろん、開発ほど全てをプロセス通り、定量的に行えるとは限りませんが、できる限り近いアプローチが好ましいでしょう。
おすすめ書籍
具体と抽象の往復については、書籍「 具体と抽象 」がおすすめです。
