マージリクエストとペアプロとコードレビューと

GitHub のプルリクエストや GitLab のマージリクエストでのコードレビュー機能の登場で、非同期でのレビューが手軽になりました。これは画期的なことでした。

開発において問題を早期に発見することはとても重要です。リリース後に問題が発見された場合の解消にかかるコストは、コーディング時に発見したときの 10 倍とも 100 倍とも言われています。マージリクエストを利用したコードレビューは問題の発見をなるべく早め、不具合の対処の工数を抑えるのに役に立ちます。

しかし、マージリクエストでのレビューは万能ではありません。次は、マージリクエストでのレビューでよくある課題です。

• プログラム設計のまずさを指摘され、すべて書き直しになった。
• レビュアーとレビューイ間でのコミュニケーションがうまくいかず、レビュー指摘とその改修のサイクルがいつまでたっても完了しない。
• レビューが溜まってしまい、たくさんのマージリクエストを並行で開発しないといけなくなり混乱し、能率が落ちた。

このような課題は真面目にコードレビューをしようとしている開発チームほど陥りやすい傾向があります。開発チームはレビューやその改修を負担に感じるようになります。結果、レビューが形骸化したり、理由をつけてレビュー指摘の修正を拒否するようになります。問題を早期発見し、不具合修正の工数を抑えるというレビュー本来の目的は失われてしまいます。

この問題の解消には、マージリクエストよりも早いタイミングのレビューになるペアプロやモブプロが有効です。

ペアプロ (ペアプログラミング)

名前の通り、ペアプロではプログラミングを二人で共同で行います。もちろん、コーディングをしているのは一人ですが、もう一人は調べものをしたり、助言をしたりします。議論をすることも多いです。コーディング役は適当なタイミングで交代します。

単にお互い交互にレビューしあうのではなく、共同でコードを書いていくイメージです。

太郎「まって、そこ if 文じゃなくてストラテジーパターンの方がよくね?」

花子「私もそう考えたんですけど、仕様書見た感じ将来の仕様変更がなさそうなんですよね」

太郎「うーん、自分は仕様変更ありそうだと思ったんだけど...」

花子「たしかに微妙ですよねぇ。一旦このまま (if 文のまま) にしておいて、コメントに修正の際はストラテジーパターンに変えるように書いておきましょうか?」

太郎「それだ!」

太郎「念のため、ストラテジーパータンに後で変えやすいように、if 文のステートメント部分は別関数に切り出しておいたほうがよさそうね」

花子「それは言われなくても今からやりますって! ユニットテストが面倒ですもん」

太郎「ですよねー」

このやり取りをマージリクエストでやると、書き上がったコードの書き直しをしたくない花子さんと、変更に対する強さを折り込みたい太郎さんの戦いになりがちです。誰だって、たくさん書いたテスト済みのコードの書き直しをさせられるのは嫌なものです。

特に新人や開発チームに新しく入ったメンバーは知識不足でレビュー指摘が多くなります。マージリクエストでの非同期レビューでは、最初からやりなおしが発生したり、コミュニケーションがうまくいかずに時間がかかりやすいです。積極的にペアプロを採用しましょう。

常にペアプロで開発しているチームもありますが、必要だと判断した場合のみペアプロをする方法でも構いません。マージリクエストでのレビューがなかなか収束しない場合はペアプロに移行したほうがいいでしょう。また、ペアプロをしていて、ある程度方向性が見えてきたら、ペアプロを解消し残りの実装とレビューはマージリクエストで行ってもいいかもしれません。

モブプロ (モブプログラミング)

ペアプロは二人でしたが、モブプロは三人以上でプログラミングを行います。コーディングを交代しながらなのはペアプロと同じですが、調べ物や助言をする担当がたくさんいることになります。

ペアプロより人数が多いので、様々なアイデアが出やすいことやそこで得られた知識を参加者が共有できるのが強みです。不確定な要素が多く試行錯誤が重要になる場面ではペアプロよりも効果的です。

• 初めて使うライブラリや言語などを即座に使いこなせる人はいません。いろいろな実装のパターンを比較したり、意見を出し合ったり、様々なウェブサイトを参考にしたりしながら、よりベターな実装方法を検討し共有できます。
• 一人でコードを書いてて、「これ仕様をちょっと変えればすげー楽なんだけどな」と思ったことはありませんか? ペアプロだと二人のぐちで終わってしまうことが多いですが、モブプロでは議論の上に採用されることがあります。

モブプロで生まれた知見は開発チームの重要な財産になります。モブプロに参加しなかったメンバーも、参加したメンバーとのペアプロの中でそれを知ることができます。

ペアプロは常時やっている開発チームもありますが、モブプロは要所要所で活用します。プロジェクトの初期の頃はもちろん有用ですが、プログラムに脆弱性や大きな問題が発生した場合もモブプロが役に立ちます。効果がありそうと思ったら積極的に活用しましょう。

その他の方法

ペアプロ・モブプロのほかにもコードレビューに役立つ方法があります。

検査ツールの導入

JavaScript / TypeScript だと ESLint、Java だと SpotBugs のように、プログラム言語にはよく使われる静的解析ツールがあります。これらを統合開発環境に組み込むことで、ペアプロのようなリアルタイムのレビューが可能となります。

最近では AI によるレビューを利用している開発チームも増えています。静的解析ツールのように決められたチェックを確実にするのには向いていませんが、静的解析では見つけづらい問題が見つかることがあります。

静的解析ツールも AI も完全ではありませんので、人によるレビューは必要です。しかし、レビュー依頼前に相当量の問題が解消しているため、レビュアー・レビューイ双方の負担が大きく軽減できます。

コンピューターができるレビューはコンピューターに任せちゃいましょう。

早めのレビュー依頼

完成してからレビューを依頼して「なんか違う」と言われ、やり直しになった経験がある方も多いでしょう。それを防ぐために、少し書いてみたものをちょっと見てもらって、このまま続けていいかどうか聞く人は多いと思います。

マージリクエストでも同じことができます。

• 実装無しで動く画面だけを作って、マージリクエストにスクリーンショットを貼り付けて、デザイナーさんにこのまますすめていいかレビューを依頼する。
• プログラム設計をマージリクエストに貼り付けてレビューしてもらい、OK が出てからコーディングを始める。
• 主要となる部分を大雑把に少しだけ実装してからマージリクエストでレビューをもらう。

漫画家が担当編集にネームを提出するのと似ています。

リアルタイムコード共有

Visual Studio Live Share や JetBrains Code With Me のように、リモートでのペアプロ・モブプロを支援する仕組みがあります。 

これらの仕組みは、今まででは難しかった複数人での同時プログラムを可能とします。これをうまく活用している開発チームもあります。

• 「そこ間違ってるよ!」ではなく「そこ間違ってるからこっちで直すね」ができます。間違いの指摘は「違うそうじゃない!」となり時間を浪費することがあります。
• 複数のパターンで書いてみて比較するのがやりやすくなります。
• フロントエンドとバックエンドをそれぞれが同時に実装するのが可能になります。今までより、とりあえず動くところまでもっていくのが早くなります。

最後に

現代では世の中の変化に追従するためや、細かくリリースして反応を見ながら作るために、変化に対応する強さを以前より求められるようになりました。有名な @t_wada さんのスライド「質とスピード」でも、スピードのためには品質が必要だと解説されています。この変更に対する強さの品質の向上にはコードレビューや設計レビューも重要な役割を担っています。

また、レビュ ーはレビュアーの能力を超えることはできません。変化に対応できるプログラム設計ができない人がいくらレビューをしても、変化に対応できるプログラムにはなりません。今までのやり方がこうだったからとレビューするのではなく、変化に対応できるプログラム設計とはどういうものかを学ぶ必要があります。

マージリクエストやペアプロ・モブプロ、コード検査や AI などレビューの方法は様々です。どれか一つや今までのやり方に固執するのではなく、状況に合わせてレビュー方法を変えることが大事です。さらにそれらをうまく組み合わせながら、様々な工夫をして、問題の早期発見につなげ、開発の効率化につなげるようにしてください。

---

この記事の漫画とイラストは なつよ さん (@infragirl755) が描いてくれました。