松田流コードレビュー「私達は全員でコードレビューします」

Pocket

松田流コードレビューとは、毎朝チーム全員でコードレビューを行うことを指します。毎朝1時間、チーム全員でプロジェクタの前に集まり、昨日コミットされた内容を一つずつ確認していきます。全員がレビュアとなり、気になる点があれば誰でも指摘し、異論がなければ、指摘内容に沿ってその場で実際に修正していきます。この取り組みを毎日重ねた結果、私達は各Storyの具体的なコードを、メンバ全員で共有することができました。これこそ真のナレッジだと考えます。たった1時間、毎朝このような活動を行っただけですが、その効果は大きいと実感しています。

チームの生産性と品質が向上する

松田流コードレビューの目的は、チームの生産性と品質を向上させることです。具体的には、主に次の3つの目的があります。

思想を共有する

1つ目は、思想を共有することです。以前は、対面ではなく指摘表などのドキュメント形式でコードレビューを行っていましたが、これでは思想の共有はできませんでした。なぜなら、指摘表だけでは結論や指示しか伝えられず、表面的な理解に留まってしまうためです。過去に、できる限り背景や理由、考えなどを詳細に指摘表に書いたこともありましたが、文面でわかりやすく伝えることは困難でした。

松田流コードレビューでは、コードをプロジェクタで投影し、同じコードを全員で読みながら、気になったことをその場で指摘します。ドキュメントを通して行う指摘とは異なり、指摘に対する相手の反応を直接見る事ができます。ただ頷いているだけのように見えたら、そう指摘した理由や背景、重視している考えなど、より詳しい説明を付け加えて相手の反応を確かめることもできますし、反論を求めることもできます。そうして互いに意見を交わし、実際にその場でコードを変更しながら考えを具体的にすり合わせていくことが、思想の共有につながっていきます。思想の共有ができれば、コードを組むうえでのベースとなる考え(Common Knowledge)が形成され、意思決定のスピードも質も高まっていくことになります。

なお、思想の方向性は、揺れ動いても良いと思っています。むしろ、柔軟であるべきです。新たな考え方や技術が入ってくれば、それに応じて議論し、その結果、結論が変わっても構いません。重要なのは、議論するための土台が共有されていることです。

手戻りを最小にする

2つ目は、手戻りを最小にすることです。通常の現場では、開発者が実装を完了させた後にコードレビューを行いますが、このタイミングでは遅すぎるというのが私の考えです。なぜなら、抜本的に見直したいコードに直面しても、実装者はこの時点ですでに多くの時間を費やしてしまっているためです。リファクタしたくてももう時間が足りません。このような理由で、大きな指摘はせず表面的な指摘に留めたり、無視する、といったようなことが私の以前の現場でも実際に繰り返されてきました。

そこで思いついたのが、コードレビューを毎日行うというやり方です。昨日書かれたコードであれば、たとえすべてをひっくり返すような指摘をしても、手戻りは最大で1日ですみます。なぜこのような実装をしたのか読み取れない場合も、昨日書いたコードに関してであれば実装者から聞き出すことができるため、安心して修正方針を決めることができます。また、開発フェーズの早い段階で指摘できるため、自ずと指摘が減っていきます。コードの品質を高めながら開発を進めることができ、生産性・柔軟性・拡張性・統一性・ノウハウの共有など、多くの面でメリットがあります。

コードを共同所有する

3つ目は、コードを共同所有することです。属人性の排除、と言った方がわかりやすいかもしれません。属人性の排除は、どの現場でも必ず課題として挙げられてきました。単独で作業を行う以上、これは避けられない問題ですが、軽減させることはできます。その方法の一つとして、今回ご紹介している全員でのコードレビューは有効です。これを行うことで、全員の知識をかなり細かいレベルで合わせることができます。

以前の現場でも、ドキュメントレビューの結果を、レビュイだけでなくメンバ全員に展開したりしていましたが、これだけではコードの共同所有は実現できませんでした。他の人に対する指摘を丁寧に読む時間を誰も確保できなかったためです。松田流コードレビューなら、毎朝1時間スケジュールに入れているので、強制的に時間を確保することができます。

シンプルさが重要

全員でコードレビューを行うためには、効率的に行う必要があります。そのためには、シンプルさが重要です。シンプルとはつまり、わかりやすい、ということです。そのためのポイントとして、私は次の3つを掲げています。

可読性の高いコードを書く

コードレビューで確認したいことは、実装された内容が最適解かどうかです。コードレビューの観点を、この本質的なポイントに集中させるためには、コードが読みやすいことが大前提となります。コードを理解することに多くの時間が割かれてしまう状況は、将来の保守性を考えても良くないため、早急に対処が必要です。

私は、可読性の高いコードを書くために、次のようなガイドをチームに提供しています。

・名前にこだわる – 変数名、定数名、メソッド名、クラス名、テーブル名、ファイル名、ディレクトリ名など、名前をつけるものはすべて。対象を端的に表現する象徴的な単語を選択、リストなら必ず複数形、助詞や前置詞等を省略しないなど、細部まで配慮し、誤解を生まない表現を徹底する。番号制は論外。

・粒度を統一する – 処理の詳細はメソッド内に隠蔽し、概要となる情報をメソッド名に詰め込む。メソッド内の処理ブロックを、そのContextに合わせた最適な粒度でメソッドとして抽出し、まるで自然文のように読めるソースコードにする。こうすることで、単一責任の法則も意識しやすくなる。また、小さな単位でメソッド化されることで、コードの再利用性も高まる。

小さな単位でコミットする

コードレビューをするためには、実装者の意図を理解する必要があります。意図は、可能な限りコードから読み取れるようにすべきですが、特定の1行に対する意思決定の意図や背景までを、もれなくコードで伝えることはできません。しかし、コードを読む人や将来改変しようとする人にとっては、そうした局所的な情報が必要となることが多々あります。彼らは、サイドエフェクト(※1)を生み出さないよう、実装者の意図を細部に渡り完全に把握しようとするためです。

(※1)サイドエフェクトとは、プログラムを修正したことによって生まれた新たなバグのことです。

したがって私は、小さな単位でコミットすることをチームにお願いしています。具体的には、意思決定の最小の単位でコミットするということです。最終的にできあがるコードは、こうした小さな意思決定の塊であり、その単位で意図をしっかりと残すことは、実装者の責任ともいえるのです。

新しい機能を実装するときは、特に注意を払う必要があります。よく見受けられるのが、最初のコミットが「○○画面実装完了」といったケースです。これでは、実装が一段落した時点のコミットしか残りません。実装者は、このコミットに至るまでに様々な小さな意思決定を積み重ねてきたはずです。私はチームに、新機能を実装する場合のコミット単位の目安として、イベント単位かつレイヤー単位でのコミットを提示しています。類似機能をコピーして新機能の実装を始める場合は、まずはコピーしたままの状態でコミットし(ブランチを分けてからコミットするので他の開発者には影響しない)、それ以降は、意思決定の単位でコミットするようお願いしています。こうして小さなコミットを行うことは、レビューをポイントを絞って行えるだけでなく、貴重な情報を蓄積することにもなるのです。

ルールや指摘には、必ず理由を伝える

通常の開発では、統一感や一貫性を保つためにルールを設けますが、私は、このようなルールに決めた理由を必ず伝えることを重要視しています。理由は以下2点です。1つは、ルールは強制力を持つため、十分に納得してもらわなければ、不満を生み出し、ルールの逸脱を招く恐れがあるためです。良いルールである、と全員が納得しなくてはなりません。2つ目は、ルールは必要に応じて変更すべきだからです。どんなルールも変更できるよう、意図を明確にしておく必要があります。

このことは、指摘する場合も同様です。理由がきちんと伝わらなければ、再発を招く可能性があり、同じ指摘が繰り返され、レビュー効率を下げることになります。

コードがすべて

全員でコードレビューすることは、これまでの働き方では共有できなかった情報が具体的に共有でき、チーム内の会話や雰囲気も変わっていきます。開発現場において、何よりも重要なのはコードです。そのコードの詳細を全員で共有し、改善していくことは、自分たちの生産性や品質を直接的に高め、より本質的な仕事にシフトさせることができると思います。

お問い合わせ先

執筆者プロフィール

Matsuda Yousuke
Matsuda Yousuketdi AI・コグニティブ推進部
新人の時、上司からXP(eXtreme Programming)を教わって以来、アジャイルな文化に魅了されてきました。昨年からようやくScrumで開発できるようになり、刺激的な毎日を送っています。最近は健康のため立って仕事をしています。
Pocket