英国のソフトウェアエンジニア（開発者およびDevOps専門家）の健康状態に関する報告書によると、83%が何らかの燃え尽き症候群に悩まされており、その大半がCOVID-19が一因であると認めている。
この調査[PDF]は、DevOps企業Haystackの依頼を受けて世論調査会社Survationによって2021年6月に実施されました。参加者数は少なかったものの（250名強）、回答の質が低くなりやすいオンラインフォームではなく、インタビューで実施されました。
回答者の26%は純粋なソフトウェア開発者、30%は運用（DevOpsや信頼性エンジニアリングなど）、そして44%は両方の要素を担当するソフトウェアエンジニアでした。企業規模の詳細は不明ですが、非常に小規模な企業から大企業まで多岐にわたるとのことでした。
残念なことに、55%が中度または重度の燃え尽き症候群を経験していると回答し、全く燃え尽き症候群を経験していないと回答したのはわずか17%でした。大半（81%）は、少なくとも部分的にはCOVID-19が原因だと考えています。その理由を尋ねると、最大の要因として仕事量の増加を挙げ、「COVID-19による全般的な不安」が僅差で続きました。
言い換えれば、パンデミックに伴う一般的なストレスに関してはソフトウェアエンジニアも他の人々と何ら変わりはなく、それが作業量の増加と相まって大きな負担となっているのです。
英国のソフトウェアエンジニアの83%が、ある程度の燃え尽き症候群を報告している。
なぜ仕事量が増えたのか？調査を委託したコンピューター科学者のジュナード・アリ氏は、「デジタル化」の進展が主な要因だと述べた。「コーヒーショップに入ると、チェックインにQRコードをスキャンしなければなりません。多くの買い物がオンラインで行われ、消費するメディアの多くがオンラインに移行しました。あらゆる種類のビジネスがオンラインに移行せざるを得なくなりました。パンデミックは世界のデジタル化を加速させました。」
- 情報セキュリティの地獄、燃えろ！セキュリティ専門家のわずか21％が現在の仕事を辞めることを考えていない
- テクノロジーはロックダウンの災難からあなたを救わない：在宅勤務中に家族と自由時間を管理する方法
- エドテックは学校の予算削減を回避し、教師を燃え尽き症候群から救うだろう、とUK.govは予測
- プログラミングの子犬が燃え尽き症候群の黒い犬になったとき、あなたは何ができますか？おい、出て行け
Haystack氏は、開発者の燃え尽き症候群と「サイクルタイム」を強く関連付けています。レポートでは、「エンジニアリングチームがアイデアを本番環境にデプロイし、実際のユーザーからのフィードバックを得るまでのスピード」と定義されています。短いサイクルタイムは、開発者のパフォーマンスが高いことと関連しています。Haystack氏は、GoogleのDORA（DevOps Research and Assessment）チームを例に挙げています。このチームは、チームを「エリート」（1日に複数回のデプロイ、サイクルタイムは1日未満）から「低レベル」（月に1回未満のデプロイ、サイクルタイムは1～6か月）まで分類しています。
とはいえ、この新しいレポートでは、短いサイクルタイムが燃え尽き症候群を増加させるという証拠は示されていません。さらに、このレポートによると、英国のソフトウェアエンジニアは短いサイクルタイムに関しては平均以上であり、50%が2～3日以内に機能を納品できると回答しています。
アリが思いついた最良の答えは、「GoogleのState of DevOpsレポートによると、エリートレベルのパフォーマンスを誇る企業の従業員は、自分のチームを素晴らしい職場として推奨する可能性が1.8倍高いことが分かりました。…多くの仕事をこなしているときに人々が燃え尽きてしまうのは、プロセスとツールが整っていないのに仕事への要求が高まってしまうという摩擦が原因です。より迅速にデプロイできる能力があれば、摩擦を取り除くことができ、物事はよりスムーズになります。」というものでした。
「管理者は燃え尽き症候群を察知できるものの、組織内にベストプラクティスが組み込まれていないため、適切な対応ができないのが現状です。」
さらに、良好なコミュニケーション、長時間労働を要求しないこと、チームメンバーが休暇を確実に取れるようにすることなど、常識的な管理慣行が燃え尽き症候群の緩和に少なくとも同じくらい重要かもしれないとも言えるでしょう。
短いサイクルタイムの重要性を強調することで、結果として経営陣が開発者にデリバリーのスピードを上げるようさらに強く要求するようになる、といったマイナス効果が生じる可能性はあるでしょうか？それは誤解です。
Googleチームがこれらの因果関係を検証した結果、サイクルタイムに到達する前に、チームの心理的安全性が重要な要素の一つであることがわかりました。人々は何かに対して警鐘を鳴らすことができますか？物事について話し合うことができますか？それがサイクルタイムの短縮、燃え尽き症候群の減少、そしてビジネス上の利益につながる傾向があります。
経営陣の期待と、ソフトウェアエンジニアが達成可能だと認識している目標、あるいはそれを達成するために求められる方法とが一致していないと、ストレスが増大します。こうした問題はよく知られており、「プロセスやツールよりも個人とインタラクション」、そして「契約交渉よりも顧客とのコラボレーション」を重視する2001年のアジャイル宣言は、今もなお有効です。
報告されている燃え尽き症候群の高レベルは、パンデミックによるストレスと、アジャイル手法の導入が継続的に失敗していることが一因であると言えるでしょう。アリ氏もこれに同意しました。
「私は約8年間、エンジニアリングマネージャーを務めてきました」と彼は語った。「『アジャイル™』を採用している企業は数多くありますが、真のビジネスアジリティは実現していません。ウォーターフォール型のプロセスを採用し、スクラムやSAFe（スケールド・アジャイル・フレームワーク）と銘打っていますが、真のアジャイルとは言えません。適応できていない彼らは、アジャイルを名乗っているだけで、ただ昔ながらのビジネスモデルを実践しているだけです。」®
