株式会社renue
コンサルティング
コンサルティングで、この記事のテーマを実務に落とし込めます
renueが社内で運用しているシステムをサービス化したものです。何ができるか、どう動くかをサービスページでご覧ください。
デベロッパーエクスペリエンス（DevEx）は、開発者が仕事を進める際の体験と、日常的に生じる摩擦に着目する考え方です。生産性を改善するには、コードを書く速さに加え、確認待ち、必要な情報の探しにくさ、変更後の手戻りまで見ます。本記事は2026年10月26日に確認した公式資料をもとに、DORA・DX Core 4との違いと、測定から改善につなげる手順を整理します。
DevExの測定は、開発者の体験と作業の記録を組み合わせる
DX社の2023年研究の公開概要は、開発者からのフィードバックと、利用するエンジニアリングシステムのデータを組み合わせる測定を説明しています。ログには作業の発生や完了が残っていても、担当者が何を理解できず困っていたかまでは分からない場合があります。一方、体感だけで待ち時間や改善後の変化を捉えることにも限界があります。両者の食い違いを調べることが改善の入口になります。
たとえば「レビューが遅い」という声があっても、依頼から初回の反応までが長いのか、指摘の内容が分からず往復しているのか、承認後のテストを待っているのかで対策は異なります。平均時間の集計に加えて、実際の変更の流れと、担当者が支援を必要とした場面を確認します。短い変更と大規模な変更、新規開発と障害対応を一緒にして、担当者の能力の差と解釈することは避けます。
質問を、対処できる摩擦へつなげる
現行のDX Core 4公式ガイドは、DXIを開発者体験に関するサーベイとし、摩擦、フロー、認知負荷をシステムの記録だけから推定するものとはしていません。次の表は、この観点を自社の質問と確認作業へ置き換えるための本記事の例です。公式の質問票や共通の合格点ではありません。
| 観点 | 質問の例 | 一緒に確認するもの |
|---|---|---|
| フィードバック | 結果を得るまで、どこで待つか。指摘を次の行動に使えるか | テストの実行・待機時間、レビューの依頼と返信、差し戻し理由 |
| 認知負荷 | 変更するために、何を調べ、誰に聞く必要があるか | 手順の所在、環境構築のつまずき、担当や依存関係の不明点 |
| フロー | 集中を中断する依頼や、作業の切り替えは何か | 割り込みの種類、未完了作業、問い合わせの受け渡し |
調査の前には、結果を何の改善に使い、誰が閲覧し、どの単位で共有するかを説明します。少人数の回答や自由記述は個人が推測されることもあるため、集約と引用の範囲を決めます。回答がなかったことを満足している証拠にせず、回答率や対象職種も記録します。点数を収集して終わらせず、挙がった問題への対応と、今回は対応しない理由を担当者へ戻すところまでを運用に含めます。
DORAの5指標は、一つのサービスのデリバリーを測る
DORAの現行ガイドは、変更のスループットを3指標、不安定さを2指標で捉えています。DevExの体験の調査と関連づけて使えますが、同じ測定ではありません。DORAは変更を届ける過程の成果を扱い、顧客にとっての価値や、開発者の感じる負担をすべて一つの数値にまとめるものではありません。
| 指標 | 何を測るか | 区分 |
|---|---|---|
| Change lead time | 変更のコミットから本番デプロイまでの時間 | スループット |
| Deployment frequency | 一定期間のデプロイ回数、またはデプロイ間隔 | スループット |
| Failed deployment recovery time | 即時対応を要する失敗デプロイからの復旧時間 | スループット |
| Change fail rate | デプロイ後に即時対応が必要になったデプロイの割合 | 不安定さ |
| Deployment rework rate | 本番インシデントを受けて行う計画外デプロイの割合 | 不安定さ |
復旧時間は、原因を問わないすべての障害の平均復旧時間と混同しません。変更失敗率と手戻り率も、同じ名前の言い換えとして扱わないようにします。過去のFour Keysや特定年度の調査群の値を、現在の全システムに必須の合格基準として適用することも避けます。本記事では過去のElite群の数値表を、共通の目標値としては提示していません。
対象と分母を決めてから、変化の理由を確かめる
実装時には、アプリケーションまたはサービスの範囲、環境、本番への変更と数えるイベント、インシデントとの対応、計測期間を記録します。取得できないログや関連づけられない変更は、失敗がなかった扱いにせず未取得として残します。集計方法を変更した場合は、同じ時系列の途中で条件が変わったことを示します。件数の少ない期間は、率だけでなく対象件数を併記すると判断の前提を確認できます。
DORAは異なるアプリの単純比較や、数値そのものを競争の目標にする使い方に注意を促しています。実務でも、デプロイを細分化して回数だけを増やす前に、利用者への影響と検証の負担を確認します。自社の同じサービスで、待ち時間、変更の大きさ、失敗後の作業を振り返り、次に改善する制約を選びます。開発・運用の責任分担や実装の流れは、DevOps導入とCI/CD・運用の設計で確認できます。
DX Core 4とSPACEは、活動量だけの評価を避けるために使う
DX Core 4の提唱者による解説は、DORA・SPACE・DevExの考え方を取り込み、Speed、Effectiveness、Quality、Business Impactの4つの観点を組み合わせています。速度だけが向上したときに、品質や体験が悪化していないかを合わせて検討するための枠組みです。指標を増やして一つの人事評価点へ合算することを目的にはしません。
製品上の集計では、自己申告とシステム計測で測る対象が異なることにも注意します。現行公式ガイドでは、SpeedはPR統合のペース、EffectivenessはサーベイによるDXIです。Qualityは自己申告の変更失敗割合と、システム上で不具合修正に分類したPRの割合を区別しています。Impactも新しい機能に向けた時間の割合と、分類されたPRの割合を区別しています。システム集計の利用条件はDX Data Cloudと案内されています。これらを、同じ値が別の方法で取得できるだけと考えないようにします。
新機能に分類されたPRの割合は、顧客の継続利用や売上・利益を直接測った値ではありません。不具合修正のPR割合も、本番の失敗デプロイ率とは同一ではありません。比較する際は、集計方式、分類の基準、対象者、対象期間が同じかを確認します。自己申告の振り返り期間とシステム側の集計窓にも違いがあるため、切り替え前後の数値を説明なしでつなぎません。未提供の計算方式の予告を、現在の全契約で使える機能とは扱いません。
「一人当たり」は、個人の貢献そのものを表さない
提唱者の解説も、スループットの利用には、体験など反対方向の指標との組み合わせ、目標や報酬への直接的なひもづけを避けること、誤用を防ぐ説明を条件として挙げています。PRの分け方、レビュー・調査・支援の役割、ボットの扱いや対象人数が違えば、一人当たりの値の意味も変わります。本記事では、チームの仕事の流れを改善する資料として扱い、PRが多い人ほど能力が高いという判断には使いません。
Microsoft Researchが公開するSPACE論文の概要も、生産性を個人の活動量や単一の指標・次元だけでは測れないと説明しています。どの枠組みを使う場合も、数値から分かる範囲と分からない範囲を説明します。レビュー支援や障害予防の貢献が記録に見えない場合は、追加の対話や成果の確認が必要です。製品の導入と、組織の評価制度の設計は分けて検討します。
開発の改善に環境負荷の観点を加える場合は、グリーンソフトウェアとSCI・カーボンアウェア開発をご覧ください。DORAのデリバリー指標やDX Core 4の体験・活動量と、機能単位当たりの炭素強度は別々に定義します。強度と総排出量、実測と推計、品質・時間・費用を合わせて比較する手順を整理しています。
テストの待ちや失敗の調査を改善する場合は、Selenium・PlaywrightとAI修復を比べるテスト自動化の確認点をご覧ください。操作の成功と期待結果の検査、待機する条件、自己修復による誤った合格、初回失敗と再実行の記録を分けています。実行時間だけでなく、データ準備や誤検知の確認・保守まで含めて比べることで、テストの件数と開発者の負担、利用者へ届ける品質を混同せず改善を検討できます。
改善は、小さな課題の検証から実装・運用へつなげる
最初に、困っている作業、担当者、利用者への影響を一つ選びます。次に、現状の記録とサーベイを照合し、変える作業と確認する結果を決めます。たとえばテストが遅いなら、実行そのものと実行待ちを分け、失敗の調査や再実行にかかる負担も調べます。環境構築が難しいなら、必要な権限、手順の不足、依存する設定を確認します。以下は本記事の進め方の例で、共通の導入期間や必要人数を定めるものではありません。
- 対象サービスと改善する摩擦、測定の使い道・共有範囲を合意する。
- ログと担当者の声を照合し、取得漏れ・対象外と比較期間を記録する。
- 変更する手順、担当者、確認項目、戻す条件を決めて小さく試す。
- 待ち時間だけでなく、手戻り、品質、運用・保守の負担を確認する。
- 結果と理由を共有し、手順・教育・担当を更新して次の課題を選ぶ。
ポータルの導入と、仕事の改善を分けて評価する
Backstage Software Catalogの公式資料は、ソフトウェアの所有者とメタデータをまとめ、所在や担当を発見できるカタログを説明しています。情報探索の課題への選択肢ですが、ポータルを作るだけで手順が最新になるわけではありません。登録する情報、更新の責任、認証・閲覧範囲、誤った情報の修正を決めます。内部開発者プラットフォーム（Internal Developer Platform）全体と、その入口となるポータル、個別カタログの機能も区別します。
AIの効果は、生成した量から本番での結果まで確かめる
DORA 2025年報告の公開案内は、AIが組織の既存の強みと弱みを増幅する役割を説明しています。これを、特定ツールで必ず生産性が上がるという約束には使いません。AI導入前後では、依頼の難しさ、担当者の構成、レビュー・テストや他の改善の変更も記録します。入力した回数や生成行数に加え、確認と修正の時間、統合後の不具合、利用者への結果を追います。前後差があっても、同時に変えた条件があれば、AIだけの因果効果と即断しません。
費用には、利用料、設定・連携、計測、教育、確認と保守を含めます。削減できた時間の金額換算と、実際の支出削減や追加利益は区別します。固定の人数・期間や一般的な削減率から便益を決めず、自社で確認できた結果を使います。renueのFDEによる要件整理・設計・実装・運用支援では、現場の課題とKPI、既存ツールとの接続条件をもとに支援範囲を相談できます。測定画面や連携、改善手順の実装・運用を検討する用途で、特定の分析製品・プラットフォームの標準導入や、人事評価・生産性向上率を保証する案内ではありません。