コードレビューvsモブプログラミング
コードレビューが与える弊害に疲弊しました。もうやめたい。
っていうかコードレビューがうまく回るとか、人間業じゃなくない？
そんな想いを抱き、たどり着いたのはモブプログラミングでした。
始めてモブプログラミングを経験したのは、3年ほど前でしょうか。
正直自分が想定していたよりもはるかに効果が出て、衝撃を受けました。
コードレビューはコストが高い
誰かが実装をやりきって、それを他人にコードレビューを依頼する。
そして依頼された人は、自身も他の実装をしている。当然、切りが良いところまでいかないとレビューには入りたくない。スイッチングコストが発生することを考えると、至極当然のことだろう。
他人のコードのレビューをするためには、実装内容に関する仕様を理解して、実装およびこの実装方法を選択した背景を理解する必要がある。自動テストのケースは十分なのか、誤ったテストになっていないかも確認しないといけない。妥協せずにレビューするということは、一度実装をやり切るのに近いコストがかかると思ってよいだろう。
そして、GitHub上でレビューコメントを介してのやり取りだと、うまく伝わらなかったりすることもある。対面でできるならこの問題は軽減されるが、ミーティングや勤務時間の違いから対面で実施できないこともある。
レビューの指摘によっては、少なからず手戻りが発生し、場合によってはほとんど作り直すようなこともある。そして修正したコードがすぐにApproveされるとも限らない。望ましい修正ではないかもしれないからだ。こうしてレビューがなん往復もラリーすることも、決して珍しくはない。
コードレビューは「自分のタスク」じゃないという錯覚
前述の通りでコードレビューは非常にコストがかかる。そのため、「自分のタスク」じゃないからとレビューを後回しにして「自分のタスク」の実装を進めてしまうことは少なくない。本当は「自分のタスク」なんて存在しなくて、すべては「チームのタスク」だと考えるべきだが、個人にタスクをアサインした瞬間にこの錯覚が発生する可能性がある。
レビューをしてもらえるのを待っている間はどうすればいい？ネット記事をザッピングする？本を読む？コーヒーを飲みながら談笑する？
熱心なエンジニアは間違いなく次のタスクに着手するだろう。少しでも多く「自分のタスク」をこなして、チームに貢献しているという実感も得られる。レビュー依頼がきているのであれば、他人のコードをレビューするかもしれない。
もし、なかなかコードレビューを受けられず、他のタスクに着手しつつも、すべてのタスクが完了まで持っていけなかったら、どうなるだろうか？
チームリーダーから「どうしてタスクが終わりきってないのに次のタスクに着手するんだ？」という叱責をうけるケースも少なくないのではないか。与えられた環境下で最大限の努力をしているだけなのに、一体どうしろというのか。
妥協したコードレビューという罠
さて、何度も言うがレビューには非常にコストがかかるわけで、なおかつ「自分のタスク」ではないとすると、レビューに妥協が発生してしまうことはないだろうか？
チームやプロダクトに対する強い熱意を持ったプロのエンジニアたちが、コードレビューに妥協することなどありえないから、そこは大丈夫だろう。
本当に？そんなものはフィクションで、人間なのだからそんなことはない。実際には少なからず妥協が発生する。さらに妥協ではなくても、指摘することに対する遠慮もありえる。そして 不十分なコードレビューでApproveされたコードがマージされると、どうなるか？ 想像するだけで横になりたくなる。
ところで、あなたのチームには何人のエンジニアがいる？3人か、5人か、それとも10人？
その人数でエンジニアたちがそれぞれに実装して、コードレビューを依頼し合いながら機能を実装する様を俯瞰で想像して欲しい。まるでサッカーコートにボールが5個も10個もあるような、異様な光景ではないだろうか。
モブプログラミングというコードレビューの代替案
この状況を打開するためには、どうするのがよいだろう。最初からレビュアーになるべき人たちが一緒に実装すればよい。 つまりモブプログラミングを採用するとよい。
モブプログラミングを取り入れているチームは増加傾向にあり、ほとんどすべての機能をモブプログラミングで実装しているチームも少なくない。一度モブプログラミングの効果を体験すると、戻りたくなくなる。チームの生産性は上がり、スイッチングコストが脳に無駄な負担をかけない。「自分のタスク」は無くなり、すべてが「チームのタスク」へと変わる。
モブプログラミングは他にも効果がある。コミュニケーションの増加、ナレッジの共有など。なくてはならないキーパーソンの不在に頭を悩ませる機会も減るだろう。
ただし、コードレビューもいらないような、誰がやっても自明な単純な作業までもモブプログラミングで実施するのは避けた方がいい。
モブプログラミングを円滑に進めるためのプラクティスはネット上の記事でも多く出回っている。参考にしながら、チームにとって良い形を模索するのがよいだろう。
参考記事：
Discussion