Agile is dead なわけがない

みなさんこんにちは。@ryuzeeです。 2026年3月4日に新刊の訳書『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』がオライリー・ジャパンから発売になりましたのでよろしくお願いします。

本記事は、先日Xに書いた記事を加筆修正したものです。

◯◯ is dead みたいなのは定期的に色々出てきますよね。最近話題になったのはSaaS。それからAgile is deadなんかもたまに見かけます。生成AIの登場によって色々なものが大きな影響を受けているのは事実ではありますが、みんなすぐに何でもオワコンにしたがりますねぇ。

しかし、アジャイルというのは特定の方法論とかプロセスとかを指すわけじゃなくて、価値観と原則を示すものなんですよ。アジャイルの定義と言えばアジャイルマニフェストですが、ぼくたちが今年の頭に訳し直したものを以下に示します。日々Xに張り付いていて時間がある人は今一度読んでみてください。別に生成AI時代でも変わることのない普遍的な内容なのではないかと思います。

アジャイルマニフェスト
私たちは、自らの実践と他者の実践の支援を通じて、ソフトウェア開発のより良いやり方を見出しつつある。
この活動を通じて、私たちは以下の価値観に至った。
プロセスやツールよりも個人や相互作用に
網羅的なドキュメントよりも使えるソフトウェアに
契約交渉よりも顧客との協働に
計画に従うことよりも変化への対応に
価値を置く。 双方に価値があることを認めるが、私たちは後者により価値を置く。
Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie van Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler, Brian Marick
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

アジャイルマニフェストの背後にある原則
顧客満足を最優先とし、早期から継続的に価値のあるソフトウェアを届ける。
開発の後期であっても、要求の変化を歓迎する。アジャイルプロセスは、顧客の競争力向上のために変化を味方につける。
使えるソフトウェアを頻繁に届ける。2〜3週間から2〜3か月という単位を想定するが、なるべく短い期間を選ぶ。
ビジネス担当者と開発者は、プロジェクトの最初から最後まで毎日一緒に働かなければいけない。
意欲ある人たちのまわりにプロジェクトを立ち上げる。必要な環境とサポートを提供し、仕事が完成するまで信頼する。
開発チーム内で情報をやりとりするためのいちばん効果的で効率的な方法は顔を合わせて話すことである。開発チームへの情報のやりとりの方法も同じである。
使えるソフトウェアこそが、進捗のいちばんの指標である。
アジャイルプロセスは持続可能な開発を推進する。スポンサー、開発者、ユーザーは、一定のペースをずっと維持できるようにしなければいけない。
技術的卓越と良い設計に絶え間なく注意を払うことでアジリティが高まる。
シンプルさ―最大限作らずに済ませる技―は必須である。
最良のアーキテクチャー、要求、設計は、自己組織化したチームから現れる。
チームはより効果的に働くために定期的にふりかえり、結果に従ってふるまいを調整し続ける。

まず価値観から行きましょう。これ、生成AIによって何が変わりますかねぇ。

最近米国の大学の卒業式でBig Techの人がAIについて触れると大ブーイングで涙目になっているなんて話も見かけましたが、道具ってのは人間のためのものです。なので道具とかプロセスよりも人間そのものや人間同士のインタラクションというのは普遍的に重要です。

ドキュメントについて言うと、生成AIに食わせるために良いドキュメントを書く重要性は上がりました。Spec駆動開発みたいなやつが進化するのも当然の流れです。でもそれは、実際に誰かの課題を解決したり行動変容を促したりするような「役に立つソフトウェア」の中間生成物に過ぎません。これも変わらない。

契約交渉よりも顧客との協働。これはちょっと受託開発っぽい感じがして現代のコンテキストとは違うこともあるかもしれないですが、結局顧客の課題を解決して満足してお金を払ってもらわないとその場限りになっちゃうという事実は変わらないですね。

計画に従うことよりも変化への対応は言わずもがな。たぶん生成AIの登場で多くの会社が採用計画を見直したり、ロードマップを見直したり、事業計画を見直したりしてますよね？変わらないと信じて計画を立ててそれに従ったところで、状況はどんどん変わります。そこで、最初に「もっとちゃんと計画を立てよう」なんて考えたところで、我々は技術や社会の変化を予測なんてできません。予測できるなら株を買ってます。

次は12の原則。全部個別に触れると大変なので、いくつかに絞って見ておきましょう。

顧客満足を最優先するのは、それが会社が生き残るための重要な要因だからで、変わりようがないですね。変化がばんばん起きる世の中では、ぼくの考えた最強のアイデアを温めて温めてステルスで長い期間かけて作ったところで、そんなの妄想だし、その間に世の中の状況もどんどん変わるのでお金と時間だけが失われます。なので早い時期から頻繁に出すしかない。それ以外にリスクを減らす方法がありません。

開発の後期でも要求の変化を歓迎する、というのは生成AIでさらにやりやすくなったはずです。あとから色んなことがわかっていくのが今の世の中なので、その変化を受け入れて活用しないと損だというのは変わらないでしょう。

ビジネス担当者と開発者が毎日一緒に働くのも引き続き有効でしょうね。このビジネス担当者というのは当時の文脈で言うとプロダクトマネージャーとかプロダクトオーナー的な存在を指しますが、ずっと一緒に働いていないと意思決定に時間がかかって仕方ありません。生成AIを使うようになって意思決定の頻度が上がっているので、ぶん投げてあとはよろしくは無理筋だと思います。

情報のやりとりでいちばん効果的で効率的な方法は顔を合わせて話すこと、というのはどうでしょうね。生成AIはテキスト情報を重視するのでコミュニケーションがテキストベースで非同期になることが多いのは確かですが、大きな方向性を検討したり、ブレストしたり、何がわからないのかを説明できなかったりするような状況もたくさんあります。またちょっとした確認や相談なんかは圧倒的に会話のほうが速いのは否定できないでしょう。あとはねぇ、そもそも人と会話せずに仕事してもつまんないんだよな。雑談しながら仕事するくらいが丁度いい（個人の感想です）。

技術的卓越と良い設計に絶え間なく注意を払うことでアジリティが高まるというのも変わらないですね。ダメな設計の上に機能を積み上げればメンテ不能なプロダクトになったり、バグだらけになったりするし、生成AIのアウトプットって、局所的にはそれっぽくても、全体として妥当な設計になっているとは限らないんですよね。なので適切な指示を与えたり、生成AIのアウトプットを目利きしたりするためにも技術的卓越は必須です。生成AIでコードを量産できるといってエンジニアを解雇した会社がにっちもさっちもいかない例も結構見かけますよねぇ。

シンプルさ―最大限作らずに済ませる技―は必須である、は生成AI時代こそ重要性が上がったかもしれない。作った機能がほとんど、もしくはまったく使われない割合は、2001年の調査では64%（Standish Groupの調査による）、2019年の調査では80%（Pendoの調査による）だったんですけど、生成AIでバンバン作れてしまうので、そのままバンバン作ってしまうという状況は非常に問題ですよね。ぼくらが大好きなXも最近いろんな機能が追加されてますけど、まぁ90%以上の機能は使っていません（Tweetdeckを返してほしい）。顧客の課題を解決したり行動変容を促したりといった同じゴールを達成するなら、なるべく少ない手数で簡単に達成すべきです。ソフトウェアの保守は規模の拡大とともに劇的に大変になります。

定期的にふりかえり、ふるまいを調整するのは当たり前ですね。みなさん生成AIの進化にあわせてやり方を色々ちょっとづつ変えていると思います。

ということで生成AIがあるのでアジャイルが死んだみたいなのはまったくないというのをわかっていただけましたかねぇ。ちなみに、ぼくのスタンスとしては、価値観と原則が重要であり、その価値観と原則を体現できるなら、具体的なやり方は自分たちで選べばいいという考えです（当たり前か）。なので、スクラムが合わなくなってきたのであれば、自分たちのやり方に変えればいいし、カンバンだろうとFaSTだろうと、自分たちで考えてやってください。仕事のやり方っていうのは、その仕事をする人たち自身のものだからね。

Agile is dead なのではなく、自分たちで考えずに借り物のプロセス？を回すだけのやり方が限界なだけなんじゃないかなぁ。