開発者エクスペリエンス
"開発者がより多くのことを達成できるように支援する最善の方法は、より多くのことを期待するのではなく、エクスペリエンスを向上させることです。"
– DORA メトリクスの創設者で、Microsoft パートナー リサーチ マネージャーを務める、Nicole Forsgren 氏
開発者エクスペリエンス (DevEx) とは
開発者の支援
長年にわたり、組織はビジネスの加速化のために開発者の生産性を向上させることに重点を置いてきました。ただし、開発者の生産性だけに注目すると、過労、ミス、定着率の低下などの悪影響を及ぼす可能性があります。
パラダイムが変化しました。注目すべき話題は、開発者の生産性や開発者のベロシティといった成果ではなく、開発者エクスペリエンス (DevEx) を使用してこれらの成果をどのように持続可能な方法で達成するかという点に移っています。
DevEx は、開発者がコードを記述するのを支援するだけでなく、コードを記述するのに最適化された環境でコードを記述できるように支援することです。
Nicole Forsgren、Microsoft 社パートナー リサーチ マネージャー
DevEx が重要な理由
DevEx を最適化することでビジネス成果が向上します
DevEx の測定
SPACE フレームワークの概要
SPACE フレームワークは、開発者エクスペリエンスを理解し評価するための新しい包括的な方法を提供します。"生産性は、個人またはエンジニアリング システム以上のもの。1 つのメトリックまたはアクティビティ データだけでは測定できません...SPACE フレームワークは、生産性や開発者エクスペリエンスなどの複雑な概念のさまざまな次元をキャプチャするために開発されました。"
–DORA メトリクスの創設者で、Microsoft パートナー リサーチ マネージャーを務める、Nicole Forsgren 氏
-
満足度: 開発者は、業務、チーム、ツール、文化にどの程度満足していますか?
ウェルビーイング: 開発者はどのくらい健全で幸せですか?
メトリックの例• 開発者の満足度
• 開発者のリテンション期間
• エンゲージメント
• 燃え尽き
-
システムやプロセスの結果を評価します。パフォーマンスには多くの変数があるため、定量化は困難です。
メトリックの例コードの品質:
• 信頼性
• バグがないこと
• 継続的なサービス正常性コードの影響:
• 顧客満足度
• 顧客の導入とリテンション期間
• 機能の使用状況
• コスト削減
-
作業の実行中に完了したアクションまたは出力の数を理解します。
メトリックの例
• 完了したコード レビューの数
• コーディング時間
• コミットの回数
• コード行
• ストーリー ポイントが完了しました
• 配置の頻度
-
メンバーやチームがどのようにコミュニケーションをとり、共同作業しているかを把握します。
メトリックの例• コード レビュー スコア (品質または思慮深さ)
• pull request のマージ時間
• 会議の質
• ドキュメントと専門知識の発見可能性
-
開発者やチームが業務の進行状況を把握し、中断または遅延することなく完了できるかどうかを測定します。
メトリックの例• フローを維持し、作業を完了する開発者の認識された能力
• コード レビューのタイミング
• プロセス内のユーザー/チーム間のハンドオフの数
• 中断の数
DevEx の最新の調査
開発者の成長を支援する方法について説明します
DevEx の進化
• 2024 年 5 月
ポッドキャスト: SPACE フレームワークを使用して DevEx を測定しています
最新ニュース
DevEx の影響
• 2024 年 1 月
DevEx の実例: 具体的な影響に関する調査
ハイブリッド開発者
• 2023 年 5 月
両方の長所: ソフトウェア エンジニア向けのハイブリッド作業の可能性を引き出す
DevEx と AI
• 2023 年 2 月
開発者の生産性に対する AI の影響: GitHub Copilot からの証拠
Microsoft と GitHub が開発者の業務とウェルビーイングについて調査している開発者エクスペリエンス ラボ (DXL) を参照してください。
DevEx ツール
DevEx を最適化する最新の開発者ツール
すぐに使える、連携するツールを使用して開発を効率化します。
DevEx クイック チェック
DevEx 成熟度クイック チェック
このテストを使用して、お客様の組織の DevEx の成熟度を判定し、改善方法に関するガイダンスを受け取ってください。
-
はいの場合:
02 に進みます。いいえの場合:
開発者の問題点を理解することが、DevEx を改善するための最初のステップです。推奨される次の手順:
開発者にアンケートを実行し、次のような質問をします:
- 業務を遂行する上で最も難しいことは何ですか? またその理由は何ですか?
- 開発ツールとプロセスについて考えるとき、生産性に対する最大の障壁は何ですか?
- もし、私たちのチームがソフトウエアを作る方法をひとつ変えられるとしたら、それは何でしょうか?
-
はいの場合:
03 に進みます。いいえの場合:
DevEx は多面的であるため、理解するには多面的な枠組みが必要です。それが、弊社が SPACE フレームワークを考案した理由です。DevEx の次の 5 つのディメンションが考慮されています: 満足度と幸福度 (satisfaction and well-being)、パフォーマンス (performance)、活動 (activity)、コミュニケーションとコラボレーション (communication and collaboration)、効率とフロー (efficiency and flow)。DevEx を評価するには、少なくとも 3 つのディメンションの SPACE でメトリック/KPI を追跡することをお勧めします。
SPACE フレームワークの詳細と各ディメンションのメトリックの例については、こちらの研究論文を参照してください。
推奨される次の手順:- SPACE フレームワークについて説明します。
- 組織で優先すべき SPACE の 3 つの次元を選択してください (開発者の問題点と一致している必要があります)。
- これら 3 つのディメンションごとにメトリックを選択または作成します。
- 時間の経過と共にこれらのメトリックを追跡する方法 (DevEx ダッシュボードなど) を実装し、それらを使用して DevEx の取り組みの影響を評価します。それに応じてアプローチを調整します。
-
はいの場合:
04 に進みます。いいえの場合:
各メトリックの明確かつ現実的な目標を定義することが重要です。また、これらの目標が開発者の問題点と一致していることも重要です。目標を設定するのは難しい場合があります。パフォーマンスの高い他のチームや企業のメトリックを参照することを選択する場合もあれば、業界ベンチマークを参照する場合もあります。また、継続的な改善を反映するために、目標が時間の経過と共に変化する可能性があることに注意することも重要です。
DevEx の影響と考えられる ROI を定量化する方法の詳細については、ブログと研究論文を参照してください。
推奨される次の手順:- DevEx メトリックごとに明確で現実的な目標を設定します。
- 四半期ごとの会議を開催して、これらのメトリックを調べ、DevEx の進行状況を確認します。
- 表示される影響に基づいて、DevEx の取り組みと投資を調整します。
-
はいの場合:
05 に進みます。いいえの場合:
DevEx を改善する唯一の方法は、開発者の作業方法を改善することです。通常、これは開発者の作業を容易にするツールへの投資や、主要なプロセスの合理化を意味します。効果を高めるには、特定したメトリックを使用し、DevEx の改善業務に焦点を当て、追跡することをお勧めします。DevEx への投資を進める際のヒントを次に示します。- ワークフローから苦労を取り除きます。"非効率的な作業プロセス" を最も重要な仕事の課題として引用する開発者は、非生産的な感じを報告する可能性が 2 倍高く、他の仕事を探している可能性が 67% 高くなります。計画と作業管理のプロセスを合理化し、コンプライアンス ワークフローを改善することは、開発者の負担を軽減する効果的な方法です。
- 最新の開発ツールを入手しましょう。これは労力の軽減にもつながります。GitHub Copilot などの最新のツールを使用すると、開発者はタスクを最大 55% 速く完了でき、ドキュメント作成などの日常的なタスクに費やす時間を短縮できます。
- シフトのセキュリティが左に移動しました。ソフトウェア開発ライフサイクルの早い段階でセキュリティを優先することで、組織は運用環境に到達する前に問題に対処し、コストを削減し、開発者の時間を節約できます。最新の開発者ツールは、コードの作成時に脆弱性をスキャンして、これを支援することができます。
推奨される次の手順:- 新しいツールに投資したり、問題点や DevEx メトリックに合わせてプロセスを合理化したりして、開発者の作業方法の改善を始めます。
-
はいの場合:
[体験を続ける] に進みます。いいえの場合:
時々、組織は開発者に DevEx の責任を負わせるという間違いを犯すことがありますが、これは不公平なことです。なぜなら、会社のツールチェーンやプロセスを設計しているのは開発者ではなく、リーダーシップ チームだからです。DevEx イニシアチブは、開発者のエクスペリエンスを向上させるという明示的な目標を持つリーダーシップ チームによって主導される必要があります。また、リーダーシップ チームは、これらのイニシアチブの成功に対して責任を負う必要があります。
これは、開発者が DevEx イニシアチブに関与すべきではないと言いたいわけではありません。これらのイニシアチブは開発者の苦労する点に対処するように設計されているため、もちろん、開発者はプロセス全体を通して参照し、関与する必要がありますが、1 日の終わりに、リーダーシップ チームは組織内の DevEx を改善するための責任を負う必要があります。
推奨される次の手順:- リーダーシップ チームで DevEx チャンピオンを確立し、DevEx の取り組みを推進します。
- 四半期ごとのレビューを保持して、DevEx メトリックを調べ、進行状況を評価します。
- 開発者の意見は非常に貴重なため、DevEx 体験のすべての段階で開発者を参加させましょう。
-
お使いの DevEx は他のものよりも成熟していますが、その過程が完了することはありません。最新の DevEx のリサーチを読み、DevEx を改善できるモダンな開発者ツールを調べて、競争を先取りしましょう。
作業を開始
今すぐ DevEx を改善する体験を始めましょう
AI の力を組み込んだ最新のツールを提供して、ビジネスを強化し、開発者の成長を支援します。
DevEx ラボで詳細を確認する
Microsoft と GitHub の共同研究ラボから最新の DevEx パブリケーションを探索します。
専門家のサポートを受ける
DevEx の最適化に関する Microsoft のガイダンスが必要な場合は、営業チームにお問い合わせいただければ、適切なリソースに連絡できるようにします。
SPACE フレームワークを確認する
DevEx の測定の詳細については、SPACE フレームワークの研究論文全体をお読みください。