Webアプリエンジニアの大橋です。

オープンワークでは、プロジェクトによってペアプログラミングを実施しています。
私が所属するプロジェクトでも今年の3月頃からペアプログラミングを実施しました。

自分のペースでコツコツと作業できるのがエンジニアの醍醐味で、正直な話、昨年までの私はペアプロなんてやりたくないと思っていました。
そんな私がペアプロをやることになった背景や、実際にやってみての振り返りを記事にしたいと思います。

ペアプログラミングとは

ペアプログラミングはソフトウェア開発の手法の一つで、2人のプログラマが１台のマシンを操作してプログラミングを行う手法です。
実際にキーボードを操作してコードを書く人を「ドライバ」、もう1人を「ナビゲータ」と呼びます。

レビューの工数問題を解決したい

ペアプログラミングを採用した一番の理由はこれだと思います。

オープンワークではGitHub上で1人以上のエンジニアが必ずソースコードレビューをしています。
私の所属するプロジェクトではエンジニア5-6名のうち、コードレビューは中堅以上の社員3名が分担しており、他は新入社員や非正社員のメンバーです。
レビュアーが開発を担当するとレビューの時間が取れず、他のメンバーのタスクがレビュー待ちでボトルネックになってしまいます。

そこで主な実装は新入社員＆非正社員メンバーに担当してもらい、レビュアーの3名はコードレビューをメインにすると、レビュー→レビュー指摘の対応→再レビュー→再レビュー指摘の対応、、というやり取りで時間が経過して、完成するまでに時間がかかってしまいます。
また、実装担当者が1人で悩んでなかなかレビューリクエストが来ない、ということもありました。
中堅以上の社員のリソースがレビュー専門になってしまうのは勿体なく思いますし、レビュアーも本当はレビューより実装がしたいのです。

そこで、これらを解決できそうな方法がペアプログラミングでした。

リモートでのペアプロ方法

現在はほぼリモート勤務ですが、ペアプログラミングでは特別なソフトは使っていません。

ドライバがZoom等で画面共有し、交代のタイミングでコミット＆プッシュする
交替したドライバがプルして画面共有しながら作業をする

という方法をとっています。

気軽に試しやすい方法ですが、この方法だとキリの良いところでしか交代できないので、今後はコード共同編集ツールも試してみたいです。

ペアプロをやって良かったこと

ペアプログラミングをやってみて良かったことを、チームのメンバーにも聞いてみました！
やはりレビューにかかる工数は減らせたようです。

ディレクトリ構成やクラス名、関数名などを相談しながら実装できた（これの戻りが多いと時間がかかる）
ペアプロしながら相互レビューしているので、レビューコストを削減できた
ケアレスミスに早く気付く
難しい機能はレビュアー同士でモブプロしたのでその場で相互レビューできた。
その場でフィードバックをもらえたのが良かった
細かい仕様や気づかなかった部分を認識出来る
知らなかった機能等に気づくことがある
悩みポイントを共有でき、その場で解決できる

ペアプロの課題

一方、ペアプロも良いことばかりではなく、課題もありました。
主な課題は時間の使い方とペアの組み方です。

時間の使い方

コミュニケーションコストがかからない分、作業自体は1人で進めるほうが早い
続けて実装を進めたくなるが、時間は短く区切ったり、休憩を取るようにしたほうが良い
ナビゲータの場合、画面を追うのが疲れるので、ドライバはこまめにコミット＆交代したほうが良い。
すべてのタスクをペアにすると、ペアの相手が忙しいときや休みのときにもう1人が作業を進められない。
ペアプロ中は他の作業が滞ってしまったり、他のメンバーのフォローやレビューができない
他の作業やレビューの時間も確保したい
調べたり考える時間がほしい

ペアの組み方

教えるという目的では、一方通行でも良いが、ペアプロによる相乗効果の為には、できるだけ対等な立場でお互いにレビューできるペアが良いと思う。
レビュアーが二人以上いないと効率的じゃない気がする（ペア内でレビューまで完結するのが理想）
（ペアの組み合わせによって）自分で調べたり考える力が落ちる気がする

ペアプロで工夫したこと

これらの課題を解決する為に、以下のようなことを工夫し、改善しつつあります。

ペアプロに着手する前に、TODO（やること）を整理してBacklogでチェックボックスリストにする。ペアプロ時はこのリストを元に進めるので、ドライバ交替の目安にもなる。
ペアプロに着手する前や合間に各自で調べたり予習する時間を設ける
すべてをペアプロにするのではなく、ペアでやるべき箇所を絞る。例えばペアプロ時間で大枠を実装し、やることや方針が明確な箇所は手分けして進める。
各自で進める場合もoVice（仮想オフィス）に常駐し、話しかけやすいようにする
ペアの組み方は固定にせず、可能な限りローテーションして組む

ペアプロでテスト駆動開発

ペアプロで改善したことをもう一つ上げます。

ペアプロを始める以前は、タスクの大きさや担当者のスキルによって、テストコードが後回しになってしまっていました。
理由は主に二つあり、一つはレビューの戻りが大きいと、テストコードも作り直しになってしまう為です。
二つ目は、手動テストに早く着手する為やスプリントレビューに間に合わせる為に「見える部分」を優先してしまっていたからです。

ペアプロを開始してからは、ペアの1人にレビュアーが入るので、どのメンバーにもテストコードを書く習慣をつけてもらうことができるようになりましたし、レビューの直しに時間がかかることもなくなりました。

さらに最近ではテスト駆動開発に近づけるように、最初にテストコードを書くことを意識するようにしています。
テスト駆動開発とは最初に失敗するテストコードを書き(RED)、そのテストコードが動作する実装を行なった後(GREEN)、コードを洗練させる(REFACTORING)、という工程を短く繰り返すスタイルです。

ペアプロでは、最初のドライバがテストコードを書き、交替したドライバが実装するという方法をとっているのですが、テストコードを書く時点でTODOやテスト観点をすり合わせることができるのもメリットです。