はじめに
こんにちは、エンジニアリングマネージャーの八巻（@hachimaki37）です。今年の3月にファインディさん主催のイベントにて、DevExについて登壇しました。
登壇内容は、「DevExを推進する前に上手くいかなかったこと」や「具体的な取り組み」についてです。
本記事は、約1年半ほどDevExに向き合ってきたチームの「変化」と「その成果」について書いています。DevExが変化することには、どのような意味があるのでしょうか。そして、どのような効果があったのでしょうか。検証してみた結果を深掘りします。
注記：本記事は、以下3つの完結編です。合わせてお読み頂けると本記事の解像度が高くなるかと存じます。
目次
チーム変遷
入社当初は6名、そこから4名、3名と変遷をたどり、現在は8名のチームです。
取り組みの振り返り
本記事に至るまでの取り組みを簡単に振り返ります。
DevEx取り組みのきっかけと背景
- 開発者の開発者体験を良くしたいと思っていた際に、DevEx: What Actually Drives Productivity に出会う。
- 開発生産性向上を目的としたプロジェクト（DevExプロジェクト）を立ち上げ、フォースタートアップスの開発組織（以下、開発組織と呼ぶ）を横断して推進する。
DevExプロジェクトでの具体的な取り組み
- DevEx in Action を基に、開発者体験に関するアンケート調査（以下、サーベイと呼ぶ）を設計する。
- 開発組織でサーベイを実施する。
- サーベイの結果を分析し、グループごとに課題の定義、改善を実施する。
- 今日までに計3回のサーベイを実施する。
- 一回目：2024年06月
- 二回目：2024年09月
- 三回目：2025年04月
サーベイ結果の変化
開発組織
一回目のサーベイ結果から考えると、各種指標は数値改善が徐々に見られました。今日までに行ってきたグループごとの取り組みが、しっかり開発者体験の改善に貢献してきたと考えています。
所属グループ
三回目のサーベイ結果では、各種指標は4ポイント以上（ややあてはまる）の結果となりました。私が所属するグループ（以下、チームと呼ぶ）は、新しくジョインされたメンバーが多い中でしたが、ポジティブな結果となりました。また、各種指標も一回目のサーベイ結果から改善傾向にあり、課題への改善の取り組みが、開発者体験を向上する要因になったと考えています。特にフロー状態は、大幅な改善が見られました。
強みが続いた指標
課題とした指標と設問
- フロー状態
- 設問：途切れることなく日々継続的に開発に集中できる
- 認知負荷：
結果比較
一回目と三回目のサーベイ結果を比較しました。どの設問がどのくらい改善・改悪したのかです（取り組みは一例です）。
3ポイント未満から改善された設問
途切れることなく日々継続的に開発に集中できる：2.7 → 4.2（+1.6）
- 取り組み
- カレンダー調整（MTGの時間を意図的にまとめる）
- オンボーディングのプロセス効率化
- 取り組み
当初予期していなかった予定外のタスクや要求はほとんど受けない：2.8 → 3.7（+0.9）
- 取り組み
- スプリントゴールのissueに集中する（期待値の調整を行い、やらないことを決める）
- issueの粒度改善（PRが肥大化し過ぎないように、レビュアーにも優しい取り組みやすい粒度にする）
- 取り組み
プロジェクトのソースコードは、明確且つシンプルで理解しやすい：2.8 → 3.5（+0.7）
- 取り組み
- モブレビューやリファクタリング、コードレビューの観点ナレッジ化など、品質向上を目的に実施
- 取り組み
プロジェクトのソースコードを理解するためのドキュメントは十分である：2.2 → 3.2（+1.0）
- 取り組み
- 地道なドキュメントの整備や充実化
- 取り組み
減少した設問
チームで協力して対処する必要があるインシデントの頻度は低い：3.8 → 3.5（-0.3）
開発環境にはよく整備された自動テストがあり、結果を迅速に確認できる：3.8 → 3.7（-0.1）
テスト環境としてのCIは十分に整えられており、テスト結果を迅速に確認できる：3.8 → 3.7（-0.1）
プロジェクトのソースコードの品質は優れており、よくメンテナンスされている：3.4 → 3.2（-0.2）
チーム内およびチーム間でコードや作業を理解できるような取り組みが行われている：4.4 → 4.3（-0.1）
+1ポイント以上改善された設問
途切れることなく日々継続的に開発に集中できる：2.7 → 4.2（+1.6）
会議や中断がなく、まとまった時間を開発に充てることができる：3.0 → 4.2（+1.2）
内部の技術的な質問（たとえば、コードやシステム、または作業している領域について）をすると、10分以内に回答を得ることができる：3.0 → 4.2（+1.2）
変更したソースコードは、短いリードタイムで本番環境にリリースされる：3.0 → 4.2（+1.2）
プロジェクトやタスクの目標は明確で理解しやすい：3.0 → 4.0（+1.0）
プロジェクトのソースコードを理解するためのドキュメントは十分である：2.2 → 3.2（+1.0）
プロジェクトの開発環境の設定手順はよく整備されており、すぐに開発を開始できる：3.4 → 4.5（+1.1）
取り組みの成果
これら取り組みの結果、どのような成果をチームで生み出すことができたのでしょうか。以下 Findy Team+ を用いて、2024年度上期と2024年度下期（期間：2024年4月1日〜2025年3月31日）の対比を出してみました。あくまで参考値として紹介いたします。
「オープンからレビューまでの平均時間」と「レビューからアプルーブまでの平均時間」のスタッツの推移：減少傾向にある
プルリク作成数の推移：増加傾向にある
アウトプットの総量：+146%
※計算式：2024年度下期PR数 / 2024年度上期PR数 * 100
一人当たり生産性：+122%
※計算式：（（2024年度下期PR数 / 平均稼動人数）/（2024年度上期PR数 / 平均稼動人数））* 100
期待付加価値の生産性：+138%
※計算式：（2024年度の大きなリリース / 2023年度の大きなリリース）* 100
※Findy Team+の集計ではなく、あくまで個人的に集計した数値
まとめ
以下、DevEx in Action から抜粋した研究結果です。
Outcomes
When considering the outcomes of development work or the developer experience, many researchers and people think about productivity.8,21 In our years of experience, however, we have seen that the improvements in developers' work go far beyond personal productivity for individual contributors,16 to include team and organizational outcomes.7,11 This investigation considers outcomes at the developer, team, and organizational levels, which is supported by WDT.23
Developer outcomes
Developer outcomes are those that benefit an individual developer. In particular, prior WDT research shows that improved work design positively influences job performance, creativity,22 and learning5—three outcomes investigated in this study.
Team outcomes
Team outcomes are those that can benefit an individual developer but more likely accrue at the team level of work and are therefore operationalized and studied at this level. WDT also shows that outcomes such as quality benefit teams.22 In the context of DevEx, we want to capture how work design can impact the quality of the system the team can work in, and therefore capture this as code quality and technical debt.
Organization outcomes
Organization outcomes benefit a worker's employer.improvements in developer work positively affect an organization's profitability and its ability to achieve goals.
今回、Organization outcomes（開発生産性レベル3）までは追うことができておりませんが、 取り組みの成果から考える開発者体験と開発生産性の相関が少し見えてきた気がします。
- 開発者体験が向上することは、開発生産性の「変更のリードタイム（example：オープンからレビューまでの平均時間 → -6.1h、レビューからアプルーブまでの平均時間 → -2.2h）」の改善に繋がる。
- さらに、変更のリードタイムが減少することは、チームとしての「デプロイ頻度（開発生産性レベル1） → 平均+0.8件」の改善に繋がる。
- デプロイ頻度の増加により、「価値提供の量/頻度（開発生産性レベル2） → 結果+138%」が向上する可能性が高まる。
- ただし、「変更障害率 → 平均+1.1%」と「平均修復時間 → +22.6h」は結果的に悪化したため、結果だけ見ると相関は見えてこなかった。
さいごに
約1年半ほどDevExに向き合ってきて感じることは、顧客への価値提供の「量や頻度」は高めることができたと考える一方で、システムとしての品質や可用性という根幹部分には課題が残る結果となったなと感じています。この1年半ほどで得た学びや経験を活かしながら、本来のあるべき姿やチームとしての成長を考え続け、最適解を探していきたいと思います。今後の取り組みもまた発信していきます。
