ペアプロの価値はコードを書くことだけじゃない

Transcript

1. XP祭り 2026 ペアプロの価値はコードを書くことだけじゃない 生成AI時代のペアプロ アプローチ再考 株式会社コドモン プロダクト開発部 友野 敬大 2026年09月05日
2. じゃない 2
3. 話す人 友野 敬大 ともの あきひろ 金融系SIer、シリーズAスタートアップを経て、2025年コドモン。 エンジニア 兼 エンジニアリングマネージャー。 好きなものは、型システムと柄シャツとワイン。現職までXPは未経験。 所属 株式会社コドモン 「子どもを取り巻く環境をテクノロジーの力でよりよいものに」を ミッションに持つ保育・教育施設向けSaaSベンダー。 2021年ごろからXP導入。1日のうち、6〜7割ペアプロで開発。
4. アジェンダ - ペアプロの価値はコードを書くことだけじゃない • はじめに • ペアプロの価値を最大化するためのAI駆動開発ワークフローの紹介 • 会話を増やすために効いたアプローチ • 実践後の発見と伸びしろ • まとめ 4
5. はじめに 5
6. 生成AI活用してますか？ 6
7. ペアプロで 生成AI活用してますか？ 7
8. 思い返すこと1年前 8
9. 生成AI活用で開発スピードは明確に上がった • ソロで生成AI活用を試してみる ◦ 保育施設（テナント）のオプション設定API ▪ ◦ PJで実績のないAWSサービスを使った開発 2,3日かかる見積もりが、0.5日で完了 • コードの生成だけ見るとペアプロでやる必要が ないかもしれない ◦ ◦ 早くできる感覚 → ”ペアをソロに” の モチベーション でも、それでいいのか？ アウトプット量は 間違いなく増える…！ 9
10. 人間が理解する速度は上がっていない • その時々の意思決定の説明が必要 ◦ ◦ 「テストどうするの？」「ローカルでの開発は？」 レビューを含め、ソロで完結する仕事はない • PR初見のメンバーには巨大Diffに よる高い認知負荷を強いる ◦ ◦ 理解を諦めるリスクすらある 実装コストが減る一方、説明 コストは増すばかり 10
11. before 生成AI：人間たちは会話をしていた • ペアプロの中心には会話がある ◦ 受入条件とスコープの確認 ◦ どうやって進めていくかの方針決め ◦ やるべきタスクの洗い出し ◦ タスクごとの実装（TDD） ◦ ペア交代時の引き継ぎ • ソロ × 生成AIには会話がない ◦ ペアプロは会話を通じて、小さく進めることで理解を深めていた 11
12. 今日言いたいこと ペアプロの価値は コードを書くことだけじゃない 12
13. ペアプロの価値はコードを書くことだけじゃない • ペアプロは ◦ △: 2人で1つの画面を見て一緒にコードを書く ◦ ◯: なぜその設計なのかを会話・合意しながら実装を進める ペアプロの価値は、 実装がAIに移るほど、会話と合意形成に集約される 13
14. プロジェクトでの検証・再認識した価値として紹介 • 生成AI時代でもペアプロの価値を最大化するアプローチのひとつの例 ◦ 会話と意思決定機会を増やすため、合意を記録する ◦ 10ヶ月ほどのプロジェクトでの検証・再認識した価値として紹介 • GitHub IssueとClaudeのコマンド／スキルの組み合わせだが、同様 の機能があればツールは問わない 14
15. ペアプロの価値を最大化するための AI駆動開発ワークフローの紹介 15
16. AIと、人間のための仕様駆動開発 • 合意するには言語化が必要 ◦ 何を作るのか、なぜその設計なのか ◦ AIにこれらの文脈を渡す = 仕様駆動開発 ◦ 人間同士のペアプロは自然にやっていた • 仮説：仕様駆動開発とペアプロは相性が良いのでは ◦ ペアでのフェーズ毎に情報を更新していくためにIssueを使う ▪ もともとIssue中心に開発する文化があった ▪ AIに合わせて働き方を変えるのではなく、従来の働き方に AIを迎え入れた 16
17. ペアのための仕様駆動開発ワークフロー • giro = GitHub Issue based Kiro ◦ ◦ ◦ IssueとClaudeのコマンド／スキルの組み合わせ AIのアイデアを元に、ペアの会話・合意形成を促進するワークフロー Issue本文には現在の状態、コメントには意思決定を追跡可能な情報 <<Command>> <<Command>> <<Command>> <<Command>> /plan /tasks /impl /approve <<Issue>> 概要 受入条件 タスクリスト <<Issue comments>> 設計方針 意思決定ログ Q&Aサマリー 17
18. /plan: 設計方針の合意と意思決定ログによる記録 AIがやること • • • • ペアがやること 概要・受入条件の確認 既存コードの調査 ロバストネス分析によるイン タフェース設計 採用案／他候補と理由の記録 • AIによる設計方針のレビュー ◦ ◦ ◦ • 変更対象ファイル インタフェース定義 テストパターン 採用しない案まで確認する <<Command>> <<Command>> <<Command>> <<Command>> /plan /tasks /impl /approve <<Issue>> 概要 受入条件 タスクリスト <<Issue comments>> 設計方針 意思決定ログ Q&Aサマリー 18
19. /tasks: タスク順序と粒度の合意 AIがやること • ペアがやること タスクリストの作成 • ◦ 受入テスト（E2E） ◦ 契約（インタフェース、モデル） ◦ 実装 ◦ 統合（受入テストのGreen確認） タスク粒度と順序の確認 ◦ ◦ 1タスクは1コミット粒度 ＝最小限の意味が通る単位 ロバストネス分析の1要素が目安 <<Command>> <<Command>> <<Command>> <<Command>> /plan /tasks /impl /approve <<Issue>> 概要 受入条件 タスクリスト <<Issue comments>> 設計方針 意思決定ログ Q&Aサマリー 19
20. /impl: タスク単位での変更とその合意 AIがやること • ペアがやること タスクの実装 • ◦ TDD ◦ タスクリストの上から1つずつ ◦ 人間がDiffを見やすいサイズで進 める 小さいDiffで実装内容の確認 ◦ タスクごとにTDDで進めるので そのテストケースも <<Command>> <<Command>> <<Command>> <<Command>> /plan /tasks /impl /approve <<Issue>> 概要 受入条件 タスクリスト <<Issue comments>> 設計方針 意思決定ログ Q&Aサマリー 20
21. /approve: レビュー通過の合意 AIがやること • テストの実行 ◦ • ペアがやること • Greenになったらタスクリストに チェック レビュー通過の記録 • タスクを満足しているDiffがあ るか確認 変更がユニットテストを通過す るか確認 <<Command>> <<Command>> <<Command>> <<Command>> /plan /tasks /impl /approve <<Issue>> 概要 受入条件 タスクリスト <<Issue comments>> 設計方針 意思決定ログ Q&Aサマリー 21
22. ペアの会話は、減るどころか増えた • 意思決定に関する会話が、明確に増えた ◦ ◦ ◦ • 実装の話をしなくてよくなった分、設計の話をするようになった 人間同士が話すべきことがはっきりした 結果的に、品質向上、透明性担保に効いた 参考: トライアル後アンケート（n=8 / 2026年6月） ▪ ▪ 設計の質が上がった … 半数以上が最高評価 見通し・透明性 … 100% がポジティブ 22
23. 会話を増やすために効いたアプローチ 23
24. 会話を増やすために効いたアプローチ 1. 意思決定ポイントを意図的に増やす 2. 「不採用にした案」を残す 3. 1タスク＝1つの意思決定の単位にする • 結局、XPで言っていることを実行すると効く ◦ ◦ ◦ 小さく刻む フィードバックを高速に回す ふりかえる 24
25. 判断①: 意思決定ポイントを意図的に増やす 1. 実装前の要件確認 2. 設計レビュー 3. タスクリスト確認 4. 1タスクごとのDiff確認 • AIのアイデアをペアが判断するサイクルの回数を増やす ◦ フィードバックループを短くする ◦ 判断の回数は、成長機会の数 25
26. 判断②: 「不採用にした案」を残す 意思決定ログには、採用案と却下した選択肢とその理由を書く 【記録】としての価値 【学習】としての価値 ▪ペア交代しても同じ議論を繰り返さない ▪言語化した意思決定をふりかえり理解を深める ▪AIが同じ提案を二度してこない ▪交代時の「なぜこうしたの？」に答える ▪引き継ぎとコンテキスト渡しをひとつで解決 ▪説明責任を果たすことで理解を確かめる その説明責任と意思決定を支えるのが、不採用案の履歴である 26
27. 判断③: 1タスク＝1つの意思決定の単位にする 1つの意思決定 ＝ コミット1つ分 Diffが小さくなり 認知的降伏を防げる • 人間だけでなく、AIにもフレンドリー ◦ 1タスクごとにコンテキストクリアしてもIssueを読めば次に何をすべ きか分かる ▪ context rot / lost in the middle が起きにくい • インタフェースを先に確定する意味 ◦ ◦ 変更コストが高い箇所を優先して、ペアで合意する 契約が決まっていれば、実装はリファクタリングしやすい 27
28. 実践後の発見と伸びしろ 28
29. 10ヶ月間の中での変化 • 実際の運用を進めていくうちに、想定と少し違う形に落ち着いた ◦ plan/tasksまでペア、方針合意後ソロで実装、PRをペアレビュー ◦ 「合意する必要性が特に高いところをペアでやる」に収束した ソロ ペア <<ペア>> <<ペア>> <<ソロ>> <<ソロ>> <<ペア>> /plan /tasks /impl /approve PRレビュー 29
30. 伸びしろ（今後の課題） • ペアプロ中の会話そのものはまだコンテキストにできていない ◦ 考える過程がトレースできると、さらに深い議論ができる ◦ AIをチームメンバーとして議論に迎える世界線 • タスクごとのレビューのあり方 ◦ 開発スピード観点だけでいえば人間がボトルネック ◦ 理解する速さとデリバリーする速さのトレードオフ 30
31. まとめ 31
32. 仕様駆動開発とペアプロは、同じ場所で重なる 仕様駆動開発 AIに 「何を作るか」を 伝える仕組み • • ペアプロ 合意の記録 人間同士で 「何を作るか」を 合意する場 AIが実装を担うほど、ペアがやるべきことは合意形成に集約される ペアプロはその合意形成の場として、会話を通じて価値を最大化する 32
33. AI時代のペアプロ STEP 01 ペアで会話と意思決定の機会を増やす 生成AIに問うべきなのは ▼ ✗ どれだけ速くコードを書けるか STEP 02 一人ひとりのベーススキルが上がる ▼ STEP 03 ◦ 意思決定の機会をどれだけ作れるか ◦ 考えを深める仕組みをどう作れるか チーム全体として速く・強くなる 33
34. AIは、いくらでも速くコードを書けるけれど 私たちはペアの会話以上の速さで 理解することはできない 理解の速度が、開発の速度になる 34
35. だから、ペアプロでの会話を増やしましょう！ 35
36. コドモンでは一緒に働きたい仲間を募集しています！ コドモン採用ページ 開発チームX 36