エンジニア向けのコーチング勉強会ってどんな感じ?コードレビュー編
こんにちは。コーチェットCOO兼プロダクト責任者の吉田です。
先日 2022年8月25日(木)にエンジニアのためのコーチング勉強会として「コードレビューに活かすコーチングスキル」をテーマに開催いたしました。
参加できなかった皆様向けに、勉強会の内容と様子をご紹介いたします。
全体の流れ
大まかに
前半はレクチャー中心
後半はケーススタディとロールプレイ中心
という構成です
チェックイン
コーチェットでは社内の会議でもチェックインから入ることがよくあります。
「今の気持ち」「最近の気づき」等について、会議のアジェンダ・議事録のnotionに書いたり、Zoomのチャットに書いたりしながら進めます。
今回の勉強会では参加者が全体で10名ほどでしたので、Zoomで順番に発言していただきながら進めました。
当初の期待を言語化しておいていただくことは、運営側にとって内容を調整する手がかりにもなります。期待値がすりあっている場合でも、参加者ご本人の学びにとって有効に働きます。
実際のお声としては
といった課題や期待についてお伺いすることができました。
全体を通じて、コードレビューの場をよりよいものにしたい、という思いを持った方がご参加くださっていて、私たちの事前の意図とあっていることを確認できました。
実際にそれぞれの期待についてお話しいただいた際には、ファシリテーターの側は承認のコミュニケーションを取るようにしており、安心して勉強会に参加していただけるように心がけました。
コードレビューとその目的について
コードレビューの検索ワードにもふれながら
Googleの「コードレビュー開発者ガイド」について「コードと製品の品質維持」を目的にしていることもご紹介しました。
参加者の皆さんが会社やプロジェクトで行っているコードレビューについて、どういった目的を認識されているかをZoomのチャットでお伺いしました。
明文化されてはいないというお声もありましたが
といったところが主に挙げられていました。
本日の勉強会では「エンジニアのスキル向上」や「知識の共有」といった「教育機会」においてコーチングスキルを活かす方法についてお伝えします、と本日の内容について改めて確認しました。
また、コードレビューが本来「指摘」をする場面であるということ、主に経験や能力の差がある関係性においてなされることが多く、レビューされる側・する側の関係性において
評価・ジャッジされる ←→ きちんと評価・指摘できる
コードへの指摘ではなく自分への批判と受け取ってしまう ←→ 言い方・伝え方の工夫の必要
と双方に課題や問題があること、構造的に圧力が発生しやすいことも、改めてお伝えしました。
教育機会、コーチング
教育というと「教える」ことである、となりがちですが、育成という目線で考えるとティーチングとコーチングの使い分け、配分が重要です。
初学者にはもちろん「教える」関わりが主体になりますが、徐々に一人でできることが増えてきた相手に対してはコーチングを混ぜていくことになります。
例えば「なぜこういう書き方になったのですか?」など、意図を尋ねるような関わり等です。
コーチングスキル:傾聴
コーチングは主に対話の場面でなされるもので、コーチとの対話を通じて、思考を深めたり、気持ちを整理したり、気づきを得たりすることで自発的な行動が促進されるコミュニケーションです。
コーチング的な関わりを身に付ける上で必要なことは、スキル、マインドセット、プロセスであるとコーチェットでは考えているのですが、今回の勉強会ではスキルのうち基礎的な傾聴と承認について取り扱うことにしました。
対話の場における「傾聴」はただよく聞くということではなく、相手に意識を向け、相手に集中することです。
コードレビューの場面ではどうなるでしょうか?
対話のようなリアルタイムの相互作用はありませんが、コードを通じて相手を理解しようとすること、コンテキストを理解しようとすることが「傾聴」的姿勢にあたりそうです。
例えば、汚い書き方をみたときに「クソコードだな」ではなく「なぜこの書き方になるんだろう?」と考えること、です。
ガイドラインの存在を知らないのかな、前職ではどうだったんだろうな、時間がなくて焦ってたのかな、等々です。
コーチングスキル:承認
承認はなぜ重要なのでしょうか?
承認とは「褒めることや賞賛」ではなく事実を事実として認めることを指します。
承認は、相手との信頼の土台を築き、相手の成長に対する認知を促進したり、意欲を向上させたりして、自発的・主体的な行動を促します。
コードレビューという本質的には指摘をする必要がある場面でも、承認があるのとないのとでは大きく違ってきます。
承認には4種類あります。
存在承認 例)「おはよう」、名前を呼ぶ、目線を合わせる
行動承認:例)「◯◯さんに相談されたんですね」「毎日続けているんですね」
成果承認:例)「目標に向けて一歩進み始めましたね」「ついに、やり遂げましたね」
成長承認:例)「以前よりも〜〜ができるようになりましたね」
勉強会では次に具体的な受け答えの場面を見ていただきました。
ファシリテーター2人が上司役部下役になって上の会話文を読み上げました。
この会話の中ある「承認」のコメントはどれでしょうか?またいくつあるでしょうか?
勉強会ではZoomのチャットも活用しながらあげていただきました。
というコメントもありました。
上記ケーススタディには承認のコメントが4種、4箇所あるのですが、おわかりになりますでしょうか?
承認の意味や効果を理解したとしても、なかなかスムーズに承認の言葉をかけることが難しいこともあります。一定慣れも必要ですし、何かの「こうあるべき」というポリシーやおそれが邪魔をする場合もあります。
スムーズに承認できないとすると、どんな理由があるかを考えていただきました。
3のケーススタディとして以下のような話をする人に対して、どう応対するかを見ていただきました。
必ずしも賛同できる考え方ではないかもしれませんが、上記のように自分の価値判断を脇において、否定的にならない応対も可能です。
相手を承認することと、相手に賛同する・相手の価値観を受容すること、は必ずしも同じではありません。
承認は相手の認知を促進するために、客観的な視点を提供するためのものであり、こちらの主観や価値観のフィルターを通す必要はないのです。
ロールプレイ
最後に、こちらがランダムに選んだ2人1組でブレイクアウトルームに分かれていただき、承認の練習として「簡単にお仕事について教えていただけますか?」という問いから対話をしてもらう、というロールプレイを行いました。
AさんBさんのペアの場合
Turn 1(7分)
Turn 2(7分)
チェックアウト
チェックインの時にお話しいただいた期待と比べてどうだったかも含めて、順番にお話しいただきました。
等のコメントをいただきました。
振り返り
勉強会のあと、運営メンバーで振り返りを行いました。
最後の対話での承認ロールプレイを行なった後に、「コードレビューの場面で使える承認の言葉」をあげるワークを行うと、よりよかったのではという意見がありました。
チェックアウト時には、コードレビューに応用できるというコメントもいただいておりましたが、抽象度の高い学びに対して、具体的な言葉集をつくることができれば
「勉強会を通じて得た視点をもとに、コードレビューの場面を想像して言語化する」
というトレーニングになったということと
「承認のために使える言葉集」
をお土産として持って帰っていただくことができる
という2点の効果を生むことができたのではと、ちょっと惜しかったなという気持ちがあります。
もし同様のテーマで勉強会を開催することがあれば、是非そこまでやってみたいと思います。
ご参加いただいた皆様ありがとうございました。
今後も不定期ではありますが、勉強会を企画していきます。
またご都合のあうときにはご参加いただけるとありがたいです。
当日は弊社のエンジニア2名も参加させていただいておりました。
そのうち高橋のインタビュー記事がありますので、もしご興味のある方はご覧になってください。
「コーチング」を手がけるコーチェットだからこそ経験できる、エンジニアの仕事の醍醐味とは?