LESSON 40分

ストーリー

あなた
佐々木さんのPRをレビューしたんですが、根本的な設計アプローチが違っていて…レビューで大量のコメントを書くのが心苦しいです
あ
高
高橋アーキテクト
それなら、次はペアプロで一緒に書いてみないか？レビューは”完成品”に対するフィードバックだが、ペアプロは”プロセス”を共有する。設計の考え方そのものを伝えられる
あなた
でも、ペアプロって効率が悪くないですか？　2人で1つのことをやるわけですし
あ
高
高橋アーキテクト
短期的には遅く見えることがある。でも、手戻りが減り、知識の共有が進み、長期的にはチーム全体の生産性が上がる。何より、“なぜそう考えるか”をリアルタイムで伝えられる。これはレビューでは得られない価値だ

ペアプログラミングの基本

interface PairProgramming {
  roles: {
    driver: "キーボードを操作し、コードを書く";
    navigator: "全体を見渡し、方向性を提案する";
  };
  rotation: "15-30分ごとに役割を交代";
  bestFor: string[];
  notIdealFor: string[];
}

const pairProgramming: PairProgramming = {
  roles: {
    driver: "キーボードを操作し、コードを書く",
    navigator: "全体を見渡し、方向性を提案する",
  },
  rotation: "15-30分ごとに役割を交代",
  bestFor: [
    "新しい技術の導入時",
    "複雑な問題の解決",
    "ジュニアメンバーのオンボーディング",
    "重要な機能の設計・実装",
    "バグの原因調査",
  ],
  notIdealFor: [
    "単純な定型作業",
    "一人で集中したい調査作業",
    "細かなUIの調整",
  ],
};

ペアプロのスタイル

スタイル説明適した場面
Expert-Novice経験者が教えながら進めるオンボーディング、新技術の導入
Ping-Pongテストと実装を交互に書くTDD の実践、設計の議論
Strong-StyleNavigatorが指示し、Driverが実装知識移転、設計方針の共有
Unstructured自由に役割を切り替える同レベルのペア、探索的な作業
## Strong-Style ペアプロのルール

「コードを書くには、まず相手に説明しなければならない」

### Navigator（ベテラン側）
- 設計の意図を言葉で説明する
- 具体的なコードではなく、方向性を伝える
- 「UserServiceに認証ロジックを追加するのではなく、
   AuthServiceを新しく作ろう」

### Driver（学習者側）
- Navigatorの意図を理解してコードに落とす
- 分からない場合は質問する
- 自分の理解を確認しながら進める

モブプログラミング

interface MobProgramming {
  participants: number;  // 3-6人が最適
  roles: {
    driver: "キーボードを操作。自分で考えずにナビゲーターの指示に従う";
    navigators: "全員で議論し、方向性を決める";
  };
  rotation: "10-15分ごとにDriverを交代";
  facilitator: "テクニカルリードがファシリテーション";
}

const mobBestPractices = {
  preparation: [
    "解くべき問題を事前に共有する",
    "開発環境を大画面に表示する",
    "タイマーを設定する（10-15分）",
  ],
  during: [
    "全員が発言できるよう促す",
    "1つのアイデアを試してから次に移る",
    "休憩を忘れない（1時間ごとに10分）",
  ],
  after: [
    "振り返り: 何が良かったか、何を改善するか",
    "学びの共有: 新しく知ったことを記録",
    "次回のテーマを決める",
  ],
};

ペアプロ・モブプロの導入戦略

いきなりチーム全体に導入するのではなく、段階的に広げます。

## Phase 1: 種まき（1-2週間）
- テクニカルリード + ジュニア のペアプロを週2回
- 1回30-60分に限定
- 複雑なバグ修正や新機能の設計がテーマ

## Phase 2: 広げる（3-4週間）
- 週1回のモブプロを開始（1-2時間）
- ペアの組み合わせを変えていく
- 効果を数値で測定（手戻り率、PR修正回数）

## Phase 3: 定着（2ヶ月目以降）
- チーム主導でペア/モブの場面を選択
- オンボーディングにペアプロを標準化
- ふりかえりで継続的に改善

リモートでのペアプロ・モブプロ

ツール用途
VS Code Live Shareリアルタイム共同編集
Tuple / Pop画面共有 + リモートコントロール
Discord / Zoom音声通話
Miro / FigJam設計の議論やホワイトボード
## リモートペアプロのコツ
- カメラONを推奨（表情が見えると安心感がある）
- 休憩を多めに取る（対面より疲れやすい）
- 音声が途切れたらテキストチャットで補完
- 画面の解像度に注意（文字サイズを大きめに）

まとめ

ポイント内容
ペアプロDriver + Navigatorの2名で進める
モブプロ3-6名で1つの画面を共有して進める
スタイルExpert-Novice、Ping-Pong、Strong-Style
導入戦略小さく始めて段階的に広げる

チェックリスト

  • ペアプロの役割（Driver/Navigator）を説明できる
  • 4つのスタイルの使い分けを理解した
  • モブプロの進め方を把握した
  • 導入戦略の段階的アプローチを学んだ

次のステップへ

次は「心理的安全性と学習する組織」を学びます。ペアプロやメンタリングが機能するための土台となる、チームの心理的安全性について掘り下げましょう。

推定読了時間: 40分