こんにちは。プロダクト開発部の友野です。
春のブログリレーが始まりました。松浦さんからバトンを受け取り、花粉と戦いながらがんばります。
さて、AI普及に伴い開発のあり方が大きく変化して久しいですが、AIを我々のペアプロ文化とどう組み合わせるか、XP（エクストリーム・プログラミング）の価値原則をどう保つかはチームの共通の問いとして、より良いアプローチを求めて今も議論は続いています。松浦さんの先日のブログでも、「ペアでの会話という習慣が、AI時代でも活きるのではないか」という予感を綴っていました。
私もその思いは同じで、ただこれまでのペアプロのやり方をそのまま続けるのでもなく、ペアプロをAI時代に合わせて進化させたいと考えていました。そこで取り組んだ実践と、それを通じて改めて認識したことを語ります。
スペック駆動開発はペアプロと合うか
これから紹介するのは、私のチームでの体験の話です。
遡ること昨年夏の終わり頃、あるプロジェクトでClaude Codeを使ってソロでコードを書いていた時期があります。コドモンの開発チームは基本的にペアプロで進めていますが、AIのポテンシャルを検証する意図でもありました。そこまで複雑な仕様ではなかったですし、CLAUDE.mdにコンテキストを育てながら進めていたので、明確に開発効率は上がりました。チケットあたりのリードタイムも短くなり、手応えもありました。
ただ、実績の反面、若干の違和感が残っていました。設計の合意形成が失われているという事実です。 ペアプロで大切なことのひとつに、コードを誰かと一緒に書くことそのものではなく、なぜこの設計を選ぶかをペアと合意してから実装に入ることがあると考えています。ソロで進めると、一時的にはうまくいっているように見える一方、その設計判断を一人で抱えることになり、後から「なぜこうしたのか」を説明するコストは上がります。
ちょうど同じ頃、注目を集めていたのがスペック駆動開発です。仕様・設計・タスクを明示的に言語化して、AIに文脈を与えてから動かすという考え方には共感できましたし、ペアプロでこれと同じことができれば、活路を見出せるとも感じました。
ただ、スペック駆動開発を実現する代表的な支援ツールとして知られるAWSのKiroは、成果物をローカルのファイルシステムに生成します*1。 つまりこれは、ある瞬間の文脈はドライバーのマシンの中にあるためナビゲーターからは見えにくく*2、かつペアが交代したとき、新しいペアがその文脈を把握するために、ファイルから途中経過を読み込む必要があることを意味します。リポジトリにコミットされるまでは非同期で議論を積み重ねることも難しいため、少なくとも私のチームでの、ペアの協働を前提としたワークフローとは合わない部分がありました。
すでに、答えはIssueにあった
私のチームではIssueを中心に開発を進める文化があります。概要・受入条件・タスクリストをIssueに書き、ペアで確認しながら進めるアプローチです。ペアが交代しても、Issueのタスクリストを見れば今どこにいるかが分かるこの運用は、生成AIとは無関係に、ペアプロの持続可能性のために自然と根付いてきたものです。
Kiroを始めとするスペック駆動開発支援ツールのアプローチを知ったとき、頭に思い浮かんだのはシンプルなことでした。Kiroがローカルに生成するMarkdownファイルを、GitHub Issueに置き換えればいいのではないか、ということです。
IssueはURLで共有できますし、ナビゲーターもリアルタイムで参照できます。コメントで設計の判断や却下した選択肢を残せば、ペア交代をしても、Issueを開けばそこまでの経緯を把握できます。AIに渡すコンテキストとしても、Issueのテキストをそのまま活用可能です。
私たちがペアプロのために育ててきたプロセスが、生成AIを迎え入れる基盤としてもそのまま機能するのではないかと考え、ワークフローの検討を始めました。
この社内用AIワークフローは、Kiroのようなスペック駆動開発をIssueベースで行うことから、GitHub Issue based Kiroの略でgiro（ギロ）と呼んでいます。以降、このワークフローをgiroと表記します。
AIのためにワークフローを再構築したのではなく、すでにあったプロセスをワークフローとして拡張していった、それがgiroの出発点です。
意思決定をワークフローに組み込む
ペアプロで大切にしてきた設計の合意形成を、AIとの協働でも成立させるにはどうすればいいか、giroはその問いへの私たちなりの答えです。GitHub IssueをスペックファイルとしてAIをステアリングするワークフローで、ツール自体は社内向けのため非公開ですが、考え方は再利用可能だと思うので紹介します。
ワークフローの構造
他のスペック駆動開発ツールと同じように、いくつかのステップでワークフローは構成されています。いずれもClaude Codeのスラッシュコマンドとスキルで実装しています。
- 設計（plan）
- 既存コードを調査し、やりたいことや受入条件にあいまいな点があれば
AskUserQuestionでユーザーに確認する - 調査結果とIssueの内容から、ロバストネス分析（Boundary/Entity/Controlという3種類の要素でシステムを分析する設計手法）に基づいてインタフェース設計を行い、Issueコメントに投稿する
- ユーザーが承認するまで次に進めない
- 既存コードを調査し、やりたいことや受入条件にあいまいな点があれば
- タスク分解（tasks）
- Issueコメントの承認済みの設計から、15分〜1時間粒度のチェックリストを生成しIssue本文に追記する
- 実装（impl）
- Issue本文のチェックリストのうち、未完了タスクを1つずつ取り出し、TDD（Red→Green→Refactor）で実装する
- 1タスクごとに必ず停止し、ユーザーの確認を待つ
- 承認（approve） → 3.に戻る
- テストを実行し、パスしたらチェックボックスを更新する
- テストが通らなければ進めない
このワークフローを設計するうえで意識したことが2つあります。
1つは再現性です。設計フェーズにロバストネス分析という構造化された手法を指定しているのは、「いい感じに設計して」というあいまいな指示を避け、タスク分解に一貫性を持たせるためです。
もう1つはSingle Source of Truthとしての運用です。全フェーズを通じてGitHub Issueに情報を集約し、本文とコメントで役割を明確に分けて利用します。本文には受入条件とタスクリストを置いて「現在の状態」を表し、コメントには設計方針や意思決定のログを残して「なぜそうなったか」を追跡できるようにしています。設計方針を改訂した際は<details>タグで旧版を保持し、経緯が消えないようにしています。
特に重要なのは、却下した選択肢とその理由をコメントに残すことです。「なぜこうしなかったか」が残っていると、ペア交代後の新しいペアがAIに同じ提案をさせてしまうことを防げます。結果として、人間のペアへの引き継ぎとAIへのコンテキスト渡しを、同じIssueで同時に解決できています。二重管理が発生しないため、運用コストを低く保てます。
意思決定の機会を意図的に増やす工夫
giroのワークフローには、人間が判断を下すポイントが繰り返し埋め込まれています。
- 実装前の要件確認
- AIからの質問に答えながら暗黙の前提や未定義の仕様を言語化します。自分では気づかなかったあいまいさが炙り出される体験は、人間同士のペアプロでも馴染みのある感覚ではないでしょうか。
- 設計レビュー
- ロバストネス分析に基づく設計案を読み、Boundary/Entity/Controlの切り方が妥当か判断します。変更を求めれば改訂ループに入ります。
- タスクリスト確認
- 生成されたチェックリストの粒度や順序を確認し、必要に応じて手動で調整します。
- 1タスクごとのdiff確認
- 実装が1タスク進むたびに止まるので、コードの方向性を都度判断できます。diffが小さく保たれるのでレビューしやすく、早い段階で軌道修正が効くのは大きな安心感があります。
通常のAIコーディングでは「指示→結果確認」の1往復になりがちですが、giroでは1つのIssueに対して4回以上の判断ポイントがあります。設計判断の回数が増えることで、完成してから「思っていたのと違う」となるリスクを減らせています。
これはペアプロで相方と「ここどうする？」「こっちのほうがよくない？」とやり取りする感覚に近いものです。AIが叩き台を出し、人間が判断するサイクルの回転数を上げることが、giroの狙いです。
気づけば、AI-DLCと同じ方向を向いていた
AI-DLCはAWSが提唱する開発方法論で、AIが主体となって開発を駆動し、人間はゲートキーパーとして意思決定に専念するという思想です。
社内でgiroを見せたメンバーから「AI-DLCに近いかもね」とコメントをもらったことがきっかけで調べてみると、確かに重なる部分がありました。
前の章で紹介した「実装前の要件確認」、つまりAIと対話しながらあいまいさを言語化するプロセスは、AI-DLCが定義するInceptionフェーズと似ています。またKiroをベースにしているので、当然ながら、giroのワークフロー全体、設計・タスク分解・実装・承認というサイクルは、AI-DLCのConstructionフェーズの考え方に近いものです。
ただ、出発点は異なります。AI-DLCはAIを中心にワークフローを再構築するアプローチです。giroは人間のペアプロワークフローを起点に、AIを迎え入れるために拡張したものです。
それでも、目指している場所は近しいと感じます。コンテキストを永続化し、AIと人間が同じ文脈の上で判断を積み重ねていく世界線は、まさにペアプロとAIが融合した形です。giroという命名がKiroに由来しているのも、その思想への共鳴があってのことです。AI-DLCが今後進化していくとしても、Issueを基盤にした私たちのワークフローはその差分を吸収できると考えています。出発点は違っても、大切にしていることは同じだったのかもしれません。
giroを導入した後の変化とこれから
giroを導入してから、メンバー間での意思決定に関する議論や設計判断の会話が増えました。AIが実装を担う時間が増えた分、人間同士が話すべきことが明確になったのだと思います。実際、使っているメンバーからも、設計に注力しやすくなったとコメントをもらっています。
この変化を通じて改めて気づいたのは、ペアプロが「設計の意思決定を共有する場」として機能していたということです。コードを誰かと一緒に書くことそのものよりも、なぜこの設計を選ぶかをペアと合意してから実装に入ることの重要性が浮き彫りになった結果でした。
一方で、giroはまだ発展途上です。現時点では私のチームでの利用に留まっており、他チームへの展開はこれからです。より広いフィードバックを得ながら、改善を重ねていく必要があります。
技術的にも積み残しがあります。ペアプロ中の会話そのものをコンテキストとして扱えていないこと、タスクごとのコードレビューのあり方、実装タスクの並列化など、改善の余地は多くあります。松浦さんが作った文字起こしツールとの連携も、会話をコンテキスト化する上では面白い可能性があります。
おわりに
この記事では、ペアプロ文化を持つチームがスペック駆動開発をIssueベースのワークフローに乗せ、giroとして形にするまでの経緯を紹介しました。ペアプロをAI時代に合わせて進化させるための、一つの実践例です。
改めてですが、ペアプロとスペック駆動開発は相性が良いと感じます。スペック駆動開発が「AIに何を作るかを伝える仕組み」だとすれば、ペアプロは「人間同士で何を作るかを合意する場」です。スペック駆動開発で言語化した仕様は、そのままペアの合意の記録にもなる。つまり、二つの実践が同じドキュメントの上で重なる、ということです。
AIが実装を担うようになるほど、人間がやるべきことは合意形成に集約されていきます。ペアプロはその合意形成の場として、むしろ今の時代に本領を発揮するのではないかと、giroを作りながら感じました。AIが実装を担うようになっても、設計を誰かと合意する対話の価値は変わりません。むしろその価値は、これまでより際立っています。
