- AIによるコード生成とプラットフォーム革新のおかげで、開発速度は爆発的に向上したが、依然としてプロジェクト成果は振るわず、失敗率も高い
- 問題は速度ではなく、検証とアラインメントの欠如であり、XPは意図的な制約によって学習・アラインメント・品質向上を促す
- 特にAIエージェントがコード生成・修正・デプロイを加速するほど、検証なき複雑性の増大と脆弱性は深刻になる
- XPはシンプリシティ、コミュニケーション、フィードバック、リスペクト、勇気といった人間中心の価値と、小さなバッチ・継続的インテグレーション・自動テストを重視する
- 高速な出力が当たり前になった時代に、XPはソフトウェアは結局人のためのものという原則をあらためて思い出させる方法論である
ソフトウェア生産速度の加速と限界
- 近年、AIツールやさまざまな開発プラットフォームの革新により、コード生成のハードルは大きく下がり、速度も大幅に向上している
- 数回のプロンプトやAPI呼び出しだけで、製品・機能・インフラ全体が素早く生成される
- しかし、生産性が高まったにもかかわらず、プロジェクト全体の成功率は目立って改善していないという問題がある
- Standish CHAOSレポートやMcKinseyのレポートなどでも、ITプロジェクトの大半が失敗するか予算超過に至る事例が依然として頻繁にあると指摘されている
- 単純にコード生成速度が改善しても、ソフトウェア提供の成果が自動的に高まるわけではない現象が確認されている
出力（output）が本当の問題ではない理由
- ソフトウェア開発のボトルネックがコードの入力・出力速度ではないことは繰り返し証明されてきた
- 高水準言語の導入、フレームワークやパッケージマネージャの普及、DevOps・サーバーレスの拡大、開発プラットフォームの進化、そしてAIコード生成など、加速の波が連続して起きてきた
- CHAOSレポートによれば、出力が加速しているにもかかわらず、最終結果は一貫性を欠き期待に届かないという問題が続いている
- 単純な高速化が答えではなく、より賢い「制約」が重要であることを強調する
- XPは急がずに学習し、アラインメントを取り、意図を持って開発することで正しい方向へ導く実践法である
XPの役割：速度へのカウンターウェイト
- 無制限の加速は、学習、ミスの発見、方向修正の機会を奪うという問題を引き起こす
- エクストリーム・プログラミング（XP）は、意図的な摩擦・制約を導入し、チームが正しい方向に進むよう設計されている
- 代表的な実践: ペアプログラミングはあえて産出量を半分にする
- ペアプログラミングは成果物の量を半分にするかもしれないが、共有理解、信頼、品質、チーム内スキル向上といった好影響を2倍にもたらす
- XPは協業のやり方そのものを変え、チーム能力の強化と方向性の提示に投資する
AIとともにさらに深まるXPの問題意識
- AIがコード生成をほぼ無労力にしたことで、十分に検証されていないソフトウェアが大量生産されるリスクが高まっている
- 特に複数のエージェントがコードを自動生成・改善・デプロイするagentic AIシステムでは、リスクが急激に高まる
- 制約のない自動化システムが未検証ロジックを多層的に積み上げることで、複雑性と脆弱性が悪化する
- 最近の研究では、LLMのコンテキストウィンドウが長くなるほど精度が悪化することが示されている
- 冒頭と末尾はうまく処理できても、中間部分ではかえって一般化やエラーに弱くなる
- 結果として保守コストが高く壊れやすいコードにつながり、XPはこうした無秩序なエントロピーを防ぐために生まれた
ソフトウェアは依然として人の領域
- AIが進化しても、ソフトウェアは人が人のために、組織内のコミュニケーションと文化の中で作るものという本質は変わらない
- 主要な伝達上の障害は自動化の度合いではなく、アラインメント、共有コンテキスト、明確な成果、ユーザー検証などの人間ベースの要素である
- XPの中核価値:
- Simplicity: 複雑性の低減
- Communication: チームの結束維持
- Feedback: 学習と適応の促進
- Respect: 信頼と安全の構築
- Courage: 透明性と変化可能性の支援
機能工場（feature factory）から本当の価値提供へ
- 成功するチームは速度そのものよりもフロー（flow）とフィードバックを優先する
- XPの小さなバッチ、継続的インテグレーション、自動テスト、共同所有といった実践が適応性とユーザー中心性に寄与する
- 今後コード生産がさらに速くなるほど、こうした手法は品質、リスク、意図の管理に不可欠になる
過去の教訓
- CHAOSレポートの統計:
- 1994年: 納期内・予算内で成功したプロジェクト 16%
- 2012年: 37%に改善
- 2020年: 再び31%に低下
- 20年以上にわたる革新と変化（agile、DevOps、クラウドネイティブ、AIなど）の後でも、全体的な信頼度はわずか14ポイントしか上昇していない
- ツールチェーンだけでは問題は解決できない
- 正しい方法論の重要性が再確認される
これから何が必要か
- 1. 出力はもはや制約ではない: コード生産力は検証・アラインメントの速度を追い越している
- 2. 成果中心の能力強化: フィードバック、明確な製品方向、強い協業、優れた設計などが不可欠
- 3. より人間的なプロセスが必要: AIが進化しても、継続的デリバリーは協業に依存する
- 実際に効果的なProduct Operating Modelは、人—協業、明確さ、フロー—中心の運営から生まれることを強調する
- 技術革新（プラットフォーム）よりも、チーム戦略、運営リズム、エンジニアリング実践を隙なくアラインさせるとき、AI時代の持続可能なソフトウェア提供環境を構築できる
結論: AI時代、XPは必要か？
- そうだ
- より強力になるツールの中で、人間中心の実践を固定してくれるフレームワークが必要である
- XPはチーム中心で、共感力、共有理解、正しい目標志向を同時に提供する
- 単純な出力速度ではなく、意味のある方向性とチーム内アラインメントに集中する
- AIの加速と制約のない生産の時代に、XPはソフトウェアは人の仕事であることを思い出させてくれる稀有な方法論である
1件のコメント
Hacker Newsの意見
Kent Beck（Extreme Programmingの創始者）は、AIコーディングに関してさまざまな実験をしている
Augmented Coding Beyond the Vibes のような記事で、AIをプログラミングにどう活用できるかを模索している
ChatGPTがコーディングに有用に使われ始めたとき、自分のスキルの90%はもう価値がなくなり、残りの10%はそれだけ一層価値が高くなったと語っていたのを覚えている
90% of my skills are now worth 0
私は、テストファーストのXP開発スタイルは、AIがコードを生成しそれを検証するのに役立つ時代において、さらに価値が高まると思う
このやり方のほうが、特にAIツールによるコード生成がしやすくなると感じる
最近のAIコーディングで気になることの一つは、古いレポートやガイドがリポジトリに残っていることだ
たとえばこのレポートも、生成時点のコードをもとにしたAI生成レポートだ
こうした中間成果物を履歴に残すことに、どんな意味があるのかわからない
特に
_updated_v2_from_2025のように積み上がっていくファイルには疑問を感じる例1, 例2
XPこそが本当のアジャイル手法だと思う
アジャイルは時間が経つにつれて意味を失い、形骸化してしまった
AIプログラミングはフィードバックループを素早く閉じる役割を果たすが、すべてのコードに大量の単体テストが必要だとは思わない
人々がXPの核心（私にとってはフィードバックループだ）をもう一度理解し、LLMベースのエージェントシステムによってさらに密なフィードバックループを作れるなら、ソフトウェアエンジニアリングにとって大きな前進になるはずだ
XPから始めてXPを徹底的に実践してきた経験があるので、今ではSCRUMスタイルの組織では働きづらい
SCRUMは主にXPに由来しているが、今では意味のない慣行だけが残っているように感じる
理想的なシナリオは、2人の開発者が同じブランチ上でAIエージェントたちと一緒にペアプログラミングをすることだと思う
ペアでの計画、レビュー、開発、テストが自然に繰り返される理想的なフィードバックループだ
XP時代のユニットテストと今のテストは違う
当時は機能単位のテストであり、メソッドごとのテストではなかった
AIがどれだけ正確にフィードバックループを閉じられるか次第だと感じる
コードの半分をユーザーに届けない（= 本番に出さない）のは、アジャイルではないと思う
私たちのチームは全員が元PivotsとThoughtworks出身で構成されている
ペアプログラミング、TDD、顧客常駐が基本だ
IDEでのAIも2年以上積極的に活用している
ところが今年は驚いたことに、「AIと各自が分かれて作業する」形ではなく、むしろ全員（4人）が1つのプロジェクトで歩調を合わせ、1つのことに集中する「モビング」を始めた
Claude Codeがタイピングを助けてくれて、4人が同時にリアルタイムで協力する
XPとAIが絶妙に組み合わさった、最も楽しく、集中度が高く、効果的な体験だった
XPを完全に忘れていた
一部は今では日常化しており、残りの部分は今の基準ではとてつもなく奇妙に見えるだろう
特に、LLMを使って何も考えずに1000行を超えるコードを吐き出す前に、必ず一度立ち止まって考えるべきだと強調したい
個人的には、XPの中で何が最も異質に感じられると思うのか気になる
これを、誰もがAIとペアプログラミングをすべきだという意味に受け取るべきではない
チームメンバーとペアプログラミングをすれば、お互いの考え方やコードの文脈を共有できる
しかしAIとペアプログラミングをすると、プロンプトを閉じた瞬間にAIはすべてを忘れてしまう
だからここで議論しているXPは、1990年代と同じく依然として「人間同士」で行うXPだ
AIが一部入り込むことはあっても、中心は人間だ
成果物を明示的に残さなければ、そうなってしまう
文書が十分にない新しいコードを探るときに、LLMと一緒に学んだ内容をドキュメントやエージェントファイルとしてリポジトリに残すなら意味があるかもしれない
むしろ私は、AIとペアプログラミングをしないなら間違ったやり方をしていると思う
実際、人間同士でペアプログラミングをしても、未来の私は今の記憶を全部忘れてしまうことが多い
ドキュメント化に重点を置いたペアに進むべきだ
要するに、LLMと一緒にXPペアプログラミングを必ず実践すべきだ
Extreme Vibing（XV）の講座を売ろうとする人も、きっと出てくると思う
Extreme Programmingは、独立しても使える複数の概念（例: TDD、ペアプログラミング、CI、フィードバック）をひとまとめにしたパラダイムだ
それぞれは状況によって有用だが、すべての要素を常に同時に使う必要があるとは思わない
この文脈ゆえに、XPはひとつの完成された概念としての力を失っているのだと思う
今日ではほとんどのチームがXPの一部だけを実践しており、ほぼすべての組織が本物のXP全体を適用しているわけではない
アジャイルについて言えば、大企業の多くは全体の90%以上の慣行を、およそ70%程度の忠実さで実装している傾向がある
実際には、アジャイルマニフェストで説明されているやり方を100%実装している会社は1社もなく、最もよく守っていたところでも90%程度だった
しかし核心的な実践がすべて一つのパラダイムに束ねられていたため、組織は自分たちを「アジャイル」と呼びやすかった
その結果、単に「アジャイルに転換する」と宣言することがずっと簡単になった
XPの本が哲学・原則・実践の段階に分かれている理由はここにある
その本で最も印象的な一文は、実践のない価値は死んだものであり、価値のない実践もまた空虚だという点だ
結局のところ、ベストプラクティスそのものよりも、チームに主導権を持たせ、自らプロセスを定め、よく設計された信頼できるソフトウェアを生み出せるようにすることが究極の目的だ
XPがやや「雑多なツールキット」のように見えるのも、実際にはそうした能動的なチームが選んで使うものだからだ
私は実際に、上で挙げられた実践（TDD、ペアプログラミング、CI、フィードバック）を本番コードでは常に行っている（条件が整えば）
どんな状況でこうした実践が「間違っている」と見なされるのか気になる
90年代の強迫的なアジャイルを経て、ここまでかなり進化してきたと思う
今はAIが適用されたワークフローが増えているので、単に成果物の量を増やすのではなく、本当にユーザー成果の確率を高める方向でソフトウェアプロセスを見直す必要があるという点にもっと集中すべきだ
XPはその出発点としては良いと思う（必ずしも終着点ではない）
Extreme Programming（XP）は、短い反復、速いフィードバック、シンプルな設計に焦点を当て、ペアプログラミング、TDD、CIのような実践を基盤として変化に素早く適応するアジャイル手法だ
できるだけ小さく、素早く作り、顧客とともに反復する学習と品質最適化を優先する
~ GPT5 in perplexity
最近は、AIとともにウォーターフォールが再び台頭しているように感じる
そもそもウォーターフォールは消えたことがなかった
ウォーターフォールが戻ってきたのは残念なことだ
ウォーターフォールはほとんどの場合、正しいアプローチではない
元Pivot出身でXPに熱狂している身としては同意する
下の私のコメントも参照してほしい
今でもXPを実践している