恐ろしいUMLフィーバー[1] の発見と特性解明から８年が過ぎた。あれは、地球上のいたるところで、ソフトウェアプログラム開発において、無駄と非効率を生み出した。しかし、この間に、よく知られた殆どの歪は、ソフトウェアエンジニアリング界の表面から徐々に侵食してきたものであることを報告することは、大きな喜びである。極めて稀だが、そのような活動が成功するソフトウェア開発への新しく、改善された、革命的なアプローチだ、という誤解された信念のために、かつてあるプログラムは、発電機を製造するUMLダイアグラムになった
UMLフィーバーの歓迎すべき沈静化にも拘らず、ソフトウェア産業の銀の弾丸製造工場の炉は、ナイーブで、絶望的そして無知な者たちのために高級な弾丸を製造するのに、ずっと忙しい。銀の弾丸は、傷つく方法でソフトウェアプログラムのために使われている。これらの銀の弾丸による損傷は、ソフトウェア開発を悩ます幾つもの病気を生み出してきた。これらの病気は、未だ診断や治療を容易にする目的で、特徴づけられてはいない。これら観測された病気の１つがアジャイルフィーバーである。
アジャイルフィーバーは、ソフトウェアを開発するために、アジャイルベースのプロセスを採用したり、応用したりすることに関して、その他の点では分別ある人々から常識を奪う１つの条件です。アジャイルフィーバーの結果は、コスト的影響を伴って、アジャイルベースのソフトウェア開発プロセスの誤適用、誤使用、誤解に寄与してきた。例えば、マネージャのパフォーマンス基準に、いくつのプロジェクトでアジャイルを採用したかを用いた。例えアジャイルの採用が適していなくともである。ROIの望みがない状況なのに、アジャイルを採用したプロジェクトもある。また他の例では、トレーニングや再編に投資したが、以前と全く同じ方法でソフトウェアを開発し、アジャイル辞書から取ってきた新しい用語を使っていた。
この記事を読んでいるかもしれない、あらゆる Fragilistas1 が怒る前に、この記事は、アジャイルに対する攻撃で、その著者に対してひどい事を言って、復讐されなければならないという信念からの怒りである。怖くないが。さらに、この記事では意図的に、大規模なチームへのアジャイルのスケーラビリティ、安全上重要なソフトウェアを開発することへの適用、あるいはその一般的なビジネス価値に関連する論争の炎をあおぐことを避けるつもりである。世界の学者は、これらおよびその他の問題を解決することに注力している一方で、実際のソフトウェア開発作業では、いくつかの共通した形でアジャイルを誤用して、本当に金や時間を無駄にしてる。この記事の目的は、彼らが認識し、治療することができるように、アジャイルフィーバーの観点から、それらの一般的な形態を特徴付けることである。
後述のアジャイルフィーバーは、アジャイルベースの??プロセスを採用しているソフトウェア開発組織の一部を感染させる最も一般的なものである。多くは関連しており、いくつかは他の前提条件だが、ほとんどは、主にアジャイルベースの??ソフトウェア開発プロセスの採用と実行を導く資格のない意思決定者によるものである。最後に、認識して欲しい非常に重要なことは、これから述べるフィーバーは、理論的なものではないし、実際に観測されたように、その存在が議論できるものではない、ということである。しかし、議論できるのは、これらのフィーバーの原因とそれらを対処したり、避けるための最も賢明な方法である。
フィーバー（熱）
アジャイルフィーバーは、一般的に、アジャイルベースのソフトウェア開発アプローチへの移行と関連する時間枠に沿った３つの段階の１つに属するように特徴づけることができる。初期、中期、最終段階である。多くの読者が正しく認識しているように、アジャイルフィーバーの一部は、非常に上手く段階に当てはまるかもしれないし、フィーバーの一部は、ある形で全段階に跨ぐかもしれない、という点で曖昧である。この記事は、 アジャイルフィーバーを完全に分類することにはあまり関心がなく、その症状を識別し、特徴づけることで、できるだけ早くそれらを認識することができ、治療することができるようにすることである。
初期段階のフィーバー
初期段階のアジャイルフィーバーは、集団的で全ての中で最も危険であり、最もかかる人が多く、簡単にかかってしまい、ソフトウェア開発の労力に損害を与える、最高の可能性を秘めている。アジャイルベースの??開発プロセスの導入を考慮したソフトウェアプロジェクトは、誤解や誇大広告とは対照的に、すべての決定が事実と価値の追求に基づいて行われていることを確実にするために、初期段階のアジャイルフィーバーを検知するための意識を高い状態に維持しなければならない。次の図は、初期段階のアジャイルフィーバーを示している。
- Lemming フィーバー: Lemming フィーバー のある人は、本当だろうが嘘だろうが単に言われてきたことに基づいてアジャイルを知っている人である。自分で経験した知識は無い。Lemming フィーバーの結果は、非常に危険な可能性がある。それは、もし感染した人がプロジェクトのアジャイル採用実績に関係している、いかなる種類の意思決定の責任を持っている場合である。危険は、悪い意思決定の更に大きな結果と下位の者の助言を却下する能力によって、プロジェクト組織の害のある年寄りの関数で増加する。 Lemming フィーバーは、最も危険なアジャイルフィーバーの１つであり、通常多くのフィーバーの前提条件であり、他のすべての症状を悪化させる傾向がある。
情報は、知識ではない。
Albert Einstein
- イージーボタンフィーバー: このフィーバーはアジャイルを採用することがステープルのイージーボタンを押すのと、同じくらい簡単であると考えている人の中に存在し、結果として、彼らのプロジェクトは、感染直後のレミングフィーバーの段階で想像したアジャイルのメリットを享受し始めることができる。しかし、プロジェクトの既存の開発手法によって、アジャイルアプローチへの変更が顕著な変化を意味するかもしれないし、以前より曖昧な要求で開発し、手直しは現実的に可能であることを理解し、計画がずれるのは、顧客が望む製品を進化させる文化の一部であることを理解することで顧客との関係を作り直すことになるかもしれない。典型的な感染者は、アジャイルの生産性改善をもたらすことが一般的に約束しているフィーチャであることやそのフィーチャが自分達のプロジェクトに当てはまらない可能性があることをほとんど、ないし全くわかっていない。
直ぐ得られる満足感は、そう早くは来ない。
Meryl Streep
- 万能フィーバー: 万能フィーバーの犠牲者は、アジャイルベースの開発プロセスがいかなるそして全ての開発活動に適用可能であり、ROIも問題ないと信じている。調整はアジャイル採用の重要な部分であるが、特定のプロジェクトのコンテキストに合うように調整すべき程度は、その適切さを測る重要なバロメーターである。毎日の会議が居場所の問題でなくされたり、顧客の関与が無関心のためになくされたり、日程の柔軟性が厳しいデッドラインのためになくなったり、そして対応できないために要求の進化がなければ、アジャイルは、合っていないのであろう。万能フィーバーは、他のフィーバーとは独立した精神的な考え方であり、他のは、一般的にアジャイルの戦術的誤用に関係している。
そんなにも無知がはびこる理由は、そのような人はそれを共有したがるからだ。
Frank Howard Clark
- 骨折り仕事フィーバー: 骨折り仕事フィーバーは、しばしば万能フィーバーが深刻化したものであるが、感染者は、アジャイルが必ずしも全てのソフトウェア開発活動に適用できるとは信じていない。このフィーバーは、アジャイルベースのソフトウェア開発プロセスを無理矢理ルーチン化する決定がされた時に、プロジェクトで猛威を振るう。しかし、 Agile Sweet Spot[2]にほとんど、あるいは全く資産を持っていない。 Agile Sweet Spotとは、成功の可能性を増すためにソフトウェアプロジェクトが持つべき特質の集合のことで、それは、アジャイルベースのソフトウェア開発プロセスを採用する時に適用される。骨折り仕事フィーバーの古典的症状の特徴は、アジャイルが採用されるのが、プロジェクトの開発ライフサイクルで非常に遅いことや、動かせない日程、厳格な要求、柔軟性がほとんどない、ことである。これらはアジャイルアプローチ採用の利点を台無しにする。
物事を悪く考えない長年の習慣によって、正しいものを表面的に見るようになる。
Thomas Paine
- ハレルヤフィーバー: ハレルヤフィーバーに感染した人は、アジャイルがコンピューティング時代の幕開け以来、コミットしている開発の罪からソフトウェア産業を救うためにやってきたことを非常に感謝している。その感染者は、リスク軽減と早期の顧客関与を促進するために、ソフトウェアエンジニアによって長年利用されてきた反復的でインクリメンタルな開発のような戦術をアジャイルの傘に下に分類し、間違ってそれらを賞賛している。ハレルヤフィーバーは、しばしば Cook the Books Fever に発展する。この感染者は、アジャイルベースのソフトウェア開発プロセスの採用をあらゆる観測された生産性改善によって信じており、長期的に認識されたベストプラクティスの採用を正しく信じるのとは、反対である。
私は戦争が大嫌いであるが、それに参加せずに称える人間は、もっと嫌いである。
Romain Rolland
- オームフィーバー:アジャイルフィーバーに何らかの形で感染した、あらゆるソフトウェア開発活動には、少なくとも一人がオームフィーバーにかかっている傾向にある。このフィーバーでは、アジャイルが誤って適用されたり、期待通りに上手く行っていないことを言われると、その防御として、感染者が電光石火の速さで、彼らのソフトウェア開発プロセスがベースにしているどんな出版物あれ、そこから章や節を引用する。早期アジャイルフィーバーに分類されているが、実際は全段階に広がり、ただ時間と共に更に深刻に広がって行くだけである。感染していない人の典型的な反応は、オウムフィーバーにかかった人間の首を締めたい、という強い願望を膨らませることである。
オウムに「需要と供給」という言葉を教えれば、経済学者が一人できあがる。
Thomas Carlyle
中間段階のフィーバー
中間段階のアジャイルフィーバーは、一般にアジャイル導入の後半に現れる。しかしまた、導入の初期段階に存在することもある。これらのフィーバーは、主にアジャイルが最高に合いそうな開発文脈でずっと誤解した結果であり、この場合アジャイルにそぐわない文脈でそれを強制しようとして、副作用ももたらすのである。次の図は、中期段階のアジャイルフィーバーを示している。
- 同音異義語フィーバー: このフィーバーの主な症状は、感染者が辞書にある agileの定義とソフトウェア開発の方法論を意味する大文字のAgileと混同することである。感染者は、一般的に辞書が agilityを速さ、軽さ、動きやすさと定義しているの知っているので、Agileの利点は、何とかタスクをより早く仕上げることだ、と信じている。これらの利点は、主として、多くの前線におけるコミュニケーションの改善と文化の変化によるものである、という一般認識とは反対である。 同音異義語フィーバーの感染者は、決まって Agile と agileを取り違って、プロジェクトそして／あるいは開発プロセスを両方の違いを本当に理解せずに、語るのである。感染の可能性のテストとして、感染の疑わしい人に、なんでプロジェクトを "Agile" にするのか尋ねなさい。
誤解が人々に利点として役立つところでは、人は自分を理解するには、無力です。
Lionel Trilling
- Cargo Cult Fever: 積荷信仰フィーバーは、基礎となる本質を理解せずにアジャイルのようなプロセスの表面的な外観を真似る人々に感染する。このフィーバーにかかると、このプロセスを使っている人々は、優先順位、日程、あるいは制約を変えることを基にしたプロセスを進化させたり、あるいは調整したりする文脈を持っていない。このフィーバーに感染した組織は、しばしば「地獄への道フィーバー」になってしまうが、変化する条件に適応する能力がない結果である。
理由はそれ自身に従う。そして無知は、そうであるように命令されたものには何でも従う。
Thomas Paine
- サイモンが言っているフィーバー: サイモンが言っているフィーバーの感染者は、アジャイルに関連した活動に参加することで認識されるが、彼らはそのような活動がなぜ行われれるのか、あるいはなぜ自分達がそのような活動の一部なのか、あるアジャイル「チェックリスト」に含まれているのが理由である以外、全くわかっていない人々である。このフィーバの最も共通の原因は、すべての開発活動を付加価値を加えることに結びつけられず、単に進歩の幻想でしかない、心地よい、ロボットによる活動になってしまう。このフィーバーは、 積荷信仰フィーバーが激しい組織に非常に普通に存在する。
ルールは愚か者の服従と賢者の手引きのためにある。
Douglas Bader
- 片目の王様フィーバー: このフィーバーは、アジャイル導入の成功に大きな影響を及ぼす潜在力があり、アジャイル盲信者が自分達より少しばかり良くアジャイルを理解している人にコーチされた時に発生する。片目の王様フィーバー が起きた場合の大変共通な症状は、その特定の文脈にアジャイルを調整することに失敗したり、プロジェクトがアジャイルベースのプロセスを導入するのに見合うROIが得られる確率が低いことをコーチが認識し、それに従った活動をしないことである。
馬が盲になることを心配するな、ただ荷馬車をいっぱいにしろ。
John Madden
- 見猿、聞か猿フィーバー: このフィーバーは、アジャイル導入の成功に大きな影響を及ぼす潜在力があり、アジャイル盲信者が自分達より少しばかり良くアジャイルを理解している人にコーチされた時に発生する。片目の王様フィーバー が起きた場合の大変共通な症状は、その特定の文脈にアジャイルを調整することに失敗したり、プロジェクトがアジャイルベースのプロセスを導入するのに見合うROIが得られる確率が低いことをコーチが認識し、それに従った活動をしないことである。
無知の最高の形は、それについて全く知らないことについて拒否する時である。
Wayne Dyer
後期段階のフィーバー
後期段階のフィーバーは、主にプロジェクトが済んでしまった状況から最善なものを作り出そうとする条件を含んでいるフィーバーである。単独でも複雑な状況のもとでただ仕事を終わらそうとすることに加えて、アジャイルベースのソフトウェアの採用を正当化しようとする策略が見られるのは、稀ではない。次の図は、中期段階のアジャイルフィーバーを示している。
- GoofusとGallantフィーバー: このフィーバーの症状を一番良く要約するには、同名のHighlights Magazine の漫画を読んだ多くの人に馴染みのある話を使うのが良い。「Goofusは指示に従わないのでアジャイルの宣伝する利益を得ることに失敗しているが、Gallantは、従っうので予算内で予定前にソフトウェアプログラムを提供している。」貴方は、Goofus と Gallantフィーバーに感染した人からこれらの言葉を正確に聞いていないかもしれないが、そのメッセージはおおよそ同じである。アジャイルベースのソフトウェア開発プロセスの導入による期待を達成できなかったのは、間違って行ったからである。主張するだけの真実はあるかもしれないが、もしプロジェクトの文脈が始めから Agile Sweet Spotになければ、誰もアジャイルを「正しく」行うことはできない。何だって？５０人以上のスタッフが同じ場所にいないので、毎日スタンドアップミーティングはない？顧客による要求の進化がない？顧客は地球の反対側におり、固定価格契約で、固まった要求であり、またプロジェクトがアジャイルを導入したことさえ知らない。 Goofus と Gallantフィーバーは典型的には、アジャイルが合っていないのに無理矢理プロジェクトに入れると発症する、骨折り仕事フィーバーが深刻化したものである。
非難すべき人を探すのは、常に成功する。
Robert Half
- Road to Hell Fever: 地獄への道フィーバー：このフィーバーは、アジャイルの宣伝する利益を享受する意図だった組織に一般に存在するが、理由が何であれ、認識できたはずの開発プロセス活動において、アジャイルの利点を実行しなかった。結果として、 地獄への道フィーバーに感染した組織は、アジャイル以前の形でビジネスを行う症状を示す。すなわち、トレーニングと再組織化に相当の投資した後でさえ、スタッフが同じ場所におらず、顧客とのやり取りも稀であり、要求の進化は柔軟性が無く、杓子定規な日程に固執することが続けられるのである。Goofus と Gallantフィーバーに似て、 地獄への道フィーバーの症状は、非常に良くあるのが、アジャイルベースのソフトウェア開発アプローチが合わない文脈で無理強いされる、以前の骨折り仕事フィーバー感染の後期段階の二次的な影響である。
無知は、奇跡の信仰が育つ土壌である。
Robert Green Ingersoll
- 帳簿ごまかしフィーバー: このフィーバーは、一般的に「従来型の」ソフトウェア開発アプローチからアジャイルベースのものに組織を移行するのに必要なかなりの投資を時々行う責任がる人達に感染する。この症状の中には、実際は長期間認められているベストプラクティス導入の結果である利益をアジャイルによるものだ、と偽って主張するのと一緒に、アジャイルの下での生産性を測定する創造的なアプローチがある。帳簿ごまかしフィーバーは、最も危険なものの一つで、その関連した成功物語は、他のソフトウェア開発活動における Lemmingフィーバーの原因やアジャイルフィーバーの感染拡大の可能性がある。
フィクションは、現実が覆い隠す真実を明らかにする。
Jessamyn West
防御手段
アジャイルは前述のフィーバーの原因では無く、人間が原因である。これらの人々は、充分目的があり、最高にいい学校で学んできたり、高いIQを持っていようが、多くの次元でアジャイルについて無知である。彼らは、アジャイルが宣伝している生産性改善のフィーチャの基であるアジャイルの品質について殆ど知らない。彼らはアジャイルを導入するだけでこれらの改善は保証される、と信じている。あるいは利益を提供する、アジャイル能力の程度は、プロジェクト特有の文脈に著しく依存することを殆ど知らない。
アジャイルフィーバーの多くの形態に対する防御策は教育である。不幸にして、そのような教育を猛烈に必要な感染者は、しばしばアジャイルについて何がわかっていないかについて知らないか、知らないことを学ぶことについて物分かりが悪いか、彼らを教育しようとしている人達は、明るく燃えるアジャイルの光をこれまで見たことがない、単なる田舎の馬鹿者である、と信じている。
ソフトウェア開発プロセスを定義する目的は、それをアジャイルベースにすることでではなく、プロジェクトのユニークな文脈において、最も効率的で生産的であるべきである。The Frog and the Octopus Model [3]は、あらゆるソフトウェア開発活動に、ある形で関連する９つの普遍的な要素（カエル）とこれらの普遍的な概念に影響するプロジェクト固有に変動する要因セット（タコ）を提供している。どんな銀の弾丸のガラクタが現在流行っていようが、このモデルをプロジェクトのソフトウェア開発プロセスを定義する手引きに使うことができる。
実際、 The Frog and the Octopusのようなモデルを使うのは、アジャイルフィーバーに感染した人々を引きこむのに効果的な方法である。なぜならモデルは、ソフトウェア開発をまとめて議論することでアジャイルへの言及を除くからである。例えば、アジャイルベースのソフトウェア開発プロセスが最高に合うものではない、と言って、感染者を直ちに守勢に立たせるのではなく、よりよい戦術は、一般的な意味で、開発戦略導入の適応性と価値を議論することである。そのような議論の中に、アジャイルベースのプロセスに関連している典型的な検討事項が含まれているかもしれない。例えば、要求の柔軟性、日程の弾力性、顧客参加の程度、スタッフを同じ場所に置く能力、プロジェクト文脈に関連するだろう他のいかなる特性がある。
一旦、適応可能な開発検討項目が識別されたら、それらの１つ１つについて、特定の開発アプローチに関連した議論はせずに、実現の妥当性、価値、コストを評価する必要がある。アジャイルベースのソフトウェア開発プロセスの導入と調整は、流行ではなくROIを基にされるべきである。アジャイル導入のコストと価値は、変わり、プロジェクト特有の文脈に依存するので、一つのプロジェクトで得られた利益は、全てのプロジェクトがそうすることで期待できるものを代表するものではない。
この記事で識別され、特徴づけられたアジャイルフィーバーは、おちょくったスタイルで書かれたが、アジャイルの誤用や誤適用に関連した例は、本当であり、貴方の周りのソフトウェア開発活動でも起きているだろう。これらの問題とは対照的に、競合会社に仕掛けられたならず者従業員が原因の産業サボタージュの場合、彼らは悲劇的に自ら自分に課しており、彼らを矯正できる専門家がいてでも、多くの場合続ける。アジャイルベースのソフトウェア開発プロセスの導入と調整に関与する意思決定者としての役割において、無資格な者、未経験な者、偏見のある者を再検討しない限り、恐ろしいアジャイルフィーバーを撲滅できる望みは殆ど無い。
参照
[1] UMLフィーバーによる死。
Alex E. Bell, Death by UML Fever, ACM Queue, 2(1):72-80, March 2004.
[2] Kruchten, P.B. 2010. 文脈に当てはめるアジャイル
Software Development. EuroSPI 2010 カンファレンス
(Grenoble, France, September 3-5, 2010).
ここから入手できる
[3] The Frog and the Octopus:ソフトウェア開発の概念モデル
Philippe Kruchten
About the Author
Alex Bell氏は、30年以上のソフトウェア・エンジニアリング経験があり、～で働いた。彼は、海軍、空軍、陸軍ベースのC4ISR プログラムの文脈でソフトウェア開発のあらゆる側面に関わってきた。彼は、カリフォルニア大学サンディエゴ校からシステムサイエンスの学士号を得て卒業 し、ソフトウェア業界における狂気を非難する幾つかの同様な記事を書いており、ボーイング社の Technical Fellowである。
1 Fragilistaとは、過敏で、アジャイルへの感知された攻撃に反応して、彼あるいは彼女の感情をコントロールする強さを欠いている Agilistaを描写した用語である。