ペアプロのやり方とは？ 工夫から生まれた「実践知」 – Agile Journey

ペアプログラミング（ペアプロ）は、効果的だと分かっていても、開発組織のカルチャーとして根付かせるのは簡単ではありません。

では、ペアプロがほとんど行われていなかった組織で、それが自然に広がり、カルチャーとして息づくまでにはどんな工夫があったのでしょうか。

適切な休憩の取り方、ペアとの事前合意、ふりかえりのタイミング……現場での試行錯誤から生まれた「実践知」を、ネットショップ作成サービス「BASE」のプログラミングをするパンダさんに寄稿いただきました。

自身もベテランエンジニアとのペアプロでCSSへの苦手意識を克服したパンダさん。そのリアルな体験と知見は、ペアプロ文化を組織に根付かせたい全ての人に響くはずです。

はじめに｜ペアプロは心理的安全性を築く

Agile Journeyをご覧の皆さん、こんにちは。BASE株式会社のBASE Departmentでシニアエンジニアを務めている、プログラミングをするパンダ（@Panda_Program）と申します。

私はXP（eXtreme Programming）と出会って以来、開発の現場でペアプロを6年以上実践しています。この記事では、その経験から得た「ペアプロの効果」や「現場での改善例」をお伝えします。

BASE Departmentでは「BASE」の機能開発チームの一つでチームリードを務め、チームが組成されるたびに、「どうすればこのチームでうまく開発を進められるか」ということを考えてきました。いくつかのチームをリードした経験から、信頼関係が構築できているチームは最大限の力を発揮できると考えています。それは、いわゆる心理的安全性がある状態です*1。

心理的安全性のあるチームでは、忌憚（きたん）なく意見を言い合うことができ、その結果、質の高い開発ができるでしょう。ペアプロは、その環境を作るための第一歩なのです。

この背景にあるのがXPの掲げる5つの価値です。これについては、Agile Journeyの過去記事でも紹介されています。

XPの価値として、ケント・ベックは「コミュニケーション」「シンプリシティ」「フィードバック」「勇気（courage）」「リスペクト」の5つを挙げています。これらを目的に実践されるプラクティスの中でも、ペアプログラミングは特になじみ深いものでしょう。

すべてが XP になる ─ エクストリームプログラミングで見える開発風景（セミナーレポート）

実際にペアプロをやってみると、XPの5つの価値の重要性に気付きます。この価値を理解したチームは、おのずから心理的安全性のあるチームになり、質の高いチーム開発ができるようになるのです。

ペアプロは、価値を体験すれば自然に広がる

BASEでは、最初からペアプロが普及していたわけではありません。私が入社した 2021年当時は、コロナ禍だったこともあり、フルリモートでした。前職で半年以上ペアプロを実践し、その効果を体験していた私は、「この状況でもペアプロを広めたい」と考えていました。

新チームに配属されたことを機に、4名のエンジニアに「ぜひペアプロをやりたい」と提案すると、全員が前向きに受け入れてくれました。

最初はペアプロになじみのないメンバーもいましたが、続けるうちにその良さを実感し、チーム解散後も新しいチームで自発的に取り入れるようになりました。

「ペアプロはいいものだ」と一度でもその価値を体験してもらえれば、組織内で広まるのにそれほど時間はかからない――そう学んだのです。

チームの状況に合わせた柔軟なペアプロ運用

ペアプロのやり方は、チームやペアによって異なります。実際のところ「これをやればどんなペアでも絶対にうまくいく」という方法はありません。書籍やネットの記事を読んだり、いくつかのチームでペアプロを実践したりした結果、最適だと感じるやり方は人によって異なると分かりました。

そのため、具体的な方法はあえて決めておらず、各チーム・各メンバーの構成やスキルレベル、習熟度に応じて柔軟に選択しています。

例えば「リアルタイムで会話をしながら進める」「即時コードレビューをする」といったペアプロのエッセンスは共通ですが、使用ツールとしてGather、Google Meet、Slackのハドルミーティングのどれを使うかは、チームによって自由に決められます。

現在のチームでは、全てのタスクをペアプロで行うわけではありません。ベテランが多く、ソロプロ（一人でのプログラミング）でも意思疎通や品質の確保ができるという信頼があるためです。

一方、積極的にペアプロを採用した方が効果的な場面もあります。例えば次のようなケースです。

• 新メンバーがオンボーディング用タスクを進めるとき
• 一人で進めているタスクで行き詰まったとき
• コードレビューでコメントのやり取りが増えそうなとき
• 変更の影響範囲が広く、見落としがないか不安なとき
• 未知の領域での知識発見や、ベテランからの知識移転が必要なとき

また、ペアプロでは一般的にナビゲーターとドライバーを適宜交代するのが良いとされています。しかし、フルリモートの環境だとペアプロに使うパソコンが1台ではなく、コミットの共有に手間がかかって作業の集中を阻害するケースがあります*2。そこで私のチームでは、1日単位でナビゲーターとドライバーを交代するなどの工夫をしています。

このように、「ペアプロはこうだ」という型にとらわれず、そのときの状況に合った方法を選び続けています。

信頼関係構築、知識共有の促進――ペアプロの効果

次はペアプロの効果をいくつかピックアップします。よく知られていることかもしれませんが、自分の言葉で改めて紹介します。

【効果1】信頼関係の構築と深化

冒頭でも述べたように、ペアプロの最大の効果はペア同士の信頼関係の構築だと私は考えています。

心理的安全性があるチームは言いにくいことも言い合えたり、また質問しにくいこともあえて質問できるチームです。ペアプロはもともと信頼関係があるメンバー同士で効果を発揮するだけではなく、新たに関係を構築していくメンバーの間でも有効です。

自分にない良さを持っている尊敬できる相手と効率的に作業を進められた、という達成感を二人で得ることができれば、信頼関係はより強くなります。チームで信頼関係が構築できれば、ソロワークであっても以前よりうまく進みます。

例えば、チームメンバーがソロワークで書いたコードのレビューを自分が担当するときでも、コードを書いている相手のことを十分に理解できていれば、「指摘するべきか迷う」ということが減っていきます。これを言ったら仲が悪くなるんじゃないか、気分を害さないか、など変に気を使う場面が大幅に減るからです。

結果として、「コードの質を保つためにここはコメントしておこう」という判断が生まれ、ソフトウェアの品質も保てるようになり、開発自体の質が向上すると感じています。

余談ですが、ケント・ベック（XPの考案者）はウォード・カニンガム（wikiの考案者であり、「技術的負債」という概念の生みの親）という仲のいい同僚とペアプロを始めました。年の差は10以上も離れていますが、互いに尊敬しあえる関係であったそうです。ペアプロの考案者である彼らも、ペアプロを通して互いの信頼関係がさらに強固になったことは、想像に難くありません。

【効果2】不安の軽減

ペアと一緒に作業を進めていると、「自分が仕様を理解しきれていないかもしれない」とか「コードの書き方がまずくないか」「後から誰かに指摘されるんじゃないか」という不安が軽減されます。コードのレビュワーがすぐそこにいるからです。

仕様があいまいなまま進める場面でも、その場でペアが疑問点を拾い上げてくれたり、必要に応じてプロダクトオーナーに確認してくれたりします。一人で抱え込むよりも早く不安が解消され、安心して作業を進められます。

【効果3】知識共有の促進

ペアプロでは知識の共有もスムーズに実現できます。

仕様やドメインに対する理解、クリーンなコードの書き方について、自分は知らないけれど相手が知っているのであれば、それを教えてもらいながら進められます。その逆も同じで、自分が相手に教えることも少なくないでしょう。そして、相手が学習する姿勢を見ると教える側も学べることがあります。質問があれば即座に聞いたり答えたりも可能です。

こうした双方向的なやり取りは、ドキュメントや一方的な口頭の説明という単方向の情報伝達よりも記憶に残りやすく、チームの中で知識移転が自然と行われ、チーム全体で対応できる範囲が広がります。加えて、同じコードを見ながら作業することで良いコードと悪いコードの認識が揃いやすくなります。

【効果4】後回しの防止

現場目線では、「後回しがなくなる」のもペアプロの効果の一つでしょう。

作業をしているとコードの深掘りが必要な場面や面倒な調査、腰の重い負債解消など一人だと「ちょっと……」と思うこともあるでしょう。しかし、ペアでなら「大変だけどこのままやり切りましょう！」のような自然な声かけができるようになり、後回しがなくなるのです。

【事例】ベテランとのペアプロで消えた、CSSへの苦手意識

信頼関係、不安の軽減、知識共有――これら全てを私が実感した出来事があります。

実は、私はCSSに苦手意識を持っていました。あるときフロントエンドで広範囲にわたる負債解消を行うことになり、10年以上フロントエンドで活躍しているベテランエンジニアの方とペアを組むことになりました。

その方は、CSSのコードをスラスラと書くことができたため、まるで何でも思った通りにブラウザが画面を描画してくれるかのようでした。まるで頭の中にCSSのエミュレーターがあるようだと私は驚いたものです。私は「どうしてそんなにCSSが得意なんですか」と尋ねました。

「自分もCSSは得意じゃないですよ。でも、CSSのコードを読んで、どう描画されるか分からないときは、必ずJSFiddleなどのツールを使って最小限の再現コードを書いて挙動を確認しています。

それから、ネットサーフィン中に気になるデザインを見つけたら、開発者ツールでCSSを確認したり、同じく最小限の環境で再現して実現方法を確かめたりしていますね」

「最小限のコード」といえども、毎回ツール上で再現して確認するのは大変です。この方は社内でもフロントエンド分野で“デキる方”だと評判だったのですが、その実力は小さな実験の積み重ねに裏打ちされている――そう気付くと、その人に対する信頼と尊敬がさらに増しました。

今では自分もこの方の手法をまねしています。ツール上で再現するコードを毎回書くのは確かに面倒だけれど、あの人がやっているのだから……と後回しにすることなく、教えてもらったことを自分も実践しています。

するとCSSに対する漠然とした不安と苦手意識がなくなりました。小さい環境でCSSの実験をしているとCSSのルールが一つ一つ理解でき、一つの画面や少し複雑なUIを作成するといってもそれらルールの組み合わせで構築できるのだと腑落ちしたからです。それ以来、別の人が書いたCSSのコードのレビューをしてもコメントできる内容が増え、指摘も鋭くなったと実感しています。

この方とのペアプロがなければ、私はフロントエンドの開発者としてさらに成長する機会を得られなかったでしょう。

ペアプロの負荷を下げる工夫

ペアプロは集中力を要するため、心身の負荷が高い側面もあります。しかし、いくつかの工夫を取り入れれば、その負荷を大きく下げ、持続可能な活動にすることができます。ここでは私が取り入れている3つの工夫を紹介します。

【体力的負荷の軽減】「休憩」が持続可能にする

まずは体への負担を軽くする工夫です。ペアプロは高い集中力が求められるため、つい夢中になって休憩を忘れがちです。ペアプロを無理なく続けるために「休憩」を必ず組み込むようにしています。

私のチームでは、タスクに詰まったとき「どなたか一緒に見てもらえませんか」とSlackでメンバーにメンションを送り、そのままハドルミーティングで気軽にペアプロを始めています。

1時間程度で終わるようなタスクなら問題ありませんが、1～2日かかるようなタスクでは注意が必要です。タスクが終わるまで続けてしまい、休憩を取りづらい空気が生まれがちだからです。

そこで私は、「ポモドーロ・テクニック」を採用しています。1単位を30分とし、そのタイムボックスの中で25分間は作業を進め、5分間は休憩するという有名な手法です。

また、体力的な負荷を抑えるため、ペアプロを14～19時までに制限しています。慣れないうちは、1日の終わりには頭が働かなくなり、ぐったりしてしまうこともあるので、就業時間が19時までの場合、その1時間前の18時には切り上げるなど、無理なく終えられるようにしています。

それでも疲労感は残るため、完全な解決策はないかもしれません。特にリモート環境下では相手の疲労具合も見えづらいため、「疲れたときはお互いに休憩の声かけを積極的にする」という合意をしておくと安心です。

体力的な負荷への対策が整ったら、次は精神的な負荷を軽減する工夫です。

【精神的負荷の軽減】開始前の「設計」が重要

休憩によって体力的な負荷はある程度抑えられますが、ペアプロでは別の側面――「精神的な負荷」も避けられません。

これは、二人で進めることで生じる認識や進め方のズレに起因します。自分のやり方だけで進められないことや、スキル差、常に見られている状況が負担になることもあります。

こうした負荷を軽減するには、作業開始前に「どこからどこまで進めるか」「どのように進めるか」を話し合い、合意しておくのが大事です。

つまり、作業の進め方を前もって二人で設計するのです。最初の10分ほどをこの時間に充てても良いでしょう。

この時間を設けずに進めて手戻りが発生すると、精神的なダメージは大きくなってしまいます。負担を減らし、作業を円滑に進めるためにも、開始前の合意は欠かせません。

【継続的な改善】「ふりかえり」を実施する3つのタイミング

ペアプロを実施すると必ず課題が出てきます。これを解消するために、ペアやチームで定期的にふりかえりを行いましょう。おすすめのタイミングは次の3つです。

• 【1】ポモドーロ・テクニックの作業時間（25分）終了後

直前のタイムボックスで実施した作業をふりかえり、より良く進められる方法はないかを二人で話し合います。アイデアを思いついたら、次の25分ですぐに試しましょう。しっかり前進しているという実感が得られるはずです。

その日に出た課題と向き合い、明日はどうすればその課題が解決できるか、どうやり方を変えればいいのかを話し合います。

すると、「今日はしんどかったな、明日もしんどいんだろうな」という後ろ向きな気持ちではなく、「また新しいことを試そう」「きっとうまくいくだろう」とポジティブな気持ちで仕事を終えられます。ペアで解決できない場合は、翌日のデイリーでチームに相談すると良いでしょう。

• 【3】スプリントの終わり

ペアの課題をチーム全体に共有し、他のメンバーからアドバイスをもらいます。誰かが過去に同じ課題を経験していて、すでに解決策を知っているかもしれません。

ちなみにケント・ベックはCIの待ち時間にコーヒーを飲みながらペアプロの相手とふりかえりを実践していたそうです。何か区切りを見つけてすぐにふりかえりを行うのが最も効率的です。

ふりかえりで課題が出ることはマイナスばかりではありません。ペアで課題に対する解決策を考え、それが実際に機能するとペアプロの習熟度がアップします。

このように改善を繰り返して成果を出すことでペア相手に対する信頼が深まり、「ペアプロをやっていて良かった」「別の人ともまたぜひやろう」と考える人が増え、開発組織のカルチャー醸成にもつながります。

対話でアンチパターンを避け、組織文化にする

繰り返しになりますが、あるチームでペアプロの達成感を得たメンバーは、他のチームでも「やってみたい」と思うようになります。経験者と未経験者がペアを組めば、ペアプロは社内で自然と伝播していきます。

BASEではペアプロを実施するかどうかはチームごとに自由に選べます。このように、開発者が状況に応じて自発的にソロプロかペアプロを選択できることが重要だと私は考えています。やりたいときにやり、必要がなくなればやめる。そうした柔軟さを持つことで、メンバーがその場その場で最適な開発スタイルを選ぶというしなやかなチームに成長します。

もちろん、ペアプロの方法に正解はありません。しかし、確実に失敗する「不正解」はあります。落とし穴を避けるためにも、ふりかえりや対話を重ねながら、自分たちにとってのベストなペアプロの形を探っていきましょう。

特にふりかえり、対話、コミュニケーションのスキルを高めれば「自分の望むやり方を相手に押し付ける」といったアンチパターンを避けられます。片方が我慢するような形は真の解決策と言えません。やがて「ペアを解消したい」「ペアプロはもう嫌だ」となる前に、課題にしっかり向き合い、双方が納得できる落とし所を探すことが大切です。

こうして信頼関係を築けば、ペアプロは自然と定着し、組織のカルチャーとして広がっていくでしょう。

XPにおけるペアプロの位置付け

最後にXP（eXtreme Programming）の視点からペアプロを捉えてみます。XPは、ケント・ベックが「開発に必要不可欠」と考えるプラクティスをまとめた手法です。

ペアプロは「ペアでコーディングをすること」だと思われがちですが、実際には「コードレビューを極端に考えると、コードは常にレビューされている」という発想から生まれたものです*3。

XPは、計画と実行、そしてコードからのフィードバックを重視しており、この図では、ペアプロは秒単位でコードを変更し、秒単位でフィードバックを得るプラクティスと位置付けられています。

ここでいうフィードバックとは、そのコードは仕様を実現したコードになっているのか、命名は適切か、コードのリファクタリングや整理をした方がいいのか、もっといい設計はあるのだろうか……などです。コードを書くことで、コードに対する新たな課題が見つかることもあります。その場合は一度立ち止まって二人で解決策を考えましょう。

さらにXPでは、ペアプロと同時に、TDDやリファクタリングなどの開発に関するプラクティスを全てそこで実践します。つまり、ペアプロはただ二人でコードを書くことを指しているのではありません。XPの視点から見るとさまざまなプラクティスが一挙に実践される重要な場なのです。

おわりに｜まずは実践から始めよう

本記事ではペアプロの定義や細かな進め方にはあえて深入りしませんでした。

AIが一般論を教えてくれる現代においては、それよりも、現場で起きているペア同士の対話や信頼構築、そして成長といった具体的なエピソードを紹介する方が有意義だと考えたからです。

この記事を読んで、ペアプロに少しでも興味を持ったなら、まずは試してみてください。右も左も分からないという場合は、ユーザベースさんによるペアプロのガイドラインを参考にすると良いでしょう。進める中で問題が出たら、ブログを探して他の人の対処法を参考にするのも有効です。

agilejourney.uzabase.com

全ての課題を自分たちだけで解決する必要はありません。ペアプロの先人たちの知恵を借りてショートカットしましょう。そして、どの記事にも書かれていない固有の課題や、AIでも答えが出せないような問題に直面したときは、しっかり自分たちの頭で考えて対処してみてください。

最後に「開発生産性Conference 2025」に筆者が参加した折に、ケント・ベックから本記事の読者の方々に向けて、ペアプロについてのメッセージを頂くことができましたのでお伝えします。

プログラミングは個人的に満足感を与えてくれます。しかしながら、私たちが自らの潜在能力を最大限に発揮するためには、自分の取り組みを他の人と共有することが必要です。ペアプログラミングは、人とつながり、アイデアを実現する過程で得られる満足感を他の人と分かち合うための最も直接的な手段です。

この記事が、あなたのチームがペアプロを通じて信頼を育み、チーム開発の質をさらに向上させるきっかけになれば幸いです。

編集・制作：はてな編集部