CodeZineを運営する翔泳社より、4月28日(月)に書籍『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』が発売となりました。
コードレビューはチーム開発の現場でプロダクト改善に不可欠です。しかし、不穏なレビューコメントや説明不足なPR、本筋から離れた指摘合戦など、テキストコミュニケーションにおける意図や感情のすれ違いが問題になることが少なくありません。
本書ではレビューをする側も受ける側も、気持ちよく納得して改善に取り組めるようになる「伝わるコードレビュー」の技法を解説しています。 具体的な19の事例シーンをもとに、「こんなときどうすれば」がわかるようになる1冊です。
進捗が遅れているPR、考え方・価値観の食い違い、「あの人が言っているから大丈夫」という思考停止、質問コメントに答えない修正PR、気を遣いすぎたレビューコメント──こうした事態に出くわしたことがあるなら、よりよいコードレビューのガイドラインとして本書をおすすめします。
目次
Part1 心構え編
・「伝わるコードレビュー」とは
-この本は何のための・どのような本か
-コードレビューの利点と難しさ
-コードレビューはコミュニケーション
・伝わるコードレビューの5大ルール
-コードレビューで守るべきルール
-ルール(1):決めつけない
-ルール(2):客観的な根拠に基づく
-ルール(3):お互いの前提知識を揃える
-ルール(4):チームで仕組みを作る
-ルール(5):率直さを心がける
-コードレビューは双方向のコミュニケーション
Part2 実践編
Case1:緊張感のあるレビューコメント
Case2:説明不足のPR
Case3:進捗が遅れているPR
Case4:考え方・価値観の食い違い
Case5:細かすぎるレビューコメント
Case6:Lintツールの言いなりの修正
Case7:「あの人が言っているから大丈夫」という思考停止
Case8:質問コメントに答えない修正PR
Case9:レビューポイントがわかりにくいPR
Case10:気を遣いすぎたレビューコメント
Case11:レビューされないPR
Case12:前提が揃っていないPR
Case13:コメントへの訂正情報の不足
Case14:放置された議論
Case15:見過ごされた質問コメント
Case16:想像に基づく修正
Case17:調べる前に相手に投げてしまう質問
Case18:関係者へ確認ができていないPR
Case19:感情的なコメント
Part3 TIPS編
1:クイズを出さない
2:命令しない
3:性善説で考える
4:相手の意図を断定しない
5:まずは共感を示す
6:チームで共有するタグを作る
7:Lintツールを入れる
8:作業ログをつけて参照場所をリンクする
9:相談までの時間を決める
10:詰まっていることを伝える
11:わからないレベルを伝える
12:遠回しに言わない
13:自分の考え・意見を添える
14:根拠がないなら根拠がないことを添える
15:詳細を明示する
16:何をして欲しいかを伝える
17:「念のため」の確認をする
18:同期コミュニケーションに移行する
19:質問先を明示する
20:上手に催促する
21:期限を明示する
22:すぐに返せないことを伝える
23:聞きたいことを絞る
24:相手の知識に合わせる
25:はい・いいえで答えてもらう
26:論破ではなく納得を目指す
27:Before/Afterの画像を載せる
28:「やっていないこと」を書く
29:テンプレートを用意する
30:ラベルをつける
31:箇条書きを使う
32:レビュアーを指名するロジックを作る
33:相手の理解の段階を踏む
この記事は参考になりましたか?
- この記事の著者
-
渡部 拓也(ワタナベ タクヤ)
翔泳社マーケティング課。MarkeZine、CodeZine、EnterpriseZine、Biz/Zine、ほかにて翔泳社の本の紹介記事や著者インタビュー、たまにそれ以外も執筆しています。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社