2人のプログラマーが一体となってプログラミングを行うペアプロプラミング（以下、ペアプロ）は、XP（エクストリームプログラミング）の主要プラクティスの1つです。ユーザベースのスピーダ事業では、開発組織全体でペアプロを実践し、生産性や品質の向上につなげてきました。
2022年にはその効果を最大化するため、社内の有志で「よりよきペアプロのためのガイドライン」という1万文字以上のドキュメントを策定。ペアプロの実践や「ふりかえり」に役立てています。作成自体がアジャイルに進められたこのガイドラインは何をきっかけにまとめられ、どういった内容を含んでいるのでしょうか。
現場でのペアプロを推進してきたスピーダ事業執行役員CTOの林尚之さんと、ガイドライン策定にも参加した機械学習エンジニアの二木拓也さん、ソフトウェアエンジニアとして実践する中嶋淳さんにお聞きします。
- 分からないほうが積極的にドライバーを取りに行く
- 知識を共有して全体最適を図るためにガイドラインを策定
- ペアプロの理想像を抽象から具体まで
- 2人で1人のプログラマーとして振る舞える状態を目指して
- ペアによる効果はプログラミングの領域にとどまらない
- 合わせて読みたい参考記事
よりよきペアプロのためのガイドラインはユーザベースのGitHubリポジトリで公開されています。
分からないほうが積極的にドライバーを取りに行く
── ユーザベースのスピーダ事業では全体でペアプロミングを実践されており、以前に掲載した記事（記事末の関連記事を参照）でも林さんが主導されてきたと伺っています。その経緯をまず教えてください。
林 ペアプロを始めたのは僕が開発に関わるようになった2013年ですが、当時は僕がいるチームだけでした。全体でペアプロを導入したのは、僕が社員になった2017年のことですね。
── そのときはスムーズに導入できたのでしょうか？
林 そうですね。僕たちのペアプロを見ている人が多かったし、同じチームでやっていた人もかなりいました。当時は合わない人もゼロではなかったですが、アジャイルにフィットしてくればすんなり取り組んでもらえるようになりました。それ以降はペアプロをやりたいという人を常に採用しているので、ペアプロが嫌だったりやりたくないという声に対応しなければならなかったりしたこともなかったと思います。
── 二木さんは入社以前にペアプロを経験されていたのでしょうか？
二木 入社以前にペアプロの経験はありません。社内的にも2019年4月に入社した時点では、機械学習エンジニアはあまりペアプロを取り入れていなかったのです。その年の7月頃に、私たち機械学習エンジニアとSREが林さんからペアプロの手ほどきを受けて、そこから本格的に始めました。
── 勝手なイメージですが、機械学習領域でのペアプロはあまり聞かないように思うのですが。
二木 ユーザベースではエンジニアリングの比重が多く、重要です。エンジニアリングに関して言えば、1人よりも2人でやったほうがよいものができて、将来的にも再利用でき、実験でも試行錯誤しやすいことを体感しています。データ系はいろいろな働き方ができますが、私は今のペアプロがしっくりきています。
── 中嶋さんはいかがですか？
中嶋 2021年4月に入社しましたが、前の会社ではモブプログラミング（モブプロ）をしていました。そのためペアプロもモブプロの一種という感じがあり、ハレーションはありませんでした。
── 実際にユーザベースで体験したペアプロはどうでしたか。
中嶋 これまでやってきた方法との違いを感じました。私がやってきたモブプロは15分くらいでドライバー、つまりキーボードを叩く人が交代するやり方だったんですが、ユーザベースのペアプロでは「キーボードを自分で取りにいかないと叩けないよ」と言われたんです。ドライバーの交代が自然に起きることを推奨しているんですね。最初はギャップを感じていましたが、慣れてくるととてもよい方法だと思いました。
── ドライバーの交代はあらかじめ時間で決まっているものではないんですね。
二木 基本は「分かってない側がドライバーを取る」というやり方です。とくにニュージョイナー（new joiner、新しく開発組織に入ってきた人）には、先輩メンバーが「ちょっと分からないんで私がやっていいですか」とやってみせます。すると「そうか、分からないときはドライバーをやるんだな」ということが理解できるので、繰り返しやっていくなかで「分からないんで私がやっていいですか」と言えるようになります。
── ペアプロでは1日のうちにペアそのものも何度かチェンジしますが、そのタイミングはどうでしょう？
中嶋 チームによりますね。多いチームでは1時間に1回くらい交代します。1時間作業をして10分休憩し、休憩から戻ったらペアを交代することを1日に5～6回繰り返します。
1時間ではあまり気分が乗れないまま終わってしまうこともあるので、そのときは1時間半とか、長いところは午前中いっぱいと午後1回の1日2回だけ交代というパターンもあります。
二木 私のいる機械学習のチームでも、午前中と午後の1日2回の交代というパターンが多いです。ただ、私が社内のレンタル移籍（1週間ほど他の開発チームに移籍して開発する施策）で別のチームに移り、1時間おきにペアを変えるという体験をしたら意外とやれることが分かったので、自分のチームに戻って試してみたりしているところです。
── 終わりの時間は決まっているんですか？
二木 それもチームによって違います。1日当たり8時間くらい働くチームが多いので、（昼休みを含んで）9時から始まれば18時に、10時に始まれば19時に終わりますね。残業はありません。
── リモートワークのメンバーもいると思いますが、ペアはどのように組み合わせているのでしょうか。
中嶋 できるだけメンバーがどこにいるかを合わせるようにしていて、リモートなら全員リモート、出社なら全員が出社というようにしています。出社しているメンバーとリモートで組んでいる間は問題ないのですが、休憩などでどうしても情報格差が発生してしまうんですね。出社しているとメンバー同士が雑談で情報共有できるんですけど、リモートだとほんとうに1人になってしまうので。
林 あえてリモートと出社のメンバーを半々に混ぜてみたこともあるんですけど、あまり効果が高くないことが分かって今の形になりました。リモートとオフィスのペアでは出社しているメリットがないので、両方がリモートなのと同じになってしまいます。出社のメリットを最大化しようとすると、全員が出社したほうがよいということになりますね。
2013年からSPEEDAの開発に参画。2017年にユーザベースに正式に入社し、翌2018年1月からSPEEDA事業（現スピーダ事業）執行役員CTOを務める。
知識を共有して全体最適を図るためにガイドラインを策定
── ここまで話していただいたドライバーやペアチェンジのことも「よりよきペアプロのためのガイドライン」では説明されていて、ガイドラインが実践に役立っていることを実感させます。そもそもなぜガイドラインを策定することになったのでしょうか。
林 もともとペアプロだけにフォーカスした話ではなかったんです。2022年の初頭に、組織全体をよりよくするため「個別最適と全体最適をちゃんと整理して考えよう」ということになりました。個別最適されていても全体最適につながらないケースもあるし、全体のことだけを考えて個別について考えないのもよくないですよね。高い次元で両立させるにはどうしたらよいか？ いろいろなトピックについて考える中の1つがペアプロでした。
ペアプロを行うとチームやプロジェクト全体のことを考え、知識を共有して教え合いながら全体のスキルを上げるため、全体最適につながります。いちプログラマーとしては、ひとり黙々とプログラムを書くことが個人の最適化になると考える人は多いでしょうが、それでは全体最適につながらない。検討した結果、ソロでプログラムを書くことは推奨しない、ペアプロでやっていくのがよいという話になりました。
しかし、現状でペアプロを本当にうまくやれているかというと、伸びしろはまだたくさんある。それならばペアプロのやり方を言語化し、ガイドラインを策定するのがよいだろうという話の流れです。
── コロナ禍の影響もありましたか？
林 それはありましたね。というのも、コロナ禍ではペアプロをずっとオンラインで実施していたのですが、やはりリアルの方が効果が高くなることが多いんです。リモートでもリアルでも、どんな状況でもペアプロの効果がきちんと出せるようにするための言語化でもありました。
── ガイドラインの策定にはどれくらいかかりましたか？
林 半年ちょっとです。もっとも「完成してから見せるのはアジャイルではない」ということになり、随時社内に公開してフィードバックをもらいながらブラッシュアップしていきました。最初はアウトラインのレベルでしたね。その後2週間に1回位リリースし続け、2022年12月にバージョン1.0を公開しました。
── 執筆はどのように進めていったのですか？
二木 執筆はパートごとに行いました。オフラインのペアプロについては林さんが中心となり、オンラインのペアプロについて書きたい人が2人いて、ニュージョイナーにどう伝えるかを私を含めた3人で書きました。
林 まず「オフライン編」で基本の話をして、リモートのペアプロには特有の制約があるので「オンライン編」で拡張する説明をしています。また、それぞれのパートの【キャッチアップ】でニュージョイナーに向けて「最初はここで苦労する、こう考えればいい」といったことを書いています。
- はじめに
- オフライン編
- マインド
- 一緒にゴールを目指す
- 先生と生徒にならない
- 【キャッチアップ】先生と生徒になることもある
- 【キャッチアップ】既存メンバーがNJから質問を引き出す
- 流れを止めない
- コミュニケーション
- 考えている事を口に出す
- 考えている事を聞いてみる
- 【キャッチアップ】 ペースを合わせる
- 指示をしない、されたと思わない
- 相手のタイピングを待つ
- ドライバーとナビゲーター
- キーボードを取り合う
- わからないからこそドライバーになる
- ディスプレイを指差す
- 【キャッチアップ】交代のタイミングを決める
- ペアチェンジと休憩
- ペアチェンジ
- 定期的に休憩をとる
- コントローラブル
- タイマーに縛られない
- 【キャッチアップ】機械的に時間を決めて休憩をとる
- 調査やスパイク
- 長めに時間を取る
- 調査の仕方を知る
- ストーリーへのサインアップ
- ペアプロかモブプロか
- 【キャッチアップ】複雑でないストーリーで固定する
- 【キャッチアップ】 モブプロ < ペアプロ
- 【キャッチアップ】業務中に一人で作業・調査する時間を設ける
- 環境
- 小さいホワイトボード
- 大きいホワイトボード
- 背中合わせの配置
- エチケット
- ペアプロしやすい机
- ディスプレイ
- キーボードとマウス
- オンライン編
- コミュニケーション
- 会話の量を増やす
- マイクを取りにいく
- 不意に沈黙する時間をつくらない
- 遠慮せずに話しかける
- Face To Face
- オフラインのような作業空間
- カメラをONにする
- 視界を共有する
- 周りの声が自然と耳に入るようにする
- さっと可視化して伝える
- 【キャッチアップ】NJがホストする
- 環境を整える
- 通話品質を確保する
- 通信環境を整備する
- 身体への負担を考慮する
- 他者への配慮を忘れない
- 余白をもたせる
- 休憩中に個人タスクをやらない
- 雑談をする
- 小さな喜びを分かち合う
ペアプロの理想像を抽象から具体まで
── ガイドラインの策定にあたって参考にしたものはありますか。
二木 かとじゅん（加藤潤一、j5ik2o）さんがGistで公開している「ペアプロの心得」というチェックリストは以前からチームで使っていましたし、ガイドラインでも参考にしました。
林 あのチェックリストは『ペアプログラミング』という翻訳書1をもとに、アトラクタの高橋一貴（kappa4）さんがブログに掲載していた「ペアプログラミングをうまくやるためのチェックリスト」ですね。
僕はフリーランスになった2009年頃に、加藤さんと同じプロジェクトにいました。ペアプロもしていたので、このチェックリストをプリントアウトしてみんなに渡したりしていたんです。その後ブログが閉じてしまったので、加藤さんがサルベージして公開されたようです。高橋さんには勝手ながらめちゃくちゃ感謝しています。
── 策定の作業は大変ではなかったですか。
林 アウトラインができた段階で、これを書き切れるんだろうかとちょっと心配になりました。フィードバックをもらって項目を追加したりもしましたから。
二木 最終的に原稿をマージして、1つのドキュメントにまとめる必要があり、そこは頑張りましたね。
── 林さんはペアプロを推進してきた立場ですが、二木さんはなぜ策定に参加されたのでしょうか？
二木 私もペアプロを長くやってきたのですが、新しく入った人に「ペアプロがどういうものなのか？」を伝える必要性を以前から感じてました。実践して直接教える以外にも、ガイドラインを作るという活動を通じて役に立てるのではと思い、手を挙げました。
── ドキュメントを用意したほうがよいと感じたということでしょうか。
二木 そうですね、しかもいわゆるマニュアルや手順書ではなく、このガイドラインは「考え方を伝える」という意味合いが強い抽象的なものです。普段ペアでコードを書いているときにそういう話はあまりしないので、何か指針となるものがあるといいのではないかと思っていました。
── 単に「ペアプロのやり方」をまとめただけではないということですね。
林 名前を「ガイドライン」としたのもそこを議論した結果です。守らなければならないルールではなく「こう考えるといいよ」という指針を示しています。理想像と言ったほうが近いかもしれないですね。
── 実際に読んでみると、ペアプロを実践する環境や具体的な手法から、抽象的な考え方まで多様なレイヤーが盛り込まれている印象を受けました。
二木 項目として一応は分けているのですが、全体としては抽象も具体もあるように見えるかもしれません。ただマインドから派生した結果として具体につながるので、完全に切り離すことはできません。これをプロダクトチームの理想像としてまとめておきたかったのかな、と今になって思います。
── 現在のバージョンは1.0ですが、今後のバージョンアップで追加すべき内容は何でしょうか？
林 いわゆる生成AIとのつきあいかたは追加したほうがいいと思っています。
中嶋 そうですね。使う頻度はチームや人によりますけど、基本はもうみんなペアプロでも生成AIを使っていますから。自分の場合はエラーが出たときに聞いて情報を集めて、さらに調べるという使い方が多いです。
二木 私の場合は最初に2人だけで進めて、ある程度のコードが書けた状態になってから、テストやテストを通す実装をよい感じにCopilotに分担してもらう利用方法が多いですね。
林 普通にペアがいるところに、Copilotなどの生成AIが参加して3人でモブプロしているような状態は、これからペアプロをするときに大事な考え方・捉え方ではないかと思います。とくに何も分からない状態のニュージョイナーが、生成AIと共にやってすぐに理解できるのかというと難しい。
でも、ペアプロでベテランとニュージョイナーがペアを組む場合と状況は似ていると思っているので、そこを整理してガイドラインに追加するのが今後やるべきことだと思います。
2016年に新卒として受託開発の現場でソフトウェアエンジニアとして働き始め、2019年にユーザベースに機械学習エンジニアとして入社。機械学習を使ってSaaSプロダクトの価値を高める開発に従事。
2人で1人のプログラマーとして振る舞える状態を目指して
── リリースされたガイドラインがどのように使われているのかお聞きします。
中嶋 私は策定側ではなかったのですが、ガイドラインを初めて見たときに、私たちのプロダクトチームが目指していることそのままが書いてあると思いました。
特にチームでニュージョイナーを迎えるときに使えるのはよいですね。前職でペアプロをやったことのない人だけでなく、今までペアプロをやっていた人でも、たとえば「自然にドライバーを交代する」といったやり方に慣れていない人もいるので、説明するときに役立っています。
── ほかにはどのようなときにガイドラインを参照していますか。
二木 ふりかえりをしているときに「まだ自分たちには伸びしろがあるのでは？」と思うときがあります。そんなときにガイドラインを見てみると、新たな発見があります。迷ったときに立ち返るためのものとして捉えています。
── ずっとペアプロを続けていても、まだ新たな気づきがあるのでしょうか？
中嶋 うまくいかないときに立ち返って考えてみると、プラクティスの解像度が低かったとか、別の考え方があることに気づくことが定期的にあります。
例えばXPの5つのバリュー（価値）のうち、ペアプロはリスペクトやフィードバックにも直結していることに改めて気づきました†。パートナーとはリスペクトの関係がないとそもそも一緒にできませんし、ペアプロではずっと話し続けないといけないと言われますが、それはフィードバックループを早く回すことにつながります。
† XPのバリューには「コミュニケーション」「シンプリシティ」「フィードバック」「勇気（courage）」「リスペクト」の5つが挙げられる。
── 長く続けていても発見があるのですね。理想のペアプロを実践するのは難しいと感じますか？
二木 私も2019年から5年間やってきましたが、まだペアプロに熟達したという感じはありません。2人で1人のプログラマーとしてふるまいつつ、レベルアップすることは本当に難しいと感じています。
最終的にはコードが2人の手によってレビューされ続け、あたかもひとりのプログラマーがコードを実装しているような状態を目標としている。お互いの良さを掛け合わせ、お互いの苦手な部分を補完し合うことで、相乗効果を生み出し1+1が3になるかのような成果を生み出せる。
── 今2人で1人になれているな、という感覚になることってありますか？
二木 ガイドラインにも「1+1が3になる」と書かれていますが、自分1人では作れないものがアウトプットとして出せているときですね。それには自分が持っている知識のほかにペアの人の知識も絶対必要で、それぞれの尖ってるところが発揮された結果よいものができた、ということなんです。
2人で1人のプログラマーとして振る舞えるとはそういうことなのかなと最近思っています。
中嶋 自分はペアプロをしていてキーボードを取るタイミングが相手とコンフリクトしたとき、この人も自分も同じことを書こうとしているんだなと感じます。そういうときに「2人で1人」を感じます。
── 2人で1人という感覚が人によって違うのは面白いですね。
林 どちらもありますよね。人それぞれに「今最高にペアプロできている」と思う瞬間があると思います。僕にもそういうタイミングはたくさんありました。人と一緒にやることで個別では出せない力が出せるのがいいところだと思っています。
── あえてお聞きしますが、ペアプロに向いていない人もいると思いますか？
林 そうですね。人によって最適なやりかたは違うと思います。そもそもXPが万人に向いている開発プロセスでもないと思います。僕らはペアプロでやりたい人を集めているのでうまくいくけれど、本人が無理だと思っているならうまくいかないだろうと思います。ただ、ユーザベースに来た人でも前職でペアプロの経験がある人はほとんどいません。初めて取り組む人ばかりですが、皆やれていますね。
2016年に異業種から転職してソフトウェアエンジニアとして働き始め、小売の基幹システムの受託開発、内製開発を経験後、2021年にユーザベースに入社。スピーダの開発を担当。
ペアによる効果はプログラミングの領域にとどまらない
── これまで社内で活用してきたガイドラインを公開される意図は何でしょうか？
林 自分たちとしては「いいものができた」という自負はあったものの、自社のコンテキストを前提としているので、これまで公開は控えていました。今回、少し形を整えて公開します。僕たちのプロダクトチームに最適化されたガイドラインですが、オープンソースなので皆さんの組織やチームに適した形に変えて役立ててもらえるとうれしいです。
中嶋 とくに「はじめに」を読んでもらいたいですね。ここには私たちがやっているペアプロの本質が端的にまとめられています。先ほども話した「2人でやることで1+1が3になる」とか、ドライバーとナビゲーターの役割が固定されず頻繁に入れ替わるのが良いとか、そういうことが書かれています。ここを読んで共感してもらえるようなら、その後も読む価値があると思います。
二木 私は入社したときに林さんからペアプロについてレクチャーを受けました。ガイドラインにはその全てが書かれているので、読むことで誰でも同じ体験ができます。ガイドライン策定に携わった皆で、いい仕事ができたと思います。
── 最後にお聞きしますが、ペアプロの良さとは何でしょうか？
中嶋 自分だけでは考えられないような設計が出てくるのが一番の良さだと思います。「ペアプロは楽しいです」という一言につきますね。コラボレーションが好きなら絶対に合うので、試してみてほしいと思います。
二木 ペアプロによって大きく成長できました。ユーザベースに入る前は自分1人で力をつけなければならないという思考だったのですが、ペアプロしてみると相手には自分にないスキルが必ずあり、新しい学びを自然と得ることができます。学ぶ機会に飢えている人、学ぶことが好きな人にとって、ペアプロは最高だと思います。
林 ペアでやることによって効果が生まれるのは、プログラミングの領域だけにとどまらないのではと感じています。僕が代表取締役を務めているUB Datatechでは、データ組成をペアで行う取り組みを始めて好評を得ています。ペアプロを通じて、ペアでやることの可能性に気づけたのはよかったと思います。
── ペアプロの考え方が広く理解されるといいですね。お話をありがとうございました。
取材・構成：森嶋 良子（@morishima）
撮影：小野 奈那子（nanakoono_）
編集・制作：はてな編集部
- ローリー・ウィリアムズ、ロバート・ケスラー 著、テクノロジックアート 訳『ペアプログラミング: エンジニアとしての指南書』（2003年、ピアソン・エデュケーション）/ Robert Williams, Laurie Kessler "Pair Programming Illuminated" (2002, Addison-Wesley Professional)↩
