人間のコードレビュー力を鍛えるために。AIコーディング時代の「ペアプロ・モブプロの心得」

• keyboard_arrow_down はじめに
• keyboard_arrow_down AIとの協働の難しさと課題
• keyboard_arrow_down ペアプロ・モブプロを「学習の場」として捉え直す
• keyboard_arrow_down 磨くべきは「何をつくるべきか」「できたものが良いか」を判断する力
• keyboard_arrow_down コラム：誤解を解く――人間もコードを書く意味がある
• keyboard_arrow_down 従来の「ペアプロ・モブプロ」を超越した、新たな協働の場を構築する
• keyboard_arrow_down 「ナビゲーター」「ドライバー」ではなく、人間が担う3つの役割
• keyboard_arrow_down おわりに：学習パターンや役割分担はあくまで仮説の1つ

「AIがコードを書くなら、人間同士でペアプログラミング（ペアプロ）やモブプログラミング（モブプロ）をする意味はまだあるのだろうか」――AIコーディングエージェントが日常のツールとなった今、この問いが現場で広がっています。

本稿の答えは「意味はある」です。

2012年に私が紹介した「ペアプロの心得」（※）は今日まで多くの開発者に読まれ、モブプロの現場でも参考にされてきました。しかし10年以上が経った今、その価値を改めて問い直す必要があります。人間同士のペアプロ・モブプロの価値は変わりませんが、コード生産はAIに任せ、人間は判断力を養うための「学習」に集中することが重要です。これがAI時代の協働を成功させる鍵だと私は考えています。
※「ペアプロの心得」(2012) …筆者が原著者の許可を得て転載した、ペアプログラミングを健全かつ効果的に行うための、心構えと振る舞いのガイドライン

もちろん、AIに適切な指示や仕様を伝えること――いわゆるプロンプトエンジニアリング――は重要です。しかし、それは当然の前提であり、本稿のテーマではありません。適切な指示を書けたとしても、その先にある問いが残ります。AIの出力を評価し、判断を下せる人間をどう育てるか。筆者が本稿で論じたいのは、この問いへの答えです。なお、本稿で言う「学習」とは、座学ではなく、現場で判断できるようになるための実践的な学びを指します。

なお、本稿では、1人でAIを使うソロ開発ではなく、ペアプロやモブプロといった人間同士のチーム作業にAIエージェントを迎えるケースについて論じます。

人間同士で議論しながら学び合うペアプロ・モブプロの価値は、AI時代でも変わりません。しかし、AIをこの枠組みに組み込もうとすると、いくつかの課題が生じます。

課題1：進行が重くなり、待機時間が増える

AIエージェントを導入すると、コードの提案やレビューを待つ時間が生まれます。従来のペアプロでは「15秒の沈黙すら長すぎる」とされてきましたが、AIが処理する間、人間は監督役として待機するしかありません。たとえば、AIが50行のコードを生成する1〜2分間、2人の開発者が画面を見守るだけという状況が生まれます。AIを監督する負荷でレビュー待機が増え、期待した生産性メリットが相殺されるケースは少なくありません。

課題2：AIの「ドライバー」化とコードレビュー機能の低下

「AIが書くなら、自分たちの役割は何なのか」――この問いは、固定ペアのままAI主体へ切り替えたとき、特に強く感じられます。AIがコードを書き、2人の人間がそれを見守る構図になると、実質的に「AI＝ドライバー、人間＝ナビゲーター」という役割の固定化が起きやすくなり、ペアプロの目的はAIが生成したコードのレビューになってしまいます。人間同士のペアプロでは、2人がドライバーとナビゲーターを交代しながら判断を擦り合わせていました。しかしコードの書き手がAI主体になると、人間同士の確認プロセスが発生しにくくなり、よりよいアイデアが生まれにくくなる恐れがあります。

課題3：知識共有の機会が失われ、若いメンバーの学習が停滞する

ドライバー役の人間がコーディングで詰まった際に、AIへの質問で即座に解決できると、議論を省く習慣が根付きます。その結果、スキル伝達が行われず、新しいメンバーが成長機会を失うリスクがあります。厄介なのは、表層的な理解のままでもタスクが進んでしまう点です。ペアプロ・モブプロをこなしながら目の前の仕事を片付けた気になるため、学習の欠如に気づきにくくなります。

これらの課題は、AIを人間と同じ「参加者」としてペアプロ・モブプロに組み込もうとすることに起因しています。人間同士のリアルタイム協働を前提に設計された枠組みに、非同期性と不確実性を持つAIを無理やり押し込もうとすれば、非効率化は避けられません。筆者も幾度となく挑戦していますが、リズムが乱れてしまうことが多く、うまく効果が出せていません。AIを「一緒にコードを書く開発者の1人」として扱うアプローチには限界があるのです。

ここで視点を変えてみましょう。AIは「開発者」ではなく純粋に「ツール」と捉えたとき、ペアプロ・モブプロには何が残るでしょうか？

AI時代には、ペアプロ・モブプロを「学習の場」として捉え直すことが重要です。ペアプロ・モブプロには「コード生産」と「学習」の両面がありますが、従来は「コード生産の場」という文脈で語られがちでした。しかし、学習こそが判断力を養う手段であり、AI時代にはこの側面がより重要になると私は考えています。

AI時代のコーディングには、次のような構造的ジレンマが存在します。

• 1. AIが大半のコーディングを担う
• 2. 人間の実装経験が減少する
• 3. 判断の材料（知識・経験）が蓄積されにくくなる
• 4. AIの出力を適切に評価しづらくなる
• 5. さらにAI依存が深まる（悪循環のリスク）

この悪循環が起きるのは、AIの出力をそのまま受け入れてしまうと、考える機会が失われるからです。だからこそ、判断力を養うための学習を意図的に設計することが望ましいでしょう。

では、このジレンマをどう解くか。鍵となるのは、人間がAIの出力を評価し、そこから学ぶ仕組み です。複数人で議論しながら評価し、判断基準を共有する――これはまさにペアプロ・モブプロで培われてきた方法です。この方法を、AIとの協働という新しい文脈で活かすことが重要ではないでしょうか。

改めてペアプロ・モブプロの目的を振り返ります。本稿ではAI時代に特に重要となる「学習」の側面に焦点を当てます。

• 1. コード品質向上：リアルタイムレビューでバグを減らす
• 2. 知識共有・学習：経験者から学び、暗黙知を伝達する
• 3. 設計判断の質向上：複数の視点で検討し、より良い判断を下す
• 4. 属人化の回避：知識をチーム全体に分散させる

これらの目的を見ると、いずれも「何が良いコードか」「どう設計すべきか」を判断する力を前提としています。品質向上には良し悪しを見分ける目が必要であり、知識共有は判断基準の伝達であり、属人化回避も判断力の分散です。つまり、これらは「判断力を育てる」ことに深く関わっています。

この判断力は、AIには代替しにくい領域です。AIは途中のプロセスで多くの判断を下せますが、何を作るべきか（ゴール設定）と、できたものが良いか（最終評価）は、現時点では人間が担う必要があります。

AIが生産を担う時代だからこそ、人間がこの判断力を意識的に鍛えることが鍵になります。従来はコードを書きながら自然と判断力を養っていました。AIが大半のコードを書く時代には、AIが生成したコードから学ぶという新しい形がありえます。

「AIが大半のコードを書くなら、人間はもう書かなくていい」――これは極論だと私は考えます。人に仕事を依頼するとき、依頼内容を自分が理解していなければ、成果物の良し悪しを判断できません。AIへの依頼も同じです。生産としてのコーディングはAIに委譲できますが、依頼内容を自分自身が理解するためのコーディングは人間がやる意味があります。

自分で問題を十分に理解した上で解決方法について考える。その経験があってはじめて、AIからの提案が適切かどうかを評価できます。例えば「この設計は拡張性に欠ける」と見抜くには、自分で拡張に苦労した経験が大きな助けになります。

ペアプロ・モブプロで培ってきた方法――複数人での議論、判断基準の共有、暗黙知の伝達――をAIとの協働に再構築すると、その形態はもはや従来のペアプロ・モブプロとは呼べないものになるでしょう。ここで紹介するのは、その方法を土台にした新しい協働のあり方です。

「学習の場」としてペアやチームでコードを触る機会を設ける場合、AIとの協働はどのような形になるでしょうか。以下に3つのパターンを示します。

学習パターン1：AIコードの共同レビュー

新人育成やコードベース理解に向いています。

複数人で、AIが生成したコードを一緒にレビューしながら議論します。

• 学習の観点：
• ・「なぜAIはこのアルゴリズムを選んだのか？」
• ・「パフォーマンス特性はどうなっているか？」
• ・「セキュリティリスクはないか？」
• ・「保守性の観点で改善点はないか？」

このプロセスで、新規参入者は熟練者の判断基準を学び、熟練者も自分の暗黙知を言語化する機会を得ます。

学習パターン2：複数選択肢の比較検討

シニア同士の設計判断や意思決定に向いています。

AIが生成した複数の選択肢を各自で検討し、重要な判断ポイントで集まって議論します。

• 学習の観点：
• ・「選択肢AとBのトレードオフは何か？」
• ・「この判断の前提条件は何か？」
• ・「将来の拡張性を考えるとどうか？」
• ・「過去の類似ケースではどう判断したか？」

このモデルでは、意思決定の瞬間に学習が集中します。常時画面を共有する必要はなく、本当に議論すべき時に人間が集まります。

ここでAIの活用が効果的だと言えるのは、従来不可能だった「複数選択肢の実装比較」ができる点です。人間だけでは、選択肢AとBを試すにはどうしても直列に行うことになり、両方を実装して検証するのは現実的ではありませんでした。

一方、AIを活用すれば、AもBも同時に実装し、生成された動くコードを比較して判断できます。「こう実装したらどうなるか」という仮説を、実験として検証できるのです。

この「実物比較による学習」は、AI時代だからこそ可能になった新しい学び方です。トレードオフを頭の中で想像するのではなく、実際に動くコードで体験することで、判断力はより深く育ちます。

学習パターン3：コンテキストの共同設計

ドメインの複雑度が高いチームに向いています。

複数人で、AIにプロンプトとして渡すコンテキスト（背景情報、制約条件、期待する成果）を設計します。

• 学習の観点：
• ・「このコンテキストで本当に重要な制約は何か？」
• ・「AIが見落としているビジネスルールは何か？」
• ・「どう伝えればAIが正確に理解できるか？」

コンテキスト設計自体が、ドメイン理解を深める学習の場となります。

以上の3つの学習パターンを下の図に示します。

これらの学習パターンを継続的に機能させるために、人間は以下の役割を担います。名称は、あくまでもそれぞれの役割を端的に伝えるために筆者が命名・定義したものです。

役割1：ルールをAIに伝える「コンテキスト・キュレーター」

ドメイン知識、組織の制約、過去の意思決定の背景をAIに伝達可能な形に「翻訳」する役割です。この作業自体が、チームのドメイン理解を深める学習プロセスとなります。チームにもたらす成果は、AIに適切に仕事をさせる前提条件を整え、要求の曖昧さを減らすことです。

役割2：トレードオフを見極める「ディシジョン・ゲートキーパー」

AIが提示した選択肢からトレードオフを判断する役割です。「なぜこの選択をしたのか」を言語化し、チーム全体で共有することで、判断基準がナレッジ化されます。チームにもたらす成果は、AIの提示した案から最適なトレードオフを選び、誤った方向への暴走を防ぐことです。

役割3：知見共有を促す「ラーニング・デザイナー」

AI生成物を「なぜそうなったか」を議論の題材に変換し、チーム全体の学習を設計する役割です。対話ログやAIプロンプトを蓄積し、次回の改善案に繋げることで、組織のナレッジ資産を構築します。チームにもたらす成果は、AIに任せた分を人間が学習し続ける仕組みで補い、チームの判断力を維持することです。

以上の3つの役割を下の図に示します。

本稿では、AIを「参加者」ではなく「ツール」として捉え、ペアプロ・モブプロを「学習の場」として再定義することを提案しました。とはいえ、これは一つの視点に過ぎません。AIの進化は速く、今日有効な方法が来年も通用するとは限りません。

確かなのは、AIがコードを書く時代でも、「何を作るべきか」「できたものが良いか」を判断する力は人間に求められ続けるということです。その判断力をどう育てるか――本稿で示した学習パターンや役割分担は、その問いに対する私なりの仮説です。

AIと人間の協働のあり方は、これからも変化し続けるでしょう。

答えはまだ出ていません。私自身も模索を続けています。本稿の考えが、あなたのチームでの議論のきっかけになれば幸いです。