ペアプロがうまくいっている状態とは何なのか考えてみる
本記事は、Uzabase Advent Calendar 2021 2日目の記事です。
はじめに
弊社のB2B向けSaaS事業のチーム（以下、Product Team）では、フルタイムでのTDD×ペアプロを採用しています。
そのチームの中で9ヶ月ほどペアプロを実践していき、感じたことを記事にしようと思います。
※そもそもペアプロというのは何か？ という説明は割愛させて頂きます
※あくまで私自身が「こういう状態になっているとペアプロとして上手くいっているのではないか」という考えを書いています。チーム内で「これが良いペアプロだ」と定義しているものではありません。
Product Teamでやっているペアプロ
前提として、Product Teamでやっているペアプロを簡単に説明します。
環境について
ペアプロを行う環境について軽く触れておこうと思います。
最近ではIntelliJのCode With MeやVSCode LiveShareを使用して、個人のローカルマシンに接続してペアプロを行っています。
リモートで作業を行う日もありますが、その時のコミュニケーションツールとしては、Gatherを使用して、お互いの顔を見えるようにしてコミュニケーションを取っています。
ペアプロのスタイル
ドライバー・ナビゲーター交代：キーボード奪い合い式
ネット上で記事を検索していると、ドライバーとナビゲーターという役割に分けて、時間やテストを書くごとに交代するやり方が多いと思います。[1]
Product Teamでは、このドライバー・ナビゲーターという役割は時間やテストごとでは交代しません。
ではどのように交代していくかというと、キーボード奪い合い式です。
つまり、書ける人がキーボードを奪って、ドライバーになります。
お互いがキーボードを叩こうとしてコンフリクトするくらいがちょうどいいとのことです。
もちろん、ペアのスキル差などによってはペアの片方がテストを書いて、もう片方が実装をするというピンポンペアリングを選択する場合もありますが、上記が基本方針となっています。
1時間ごとにペアチェンジ
基本方針として1時間したら休憩を入れ、休憩後にはペアのローテーションを行います。
これは同じペアによる属人化を防いだり、新しいペアによってもたらされる視点を取り入れる狙いがあります。
イメージ
09:00 - 10:00
ペア①：Aさん Bさん 【ストーリーYを実装中】
ペア②：Cさん Dさん 【ストーリーZを実装中】
↓ 休憩後：BさんとCさんをペアチェンジ
10:10 - 11:10
ペア①：Aさん Cさん 【ストーリーYを実装中】
ペア②：Bさん Dさん 【ストーリーZを実装中】
どういう状態が良いペアプロなんだろうか？
こうしたペアプロを徹底した組織の中で私も実践していますが、
ふと、「自分は普段のペアプロで上手くできているのか。前より良くなっているのだろうか」と思うようになりました。
いまのチームのペアプロのやり方は良いと思っていますが、ペアプロをすることで私やチームが何を得られているのか。
どういう状態になっていれば、より良いペアプロになってきていると言えるのかを言語化をしてみたいと思いました。
ペアプロがうまくいっている状態とは
1つのことにチームが集中できていること
アート・オブ・アジャイルデベロップメントには、ペアプロの効能として以下の記述があります。
ペアプログラミングがうまくいっているときは、いつの間にかパートナーと一緒なってコーディングをはじめとする作業に一心不乱に取り組んでいることに気づくだろう。邪魔されたり気が散ったりすることがほとんどなくなるという体験をする。邪魔が入っても、1人がそれに対処し、もう1人は仕事を続けることができる。そしてその後、すぐに仕事の流れに戻ることができる。1日の終わりには、心地よい疲労感と満足感がある。チームの仲間と同じ仕事に取り組むという極度の集中と一体感を味わう。
アート・オブ・アジャイルデベロップメント p.84
これは私自身も実感値としてあります。
私は1人で実装をしようとすると気が散りやすいタイプです。
集中しようとする為になにか音楽を選んで時間を掛けてしまったり、調査するつもりでググっていたら違うものまで調べたり、Twitterしたり。
これがペア作業になると良い意味で監視役になってくれる為、目の前のコーディング作業に集中がしやすくなります。
コーディング時に文法やバグなど技術的に詰まりそうな時にも、相手がアイデアを持っていたり、先んじて調べていたりするので、1人でコーディングするより詰まりにくくなります。
また設計についての方針が相手と違って対立し、コーディングの手を止めて議論が起こる場合もあります。
ですが、それはいずれ起こる問題を先取りしている場合が多いです（たとえば後でレビューをするときに議論するなど）。
ペアプロを行うことによって他者からフィードバックをリアルタイムで受け、実装の方針などの意見の食い違いが浮き彫りにすることができます。
それが早く見つかって解消していくことで、だんだん相手と認識が揃っていくようになります。[2]
できていないとき
では逆に1つのことに集中できていないと、どんな結果が起こるかを考えてみます。
1日の終わりに「今日は色んなことがあって疲れた」という感じる時があります。
これはペアプロによるフロー状態がうまく実現できていない可能性があります。
私が一日の終わりに、上記のような感想を抱いた出来事を振り返ってみると、
- 一度に取り組むストーリーが3〜4つ以上ある
- これは同時並行でストーリーを進めているパターンです
- 状況によってストーリーがWIPになってしまうので、仕方ない場面は多分にありますが、極力同時並行するストーリーは絞るのは大事だと考えます
このような状況が起きないように、一度に取り組むストーリーを絞ってみれるか試してみる。
またペアプロ中も、いま取り組むべきストーリーに関する話に集中ができているかどうか。
いまこの場で話さなければいけない問題なのかを考えていく必要があります[3]
頻繁に会話ができているか
会話が長い間途切れていないというのも、ペアプロが上手くできている状態じゃないかと思います。
ペアプロの心得にも、コミュニケーションについての話が書かれています。
6.ドライバーをしているときに進行中の作業についてこれから何をするのか、いま何をしているのかについて話してますか? ペアプログラミングでは、15秒の沈黙ですら長すぎます。
15秒は極端に感じられるかも知れませんが、実感値として上手いペアプロは会話が途切れていないです。
ドライバーは基本、自分のやろうとしていることを実況します。
そうすることで自分の思考のプロセスをナビゲーターに伝え、ナビゲーターはそこに違和感があれば止めたり問いかけることができます。
できていないとき
逆に沈黙が生じる場合は、あまりよくない状況です。
本来であれば相手からもらえるフィードバックが途絶えているからです。
どういった時に沈黙が生じるかはいくつか理由があると思いますが、以下のような理由が多いのではないかと思います。
- 技術的にどうコードを書いたらいいのかわからない
- 何をやるべきかがわかっていない
- 体調が悪い・疲れている
相手がこのような状態になっている場合には、状況が停滞しているとも捉えられるので、
- 技術的な停滞であれば調査をする、誰かに聞く
- 何をやるべきかわからなければ、聞いたり問いかけたりして認識合わせをする
- 体調が悪いのであれば休憩を取る
といった別のアクションを取る必要が出てきます。
ナビゲーターは一歩先を考えられているか
ペアになると 1 人がコードを書く。この人がドライバーだ。もう 1 人はナビゲータで、考えるのが仕事だ。ナビゲータはドライバーがタイプしているものについて考えるときもある
（でも、セミコロンがないのを指摘してくれるなんて勘違いしないでくれ。そんなのはうっとうしいだけだ）。次に取り組むべきタスクについて考えるときもあれば、どうやってそのタスクを全体の設計にぴったり合わせ込むかについて考えるときもある。
アート・オブ・アジャイルデベロップメント p77
ドライバー自身が実装することがわかっていると安心して（油断して）、ドライバーが書いているコードを眺めるような状況があります。[4]
いま書いているコードの次にどのクラスのどういうメソッドを作るのか（または修正するのか）。いまあるテスト以外に必要なものはないか？ 設計をより良く（よりシンプルに）できないだろうか。
といった一歩先のことを考えて、必要であれば裏で調べておくことも必要だと思います。
できていないとき
一歩先を考えられていない時は、次の作業のイメージが湧いていない状況だと思います。
その場合は今すぐドライバーに交代しても、自分ですぐに手を動かすことができない可能性があります。
チームがキーボードを奪い合って交代するやり方を基本としているのは、おそらくこういった背景もあります。
キーボードをいつでも奪ってドライバーになる心構えをしていくことで、次にどのような実装をするか少し先のイメージをしていきます。
そのイメージと乖離するようなことをドライバーがしたときには、なぜそうするのかを問いかけることで、お互い気づいてなかった景色を交換して、設計の選択肢を広げるような良いコンフリクトを起こすことができます。
さいごに：ペアプロに通じる価値・原則
自分なりにペアプロがうまくいっているであろう（またはうまくいっていない）状態を書いてみました。
ここまで書いていて、ペアプロはXPの原則である「流れ（Flow）」や「ふりかえり（Reflection）」などに通じるところがあると理解できました。
ペアプロはペア同士のコミュニケーションが大事とはいえども、本質的ではないお喋りばかりをしていて、コーディングが進まない状態というのは、良いペアプロとは言えないでしょう。
原則にある開発の「流れ」を途切れさせないよう、ペアプロを実践していくのが大事なのではないかと思いました。
Discussion