開発者エクスペリエンスの仕組みとそれが重要である理由

開発者エクスペリエンス (DX または DevEx) では、開発者の実際のエクスペリエンス、すなわち日々の作業で直面する障壁や、仕事に対する感情的なつながりに焦点が当てられます。

この記事では、開発者エクスペリエンスが重要である理由と、開発者エクスペリエンスの向上が開発者や組織に良い結果をもたらす仕組みについてご説明します。さらには、チームに有意義な変化をもたらすための推奨事項もご紹介します。

開発者エクスペリエンスを理解する

開発者の生産性が主な焦点となって以来、多くのエンジニアリング チームにおいて、開発者エクスペリエンスが広く議論されるようになりました。ここ数年、開発者の人材やテクノロジーへの投資を最大限に活用するというプレッシャーが高まっており、リーダーたちは、高パフォーマンスで生産性の高いチームを構築していることを証明するために、多大なリソースを費やしてきました。

その一方で、労働時間やコードの行数などの誤った指標で評価される開発チームは、恣意的な要件を満たそうとすることで生産性を低下させています。アトラシアンの State of Developer Experience レポートでは、生産性の指標を使用しているエンジニアリング リーダーの半数以上が、開発者の生産性を測定する指標として効果的ではないと感じていることがわかりました。組織の 38% が開発者の生産性を作業時間で測定しているにもかかわらず、開発者の 69% が作業の非効率性によって週に 8 時間以上を失っていることを考慮すると、これは当然の結果と言えるでしょう。

レポートの全文を読む

開発者エクスペリエンスが重要である理由

組織が開発者エクスペリエンスの主要な構成要素を改善すると、開発者は本当に重要な作業、つまり高品質なソフトウェアのリリースという作業により多くの時間を費やせるようになります。好きなことに集中できる開発者は、障害に直面しながらより多くの作業を強いられる開発者よりも、はるかに高い生産性を保ちます。

より優れた開発者エクスペリエンスは、開発者の生産性を向上させるだけではありません。開発者が自身の役割においてより大きな満足感を得るため、チームを離れる可能性も低くなります。

人材の獲得と定着という面でも、開発者エクスペリエンスは極めて重要です。アトラシアンのレポートでは、開発者のうち 63% が現在の仕事を続けるかどうかを決める際、開発者エクスペリエンスを重要、または非常に重要であると考えていることが示されています。さらに、リーダーの 86% は、開発者エクスペリエンスを向上させなければ、優秀な開発者人材を獲得して定着させることはほぼ不可能であると考えています。

開発者エクスペリエンスの構成要素

調査によると、ポジティブな開発者エクスペリエンスには 3 つの主要な構成要素があります。

1. 学習と調整を通じて継続的改善を可能にするフィードバック ループ

2. 適切に整理されたコードとアクセスしやすいドキュメントに基づく、管理可能な認知的負荷

3. 開発者がタスクをスムーズに進め、作業に完全に没頭できる「フロー状態」への到達力

開発者エクスペリエンスに影響を与える要因

開発者エクスペリエンスは、ツールの品質とソフトウェア開発の効率に大きく影響されます。ツールとプロセスによって、この 3 つの要素すべてが日常的に可能になると、開発者エクスペリエンスが飛躍的に向上し、開発チームはより高品質なソフトウェアとスタッフの満足度向上という恩恵を受けます。

さらには、チームにおける文化も開発者エクスペリエンスに影響を与えます。フィードバック ループを促進せず、作業のためのフォーカス タイムを確保せず、開発者のニーズをサポートしないチームは、優れたエクスペリエンスを提供できません。最終的には、ツールと文化の変革を組み合わせることが、より優れた開発者エクスペリエンスの提供に役立ちます。

開発者エクスペリエンスを向上させる戦略

組織は開発チームのエクスペリエンスを直接制御できます。つまり、開発者エクスペリエンスを意図的に向上させることが可能であり、またそうすべきなのです。

チームや組織によってニーズや課題は異なりますが、こうした戦略は開発者エクスペリエンスの向上を目指すにあたり、良いスタート地点となります。戦略を実装することで、こうした変化が開発者の満足度に大きな影響を与えて、生産性の向上をリードする可能性があります。

ツールとテクノロジー

DevOps ツールチェーンで提供される豊富で多種多様なデータ ポイントを最大限に活用しましょう。進行中のタスク、バグ数、解決までの時間、SLA 遵守、リリース準備状況、スプリント バーンダウン、ビルド ステータスを表示するモジュールを追加すると、開発者が作業の全体像を把握しながら進捗を確認できるため、継続的なフィードバック ループを確立できます。

チームが扱うマイクロサービスやその他のコンポーネントをより詳細に確認するには、アトラシアンの内部開発者プラットフォーム (IDP) である Compass のコンポーネント カタログやシステム スコアカードをお試しください。開発者は、所有するユーザーや他のシステムとの連携など、コンポーネントでの作業に必要となる情報にすばやくアクセスできます。一方、リーダーはスコアカードによってソフトウェアとチームの健全性を追跡し、ボトルネックやブロッカーを特定できます。

ドキュメント

アトラシアンの「開発者エクスペリエンスの現状」レポートでは、開発者のうち 41% が、非効率なドキュメントをメジャーな障害として報告しています。一方で、開発者に自分たちが必要とするドキュメントを作成する時間 (または意欲) が常にあるとは限りません。AI を活用すれば、コードやプロセス ドキュメントを迅速かつ簡単に作成できるため、開発者が開発者エクスペリエンスの向上に貢献する、より影響の大きいタスクに集中できるようになります。

開発者エクスペリエンスに影響を与えるのは、ドキュメントの作成だけではありません。Stack Overflow が行った最新の開発者アンケートによると、開発者のうち 4 分の 1 以上が、毎日 1 時間以上を情報の検索に費やしています。Atlassian Rovo のような AI ツールがあれば、既存の社内ドキュメントやプロジェクト管理ツールから情報を収集して要約できるため、ソフトウェア開発から離れる時間や、面倒な検索に費やす時間を削減できます。

オンボーディング プロセス

オンボーディング プロセスが不十分であると、開発者エクスペリエンスの質も低下します。開発者が成功できる環境を整えることで、新しい役割への満足度が高まり、より早く戦力になることができます。優れたオンボーディング エクスペリエンスは、チーム メンバーが自分の役割のさまざまな側面や新しいソフトウェア コンポーネントに慣れていく過程で、後から参照できるものでもあります。

包括的なソフトウェア コンポーネント カタログにより、Compass では開発者に必要なすべてのものが、単一の標準化された場所に揃っています。これにより、新入社員は最初の数週間で大量のドキュメントに目を通したり、他のチーム メンバーに常に指導を求めたりする必要がなくなります。すべてが一元化された単一のスペースにあるため、今後に備えて記憶する必要も、ブックマークする必要もありません。リポジトリやライブラリから API に至るまで、コンポーネント カタログ内のすべての項目は、すばやく簡単に検索できます。

オンボーディングのアイデアに関する詳細は、アトラシアンの従業員オンボーディング手順をご覧ください。

サポートとコミュニティ

開発者エクスペリエンスとは、ソフトウェアを作成するために使用するツールやプロセスについて、開発者がどう感じているかを示すものです。つまり、組織において開発者エクスペリエンスの状況を把握しているのは開発者自身ということです。開発者の意見に耳を傾けることで、チーム内でコミュニティが構築され、開発者エクスペリエンスへのサポートを示せます。

小規模な組織であれば、すべての開発者と直接対話できますが、スケーラブルなプロセスとフィードバックのための安全なスペースを構築するためにも、開発者エクスペリエンス調査の実施をお勧めします。調査結果を活用することで、特定の重点分野における改善状況を追跡できます。開発者エクスペリエンスに注力していることがチームに伝わるように、受け取ったフィードバックをきちんと受け止めて、必ず対応するようにしましょう。

定期的なチームのふりかえりは、開発者とリーダーがうまくいっていることを共に振り返り、ポジティブな開発者エクスペリエンスに必要となるフィードバック ループを構築する機会となります。議論は、ワークロードや期限などの文化的なトピックから、API 設計などの技術的な問題まで多岐にわたります。アトラシアンのふりかえりプレイは、ふりかえりをスムーズに始められるように、基本的なふりかえりの手順やテンプレート、特定の状況に応じたバリエーションが提供されます。

文化と作業環境

開発者がフローを維持するには、中断されることのない、まとまった集中時間が必要です。それは、ミーティングや絶え間ない通知が常態化しているような文化を避けるということです。ツールセット全体から開発者が必要とするあらゆる情報や知見を統合する、Compass のような一元管理型のツールを活用することでも、コンテキストの切り替えを減少できます。

一部のチームでは、毎週 1 日または 2 日を「ミーティングなしの日」として設けています。よりアドホックなアプローチとしては、各自の都合がいい時間に 90 分から 120 分の時間枠をいくつかカレンダーに確保するよう、チーム メンバーに促しましょう。その他のアイデアについては、アトラシアンの「ミーティングに関する 2023 年レポート」をご覧ください。

開発者が電話をサイレント モードにして、チャットの通知を切り、チームが集中できる作業環境を構築しましょう。

Compass による開発者エクスペリエンスの向上

Compass は IDP であり、開発者エクスペリエンスのすべての要件を満たします。

• フロー状態の維持: 開発者が、情報を求めてアーカイブを探し回ったり、チーム メンバーの作業を妨げたりする必要はありません。Compass では、包括的なソフトウェア コンポーネント カタログを通じて、あらゆる情報が標準化された形式で、単一の場所において提供されます。

• 認知的負荷の軽減: 開発者は一元化された単一のスペースで情報にアクセスできるため、どこに何があるのかと記憶に頼る必要がありません。

• フィードバック ループの提供: チームは、毎週のデータに基づくふりかえりや CheckOps の実践を通じて、運用上の健全性を一緒にレビューし、パフォーマンスを継続的に向上させられます。

こうした改善を行うことで、作業がよりスムーズで楽しめるものになり、組織における開発者エクスペリエンスが向上します。

開発者エクスペリエンス: よくあるご質問

優れた開発者エクスペリエンスとは

優れた開発者エクスペリエンスでは、開発者が最も重要なこと、つまり高品質なソフトウェアをより頻繁にリリースすることに集中できます。また、開発者がフローを維持できる環境が提供され、認知的負荷が軽減し、フィードバック ループを確立できます。その結果、開発者は自身の役割に満足し、オンボーディングがスムーズに行われ、より効率的にソフトウェア開発に集中できるようになり、次の役割を探すこともなくなります。

開発者エクスペリエンスの測定方法

開発者エクスペリエンスを測定するための万能な指標や指標セットは存在しません。これは、開発者エクスペリエンスがチームや組織の状況に大きく依存するためです。すべての企業が開発者エクスペリエンスを向上させるために同じツールと指標を使用したとしても、その結果はチームや企業によって大きく異なるでしょう。

ご自身の組織における開発者エクスペリエンスを理解するには、開発者が日々経験していることの全体像を把握する必要があります。まずは、次に挙げる 3 つの主要なエリアから、有意義な指針を設定しましょう。

• 認識: 開発者は自身の作業や作業環境についてどのように感じていますか?

• ワークフロー: システムやプロセスはどの程度、効率的で信頼性が高いですか?

• 主要業績指標 (KPI): チームはどのような指標に注力していますか? 従業員満足度、ソフトウェア デリバリーの体感的な容易さ、またはチームの体感的な生産性を検討しましょう。

これらのすべてのエリアで、開発者エクスペリエンス調査を使用することをお勧めします。まずは、開発者エクスペリエンス調査プレイをお試しください。

開発者エクスペリエンスの柱とは

ポジティブな開発者エクスペリエンスの 3 つの主要な構成要素は次のとおりです。

1. 学習と調整を通じて継続的改善を可能にするフィードバック ループ

2. 適切に整理されたコードとアクセスしやすいドキュメントに基づく、管理可能な認知的負荷

3. 開発者がタスクをスムーズに進め、作業に完全に没頭できる「フロー状態」への到達力