【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

DeclineAndFallOfAgile - アジャイルの衰退と凋落

目次

アジャイルの衰退と凋落

この文書について

アジャイルの衰退と凋落

James Shore

アジャイル運動の衰退や凋落について話すのは奇妙なことだ. とても人気があるこの時期には, 特にそうだ. けれど正直なところ, ここ数年のアジャイル運動は, 衰退の途にあると私は思う.

最近の状況

自分の商売がここ数年で変化していることに私は気がついた. 初めのころ, 人々は私をアジャイルの導入の手伝いに呼び出したものだった. そういう人達に, 私はアジャイル計画や部門横断型チームからアジャイル工学のプラクティス(agile engineering practices)まで, 全部入りのパッケージ(a complete package)を提供していた.

今, 私を呼び出す人々の多くは, 既に(彼らのいう)アジャイルを導入済みだ. なのに彼らは混迷している. イテレーションのコミットメントに間に合わない. 技術的な負債がたまっている. テストに時間がかかりすぎている. そこで彼らは私を呼び, 助けを求めるのだ. 出かけていった私は, 名目上はアジャイルな, しかし山ほど問題を抱えたチームを目撃することになる. そこには楽しみや落ち着き, 順調な職場といった, アジャイルな組織に期待するものは見あたらない.

私が話をした他のコンサルタントも同じ体験を知らせてきた. "Scrum チームの救済で商売繁盛だよ" とある同僚は言う. おかしな話だ. なにしろ事実なのだから.

Scrum の役割

Scrum はアジャイル方法論戦争を勝ちぬいた文句なしの勝者だ. Scrum Alliance の膨大な(実入りの良い)認定 Scrum トレーナのネットワークや, 認定 ScrumMaster? の講座のおかげもあって, 人々が "アジャイル" というとき, それはふつう Scrum を指している. だから "Agile" が失敗したというとき, 失敗したのもふつう Scrum なのだ. そして Scrum は不完全で, その不完全は意図的なものだ. "Scrum は姑みたいなものだ." 最近の Agile Vancouver カンファレンスで Ken Schwaber は言った. "いつも君の欠点を指差してくる." そのフィードバックから学び, 問題を修正することになっているのが話のミソだ.

しかし, Scrum は短い周期で回り, 工学上のプラクティスは何も含んでいない. Scrum を使うチームが設計を投げ出すのはたやすい. 短い周期を使っていると, 事前設計(up-front design)はうまくいかない. そして, Scrum はそれに代わるものを用意していない. 連続的で漸近的な設計をしないと, Scrum チームは早々に技術的負債の巨大な落とし穴にはまりこんでしまう. そして2, 3 年後に, 私か私の同僚に電話がくる. "変更に時間と金がかかりすぎるんだ!" そんな声を聞いた. "我々にテスト駆動やらペアプロやら受け入れテストやらを教えてくれ!" その時点で, 本当の問題を正すためには多額の技術的負債を支払う必要があった. 数年を要する負債だった.

何より腹がたつのは, こうした事態はみな避けられるものだということだ. 環境が更地なら, Extreme Programming に含まれる確固としたアジャイル工学のプラクティスは, 最初の数ヶ月で元がとれる. XP のアジャイル工学プラクティスがないと, コードの品質や生産性は徐々に下がっていく. プラクティスがあれば, 生産性は低いところからはじまり, しかし徐々に増していく. 証明することはできないけれど, 感覚的には 8 週間目あたりで二つの曲線は交わる. もう少し早いかもしれない. アジャイル工学のプラクティスは重要というだけではない. 元がとれるのだ! 他には何をしようと取るに足らない... 自分が選択肢を理解しているのなら. Scrum はこの点で沈黙を貫いている.

Scrum の誤用

完全に Scrum が悪いというわけではない. アジャイル開発は良い工学プラクティスだけの話ではない. それはソフトウェア開発におけるヒトの重要性を知らしめる営みでもあるのだ. 部門横断型のチームを作り, 広帯域のコミュニケーションを行い, 継続的に反省と改善を続け, 価値を生み出し, 機会を生かすために計画を変えるのだ.

Scrum はこうした他の要素も含んでいる. チームは機能横断的にすべきだし, そのチームは同じオフィスの作業スペースを共有すべきだという. チームは価値を生み出すべきだというし, 毎スプリントの終わりには出荷可能な製品を作れという. そしてチームは自己組織化され, 問題に気付き, それを取り除くべきだ. Scrum はそう主張している.

おっと, 月次スプリントと日時スクラムみたいに機械的なものもあった. 他とくらべれば, どうってことはないことだ. けれど, 人々が受けいれているのはどの部分だと思う? そう, 正解 ... スプリントとスクラムだ. 短いサイクルを受け入れているが, 短いサイクルを持続可能にする優れた仕組みは何も受け入れやしない.

君のやりかたは間違っている

今や, アジャイルに失敗しているチームは山ほどある. こうしたチームは短いサイクルで動いている. 計画の頻度があがるほど作業をコントロールできるし, 問題を見つけて直すこともしやすくなる. いいかんじだ. 実際, 彼らはそれまでより多くの成功を経験する.

しかし, 彼らは共有ワークスペースで働いていないし, 広帯域コミュニケーションを強調してもいない. オンサイト顧客もいなければ, 部門横断型のチームもない. 毎スプリントの終わりまでに全てのストーリーを片付けることすらない. リリース可能なソフトウェアを作ることもない. 良い工学的プラクティスを使っているなんてまずない.

そういうチームでも, 自分はアジャイルだと言うだろう. けれど, 彼らはただ頻繁に計画(再計画)をしているだけだ. 短いサイクルと再計画という利点をアジャイルはもたらしてくれる. それは報奨であって方法ではない. これら疑似アジャイルのチームというのは, 野菜は食べずに毎夜デザートばかり食べているようなものだ... 他のもの, 真にアジャイルなものをすべて置き去りにして, 彼らは虫歯や太い脇腹, あげくの果ての失敗まで自ら御膳立てしている. いまは気分がいいだろうが, その気分は続かないだろう.

真っ最中での失敗

慣れ親しんだこと, 楽しいことばかりやってしまうのは, 人の性だ. そして, それこそがアジャイルに起きていることだ. 人々はアジャイルの方法論をプラクティス中華料理のメニューに見立て, いかすかんじのものを二三えらび, 残りはほったらかしている. 残念なことに, 彼らがほったらかしたものでアジャイルは回るのだ. Scrum は重要(だが面倒)なものを無視させるから, より性質が悪い. そして Scrum Alliance の指導者部隊は更に悪質だ. 良い指導者もそうでない人にも, 二日間椅子に尻をくっつけておく能力を示した人間には怪しい "ScrumMaster?" 認定を与えている.

こうして, 不幸なことだが, 多くの自称アジャイルなプロジェクトは失敗する. いままさに失敗しつつある. 最後には, アジャイルが非難を受けるだろう. そしてアジャイルは終わりを迎えるだろう. すべての流行が, いつかはそうなるように.

これはひどい話だ. 良いアジャイル...本当のアジャイル...は 実際にうまくいくのだから. 私は見てきた. 私の同僚は見てきた. 何百回も繰り返されて来たことだ. 何年もうまく回っているプロジェクトだってある. けれど, この数百の成功は, 数千の失敗に埋もれてしまう.

この流れを止めることはできるだろうか. わからない. もしかしたら, "アジャイル" のブランドを諦める時なのかもしれない. 明快な定義が無いせいで, 山ほどある機能不全のプロジェクトが自身を "アジャイル" と名乗れてしまう.

あるいは, アジャイルを売り物にするをやめる必要があるかもしれない. こう言った方がいいだろう. "アジャイルは難しい. 二日の座学で身につくものじゃない." あるいはこう. "申しわけないけれど, 工学プラクティスを使わなかったり, 広帯域コミュニケーションを使わなかったり, 強い顧客の声を受け入れていないなら, 君のところはアジャイルじゃない. 君はうまくいかないだろう. 他の方法を試した方がいい." Scrum の人気があるのは, それが易しいからだ. そして, それは問題の一部でもあるのだ.

何をするにせよ, すぐに手をつける必要がある. アジャイルはそこかしこで崩壊をはじめている. 流行の廃りが本当に有意義なアイデアをだめにするのは, 憎むべきことだと思う.