『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』を読んで

伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書 | 翔泳社

コードレビューを円滑に進めたいあなたへ。 効率的なテキストコミュニケーションの技法を身につけよう。 コードレビューは、チームで開発するプロダクトの品質を高める重要なプロセスです。しかし、オンライン上のテキストコミュニケーションが基本となるコードレビューでは、「意図が正しく伝わらない」「受け手がネガティブに受け取ってしまう」などのすれ違いが頻発し、手戻りや誤解を生んでしまうことも少なくありません。 本書は、そんな意図や感情のすれ違いを起こさない「伝わるコードレビュー」の技法を解説した書籍です。具体的な19の事例シーンをもとに、わかりやすいプルリクエスト・レビューコメントの書き方や効果的なレビューの進め方を詳しく解説します。 事例シーンは、 ・緊張感のあるレビューコメントが返ってきたとき ・説明不足のPRが提出されたとき ・考え方や価値観が食い違ったとき など、開発現場のコードレビューでよくあるミスコミュニケーションのケースを収録。かわいいキャラクターとともに、問題の原因と対策を整理し、実践的な解決アプローチを提案します。 「レビューのつもりが指摘合戦になってしまう」 「何を伝えたいのかわからないコメントが飛び交ってしまう」 そんな悩みを抱える開発チームにとって、本書はよりよいコードレビューの指針を示すガイドラインになるはずです。レビューの指摘が的確に伝わり、レビューを受ける側も納得感をもって改善できる―そんなスムーズなコードレビューの技法を、本書で身につけましょう。 ■解説TIPS（一部） クイズを出さない／性善説で考える／チームで共有するタグを作る／作業ログをつけて参照場所をリンクする／相談までの時間を決める／わからないレベルを伝える／自分の考え・意見を添える／詳細を明示する／「念のため」の確認をする／上手に催促する／聞きたいことを絞る／Before／Afterの画像を載せる／テンプレートを用意する／ラベルをつける……他、多数の実践的なTIPSを収録！ ■対象読者 ・コードレビューのよりよいやり方を知りたい現場のエンジニア、メンター ・チーム全体でコードレビューの指針を整えたいリーダー・マネージャー ・はじめてコードレビューをする新人エンジニア

shoeisha.co.jp

転職活動も終わって有給消化期間になったので、今まで気になっていたけど読めていなかった本を読みました。今回読んだのは『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』という本です。

この本、題材がコードレビューだけど、本質的には「上手な伝え方の教科書」という感じでした。仕事では Slack とかでテキストベースのコミュニケーションを取ることが必ずあるけど、その際にどうすればお互いが気持ち良くコミュニケーションを取れるかということを教えてくれています。

まず、この本を読んだ率直な感想としては、自分はこれまで一緒に働く人に恵まれてきたし、そんな環境の中で自分もこの本でNGパターンとして挙げられているようなコミュニケーションを取らないように自然と成長してこれたことに本当に感謝だなという感じです。

この本の構成として、項目単位で「NGパターン → 改善例」という流れで色々なパターンを紹介してくれているわけですが、例えば「長文より箇条書きで書いたほうが読み手には伝わりやすいケースがある」という情報の整理の仕方みたいな観点もあれば、「こう書いてしまうと相手に威圧的に受け取られてしまう」という威圧的で接しにくい人と思われないようにみたいな観点もあるんですよね。

自分的に後者の例ってその人が持つ性格的なもののウェイトが結構大きいと思っていて、それって周りが色々言っても直すのが難しくて、当事者がこういう本を読んで気付くことで自発的に直してくれることを祈らないといけない部分もあると思うので、そういう人と自分は接する機会がなく（第三者ポジジョンで遭遇することはあったけど）、ちゃんとお互いに気を遣いながらコミュニケーションできる人がいる中で、自分もそこに追いつけ追い越せで生きてこれたのは良かったです。

というわけで、自分はこの本を「そうだよね。こういうコミュニケーションはいけないよね。書かれていることはしっかり意識できてるからこれからもそれをしっかり続けられるようにしよう」って感じで読んでました。

なんか味気ない感想文になってしまったので、「伝わるコードレビュー」という観点について、本の中では「PR」にテンプレートを作るということが紹介されていました。いわゆるpull_request_template.mdで用意するやつですね。たしかにこれでPRに記載すべき項目をチーム内で統一するのは大事です。

ただ、その項目の中身の書き方については各人で個性が出るところではないでしょうか？

なので最後に自分が実践している方法を１つ紹介したいと思います！

長い情報や補足情報は details タグでアコーディオンにする

これです。AI 時代になってレビューに疲れることも多くなってきたと思います。その中で PR の説明が長文だとそもそも読むのが疲れるし、読み手に何が本当に必要な情報なのか伝わりにくいというデメリットがあります。

なので自分は、クエリの実行計画や API をクラスごとに PR を分割する場合の API 全体の設計図みたいなやつは details タグでアコーディオン UI にして隠すことで、 PR の概要と詳細を読み手が意識することなくレイアウトによって自然と識別できるような作りになるように意識しています。

また、details タグに限らず、PR の Markdown は HTML タグを使えるので読み手に伝わりやすいようなレイアウトにすることが可能です。table タグで表を書くと ul, li タグで表の中に箇条書きができるのでそれもよく使います。

フロントエンドが好きなので「見る人にとって分かりやすいか」という観点はこういうところでも気になっちゃうんですよねー。

というわけで、これからも相手を思いやったコミュニケーションができるように気を付けていきたいですね。