ソフトウェア エンジニアリングの世界では、アジャイル手法に既得権益を持つ人々から、アジャイルの終焉を宣言する声が聞かれることは珍しくありません。彼らは、私たちがもっと強い信念を示さなければ、アジャイルは失われるだろう、失敗したとしても、単に だけだと主張しています。これは、「真のスコットランド人はいない」という誤謬に続く、「真の共産主義は一度も試みられたことがない」などの主張を彷彿とさせます。 適切に実装されていない 冤罪事件から航空 にもかかわらず、現実にはアジャイルはソフトウェア エンジニアリングの専門的な宗教のような地位を占めています。 ソフトウェアの災害に至るまで、さまざまなソフトウェア災害にアジャイルが関与している この状況はここ数か月で大きく変化しました。6 か月前に私が行った では、アジャイル ソフトウェア プロジェクトの が示されましたが、この調査結果を裏付ける膨大な調査結果が発表されました。 調査 失敗率は 268% 高いこと 共産主義や信仰による治療のように、普遍的に良いが非現実的な解決策がすべての問題を解決できるという壮大な幻想は、証拠にもかかわらず、常に一部の人々には魅力的です。しかし、現在根本的に変わったのは、アジャイルに従うか、それとも何か違うことをするかについて、十分な情報に基づいた同意が存在することです。」 (間違いなく、 に関する国際的なニュースは、私が言おうとしていた点を印象付けるのに役立ちました。) CrowdStrike の失敗したソフトウェア アップデート アジャイル コミュニティの一部の人々が、私がアジャイルについて話すのを黙らせようと、嫌悪すべきほどの努力をしたにもかかわらず、勝利には寛大であることが重要なので、ここで議論を再び繰り広げようとはしません。代わりに、6 か月後の最近の進展と今後の道のりについて議論する価値があると感じています。 Google の DORA 研究がアジャイルに転換 アジャイル失敗率調査を委託した JL Partners は、ここ数か月、驚異的な成果を上げています。限られた説明責任で調査を行う他の多くの企業とは異なり、彼らは選挙を予測することで定期的にモデルをテストしています。英国の選挙に関しては、 あることがわかりました。Politico 米国の選挙に関してはさらに驚くべき成果を上げています。 最も正確な予測を出している企業のひとつで のレポートによると、 … JL パートナーズは、選挙前の最終予測において最も正確な会社の一つになるかもしれない。同社の最終モデルはトランプ氏の勝利を予測した 2 つのうちの 1 つであり、選挙人団の勝利も 287 対 251 と予測した。これは、どの世論調査会社よりもトランプ氏の勝利の予測差が最も大きかった。また、同社はトランプ氏が一般投票で勝利すると予測した数少ない世論調査会社の一つでもあった。 さらに、RAND Corporation が当初米国国防総省のために実施した調査では、 が判明しています。さらに、Synodus (BOC Aviation、KPMG、Unilever などの Fortune 500 企業に技術を提供する世界的なプロバイダー) は、 、プロジェクトの提供速度が 2 ～ 3 倍になり、大手航空会社が開発コストを 63% 削減したと報告しています。 AI 開発とアジャイルは相性が良くないこと アジャイルから離れることで これは、スピードとコストが従来、アジャイルと LEAN に関連付けられた指標であるのに対し、インパクト エンジニアリングのアプローチでは、インパクトを主要な指標として重視しているという事実にもかかわらずです。 最後に、コルム・キャンベルが「 」という記事で書いているように、アジャイルの失敗率調査に対して「アジャイル・マフィア」が主張したことは全面的に反証され、哀れな個人攻撃だけが残されました。 恐竜による P-Hacking しかし、おそらく最も意外な研究支援領域の 1 つは、Google の DORA チームによるものです。DORA 自体は、DevOps ムーブメントにルーツがあり、それ自体がアジャイルの産物です。2024 年の年次 DevOps 状況レポートは、アジャイル研究に放送時間が割かれているため、今年は特に広く取り上げられることはありませんでしたが、彼らがアジャイルにも背を向けているのは興味深いことです。 さて、私は ことを指摘しておくべきでしょう (アジャイル、DevOps などについて考えが変わって以来)。彼らが物事を測定するために使用する主な指標は配信のスピード ( ) に重点を置いているからです。しかし、彼らが自分たちのアプローチを使用してもこの現象が見られるという事実は、ここで何かもっと深いことが起こっていることを示しています。 DORA チームの手法に批判的であった ユーザーが望んでいるものではないことはわかっています 「State of DevOps Report 2024」の 64 ページで、次のように主張されています。 「アジャイル宣言では、「包括的なドキュメントよりも動作するソフトウェア」を推奨しています。しかし、私たちは、品質の高いドキュメントが動作するソフトウェアの重要な要素であることに気づき続けています。」 さらに、82 ページでは、DevOps 自体に背を向けているように見えます。 「私たちは、DevOps 運動の一部である文化、コラボレーション、自動化、学習、そしてビジネス目標達成のためのテクノロジーの使用という基本原則に常に取り組んでいます。私たちのコミュニティと研究は、"DevOps" というラベルに関連しない人々を含む、さまざまな役割の視点から恩恵を受けています。"DevOps" という用語が注目されなくなることを覚悟してください。」 私は彼らの研究方法にまだ問題があると思っています。成功を測定するために使用されるエンドポイントはスピードに重点を置いており、さらに、 そのようなアプローチに疑問を投げかけているにもかかわらず、彼らは変革型リーダーシップを提唱し続けています。 この分野の心理学的研究が 人間的なレベルでは、十分な情報を得た上での同意を得ずに組織や人々を変革しようとすることに重点を置きながら、自分自身の失敗（十分な情報を得た上での同意がある限り）よりも優れた学習源は往々にしてないことを認識していないのは、非常に粗雑な行為に思えます。これが、私が や のような研究に対して抱いている主な批判です。 フェニックス・プロジェクト ユニコーン・プロジェクト しかし、従来の Agile や DevOps の指標に対する Impact Engineering の裏付けが増えていることは注目に値します。 スクラム、TDD、デザインパターン 数か月前、The Register が 記事で私にインタビューしたとき、私は Agile、DevOps、デジタル変革に対する現代的なアプローチに問題があると感じていた 3 つの要因を隠さず話しました。 「 」という Study backer: Catastrophic takes on Agile overemphasize new features にもかかわらず、要件を軽視するアジャイルのアプローチ。 郵便局のスキャンダルやボーイング 737 Max 8 の墜落などの災害 そもそも問題を防ぐのではなく、新機能の提供と問題からの回復のスピードを優先する DevOps の実装 - 調査によると、一般の人々はコンピューター システムを使用する際に、最新の機能をできるだけ早く入手すること でないと考えており、データのセキュリティ、データの正確性、重大なバグがないことが一番重要な要素であることを示しています。 は最も重要 インフォームドコンセントを得ずにボトムアップの組織変革を試み、インフォームドコンセントを得た上で人々が自らの失敗から学べるようにすることの重要性を無視しています。確実な成功として売り出されているこのようなプログラムは、圧倒的にストレスの多い悲惨な結果と失敗に終わっています。 ソフトウェア災害とキラーコンピュータ（ 報道された）を調査し始めたとき、私が道徳的な問題を感じ始めたのはこの3つの要因でした。調査していた災害のケーススタディに同じ関連性が見られなかったため、さまざまなソフトウェア開発アプローチやプロジェクト管理手法に特に問題はありませんでした。これらの他の問題に関しては、エンジニアとしての個人的な見解を表明する必要性を感じませんでした。 4月にフォーブス誌で それでも、爆発半径が最初の 3 つの領域を超えて、アジャイル宣言の共著者が提唱するスクラム、テスト駆動開発 (TDD)、オブジェクト指向プログラミング (OOP)、デザイン パターン (たとえば、Soumen Sarkar の LinkedIn の投稿 」を参照) などの他のアプローチにまで広がっているのは興味深いことです。 「デザイン パターン この分野について私が付け加えることはあまりありません。しかし、アジャイルの共著者たちが、宗教としてのアジャイルの死にそれほど抵抗していなかったら、ソフトウェア エンジニアリング コミュニティは彼らの他のアイデアに対してもっと寛容だっただろうと疑問に思います。アジャイルの宗教的地位は おり、OOP、デザイン パターン、TDD などすべてが手に入るように見えるので、この疑問はもはや意味がありません。 死後硬直して 損失回避の認識に向けて 過去数か月間、私はアジャイルについてさまざまな技術出版物の第一面を飾るニュースとして、またコミュニティ全体で広く議論されるニュースとして、かなりの時間を費やしてきたので、奇妙な出会いがあっても驚くことではないかもしれません。しかし、大部分は、人々が公共の場で私に近づいてきて、アジャイルについてランダムに議論を始めるという、非常に楽しい出会いでした。 しかし、私に強烈な印象を残した出来事が一つありました。数週間前、私は英国議会に行き、調査に取り組んでいたさまざまなテクノロジースキャンダルについて政策立案者に説明しました。私自身、権力を握ることにあまり興味がなかったので、国会議事堂内のプライベートバーに、酔ったときに権力を乱用しないよう注意を促す標識がなければならないことにいつも疑問を感じていました。 しかし、この講演では、私はいつもよりきちんとした服装で見栄えが良かっただけでなく、国会議員と、国王顧問（優れた弁護活動により国王からその称号を与えられた上級弁護士）である友人に囲まれ、同情的な聴衆の前に立っていた。 私が講演を終えていくつかの質問に答えた後、聴衆の中にいたビジターがアジャイルについて話し始めました (講演はアジャイルに関するものではありませんでした)。私のスリーピーススーツとは対照的に、彼はケチャップの染みのついたシャツを着ており、(詳細は省きますが) 見栄えも政治とのつながりもありませんでした。彼は「フィードバックを少しいただいてもよろしいでしょうか?」と切り出しました。 彼がアジャイルについて話し始めたとき、私はいぶかしげに彼と目を合わせました。すると彼は、まるで自分がもうオンラインではなく、実際に誰かと向き合って話していることに気づいたかのように、うつむいて話すのをやめました。私が返答する前に、CEO の友人が口を挟んで、その点について私に代わって説明してくれました。 その瞬間、私は今までに感じたことのないほど権力を嫌っていることに気づきました。 残念なことに、この人物は、すでに確実な変革ソリューションを売りつける人々の犠牲者となって、自分の人生に困難をもたらしていたようです。このような状況で、なぜこうした変革手法がまだ提唱されているのでしょうか。 もっと広い視点で見ると、なぜアジャイルは現実世界では機能しないのでしょうか。共産主義では、少なくとも失敗の原因は貪欲さにあると言えます。では、アジャイルの失敗の心理学とは何でしょうか。私の考えでは、その答えは、 と呼ばれる心理的要因に行き着きます。多くの要望に応えて、私は最近、Impact Engineering の研究に関するプレプリント論文を書きました。この論文では、損失回避の認識がプロジェクトの成功を緩和する上で果たす役割に焦点を当てています。 損失回避 論文 、次のように結論づけています。 「それでは私はフランケンシュタイン博士ですか? それともあなたはずっとモンスターだったのですか?」: 損失回避を考慮した開発方法論によるソフトウェア プロジェクトの失敗の軽減 は ケーススタディによれば、問題に対処せずに隠蔽すると、ソフトウェア災害が雪だるま式に膨れ上がり、大惨事になる可能性がある。損失回避という心理的要因が、悲惨な結果を招くにもかかわらず、組織がこの道を進む動機となる可能性がある。 しかし、ソフトウェア方法論は歴史的にこの心理的要因を無視し、代わりに人間はできるだけ早く問題に対処したいと想定してきました。さまざまな方法論に関するこれまでの研究では、問題を提起して議論する心理的安全性がソフトウェア提供の改善の鍵であることがわかりました。しかし、このような重要な文化的および心理的変化がすべての組織で達成できると考えるのは間違いなく楽観的です。私たちの調査によると、英国と米国の間でも、心理的安全性は両国のエンジニアリング実践における最大の違いのままです。 この論文では、別の方法に焦点を当てています。せいぜい困難な文化的変化を達成しようとするのではなく、より実用的なアプローチに焦点を当てています。つまり、最初から堅牢な要件によって損失回避の引き金となるものを制限し、必要な場所で心理的安全性を目指します。私たちの調査では、心理的安全性よりもプロジェクトの成功率を高める唯一の要因は、最初から明確な要件を持つことであることがわかりました。 私たちの仮説に反して、たとえ開発の後半で要件が変更されたり、現実世界と一致しなかったりしても、要件が明確であるだけで、ソフトウェア プロジェクトの成功に重要な役割を果たすという結果が出ています。これは、損失回避が最も低いときに、プロジェクトの開始前に問題を議論して対処するためのゲートを設けることで、成功率を最大限に高めることができることを示唆しています。 RedHook の曲「Dr. Frankenstein」には、「それで私は Dr. Frankenstein なの？それとも、あなたはずっと怪物だったの？」というフレーズがあります。この論文では、壊滅的なソフトウェア プロジェクトについて、人間が小規模な技術的問題に対処できなかった場合にソフトウェア プロジェクトが惨事になると主張しています。既存のソフトウェア エンジニアリング方法論では、人間は機械ではなく、心理的要因が問題に対処する能力を妨げるという点に対処できていません。この既存の方法論の時代錯誤を特定したこの論文では、プロジェクト開始前に要件を使用して損失回避が最も低いときに問題に対処する機会を提供することで、この状況に対処する方法を示します。
