はじめに
「開発でチャレンジして、失敗・成功したことをシェアしよう by 転職ドラフト Advent Caledar 2024」用の記事として、ペアプログラミングについての知見共有をします。
ペアプログラミングとは？
ペアプログラミング(以下ペアプロ)は、1台のコンピュータを2人で共有しながらプログラムを作成する手法です。
役割を分担して作業することで、効率的かつ効果的な開発を目指します。
| 役割 | 内容 |
|---|---|
| ドライバー | 実際にコードを書き、プログラムの詳細な実装に集中します。 |
| ナビゲーター | コードのレビューや設計の全体像を考え、方向性を示します。 |
ペアプロの目的
ペアプロの目的として、一般的に以下のようなものが挙げられます。
-
開発パフォーマンスの向上
- 個々人で見るとバラつきがちだが、チーム全体で見るとパフォーマンスは向上する
- 経験の浅いメンバーのフォローアップ
- ナレッジの偏り防止
-
品質の向上
- リアルタイムでレビューすることにより品質が上がる
- 集中して作業するため、ミスが減る
-
コミュニケーションの活性化
- 一緒に作業をすることでそれぞれの人となりを知ることができる
- 信頼関係が築かれ、チームワークが向上する
ペアプロのバリエーション
ペアプロにはオーソドックなやり方以外にもいくつかのバリエーションがあります。チームの成熟度や目的に応じて取り入れてみましょう。
プロミスキャスペアリング (Promiscuous Pairing)
毎回ペアや役割を入れ替えるスタイルです。
| 作業 | 1回目 | 2回目 | 3回目 |
|---|---|---|---|
| 作業１ | Aさん × Bさん | Bさん × Cさん | Cさん × Dさん |
| 作業２ | Cさん × Dさん | Dさん × Eさん | Eさん × Fさん |
| 作業３ | Eさん × Fさん | Fさん × Aさん | Aさん × Bさん |
これは難易度が高いため、チームとして成熟しているケースで取り入れることをオススメします。
チーム全体で網羅的に知識共有が必要な場合や、コードの属人性を排除したい場合に有用です。
マイクロペアリング (Micro Pairing)
1回のペアプロの中で頻繁にドライバーとナビゲーター役割を入れ替える方法です。
例えば以下のようなやり方をします。
- Aが失敗するテストを書く
- Bが実装を書いてテストを成功させる
- Bが次のテストを書く
- Aが実装する
モブプログラミング (Mob Programming)
3人以上で集まって全員で意見を出し合って作業を進めていく方法です。
厳密にはペアプロではありませんが、難易度が高い設計や実装など、必要に応じて取り入れると効果的です。
タイムボックス
ペアプロを実施する際は、必ずタイムボックスを区切っておくことが重要です。
可能であれば、何時から実施するかのサイクルも決めておきましょう。
人間が集中できる時間は45〜90分と言われており、これより長い時間実施するのは効果的でありません。
また、1枠実施した後は必ず休憩を入れるようにしましょう。
例：1枠60分 × 1日3回 の場合
| 時間 | 実施内容 |
|---|---|
| 11:00 - 12:00 | ペアプロ1回目 |
| 12:00 - 13:00 | ランチ休憩 |
| 13:00 - 14:00 | ペアプロ2回目 |
| 14:00 - 14:30 | 休憩 + 個人作業 |
| 14:30 - 15:30 | ペアプロ3回目 |
| 15:30 - | 休憩 + 個人作業 |
必要に応じて単発で実施する場合であっても、時間(長さ)は決めておいた方が良い
ペアプロを実施する作業
ペアプロを避けた方が良い作業としては、以下のようなものがあります。
- 内容が明確であり、誰が実施しても品質の差が出にくい作業
- ルーチン作業
上記以外であれば、基本的に実施対象としてOKです。「ペアプログラミング」とは言いつつ、設計等プログラミング以外であっても有用です。
ペアプロを成功させる工夫
ペアプロの導入が上手くいったケースから、いくつか重要だと感じたポイントを以下に記します。
導入時
目的の明確化
ペアプロの目的をチーム全体で共有することが重要です。
なぜやるのか？ 何を達成したいのか？ を明確にします。
例：コードレビュー効率化、知識の共有、新規参画メンバーの立ち上げ、など
ルールの整備
どの方式を採用するのか、ローテーションをどうするのか、など ペアプロの実施要領を決めて文書化し、「目的」と合わせてチーム全体に共有します。
チャットやメールだけでなく、きちんと説明の場を設けた方が良い
実施時
休憩は必ずとる
連続してのペアプロ実施はかなり疲弊するため、間に5分以上は何もしない時間を作りましょう。
個人作業をしてしまいがちではありますが我慢...
タイムボックスは守る
ペアプロ1枠を60分と決めたら、延長はしないこと。
キリが悪いからあと10分だけ...というのはNG!
ナビゲーター役がしっかりとタイムマネジメントを行うのが重要です。
60分の枠であれば、
- 最初の10分で方針決め
- 40分間ペア作業
- 残り10分になった時点で切り上げに入る
といったように、しっかりとドライバーをナビゲートする必要があります。
この辺りの定義も「ルール整備」の段階で明文化しておけると理想的です。
定期的にフィードバックを得る
初日終わった後＋1週間毎 など定期的にメンバーにヒアリングし、フィードバックを得ます。
マンネリ化しないように、やり辛い点やチームに合わない箇所は変えていきましょう。
リモートで実施する場合はツールを活用する
ペアプロは対面での実施が理想ではありますが、リモートでも可能です。(むしろ、リモートの方が個人作業になりがちなので、取り入れるメリットは大きいかもしれません)
その場合は、ツールを活用しましょう。
- Zoom のホワイトボード機能
- Visual Studio Code の Live Share
- Miro や Figma の活用
- など
※詳細は割愛
個人的な感想
これまで何度かペアプロが実施されている現場で参加したり、自身で導入したりしてきました。
その中で感じたのは「ペアプロの効果は実感できているものの、定着は難しい」ということです。
完全には無くならないまでも、定期的な実施は自然消滅するケースが多かったです。 (執筆時点でも定期的な実施はしておらず、「必要に応じて実施する」という頻度に留まっています...)
理由は様々ですが、大きくは以下のようなものがあります。
- チームが置かれている環境に依存する
- 打ち合わせが多い現場だと時間を合わせずらい
- 兼務があると足並みを揃え辛い
- 消耗する
- 集中して作業する分、疲弊する
- 毎日実施とかにすると、どこかで燃え尽きる
- プロジェクトが(それなりに)うまく回っていると必要性を感じにくい
- メンバーそれぞれが自律して作業ができている状況下では必要性を感じにくい
- 必要に駆られないとモチベーションに繋がりにくい
ただ、今回この記事を書いてペアプロのメリットも再認識できました。
定着している現場も少なからずある(はず)なので、持続可能なペアプロの実施を考えてみても良いかも、と感じました。
また何か成果が得られたら、記事にしてみたいと思います。
月1くらいでゆるく開催とかでもやる価値はありそう
最後に
個人の感想はマイナス寄りになってしまいましたが、取り入れてみると "想像していたより効果が実感できる" ことの方が多いはずです。
実施することで得るものは多いので、ぜひ一度試してみてください！
参考リンク
- スクラム現場ガイド
- SCRUM BOOT CAMP THE BOOK