新発売の情報を見たときに「面白そう」と思って予約し、発売日ごろに手にしていたのですが、やっと読みました。
結論、なかなか良さげでひとにもオススメできるなーと思いました。また、自分のようにQAエンジニアで普段コードレビューしない人にとっても、読む意味がありそうです。
読んだ背景
前述の通り普段コードレビューはしていないのですが、コードレビューも最終的に品質向上につながるはずだと思っているので、そのあたりのつながりや開発者に対して共有できるヒントがあればと思ったのがひとつ。
もうひとつは、コードレビューはしていないもののテストケースのレビュー等は行っているので、そういった他のレビューに応用できる何かが得られれば、という意図もありました。
本の内容
コードレビューによくあることとして、
- 説明不足
- 意図が伝わらない
などでレビュワー・レビュイー間がギスギスしてしまい、結果としてチームの雰囲気が悪化・・・ということがあります。
そういったことを減らして、コミュニケーションを良くすることで開発効率や品質UP、というのが本書の狙いだそうです。
本書の論旨構造としてはこのような形です。
チームの力を最大限に出して、高品質な成果物を出したい。
そのためにはメンバー同士の信頼関係を築くことが大事で、さらにそのためには率直で効率的なテキストコミュニケーションを行う必要がある。そのための技術を学びましょう、ということです。
コードレビューはコミュニケーション
コードレビューは本質的に批判・批評なので、レビュイーとしても素直に聞けなかったり身構えたりしてしまうのが難しさです。コードと人格とを切り離してやりとりすることが大事ですが、とくに言われた側がそれらを切り離して捉えるには一定の訓練が要ります。
コードレビューはレビューアーとレビュイーのコミュニケーションであり、やりとりする情報に過不足があったり余計な情報を察したりしてしまうとすれ違いが発生します。コミュニケーションではあるものの、互いに人対人として向き合うとズレるので、そうではなく問題対私達の構図でコミュニケーションをとる必要があります。
本書に記載の「コードレビュー」の説明として、以下の表現が気に入りました。
受け入れ可能なコードの状態を目指してレビュアーとレビュイーが二人三脚でコードを改善していくもの
コードレビュー５つのルール
以下がコードレビューのルールとして紹介されていて、それぞれについて具体例を交えて説明があります。
- 決めつけない
- 客観的な根拠に基づく
- お互いの前提知識を揃える
- チームで仕組みを作る
- 率直さを心がける
さらに、５つに紐づくTipsもPart3で紹介されていて、読んで１つずつ実践するのによさそうです。
感想
冒頭で「QAエンジニアにもオススメできる」と書きましたが、その理由は本書で述べられている話が コードレビューに限らずエンジニアリングの現場におけるコミュニケーション全般で大事なことだから です。
上述のコードレビュー５つのルールなどもそうですが、そのまま「エンジニアチームのコミュニケーション５つのルール」にしても違和感ないように思います。Slackでのやりとりやビデオ会議中のやりとりにおいても、同じことを気をつけたほうがいいなー思いながら読みました。
QAエンジニアは開発者とのコミュニケーションを日常的にとりますし、たとえばテストでのバグ報告などはコードレビューと同じく批判・批評的な側面もあるため、伝え方のポイントなどはかなり通じるところがありそうです。
普段から「心理的安全性が大事だよね」といったことは多くの開発現場で語られていると思いますが、じゃあ心理的安全性って何よ？と考えたとき、それを実現するためには本書に出てくるようなちょっとした心がけをチーム皆が積み重ねた先でたどり着ける状態のはずです。
具体的なスレ違いのエピソードをもとにどのような言い方・伝え方をすべきだったのかレベルで説明してくれているので、チームで輪読したりするのも良さそうです。
追加情報
類書としては、『間違いだらけの設計レビュー』も挙げられます。
コードレビューと設計レビューとで違いはありますが、チーム内のコミュニケーションを良好にして、その先の（本来そのレビューが実現したい）成果につなげよう、という考え方のベースは似ているように感じました。
『間違いだらけの設計レビュー』のほうが骨太というかページ数が多いので、先にこちらの『伝わるコードレビュー』を読んで、もっとレビューに関してがっつり知りたいという場合に『間違いだらけの設計レビュー』のほうに手を伸ばすのが良いでしょう。
過去レビュー記事も書いているのでよろしければこちらもどうぞ。＞『間違いだらけの設計レビュー第3版』を読んだ - テストウフ