こんにちは。Findy Tech Blog編集長の高橋（@Taka-bow）です。
DevEx（開発者体験）の認知度はわずか4.9%。この数字もまた、日本の開発現場が直面する課題の一つであり、同時に大きな伸びしろを示しています。
前回の記事では、Visual SourceSafe 15.8%という数字から見える技術格差と、AI時代に広がる生産性格差について取り上げました。今回は、その技術格差の背景にあるDevExに焦点を当て、日本の開発者が本当に求めているものを考察します。
DevExとは何か
日々の仕事の「体感」に着目する
DevEx（Developer Experience）とは、開発者がソフトウェア開発で得る体験の質を指します。開発者満足度調査とは異なり、開発生産性に直結する「体感」に着目する点が特徴です。
たとえば、次のような場面を思い浮かべてください。
- ビルドやテストの結果を待っている時間
- 必要な情報がどこにあるか分からず探し回る手間
- 会議の合間で集中が途切れる感覚
- コードレビューの返答がなかなか来ない状況
- 複雑なコードを読み解くのに消耗する時間
これらは開発者なら誰しも覚えがある場面ですが、DevExはこの「体感」を改善可能な課題として扱います。
2023年に発表された論文「DevEx: What Actually Drives Productivity」（著者：Abi Noda、Margaret-Anne Storey、Nicole Forsgren（DORA創設者）、Michaela Greiler）では、DevExを構成する3つの中核的な次元が提唱されています。
DevExの3つの次元
| 次元 | 説明 | 例 |
|---|---|---|
| Feedback Loops（フィードバックループ） | 開発者が行動に対する応答を受け取る速度と質 | ビルド時間、テスト実行時間、コードレビューの待ち時間 |
| Cognitive Load（認知負荷） | タスク遂行に必要な精神的処理量 | ドキュメントの質、コードの複雑さ、ツールの習得難易度 |
| Flow State（フロー状態） | 完全に集中して作業に没頭できる状態 | 中断の頻度、会議の多さ、自律性の度合い |
冒頭で挙げた場面は、この3次元に対応しています。
- ビルドやテストの結果を待っている時間 → フィードバックループ
- 必要な情報がどこにあるか分からず探し回る手間 → 認知負荷
- 会議の合間で集中が途切れる感覚 → フロー状態
- コードレビューの返答がなかなか来ない状況 → フィードバックループ
- 複雑なコードを読み解くのに消耗する時間 → 認知負荷
3次元フレームワークについては、過去の記事でも詳しく解説しています。興味のある方はあわせてご覧ください。
DevExが提唱された背景
DevEx論文の著者には、DORAの創設者であるNicole Forsgren氏が名を連ねています。DORA指標は組織レベルのデリバリーパフォーマンスを測定できますが、個々の開発者が日々の業務で何に困っているかは見えません。DevExは、この視点を補う「開発者中心のアプローチ」として提唱されました。
加えて、DevExに取り組むことは、開発者が所属する組織全体の力を引き上げることにもつながります。
- 【エンジニアの採用・定着】開発環境や働きやすさは、エンジニアが職場を選ぶ際の判断材料の一つです。DevExの改善は、人材の採用や定着にも影響します。
- 【生産性との関連性】前述のDevEx論文では、開発者が良い体験をしている組織ほど、実際の開発生産性も高いと報告されています。DevExは「開発者を甘やかす」のではなく、組織のパフォーマンスを最大化するための投資です。
DevEx認知度4.9%が示す日本の現状
開発生産性指標の認知度と活用度
エンジニアの採用競争力にも、組織の生産性向上にも直結するDevEx。しかし日本での認知度はわずか4.9%です。開発者が日々抱える課題を解決するフレームワークが、ほとんど知られていません。
調査では25種類の開発生産性指標について認知度と活用度を調べています。何が知られていて、何が知られていないのか。その差が、日本の開発現場の現状を映し出しています。
開発生産性指標の認知度・活用度（全25指標）
| 指標 | 認知度 | 活用率 |
|---|---|---|
| バグの数 | 58.1% | 31.8% |
| 残業時間 | 53.3% | 21.9% |
| コードの行数 | 52.9% | 22.9% |
| タスクの完了数（スプリントの達成率に含まれることもある） | 48.1% | 30.1% |
| テストカバレッジ | 34.1% | 18.2% |
| バグ修正のスピード（修正にかかる時間） | 27.7% | 9.9% |
| 顧客からのフィードバック | 26.1% | 10.9% |
| コミット数 | 24.7% | 6.9% |
| タスクの割り当て数（アサインされた数と完了した数の比率） | 23.7% | 9.9% |
| コードレビュー効率（レビューに要する時間や改善の質など） | 20.3% | 10.2% |
| ベロシティ（ストーリーポイントの消化速度） | 17.7% | 7.1% |
| 平均復旧時間（MTTR – Mean Time to Recovery）（単独計測） | 15.7% | 3.6% |
| デプロイ頻度（単独計測） | 13.9% | 3.4% |
| チームの幸福度（eNPSなど） | 11.3% | 4.5% |
| 変更リードタイム（単独計測） | 10.0% | 3.1% |
| 技術的負債の定量評価（コードの複雑性などを数値化） | 7.8% | 2.8% |
| コードのリワーク率（修正が必要になったコードの割合） | 6.5% | 2.9% |
| プルリクエストサイクルタイム（PRの作成からマージまでの時間） | 6.0% | 1.6% |
| デベロッパーエクスペリエンス（DevEx） | 4.9% | 2.1% |
| 変更失敗率（単独計測） | 4.6% | 1.8% |
| Flow Metrics（開発プロセス全体の流れを可視化する指標） | 4.4% | 1.9% |
| Four Keys / DORAメトリクス（変更リードタイム、デプロイ頻度、デプロイ失敗時の復旧までの時間、変更失敗率） | 4.3% | 2.4% |
| PSP（Personal Software Process） | 3.9% | 1.8% |
| SPACEフレームワーク（開発者の満足度、パフォーマンス、コラボレーションなど） | 3.8% | 1.8% |
| DX Core 4™（DORA、SPACE、DevExを統合したフレームワーク） | 3.1% | 1.3% |
| 知らない / 聞いたことがない | 14.0% | 18.2% |
| その他（具体的に） | 0.1% | 0.1% |
（N=798）
上位4指標（バグの数、残業時間、コードの行数、タスク完了数）は認知度50%前後で、いずれもアウトプットを直接カウントする指標です。これらは測定しやすい反面、開発者が日々感じている「ビルドが遅い」「情報が見つからない」「集中できない」といった体験とは直接結びつきません。
一方、DevExの認知度は4.9%に留まっています。開発者の体験を改善すれば生産性が上がるという考え方は、まだ日本では広まっていないようです。
興味深いのは、DORA指標を構成する「デプロイ頻度」「変更リードタイム」「平均復旧時間（MTTR）」「変更失敗率」の認知度です。個別指標としては4.6%〜15.7%の認知度があるにもかかわらず、「Four Keys / DORAメトリクス」というフレームワーク名の認知度は4.3%に留まっています。指標は知っていても、体系化されたフレームワークとしては認識されていないのかもしれません。
なぜDevExは日本で知られていないのか
先ほどの表を見ると、認知度の高い指標には共通点があります。「バグの数」「残業時間」「コードの行数」「タスク完了数」はいずれも数えやすく、報告しやすい指標です。一方、DevExが扱う「ビルドを待つストレス」「情報を探す手間」「集中が途切れる感覚」は、数値化しにくく、経営層への説明も難しい。測れないものは改善対象になりにくいのかもしれません。
もう一つ考えられるのは、開発手法との相性です。調査では、ウォーターフォール開発が36.8%、開発手法が「よくわからない」が18.2%で、合わせて55%を占めました。DevExはアジャイルやDevOpsの反復的な開発と親和性が高く、フィードバックを素早く得て改善を繰り返す文化が前提にあります。半数以上の開発現場では、そもそもDevExが機能する土壌がない可能性があります。
加えて、日本の産業構造も影響しているかもしれません。受託開発では「納品」がゴールになりやすく、開発者の体験は顧客への請求項目に含まれません。自社プロダクト開発と比べ、DevExへの投資が正当化されにくい構造があると考えられます。
CI/CDとドキュメンテーションに見る課題
DevExが知られていないということは、開発者の体験を改善するという発想自体が広まっていないことを意味します。その影響は、開発基盤の満足度に表れています。第4回でも取り上げたデータをDevExの視点で見直してみます。
開発基盤の満足度とDevExの対応
| 項目 | 満足度 | DevExの次元 |
|---|---|---|
| CI/CDパイプライン | 14.2% | フィードバックループ |
| ドキュメンテーション | 17.5% | 認知負荷 |
| タスク管理システム | 18.2% | 認知負荷 |
| コードレビュープロセス | 19.2% | フィードバックループ |
| 開発環境整備 | 24.7% | 認知負荷 |
（N=798、「満足」「やや満足」の合計）
CI/CDパイプラインの満足度14.2%は、ビルドやテストの結果を待たされている開発者が多いことを示唆しています。これはDevExの「フィードバックループ」の課題です。
一方、ドキュメンテーションの満足度17.5%は、新メンバーのオンボーディングに時間がかかったり、「あの人に聞かないと分からない」状態が続いたりする形で現れます。これはDevExの「認知負荷」そのものであり、開発者が本来のコーディングに集中できない状況を生んでいます。
阻害要因をDevExの視点で読み解く
開発基盤だけでなく、開発現場で日常的に挙がる「困りごと」にも、DevExの課題は潜んでいます。第3回で取り上げた「開発生産性を阻害する要因」をDevExの視点で整理すると、次のような対応関係が見えてきます。
| 阻害要因 | 回答率 | DevExの次元 | 影響 |
|---|---|---|---|
| 不明確な要件 | 53.5% | 認知負荷 | 何を作るべきか分からず、確認や手戻りに時間を取られる |
| 会議が多い | 38.7% | フロー状態 | 集中できる時間が確保できない |
| コミュニケーションの問題 | 33.6% | フィードバックループ | 必要な情報が適時に得られない |
| 技術的負債 | 30.5% | 認知負荷 | 複雑なコードの理解に時間がかかる |
日本の開発現場が抱える課題の多くはDevExの問題として捉えられます（影響はDevExだけに留まりませんが）。「不明確な要件」と「技術的負債」は認知負荷を高め、「コミュニケーションの問題」はフィードバックループを遅らせ、「会議が多い」はフロー状態を妨げます。
まとめ
今回は、DevExの認知度4.9%という数字から、日本の開発現場の現状を読み解きました。従来型指標（バグの数、残業時間など）が50%以上の認知度を持つ一方で、開発者の体験に着目するDevExは浸透していません。
CI/CDパイプラインの満足度14.2%、ドキュメンテーションの満足度17.5%という数字は、フィードバックループや認知負荷に課題があることを示しています。また、「不明確な要件」「会議が多い」といった阻害要因も、DevExの3次元で整理すると改善の糸口が見えてきます。
認知度の低さは、裏を返せば伸びしろの大きさです。開発者の体験を改善することが、結果として組織のパフォーマンス向上につながります。
次回は「なぜDORA指標は日本で普及しないのか ── 認知度4.3%の背景と打開策」をお届けします。
- 調査全体について
- 開発手法による意識の違いの本質
- 取り組みが失敗する本当の理由
- なぜ従来型ツールから移行できないのか
- 日本の開発者が本当に求めているもの
- 数値化への懸念と向き合う方法
- 経営層を説得する具体的な方法
- 品質文化を強みに変える改革のロードマップ
お知らせ
「Development Productivity Conference 2026」が2026年7月22日〜23日に開催されます。継続的デリバリー（CD）の先駆者であり『継続的デリバリーのソフトウェア工学』著者のDave Farley氏が初来日。日本からはテスト駆動開発の第一人者・和田卓人氏が登壇します。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。
