ペアプログラミングのメリットと注意点

はじめに

電通デジタルでフロントエンドを担当している石原です。

最近、自発的な取り組みとしてペアプログラミングを行いました。この記事ではペアプログラミングのメリットや、これは注意した方が良いなと思った点を紹介します。よろしくお願いします。

ペアプログラミングをやった背景

私が所属するプロダクト開発チームではスクラム開発を採用しており、タスクを各々主体的に担当して日々開発を進めています。プロダクト開発チームの中にはバックエンドに強みを持った人もいれば、私のようにフロントエンドをメインで担当する人もいます。

個人で明確に役割を区切っているわけではないため、例えばフロントエンドをメインとする人でもバックエンドのタスクを担当することはできます。しかしながら、自分があまり詳しくない言語やリポジトリのタスクを進んで担当するのは技術的・心理的な壁になっていました。

そのような状況下で、新しいプロダクトの機能開発が今年 2 月に始まりました。この機能は、要件定義〜本番リリースまで約2ヶ月で完了する見積もりで、具体的な開発内容はバックエンドの API 新規開発（Go言語 + gRPC）とフロントエンド側での処理追加（TypeScript + React）でした。

これはチャンスと思い、よく一緒に競技プログラミングをしている同じチームのバックエンド担当の後輩と、その案件をペアプログラミングで進めようと手を挙げてチームを組みました。（開発部では開発の進め方に制限がなく、主体的に提案すればどのようなことでも可能です）

毎日できる限り、ビデオ通話しながら設計と開発を進めました。1日1〜2時間の時もあれば、1日7時間みっちり行った時もありました。結果としてこの機能は、ほぼ見積もり通り約2ヶ月で本番リリースすることができました。

ペアプログラミングは全てリモートワーク下で行っており、一度も出社していません。二人とも各自宅からです。また普段使っているエディタも異なっていたので、VSCodeのライブシェアといった共同コーディングツールは使わず、ドライバー（コードを書く側）とナビゲーター（実装の方針を指示する側）に分かれて行いました。なお、短時間で実装者とナビゲーターを入れ替えるのではなく、一日単位で入れ替えていました。

ペアプロのメリット

知らない技術について詳しくなれる

これはペアプロをやる動機になったメリットです。私は普段フロントを開発しているので、例えばgRPCを使ったAPI開発の流れやその具体的な作業などは全く知らなかったのですが、実際にペアプログラミングでその流れを全て経験できました。

もちろん全て教えてもらいながらだったのですが、自分でコードを書いてPRを上げてテストする流れを体験できたのは、ペアプロをしなければ難しかったと感じました。

他の人の実装や設計のスタイルを知ることができる

電通デジタルの開発部では全員がコードを書きます。コーディングルールには現れない実装の順番やプロセスというものが各人にあると思いますが、ペアプロではそれを知ることができます。

例えば関数を実装する時に処理内容のコメントを書いてから始める、実装と並行しながら設計ドキュメントや処理のフロー図を更新していく、IDEのリファクタリングツールを最大に活用する（私のエディタにはない機能だった…）など、自分も取り入れてみたいと思えるポイントがありました。

ペアプロをすることで、改めて実装の仕方や進め方を振り返って考えることができます。これはペアプロの大きなメリットと思います。

手の止まる時間がなくなる

やってみて気が付きましたが、ペアプロ中は集中力がかなり続きました。1〜2時間で集中力が切れて終わることは一度もなく、部内のミーティングなどがない限り、ご飯を食べる時間以外は設計とコーディングをしていました。

ペアの後輩とはよく雑談などもする間柄ですが、ペアプロ中は雑談をすることはほぼありませんでした。タスクをどう終わらせるか、アルゴリズム部分の実装をどう行うかなど、一人で実装していたら手が止まりそうな時でも、会話をすることで集中を切らさずに実装し続けることができました。

よくペアプロは開発の効率が上がると言われていますが、この手が止まる時間がなくなることが一番効率アップに寄与していたと感じます。

ペアプロを行う上で注意した方が良いこと

事前に基本的な設計や要件定義を終わらせておくこと

今回ペアプロを行う前に、実装する機能のロジックの精査やテストケース作成は、別タスクで完了した状態でした。要件の詳細はプロダクトオーナーと会話して、私と後輩の間で疑問点を解消していました。

機能についての疑問点や不明点があると、ペアだけで意思決定できないためにどうしても作業が止まります。手戻りや別チームとコミュニケーションが極力発生しないよう、できる限り要件は詳細に決めた状態としておくことが重要だと思います。

互いが元気なタイミングで実施すること

後輩と私は生活リズムが対照的で、後輩は朝強く、私は朝弱いタイプでした。そのためペアプロは朝11時〜17時（お昼休憩あり）くらいで実施することが多かったです。

11時時点では私は頭が動き始めたところで、後輩の頭は冴え渡っていました。逆に夕方にかけて私の頭が冴えてきて、後輩が徐々にヘロヘロになっていくという、人間のコントラストを感じました。生活リズムは直そうと思っても直らないので、せっかくペアプロをするなら双方が比較的元気なタイミングで実施するのが良いかなと思います。

人間の相性はありそう

ペアプロをしていると、「こういう実装の方が良いのではないか」とか「自分ならこう書くがどうか」など、実装や設計、進め方について意見を率直に述べ合うことが多いです。意見を遠慮するとペアプロとして消化不良になります。

しかしながら、どうしても人の相性によっては率直に意見を言うのが難しく、「納得できるまで質問する」「実装方針についての意見を健全に戦わせる」ことができない場合もあると思います。相性によっては単純にペアプロが重荷になることもあると思うので、いつでも誰とでもやるべき、とは思いませんでした。

おわりに

ペアプロでの機能実装はとても楽しかったです。（それが最大のメリットだったかもしれません）

ペアプロで設計・実装した機能は、バックエンド・フロントエンドとも全てのコードを把握することができました。ペアプロの利点として一般的に言われるように、特定の誰かがコードのオーナーシップを持つ状態を避けることができました。

また二人で集中してテストを実装したこともあり、ローンチ後も目立ったバグなどは発見されていません。今後も機会を見つけてペアプロを実施していきたいなと思っています。

この記事を通して、電通デジタル開発部の雰囲気なども伝わっていれば幸いです。一緒にペアプロをしてくれた後輩、そして温かく見守ってくれたチームの皆さんありがとうございました。