ここ最近は開発が佳境で、同僚とかなりの頻度でペアプロ（ペアプログラミング）（ここではペアオペも含む）している。主にTypeScriptを使ったNext.jsのコードを書いているが、もちろん設計もするし、もうちょっと大きいアーキテクチャみたいな相談もする。DBスキーマをどう割るか・・・みたいな話もしている。たいていみんな出社していないので、リモートでこれをやっている（国内だし全員日本語話者なので時差とかはない）。
いちおうどの面子もペアプロの心得はあったのだが、当初は微妙にギクシャクしたり、疲れきったりしていた。そんな中、同僚がRGST2025に行ったりする中でうまくいくようになってきたので共有する。
以前はペアプロやる？と聞かれるとウゲ〜面倒だな、とっとと終わらないかな、と思っていたのだが、今は完全にお気に入りの道具箱に入っていて、飛び出す機会を伺っている。
また、他にもオススメの知見があったら引用して記事を書いたり、ブックマークしてコメントしてほしい。
ペアプロ知見
用語
- ドライバー
- 実際にキーボードを叩いてコードを書いている人のこと
- 今なにやってるかを表現しながらペアプロセッションを進める
- ナビゲーター
- ドライバーの様子や周辺のコードの様子を見ながら助言を行う人のこと
やると良いこと
ここは自分がやることを心がけているコーナーだ。
気さくにやる
上下関係のもとで行なわれるペアプロは重苦しくイヤなものになる。あくまでフラットに、われわれはコードを通じて対等である、一緒に頑張ろうね、という感触を両者が心得ておく必要がある。
ビジネスライクになりすぎるとこれはこれでコミュニケーションが阻害されるので、気さくという表現にした。
ボツにしたスライドを供養しておきます pic.twitter.com/AyLaj0cPwW
— Takuto Wada (@t_wada) 2024年12月19日
↑これすき
時間を絞る
われわれは45分作業をして、10分の休憩を入れて交代、を繰り返している。長くても3時間とかが限度だ。それ以上は互いの慣れや信頼、問題の難しさにもよるが、ヘロヘロになる。 適当に飲み食いしながらやるのも良いかもしれない。
全画面共有する
ウィンドウ共有は使わない。リモート環境で行なわれるペアプロは、スクリーンと音声だけが情報源だ。ただでさえ情報量が絶対的に不足している。なんでも見せられるようにするべきだし、ウィンドウ共有切り替えの手間で集中が抜けてしまうので全画面共有を行っている。
当たり前だが、見られたら困るものは最初にどっかに隠そう！（時として、見なかったことにする熟達した大人の優しさが求められるかもしれないが・・・）
目的を最初に設定する
やると良いと聞いた、みたいな理由でなんとなくペアプロを開始するとかならず疲弊する。行き先が分かっていない状態で二人で運転しているようなもんだ。
ペアプロをする目的はいくつか考えられるが、主なものは「情報伝達」「目を増やす」だ。
情報伝達を目的としたペアプロは、難しい機能を作っていて、今後これをみんなが触るだろうからみんなに勘所を分かってもらいたい、といったシチュエーションで行なわれる。知識の展開である。
目を増やすことを目的としたペアプロは、注意が必要な箇所のコーディングや作業をしたいので（例えば本番DBのALTER TABLEをするとか・・・）、警戒するといったシチュエーションで行なわれる。これはどちらかといえば知識の集中である。
ペアプロを予定する前に、どういうつもりでやるのかを軽く会話して、必ず同じ方向を向くようにしよう。暗黙に仮定していた前提が食い違っているときほど不幸なコミュニケーションが発生してしまう。どうして何も言わないんだよ！とか、ゴチャゴチャうるせえよ！みたいになってしまう。
ちなみに、速度を上げるために行うペアプロは存在しない！ ペアプロは言うなればラリー競技みたいなもので、ドライバーとナビゲーターがそれぞれの力を合わせることで迷いやミスを減らし、結果として目的地には早く着く、といった類のコミュニケーションであり、ペアプロをやったからといって時速200kmで疾走できるようにはならない。目玉が増えるだけだ。
雑談する
大抵の場合、ペアプロがしたいのは、難所を越えようとしているときだからだ。みんなが後から通りやすくなるように、またはみんなの知恵が欲しいから目玉を増やすのだ。
しかし、難所と向き合うには多大な集中力が必要だ。しばらくやっていると、気付かぬうちに切れてしまう。集中力を切らすとパフォーマンスも下がるし、ミスを誘発する。
我々の場合、ドライバーとナビゲータはけっこうしょっちゅう雑談している。こないだのアレ見た？めっちゃ話題になってたよね〜、とか、最近変なガジェット買ったんだ、とか、こないだカンファレンス行ってたじゃん、どうだった？みたいなのを喋りながらやる。そうすると脳は機嫌が良くなってまた集中力が戻ってくる。本格的な休憩を挟む前に、マイクロ休憩が入っているような感じだ。
もちろん雑談ばかりになってしまってはいけないのだが、雑談自体も飽きるものでそのうち作業に戻ってくる。
ドライバーはゲーム実況者になる
ナビゲータが読心術に長けているとか、魔法使いの家系だとか、思考を盗聴できるとか、そういうのでない限り、ナビゲータがドライバーが何を考えているかを知るためには、ドライバーが喋る必要がある。あまつさえ、リモートであれば表情を伺い知るのも難しくなる。
よく喋ろう。 同僚の 
id:ymse 曰く、「ゲーム実況者になれ」というのだから面白い。まさにそうだ。ゲーム実況者はずっと喋って、何が良いのか、何に困っているのか、をリスナーに伝達し続ける。ときおり自分が持っている知識を提示して、リスナーと知識の同期を図る。ペアプロの場合リスナーは1人しかいないから、安心して間違えよう。安心して「迷った！」と言おう。
気持ちとしては、いつもの倍喋るつもりでいてほしい。それで丁度良いくらいだ。もし本当にうるさかったらナビゲータがそう言うはずだ。
相槌を互いに声でうつ
これは前項とも近しい話だが、会話のキャッチボールが成り立たないときまずい沈黙が訪れることになる。ドライバーの実況をちゃんと聞いていますよ、寂しくさせませんよ、という暗黙のメッセージを、「うんうん」という相槌で必ず発信し続けよう。そしてドライバーも、ナビゲータに対して同じメッセージを送ってあげよう。
ちなみに頭だけうなずくのはNGだ。ドライバーはエディタやシェルを見てるし、ナビゲータは画面共有やGitHubの画面を見ているはずだからだ。
まずPRに起こす
ペアプロを始めるときはまず小さな小さなコミットを打って、そこを起点にプルリクエストを作って進めよう。こうすることでナビゲータが「今どこまで実装できているか」をドライバーに頼まずとも確認できるようになる。
かなり小まめにpushする
前項ともかかわることだが、1つのステップが終わったらすぐコミットしてしまおう。100行でコミットするのは多すぎだ。自分の場合、関数を生やしました、とか、コンポーネントを書いた、とか、そういうレベルでcommitとpushをしている。これはナビゲータのためだし、レビュワーにも優しい。後からcherry pickもしやすい。
文字はデカくする
画面共有でやりがちなのだが、ブラウザやエディタ、シェルの文字サイズが動画コーデックの圧縮で潰れて全然読めない、ということがある。普段の2倍くらいにデカくしよう。大抵のソフトでCtrl + +を押したり、Ctrlキーと一緒にスクロールしたらズームがかかる。
しっかり声を出す（リモートの場合）
デカすぎる声はこっちでボリュームを絞ればいいが、小さすぎる声はどうしようもない。音声コーデックの限界やノイズキャンセリングによって、聞こえなくなってしまうのだ。ちゃんと声を出そう。これに関してはいつもの2倍は出す必要がなくて、1.3倍くらいの気持ちではっきり喋ろう。
やらないこと
やるべきことがあれば、やらないほうがいいこともある。もちろん場合によりけりだが、自分たちはあまりやっていないことを紹介する。
一緒にやって情報格差をなくす、という目的であればLiveShareを使ってはならない
花火といえば玉屋、ペアプロといえばLiveShareみたいな風潮だが、自分たちは今のところそんなに使っていない。
いっとき使っていたのだが、やめた。なまじLiveShareは操作ができてしまうので、ナビゲータが指示厨っぽくなり、ドライバーはスポイルされてやる気をなくしてしまい、もうお前がやれ！みたいになってしまって疲弊することがわかったからだ。なんなら、うっかりするとどんどんナビゲータが実装を書いてしまい勝手に進めてしまったりする。
ナビゲータがいつでもコードを止められるという状況は、ドライバーからすれば、教習所の教官がいきなりブレーキをかけてくるようなものであり、かなりキツい勾配をペアプロに巻き込んでしまう。
Read Onlyなモードもあるようだが、やはりナビゲータが逸る気持ちを押さえられなくなってしまう。あくまでドライバーに走ってほしいので、全画面共有くらいが丁度良いと思うようになった。
おわり
ペアプロは奥深い。世間はペアプロをどういう感じでやっているのか気になる。
