2023年3月30日
ヒヤリハットから学ぶ データ分析の注意ポイント
当社は、これまで多くのデータ分析のプロジェクトを実行してきました。大きな問題が生じることはありませんが、細かい失敗やヒヤリハットの経験はあります。今回は、そうした小さな失敗と、そこから得られる学びを紹介します。
1．成果指標を覆されたケース
あるプロジェクトにおいて、人事部と成果指標の合意がとれていました。データ分析も順調に進んでいました。しかし、分析結果をフィードバックした際、経営者から「その成果指標はあまり重要ではないのでは」という疑問が投げかけられました。成果指標が覆ると分析の前提が崩れます。
そこで、経営者にヒアリングを行い、「何が成果指標だと思うか」を確認しました。幸いにも、影響指標として挙げていたものの中に経営者が求める成果指標が含まれていることが判明しました。その指標を新たに成果指標に設定して再分析を行い、経営者の納得が得られました。
このケースから、成果指標の合意を関係者間でとることの重要性を学びました。人事部は経営者にメールで報告していたのですが、合意を明確にとっていませんでした。影響指標の中に経営者の求める成果指標が偶然含まれていましたが、そうでなければ取り返しがつかない可能性もあります。
※成果指標とは、人や組織の目指すべき状態を表す指標。影響指標とは、成果指標を促す／妨げる要因を指し、データ分析を進める上で非常に重要な考え方です。
2．成果指標を追加したケース
社内データを分析するプロジェクトにおいて、クライアントの提案を受けて２つの成果指標を設定しました。分析をしたところ、もう1つの指標を成果指標に追加した方が分析のまとまりが良いということが分かりました。そこで、成果指標を3つにして分析結果を提出しました。
人事部は、3つの成果指標によって得られた豊かな分析結果に満足していました。しかし、人事部経由で経営者にフィードバックしたところ、経営者は「話が違う」と難色を示し、結局、分析をやり直すことになりました。
このケースから学んだことは、成果指標の修正には慎重になるべきだということです。プロジェクト開始時に成果指標の合意を取っているので、修正がいかに分析上妥当であっても、修正する際も同様のプロセスを経る必要があると感じました。
3．基盤となる仮説が棄却されたケース
データ分析のプロセスにおいて、クライアントの仮説が外れることがあります。クライアントがその仮説に基づいて長年にわたって施策を講じている場合、施策の根拠が覆されてしまいます。
それでも、データ分析で得られた結果を示すことは大事です。仮説が棄却されたという結果をフィードバックし、理由を考察しました。クライアントは納得してくれましたが、それでも明らかに落胆している様子が見て取れました。
そこで、プロジェクト終了後にクライアントの主要担当者と個別に打ち合わせを行いました。これまでの施策と今回の分析結果、今後の方針をどのように社内に説明するかを一緒に考えました。
分析結果に真摯に向き合うことは変わらず重要です。結果を隠す必要もありません。しかし、クライアントの感情に配慮することの重要性を、このケースから学びました。また、クライアントの施策の歴史に敬意を払うことも忘れてはなりません。
4．呟いた分析をしなかったケース
プロジェクトを進める中で、クライアントと分析のアイデアを出し合います。柔軟性の高いプロジェクトでは、多くのやり取りが行われます。しかし、全ての分析アイデアを実行できるわけではありません。
アイデアを取捨選択して分析を行い、結果を提出したところ、クライアントから「お願いした分析をやっていません」と指摘されたことがあります。追加で分析を行うことで事なきを得ましたが、これも小さな失敗と解釈できます。
そこで学んだ教訓は、分析の方針を事前に確認することが重要だということです。一つひとつを確認するのが難しい場合でも、分析結果を提出する際に「前回のミーティングでこういうアイデアが出ていましたが、実行しなくても大丈夫ですか？」と併せて伝えれば良いでしょう。
5．他社比較が追加されたケース
組織サーベイのプロジェクトにおいて、設計が順調に進んで回答も集まっていたところ、クライアントから他社との比較を求める要望が出ました。経営者がプロジェクトの進捗報告を受け、「自社が他社と比べて、どのような位置にいるかを知りたい」と考えたため、追加で予算を確保することになりました。
当社が提供するサーベイはオーダーメイド型であり、同じ項目で比較することは難しい状況でした。そこで、同じ項目のウェブモニター調査を実施することで、比較が可能となりました。
実は、他社比較に関心を持つ企業は少なくありません。特に経営者は、自社が他社と比べてどうかを知りたいと考えることがあります。そのため、当社ではこれ以降、他社比較をオプションとして提示するようにしています。
6．積み上げ型を要請されたケース
社内データと組織サーベイのデータを組み合わせて分析するプロジェクトにおいて、重回帰分析を行いクライアントにフィードバックしました。しかし、後に人事部内で内容を共有した際に、「単純集計の結果を見たい」との要請が入りました。
そこで、クロス集計の結果をそのまま提供したのですが、結局、複雑すぎて手に負えなかったようです。最終的に、重回帰分析の結果を施策に活かすことになりました。
このケースから、分析を行う前に、これまでの組織サーベイでどのような結果を受け取っていたかを確認することが重要だと分かりました。他社が提供する組織サーベイの中には、単純集計の結果を大量にレポートするものもあります。このケースでは、クライアントもそれに慣れていたようです。
7．分析結果がクライアントの実感とずれたケース
データ分析をさまざまな角度から実施し、その一つとして重回帰分析を行いました。目的は、成果指標と影響指標の関連性を検証することでした。分析結果をクライアントに報告したところ、一部に違和感を覚えたようです。クライアントにとって、関連があると期待していた指標の間に関連が見られなかったためです。
クライアントは、分析結果に納得できず、自ら相関分析を行ったところ、想定していた関連が見られました。そこで当社に相談があり、「どう受け止めればいいのか」と尋ねられました。私たちは、まず回帰分析と相関分析の違いを説明し、その上で予想外の結果が得られた理由を説明しました。クライアントに納得していただくことができました。
クライアントの実感と分析結果が合わないことはあります。事前に仮説を丁寧にヒアリングし、分析結果が実感と異なる場合には、より丁寧に考察することが重要だと学びました。想定した仮説と異なる結果が得られることは、データ分析の醍醐味の一つだと思います。
8．分析結果が既知の内容だったケース
離職に悩んでいたクライアントがいたので、当社は要因分析のプロジェクトを引き受けました。分析結果を報告したところ、「既知の内容です」という反応がありました。クライアントは、もっと斬新な洞察を期待していたようです。
そこで、当社はクライアントの意見を聞き、追加分析を行いました。複数の観点から分析を行った結果、クライアントが知らなかった事実を発見することができました。この結果、プロジェクトは成功裏に終了しました。
しかし、もしクライアントが新たな洞察を求める場合、インタビューや観察といった手法の方が、仮説検証型の定量分析よりも適しているかもしれません。重要なのは、クライアントが何を求めているのかを正確に見極めることです。
9．スケジュールが変更になったケース
当社では、プロジェクトを始める際にスケジュールを組んでいますが、時に遅延が発生します。あるケースでは、組織サーベイの回収数が少なく、回収期間を1週間延長することになりました。データ分析などに必要な時間を確保するため、納期も1週間遅らせるのが一般的です。
ただし、予算や納期の制約がある場合、納期を変更できないこともあります。クライアントと相談し、納期までに達成可能な内容を明確にする必要があります。このプロジェクトでは、内容をすり合わせして納期を守ることができました。
このケースからの教訓は、締め切りや納期がどのようなものであるかを確認したほうが良いということです。締め切りには、柔軟なものもあれば、厳格に守らなければならないものもあります。状況に合わせて対応することが必要です。
10．追加分析をしなかったケース
あるプロジェクトで、クライアントから追加分析の依頼がありました。しかし、その分析は大きな工数がかかるもので、契約にも含まれておらず、元々の目的に対して効果が小さいことが分かりました。そこで、まずクライアントとプロジェクトの目的を再確認し、提案された追加分析が目的に対して効果が小さいと説明しました。
結果として、提案した別の分析方法が採用され、追加で見積もりをして実行することになりました。この経験から、プロジェクトの目的を定期的に確認することの重要性を学びました。数カ月にわたるプロジェクトでは、目的を忘れてしまうことがあります。追加したい要素があるときには、それが目的に貢献するかを基準に判断することが大切です。
また、クライアントの意見をそのまま受け入れるのではなく、意見の背景を汲み取り、自社から提案することが求められます。プロジェクトに参加する全員が目的を共有し、進捗を確認することで、クライアントの要望にも適切に対応できます。
11．測定を忘れていたケース
当社では、組織サーベイの際に成果指標と影響指標の項目をまとめた「概念項目表」を作成しています。しかし、ある時に成果指標と影響指標を別のシートに分けてしまいました。そのせいで、アンケートの回答画面に成果指標しか表示されておらず、影響指標が測定されていないことに気付きました。
幸い、成果指標の回答データに回答者のIDが記録されていたため、影響指標だけを後から回収し、事後的に照合することができました。この経験から、新しい方法を試す際には特にミスが発生しやすいため注意が必要であること、さらに、アンケートの回答画面に関しても、二重チェックが大切であることを痛感しました。
このミスは、概念項目表の分割とアンケートの回答画面の不備が重なって起こったものでした。これ以降、同様の問題を起こさないために、二重チェックを徹底することにしています。
12．データ処理が誤っていたケース
データ分析のプロセスでは、時には驚くべき結果が得られますが、その結果が誤ったデータ処理の結果である場合もあることを知っておく必要があります。
ある時、当社は社内データの分析を行い、仮説とは逆の興味深い結果を見つけました。しかし、データを再確認すると、逆転処理がされていないことに気づきました。ある概念の全項目が逆転項目だったため、解釈が逆になっていました。
逆転処理を間違うと、結果が変わります。データ処理には正確さと慎重さが必要であり、違和感のある結果が出た場合は、処理に誤りがないかをチェックすることが重要です。
13．関連が認められなかったケース
内製で作成された組織サーベイのデータ分析を依頼されました。データ分析を進めていく中で、意外な事態が発生しました。成果指標と関連する影響指標が見当たらないのです。
そのため、先行研究をもとに影響指標となり得る要因を挙げ、測定はしていないものの、それをもとに対策を検討することになりました。根本的な原因は、影響指標の候補が適切に設定されていなかったことでした。この経験から、調査設計の重要性を再認識しました。
データ分析の依頼を受けた時点で、ローデータをチェックし、結果が出そうかを検討することが大切だと気づきました。近年は「フィージビリティチェック」といって、本格的な分析をする前に項目をチェックする段階を挟んでいます。
14．項目に問題があったケース
内製型の組織サーベイで、データ分析の依頼を受けたケースです。分析してみると驚くことが起こりました。理論的には相関がないはずの概念同士に高い相関が見られたのです。
原因を調査すると、質問項目に問題があることが判明しました。そこで、因子分析を改めて実施し、概念を再構成することにしました。新たに概念を定義し、クライアントと合意を得た上で分析を進めました。
質問項目の作成は簡単に思われることもあるのですが、実際には専門的な知見が必要です。この経験から、質問項目の作り方に関する知見をもっと伝えていく必要があると痛感しました。また、次回以降の組織サーベイでは適切に測定できるよう、予算をいただいて項目の修正を提案することが重要であると学びました。
15．波風が立ったケース
離職の要因を探り、対策を講じるためにサーベイを行ったケースがあります。離職意思を尋ねる一般的な質問を入れたところ、サーベイの回答者から人事に問い合わせが続々と寄せられました。調査の目的や誰が結果を閲覧するのか、回答しなくても良いのかといった問い合わせです。
調査目的の説明が不十分でした。データを何に用いて、何に用いないのか。個人情報つきで閲覧できるのは誰かなど、十分な説明がなされていませんでした。
離職意思を厳密に測定することは大事ですが、調査のプロセスで波風が立つと、回答者に余計な負担を強いますし、測定の精度も低下します。また、対策にも前向きでなくなります。組織サーベイの回答を依頼する際に、調査目的やデータの利用方法について、丁寧に説明する必要があると痛感しました。
16．非効率な処理をしたケース
社内データ分析のプロジェクトで、扱いにくいデータがあったため、分析に回す前のクリーニングに時間をかけました。ところがよく見てみると、分析する必要がないデータまでクリーニングしていることに気づきました。
クライアントに対しては特に問題なかったのですが、データクリーニングに時間をかけすぎたばかりに、締め切り間際に時間的に追い込まれてしまうことになりました。
分析の目的を何度も確認することが重要です。その上で、限られた時間の中で、目的を達成するためにまずクリアすべき事項に資源を焦点化しなければなりません。
17．読み飛ばされていたケース
ウェブモニター調査では、「読み飛ばし」の尺度を入れるケースがあります。指示通りの回答をしていない場合、質問を読み飛ばしていると見なして処理するのです。これは珍しいケースですが、組織サーベイに読み飛ばしの項目を入れることになりました。
いざ回答をチェックしてみると、少し恐ろしいことが起こりました。それなりの割合の回答者が読み飛ばししていたのです。読み飛ばしのサンプルを除去したバージョンと、除去していないバージョンの両方で分析を行いましたが、大きな差はありませんでした。
しかし、この経験はデータ分析のプロフェッショナルとして考えさせられるものでした。組織サーベイに回答する際の態度はどのようなものか、また、読み飛ばしという行為をどう解釈し、対処すべきか、引き続き向き合っていく必要があると感じました。
18．紙で回収したケース
全社員にPCやモバイル端末が配布されていない企業も存在します。あるプロジェクトでは、クライアントと相談し、紙のアンケートを配布することになりました。対象者数は数千名にのぼり、調査票の作成、印刷、配布が必要となりました。印刷と配布はクライアントにお願いしました。
ただ、アンケートの回収が大変でした。調査票は人事部門ではなく、当社に郵送で送ってもらうことにしましたが、アンケートが次々と届き、ポストに入りきらない状況に陥りました。さらに、データ化も困難を極めました。
この経験を経て、紙のアンケートは当社では実施せず、クライアントあるいは第三者に回収とデータ化を担当していただくことにしています。
19．短納期で実施したケース
予算の関係で短納期の依頼が舞い込むこともあります。「今月中にデータ分析を終えてほしい」と、緊急の相談をいただくケースです。
しかし、データ分析は即座に開始できません。契約や手続き上の必要事項があるからです。その結果、分析を開始できる時点で、納期まで残り2週間となっていたケースもありました。
このケースでは、最低限の要件や品質基準を明確にするために、プロジェクトの初期段階で通常より長めのミーティングを実施して、念入りにすり合わせしました。短納期のときにこそ、開始時に調整をすることで、プロジェクトの成功につながることを学びました。
20．日程調整に手間取ったケース
当社のデータ分析はオーダーメイド型のため、クライアントと密接に連携しながら進行します。プロジェクトの中で多くの打ち合わせを行います。
複数のプロジェクトを同時進行すると、日程調整が難しくなり、プロジェクト全体が予定より2週間ほど遅れてしまうケースもありました。遅延は、打ち合わせの日程調整がギリギリになっていた場合に起こりやすいと言えます。
参加者の人数が増えるほど調整は難しくなるので、早めの調整が欠かせません。一見些細なことに思える打ち合わせの日程調整ですが、実はプロジェクトの遅延を引き起こす要因となります。
執筆者
伊達 洋駆 株式会社ビジネスリサーチラボ 代表取締役
神戸大学大学院経営学研究科 博士前期課程修了。修士（経営学）。2009年にLLPビジネスリサーチラボ、2011年に株式会社ビジネスリサーチラボを創業。以降、組織・人事領域を中心に、民間企業を対象にした調査・コンサルティング事業を展開。研究知と実践知の両方を活用した「アカデミックリサーチ」をコンセプトに、組織サーベイや人事データ分析のサービスを提供している。著書に『現場でよくある課題への処方箋 人と組織の行動科学』（すばる舎）や『越境学習入門 組織を強くする「冒険人材」の育て方』（共著；日本能率協会マネジメントセンター）などがある。2022年に「日本の人事部 HRアワード2022」書籍部門 最優秀賞を受賞。
