ペアプログラミングを試験的に実施してみたことを振り返る！

ブレインパッドでは、より良い製品開発のために新たな開発手法を取り入れるなど、日々さまざまな取り組みを行っています。今回、ペアプログラミングを試験的に導入しましたので、その模様をご紹介します！

こんにちは。
マーケティングプラットフォーム本部開発部の西尾です。

ブレインパッドでは、クライアントワークとなる受託分析のみならず、プライベートDMPの「Rtoaster」やインターネット広告支援ツールである「L2Mixer」といった、Webマーケティング支援ツールを自社製品として開発しています。

製品の開発といってもただ開発をするのではなく、GitHub FlowでPull Requestベースの開発フロー・TDD・CIなどといったモダンな開発手法を取り入れ、より良い開発を行うことを心がけています。

今回のブログは、開発手法改善の一環として試験的に導入した、ペアプログラミング（「ペアプロ」ともいう）についてご紹介します！

■ペアプログラミングとは？

取り組みの紹介の前に、「そもそもペアプログラミングって何？」という点について説明します。ペアプログラミングとは読んで字のごとく、ペア（2人）でプログラミングを行うことを指します。プログラミングと言っても、ただコードを書くだけではなく、「タスク分割」「設計」「実装方針の相談」もペアプログラミングに含まれます。

近年、GitHub上で多くのコードレビューがPull Requestの形でオープンなものとなりつつある中で、Pull Requestベースでの開発が開発現場におけるデファクトスタンダードとなってきています。

その中で、ペアプロミングは、Pull Requestの差し戻しなどによる手戻りの発生やレビュー待ちPull requestの渋滞といったボトルネックの解消、コードレビューをリアルタイムに近い形で行うことによる開発の高速化、といった点を期待して近年注目度が高まっています。

さっそく「WEB+DB PRESS Vol.102」でもペアプロミングの特集が組まれていて、今後開発現場に浸透していくのではないかと感じています。

■ペアプログラミングの様子を画像で再現

とはいえ、やったことのない人にはいまいちピンと来ない内容なので、ペアプロの様子を直感的に理解していただけるよう再現画像を用意しました。それではさっそく、画像と一緒に見ていきましょう！

筆者（どないしょー。。。これどうやって作るんー。。。）

筆者（あかーん。わからーん。）

筆者（せや。ちょっと先輩とペアプロしてみよう。都度質問するんやなくて、スキルは盗むものやで!!）

ここで先輩と、状況と要件について整理します。

筆者「ちょっと〇〇が××でして。。。」
先輩「ふむふむ。。。」

次に、現状を確認します。

先輩「このメソッドでは△△な処理をしていて。。。」
筆者「なるほどー。」

そして、コーディングを行います。

筆者「このメソッドの引数には◎◎が渡されるので。。。」
先輩「あっ、それは違いますねー。」
筆者「おっと。。」

ある程度進んだところで、こまめに仕様と方針を確認します。

先輩「インプットとアウトプットが。。。」
筆者「なるほどですねー!!」

確認した内容を照らし合わせながら進めます。

筆者「ここはこーで、そこはそーで。」
先輩「ですです。合ってますよー。」

キリのいいところで、たまに休憩を挟みつつ。。。

上記工程を繰り返して。。。

無事、要件通りのものが完成しました！！

筆者「やったー。」
先輩&チームメンバー「お疲れ様でしたー。」

■今回こんなことを工夫してみました

再現画像では表現しきれないほどたくさんの工夫をしているので、ここでご紹介します。

●作業ログを事前に準備する

ペアプロ中、ペアを組んだ相手からどのようなアドバイスをもらったか、すべて記憶することは正直難しいです。

実際、ペアプロは、（仕方のない場合を除いて）他の業務の差し込み要素を極力排除して実施するので、コードに集中できるというメリットがあります。

一方デメリットとしては、集中するあまりペアプロ中に学んだ作業を記録する工程を踏むことが難しく、後で見返しても覚えていないことが出てきてしまう。。。という事態がありました。

そこで、今回は作業量が比較的少なかったこともあり、開発の勢いを殺すことを覚悟でナビゲーター役の先輩との合意の上、逐次メモを取っていくスタイルを取ってみました。

●できるだけ考えていることを口に出す

何をどのように進めるのか、簡潔さとか諸々を気にせずにできるだけ考えていることを全部声に出すようにしました。これは実際の思考内容を修正するにあたり、コードというアウトプット以前の状態で

既存の状態をどう把握したか
仕様をどう理解しているか
これから何を実装しようとしているか
実装するにあたり何を調べようとしているか

については、可能な限り声に出していました。

■そして、今回得られたこと

今回、実際にペアプロをやってみて、得られたことを紹介します。

●仕様の共有やレビューにかかるコストがトータルで減った

仕様の共有についてはペアプロ時に「何をどのように作るか」を考えるにあたり、ドライバー・ナビゲーターともに仕様を把握する必要があったため、実装前に確認を行いました。（大枠や進捗に関して逐次共有していたのも少し効果を発揮しました）
これにより、実装後に時間を置いて一気に全てを確認するよりも、仕様の共有コストは量・時間の両面から減らすことができたように感じます。
レビューについてはお互いにコードを見ながら作っているので、実装と同時に確認を行えたことがコスト減につながりました。

●詰まった瞬間に解決の糸口をアドバイスしてもらえた

前提や途中経過等々の説明を省略してディスカッションしたり、質問に対して即座にアドバイスをいただけたことは、メモを取りつつ進めた中でも大幅なスピード感の向上を感じることができ、私自身にとって満足感が大きかったです。そして何より、自分自身にパーソナライズ化された状態で必要な知識を学べたことが、とても良かったと思っています。
具体的には、テストコードの共通部分を別ファイルに切り出す際の実装方法や、実装当時にどのようなことを考えながら実装していたかといった考え方の部分など、実装時に生きる知識だけでなく今後に生かしていける考え方まで伝授していただけました。また、実際にペアで作業しているので、得意不得意な内容を自然と相手に伝えることができた点も、良かったと感じています。