インタビューソフトウェアを高速化することも、問題が起こらない状態に保つこともできます。しかし、レイオフやリストラが頻発する時代に、その両方を同時に実現するのは、良く言っても困難であり、最悪の場合、不可能です。
アジャイルの現状が万全ではないという調査結果を受けて起きた騒動を受けて、The Registerに語ったジュナデ・アリ博士はそう述べています。
ジュナード・アリ博士写真: ニコラ・ボールド・フォトグラフィー
アリ氏は、英国の成人は新機能満載のソフトウェアよりも、きちんと動作するソフトウェアを好むという（自身が委託した）調査を指摘する。「彼らは実際、コンピューターシステムを使う際に、最新の機能をできるだけ早く手に入れることを最も重要でないと考えているのです。 」
アジャイル宣言の共著者が失敗率レポートを批判し、「再構想」プロジェクトを主張
続きを読む
「一般の人々は、データのセキュリティ、データの正確性、そして重大なバグがないことが自分たちにとって重要なことであると同意する可能性が高い。」
アリ氏によると、これはDevOpsやアジャイル手法で用いられるいくつかの指標とは全く対照的だ。「これらの指標は、ソフトウェアの提供速度と、問題解決のスピードを重視しています。」
銀行、小売業者、モバイルネットワーク、クラウドベンダーが最近相次いで障害に見舞われたため、障害対応に携わる人にとっては黄金時代と言えるでしょう。アリ氏は、信頼性の低いアップデートをリリースしたことが原因だと考えています。さらに、最近のCrowdStrikeの問題のようなインシデントがユーザーの信頼にどのような影響を与えるかを懸念しています。
結局のところ、ゼロデイ攻撃などから生じる正当なセキュリティパッチは、できるだけ早くインストールする必要があります。しかし、アリ氏によると、信頼の喪失はユーザーの抵抗につながる可能性があるとのことです。
多くのアジャイル原理主義者は、ユーザーストーリーだけで十分だと主張するでしょう。ユーザーストーリーは本質的には機能的な動作を記述するだけであり、一般化可能な仕様や非機能要件が欠けています。
アリ氏は膨大な量の悲惨な事例を所蔵しており、このテーマについて長年にわたり数多くのエンジニアリング上の大惨事を取り上げ、幅広く執筆してきました。しかし、彼の見解は、問題は必ずしもテストプロセスにあるわけではないというものです。「よくあることですが、典型的なコンピューターの壊滅的な障害は、初期の要件エンジニアリングプロセスに欠陥があることから始まります。」
「そして、問題は連鎖的に発生します。なぜなら、多くの場合、こうした問題は隠蔽されたり、エンジニアが警告を発しても安全だとは感じられなかったりするからです。そして、それがソフトウェア開発プロセス全体に雪だるま式に広がり、ついには大惨事を引き起こすのです。」
CrowdStrike は、あまりにも目に見える災害であり、それを静かに隠蔽することはまったく選択肢ではなかった例です。
フレームワークとプロセス
これはアジャイルのせいなのでしょうか？エンジニアが発言を恐れるというのは、オリジナルのアジャイル宣言の著者たちが想定していたことではありませんでした。しかし、オリジナルのアジャイル宣言の理念は、長年にわたってフレームワークやプロセスが次々と登場する中で、徐々に崩れ去ってきました。宣言の著者の一人であるジョン・カーンは、「アジャイルフレームワークを実践することと、アジャイルであることの違いについて、誤解されている点があります」と述べています。
Ali 氏は、潜在的な災害を回避し、テストが必要なもののテストを行うための鍵として要件を把握するというテーマに熱心に取り組みました。
「テストは存在するツールの一つですが、テストを実際に機能させるには、何をテストしているのかを理解する必要があります。そのため、非機能要件を概説する適切な要件定義が必要です。」
信頼性など。
興味深いのは、アジャイルコミュニティでは多くの人が、特にアジャイル原理主義者の多くが、ユーザーストーリーだけで十分だと主張することです。ユーザーストーリーは本質的に機能的な動作を記述するだけで、一般化可能な仕様や非機能要件が欠けているのです。
「そして、それが大きな欠陥の一つだと思います。アジャイルの最も教条的な適用を見てみると、ユーザーストーリーはあっても、一般化できる仕様が欠けていることがわかります。」
カーン氏はこれに反対し、明確な要件を放棄するのは「愚かだ」と主張するだろう。アジャイルソフトウェア開発宣言をざっと読むと、動作するソフトウェアと包括的なドキュメントの両方に価値が置かれている（ただし、前者は後者よりも重視されている）。
アジャイル宣言の出版は2001年に遡りますが、アリ氏は長年にわたるその進化に最も関心を持っています。アリ氏は、強力な要件収集プロセスがそれを補完する限り、プロジェクト管理についてはあまり懸念していないと述べています。
- 脆弱なアジャイル開発モデルは、プロジェクト失敗の原因ではなく、症状である。
- 調査によると、アジャイルソフトウェアプロジェクトの失敗率は268%高いことが判明
- このタイプミスがMicrosoft Azureの障害を引き起こした
- CrowdStrikeはマーフィーの法則に遭遇しました。
しかし、ソフトウェアエンジニアリングの世界では、状況はそれほど楽観的ではない。彼はDevOpsの解釈を指摘し、システムが問題から回復する限り、問題はそれほど重要ではないと指摘する。そして、速度と品質は決して矛盾しない。「これは過去に、全く壊滅的な結果を招いたことがあるのです。」
しかし、組織変革、つまり「アジャイル」と銘打たれた方法論とマインドセットを企業全体に適用する段階でこそ、真の失敗が起こり得るのです。アリ氏は、関係者への十分な情報に基づく同意なしに変革が試みられたり、企業が誤った情報に惑わされたりした事例を指摘しています。
「一度にすべてを手に入れ、両方のメリットを享受できるような普遍的なソリューションは存在しません。しかし、こうした変革手法は、しばしばそうしたメリットを売りにしています。」
予算がますます厳しくなる中、「少ないリソースでより多くの成果を上げる」という手法で、レイオフやリソース不足を補う特効薬の誘惑は魅力的です。しかし、アジャイル宣言の共著者であるジョン・カーン氏と、アジャイル手法の批判者であるジュナード・アリ博士の両氏の観点から見ると、プロジェクトや組織の問題を「アジャイル」という名目の絆創膏でカバーできると考えるのは、良く言っても近視眼的であり、最悪の場合、壊滅的な結果を招くことになります。®
