コードレビューにこそ、コーチングのアプローチを適用するべきかも - little hands' lab

3つのコミュニケーションパターン 会社でコーチング研修があり、(主に部下と1on1を想定して)コミュニケーションパターンが以下の3つに分けられるという話がありました。 コーチング： 「答え」は相手の中にある 相手の話を聞く/問いかける/人となりを認める ティーチング： 「答え」はこちらにある 知識ややり方を教える/相手が理解してないことを説明する フィードバック： 成長を促すために、周りからどう見えているか、思われているかを伝える ポイントは 「いつもティーチングで自分が思うことばかり言ってしまってないか？アプローチには種類があることを認識し、適切に使い分けていこう」 という話でした。 これだけでもとても面白い話だったのですが、「これ、コードレビューでも同じではないか？」と思ったのです。 レビューにおけるティーチングとコーチング ティーチング ティーチングはいわゆる「指摘」です。 プルリク

[umai_bow]

分かる。教育としてはそれが正しいのは分かるけど、コードレビューの目的はコードの品質を保つことだから、これを100%実践するのはためらってしまう

[koogawa]

面白いアプローチ

[vanbraam]

"××にしてください"というコメントはしないようにしている.する時も必ず"○○なので"という理由を書く.また変に感じたコードでも,必ず"なぜそのような書き方をしたのか聞く".自分が間違っている可能性もあるので

[take_she12]

確かに。大事な視点。

[ch1248]

臨床心理学の応用っぽい。

[Dai_Kamijo]

ティーチングとコーチングの言葉の違いを初めて知った。個人的にティーチングは苦手なので、できるかぎりコーチングばかりしてるなー。 — Yoshihiro Kameda (@kmdsbng) January 15, 2018 from Twitter https://twitter.com/Dai_Kamijo January 16, 2018

[dexia2]

チームのコードの場合、「考えていればOK、やってみよう」というわけにはいかず、ある程度答えみたいなものがあるんじゃないかと思います。なので、効果は限定的かと。