伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書 - FL#93に参加してきた

伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書 - FL#93 - connpass

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

開発現場で欠かせない「コードレビュー」。しかし、「どう伝えるか」「どう受け取るか」で、チームの雰囲気も生産性も大きく変わります。

本書では開発現場のコードレビューでよくあるミスコミュニケーションのケースを例に、意図や感情のすれ違いを起こさない「伝わるコードレビュー」の技法を解説した書籍です。 今回は著者の鳥井 雪 氏、諸永 彩夏 氏、久保 優子 氏にご登壇いただき、さらに監修の島田 浩二 氏をモデレータに迎え、視聴者Q&Aパネルトークセッションを含めた勉強会を開催いたします。

会の様子

講演

本を書いたきっかけ

会社がめちゃくちゃテキストコミュニケーションに強い企業だったこともありテキストコミュニケーションに関する声がかかったそうですが、広範囲すぎてフォーカスを絞ろうという話になり、コードレビューに絞って本を書くようにしたということでした。

本を書く際に気をつけたこと

• レビュワー/レビュイーどちらかが改善をするような話ではない
• 性別は特定しない
• 自分のことは棚上げする
• 問題×私達にする
• 悪意を見出さない

印象的だったこと

「まずは共感を示す」に関しては、島田さんからうわべだけの"共感"を示したりテクニックとしての"共感"を読者がしないようにしてほしいというお便りをもらって、一から書き直した場所なので印象に残っているという話が久保さんからありました。

本書に込めた想い

レビュアーは余すことなく気持ちを伝えるようにしてほしいという話が出ていて、思っていること(成長してほしい、期待している、これよくありがちな勘違いですよね...)は余すことなく伝えるようにしたほうがいいという話が出ていました。

レビュアーに伝わるPRの準備

自分が一番多くの情報を持っているということに自覚的になったうえで、レビュアーに対して特に伝えたい箇所を絞って伝えるようにするのが重要だという話がありました。
レビュアーは知識があるだろうという前提に立たないようにしたり、コミットを分けるなどといった工夫をするようにするといいということです。

また、レビュアーから冷たいコメントが返ってきたように感じたときも、そのコメントになにか想いなどを上乗せしたりせずに相手を信頼して、素直に「こういう意図なのかな？」と聞き返すみたいなことをしていくのが重要だという話がありました。

Q&Aパネルトーク

講演の後はQ&Aパネルトークがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

レビューコメントで必ず修正してほしい、参考情報、みたいなレベル感をどのように調整しているか？

レビューコメントにmust, wantみたいなラベルをつけるのがいい。

レビューのタイミングで基本設計やアーキテクチャの問題を話す際に苦慮しているのだが伝え方で改善できる部分はあるか？

• なんでそういうことに思い至ったのか？をコメントとして書き残す
• レビューだとすごい長文になって大変そうなので、MTGとかでやり取りしたほうがいいのかな、と思う

レビュアーとレビュイーで意見が分かれた場合のプラクティスは？

• お互いになぜそっちの方がいいと思っているのか？から話し合う
• 理由とかまでしっかり話した上で意見が対立することは経験上まずない印象はある。それでも意見が対立しているのであれば、今どういう状況なのか？とかも整理するといいのかもしれない

レビューで厳しいレビューがきてうっとなったときにレビュアーはどう対処するといいか？

• まず画面から立ち上がるがいいと思う。投げられた後にそのまま勢いで書くと剛速球を投げ返すみたいになりがち
• コアプロトコルという手法があり、「今の指摘を受けてこういう風に思いました」と伝えると良いと思う
• もっと辛いことを思い出して「これよりはましか」と思うようにする

全体的におかしいコードはどこから指摘する？

• ペアプロしちゃうのがいいと思う
• 一緒にやろうか、みたいな方が問題が少なく感じる
• 根本的なところから話しちゃう、みたいなのはある

レビューが辛いとか怖いみたいな気持ちを和らげるためには？

• レビュアーと雑談する
• レビュー前レビューを仲が良い人にお願いする(もしそこで見逃されたらあの人も見逃したしなあみたいな感じで済ませる)

レビュアーとして根拠を明示したほうがいいと思うがレビュイーのレベルに合わせてどういうところを気をつけるとかはあるか？

• 一発で答えを出そうとしないようにする
• 逆にレビュイーに関しては「分かりました」だけはやめたほうがいいと思う
• 親切心でわーっと書いて相手が受け入れられないみたいなのはあるが、そこは探り探りでやるといいと思う

2approveが必須の場合の工夫は？

• 時間を優先したいのか品質を優先したいのかを改めて考える
• Approveする人への催促もコミュニケーションだと捉える

もらえて嬉しかったコメントはあるか？

• 褒めるよりも認める方がまずはいいと思う(ここはきちんと書けているね、と言ってあげることが大切)
• 書いた1年後くらいに褒められたコメント
• 「自分も同じ考えになるかな」みたいなのは嬉しい
• ディスクリプションの書き方がわかりやすかったね、というのをエンジニア以外から褒められたときは嬉しかった

会全体を通した感想

きめ細やかな回答が多かったですし、心構え的な話はありつつも具体的な振る舞いレベルでのコメントが多かったので、やはり普段から実践されている人たちのアドバイスは解像度が高くてすごく良いなと思いました。