ペアプログラミングを導入するなら、まずはこう準備しよう！
これが揃えば、より楽しく、よりスムーズにペアプログラミングができる。
前回の「ペアプログラミングの５つのいいこと〜だから、難しくてもやりがいがある！」編ではペアプログラミングのメリットとよく耳にする懸念点について書きました。慣れるまで難しい部分もあるけれど、総合的にはプラスが多いとの考えをシェアしました。 😉
今回は、ペアプログラミングをしてみたい！という方に向けて、導入する時に役立つポイントをまとめてみました。前回同様、私個人の意見になりますが、基となっているのはPivotal Labsでの経験がほとんどです。
ペアプログラミングの経験がある方もない方もコメント大歓迎です！
1台のPCに2台のモニターと２つのキーボード＆マウスを繋げたペアステーションを用意しよう
ペアプログラミングと聞くと二人のエンジニアが席を寄せて一台のモニターを覗き込んでいるイメージもあるかもしれませんが、それではあまり生産的ではありません。
１台のコンピューターに２台のモニター、２台のキーボード、２つのマウスを繋げた設定が理想的です。両方のエンジニアが同時に実装を見ることができ、キーボードの譲り合いをせずにすぐに入力できることが重要です。「よく見えないからモニターこっち向けて」とか、「キーボードちょっと貸して」の様なちょっとしたやりとりを削ることで、ずっと生産的になります。プロジェクトによって1ペアから多くて４、５ペアのチームもありますが、ペアの数だけペアステーションを用意することになります。
ちなみに、Pivotal Labs Tokyoのペアステーションの設定はiMac（27インチ）+ 外付けモニター（27インチ）ですが、デスクトップ+外付けモニター2台でも問題ありません。平等性を保つ為にも2台のモニターは同じサイズにしましょう。
キーボード・マウスに関しては、チーム共通のデフォルトを決めずに、US配列でもJIS配列でも、マウス派でもトラックパッド派でも各エンジニアの好きなものを使える環境が理想的です。複数ペアのチームは定期的にペア交代をするのですが、その時にキーボード・マウスを持って席を移動するので、接続設定が複雑なbluetooth型より有線型が入れ替えに便利です。（ペアの移動についてはあとの方にある「ペアプログラミングをスムーズに続けるためのチームのテクニック」で詳しく紹介します）
コンピュータのログインユーザーや設定を共通化し、チームで管理しよう
コンピュータのログインからIDEまで、開発に必要な全てのソフトウェアや設定をエンジニアチームで決める必要があります。複数ペアの場合はペア交代で一日おきぐらいにはペアステーションが変わるので、全員に全てのマシンとアカウントのアクセス権限があることが重要です。
マシン間のファイル交換等も簡単にできるようにコンピュータに覚えやすい名前をつけて、共通のログインユーザ・パスワードを使ってsshなどでアクセスできるように設定すると便利です。ちなみに、Pivotal Labs Tokyoではコンピュータにtoroとかikuraとか、寿司ネタの名前をつけてます。🍣
ssh以外の方法でもデータを共有できるように予めチーム共有のGmailを作成して、そのアカウントでBitbucket、Google Docs、Postmanなどのアカウントを作ると便利です。
複数ペアでの開発をすると、自分以外のコードを見ることが多くなるので、分からないコードに関する質問を誰に聞けば良いのかが分かると便利です。git duetを使うとコミットメッセージに二人の名前をauthorとreviewerとして両方記録できるのでお勧めです。
ペアプログラミングに向いたエンジニアを探そう
ペアプログラミングに向いたエニジニアを探す時の、技術や経験以外に重要な要素は？
ペアプログラミングはエンジニアのスキルレベルとは関係なく好き嫌いが分かれます。新しいチームメンバーは、ペアプログラミングに興味を持っていることに加えて以下の特徴が必要条件と言えます。
・チームメンバーに相談することをためらわない人
・何かについて自分が分からないということを、他人に知られるのを恐れない人
・自分とは違う考え方や技法を論理的に考慮し、取り入れることのできる人
当然、エンジニアとしての技術や経験も重要ですが、それ以外にもこのようなオープンなコミュニケーションができる・したい、ことが重要です。
ペアプログラミング体験をして、フィットするかどうかを確かめる
チームワークやオープンなコミュニケーションのできるエンジニアでも、やってみるまでは分からないので、半日ほど実際のプロジェクトに参加してペアプログラミングを体験してもらうことをお勧めします。
ペアを組んでみることで、お互いのコミュニケーションスタイルや開発へのアプローチが分かるので、面談や説明会などよりはずっと効果的に相性のいいペアを見つけられます。
ペアプログラミングをスムーズに続けるためのチームのテクニック
毎日チーム内でペア交代しよう（複数ペアの場合）
毎日ペアを交代することで、チームの全員がコードベースの全てに触れ、理解することができます。交代をする時にはペアの片方が前日と同じペアステーションに残り、交代してきたエンジニアに前日の進展や課題を説明します。ペアステーションごとに開発トラック（開発するべき一連のユーザーストーリーをまとめたエピックや機能）をアサインすることが多いので、一人のエンジニアが連日同じ開発トラックに残るのは２日までに抑えることをお勧めします。
数ヶ月ごとに新しいメンバーを入れよう
ペアプログラミングの利点の一つは複数のエンジニアの考えを新しく取り入れ続けられることなので、長期プロジェクトは数ヶ月ごとにメンバーを一人入れ替えるとアイデアの循環に効果的です。既存のアイデアや方向性を検証することができますし、新鮮なアイデアを取り入れることもできます。
休暇などでエンジニアの数が奇数になっても開発は継続しよう
ペアプログラミングの開発チームは偶数人構成が大前提ですが、休暇などで一時的に奇数人になっても開発は続けられます。
３台目の外付けモニターを繋げて三人でトリオ・プログラミングをすることも選択肢の一つです。新しい開発パターンを試したり新しいアイデアを取り入れたい時など、不確定要素があり、ディスカッションの多そうな開発段階の時に効果的です。
逆に、開発パターンや進行方向がチーム内ではっきりと共有されている場合は、余ったエンジニアがソロで開発することも選択肢にあります。シンプルだけど時間のかかる開発タスクや簡単なリファクタリングなど、後日チームと共有しやすい内容であれば、ソロで実装しても問題ありません。
また、他にも奇数人になっているチームがあればエンジニアを借りる（もしくは貸す）ことでメンバーが全員揃うまでどちらかのチームの穴を埋めることができます。新しいエンジニアの意見を聞く機会にもなりますし、受け入れるチームとしても参加するエンジニアとしても発見や学びがあるはずです。貸し出したエンジニアは、新しいアイデアや閃きを持ってチームに戻ってくるかもしれません。
ペアプログラミングをスムーズに進めるためのエンジニアのテクニック
ペアプログラミングは開発の段階や種類、エンジニアの技術者としての経験、エンジニアのペアプログラミングの経験などによって進め方が変わります。大きく分けると以下のDriver-NavigatorとPing-Pongがあります。ペアプログラミングはとても難しいので、どちらかのテクニックを必ず型通りに厳密に守らなくてはならないわけではなく、目標とするべき形の一つとして参考にしください。
ドライバー・ナビゲーター方式（Driver — Navigator）
車の運転手と助手にたとえたテクニックで、キーボードで入力する人をDriver、実装の説明をする人をNavigatorとします。エンジニアの間で新しい技術や実装方法を教える時によく使われる手法です。DriverばっかりタイプしてNavigatorは暇？と思われがちですが、学びの段階によって様々な重要な役割を持ちます。
最初は、教える側のエンジニアがNavigatorとして口頭で実装の説明をし、教わる側がDriverとしてNavigatorの説明をキーボードで入力します。Driverは初めての言語・プラットフォーム・開発パターンでも、打ち込むことで早い段階からその実装のイディオムに馴染むことができます。ちょっと慣れてきたら、自分から実装をリードし、わからない部分に関してはNavigatorの意見を聞くようにします。
学びが更に進んだらDriverとNavigatorの役割を入れ替えましょう。Driverは「次はどういうテストを書きましょうか？」や「この変数は何とよびましょうか？」など、進行の役割をします。それに対してNavigatorが実装内容を提案し、Driverが入力します。Navigatorが実装を説明しながら自分の理解度を再確認し、Driverがキーボードで入力しながら、必要に応じてヒントやアドバイスを出す形になります。
ピンポン方式(Ping-Pong)
考えを口頭で説明しなが自らキーボード入力する実装役と、コードの生産性や誤入力のチェックをしながら必要に応じてフィードバックをするレビュー役に別れてペアを組む手法です。お互いの役割を尊重しながら頻繁に交代しながら卓球のボールを受け渡し続けます。
ピンポン手法はテスト駆動型開発のRed-Green-Refactor開発サイクルと良く合います。以下のRed、Green、Refactorの順番に開発を続けると、価値の高いテストと実装コードを書けます。
Red ：次に必要な振る舞いを表すテストを書いて走らせる。（まだ実装はされていないのでテストが失敗し、Redとなる）
Green ：失敗しているテストを成功させる為の最少限の実装をする。（テストを再実行すると通るのでGreenとなる）
Refactor：実装の内容を必要に応じてリファクタリングする。重複の多い部分を共通化したり、大きいメソッドをより分かりやすく単一責任の小さいメソッドに切り分けたり、変数名をより分かりやすくリネームしたりします。求めている振る舞いのテストが成功している状態で始め、テストが失敗していないことを確認しながら納得のいく品質になるまで少しずつ変更を加えます。
このサイクルを以下のようにPing-Pongでペアプログラミングするとスムーズに進められます。AさんとBさんがペアを組んだ場合、
- Aさんが失敗するRedのテストを書く
- Bさんがそのテストを成功させGreenにし、必要に応じてRefactorをする
- Bさんが次のRedのテストを書く
- Aさんがその次のテストをGreenにし、必要あればRefactorする
テストが失敗しているタイミングで引き渡しをすることで、次のステップの指針を立てる役割と実装の役割をはっきりと分けることができるので、役割ごとのチャレンジを楽しむことができ、ペアの間で方向性が合っていることも確認できます。
今回の記事では、様々な開発環境の設定やテクニックなどを紹介しましたが、最初から全てを導入するのは難しいかと思います。まずは、ペアプログラミングに興味のある仲間を見つけやってみることをお勧めします。最初は小さいチームで初めて、「これはいけるぞ！」と思えるようになったら少しずつ新しい手法やツールを取り入れながらプロセスを改善していくことをお勧めします。
Pivotal Labsでは、定期的にワークショップ型イベントを開いたり、ブログでプロダクト開発やチームビルディングなどについて紹介していきます。
イベントの最新情報：
Meetupグループに参加すると、いち早く案内が届きます😎📩
公式ブログ：
Product Runも是非フォローお願いしますっ🙌🏻🗒
