チームの心理的な変化に気づくためにしていること
コドモンの開発ブログを移転しました。最新の記事はこちらからご覧ください。
こんにちは！コドモンプロダクトチームの市川です。
この記事はEngineering Manager Advent Calendar 2020の3日目です🎄
Advent Calendarからいらっしゃった方にはお馴染みかもしれないEMFM（エンジニアリングマネージャーによるエンジニアリングマネージャーのためのPodcast）に出てくる内容を元にした表現ですが、私は「エンジニアリングマネージャーの責務は、エンジニアリングにおけるボトルネックを発見→解消し、エンジニアリングを最適化していくこと」だと思っています。エンジニアリングマネージャーの仕事として挙げられる様々なタスク（採用・評価・教育・1on1などメンバーとのコミュニケーションetc...）は、すべて上記の責務を果たすための手段という認識です。
その前提においては、既に顕在化しているボトルネックを解消することと同様に、潜在的なボトルネックを見つけることも重要そうです。
チームの変化に気づくために何をしているか
コドモン開発チームでは、メンバーの心理的なヘルス状況の変化に気づくために、チームヘルスモニターと称したアンケートを月次で実施しています。
なぜしているか
端的にいうと、潜在的なボトルネックの種を発見するためです。
メンバーが雑談や愚痴として明示的に伝えてくる課題感や、自分の目から見える課題感はボトルネックとして捉えやすいですが、”実際に誰かの中に潜在的に存在する（かもしれない）ボトルネックの種”を見つけるのは、よほどのコミュニケーション超人でない限り難しいと思います。そこで、そのようなボトルネックの種（＝メンバーやチームの心理的な変化）に気づける仕組みとして、心理的なヘルス状況をアンケート形式でモニタリングする運用を始めました。
特に、コドモン開発チームは日々のプロセス改善にも目を向けており、プロセスや仕組みをチューニングすることもしばしばあります。そのような変化がメンバーやチームの心理に何かしらの影響を与えている可能性が常に存在するため、メンバーの心理的変化に気づけるようチームヘルスモニターを実施し始めたという背景もあります。
どのように運用しているか
毎月アンケートを実施→集計・分析→（必要に応じて）チームやメンバーに話を聞く、という流れで運用しています。
アンケートの実施
アンケートは、Atlassianのヘルスモニターを参考にしつつも大幅にアレンジした1ページ目と、Googleのre:Workの心理的安全性チェック項目をほぼそのまま使った2ページ目で構成しています。
▼メンバーの心理的なヘルス状況を聞きたい1ページ目の質問群
・所属チーム
・「この一ヶ月、気持ちよく開発・保守できた」の5段階評価とその理由
・「この一ヶ月、会社に自分が貢献できたと思う」の5段階評価とその理由
・「この一ヶ月、自分が成長した実感がある」の5段階評価とその理由
・「この一ヶ月、自分に精神的/時間的に余裕があったと思う」の5段階評価とその理由
▼心理的安全性に関する状況を聞きたい2ページ目の質問群
・「チームの中でミスをしても、それを理由に非難されることはない（建設的なフィードバックとして指摘される）」の5段階評価
・「チームメイトは、一度引き受けたことは最後までやりきってくれ、成果も信頼できる人たちである」の5段階評価
・「何かを決めたい場合に、チームの中でどのような意思決定プロセスを経ればいいか明確である」の5段階評価
・「チームのためにしている仕事は、自分自身にとっても意義がある」の5段階評価
・「チームの成果が組織の目標達成にどう貢献するかを理解している」の5段階評価
これを、毎月決まった時期（コドモン開発チームでは月末月初を避けて3週目）に実施しています。
アンケート回答の集計と解釈
回答を締め切った後、集計用のシートでチームごとの各項目の平均値の推移を、ローデータのシートでポイントの低い回答の理由記述を確認します。
▼集計用のシート（メンバーの心理的なヘルス状況）
例えば上記のチームBの場合、8月に担当機能において不具合が発生しチームで対応したのですが、ヘルスモニターにおいても「貢献」「余裕」の落ち込み→復活として数値に表れています。
※文字色については、前回実施時より0.3以上上がっていれば青、下がっていれば赤くしています。
▼集計用のシート（心理的安全性に関する状況）
例えば上記のチームCの場合、10月からチーム編成に変更がありました。変更後のチームキックオフの影響もあってか「ミスしても非難されることはない」「チームの成果が組織にどう貢献するか理解している」の数値は向上したものの、「チームのためにしている仕事は自分にとっても意義がある」の数値は減少しています。（このような場合、減少の背景に何があるのかをローデータのシートなどで探り、明確に対応すべきものがあるか判断します）
▼ローデータのシート
運用において気をつけていること
敏感になりすぎない
チームにおける心理的なヘルス状況をモニターするうえでは、数値の上下に敏感になりすぎないことが大事なのではと思っています。
このモニタリングの目的は「チームのボトルネックの種に気づけるようにする」ことでありつつも、チーム外からの不用意な介入は、チームの健全な運営の妨げになりそうです。本来チーム内のネガティヴな変化には、日々の振り返りの中でチーム自体が気づいて対応するはずだからです。
なので、チームヘルスモニター上で明らかな変化があったとしても、3ヶ月くらいはその数値上の変化を引用しての働きかけは控えた方がいいのだろうと思っています。（とはいえ、個別回答に明らかなメンバーの心理的な落ち込みが見られる場合は、そのチームのリーダーの判断で必要に応じて何らかの働きかけを行うこともあります）
複数のチームを比べるのではなく、一つのチームを時間軸に沿って前後比較する
回答結果はチームごとで集計していますが、チームごとの平均値を比較するのではなく、時間軸で比較しています。チーム横軸で比較してメンバーのバランスなどを見るという見方もできるといえばできそうですが、全体の平均を合わせる必要性は今のところ感じていません。時間軸においてチーム内で変化があるかのみ、シンプルにモニタリングしています。
運用していて感じるメリット
チームヘルスモニターの運用を始めて半年経ちますが、「チームのボトルネックの種に気づけるようにする」という目的においては、多少働きかけのトリガーになることはあるものの、正直まだ大きな実感や事例はありません。（チームヘルスモニターが意味を持つような出来事はそもそも起こらないに越したことはないですし）
運用していて思ったのは、出来事と数値の推移を照らし合わせることで、チーム状況についての認識と実態を答え合わせできることも、この運用をしていて得られている大きなメリットのひとつだということです。
例えば以下のようなシーンにおいて、「チームヘルスを数値として確認できる仕組みがあって良かった」と感じます。
・新しく始めた取り組みが逆効果になっていないかを確かめて少し安心できる（もちろんスコアが全てではないですが、一つの判断材料として）
・各チームのリーダーの働きかけが少しずつ上手くいっている様子が見える
・プロダクトのトラブルで一時的にスコアが下がったあと上がり直していく様から、チームの回復が見える
コドモン開発チームはまだまだ発展途上で色んなことを模索している時期でもありますが、このように「チーム状況についての認識と実態に大きな乖離がないことを確認できる手段」を持てることは模索する際の大きな助けになっています。
終わりに
このような運用はチームの文化や状況によって良し悪しも分かれると思いますが、「チームのエンジニアリングを最適化するために、何かしらで状況を測ってみたい」と思っていらっしゃる方がいれば、選択肢の一つとして検討してみても良いかもしれません。もしくは、他にもっと良い方法をご存知の方は、ぜひアドバイスなどいただけるととても嬉しいです。