AgileとJiraのゆっくりとした苦痛に満ちた死
(ehandbook.com)"AgileはもはやAgileではなくなったのだから、今こそAgileはJiraとともに消え去るべき時だ"
- ソフトウェア開発サイクルはますます長くなり、技術チームはますます大きくなり、開発管理にはますます多くのアプリが必要になり、実際にコーディングする人はますます減り、より短い期間の中で、継続的なチェックポイントの間に進捗はますます少なくなっている
- アジャイルはどこから間違ってしまったのだろうか？
- アジャイルは、文書中心の重い従来型ソフトウェア開発プロセスの代替として、2000年代初頭に生まれた方法論である
- しかし現在では、アジャイルは従来の複雑なプロジェクト管理手法へと変質しつつある
技術の肥大化（Tech Bloat）が主要な問題
- 多くの人がアジャイルを捨てる、あるいは捨てようとしている主な理由は、技術の肥大化にある
- 技術の肥大化は、あらゆるテック企業の敵であり、社内または外注の開発チームを持つ非テック企業にとっても危険である
- 技術の肥大化は技術的負債とは異なるが、技術的負債を生み出す
- 技術の肥大化の症状は次のとおり
- 顧客と繰り返し会話しているのに、顧客行動の専門家にはならない
- 締め切りと納期を絶えず評価し、再評価する
- すべての詳細が文書化されるまで、開発プロセスを始めることを極端にためらう
- 最もリスクの高い作業ではなく、最も簡単な作業から始めようとする動機が生まれる
技術の肥大化がもたらす混乱した結果
- 文書化の増加
- 何を、なぜ開発したのかだけでなく、どのように開発したのかまで追跡する文書化が、プロセス全体に入り込む
- この「どのように」がステータス更新の焦点となり、チームは自分たちの働き方を絶えず再評価する
- チームは仕事を進めることよりも、なぜ仕事が終わっていないのかを議論することに多くの時間を費やす
- 頻繁な締め切り設定
- より頻繁なチェックポイントごとに、さらに多くの締め切りが設定され、本質的に創造的なプロセスのあらゆる転換点でマイクロマネジメントを生む
- これは質の高いソフトウェアの生産に逆行する。すべての作業が、どれだけうまく実行されたかに関係なく、決められた期限に合わせて引き渡されるからである
- 再評価プロセスにおける絶え間ない疑念
- 再評価の期間中に絶え間ない疑念があるため、ベストプラクティスは確立されず、無駄は排除されず、規模の経済も認識されなくなる
- 生産プロセスのマイクロマネジメント
- 機能全体の30%ほどが完成した頃には、もはやそれは優先事項ではなくなっている
- 組織は、ロードマップが依然として成功する製品づくりを定義しているかどうかに関係なく、ロードマップに載っているものを作り続ける死のスパイラルに陥る
- 最終結果
- 製品は、多様で相反する顧客要求の重みに苦しめられる
- 機能はしばしば市場投入が遅れ、市場に最も適した方法や順序ではなく、技術チームに最も都合のよい方法や順序で提供される
- 結局、営業・マーケティングチームは自分たちが何を売っているのか分からず、顧客も何を買っているのか分からないため、反発が起こる
- すると組織は大規模な整理に乗り出す
世界に必要なのは、より多くの機能ではなく、重要な仕事をよりうまくこなす軽量なソフトウェア
- これは新しい概念ではないが、あらゆる方法論が最終的にはそこから離れていく概念でもある
- 人々はやがて、トヨタ方式はトヨタにとって十分にトヨタ的なのかと問い始め、それ自体が仕事を増やす行為になってしまう
- アジャイルは今や、かわいい名前と短い会議、そしてより多くのルールを持つPMPになってしまった
- 問題はアジャイルというアイデアそのものではなく、それを実行し統制するリーダーシップの欠如である
- 効用より締め切り、成長より削減、進歩より節約に焦点を当てる中間管理職の問題である
GN⁺の見解
- アジャイルは本来の意図とは異なり、官僚化・形式化され、ソフトウェア開発を遅らせる要因になっている
- 技術の肥大化は、アジャイルに限らず、あらゆる技術組織で警戒すべきリスク要因である
- 文書化、締め切り設定、マイクロマネジメントなどが、かえって品質とスピードを低下させる可能性がある
- アジャイルの本質は顧客中心、協働、柔軟性などにあるため、形式に縛られるのではなく原則を改めて思い出す必要がある
- ソフトウェア開発で重要なのは、より多くの機能ではなく、中核機能をうまく実装することである
- 組織文化とリーダーシップがアジャイルの成否を左右するため、技術マネージャーはこの点に注意を払う必要がある
- アジャイルを超える新たな方法論を模索すべき時期が来ているのかもしれない
17件のコメント
元記事が有料記事なので最後まで読めてはいないのですが、訳文の表現はもう少し整えるとよいと思います。
「AgileはもはやAgileではなくなったのだから、今こそAgileはJiraとともに消えるべき時だ」
=> 「Agileが
being agileであることをやめてしまったので、今こそAgileはJiraとともに消えるべき時だ」大文字のAgileと小文字のagileを区別して使う考え方がありますし、
being agileとdoing agileは互いに結びついていますが、区別して考えます。being agile by doing agile.アジャイル導入の理由が重要ですよね。開発をうまく進めるために導入するのでしょうか？ いや、お前たちが遊んでいるように見えるのは我慢ならない。どれだけ一生懸命やっているのか、私が一度見てやる。そんなマインドで導入するんです。だから地獄になるんですよね。
このあたりまで来ると、アジャイル準拠チェックリストが必要になりそうです。
アジャイルか waterfall かという問題以前に、人や文化などの環境がそのままなら、どれほど斬新な開発方法論を持ち込んでも、結局は K-OOO 化する道しかありません
要件変更が（ほとんど）ないのであれば、開発する側にとってウォーターフォールが本当に楽な方法であるのは確かです。要件変更さえなければ、ですが……
Kアジャイルは再評価もないのに…!
顧客 : この画面はボタンがここにあるのがよさそうですね
開発者 : （徹夜することになるな、新規案件もあるのに）
顧客 : 別の画面にはボタンが必要ですね
開発者 : （誰か分身の術を使ってくれ） はい、ハハッ..
顧客 : まだできていないんですか？ スケジュール的にはもう全部終わっているはずでは？
開発者 : （助けて） はい..;;
アジャイルをアジャイルらしく長期的に活用している事例はあまりなく、
ほとんどの組織が締め切りの短いウォーターフォール業務へと収斂していくようですね。
アジャイルが問題なのではありません。それを実践する人が問題なのです。どんな方法論を持ち込んでも、結局はそれを実践する人がどうやるか次第です。私は、アジャイルは方法論ではなく、一定のサイクルごとに製品を成長させていく精神に近いものだと考えています。これを見失って盲目的にプランニングや振り返りをしても、時間の無駄のように思います。
韓国式アジャイルだけがそうなのかと思っていましたが、グローバルな現象だったんですね。
何か見当違いなものを延々と叩いている感じはしますね……。アジャイル宣言に合っているかどうかで判断すべきなのでしょうけど……
アジャイル宣言に参加したuncle bobもこの問題を早くから理解し、誤ったアジャイルを正すために2019年に『クリーン・アジャイル』を出版しましたが、いまだにこうした問題が続いていますね。個人的には、アジャイルには標準ガイドラインがなく、「文化」という曖昧な表現を使っているためだと思います。具体的な標準ガイドラインが示されるとよいですね
筆者は、おそらくどんな方法論であっても、それが官僚化した時点で捨てるべきだと主張するのではないかと思いますね。
同意します。誤ったアジャイルを実践しておいて、アジャイルが間違っていると語るケースが増えているように思います。
一方で、登場してからかなり時間がたっているのに、プラクティスをしっかり積み上げるのが難しいというのは、避けられないことなのかもしれません。
巡り巡って、結局は元どおりなんでしょうか？
Hacker Newsの意見
Agileの問題点
Agile Manifestoの原則
Agileの本質
Agileの柔軟性
JIRAに関する意見
Agileの起源
Agileの現在
JIRAの問題点
Agileの適用