ペアプロとフロー効率

世の中に大量にペアプロ記事があるのに新たに追加してしまうシリーズ。

自分の考えのまとめ置き場が欲しかったんだ(´;ω;`)

背景

ペアプロのメリットについて、詳しい人からの知識移転ができる。先輩から後輩へのスキル移転ができてチームが成長するといったメリットが挙がることが多いと思います。

これはこれで分かるし必要だと思うんですが、一方で二人で一つの作業をやったら効率は半分になるのでは?といったもやもやがあるときに上記のような長期的なメリット*1を挙げられると頭ではわかるけど腹は膨れないなというか、実践につなげるのが難しいことってないでしょうか?

特にペアプロは一人では完結しないので草の根的に行うのには大きな熱量を必要とします。 「長期的なメリットがあるからやろうぜ」といって人を巻き込んで、それを布教して、長期的なメリットが得られるまでやり続けられるって結構大変じゃないかなと思ってます。

この記事では、長期的なメリットについては脇に置いて、ペアプロをやることで短期的にもこんなメリットがありそうだ!といった近視眼的視野でペアプロについて考えます。 そのためガチ勢からすると重要なところが語られてない!と思うかもしれません。その辺はちゃんとした記事がたくさんあると思うので許して。 あといくつか仮定があるので、うちはこうじゃないとかうちには当てはまらないとかもあると思います。人によって答えは違って良いだろうということでこれも許して。

なお話の前提になるフロー効率については フロー効率性とリソース効率性について で学べます。

行ったり来たりのレビュー HELL

さて、機能開発においてはどのような言語でもそこそこの量のコードを書くことになると思います。 典型的な着手方法としてAさんは機能1を作ってBさんは機能2を作るといった形での作業分担方式がありそうです。

作るところまではいいんですが、レビューがなかなか大変ですよね。 正直、ドメインのコードが300行どーん!みたいなPRがきても一発でマージできることはなかなかないでしょう。

これは得てしてスキルの問題ではなく将来どんな追加が予想されるのか?といった未来に関する想定の違いや、こういう概念もあるんじゃない?といった捉え方の違いだったりします。 ドメインの捉え方、パッケージやクラスをどう切るか、一人だと考え方の癖がどうしても出るしレビュアーと合意に至るためには多少なり議論が必要になることが多いでしょう。

こういった議論が必要なケースで非同期のレビューを続けてレビューコメント数が100近くになったり、レビュアーが別業務で忙しかったりすると3時間に一回レビューコメントを返信し続けて早一週間みたいな状況になり得ます。

さらにレビュー対応によりドメインの構造が大きく変わったので先に開発しておいた5つのPRを順番にリベースしてまわるみたいな地獄に続くこともあるでしょう。

反対に、(なんかここまで書いてもらってるしAPI実装自体はできてるからそこまでモデリングこだわらなくてもよいか・・?自分の考えも一長一短あるからこれの方が良いのかも・・)みたいな気持ちになってLGTM!!!みたいなことも人生に一度くらいは覚えがあるのではないでしょうか。 こんなことになったら、もうレビューは単なる作業チェックです。*2

こうして長い長いレビュー時間が必要になったり妥協したソフトウェアが完成するわけです。 後者については防ぐべき事柄だと思います。前者についてはどうでしょうか?

フロー効率と手戻りの最小化

レビュー待ち時間が長くても、レビュアー・レビュイーは待っている間に何かの仕事を行ってはいるのでリソース効率については問題ないと言えます。 ですが、「一つの機能がマージされるまでが長い」「リベースといった本来不必要な作業が発生する」といった点はまさにフロー効率が悪い場合の特徴と言えます。

フロー効率を改善しようというのはペアプロを始める一つの動機になるでしょう。 具体的なメリットとして、ドメインのコードを書く段階で合意が取れたコードを作成できます。 また書いてしまったし今更言うのもな・・といった遠慮の問題も大きく軽減できます。

書いたコードが即レビューされる小さいフィードバックサイクルを持つ開発プロセスでは、レビューによって後から大量の修正が必要となるような手戻りのコストを削減できます。

また、ペアプロでは非常に細かい単位でこれはどうしてこうするのか説明を求められます。 口頭での説明を通して、二人が本当に対象を深く理解しているのか?を細かく確認し合う中で、惰性で書いたコードとそうでないコードを区別できるようになります。

そこで説明できないコードはおそらく対象となる問題への理解が不足しているでしょう。 そしてそれは、何かを説明しているようで結局聞かないとわからないあいまいなコメントや、何となくここに入れておけば怒られないゴミためパッケージの誕生につながります。

説明と議論を通してコードやモデリングの穴を探すのは非常に有効な手段です。(それこそが単なる作業チェックではないレビューのあるべき姿のはず。) ペアプロではこうした妥協による品質の低下も削減できますし、むしろ通常のレビューよりも濃いレビューを促進できます。*3

ペアプロではたしかに二人でコードを書くことになりますが、レビューのやりとりとリベース地獄によって消費される時間を思えばそこまでスループットは低下しません。むしろ普段集中するために費やしてる時間もコード書けるので向上を感じられることもあるんじゃないかなと思います。 レビューが長くなりそうだなと感じたときにペアプロを始めると成功してる実感を得やすいはずです。(ペアレビューから始めるのもおすすめです)

さらに、細かいフィードバックサイクル(レビュー・説明)によって作業分担方式では検出できなかった潜在的な問題を早期に検出できるような効果も期待できます。 細かい品質の積み重ねが後に大きな違いになるのは想像に難くありませんし、議論によってリファクタを繰り返すスタイルは細かい成功してる実感も感じやすいんじゃないかなと思います。

あと単純に楽しいです。集中できない日もペアでとりあえず始めると意外と集中できます。

ペアプロしたい時

ぶっちゃけ手戻りとか難しいこと考えずに、これレビューコメントが多くなりそう!みたいな予感がしたらペアプロするというのが一番簡単な判断基準です。

ただしペアプロは魔法の薬ではないので、いつ何時もうまく行くわけではありません。 会話のスピードで色々決まってしまうので一人で考えたほうが細部まで詰められるということもあるし、モデリングの自由度が高すぎる状態で0から初めると議論が発散する可能性もあります。便利な仕組みを1から作るときや0からモデルの土台を作るところまでは一人でやったりして、適宜切り替えられると便利です。

まとめ

昨今ではペアプロやってるところも特に珍しくなくなってきてモブプロが推進されているチームも多くなってきているので(要出典)、いまさらペアプロの良さを書くのはやや時代遅れな感じもしますが、一方でどういう効果があるんだっけ?というのは常に捉えておかないと、「いいよねペアプロ教」みたいになって(理由の説明が十分じゃないのに)誰かに押し付けてしまったり、逆に「ペアプロはいつも有効なわけじゃない」となって十分に議論されずに不要とされてしまうことはまだまだあるのではないかなと思います。

楽しくできてれば良いかなと言う気持ちもありますが、トレードオフ関係を明らかにした上で良い方法を選択したいので考えをまとめました。(でも全体的にふわっとしてるし、書いてから読み直しただけでちょっと恥ずかしくなる・・・)

ということで、フロー効率が下がってきたな(PRのマージがなかなか終わらないな、議論ちゃんとできてないな)なんてときにペアプロすると短期的な効果が実感しやすくて、長期的な目的を根気強く目指さなくても気軽にペアプロやりやすいんじゃないかなという話でした。

ref

*1:ここでの長期は割と感覚的なものなので人によって違うはず。自分の中では”いつかメリットを感じられるその時まで”やり続ける必要があるといったイメージ

*2:ここまでで、こんなこと一度もない。と思った人は成熟したチームの一員として一つの目標として働けていると思うのでめっちゃ羨ましい限り。

*3:ここはオンラインのレビューでも元からできてるよ!っていうチームもあるかもしれません。