3つのコミュニケーションパターン
会社でコーチング研修があり、(主に部下と1on1を想定して)コミュニケーションパターンが以下の3つに分けられるという話がありました。
- コーチング：
「答え」は相手の中にある
相手の話を聞く/問いかける/人となりを認める - ティーチング：
「答え」はこちらにある
知識ややり方を教える/相手が理解してないことを説明する - フィードバック：
成長を促すために、周りからどう見えているか、思われているかを伝える
ポイントは
「いつもティーチングで自分が思うことばかり言ってしまってないか？アプローチには種類があることを認識し、適切に使い分けていこう」
という話でした。
これだけでもとても面白い話だったのですが、「これ、コードレビューでも同じではないか？」と思ったのです。
レビューにおけるティーチングとコーチング
ティーチング
ティーチングはいわゆる「指摘」です。
プルリクに対して
「ここは○○なので××にしてください」
というコミュニケーションは、レビューの中では一般的ですよね。
これはこれで、コードの品質担保には重要なコミュニケーションです。
ただ、結構これだけだと「はーい、直しました」ってレビュー投げ直して終わり、となりがちですよね。
ただの凡ミスとかなら良いですが、後輩にきちんと設計の意図を考え直してもらいたい時などは、「指摘された通りに直す」だけだと学びが浅くなりがちです。
コーチング
そこでコーチングのアプローチをとってみるとどうなるでしょうか？
- コーチング：
「答え」は相手の中にある
相手の話を聞く/問いかける/人となりを認める
これを応用すると、
- なぜそのような書き方をしたのか聞く
- きちんと意図を持って書いてたのならそれは認める(考えてなかったらオコ)
- 「この書き方だとこういう時に困らない？」「それを避けるにはどうしたらいいと思う？」と考えさせてあげる
というコミュニケーションになるでしょうか。
さきほどのコミュニケーションにくらべると、明らかに考えを深めることができそうですね。
これはもしかしたら、PR上のテキストではなく直接コミュニケーションするなど、やり方を考えても良いかもしれません。
まとめ
大切なことは、まずアプローチには種類があることを認識することだと思います。
3種類あることを知らずに同じようなアプローチを続けるのと、知った上で一つのアプローチを意図的にするのは大きく異なります。
ぜひこの3種類を認識して、普段のコミュニケーションをふりかえってみてはいかがでしょうか？
参考資料
コーチング講習の課題図書で以下の2冊が配布されました。どちらも読みやすい本だったので興味がある方は手に取ってみてください。
コーチはこちらの方でした
