パルスサーベイ考(後編) - 月次サーベイの実例
今回は、前回の議論に続き実際にDeNAで行なっているパルサーベイの事例を見ていきます。
コンセプト
わたしたちのパルスサーベイは以下の体験を提供するものであることを目指しています。
マネジャーにとっては、メンバーの変化に気づき対話のきっかけとなるものであること
メンバーにとっては、ふりかえりの機会となること。その際の回答コストがミニマムであること
上位マネジャーや担当人事にとっては組織の状態の俯瞰した視点から可視化されたものであること
よって、記名式で直上長にも共有する形をとっています。また、後述しますが、グループリーダー(いわゆる課長レベル)での相互の議論を活性化するために同じ部の配下であれば隣のグループの情報は見えるよう設計されています。
結果、見られることによる一定のバイアスはかかる形となり、例えば従業員からのHRへのホットライン的な役割は果たしにくい構造となっています。
設問の設計
現在のところ、設問は以下の2問としています。実施スパンは月に一回、月末付近に行なっています。
定量設問 - 今月のやりがいはどうだったか - 1(低)〜7(高)の7段階
定性設問 - 上記の理由やふりかえりを記述してください
回答者の負荷を考えると可能な限りミニマムであるべきです。とくに定量設問は直行する要素以外は避けるべきでしょう。
一般的に設問は増える傾向にあります。増やしたくなる傾向、というのが正確な表現でしょうか。例えば、会社のパーパスの共感だったりバリューの体現だったり、つどつどの課題意識から設問をふやすアイデアは思いつくのですが、前回の議論のとおり、サーベイはとるだけで課題を解決するものではなく、後工程までつなげてはじめて成果となるものです。また、回答者にとってはその瞬間にありがたみを感じられるものではないため、回答コストへも目を配る必要があります。よって、設問追加の議論がおきた場合は、その設問が、①直行する要素であるか(現在の設問に全く内包されないものであるか)、②後工程までデザインしきれるか(レポーティングのレイアウトや担当人事によるガイダンスまで仕切れるか)、の2点で考えるようにしています。その2点を満たさない場合は安易に混ぜるべきではなく、他のやり方を検討する方が適当です。
スケールの問題
定量設問の回答方法では、最も一般的なのはリッカートスケール(リッカート尺度)と呼ばれる5段階のスケールでしょう。宣言文への同意のレベルを聞く回答スケールで、その名称は知らずとも多くの方にとって以下の回答は親しみがあるのではないでしょうか
1. 全くそう思わない
2. そう思わない
3. どちらとも言えない
4. そう思う
5. 強くそう思う
上記の回答セットは理解しやすいため回答コストが低い一方で、「やりがい」やムードのような、ソフトかつ、一般的にプラス方向の圧を受ける要素を問う時に4点に集中し月次で変化が起きにくいという課題がありました。『変化に気づく』というコンセプトを実現するため、月次でのわずかな変化を表現されるよう7段階としました。そうすることで、4点を「どちらとも言えない」と位置づけた上で、ポジティブ回答の範囲を5〜7と広げ、5点6点でのアップダウンが可視化されるように意図しています。
余談ですが、スケール設定も議論がつきない点で、NPSのような10段階(または0点もいれた11段階)や、中央にニュートラルを置かず必ずどちらかのスタンスをとるよう促す6段階とする考え方もあります。わたしたちも議論の末、回答者が迷いすぎず(例えば、10段階での6点7点はどういう意味か?等)、かつ実情をもっとも表現できるスケールという意味で、ニュートラルを残した7段階の形を選択しました。
メトリクスであり追うべき指標ではない
やや脱線しますが、「キャンベルの法則」という概念があります。
パルスサーベイの結果も数ヶ月続けていくと端的に組織の状態を可視化するメトリクスとして有効なことが見えてきます。その段階において大切なのが、これはあくまで状態を可視化する指標であり、目指すものでないこと、と共有認識とすることです。とくに、わたしたちの行なっているような記名式であると、スコアが悪い部署のマネジャーにプレッシャーがかかった結果、メンバー当人に圧力が働く、という展開がおきえる構造となっており、その点は繰り返しアナウンスしていっています。1on1で話す際も、スコアについて「今月は2ポイント下がってるけどなんで?」とは聞かずに、あくまでふりかえりに書かれた内容を参考に次へつなげる話す形を推奨しています。
ビューアーの設計
サーベイ結果を閲覧するために内製のウェブアプリを開発しました。これは、頻繁な組織変更に追随すること(csvダウンロード等の手作業をかけずに基幹データと連携すること)。また、子会社が増えたり、マネージャーが複数部署を兼務しているようなケースに対応すること、を要件として、当初は外部ツールの導入の含め検討していましたが、結局運用コストが膨らんでしまったり、ツールの制限によりやりたいことができなくなる懸念が少なくないことが分かり、内製開発に踏み切りました。
3つのビュー
マネジャー向けに3つのビューを提供しています。どういう順番で見てもらいたいか、どこに着目してもらいたいかでアプリへのランディングからのユーザー体験をチューニングしています。
グループビュー
グループ全体のコンディションの状況と、各人の定性コメントを表示したもので、直接マネジメントを行うグループリーダー層にとってはランディングページとなります。
個人ビュー
個人の推移を表現するものです。グループビューのメンバー名をクリックすると遷移するようになっています。また、評価ツール等、わたしたちのチームが提供する他のアプリからも導線が貼られています。
比較ビュー(配下グループ比較・過去比較)
間接マネジメントを行う部長以上にとっては配下グループの状況を俯瞰する配下グループ比較ビューがランディングページになります。また、グループ全体として過去からの状況変化を俯瞰するための過去比較ビューも用意しています。
なお、こういった分布を提示した場合どうしてもコンディションの低い層に注意がいくのですが、そうではなくスコアが高い層の割合をに着目してもらうべくスコア6点のところにラインを引き、割合を表示しています。
閲覧スコープの考え方
閲覧スコープにも一工夫加えています。なぜなら、繰り返しになりますがサーベイはとっておわりではなく、そこから議論が深まり次の変化につながってこそ効果がでるものであるため、マネジャー同士がお互いに意見を言い合いよりよい組織改善につなげるため、同じ部であれば横のグループの情報を閲覧可能としています。これにより縦のラインだけでなく横のラインでも連携して議論することを促しています。
まとめ
よいパルスサーベイを行うためには以下の3点が重要と考えています。
コンセプトを決める。何を重視し何を捨てるか
コンセプトを実現するためにどれだけミニマムにできるか
レポーティングから後工程までをどうデザインするか
今回はわたしたちが現在行っている例を紹介しました。もちろん、私たちもこれが完全な姿と思っているわけではなく、課題はあり、日々改善を続けていきたいと考えています。もしこの記事がなんらかヒントになったり、「うちではこんなことをしている」といった事例があったらぜひお話しを聞いてみたいです。どうぞよろしくおねがいします。
次回〜データ連携と権限の設計
ビューワーのお話で終えたので、次回はこういったツール化をする上での基幹データとの連携および権限の設計について話します。とくに権限の設計は、人事データの特性上、肝となってくる部分です。また日々の組織変更に追随するため可能な限り自動化して閲覧範囲を追随していくことが必要となってきます。実例としてどのように管理しているかを紹介したいと思います。
この記事が気に入ったらサポートをしてみませんか?