本記事は 2024/10/15 に開催されたイベント「アジャイル✕コード✕AI – AI時代のアジャイル開発とは！」の内容をもとに執筆されました。
「コード×AI ー ソフトウェア開発者のための生成AI実践入門」(以後「コードAI本」)の著者である服部佑樹と、著名なアジャイルコーチの川口 恭伸さんが、AI時代のアジャイル開発について対談しました。（以降敬称略）
モブプログラミングの核心へ：複数の視線が育む集合知
服部：
最近のソフトウェア開発現場でのAI活用について、川口さんの印象はいかがでしょうか？開発チームと近い位置で支援されている中で、どんな取り入れ方をされているのか、まずは大枠で教えていただけますか。
川口：
コード生成系AIは、かなり一般的になってきていますね。 ただ、私が特に注目しているのは、純粋なコーディング以外の領域でのAI活用です。例えば、かつてのエキスパートシステムのような専門家の知識を活用する場面で、チャットベースのUIや自然言語でのやり取りができる点は非常に興味深いですね。
また、テスト生成の分野でもAIの活用が進んでいます。私自身、アジャイル開発、特にモブプログラミングを推進している立場から見ると、AIとの相性の良さを強く感じています。
AI×モブプログラミングで「集合知」をブーストする新手法
川口：
モブプログラミングって面白いんですよ。実は、アメリカのスプリンクラー業界で圧倒的シェアを持つハンター・インダストリーズが生み出した手法なんです。私も2週間ほど現地で学ばせてもらいましたが、本質は「チームの知識をど真ん中に置く」というシンプルな考え方なんです。
4 eyesという考え方で、同じコードを必ず複数の目で見ることで、バグの早期発見や知識共有を促進する。これがチーム全体のスピードアップにつながるんです。面白いことに、このモブプログラミングという形態が、AIとすごく相性がいいんですよ。考えてみてください。モブプログラミングって、すでにチームで「集合知」を活用している状態なんです。誰かが分からないことがあれば、その場で質問して解決できる。AIはこの流れにすんなり入ってくるんです。一人で黙々とコードを書く「カウボーイコーダー」的なスタイルよりも、チームでAIを活用する方が、より効果的な使い方ができるんです。
服部：
私もコードAI本の中でAIモブプログラミングについて触れましたが、モブプログラミングの中でAIを使うと、AIの使い方自体も進化するんです。例えば、あるメンバーが「こういうプロンプトの書き方があるよ」と共有したり、チームの文脈に合わせたAIの使い方を皆で考えたり。これが個人では得られない学びになるんです。
学習プロセスの中でAIをどう活用するかは、多くの開発者が直面している課題ですよね。
川口：
面白いのは、従来のモブプログラミングでも、ナビゲーター役の人たちは常にGoogle検索をしながら情報を集めていたんです。今はその役割の一部をAIが担えるようになった。特に基礎的な部分から丁寧に説明してくれるので、初学者にとっても理解が深まりやすい。
服部：
例えば、私も最近知人と画面を共有しながら開発する機会があったんですが、参加しているメンバーから「次はこれをAIに聞いてみよう！」みたいなアイデアが次々と出てきて、探索的な学習がどんどん進んでいく。AIは学習の加速装置として機能していますよね。
川口：
AIが持っている知識も、結局は人間が作り出したドキュメントから学習したものなんです。Googleが登場して検索の世界が変わったように、今はその次のフェーズに来ている。でも本質は変わらない。AIは膨大な人間の知識を整理して提供してくれる、すごく優秀なアシスタントなんです。この認識を持っておくことが大切ですね。
服部：
モブプログラミングとAIの組み合わせは、チームの学習と開発の両面で相乗効果を生み出してますね。個人プレーではなく、チームとしてAIを活用する。これが、これからのソフトウェア開発の新しいスタンダードになっていくかもしれませんね。
スピード×品質：AIが切り拓く高速プロダクト開発の未来 - 「速さ」と「深い理解」を両立する鍵は何か？
服部：
最近、多くの企業が生産性向上を目指してAIを導入していますよね。特に開発支援AIの導入判断では、投資対効果が重要な判断基準になっているように感じます。ただ、純粋な開発生産性の向上だけでなく、開発者体験の向上やチーム内の摩擦の軽減といった、数値化しにくい効果もあると思うんです。こういった部分について、川口さんはどのようにお考えですか？
川口：
そうですね。実はアジャイル開発のコミュニティでは、「開発生産性」という指標自体にあまり良い印象を持っていない人が多いんです。というのも、「これを作りたい、いつまでにできる？」という質問に対して、単純な関数では表せないことが多いからです。
むしろ重要なのは、チームメンバーがコードやプロダクトに対する深い理解を持っているかどうかです。具体的には、以下の3つの理解が重要だと考えています：
- プロダクトが誰にどんな価値を提供するのか
- 実際のユーザーの声を理解できるレベルの知識
- コードベースへの深い理解
これらの理解があることで、次のステップへの移行が素早くなります。
服部：
なるほど。つまり、単純な開発速度よりも、ビジネスニーズへの即応性が重要だということですね。
川口：
その通りです。ビジネスの世界では、「明日言われたことを明後日に提供できる」能力が非常に価値があります。極端な話、先回りして解決策を用意できれば、それだけで大きな価値になる。そこにAIは確実に貢献できると思います。
服部：
でも、AIの活用にも課題がありますよね。例えば若手エンジニアがAIの生成したコードをよく理解せずにコミットしてしまうような問題がある、なんて話も聞きます。
川口：
はい、それは課題です。表面的には動作するものの、中身を理解していないコードが組織のリポジトリに入っていくリスクは確実に高まっています。ただ、これは昔からある問題の新しい形とも言えます。機密情報の誤った公開や、理解していないコードを理解しているふりをするといった問題は、AIの登場以前からありました。
服部：
このような状況で重要なのって、チームとしてAIをどう活用していくかという方針づくりですよね。単にコードを速く書けるようになるだけでなく、チーム全体としての生産性向上につながる使い方を模索する必要があります。
組織の壁を超えて：マーケティングと開発の新しい関係性
川口：
XPの生みの親であるケント・ベックが、実はマーケティングと開発者の間にある深刻な対立を解消したかったという話は、とても示唆に富んでいます。典型的なシナリオを考えてみましょう。マーケティングサイドが「この予算でこの期限までに」と一方的に決めてしまい、開発者がその制約に縛られる。この構図、皆さんも見覚えがありませんか？
でも、ケント・ベックが提案したのは、そのパワーバランスを根本から変えることでした。開発者が「このペースなら安定的に開発できます」と示した見積もりは揺るがせないものとし、その上でマーケティングサイドと建設的な対話を始める。
そこで登場するのが、XPでいう「計画ゲーム」 や Scrumの「プロダクトバックログ」 といった仕組みです。これらは単なるツールではなく、両者の対話を促進し、意思決定を透明化するための「場」なんです。
服部：
つまり、上下関係ではなく、フラットな関係性を作り出そうとしたわけですね。
川口：
ええ。でも、ここで興味深いのは、XPが生まれてから20年以上経った今でも、この力関係があまり変わっていないという現実です。ケント・ベック自身が2019年に、この状況に「深い絶望と興味」を感じていると語っているんです。
服部：
それって本当に根深い問題ですよね。私も『コード×AI』という本を書いた時に、技術的なプラクティスについて多く触れましたが、結局のところ個人の技術力だけでは解決できない問題があると感じています。
川口：
そうですね。例えば、どんなに個人が頑張っても、締切りという制約の前では品質が犠牲になりがちです。結局、根本的な解決には、計画段階からの見直しが必要になってくる。
ああ、そうそう。Woody Zuillというエンジニアが、CEOと最初に交わした約束が興味深いんです。「リリースは開発が決める」「見積もりはしない」「半年はこのやり方でやらせろ」という3つの条件を出して、それを実現した結果、1年半もの間バグが出なかった。これによって経営陣からの完全な信頼を獲得したんです。
服部：
すごいですね。技術的なプラクティスも大事だけど、それ以上に組織としての意思決定の仕方や信頼関係の構築が重要だということですね。
川口：
そうなんです。生成AIの時代になって、また新しい可能性も見えてきています。例えば、生成AIを使って効率が上がった分、マーケティングと開発が一つのチームとしてより密接に協働する時間を作れるかもしれない。
服部：
結局のところ、技術的な解決策だけでなく、組織としてどうやって協働していくか、という視点が重要になってくるんですね。これはAI時代にも変わらない、永遠の課題なのかもしれませんね。
AIとの協働について書いたコードAI本は好評につき重版決定。
また、川口さんが監修されたアジャイルプラクティスガイドブックも好評発売中です。（服部佑樹もコラムを寄稿していますので、ぜひチェックしてみてください！）
