本レポートの前編はこちらから。
中学からプログラミングを始め、東京大学文学部卒業後、（株）ジャストシステム、ベンチャー企業、フリーランスを経て、2007年に万葉を設立。現役のRubyプログラマとして受託開発を続けている。Rubyアソシエーション評議員。著書『現場で使えるRuby on Rails 5速習実践ガイド』『たのしい開発 スタートアップRuby』など。
コードレビューには中央集権的なやり方と民主的なやり方がある
新人研修を標準カリキュラムに沿って進めるようになって分かったことがあります。プルリクエスト＆レビューの効果がすごいことです。プルリクエストとはコード変更提案のことで、GitHubという共同開発を支援するサービスで使える機能です。
先ほど（前編で）お話ししたとおり、タスク管理WebアプリケーションをRuby on Railsを使って開発するのが弊社の標準カリキュラムです。研修中に作成したソースコードは、実案件と同様にGitHubに上げてもらうのですが、誰も見ないまま淡々と開発を進めてもらうわけではありません。作成したソースコードはプルリクエストという形でまずGitHubに送ってもらい、メンターや手の空いている社員など2名以上のレビューを受けます。具体的には、GitHubにプルリクエストとして上がってきたコードを、レビュアーがブラウザ上で1行1行確認し、コメントを入れたり議論したりします。
なお、目で見てレビューする以外に、CI（継続的インテグレーション）ツールを使い、コードを自動的にテストする仕組みも整備してあります。テストも通過し、レビューにてこのコードで良いとなったら、めでたくプルリクエストをマージすることができ、変更がマスターブランチに取り込まれます。
ところで、コードレビューと一口に言ってもいろいろあります。ですので、話が少し脱線しますが、ここで説明しておきたいと思います。
よくある中央集権的なコードレビューのイメージは、コードベース（既存のソースコード）に追加・変更するコードをマージする権限を持つ人が、コードの品質を担保するために中心になってレビューを行い、合格ならマージするみたいな感じです。こういうレビューもあると思います。
一方、民主的なコードレビューというのもあります。この場合はコードレビューを、個人が書いたコードをチームで共有するためのステップであると考えます。つまり、誰かが品質を確認し合格したコードを取り込むステップではなく、個人が書いたコードを皆でコンファーム（確認する）ステップと捉えるのです。
コードレビューっていうと文句をつける、指摘をするといったイメージがあるかもしれないんですが、（民主的なコードレビューでは）良いと思った点を褒めることもあるなど、コミュニケーションするといった感じになります。コメントは必ずしも指示じゃない。だから、「このほうがいいと思います」と言われても「こだわりがあるのでこれでいきたいです」みたいに言い返すことができて、それが通れば別にそれでもいいといった感じです。
そうやって（コミュニケーションを重ねつつ）コードを改善して、合意が取れた段階でコードベースにマージする。先ほど述べた弊社が新人研修で行うコードレビューは、後者の民主的なスタイルのコードレビューのことを指しています。これがすごい効果をもたらすんです。
