コードレビューではなくモブプログラミングをください

初めに

この記事はSvaťa Šimara氏の「Don’t do Code Review, try Mob instead」の翻訳です。筆者はかなり濃密なモブプログラミングをされており、事例として大変興味深いです。

モブプログラミングは開発手法の一つです。用量用法を守って正しくお使いください。

コードレビューの欠点

• 長いフィードバックループ
• 待ち時間
• 様々な未完了タスク
• 文字によるコミュニケーションは時間がかかる、マジで

私のプログラミングの一日はたいていこうだ。「コード書く -> レビューに送る」 今は？ ああ…またタスクだ。まあこれは簡単だから次のやつ行こう。そんな時に限って急なレビューが入って、しばらく待って、自分でレビューして…ようやっと2番目のタスクのレビューだよ！　いや、それには反対だよ、ちゃんと返答しなきゃ…小一時間かけて論点をまとめたけど、次の日に同僚からもらった返事はOKの一言だった。え、そんだけ？！

コードレビューの最も顕著な問題は、それが難しい質問・回答の非同期のキャッチボールというところだ。非効率的なうえに、関わっている人がイライラしてくる。

別のやり方として、コードレビューをなる早で行うことが挙げられる。自分がこのアプローチをとるとき、1週間まるまるコードレビューに費やすことになる。これは大げさな話ではない。コードレビューを増やすほど、受ける質問の量も増える。これもまたイライラする。

コードレビューの狙い

コードレビューの長所って何だろう？

• 知識の共有
• 責任の共有
• コードストラクチャの改善
• 学習

良いコードレビューはこう言った部分をカバーしている。でもコードレビューは手段なのだから、より良い方法があれば、コードレビューをする必要は無い。

モブプログラミング

モブプログラミングとはチームが一丸となって同じ時間に同じスクリーンに集まるということだ。もしくは、自分の場合だが、リモートで画面をシェアすることもある。
自分の場合4人組で働いていて、1日5~6時間ほどモブをやる。まずタスクを決めて、着手可能になった段階でセッションを回していく。

セッションでは一人のドライバーがタイプやクリックをし、もう一人ナビゲーターがドライバーに何をするか指示を出す。残り二人はそれを注意深く聞き、ナビゲーターが間違った方向に進んでしまった時だけ介入する。ナビゲーターは3分間で…たった3分だけで、ローテーションを回す。

ローテーションしたら今度はドライバーがナビゲーターになる。次の手順が分かるからだ。先ほどのナビゲーターは休み、その他(mob)のどちらかがドライバーになる。そしてまた3分後に役割交代をしていって…

この通り、ローテーションは激務だ。常に注意力が要求され、うっかりすると自分がナビゲートする番に、何をすればいいか分からなくなってしまう。

仕事の質を保つため我々はよくコーヒー／トイレ休憩を入れるし、もちろん昼食はゆっくり休む。

コードレビューの目的は達成される

知識の共有は即達成できる。メンバー全員で精神的なプロセスを取り、何故、何が行われたのか分かる。
責任の共有は、個人的な意見ではあるが満たされる。自分は、我々がなしたこと全てに責任を持ち、いつだって「反対」とか「もっと良いやり方がある」と言える。
コードの構造は全員納得できるので、チーム全員ができる最良のコードが一貫性を持ってできる。
学習も…これまたあっさりと(instant)、しかし濃密に(intense)できる。ナビゲーターが良ければ、何をすればいいか言うだけでなく、どうすれば効率よく出来るかも伝わる。自分の場合、毎日ベターなソフトウェアアーキテクチャーや、テスト方法、IDEの効率的な使い方などが学べる…これもナビゲーターが自分の知らないことを知っている(なおかつ教えてくれる)からだ。
全体的に、モブプログラミングはコードレビューの上位互換だ。しかもキャッチボールのイライラが無いと来ている。

モブプロって効率悪い…

そんなふうに考えていた時期が俺にもありました…始めてから数週間の間は。

それはチームを立ち上げるときやメンバーの言語やツールに関する経験が浅いときに当てはまる。この時期はモブプロはほぼ学習になる。

でも最初の数週間を耐えればすべてが変わってくる。

ほぼ毎日、自分ひとりだったら解決に1時間(下手したら数時間)かかる問題に出くわす。しかし我々は4人いるので、たいていの場合簡単なやり方を知っている人がいるものだ。同僚も同じ経験をしたと言っていた。自分では何をすれば分からなかったが、すぐに分かる人が誰かしらいるのだ。

メンバーはそれぞれ違う分野の専門家でもある。DBに強い人がいれば、使っているフレームワークを熟知している人や、例えば決断力に優れている人がいる。ナビゲーターが詰まった時は、この「専門家」が障害物を取り除いてくれる。それもすぐにだ。

モブるのに必要なこと

モブプログラミングは万人向けではない。

まず、(リモートでも何でもいいから)時間を共有できなければ機能しない。

モブるにはにはコミュニケーションスキルが必須だ。受動的攻撃心、ないし横柄さはお呼びでない。同僚よりもあなたが優れていることを誇示したいのであれば、モブには不適格だ。¹

モブるには忍耐と経緯が必要だ。なぜなら誰もがいつでもコンディション万全という訳ではないからだ。問題解決を急いでいて、なおかつ同僚を先導/指導する気が無いのであれば、モブプロは成り立たない。同僚が向上せず、チームが育たないからだ。

必要なことは以上だ。(リモートであっても)同じ時を過ごし、我慢強く、新しい方法に興味を持って、同僚も似たような視野に立っていれば、モブプロはいいぞ！

モブプロ対コードレビュー

モブプロとコードレビューは月とスッポンだ。

コードレビュー形式では、問題解決に数時間は取られたのち、解決策をコードレビューに送り、さらに待って、レビュアーの変更点の指示が来て、自分のコード変更点について申し開きをすることが多い。2～5日後に自分のコードをマージする準備が整ったと思ったら、競合を解決しなきゃならないと来た！

モブプログラミングにそんなのはない。

• 試行錯誤はメンバーの経験で抑えられる
• 待ち時間無し
• 即座の議論・コード変更
• マージ競合削減

モブプロにはさらに利点がある。自分にとって特に大事なのは同僚との仲が良くなることだ。プログラマーも社会的動物だし、その点モブプロは本当に助けになる。

まとめるとモブプログラミングはフィードバックループを大幅短縮できて、素晴らしい成果が挙げられる。

1. 原文のトップハイライト。 ↩