アジャイルに別れを告げて
(lewiscampbell.tech)- ソフトウェア業界を席巻してきた アジャイル（Agile） 手法について、実際には曖昧な原則と、すでに解決済みだった問題の再包装にすぎなかったのではないかという批判的再検討
- ウォーターフォールとの対立構図はほぼ虚像であり、反復的開発と顧客参加 のような中核概念はすでに1970年代の研究で提示されていた
- アジャイルは常に ウォーターフォール（Waterfall）モデルの反対 としてのみ定義されてきたが、ウォーターフォールモデルの限界はすでに1970年代に広く知られていた事実
- 近年 大規模言語モデル（LLM） の登場により、スペック駆動開発（Spec-Driven Development） が再び重要になり、ドキュメント中心の開発が台頭している
- 「包括的なドキュメントよりも動くソフトウェア」というアジャイルのスローガンは、いまや「包括的なドキュメントが動くソフトウェアを作る」という認識へと転換しつつある
- アジャイルが残した曖昧さを越え、明確な原則と工学的アプローチへ立ち返るべき時点 に来ている
> RIP Agile, we hardly knew ye.
> And I mean that literally - because no one was ever clear on what it was.
> アジャイルよ、安らかに眠れ。私たちは君をまともに知りもしなかった。
> 文字どおりだ。なぜなら、アジャイルが正確に何なのかを本当に理解していた人は誰もいなかったのだから。
アジャイルのアイデンティティ問題
- アジャイル（Agile） はソフトウェア業界全体を覆った巨大な潮流だったが、実際にはその意味が不明確なまま広がった概念だった
- 疑問が呈されるたびに、「それは 本当のアジャイル ではない」という返答が繰り返されてきた
- アジャイル宣言（2001） を実際に読んでみると、具体的な指針はほとんどなく、「顧客との協調は契約交渉より重要だ」といった 曖昧な格言 レベルにとどまる
- 「開発後半でも要求変更を歓迎せよ」といった原則は 商業的には非現実的 である
- 「真のアジャイル（True Agile）」 という主張のもと、実務上の問題点は宣言とは無関係だという形で回避され続けてきた
- アジャイル業界がアジャイルをまともに実践しておらず、宣言そのものにも意味が乏しいのだとしたら、アジャイルの実体とは何なのかが疑問になる
「ソフトウェアにウォーターフォールの亡霊が漂っている」
- アジャイルは常に、自分が 何ではないか（Waterfall、ウォーターフォール） によってのみ定義されてきた。アジャイルをしていなければウォーターフォールをしていることになり、しかもウォーターフォールは機能しない、という論理構造である
- しかし、ウォーターフォールがうまく機能しないという事実は 1970年の時点で すでに知られており、Winston W. Royce がその理由を正確に説明していた
- Royce は代替案として、プログラム設計から始めること、ソフトウェアのプロトタイプを作って要求を洗練すること、顧客を公式かつ深く継続的に関与させること を勧めていた
- これらすべてが後になってアジャイルの革新だと主張されたが、実際には 月面着陸の翌年（1970年） にすでに書かれていた内容だった
- 脚注1: アポロ誘導コンピュータ のプログラマたちは、ストーリーポイントもなく、「技術的卓越性への継続的な配慮が俊敏性を高める」といった原則すら知らずに、どうやってあれほどの偉業を成し遂げたのだろうか？
1976年 Bell-Thayer 論文と反復的開発の歴史
- 1976年の Bell と Thayer の論文は、"Waterfall（ウォーターフォール、滝モデル）" という用語を初めて使用 した文献であり、この用語自体がやってはいけないことの例として使われている
- 当該論文の実証研究による結論は、要求の欠陥はソフトウェア開発工程で 設計によって要求を満たそうとするときに 初めて発見される、というものだった
- 反復的開発は新しいものではなく、アジャイル以前の数十年間にわたって継続的に洗練されてきた
- 宣言が業界を解放する以前から、ウォーターフォールは最新技術ではなく、要求や仕様書の有効性を真剣に疑う人もいなかった
スペック駆動開発（Spec-Driven Development）の台頭とアジャイル後
- 大規模言語モデル（LLM） の普及により、プログラマが再び 仕様（specification） を書く流れが強まっている
- LLM は 曖昧な入力に弱い ため、問題を明確に記述することが正しいコード生成を助ける方法として定着しつつある
- アジャイルが「包括的なドキュメントよりも動くソフトウェア」を強調したのに対し、スペック駆動開発は 「包括的なドキュメントが動くソフトウェアを作る」 という反対命題を提示する
- Royce はすでに1970年に、「文書化、仕様、設計はコードを書く前までは同じ概念であり、文書が悪ければ設計も悪い」と指摘していた
- 文書が存在しなければ設計も存在しない という点を強調している
- 1970年と1976年の研究を振り返ると、2001年のアジャイル宣言が 新しい洞察を提供していなかった ことが明らかになる
- アジャイルは 曖昧な定義と商業的パッケージング によって既存の工学的アプローチを置き換えただけで、実質的な進歩を成し遂げなかった
- それらのエンジニアの論文のほうが、はるかに明確な意味を持っていた
- ソフトウェア開発がいまも変化し進化し続ける中で、アジャイルを歴史の中へ送り、新しい視点へ切り替える時点 に来ている
- 過去の真摯なエンジニアたちが残した 明確な原則と工学的思考 へ立ち返るべきである
21件のコメント
なぜ方法論をそんなに経典のように扱うのか分かりません。元の著者も方向性が違うだけで、教条主義的なのは同じだと思います。
結論がやや極端な気がします。商業化や形式化が問題になり得るとしても、スプリントやバックログのようなツール自体が役に立たなくなったわけではないでしょう。水平的で目標志向の会議文化が根付くのに役立った面もありますし。SDDの重要性が増したのはその通りですが、その仕様自体もAIと協調しながら素早く作成できるので、依然としてアジャイルだと思います。2週間単位のスプリントが数時間程度に短縮されたにすぎず、反復的に磨き込んでいくという本質はそのままだと思います。
同感です。
垂直的な意思決定の打破や、短いサイクルでの反復的改善だけを取ってみても、私たちに残すメッセージは大きいですよね（もちろん、プロジェクトマネジメントの手法やツールも同様です）。
「アジャイル自体は新しい洞察を提供できなかったうえ、アジャイルを擁護する人たち全体を盲目的なアジャイル信者のように決めつける」という結論は、過激すぎるように思います。
同感です。アジャイルは今でも有効です。現場を経験したことのない人たちが空中に向かって話しているようなものですね。
ばかげた文章ですね。肝心なのは、spec.自体をアジャイルに書かなければならないということなのに……。アジャイルとは、顧客の要求事項の変化に素早く対応して適応することです。
こうしたアジャイルに対する誤った誤解や中途半端な思い込みを持つ人たちのせいで、アジャイルであれ開発文化であれ、おかしな方向に進んでいくのです。
spec自体をアジャイルに書くとはどういうことですか？
そもそもアジャイルとは何なのか分からない、というのがあの記事の核心です。アジャイルにはこういう特性があり、こうしなければならないと語るばかりで、肝心の「これはアジャイル手法で作られた製品です」と示してくれる文章はこれまで見たことがありません。宣言文を見ても今ひとつ腑に落ちませんでした。一度見せてもらえないでしょうか。
ケント・ベックのエクストリーム・プログラミング、ジェフ・サザーランドのスクラムなど、ほとんどのアジャイル手法の本に基本的に書かれている内容です。ユーザーストーリーを見てもよいでしょう。アジャイルの根幹が、顧客要求への素早い適応のための短いスプリントとデモにあることを、ほとんどの人はよく分かっていないようです。
3、4番ですね。仕様を詳細に書くことには際限のない深さがあります。組織に合った程度というものがある、ということです。成功したサービスがどのように作られたかという歴史を見ると、99%のケースでは、仕様を正確に書くことにあまり力を入れすぎないこと自体が重要だったと認識しています。そこに埋没しないということです。サマナーズウォー、ダンジョン&ファイター、ジグバン、リネージュのようなものがどう作られたかを見れば分かります。
ウォーターフォールのサイクルが1日で回るとしたら？
最近、こういうケースをより頻繁に見かけます
ひどいことに、これがいちばん頻繁に目にするもののようですね……
韓国国内でアジャイルは、開発者へのスケジュール圧迫のための道具でしかなく、それ以上でもそれ以下でもない。
ある基準では、みんながアジャイルなんですよね。今のように素早くデプロイしてフィードバックを受け取る時代が、かつてあっただろうかと思います。
短いサイクルでのリリース以外に、アジャイルに何が残っているのか分からない。
バックログやスプリントも別の形でそれ以前からすでに存在していたし、顧客とのコミュニケーションも現実に合わない部分が多い。結局、アジャイルよりもDevOpsの改善のほうが、開発の向上にはるかに大きく寄与したと思う。
この記事自体がアジャイルではない！
コードを読む必要がまったくないわけではないので、その観点では「ドキュメントよりコード」という言葉は有効な気がしますし、指示文としてのドキュメントは実装主体であるLLMが読むべきなので、その観点では同意できます。したがって、結論としては両方が同時に重要なのではないかと思います。
今のLLM生産物の問題は、運用段階で蓄積される負債です。継続的な運用のためには開発者がコードに関与しなければならず、そのためには少なくとも今のところ、コードはドキュメントの代わりを果たせるべきだと考えています。
あえて慎重に反論を述べるなら、私はコードがドキュメントの代わりにはならないと考えています。programming language はまだ自然言語の豊かな表現力や伝達力を備えていませんし、現実的に言って、あれだけ多くのコードをいったいいつ全部読むのでしょうか。
ドキュメントの代わりになり得るコードを持つことは希望であり願いですが、登ることのできないバベルの塔のようなものです。
むしろ OOAD をしっかりやるほうがまだ良さそうです。
逆に、自然言語がコードを代替することも難しいと思います。自然言語はコードに比べて素早い反面、あまりにも抽象的です。コンピューティングのためには結局ディテールを埋めていく必要がありますが、この役割を自然言語が担うには無理があるように見えます。
SWを書くうえで問題になるのは抽象性というより曖昧さです。自然言語は本質的に曖昧です。多義的でもあります。 だから自然言語でコーディングしようとする試みがうまくいかないのではないかと思います。
こうした状況で、自然言語がコードを置き換えるなど到底ありえません。
おっしゃるご意見には共感します。
コードで置き換えられない部分が確かにあります。
そういう意味で少し違う形で説明するなら、可読性の高いコードは、ドキュメントを作る必要がない状態を生み出す、ということを言いたかったのです。
ソフトウェアが長期化するにつれて蓄積されるドキュメントも、開発者に認知負荷を与えますから。コードとドキュメントを行き来する作業を減らそう、というのが核心です。
コードだけを完全に残せるとは思っていません。
文脈や置かれた状況によって変わることもあると思いますね。
コメントありがとうございました。
Hacker Newsの意見
Agileを通じて興味深い現象を見た
失敗すると「十分にやっていなかった」と解釈される構造になっている
クラウド、マイクロサービス、緊縮政策などでも同じパターンを見てきた — 失敗の原因は常に実行不足であり、アプローチ自体が間違っていることは決してないという信念が働く
チームがAgileを試してうまくいかなければ、「それは本当のAgileではなかった」という防御論理が登場する。結局Agileは失敗しえない概念になってしまう
Agile Manifestoは価値と原則だけを扱う。問題は、それを無理やりプロセスに押し込める組織文化だ
失敗時に内面を振り返らせる構造が必ずしも悪いわけではない。外部のせいにするより自己省察を促すという点では、健全なシステムかもしれない
顧客に約束したロードマップと柔軟な対応は両立しにくい。現実には、計画中心の組織がAgileを真似している程度だ
失敗すると「エージェントをもっと使うべきだった」という結論になる。まるで「トークンはいくらあっても足りない」という冗談のように聞こえる
私はAgileの形式化を恐れるようになった
40人規模のチームをうまく運営したことはあるが、本当のAgileはたった4つの文に要約される — 人、動くソフトウェア、顧客との協業、変化への対応
問題は、「大文字のAgile」がむしろ柔軟性のないプロセスに変質してしまったことだ
人数が増えると目標の足並みをそろえるのが難しくなり、結局は統制と手続きが必要になる
チケット作成権限すら制限するなど、柔軟性とはほど遠かった
文書化が不足すると保守不能になり、最終的にはYOLO開発に流れてしまう
私がいた大企業のAgileは嘘だった
ある同僚は「次のスプリントの仕事を前もってやっておけば、いつも期限通りに終わる」と言っていた。
つまり、Agileは実際の仕事より指標を生産するシステムとして機能していた
管理者は数字が上がるのを見て満足し、製品は統計の副産物に成り下がる
Agile Manifestoの原文をあらためて見る価値がある
それが唯一の合意点だ。Agile以前のウォーターフォールがどれほどひどかったかを思い出すべきだ
固定された日程と成果物を強要していた時代を終わらせた武器だった
チームが自律的に働くと自分の立場が脅かされるからだ
Kent Beckが「Extreme Programming」で述べたように、Agileは想像上の全能性の専制を避けようとする試みだった
かつてのウォーターフォールは設計段階ですべてを予測しようとし、学習とフィードバックを無視していた
しかし時がたつにつれ、Agileの儀式と形式が本質を覆い隠してしまった
私は今でもAgentic programmingは好きだが、結局重要なのは文脈をつなぐ人間の役割だ
元の記事は混乱していた
Agileが新しいものを何も生み出していないと言いながら、LLMがコードを書くならAgileは死んだと主張していた
しかしAgileの核心は、不完全な仕様を認めて反復的に改善することだ
この原則は今でも有効だ
Agileはその一つの変種にすぎず、ひどい実装が多かっただけだ
良い製品は結局仕様 → 学習 → 修正の循環から生まれる
Backlog Grooming、Sprint Reviewのような手続きが、かえって変更を抑制している
仕様ベース開発は長続きしない気がする
やはり動くソフトウェアを作って反復するほうが速い — 結局はAgileへの回帰だ
仕様の品質が上がり、コードよりレビューしやすくなった
GitHubリンク 参照
マニフェストにはDaily StandupやAgile Coachといった言葉はない
本質は「プログラマーをマイクロマネジメントするな」ということだ
つまり、動機づけられた個人に環境と信頼を与えよというメッセージだ
Kent Beck、Martin Fowlerなどの創始者たちは、もともと柔軟なガイドラインを意図していた
しかし時間がたつにつれビジネス化され、盲信的な追随者が生まれて混乱が大きくなった
成功するかどうかは結局人の力量と姿勢にかかっている
スプリントの長さも状況に合わせて調整すべきで、仕様がなければチームが自分たちで作る必要がある
AI時代でも、Agileを賢く使う人がいるなら依然として有効だ
「Specを書く」とは正確には何を意味するのか気になった
私がこれまでやってきたすべてのAgileプロジェクトには設計文書があり、チケットはその文書から派生していた
文書のないチケットベース開発は地獄のように思える
みんなが自分に都合よく解釈する
チケット中心のアプローチのほうが、むしろより純粋なAgileに近い
偽物のAgileでは、POやPMが作った文書が真実であるかのように扱われる
あなたが言ったやり方こそ、私が意図した**「仕様を書く」ことの意味**に最も近い