本記事は『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』（著者：鳥井雪／久保優子／諸永彩夏）の「Case 1 緊張感のあるレビューコメント」などから抜粋したものです。掲載にあたって編集しています。
緊張感のあるレビューコメント
お昼休みが終わった午後のオフィス。入社1年目のプログラマーのポチ田がPCの画面を見て青い顔をしています。ポチ田はこのプロジェクトに入ってまだ1ヶ月。先輩プログラマーのミミ沢が、心配して声をかけました。
ポチ田は涙目で、PCのモニタを指差します。そこには、午前中にポチ田が出したPRの画面が映っていました。レビューコメントが1つだけついています。
ベテランプログラマー、タマ本からのコメントです。
ポチ田はすっかり尻尾を丸めておびえています。聞けば、ポチ田は午前中にこのコメントをもらって、なんと答えればいいかお昼休みの間中悩んでいたとのこと。
なるほどね、とミミ沢は肩をすくめました。それから、タマ本のいるデスクまで行って、タマ本と軽く話をします。しばらくすると、タマ本のコメントが更新されました。
解決のアプローチ
レビュアー編
更新されて、タマ本のコメントは次のように変わりました。
以前に比べ、コメントの内容がずっと具体的になりました。タマ本が尋ねたい内容も明確で、ポチ田がタマ本のコメントの真意をいろいろと推し量る必要もありません。
レビュイー編
更新されたコメントを見て、ポチ田は嬉しそうに鼻を動かしました。
率直さは、PRのコミュニケーションでは価値のあるものです。コメントの意図がわからなかったら、そのまま返信で聞けばいいのです。悩みに悩んでお昼休みを無駄にすることはありません。
解説
今回のCaseにおける問題の詳細と改善のコツを見ていきましょう。
問題1 レビューコメントが言葉足らずで、質問の意図が伝えきれていない
タマ本は、2つの選択肢から1つを選んだ理由を聞くつもりで、「このメソッドを使ったのはなぜ？」とコメントしました。しかし、ポチ田にはその意図は全く伝わっていません。これはどうしてでしょう。
▶質問には理由がある
質問には、必ず「どうしてその質問をしたのか」という理由があります。しかし、当初のタマ本のコメントでは、その理由や背景の情報がまるっと抜けているのです。そのため、コメントを受け取ったポチ田は理由を想像するしかありません。その結果、「ダメってことかな……」と疑心暗鬼に陥り、質問への答え方もわからなくなってしまいました。
タマ本は、「自分が知っている知識は相手も知っている」「自分が考えるように相手も考えるだろうから説明は不要」と無意識に考えてしまっていたのかもしれません。更新されたタマ本のコメントには、次の改善点が見られます。
- 「[ask]」のように、コメントの意図を明確にするタグを利用する
- 「2つのメソッドのうち1つを選んだ理由が気になった」と質問の背景・理由を説明する
- 「今のコードでも問題はないと思うけど」と、批判でないことを明示する
- 「こちらを選んだ理由が知りたい」と、何を答えてほしいかを具体的に示す
レビューコメントで質問を行うときは、「質問の理由を伝えられているか」「何を答えてほしいかを示せているか」の2点を意識するとよいでしょう。この2点が伝えられていれば、質問を詰問と誤解される事態はぐっと減らせるはずです。
【改善のコツ】
- 質問の理由を伝える
- 何を答えてほしいかを示す
問題2 レビュイーが深読みしすぎて、コミュニケーションを止めている
ポチ田は情報不足の質問に、「ダメってことかな……」と悪い想像を膨らませてしまいました。そして、質問の意図を確認せず、思い悩み続けていました。
テキスト上のコミュニケーションでは、表情や声のトーンなどの情報が伝わらない分、相手の言葉を攻撃的なニュアンスで捉えてしまいがちです。そのため意識して、文章に書かれている以上の事柄を読み取らない訓練をしましょう。
もう1つの問題点は、ポチ田が「ダメってことかな……」と思いながら、タマ本にそう確認せずに悩んだままでいることです。これでは、仕事が前に進みません。そのまま無理矢理質問に答えても、タマ本が聞きたかった回答とは異なるちぐはぐな内容になるでしょう。
質問の意図に悩んだときは、率直に尋ねてみましょう。尋ねることで、タマ本も自分のレビューコメントの不備に気づくことができます。
▶行間を読むことの難しさ
行間を読め、とはよくいわれますが、行間を読む必要のあるコミュニケーションは高コスト、かつ誤解を生みやすいものです。行間を読む文化を育てるより、行間を読まなくても情報が出揃うコミュニケーション文化を作ることを意識しましょう。
文化の形成などというと、大変な仕事に思えるかもしれません。けれど文化を作るのは、PRやチャットツールでの、ひとつひとつは些細なやり取りの積み重ねです。「質問の意図が掴めなかったのですが」から始まる率直な返信が、明確で効率のよいコミュニケーションを作っていくのです。
【改善のコツ】
- 文章に書かれていること以上の事柄を読み取らない
- 質問の意図がわからなかったら、わからなかったことを伝える
TIPS クイズを出さない
テキストコミュニケーションにおいて、相手に推測させるのは悪手です。上記の例のようなクイズを出されると、相手は「試されている」とストレスを感じます。期待に応えられるか、失望されるかもしれないと気を揉みますし、関係性によってはバカにされていると感じるかもしれません。さらに、相手がクイズに答えたあと、その答えが期待通りの答えであったにしろなかったにしろ、クイズを出した側が回答をする、というやり取りが増えてその分時間もかかります。
また、クイズはその性質上、「問題を出す側は答えを知っていて、出される側はその答えを当てなければならない」という前提があります。クイズを出す側と、出される側での立場の強弱が自然と生まれてしまうのです。意識せずとも立場の強弱を作ってしまうやり方は、レビュアーとレビュイーの「二人三脚で問題を解決しよう」という意識に悪影響を及ぼします。
クイズよりもよい方法を探そう
クイズを出してしまう意図は、「理解度を試したい」か「自分で調べて考えることで身につけてほしい」といったものが多いと思います。理解度については、改善の余地のあるコードが出てきた時点で期待より不足していると判断できます。自分で調べてほしいなら、クイズのような曖昧で意図の読みにくいアプローチをするべきではありません。「この領域について理解を深めてほしいから、このドキュメントやこの単語を調べてください」と、コードレビューとは別のチャンネルで始めましょう。
そうすれば相手は、あなたの意図を勘ぐるコストを払わずに済みます。もっと理解を深めてほしい、という意図が明確になるためです。その上で「理解度を確かめるために、次の設問に答えてください」と問いかけるのは全く問題ありません。唐突にクイズを出して「この人は自分に何を求めているのだろう……」と戸惑わせるのは避けましょう。
また、次のようなコメントも、意図の読み取りづらいクイズをしているBadパターンの1つです。
次のように相手にしてほしいことを率直に伝えるほうが効率的です。
TIPS 性善説で考える
コードレビューの最中、「この人は怠けてこんな読みにくいコードを書いているのではないか」と思ったり、「こんなまわりくどいコメントをするなんて、馬鹿にされているのでは」と感じたりする瞬間はありませんか？ そんなときは一度深呼吸して、別の可能性を考えてみてください。ハンロンの剃刀、「無能で説明できることに悪意を見出すな」の原則です。能力不足が原因で起きていることを、悪意のせいにしてはいけないのです。
読みにくいコードになってしまっているのは、フレームワークへの理解不足や、抽象化の経験不足のためであり、怠けによるものではないかもしれません。コメントがまわりくどいのは、レビュアー自身も言いたいことをまとめられていないためかもしれません。
相手の悪意を前提としてコミュニケーションを開始してしまった場合、こちらからの返信コメントが喧嘩腰になってしまうこともあるでしょう。その結果、コミュニケーションがぎくしゃくし、本当は存在しなかった「悪意」が発生してしまうこともあるかもしれません。それを感じてあなたは、「やっぱり最初から悪意があったんだ」と思うでしょう。これはコミュニケーションとして最悪のパターンです。
悪意を前提にしないコミュニケーションのすすめ
実のところ、「実際に悪意があるかどうか」は問題ではないのです。仮に怠けたことによって読みにくいコードが生まれたとしても、「この書き方では読みにくいので改善してください」と指摘し、それが改善されればコードレビューの目的は達成されます。嫌味のたっぷり入ったコメントに対し「意図が汲み取れなかったかもしれないのですが、こういう意味で合っていますか？」と素直に聞き返して、詳しい説明が返ってくればそれでいいのです。
存在しようがするまいが、悪意を前提にコミュニケーションを始めては、自分にかかる負荷が増えるだけで、よいことはありません。コミュニケーションを続けて、それでもよい方向に事態が進まない場合にだけ、あらためて第三者に入ってもらうなどの対策を考えるとよいでしょう。
もちろん、人格を攻撃するような発言や、ハラスメントに当たる行為には毅然と対応するべきです。あくまでも、「この人はきっと悪意でこうしている」という自分の決めつけが存在していないかをチェックし、想像しすぎている場合は性善説を採用するほうがよい、ということです。
