ペアプログラミングをやってみて感じたこと

この記事について

ROXX Advent Calendar 2019 - Qiita の18日目の記事です。

所属はいちおう back check チームですが、どんどん優秀なメンバーがジョインしているので最近あまり活躍できる場がありません。そんな中、数少ない仕事のうちのひとつに、チームメンバーのひとりと継続的に行っているペアプログラミングがあります。
本記事では、ペアプログラミングをやってみて、どう感じたか、というのを、ペアメンバーの感想も交えて記します。

はじめに

ペアプログラミングについて

ペアプログラミングのメリットについては以下の記事が参考になります。
ペアプログラミングの５つのいいこと - Product Run - Medium

1. 新しい技術や開発パターンを効率的に身につけられる
2. ちょうどいい緊張感がコードの質も生産性も上げてくれる
3. バス係数が上がり、神デベロッパーに依存しなくてよくなる
4. masterブランチでの開発からの即デプロイが可能になる
5. 開発パターンや知識の指数的拡散

私たちのケースでは、1,2 が該当しています。

チーム全体で取り組んだとしたら 3, 4, 5 も得られるだろう、という予感はありますが、まだチームにそれを提案できるところまで踏み込んでやれていないので、今後の成果次第かもしれません。

ここに書かれていないことをひとつ挙げるとすれば、リアルタイムでのフィードバックが得られる、ということです。普段コードレビューを行っているチームは多いと思いますが、それはあるていど完成したコードの状態に対するフィードバックになってしまうので、大幅な変更が伴うような指摘がしにくい（チームによってはしてるかもしれませんが）、という問題があります。ペアプログラミングであれば、最初の1文字からフィードバックを得ることができるので、大きな手戻りが発生する（あるいは先送りされる）リスクを軽減することができます。

ペアについて

私: PHP歴15年、Laravel歴3年、ROXX歴2年
彼: PHP歴1年、Laravel歴1年、ROXX歴1年

（年数はおよそです）

やったこと

・業務のプロダクト
・業務外の個人プロジェクト
・オブジェクト指向モデリングの課題

それぞれに違ったやり方と効果があったように思います。

業務のプロダクトと業務外の個人プロジェクトでは、ドメイン知識は彼のほうがあったので、私がドライバーのときは、ナビゲータの彼に要件がどうなっているかを確認しながら進める形になり、逆に彼がドライバーのときは、別の書き方のほうがよさそう、とナビゲータの私が思ったときに、アドバイスするようにしました。

一方、オブジェクト指向モデリングの課題に取り組む際には、彼に基礎的な知識が不足していたことから、私が基礎的なことを説明しながらやっていたので、彼から質問を受けて私が答えて、それに沿って実装する、みたいな時間が多かったように思います。

どちらにも共通しているのは、できるだけテスト駆動でやるようにしていた、という点です。「できるだけ」というのは、プロダクションコードとテストコードを頻繁に行き来することで、集中が削がれそう、と思ったときは、プロダクションコードのみを進めたことがありました。

パートナーの彼も以下のような感想を書いてくれました:

テスト駆動開発とペアプロは抜群に相性がいいと思います。指導者、非指導者との技術力の差が大きくても、書いたテストを通すという小さいゴールをいくつも設定しておくことで、実装において認識のずれが出にくくなると感じました。

テスト駆動でやると、なにから手をつけていいのか、がわかりやすくなるので、自分ひとりでもできるだけテスト駆動でやるようにはしていますが、ペアプログラミングをするときは、テストを書くことでゴールに対する認識を二人で合わせられるので、なおさらテスト駆動がいいかもしれません。

パターン別感想

先に挙げた3つのパターン別に、感想を書いておきます（引用しているのはパートナーのものです）。

業務のプロダクト

業務のプロダクトを選択するメリットは、解決したい課題が明確であること。またチームのコーディング規則や並行する他タスク配慮した実装を考える必要がありますが、その思考の課程を追うことができることも大きな収穫でした。
注意が必要なことは、指導者側が対象の業務プロダクトのドメイン知識や既存コードや将来的なリファクタリングの予定についても知っている状態でないと意図とは違う実装になりえる可能性があることです。

「指導者」と書いてあるのが私のことを指しています。が、私は業務のプロダクトに関しては、あまり正確なドメイン知識を持っていないので、その点に関しては私のほうが「被指導者」ということになります。私たちの場合は、片方が要件を把握していたので問題ありませんでしたが（と思ってるんですが）、両方ともがドメイン知識に疎い場合だと、けっきょくだれかに確認しながら進めなくてはならず、一定時間集中して行ったほうがいい結果が得られると思われるペアプログラミングにおいて、集中を妨げる原因になると思うので、避けたほうがいいかもしれません。

業務外の個人のプロジェクト

業務外の個人プロジェクトを選択するメリットは、非指導者側の興味関心が高いことと、設計のことまで学べることです。ペアプロで業務プロダクトを取り扱う際、既存の状態を再設計するような機会はなかったため、その機会を作ることができたとも言えると思います。
注意が必要なことは、個人プロジェクトだとシンプルなアプリケーションになりがちで、業務プロダクトほどの複雑さを持つコードが必要でないことです。基礎の定着という意味では有効ですが、すでに走っている業務プロダクトにそのまま活かすには間接的すぎると思います。

これは会社の（チームリーダーの）厚意で、週に1時間ていど業務時間内に業務外の個人プロジェクトに時間を割いていました。トレーニングのひとつとして、スクラッチからウェブアプリケーションをつくるというのは色んな面で有用と思います。要件定義、アーキテクチャ、インフラといった、普段あまり大胆に触れることのない領域だったり、職責の範囲によっては携われない領域だったり、に対しても、フィードバックを得ることができます。今回は、Docker で開発環境構築をしたり、Heroku にデプロイしたり、といったことにチャレンジしました。

オブジェクト指向モデリングの課題

オブジェクト指向のモデリングの課題は、サーバーサイド入門者である被指導者にとっては、とても有効だと思います。
それまで主にフロントエンドを担当していたため、モデリングの考え方を理解するハードルは高かったです。この課題をもらったあとにいくつか本を読んでみました。しかし、ほとんどが読ませる内容になっていて、すぐにコードに落とし込むにはハードルが高いと感じました。
ペアプロで課題をいただき、話しながら手を動かして進めていくほうが理解が進みました。「体で覚える」モデリングとして、ペアプロの課題としても有効だと思っています。

これは、初学者の多くが抱えている問題なのかなと思うんですが、設計のトレーニングというのは、なかなか独学ではやりにくい領域なのかな、という感覚があって、設計の段階からペアプログラミングをすることで、どういうロジックで概念モデルをソフトウェアに落とし込んでいくのかっていう過程と、シニアエンジニアであっても、試行錯誤して設計しているんだっていう、ある種の安心感というか、そういうものなんだ、という認識を持ってもらえるんじゃないかな、とも思います。

なので、要件定義がなされた直後の状態からのペアプログラミング、というのもおすすめしたいと思います。

おわりに

月並みではありますが、ペアプログラミングはいいぞ、ということでポエムを綴ってみました。

個人的にはまだまだ試行錯誤の最中で、より効果的なやり方、基本方針は守りつつ個別最適化する道筋、みたいなのを探っている最中です。

ビジネスでもプライベートでもペアを募集しておりますので、興味のある方がいたら、コメント欄でも Twitter でもご連絡ください（同僚諸氏にも読んでもらえることを願って）。