LASSIC Media らしくメディア
ペアプロ・モブプロ導入を外注で支援する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ペアプログラミングとモブプログラミングの定義、ドライバ・ナビゲータの役割分担を一次情報に基づいて整理します。
- 知識移転・属人化解消・オンボーディング短縮といった導入効果と、向く作業・向かない作業の見極め方を解説します。
- 外部コーチ・ファシリテーターへの委託範囲と、内製化に向けた発注側の準備事項を整理します。
目次
ペアプロ・モブプロの定義とドライバ／ナビゲータの役割
ペアプログラミングとは、2人の開発者が1台のコンピュータで共同してコードを書く開発手法である*1。モブプログラミングとは、チームの全員が同じ課題に同じ時間・同じ場所・同じコンピュータで取り組む開発手法を指す*2。いずれも1人で黙々と実装する従来型のスタイルとは異なり、複数人が同じ画面を見ながら考えを声に出して進める点が共通しています。
ペアプログラミングでは役割が2つに分かれます。ThoughtWorksの技術者Birgitta BöckelerとNina Siesseggerが2020年にMartin Fowler氏のサイトで公開した記事によれば、キーボードを操作し実装の細部に集中する担当を「ドライバ」、コードをリアルタイムで確認しながら大局的な視点で次のステップや障害を指摘する担当を「ナビゲータ」と呼びます*1。同記事では、この作業は単なる分担作業ではなく「計画を立て、仕事を議論し、アイデアを明確にし、アプローチを検討して、より良い解決策に到達する」協調的なプロセスだと説明されています*1。
モブプログラミングはこの発想をチーム単位に広げたものです。手法を体系化したWoody Zuill氏らが運営するmobprogramming.orgでは、モブプログラミングを「優れた人材全員が、同じ課題に、同じ時間に、同じ場所で、同じコンピュータで取り組む」ことと定義しています*2。実践では1台のPCに対して複数人が交代でキーボードを操作し、他のメンバーは画面を見ながら意見を出す形が一般的です。
導入で期待できる効果と生じやすい誤解
ペアプログラミングとは、2人が1台のコンピュータで共同してコードを書き、知識共有とレビューを同時に行う開発手法である。前掲のBöckeler・Siessegger氏の記事は、この手法の効果として「チーム全体でテクノロジーとドメイン知識を日常的に広げ、知識サイロを防ぐ」点を挙げています*1。1人が持つ業務知識や実装の背景が特定の担当者だけに留まる状態、いわゆる属人化を防ぐ働きがあるということです。
レビュー機能についても同記事は「4つの目で小さいことから大きなことまで見守り、より多くのエラーが実装段階で発見される」と述べています*1。コードを書いた直後に別の視点でチェックが入るため、後工程のレビューで差し戻される手間を減らせるという整理です。新規メンバーの立ち上がりに関しても、同記事は「新規メンバーがプロジェクト・ビジネス・組織を効果的に学習できる」ことをオンボーディングの利点として挙げています*1。
モブプログラミングでは、mobprogramming.orgが「質問への即時回答によるメール依存の削減」「集団での判断による意思決定の質向上」「複数の目による継続的な監視で重複コードや技術的負債を発見しやすくなる」といった効果を挙げています*2。個人の判断ではなく、その場にいる全員の合意で進む点が特徴です。
一方で生じやすい誤解もあります。ペアプロ・モブプロは「すべての作業を常時この形式で行うべきだ」という手法ではありません。両手法とも、状況や作業内容に応じて使う場面を選ぶ実践として紹介されており、常時実施を前提とした定義ではない点は導入前に理解しておく必要があります*1*2。
向く作業と向かない作業の見極め方
ペアプロ・モブプロの効果は、知識移転やレビューの質向上に集約されます。したがって、複数人の関与が価値を生みやすい作業ほど適性が高いといえます。具体的には、複雑な設計判断を伴う実装、属人化リスクの高いコア機能の改修、新規メンバーが初めて触るモジュールの引き継ぎなどが該当します。
反対に、定型的で判断の分岐が少ない単純作業、あるいは個人の集中を要する調査・検証作業では、複数人が同時に関与する必要性が薄くなります。前掲の一次情報でも、常時この形式で作業することを求めているわけではなく、場面を選んで活用する実践として紹介されています*1*2。この見極めを誤ると、単純作業にまで人数をかけてしまい、チームの生産性の実感が下がる要因になります。
導入初期は、属人化が特に懸念される機能やオンボーディング対象のタスクなど、効果が明確に見込める領域から始めると、チーム内の納得感を得やすくなります。
社内導入の進め方——時間の区切り方とローテーション
ペアプロ・モブプロを社内に定着させる際は、最初から終日実施を目指すのではなく、時間を区切って試行することが実務上の起点になります。1回のセッションを短時間に設定し、その中でドライバとナビゲータ、あるいはモブでのキーボード担当を交代する「ローテーション」を組み込むことで、参加者全員が実装とレビューの両方の視点を経験できます。
ローテーションの頻度や役割交代のタイミングは、チームの慣れの度合いによって調整が必要です。導入直後は交代の間隔を短くして手法自体に慣れることを優先し、慣れてきた段階で扱う課題の難易度を上げていく進め方が、無理のない定着に近づきます。
また、振り返りの機会を設けることも欠かせません。セッションの終わりに「何がうまくいったか」「次回何を変えるか」を短く共有する場を持つことで、手法自体の改善サイクルが生まれます。
リモート環境でのペアプロ・モブプロの実践
リモートワーク環境では、1台の物理コンピュータを複数人で操作する前提が成立しません。そのため、画面共有機能を備えたビデオ会議ツールや、複数人が同時にカーソルを操作できるオンラインエディタ・IDEの共同編集機能を使って、同じコードベースを見ながら会話する形に置き換えるのが一般的な工夫です。
リモートでの実践では、対面時よりも会話の間（ま）が生まれやすく、ドライバが黙って作業する時間が長くなりがちです。ナビゲータ役が意識的に発言し、考えていることを言語化する運用ルールを設けることで、対面時に近い協調の質を保ちやすくなります。通信環境やツールの操作性がボトルネックになる場合もあるため、事前に接続確認を行っておくことも実務上の留意点です。
コスト懸念とどう向き合うか
ペアプロ・モブプロに対してよく挙がる懸念は、「2人以上が1つの作業に同時に関与するため、1人当たりの生産量が下がるのではないか」というものです。この懸念は、単純な作業時間の投入量だけを見た場合には成立し得る指摘です。
一方で、前掲の一次情報が示す効果は、実装段階でのエラー早期発見によるレビュー工数の削減、属人化解消による将来の保守コスト低減、オンボーディング期間の短縮といった、実装直後の時間だけでは測れない領域に及びます*1*2。したがって、コストを検討する際は「今この瞬間の実装速度」だけでなく、「後工程の修正・引き継ぎコストがどう変わるか」を合わせて評価する視点が必要です。
実際にどの程度の投入時間が見合うかは、対象業務の複雑さやチームの成熟度によって異なります。断定的な削減率を示す一次情報は確認できていないため、本記事では具体的な数値を示さず、費用対効果は自社の対象業務に応じて個別に検証すべき事項として整理します。
外部コーチ・ファシリテーターへの委託範囲
ペアプロ・モブプロは、社内に実践経験のあるメンバーがいない状態から独学で始めると、役割分担やローテーションの運用が定着せず、形だけの実施になりやすい取り組みです。この立ち上げ期を外部の支援者に委ねる選択肢があります。
委託範囲として想定されるのは、大きく3つです。第一に、初期セッションでのファシリテーション（進行支援）です。ドライバ・ナビゲータの交代タイミングや議論の進め方を、実践に慣れた立場から場に合わせて調整します。第二に、チームへの伴走です。数回のセッションに同席し、チームの実装内容やコミュニケーションの様子を見ながら、運用ルールの調整を助言します。第三に、内製化への移行支援です。外部支援者が主導する期間から、チーム内のメンバーがファシリテーター役を担う期間へと、段階的に役割を引き渡す設計を一緒に組み立てます。
委託の際は、これら3つのどこまでを依頼するかを事前に明確にしておくことが重要です。ファシリテーションのみを短期で依頼するのか、内製化までの伴走を含めた期間で依頼するのかによって、必要な体制と期間の見通しが変わります。
委託を内製化に移行するための発注側準備
外部コーチ・ファシリテーターへの委託を内製化につなげるには、発注側にも準備が必要です。まず、対象とするチームとタスクの範囲を絵に描けるレベルまで具体化しておくことです。「どの機能の、どの作業を対象に、誰が参加するのか」が曖昧なまま委託を開始すると、支援者側も進行の設計がしづらくなります。
次に、セッションの記録・振り返りを残す担当を社内で決めておくことです。外部支援者がいる間に得られた気づきや運用ルールの調整点を記録しておかないと、支援終了後に同じ試行錯誤を繰り返すことになります。
最後に、内製化後にファシリテーター役を担うメンバーを早い段階から決めておくことです。委託期間の終盤だけで役割を引き継ぐのではなく、初期セッションから当該メンバーに意識的に関与してもらうことで、引き継ぎ後の運用が滑らかになります。
ペアプロ・モブプロの導入には、社内で実践経験のあるメンバーの確保、ファシリテーションのスキル、チームの合意形成といった要素が必要です*1*2。これらをゼロから内製で揃えるには相応の試行期間を要するため、外部支援を活用しながら段階的に内製化する進め方が、実務上の選択肢の一つになります。
まとめ：ペアプロ・モブプロ導入を判断する3つの軸
本稿では、ペアプログラミング・モブプログラミングの定義と役割分担、導入効果と誤解、外部委託の範囲を整理しました。要点を3つに集約すると次の通りです。第一に、両手法は常時実施を前提とせず、属人化解消やオンボーディングなど効果が見込める作業を選んで使う実践です。第二に、コストは実装直後の時間だけでなく、後工程のレビュー・引き継ぎコストまで含めて評価する必要があります。第三に、外部コーチへの委託はファシリテーション・伴走・内製化支援の3段階に分けて範囲を定めると、社内への定着がしやすくなります。
よくある質問
ペアプログラミングとモブプログラミングは何が違いますか。
ペアプログラミングは2人で1台のコンピュータを使い、ドライバとナビゲータに役割を分けて進める手法です*1。モブプログラミングはチーム全員が同じ課題に同じ場所・同じコンピュータで取り組む手法で、参加人数がチーム規模に広がる点が異なります*2。
常にペアやモブで作業する必要がありますか。
常時実施が前提の手法ではありません。属人化のリスクが高い作業やオンボーディング対象のタスクなど、複数人の関与が価値を生みやすい場面を選んで活用するのが実務上の進め方です。
リモートワークでも導入できますか。
画面共有機能を備えたビデオ会議ツールや、複数人が同時に操作できるオンラインエディタの共同編集機能を使うことで実践できます。対面時より会話が減りやすいため、ナビゲータ役が意識的に発言する運用ルールを設けることが有効です。
外部コーチにはどこまで依頼できますか。
初期セッションのファシリテーション、チームへの伴走、内製化への移行支援の3段階が主な委託範囲です。短期のファシリテーションのみか、内製化までの伴走を含めるかで、必要な体制と期間が変わります。
導入効果はどのように測ればよいですか。
実装直後の作業速度だけでなく、後工程のレビュー工数の変化や、属人化解消による引き継ぎコストの変化まで含めて評価する視点が必要です。断定的な削減率を示す一次情報は確認できていないため、自社の対象業務に応じて個別に検証することが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Birgitta Böckeler, Nina Siessegger「On Pair Programming」ThoughtWorks・Martin Fowler氏サイト掲載（2020年）
- *2 出典：Woody Zuill ほか「Mob Programming」mobprogramming.org
