バイバイ DORA: DevOps レポートの現状の欠陥

2 年前、私は開発者の燃え尽き症候群がソフトウェア エンジニアに与える影響を調査したところ、 83% が燃え尽き症候群に苦しんでいることがわかりました。ここ数か月間、私はさまざまな組織のソフトウェア開発に対する認識についてさらなる調査に取り組んできました。その中には、ソフトウェア エンジニアの 75% が最後に不正行為を報告したときに報復に直面しており、ビジネス リーダーの 89% が不正行為について懸念しているという調査結果も含まれています。 ソフトウェアの期日通りの納品。

Google の DORA チームは数年間、ソフトウェア エンジニアを対象に独自のアンケートを実施しており、測定フレームワークの最初の作成者は現在、SPACE や DevEx などの他のフレームワークを作成しています。私は当初これらのチームが作成した研究を信頼していましたが、さらに研究を進めるにつれて欠陥が明らかになりました。

休暇期間中、私はアンドリュー・ジェンキンソン博士の著書「なぜ私たちは食べすぎるのか：食欲の新しい科学」を読んでいます。その本の中で、ジェンキンソン博士はアンセル・キーズ博士による「7カ国研究」として知られる研究を批判しています。ジェンキンソン博士はキー博士の成功を次のように説明している。群衆の称賛に彼は喜びとエクスタシーで満たされた。彼の生涯の仕事が実を結びました。彼の研究には資金が流入し、その分野の第一人者としての彼の評判は何年にもわたって安泰となるだろう。名声は良かったが、今や彼は権力と影響力という真の二つの賞を手に入れた。」

しかし、ジェンキンソン博士は次のように述べています。厳密に言えば、彼が提示したことは真実でした。しかし、彼はそれがすべての真実ではないことをよく知っていました。」

DORA の研究成果とその後の研究をさらに詳細に研究するにつれて、この説明と、DORA の State of DevOps Report およびその後の SPACE および DevEx フレームワークにおける研究の厳密さとの類似点が明らかになりました。

データはどこにありますか?

まず、DORA の調査は、主観的な調査を使用して何千人もの開発者をサンプリングして実施されます。この調査は DORA チームによって社内で実施されます。通常、このような調査を生業とする人々は、市場調査協会 (MRS) や英国世論調査評議会 (BPC) などの組織に参加し、会員となっている組織が行う調査を国民が信頼できるようにしています。例えば; BPC 規則では、会員に対し、調査が公開されてから 2 営業日以内に質問を含む完全なデータ表を開示することを義務付ける厳格な開示規則を設けています。

ここで最初の問題が残ります。 DORA チームは生データを公開せず、DevOps レポートのみを公開します。

欠陥のある方法論

Google の DORA 調査、およびチーム設定内で使用される SPACE および DevEx フレームワークは、主観的な調査を使用して測定値を作成します。主観的な調査を使用する場合は、バイアスが影響しないように措置を講じることが重要です。

ただし、DORA は、変更リード タイム、導入頻度、変更失敗率、復旧までの時間 (以前の平均復旧時間) という 4 つの主要な指標を使用して結果を測定します。これらは基本的に、新機能を導入する速度と問題を解決する速度の尺度です。

「あなたの同僚は野菜をたくさん食べますか?」と何人かの人に尋ねたと想像してください。 「あなたの同僚はよく運動しますか?」自分の職場について気分が良くなった人は、おそらく両方の質問に「はい」と答える可能性が高いでしょう。これは、より多くの野菜を食べることが常にジムへの参加レベルの向上につながるという意味ではありません。相関関係はあるかもしれませんが、因果関係は確立されていません。

DORA の研究では、スピードと信頼性は密接に関連していると主張していますが、それは完全にスピードに基づいた結果測定に基づいています。さらに、主観的な調査を使用すると、自分の仕事に満足している受信者が両方の質問に「はい」と答えるようになる可能性があります。そして、より有能な企業は必然的に両方の要素においてより有能である可能性がありますが、これは因果関係を生み出しません。

例えば;航空機へのソフトウェアの導入がまれであることと比較して、航空ソフトウェアの信頼性がどれほど高く評価されているかを考えてみましょう。あるいは、アジャイル手法の先駆者であるトヨタが、ソフトウェア信頼性訴訟「ブックアウト対トヨタ」で、死亡事故につながった意図しない加速バグについて社内コミュニケーションで「実のところ、フェールセーフなどの技術はトヨタの一部ではない」と認めたことを考えてみましょう。技術部門のDNA」。あるいは、複数の自殺の原因とされ、妊婦を含む不当投獄された人々を含む「英国史上最も広範な誤判」と言われている Horizon IT スキャンダルの際に、ソフトウェア開発者である富士通がどのようにして、ソフトウェアの使用を先駆的に行ったかを考えてみましょう。ソフトウェアを開発するためのアジャイルな方法論、すなわちRapid Application Development 。

欠陥のある測定結果

前述したように、DORA の調査では、新しい作業のデプロイとバグ修正の速度を評価してパフォーマンスを評価する 4 つの主要な指標に基づいて測定されました。ただし、これらの指標は、測定に有用な結果であるという範囲でのみ重要です。

私はソフトウェア エンジニアと一般大衆の代表的なサンプルの両方を対象に調査を実施しました (調査会社 Survation と共同) が、どちらも速度が最も重要でない要素であることに同意することがわかりました。むしろ、一般の人々が最も関心を持っているのは、データのセキュリティ、データの正確性、重大なバグの防止です。ソフトウェア開発者や一般の人々が最も重要だと主張するこれらの結果に 4 つの主要な指標を結び付ける仮説を見つけるのは困難です。特に、重大なバグを防ぐことが、バグを迅速に修正したり、作業を迅速に進めることよりも優先順位が完全に低いことを考えると、そうです。データ セキュリティなどの他の要素であっても、これらが 4 つの主要な指標のいずれかとどのように関連しているかを理解するのは困難です。

ビジネスの意思決定者の間でも、納期が早いことよりも納期厳守が重要であると考えられているようです。私が JL Partners と行った調査によると、英国ではそのようなビジネス上の意思決定者の 98%、米国では 96% が「ソフトウェア エンジニアリング チームの目標は、高品質のソフトウェアを予定どおりに提供することである」という意見に同意しています。英国では 65%、米国では 62% が強く同意しています。

ついに; Survation と私が行った調査では、ソフトウェア エンジニアに対する信頼と一般の信頼性に対する期待は業界ごとに大きく異なる可能性があることがわかりました。つまり、画一的なアプローチは推奨されず、Engineering Council UK が提案しているものを支持する必要があります。リスクに関するガイダンス: 「リスクに比例し、組織の定義されたリスク選好と一致する意思決定アプローチを採用する」。

お金に従ってください

キーズ博士が研究で製糖業界から資金提供を受けたように、多くの調査では、資金を追跡してインセンティブがどこにあるのかを理解することが重要です。 DORA チームは当初、IT インフラストラクチャの自動化に重点を置いている会社である Puppet のために DevOps レポートの作成を開始し、現在は Google Cloud に対してこの作業を行っています。どちらも、開発者ができるだけ早く作業を展開できることに強い関心を持っています。ただし、これがすべての問題の解決策であることを意味するわけではありません。

DORA は、プロセスにある程度の実証的評価を追加することで、ソフトウェア エンジニアリングの世界に貢献してきました。しかし、私たちはマーケティング資料を真実全体と混同することを避け、そのような研究の欠陥を認識しなければなりません。