📊

State of Developer Experience Report 2024 概説

2024/12/21に公開

platform

!本記事はクラウドワークスグループ Advent Calendar 2024 21日目の記事です。
2024年9月に発表されたState of Developer Experience Report 2024の概説です。

 Developer Experienceの定義「開発者が、日常的にソフトウェアをデリバリーする際に使うツールやフレームワーク、プロセスに対してどう感じているか」
いわゆる開発者体験です。
ただし多くの組織では開発者の生産性とDeveloper Experienceを混同しているという結果もあり（例えば、今回のレポート回答者の41%が、開発者の生産性とDeveloper Experienceを評価するのに同じツールを使用している）、業界共通の認知を得ているとは言い難い状況です。
Developer Experienceは日常的にはDXと略すこともありますが、Digital Transformationとの混同を避けるためこの記事ではDevExと表記します。
「DevExを高めることは開発者の生産性を高める」という研究結果は多くありますが、「充実した仕事の結果の高い満足度」という見方もでき、実際の因果関係は定かとは言い切れません。
DevExを高めることが本質的な価値なのかというと、それよりもユーザーへの価値のデリバリーに集中することが我々の一義的な仕事であるのは確かです。
とはいえ、組織内におけるDevExの明らかな低下を放置してよいかというと、「そんなことは無い」というのがリーダーたちの総意です。

 レポート概説ここからはレポートの内容の概説。
世界中の様々な業界の2,100人以上の開発者およびマネージャーを対象に、Atlassian社が中心となって調査が実施された。ちなみに2024とあるが、2023以前はなく今年から開始されたリサーチである。State of DevOps ReportでもDevExについての調査が含まれているのでこのような調査が初というわけではないが、DevExの詳細にまで踏み込んだリサーチは初といえる。
※レポートはこちらから誰でもダウンロード可能

 サマリー総じて開発現場におけるDevExへの改善の余地は大きいという結果になっており、Mgrやリーダー層だけでなく、エンジニア個人個人においてもフラストレーションが溜まっている様子が伺える。


週に8時間以上の非効率な時間があるという回答が7割を占める


開発時間のロスの要因となっている（と感じている）TOP５
技術的負債 (59%)
不十分なドキュメント (41%)
ビルドプロセス (27%)
ディープワーク（作業集中）のための時間不足 (27%)
明確なディレクションの欠如 (25%)

 AIのインパクトに関するリーダーとエンジニアの捉え方に差分があるエンジニアリーダーとエンジニアの間には、DevEx向上におけるAIのメリット認識に関して大きな隔たりがある。ほとんどのリーダーがAIを重要視している一方で、エンジニアの3分の2はAIツールによる実質的な生産性向上を実感していないとのこと。

リーダー層はAIへの期待がTOPにきている一方



エンジニアの2/3はそこまでではない

 ここまでの考察
 Copilotingに対する期待の小ささ開発者はコーディングの時間にストレスを感じているというよりは、それ以外の仕事による非効率が耐え難い。であれば、Copilotのようなコーディングを楽にしてくれることは大きな課題解決に繋がらないという捉え方をしているといえる。もっと言うと「これ以上おれたちのコーディングの時間を減らさないでくれ！」である。

 開発者の負荷の高まり2020年代に入ってもソフトウェア開発者が求められる仕事は増え続けている。20年前まではコーディングがメインだったと言えるが（明確な分業体制だったとも言える）、それからテストを書き、クラウドコンピューティングやDevOps以降はさらに役割が多岐に渡ってきている。さらには続々と現れる新しい技術、作るプロダクトの複雑さ、ビジネスの難易度も飛躍的な高まりを見せる中で、開発者たちは市場競争のプレッシャーにさらされ、認知負荷の増大はとどまることを知らない状況と言える。

 業界全体としての危機感をもつ必要ソフトウェア開発に限らず、認知負荷が高まった状態でよいパフォーマンスを発揮できるかというと、誰しも限界がある。このまま我々の仕事が無制限に増え続けていくことを放置しているとソフトウェア業界は成熟していくどころか破綻していく可能性すらある。

 DevExをどう改善していくかレポートの内容に戻る


 フロー状態を保つことと認知負荷を減らすことは表裏一体アーカイブから情報を掘り当てたり、詳しい人物に尋ねることそれ自体というよりは、それによる浪費時間や待ち時間、心理的呵責がDevEx低下の大きな2要素であり、それらへの対処が必至。つまりは一元化された情報と標準化されたフォーマット、それらへのアクセシビリティの重要さを見直すべきである。

 DevEx向上における開発者フィードバックの重要性DORAやFour Keys、SPACEのような世に出回っている指標とフレームワークを自分たちの組織にも杓子定規に当てはめることも理解の隔たりの一例といえる。
DevExを向上させる最善の方法は、開発者と直接関わり、彼らのペインポイントを理解することだと強調する。外部のソリューションやツールだけでは、適切なコンテキストなしに社内の課題に対処することはできない。
また、課題の優先度付けが明確になっている組織は、そうでない組織よりも明確に満足度が高いという結果になっている。

 DevExを計測すること基本は定性調査である。
開発者に対する満足度調査には彼らのペインに対応する質問が含まれていないことが多く、課題の理解を手助けするための具体的な詳細を提供する必要がある。どの領域に優先的に取り組むべきかを明確にできることに価値がある。
アンケートなどの取り組みへの透明性を保つことも重要で、彼らが計測やフィードバックプロセスに参加することでDevExが向上する傾向があった。

 プラットフォームエンジニアリングとDevExCompass（Atlassian製） のようなプラットフォームは、プロセスを合理化し、認知負荷を軽減し、コラボレーションの促進を助ける。しかし、プラットフォームだけですべての問題を解決できるわけではなく、組織固有のニーズや開発者のフィードバックに合わせて調整する必要があり、それを仕組みとして構築していく役割を誰かが担わないといけない。
各種プラットフォームやフレームワークの作者もそのように推奨しているケースが多い。
つまりは現在のトレンドである「プラットフォームエンジニアリングチーム」の話になる。

プラットフォームエンジニアリングチームは、CI/CD、モニタリング、ロギングなどのインフラや開発者ツールを含んだ内部サービスを提供する。それらによってソフトウェアデリバリーチームが 組織の標準やプラクティスに準拠するのを容易にし、認知負荷を軽減し、自律的に作業できることを手助けする。
Gartner社によると、2026年までに大規模なソフトウェアエンジニアリング組織の80％が プラットフォームエンジニアリングチームを設立するという。DevExに与える影響を考慮すると、 プラットフォームエンジニアリングチームを擁立しないと、企業は間もなく不利な立場に立たされることになるだろうという観測がされている。

 企業規模と企業文化がDevExに与える影響DevExは各組織に固有のものであり、その規模、文化、意思決定プロセスの影響を受ける。大企業はツールを標準化する傾向があるが、中小企業はより柔軟性を提供し、ツールの乱立につながる可能性がある。
文化とは価値観により形成される。自分たちがバリューだと感じていることを形式知化し、摩擦が発生するポイントを解決していくことで、健全な文化が形成され、DevExが高まっていく。

 AIの役割はコード生成にとどまらない生成AIの公開当初、AIは主に開発者の役割であるコーディングの最適化に焦点を当てていた。しかし、AIはドキュメンテーションや社内サポートのような分野でもっと活用でき、DevExにもっと大きな改善をもたらすという認識も広まってきている。よって上記のような開発時間のロスの解決策になりえるような日進月歩の進化を遂げている。

 ここまでのまとめ
 主なDevEx改善組織による違いがある前提で、「自分たちにとっての日常的なペイン」についてのフィードバックループが回る仕組みを常に維持する
増えゆく複雑性に対処するための一手段としてのプラットフォームエンジニアリング（チーム）
健全なエンジニアリング文化とは「継続的な学習と継続的な改善を奨励する文化」であり、その文化を醸成すること
組織の文化が違えば、生産性を測定する方法も異なってくる
他社が計測しているものは基本的に自分たちには当てはまらないということ

AIがDevExの改善に貢献する可能性は引き続き注視していく価値がある

 総括レポートの結果自体にそこまで目新しいものがあったわけではなく、我々が日頃なんとなくそうではないかと感じていたことを裏付ける結果になったという総括で締めます。