Zenn
株式会社GroovesPublicationへの投稿
🩺

健康診断のようにチームのエンゲージメントと開発者体験を確認する、定期アンケートの運用紹介

とりい
2024/11/19に公開
マネジメント
チームビルディング
開発者体験
開発生産性
idea

はじめに

本記事は私が現職で1年数ヶ月程度運用してきた開発組織向けの定期アンケートについての紹介になります。なぜ運用しているのか、どんな設問を用意しているのか、運用時のルールや注意点、気づきなど目次に沿って説明していきます。
漠然とチーム状態に不安がある場合やアンケートの運用事例を知りたい際など、参考の一助になれば幸いです…！

背景

この数年、エンジニア組織の開発生産性や開発者体験(DevEx)というワードが経営から現場まで各レイヤーで注目され、考え方の良し悪しや具体の運用事例などが多く語られているように感じています。
私自身、エンジニアリングマネージャーとしてSPACE[1]というフレームワークにはとても共感しており、自組織の状態を考察する際の一要素として計測と活用をしています。そこで計測の際に苦労するのが定性的な指標("Satisfaction and well-being"や"Communication and collaboration")の扱いになります。これら定性的な指標を数値化するアプローチ[2]のひとつとして自組織ではアンケートを実施しています。
大きな組織であれば専用のサーベイツールを使う、もしくは内製開発[3]するといった選択肢もありえるかもしれません。私たちに関しては組織的にまだまだ大きな規模とは言えないので、現状はGoogleフォームでアンケートを作成・メンテしています。

補足

前職でもEMをしていたのですが、私がSPACEという考えに触れたばかりなこともあり、アンケートを活用した実運用などはできていませんでした。前職でEMを引き継いでくれたメンバーが、その後アンケートも含めた運用に挑戦し、SPACEの説明なども含めて整理してくれたナイスな記事があるのでこちらで共有させてください！
https://qiita.com/kissy24/items/decfac2256324a5227ea

運用に際して

Googleフォームでアンケートを作成し、現在はおよそ2ヶ月に1回の間隔でプロダクト開発メンバーに回答してもらっています。なお回答間隔は組織の状況に応じて変えていただくのが良いと思います。考え方として、回答依頼の頻度が多すぎるとメンバーへ余計な負荷を与えたり、チーム状況も変化しておらず回答が固定化されてしまいます。逆に少なすぎるとチーム状況の遷移や傾向が定点観測として追いづらくなります。現在の私たちの組織では1スプリントのタイムボックスが2週間なため、4スプリントも経過していると一定の変化がチームで起きていそうだと仮定し、2ヶ月を設定しています。

グランドルール

以下はアンケートの回答をメンバーへ依頼する際に伝達するグランドルールになります。

  • 2ヶ月に1回程度の周期での実施を想定しています
  • 平均値を出しているのはチームの健康診断的な側面が大きいです。時系列で見た際に多きな変動があったり、極端な数値が見えた際に気づくことができます
  • 個人の数値もあくまで数値であり、その回答背景を大切にしたいと考えています(そのためヒアリングを行っています)
  • 全体の平均値を上げることが目的ではなく、ユーザーへの提供価値の質とサイクルを向上させるための課題感把握と、Mgrからのトップダウンな施策が必要か、メンバーレベルからのボトムアップな改善を求めるか、アクションの検討に活用したいと考えています
  • 上記チーム改善のためだけに使用します。現状を把握するため、率直に回答してもらえると助かります！

回答の整理

各設問は5段階のリッカート尺度を使った定義になっているので、回答結果は数値として集計できます。現状はGoogleスプレッドシートへかなりシンプルな形式で集計しています。
個人の回答履歴は当人とEM以外には非公開とし、公開資料にはチームごとの平均値を残すようにしています。

集計イメージ
Unitはチームと置き換えてください。数値によってセル背景色にグラデーションをかけたりしています。

1on1への活用

集計結果を考察すると共に、チーム状況の把握や改善アクションの検討へもう一歩踏み込むために、回答背景を各メンバーへ1on1などの際に15分程度ヒアリングしています。
ヒアリングを通して、個人的には以下のようなありがたさを(EM観点で)享受しています。

  • 背景を知ることで、集計結果の考察から得られた仮説の補強や修正が進む
  • メンバーにとっては回答時の気持ちを振り返る機会にもなるので、自己内省のきっかけにもなる
  • 項目を振り返ることで1on1での話題が広がり、「実はこういうこともあった」など、お互いの新たな気づきにつながる

全体への周知

運用を継続する中で以下のような意見をメンバーからもらい、取り組みやその後のアクションに対して自分自身の周知が不足していたことを反省しました。

  • チーム平均値のこの数値が低い背景、他メンバーの意見を知りたい
  • 集計やヒアリングをしているけど、何につながっているのかよくわからない

現在は集計とヒアリング内容を踏まえて各チームに対する気づきやアイデアの提言を整理して、Notion上でチームへ共有するようにしています。アウトカムへの満足度が高い場合にどういった機能リリースが好影響を与えていたかの背景を伝えたり、逆に低い場合はどういった課題感があったかなど、ヒアリングを通して得られた意見やこれから取り組んでいきたいアイデアの紹介を行っています。
伝えた背景や課題などは各チームのレトロスペクティブなどで取り上げられている場合もありますが、改めて共有することでチームにとっての重要性が増すことも期待しています。

実際のアンケートでの設問例

以下が実際に使用している設問になります。長くなるので折りたたんでいます。
※チーム内にしか伝わらない用語の置き換えなど、一部記載を変更しております

アンケートの内容

チーム改善のためだけに使用します。現状を把握するため、率直に回答してもらえると助かります！
個人の回答内容はEMのみが閲覧でき、本人の許可なく回答内容を他者へ公開しません。
ただし個人が特定できない状態での公開は検討しています。チーム全体での平均値など。
2ヶ月程度の間隔での集計をいったん検討しています。
1: 全く当てはまらない
2: あまり当てはまらない
3: どちらとも言えない
4: ぼちぼち当てはまる
5: よく当てはまる

設問例

※チーム内にしか伝わらない用語の置き換えなど、一部記載を変更しております

  1. 気後れなくチームメンバーに対して発言できる
  2. 周囲のメンバーの価値観や目標を知っている
  3. チーム内でのコミュニケーション量に満足している
  4. 各メンバーはHRTのマインドを維持している
  5. プロダクト開発の半期方針を把握している
  6. プロダクト開発のロードマップを把握している
  7. 最近の業務にやりがいを感じている
  8. 各スプリントで自身の作業量は適切である
  9. 自身の業務状況や学び／気づきをチームへ共有できている
  10. 個人やチーム活動を振り返り、日々の業務やMTGの中で行動指針を土台にした行動や話し合いが行われている
  11. チームのアウトプットに満足している
  12. チームが創出するアウトカムに満足している
  13. 知りたい情報にアクセス可能であり、情報取得にかかる時間が少ない ※機密情報(秘や人事秘)は除く
  14. MTGの総時間と密度は適切である
    ※以下設問はエンジニアメンバーにのみ追加で回答してもらっています
  15. リファインメントの機会や量は適切で、見積もりに必要な情報が入手できる
  16. コードをレビューする際の認知負荷が少ない　※レビュアー目線で回答してください
  17. PR提出後、レビュアーからのリアクションが早い
  18. CIによる自動テストは信頼できる ※事故やフレイキーなテストに遭遇していない
  19. デプロイ作業やリリース作業は明確で不安は少ない
  20. プロダクトの技術的負債は戦略的にコントロールされている
  21. 必要に応じてペアワークやモブワークの実施が容易である

自由記述欄(任意：何かコメントや要望がありましたら)

設問の意図や背景の補足

私たちの組織がフルリモート組織なこともあり、コミュニケーション状況やプロダクト方針の共有状況についてメンバーがどう感じているかに重点を置いた設問を多く設定しています。設問の後半は認知不可やフロー状態に関連する設問を設定しています。
(Slackでの)コミュニケーション量、MTG時間や密度、コードレビューまでの時間などはアンケートでなくても定量的に測定可能ですが、感情的な満足度も集めることで定量定性の両面から組織状況を把握したいと考えています[4]。
例えば、コードレビューまでの時間を早めたいという定性的な声が聞こえた場合に、定量的な測定結果と合わせると今以上に早くする現実的な方法が検討ができます。既に十分な速さがあるとすればルール策定や通知botといった直接的な手段以外にも、チームサイズや開発プロセス自体の見直しといった間接的な選択肢も浮かぶかもしれません。検討なしに思いついた手段の追加や修正をした場合(上手くいくこともありますが)、チームのリズムを大きく乱してしまいアンケートの他項目へ悪影響を与えたり、チームの燃え尽きにつながる可能性もあります。
定期的な計測を行っていると、上記のような組織アクションの影響が多角的に振り返れることも良さだと感じています。

なお各設問は定期的に見直しているため、設問の増減や記載の見直しを経ています。

まとめ

運用時に気をつけていること

  • 数値を上げることが目的ではなく、組織の状態把握や組織改善につなげることが目的、このことを忘れない
  • 個人の評価には使用しない
  • 自由に負荷なく回答してらもえるルールの検討と周知を行う
  • 集計やヒアリングから得られた気づきやアイデアをチームへ周知する

運用を通して得られた気づき

  • ヒアリングや他測定データと組み合わせて考えることで、チームを観察する中で得られる仮説を補強したり修正するための材料が得られる
  • 組織に対してアクションを行った際、意図しない領域で悪影響を与えていないか定期的に振り返るきっかけになる
  • ヒアリングまでセットで行うことで、より良い1on1へつながる場合がある
  • 運用を継続し時系列データが蓄積してくると、チーム組成やメンバージョインなどのイベントごとにどのような影響がチームへありそうか予測の助けになる

今後の課題

  • 継続的な運用改善
    運用を継続する中で、チームが安定傾向な場合は回答が硬直化する部分も見えてきました。現状に則した設問の見直しや、実施間隔、見せ方や周知の工夫など運用面は継続的な改善が必要だと感じています。(私自身も回答する立場であれば、マンネリに感じてしまうこともありますので納得感を維持してもらえる運用を目指したいです)
  • 潜在的な課題の発見
    メンバーが現在課題に感じていることはアンケート結果へ表れやすいのですが、潜在的な課題などは表れてきません。アンケート結果だけで潜在的な課題を発見することは難しいかもしれませんが、定量測定の結果やヒアリングと合わせることで、より潜在的な課題も事前に把握できるような試行錯誤は繰り返したいと考えています。
脚注

  1. SPACEについて説明された論文になります。https://queue.acm.org/detail.cfm?id=3454124 ↩︎

  2. 2014年と古めの記事にはなりますが、当時のSpotifyはアンケートではなくチームでワークショップを開催して健康状態を測定していたとあります。https://engineering.atspotify.com/2014/09/squad-health-check-model/ ↩︎

  3. Linkedinの事例: https://www.linkedin.com/blog/engineering/developer-experience-productivity/inside-look-measuring-developer-productivity-and-happiness-at-l ↩︎

  4. "DevEx: What Actually Drives Productivity"では、客観的データに加え開発者の声を把握する必要性が記載されています。　https://queue.acm.org/detail.cfm?id=3595878 ↩︎

株式会社Grooves
株式会社GroovesPublication

Grooves所属メンバーの個人発信をまとめたPublicationです。記事内容はあくまでも個人の見解であり、会社としてレビュー等はしておりません。あらかじめご了承ください。

Discussion