こんにちは。スタディサプリの認証チームに所属している @taki-21 です。 今回は社内サーベイを効果的に実施するためのポイントについて紹介したいと思います。
はじめに
私たちのチームは 2024 年 4 月から 9 月までの 6 ヶ月間を通して他チームとスムーズな連携を図るために、社内でのプレゼンスを向上させる取り組みを行ってきました。 今回はその取り組みの中の一つであるサーベイに焦点を当てて「サーベイを効果的に実施するためのポイント」についてお伝えしたいと思います。
先に結論を書くと今回の取り組みを踏まえて以下の点について気をつけると効果的なサーベイになるのではないかと思っています。
- サーベイの目的を明確に伝える
- 専用のチャンネルを作成し回答を依頼し、回答したら抜けてもらう。都度リマインドする。(※ 利用ツールは Slack を前提としています)
- サーベイの全体の構成や質問のフォーマット(回答例をつけるなど)を工夫する
- 目的に応じて適切なサーベイの対象者を選定する
- サーベイを連続で実施する際は、施策の影響度や回答者の負担を踏まえ実施回数を決定する
- フィードバックへの対応を迅速に行う
サーベイを行った背景
私たちのチームは、スタディサプリの認証基盤を開発するプロダクト横断的なチームです。認証に関わる案件については、要件定義などの初期段階から関わることが理想ですが、他チームと早期に情報共有ができていない場面があり、スムーズな連携が課題となっていました。
こうした課題を分析する中で、そもそも他のチームが私たちの役割や存在をどれほど認知しているのかという疑問が浮かびました。そこで、サーベイを活用して認知度を計測し、その結果をもとに施策を検討し実施することで、まずは社内でのプレゼンスを向上させ、最終的にチーム間の連携強化を目指すことにしました。
最終的にはサーベイの結果をもとに、マネージャやエンジニアが集まるキックオフの場でチームの役割を共有したり、社内の記事で認証チームが扱っているユーザーについて共有をしたりといった施策を実施し、認証チームのプレゼンスが向上したという成果を得ることができました。 ここからは具体的にどのようなサーベイを実施したか、また、どのような学びがあったかを紹介します。
サーベイの目的
今回のサーベイの目的は以下の2つです。
- 施策の効果計測
- プレゼンス向上のための施策がどの程度効果を発揮しているか、定量的に把握するため
- フィードバック取得
- 他チームからのフィードバックを通じて施策の改善点を見つけるため
サーベイの方法
サーベイを開始する前に主に以下の点について検討しました。
1. 何回実施するか
2024 年 4 月から 9 月までの 6 ヶ月間で以下のフィードバックサイクルを何度回すかによって変わってくると思います。
現状把握(サーベイ実施)-> 分析 -> 施策 -> 効果の確認(サーベイ実施)
まず現状を知るために 1 回、そして最終的な結果を知るために 1 回実施することは最低限必要であり、その間にもう 1 回実施するかどうかを検討しました。
今回は、自分たちが実施した施策について効果があったのかだけでなく、フィードバックをいただいて、その施策に関しても改善できる余地を確保するため最終的にフィードバックサイクルを 2 度回すことにしました。
つまり、全体の計画としては以下のようにサーベイを合計 3 回(5 月, 7 月, 9 月)実施することにしました。
2. どのように依頼するか
依頼方法もサーベイの回答率に影響するため重要だと思います。 今回はある程度強制力が働く方法を採用してみました。
具体的な方法は以下のとおりです。
- サーベイ専用の Slack チャンネルを新規で作成する(例:
#tmp-202405-auth-devs-survey
) - 背景や目的を共有しサーベイの回答を依頼する
- 回答したら抜けてもらう
- 締切期限まで都度リマインドをする
こちらの方法は同じ横断的なチームである SRE チームが半年ごとに実施しているサーベイと同じ方法になります。自分自身この SRE チームのサーベイに関しては忘れずに回答していたなと思ったので参考にさせていただきました。
3. どのような質問を用意するか
基本的にサーベイの目的に沿った質問を用意しました。 また今回はサーベイのやり方についてもフィードバックをいただきたかったのでサーベイ自体の質問も追加で用意しました。
サーベイの目的に沿った質問
今回のサーベイの目的は「施策の効果計測」と「フィードバックの取得」です。 施策全体の効果計測のための質問は全3回で固定にしました。同じ質問でないと計測できないためです。 また施策ごとの効果計測やフィードバックの取得はサーベイごとに変更して用意しました。
- 施策全体を通して固定した質問の例
- 認証チームの存在について名前・活動内容について知っているかどうか
- 認証に関する案件や相談、質問があれば認証チームに共有しようという認識があるかどうか
- 施策ごとの質問の例
- 最近できた「auth 投げ込み」絵文字の存在を知っているかどうか
- 認証チームがオーナーシップを持っている範囲をまとめた社内記事を読んだかどうか
サーベイ自体の質問
例えば以下のような質問です。
- 新規の tmp チャンネルへの招待はストレスにならないかどうか
- 上期中(~ 2024-09-30)に実施するサーベイの頻度 3 回を予定していますが、ストレスにならないかどうか
- 上期中に 3 回のサーベイを実施させていただきましたが、ストレスがかかったかどうか
※ 上記に加え、回答の補足や質問・相談が記述できるフリーコメント欄も設けました。
4. どのようなフォーマットにするか
最初は特に何も考えずに用意した質問を順番に Google Form に設定するだけでしたが、同時期に実施された SRE チームのサーベイのフォーマットが以下のように工夫されており、非常に答えやすかったため導入させていただきました。
- 最初にサーベイの目的が明記されている
- 質問の種類によってセクションが分かれている
- 抽象的な質問には回答例が記載されている
サーベイの実施で得た気づき
サーベイの実施を通して自分自身が気づいた点について順に紹介していきます。
フリーコメントの重要性
予想以上に多くの方からフリーコメントをいただき、とてもありがたかったです。自分たちが感じていない課題感を教えていただくこともできたので、フリーコメントは用意した方がよいと思います。
目標設定の不足
全 3 回のサーベイを終えた際に最終的にどれくらいの成果を目指していたんだっけという気持ちになりました。
今回のような割合を計測する質問を含むサーベイでは「認知度 xxx % を目指す」というような目標を決めたほうが、改善の指針になったり自チームの共通認識が生まれ改善のモチベーションにつながるかなと思いました。
最初から目標を決めるのは難しいですが、1 回目で感覚を掴んだ後は目標を決めることはできたかなと思いました。
サーベイ回数と負担のバランス
半年中に 3 回のサーベイを実施するのは、回答者にとって負担になるだけでなく、依頼者も普段の業務と並行しながら分析や改善策の検討・実施が必要になるため少し負担に感じる部分がありました。
フィードバックからの学び
フィードバックを通して学んだ点について順に紹介していきます。
サーベイ専用チャンネルの効果
運用の仕方が工夫されているというフィードバックをいただきました。個人的にも同時期に他チームが開発者全体の Slack チャンネルでサーベイを実施しており、参加者が集まりにくいという声を聞いていたため、やはり一定数回答を得るためには、強制力やリマインドの工夫が必要だと感じました。
サーベイの対象者を精査する必要性
サーベイの対象者に Technical Product Manager(TPM)を入れる必要があるのではというフィードバックをいただきました。今回の課題である早期連携の強化を達成するには開発者ではなく TPM や PdM などのレイヤーの方にもサーベイを答えてもらう必要がありました。
サーベイの対象者を誰にするのかということもサーベイを効果的に実施する上で必要な観点だと思いました。
サーベイの目的が正確に伝わっていなかった
サーベイの目的について伝わっていないというフィードバックをいただきました。サーベイを何のためにやっているのか、回答がどんな役に立つのかという部分を正確に伝えることができると回答者が回答する価値があるのかどうかを判断できるため、意味なさそうだから回答しないというケースを減らすことができると思います。
また今回のようにサーベイを複数回実施する場合は、複数回実施する上でどのような効果があるのかについてもちゃんと共有するべきでした。
回答者が回答に値すると判断し納得した上で回答できるような情報を提供するとよりよいサーベイになると思いました。
短いスパンでの連続したサーベイの実施による回答者の負担
半年で 3 回のサーベイ実施は回答者にとって負担がかかるというフィードバックをいただきました。割合で見ると負担がかかると答えた方が約 25 %ですが、サーベイのボリュームが今回より大きくなるとより負担がかかると思います。
先述しましたが、依頼側としても現状把握、分析, アクション, 効果確認という一連のサイクルを回すと考えると半年でサーベイは 2 回ほどが妥当かなと思いました。
ただし、施策によるサーベイ回答者への影響の大きさによって適切な頻度は変わると思います。 今回のサーベイは「プレゼンス向上のために認証チームの活動や依頼を共有する」という内容でしたが、例えば「開発体験を上げるために新しい仕組みを導入する」という内容であれば施策を実施した際の回答者への影響は今回より大きく、より回答者からのフィードバックが重要となります。
このようにサーベイの回答者に対する施策の影響度が大きければ負担があるとしても頻度を増やすということは考えても良いと思いました。
つまり、施策の影響度や回答者の負担を考慮して実施回数を決定することが必要です。
コメント・相談・質問への未回答による信頼感の低下
コメント・相談・質問した内容について回答が得られていないため回答のモチベーションが下がったというフィードバックをいただきました。回答者の立場になるとせっかく時間を使って質問や相談をしたのに反応がないと、回答の意味がないな、見られていないのかなという不信感を抱くのは当たり前のことでした。
マネージャ と 1 on 1 でサーベイについて相談した時も「キックオフのアンケートとかで質問すると DM とかで返信をくれる。そういった体験があると自分の回答に意味があるんだなと実感し今後も回答しようというモチベーションにつながる」ということをおっしゃっていました。今回はその重要性を考えられておらず、回答を後回しにしてしまっていたため、今後は迅速なフィードバックを心がけたいと思います。
また、チームで回答の認識を揃える必要があったり、すぐ回答できない場合はその趣旨をしっかり相手に伝えるということを次回以降実施したいと思います。
サーベイを効果的に実施するためのポイント
改めて今回の経験から自分が考えるサーベイを効果的に実施するためのポイントを簡潔にまとめてみました。 自分を含め次回サーベイを実施する方はぜひ参考にしていただければと思います。
- サーベイの目的を明確に伝える
- 専用のチャンネルを作成し回答を依頼し、回答したら抜けてもらう。都度リマインドする。(※ Slack を前提としています)
- サーベイの全体の構成や質問のフォーマット(回答例をつけるなど)を工夫する
- 目的に応じて適切なサーベイの対象者を選定する
- サーベイを連続で実施する際は、施策の影響度や回答者の負担を踏まえ実施回数を決定する
- フィードバックへの対応を迅速に行う
さいごに
これまで回答者としてしか関わってこなかったサーベイの計画・実施を経験し、多くの学びを得ることができました。
特に依頼者側としてサーベイに回答いただけること、そしてフリーコメントで有益なフィードバックを得られることにありがたみを感じました。この経験を通じて、今後は自分自身もより積極的にサーベイに参加し、より良い環境づくりに貢献していきたいと思いました。
社内サーベイを実施する際にこちらの記事が参考になると幸いです。