はじめに
Developer Productivity室の @uncle__ko です。
自分が所属してるCyberAgentのDeveloper Productivity室では開発生産性向上に日々取り組んでいます。
ついに2024年版 State of DevOps Reportが公開されましたね。
今年はAIとPlatform Engineeringについて深堀ってレポートされていました。
時代を感じますね。
State of DevOps Reportは DevOps Research and Assessment（DORA）チームが2014年から毎年公開しているDevOps業界の年次調査レポートです。
DORAは書籍「LeanとDevOpsの科学」の著者陣が中心となって設立された調査機関で、このレポートは書籍からのトレンドの変化を読み取れるとてもいいレポートになってます。
開発生産性向上を担うチームとしては、このレポートはとても有用な資料になりますし、開発生産性を向上させたいエンジニア組織にもとても有用な資料となることかと思いますので、このレポートの内容を簡単にですがまとめて見ようかと思います。
もしこの記事をみて、詳細が気になった人は実際のレポートを参照してみてください。
Software delivery Performance
DORAのfour keysの指標は通常連動して変動することが観察されています。最高のパフォーマンスを発揮するチームはすべての指標で良好な結果を出す一方で、最もパフォーマンスが低いチームはすべての指標で不良な結果を示します。
Software delivery Performanceの指標の進化
four keysの分析には、長い間外れ値が存在していました。
それが変更失敗率です。
DORAは、変更失敗率の指標がチームに求められる再作業の量の代理指標として機能するという長年の仮説を持っています。デリバリーが失敗すると、チームはその変更を修正する必要があり、おそらく別の変更を導入することで対応します。
この理論を検証するために、今年は再作業率に関する別の質問を追加しました。「あなたが担当している主要なアプリケーションやサービスについて、過去6か月間に計画されていなかったが、アプリケーションのユーザー向けバグを解決するために行われたデプロイはおおよそ何件ですか？」
データ分析の結果、再作業率と変更失敗率が関連しているという仮説が確認されました。
Performance levels
すべての4つのクラスター内で、スループットと安定性は相関しています。この相関関係は、中程度のパフォーマンスクラスター（オレンジ）においても持続しており、ここではスループットが低く、安定性は高くなっています。これは、スループットと安定性以外の要因がクラスターのパフォーマンスに影響を与えていることを示唆しています。たとえば、中程度のパフォーマンスクラスターは、変更をより頻繁に出荷することで恩恵を受けている可能性があります。
頻繁なデプロイメントと、デプロイ時の失敗の少なさのどちらが良いのでしょうか？
この質問に対する普遍的な答えはないかもしれません。それは、考慮されるアプリケーションやサービス、そしてそのアプリケーションに取り組むチームの目標、さらに最も重要なこととしてアプリケーションのユーザーの期待によって異なります。
DORAは、迅速なチームを「高パフォーマンスチーム」と呼び、遅いがより安定したチームを「中パフォーマンスチーム」と呼ぶことにしました。この決定は、これらのパフォーマンスレベルを使用する際の潜在的な落とし穴の1つを強調しています。特定のパフォーマンスレベルに到達することよりも、改善することがチームにとってより重要であるべきです。最良のチームは、必ずしもエリートパフォーマンスを達成するのではなく、エリート改善を実現するチームです。
これはなかなかおもしろいなと思いました。
パフォーマンスがエリートレベルでも障害が多ければよい組織とは言えなさそうなので、肌感に近い気がしました
DORAのQuick Checkでサクッと組織のデリバリーパフォーマンスを測定できるので、ぜひ試してみるとよいと思います
Artificial intelligence:adoption and attitudes
2023年の『Accelerate State of DevOps Report』では、パフォーマンスに影響を与える多くの技術的能力の一つとしてAIが取り上げられたに過ぎませんが、今年はこのテーマをより深く掘り下げて探求してます。
Adopting Artificial Intelligence
AIの採用に関する調査結果は、AIがもはや「遠くの未来」の存在ではなく、非常に高い可能性で今後も定着するという認識が高まっていることを示唆しています。
回答者の大多数（81%）が、自組織の優先順位がAIをアプリケーションやサービスにより多く組み込む方向にシフトしていると報告しました。さらに、49.2%の回答者は、このシフトの大きさを「中程度」または「重要」と説明しています。
調査対象のすべての業界の参加者は、日常業務におけるAIへの依存度が統計的に同じレベルであると報告しており、これはAIの急速な採用がすべての業界セクターで均等に進行していることを示唆しています。
個々の業界は、規制の制約や革新の歴史的なペースの観点から大きく異なることがあり、これらは技術採用の速度に影響を与える可能性があります。しかし、大規模な組織で働く回答者が、小規模な組織で働く回答者よりも日常業務におけるAIへの依存度が低いと報告していることを発見しました。これは、大企業がその高い組織の複雑性や調整コストのために技術の変化に適応するのが遅いという先行研究の結果と一致しています。
個人レベルでは、75.9%の回答者が日常の職務の一部にAIを利用していることがわかりました。
次のタスクに職務責任が含まれる回答者のうち、多数がAIに依存していることが明らかになりました：
- コードの記述
- 情報の要約
- 不慣れなコードの説明
- コードの最適化
- コードの文書化
- テストの記述
- コードのデバッグ
- データ分析
調査回答に含まれるすべてのタスクの中で、ソフトウェア開発業務におけるAIの最も一般的な使用ケースは、コードの記述（74.9%）と情報の要約（71.2%）。
チャットボットは、回答者が日常業務でAIと相互作用する最も一般的なインターフェースであり（78.2%）、次に外部ウェブインターフェース（73.9%）、そしてIDE内に埋め込まれたAIツール（72.9%）が続きました。回答者は、内部ウェブインターフェース（58.1%）や自動化されたCI/CDパイプラインの一部としてAIを使用する可能性が低く（50.2%）、これらの技術の利用状況は、AIに関する意識やインターフェースの頻度に依存している可能性があることを認識しています。そのため、これらの数値は実際よりも低く見えるかもしれません。
データサイエンティストや機械学習の専門家は、他の職種を持つ回答者よりもAIに依存する傾向が高いことがわかりました。逆に、ハードウェアエンジニアは、AIに依存する可能性が他の職種の回答者よりも低いことがわかり、これはハードウェアエンジニアの責任が、AIが一般的に使用される上記のタスクとは異なるためかもしれません。
Perceptions of Artificial Intelligence
AIを採用している多くの組織や開発者にとって、開発作業におけるAIの使用から得られる利益は非常に大きいようです。調査の実施前の3ヶ月間において、75%の回答者がAIによる生産性の向上を報告しました。この調査は2024年初頭に実施されました。
特筆すべきは、回答者の3分の1以上が観察された生産性の向上を中程度（25%）または極端（10%）と評価したことです。AIの影響によって生産性にわずかな悪影響を感じたと報告した回答者は10%未満でした。
役割ごとに見ると、AIによる生産性の向上を最も大きく報告したのは、セキュリティ専門家、システム管理者、そしてフルスタック開発者でした。
他の役割と比較して、モバイル開発者、SRE、プロジェクトマネージャーは、生産性の向上の度合いが低いと報告しました。
参加者のAI生成コードに対する信頼感は複雑でした。ほとんどの回答者（87.9%）は、AI生成コードの品質に対して何らかのレベルの信頼を示しましたが、その信頼の度合いは一般的に低く、39.2%が「ほとんど信頼しない」（27.3%）または「全く信頼しない」（11.9%）と報告しました
調査の結果、開発者がAIを急速に採用し、それに依存し、パフォーマンス向上に寄与していると認識しているにもかかわらず、AIに対する全体的な信頼の欠如は驚くべきものでした。インタビューの中で、多くの参加者がプロフェッショナルな仕事で使用するAI生成コードの出力を調整する意欲や期待を示したことは注目に値します。
Expectations for AI’s Future
楽観的な見解として、AIが開発専門家のパフォーマンスにポジティブな影響を与えているというDORAの調査結果と一致して、回答者は今後1年、5年、10年の間にAIの影響により自社の製品の質が向上し続けると期待しています。
しかし、同時に回答者は、AIが自らのキャリア、環境、そして社会全体に対してネットとしてネガティブな影響を及ぼすと考えているようです。
AIが私たちの世界に与える将来の影響は不透明ですが、今年の調査結果は、AIがソフトウェア開発の分野において無視できないパラダイムシフトをもたらしたことを強く示しています。これまでのところ、これらの変化は開発専門家によって歓迎されています。
Exploring the downstream impact of AI
AI導入は個人の生産性、フロー、仕事の満足度を高める一方で、価値のある作業に費やす時間を減少させる可能性もあります。同様に、AIはコード品質、ドキュメンテーション、レビュープロセスに対してポジティブな影響を与えますが、驚くことに、これらの改善はソフトウェアのデリバリーパフォーマンスの向上にはつながりません。実際、AIの導入はこの領域では有害であるように見え、その影響は製品パフォーマンスにはほとんど影響を及ぼさないままです。
明らかなメリット
AIを採用することが個人の成功や幸福感に与える影響については下記にまとまってます
AIがフロー、生産性、仕事の満足度に対して大きな利益をもたらしています。
例えば、生産性は、個人のAI採用が25%増加すると、おそらく約2.1%向上する。
これは小さく見えるかもしれませんが、これは個人レベルの話です。
このパターンが数十人の開発者、さらには数万人の開発者にまで広がると想像してみてください。
潜在的なトレードオフ
AIの導入における価値提案の一つは、人々がより価値のある仕事に多くの時間を費やせるようになることです。つまり、手作業や繰り返しの多い退屈なタスクを自動化することで、回答者は「より良いこと」に時間を使えるようになると期待されていました。
しかし、データは、AIの採用が増加すると、価値のある仕事に費やす時間が減少する可能性があり、退屈な作業に費やす時間は影響を受けないことを示唆しています。
回答者のウェルビーイングの指標であるフロー、仕事の満足度、生産性などは、従来から価値のある仕事に費やす時間と関連していました。そのため、価値のある仕事に費やす時間が減少しているにもかかわらず、これらの指標が改善されているのは驚きです。
DORAはこの仮説を「真空仮説」と呼んでいます。この仮説は、AIによってフロー、生産性、仕事の満足度が向上しつつも、価値ある仕事に費やす時間が減少し、退屈な仕事に費やす時間が変わらないというデータを説明するものです。
AIは生産性とフローを向上させることで、人々がより効率的に仕事を進められるようにしています。この効率化により、価値あると考えられる作業をより早く完了させることができるようになっています。ここで「真空」が生じます。つまり、余分な時間が生まれるのです。AIは仕事の価値を奪うのではなく、その実現を加速させているのです。
The promising impact of AI on development workflows
AIの採用が25%増加した場合にこれらの成果がどのように変化するかにを視覚化したもの
AIの採用が25%増加すると、以下のような影響が見られます。
- ドキュメント品質が7.5%向上
- コード品質が3.4%向上
- コードレビューの速度が3.1%向上
- 承認速度が1.3%向上
- コードの複雑さが1.8%減少
これらの結果は、AIの導入がソフトウェア開発におけるさまざまな側面でポジティブな効果をもたらすことを示唆しています。
AIの最も一般的な用途はコードの作成です。67%の回答者が、AIがコードの改善に役立っていると報告しています。ここでは、その感情がさらに確認され、AIがコードの品質を向上させ、コードの複雑さを減少させていることが示されています。古いコードのリファクタリングと組み合わせることで、AIによって生成された高品質のコードが、全体的により優れたコードベースにつながる可能性があります。
このコードベースは、AIが生成する質の高いドキュメントによりさらに改善される可能性があります。
より良いコードはレビューしやすくなり、AIによる支援を受けたコードレビューと組み合わせることで、レビューと承認がより迅速に行われることがデータで明確に示されています。
もちろん、コードレビューと承認の速度が速くなったからといって、レビューや承認のプロセスがより徹底的であるとは限りません。AIへの過度の依存や、AIによって生成されたコードへの信頼が影響している可能性もあります。
さらに、コードとドキュメントの品質が向上しているのは、AIが生成しているためなのか、あるいはAIが低品質と見なされるドキュメントやコードから価値を引き出す能力を高めたためなのかは明確ではありません。AIを使用することで、私たちが「質が高い」と考える基準が少し下がっている可能性もあります。この2つの理解方法は排他的なものではなく、両方がこのパターンに寄与している可能性があります。
これらのパターンで明確なのは、AIが依存しているドキュメントや作業しているコードベースからより多くの価値を引き出すのに役立っているということです。また、コードレビューと承認プロセスにおけるコストのかかるボトルネックの削減にも貢献しています。ただし、AIがこれをどのように実現しているのか、そしてこれらの利点がソフトウェアの納品改善などのさらなる効果につながるのかは、まだ明確ではありません。
AI is hurting delivery performance
期待に反して、DORAの調査結果は、AIの導入がソフトウェア配信パフォーマンスに悪影響を及ぼしていることを示しています。配信スループット（処理速度）への影響は小さいものの、マイナスの影響が見られます（AIの導入が25％増加するごとに約1.5％の減少が推定されます）。配信安定性への悪影響はさらに大きく、25％のAI導入増加で約7.2％の減少が推定されます
AIによって生産性とコード生成速度が劇的に向上したことが、DORAの最も基本的な原則の1つである「小さなバッチサイズの重要性」を忘れさせてしまった可能性があると仮説を立てています。つまり、AIにより同じ時間でより多くのコードを生産できるようになったため、変更リストが大きくなっている可能性があります
Platform Engineering
Platform Engineeringでは、開発者体験の改善に多くのエネルギーと注力が費やされており、その一環として「ゴールデンパス」と呼ばれる高度に自動化されたセルフサービスのワークフローが構築されています。これは、プラットフォーム利用者がアプリケーションの提供と運用に必要なリソースとやり取りする際に使用するもので、ソフトウェアの構築と提供における複雑さを抽象化し、開発者が自分のコードだけに集中できるようにすることを目的としています。
Platform Engineeringの成功の鍵は、ユーザー中心のアプローチ（Internal developer platformにおけるユーザーとは、開発者を指します）、開発者の自立性、そしてプロダクト思考です。ユーザー中心性が組織パフォーマンス向上の重要な要素であることは、今年および過去数年の報告で確認されています。ユーザー中心のアプローチがなければ、プラットフォームは支援ではなく障害になる可能性が高まります。
今年の報告書では、プラットフォームとソフトウェアデリバリーおよびオペレーションのパフォーマンスとの関係を調査し、いくつかの肯定的な結果を見出しました。Internal developer platformのユーザーは、個人の生産性が8%高く、チームのパフォーマンスが10%高いことが分かりました。さらに、プラットフォームの使用により、組織のソフトウェアデリバリーとオペレーションのパフォーマンスは6%向上します。
しかし、これらの向上にはいくつかのデメリットも伴います。スループットと変更の安定性が、それぞれ8%と14%の低下を示したことは驚きでした。
The promise of platform engineering
プラットフォームの影響は肯定的で、Internal developer platformを利用することで個人の生産性が8%向上し、チームのパフォーマンスが10%向上することが確認されました。
生産性だけでなく、プラットフォームの導入は組織全体のパフォーマンス向上にも寄与し、6%の改善が見られました。プラットフォームを活用することで、組織は迅速なソフトウェア提供やユーザーのニーズの満たし、ビジネス価値の向上を達成できるようになります。
プラットフォームの導入からの年数と生産性の関係を考慮すると、Platform Engineeringの取り組みの初期段階でパフォーマンス向上が見られ、その後、減少し、プラットフォームの成熟に伴って回復する傾向が見られます
長期的には、生産性向上が維持され、Internal developer platformがソフトウェア提供および運用プロセスにおいて果たす潜在的な役割の大きさが示されています。
プラットフォームユーザーが支援チームを介さずにタスクを完了できる場合、チームおよび個人レベルの生産性が5％向上することが分かりました。この発見は、Platform Engineeringの基本的な原則であるセルフサービスのワークフローを推進することの重要性を示しています。
プラットフォームチームにとっては、ユーザーからのフィードバック収集が重要であることを示しています。調査回答では、どのフィードバック手法が最も効果的かは示されていませんが、一般的な手法としては、非公式な会話や課題トラッカーに続いて、共同開発の継続、アンケート、テレメトリ、インタビューなどが挙げられます。
これらの方法はすべて、ユーザーが自立してタスクを完了できるかを理解するのに有効です。また、調査データでは、プラットフォームに対してフィードバックを収集しないことがネガティブな影響を与えることも示されました。
The unexpected downside
Platform Engineeringにはチームや個人の生産性向上、組織パフォーマンスの改善といった明確なメリットがある一方で、スループット（処理速度）と変更の安定性が低下するという欠点も見つかりました。
さらに、変更の不安定性とバーンアウト（燃え尽き症候群）の間には非常に興味深い関連性があることも予期せず発見しました。
Throughput
スループットに関しては、プラットフォームを使用しない場合と比較して約8%の減少を見ました。この背後にある原因についていくつかの仮説があります。
まず、変更が本番環境にデプロイされる前に通過する必要のある追加のプロセスが、全体的なスループットを低下させている可能性があります。一般的に、Internal developer platformを使用してソフトウェアを構築および提供する場合、システム間の「引き継ぎ」やチーム間の引き継ぎが増加します。
例えば、コードがソース管理にコミットされると、自動的に異なるシステムでテスト、安全性チェック、デプロイ、モニタリングが行われます。これらの各引き継ぎは、全体的なプロセスに時間が加わる機会となり、スループットが低下する一方で、作業を遂行する能力は増加する結果となります。
プラットフォームの存在によって、ソフトウェアの開発とリリースに関わるシステムやツールが増加する場合、適切でないプラットフォームを使用することが求められると、プロセスの自然な遅延が生じることが、独占使用と生産性の低下の関係を説明する可能性があります。
これに対抗するためには、ユーザー中心のアプローチを取り、Platform Engineeringの取り組みにおいてユーザーの独立性を高めることが重要です。
burnout
Internal developer platformを使用する際に開発および運用されるアプリケーションの変更の安定性を考慮すると、変更の安定性が驚くべきことに14%減少していることが観察されました。
これは、変更失敗率と再作業の発生率がプラットフォームを使用しているときに大幅に増加していることを示しています。
プラットフォームは開発者やチームが変更を自信を持ってプッシュできるようにし、変更が悪い場合には迅速に修正できるという利点があります。この場合、高い不安定性は必ずしも悪いことではなく、プラットフォームがチームに実験を行い変更を提供する力を与えているため、変更失敗と再作業のレベルが高まります。
また、高い変更の不安定性と燃え尽き症候群を抱えるチームが安定性を改善し燃え尽き症候群を減らすためにプラットフォームを作成する傾向があります。
これは、Platform Engineeringがしばしば燃え尽き症候群を減少させ、小さな変更を一貫して出荷する能力を高める実践として見なされるため、理にかなっています。
この仮説では、Platform Engineeringは燃え尽き症候群や変更の不安定性を抱える組織の症状と見なされます。
Developer Experience
Leading transformations
高パフォーマンスのチームは、自分たちを妨げている要因を理解し、DORAメトリクスを基準として体系的かつ継続的に改善を行っています。長期的な成功にはすべての柱での卓越性が求められますが、10年にわたるDORA研究から、組織内での変革を推進するための4つの具体的かつ影響力のある方法が明らかになっています。
- 安定性を優先
- ユーザーに焦点を当てる
- 優れたリーダーを持つ
- 質の高い文書を作成する
What can organizations do?
組織はユーザーを理解するために時間とリソースを投資することを推奨します。誰のために構築しているのか、彼らが直面している課題について理解することに焦点を当ててください。この投資は非常に価値のあるものだと強く信じています。
ユーザーについての仮定をする誘惑に抵抗しましょう。彼らの環境で観察し、質問をし、彼らの言うことに基づいて方向転換する謙虚さを持ってください。そうすることで、開発者はより生産的になり、燃え尽き症候群に陥りにくくなり、より高品質な製品を提供できるようになります。
内部文書は、ユーザーからの信号がなければ予測される製品のパフォーマンスに対して意味のある影響を与えないことがわかっています。しかし、チームが高品質の内部文書を持っている場合、その中に含まれるユーザーからの信号は、製品パフォーマンスに対してより高い影響を与えます。
具体的には、以下の2つの方法で、組織は優先順位の安定化を図ることができます：
優先順位の安定化: 組織の目標やプロジェクトの優先順位を明確にし、一貫した方向性を持つことで、従業員が混乱や不安を感じることなく作業できる。
日常業務への影響を防ぐ: 従業員が日常業務で優先順位の変動に振り回されることがないよう、必要なサポートやリソースを提供し、作業の安定性を保つ。
さいごに
今年はAIとPlatform Engineeringが大きく深ぼられていました。
どちらについても、良い点だけでなく、注意しなければいけない点がまとまっていたのがとても良かったと思います。
どちらについても採用するメリットは大きいですが...
闇雲にAIやPlatform Engineeringを採用せずに、メリット・デメリットを認識した上で採用することが重要です。
かなり省略しているので、詳細が知りたい人はぜひレポートをダウンロードしてみてください
※画像はすべて2024年版 State of DevOps Reportから引用しています
Discussion