アジャイル開発のコードレビューで、建設的なコミュニケーションを行うための心構え

コードレビューの目的

【プラクティス】ソースコードの共同所有

筆者はコードレビューの一番の目的を「ソースコードを書いた人の持ち物から、チームの共同所有物にする」ことだと考えています。ソースコードの共同所有とは「リポジトリのどの箇所もチーム全員が断りなく修正できる。またすべてのソースコードに関する責任を全員が担う」ことを意味します。

　構成管理システムが進化し便利になったことで、コードレビューは頻繁に実施されるようになりました。しかし考え方の違いからコメントのやりとりが長くなったり、それによって空気が悪くなってしまったり、ときには喧嘩になったりします。「目を皿のようにしてロジックを調べ、バグがないか確認する」ようなコードレビューを行う人がいますが、コードレビューでバグを見つけるのはコストがかかる難しい作業です。

　またコードレビューでバグを見つけるにはスキルが必要であり、担当できる人数も限られるでしょう。その人にコードレビューが集中すると業務負荷が高まり、意図せずリポジトリの門番になってしまうことも避けられません。バグがないか確認したいのであればテストコードをきちんと書くべきです。仮にテストコードが書きにくい箇所だったとしても、開発者がきちんと動作確認を行うべきです。

　ソースコードをチームで共同所有していくには、リーダーや管理者などの限られた代表者だけが許可／承認する状態をなくしていく必要があります。限られた人のみが許可／承認を行う場合、責任の所在が明確になったり、責任者からのコードレビューの指摘が通りやすくなったり、意見が分かれても言い争いになりにくくなったり、といったメリットがあります。しかし、これは諸刃の剣です。チームが「ソースコードは責任者が管理するもの」と考えてしまったなら、共同所有とはいえません。

　人ではなくソースコードに目を向ける意識が重要です。「ソースコードのこの箇所がちょっと読みにくかったです」などと率直に伝えるとよいでしょう。知らない設計や技術が持ち込まれた場合でも、チームとして学び、運用していけるように教育や学習の機会として活用していきましょう。

建設的なコミュニケーションのための心構え

　コードレビューはソースコードをよりよくするための作業です。設計や技術のあるべき形について、建設的な議論を積み重ねるためにいくつかの点に気をつけなければいけません。

【プラクティス】レビュアー／レビュイーから伝える努力

　レビュアーとレビュイーの双方が、考えていることを丁寧に言語化し、伝える努力を尽くします。考えていることをお互いに伝え合わないと、どこまで話をしても意見が合いません。そのため、レビュアーはレビュイーに伝わるようにフィードバックしましょう（図1）。

　コードレビューとなると「すごい指摘をしなくては」と身構えてしまいますが、まずはソースコードを読んで感じたことを素直に伝えるところから始めましょう。読みにくいソースコードがあれば「ここが読みにくい」と素直にコメントし、ソースコードの意図がわからなければ「この箇所がよくわかりませんでした」と伝えてください。

　問題や直したほうがよい箇所の指摘以外でも、「いいね」「勉強になりました」「LGTM（いいと思う）」といったポジティブなフィードバックもレビューを建設的な雰囲気にするのに役立ちます。フィードバックとしてコメントした内容が、相手に必ず伝わるとは限りません。もし伝わらなければ、異なる言い回しを試してみましょう。「伝わらないのは読み手のスキルが足りないからだ」などと相手を責めていても、建設的な議論はできません。

　レビュイーも現在の作業状態や、自分の考えをレビュアーに伝える必要があります（図2）。実装途中でコードレビューを行ってもらう場合は、まだ実装途中である旨を伝えましょう。プルリクエストのタイトルにWIP（Work In Progress）と含めて作業中であると示したり、GitHubなど、特定のプルリクエストについてドラフト状態であることを表明できるGitホスティングサービスもあります。

【プラクティス】プルリクエストテンプレート

　コードレビューで見てほしいポイントや、懸念点があれば先に伝えましょう。プルリクエストの説明欄に記載したり、プルリクエストでソースコードへのコメントを書き込んだりできます。プルリクエストのテンプレートを整備して、見てほしい箇所や悩んでいる箇所を記載させる仕組み作りもできるでしょう（図3）。

【プラクティス】協働作業でソースコードをよくする

　コードレビューはレビュアーがレビュイーの書いたソースコードを一方的に批評／評価／承認するのではなく、双方が協力／協働してソースコードを改善する作業です。批評／評価／承認の意識があると、レビュアーの指摘はソースコードではなく相手（レビュイー）個人に向いたものになりがちです。以下は協働作業でソースコードを改善する意識を育むために、レビュアーが避けるべき行動です。

• 不明瞭な言葉遣い
• きつい言葉遣い
• 個人への攻撃や口撃
• その他相手にコードレビューを受けたくないと思わせるような行動

　このような行動がコードレビューで取られると、レビュイーが身構えて心理的な負担がかかり、コードレビューに要する時間も長くなります。

　これは決して、踏み込んだ指摘は行わない、という意味ではありません。コードレビューを甘くやることにメリットはありません。建設的な提案なのだと相手に受け取ってもらうには、主張の根拠や背景をきちんと示すとよいでしょう。漠然と「このソースコードの書き方がよい」と伝えるより、「コーディングルールのここに従っていない」や「読みやすいソースコードを解説したこの書籍によると……」と具体的に伝えてください。

　またよくないソースコードを指摘する際は、具体的な修正案が出せるとよいでしょう。Gitホスティングサービスによっては、プルリクエストのコメントで修正提案を出す機能が用意されており、レビュイーはボタンを押すだけで修正を取り込めます。誰が見ても不明瞭できついと感じる言葉遣いがある一方で、人によって受け取り方に差がある場合もあります。レビュアーにその意図がなくても相手を傷つけたり、不安にさせたりすることもあるでしょう。フィードバックはできるだけ丁寧にし、説明を省略しないように心がけるべきです。

【プラクティス】コードレビューのやり方を見直す

　1回のコードレビューで指摘事項が何十件も出てきて、どんなに丁寧なやりとりをしたとしても、レビュイーにプレッシャーを与えてしまいそうと感じた場合は、一度に行うコードレビューの分量を見直したほうがよいかもしれません。コードベースへの理解や慣れ、レビュアー／レビュイーのスキルレベルによって、適切なコードレビューのサイズは異なります。コメントの数が多く、やりとりが収束しないようであれば、小さな単位でコードレビューを分けられないか検討してみてください。

　もしくはレビュアーとレビュイーで席を並べて（またはリモートで顔を合わせて）、同期的にレビューを実施することもプレッシャーをやわらげるのに有効です。コメントの意図が伝わらなかったことに気づきやすくなり、伝え方を変える対応ができます。コメントのやりとりが続き、コードレビューが長期化した場合も同期的なコードレビューを始めるのによいタイミングです。コードレビューが長期化している兆候は、次のようなものがあります。

• コメント数が一定数を超えた
• 指摘を受けて修正したコミット数が一定数を超えた
• プルリクエストが作られてから所定の期間が経過した

【プラクティス】コメントにフィードバックのニュアンスを含める

　コードレビューで寄せられるコメントは、絶対に直さなければならないものから、ちょっとした指摘、レビュアーが感じたモヤモヤなど、さまざまなものがあります。コードレビューはすべてのコメントや指摘に対応する必要はありません。

　コメントにフィードバックのニュアンスを含めておくと、受け手に対応すべきかどうか判断を委ねられます。コードレビューでは短い言葉をプレフィックスとして付与し、気持ちを含めることが多いです。以下によく使われる単語とその意味を紹介します（表1）。

コードレビューでコメントが思いつかない状態を乗り越える

　「プルリクエストのコメントが思いつきません」という人が一定数います。理由は次のようなものをよく聞きます。

• 新しい会社に入った
• 新しいチームに異動した
• 技術／ドメイン（システムを適用する対象の事業領域や業務）に詳しくない

　いずれも「ドメインに詳しくなれば、じきにコメントできるようになる」ように思えますが、実際には3ヶ月経っても半年経ってもコメントができないことがあります。

　一方で会社に入ったばかりや、チームに異動してきたばかりでも積極的にコメントをしてくれる人もいます。技術／ドメインに詳しくないというのは表向きの理由で、実際は自信がない、指摘を返されるのが怖い、自分のスキル不足を知られるのが怖いという背景があるのではないでしょうか。

　コードレビューでの直接的なコミュニケーションを避け、他の人がプルリクエストでやりとりする様子を盗み見てキャッチアップをしていくのであれば、獲得できるスキルやドメイン知識は限定的なものになります。チームとしては多少の教育や説明の負荷があったとしても、参加したばかりの段階から積極的にコメントをしてもらい、早く開発に慣れてドメインを学んでほしいと思っているはずです。

【プラクティス】質問することで学ぶ姿勢を持つ

　質問することで学ぶ姿勢を絶えず持ちましょう。間違えても受け入れてくれる環境であることを信じ、自分のスキル不足を知られてしまう恐れを乗り越えて、積極的に質問してください。そうすることでより早くフィードバックと学びを得られます。また教える側も、質問のやりとりを通じて何につまずいているのかを理解し、相手の知識や理解度に合わせたサポートができます。早期にフィードバックを受けて学んでいけるほうが、本人の成長にとっても、チームや会社にとってもよいはずです。

　一方で精神的な不安や恐れがなくても、レビューのコメントが思いつかない場合もあります。他の人のコメントを見てその理解や後押しはできるのですが、自分が最初にコメントを書くことはできないという状態です。他の人よりコメントを書くのが遅いのではなく、時間をかけてもコメントをするべき観点に気がつけないのが特徴です。この課題について筆者は、よい設計やよい実装について考える習慣がないためだと考えています。このような人は、次に挙げる条件に当てはまることが多いです。

• 昔ながらのコードベースで、どこに何の処理を置くかが決まっている
• よい設計へと改善していく習慣が個人やチームにない
• 本人が動くプログラムを書くことに一生懸命で、よい設計を考える余裕がない
• 本人に設計を継続的に改善していくための技術的なスキルがない

　ある機能追加や修正を実現するやり方の正解は、1つだけとは限りません。冗長だったり、複雑だったり、今ひとつに感じたりする処理や設計を感じ取り、モヤモヤとして表明するところから始めましょう。1人で改善までやり切る技術スキルは備えていなくても、コードレビューでのやりとりを通じてアイデアが見つかるかもしれません。

　もしアイデアだけでも見つけられれば、ソースコードを改善するきっかけを作れたことになり、それが貢献になります。そうでなくとも、チームで議論するきっかけを作れれば、それは十分に貢献といえます。

　このように、ソースコードや対象のシステムがわからなくても貢献できることがあります。積極的にコードレビューに参加して、伝えられるフィードバックがないか探しましょう。長く同じソースコードを触っていると視点が偏り、気がつきにくいことが出てきます。チームに新しく参加した人からのフィードバックは、いつだって貴重でありがたいものです。

Amazon　 SEshop　 その他

 

アジャイルプラクティスガイドブック
チームで成果を出すための開発技術の実践知

著者：常松祐一 監修：川口恭伸、松元健
発売日：2023年7月20日（木）
定価：2,860円（本体2,600円＋税10%）

本書について

本書は、個々のプラクティスを取り上げ、それぞれの目的や考え方などの原理・原則、そして、チームや現場の状況に即したプラクティスの効果的な選択・活用のしかたを、具体例を交えながら解説するガイドブックです。