デベロッパーエクスペリエンス（DevEx）とは: 開発生産性Conference 2024 に向けて

こんにちは！ファインディの @Taka-bow です。

まもなく「開発生産性Conference 2024」が開催されます。2日目のキーノートスピーカーであるNicole Forsgren博士は、昨年はビデオ越しのご登壇でしたが、今回は来日してくださる予定です。

昨年は「SPACE：生産性フレームワーク」の研究についてご紹介いただきましたが、今回はどのようなお話を伺えるのでしょうか？

ご講演のタイトルは

Mastering Developer Experience: A Roadmap to Success
（デベロッパーエクスペリエンスを極める：成功へのロードマップ）

とのこと。大変楽しみです。

dev-productivity-con.findy-code.io

博士は、書籍 "Accelerate" *1 の筆頭著者としても広く知られていますが、最近はデベロッパーエクスペリエンス（DevEx: Developer Experience）研究の第一人者としても注目されています。

そこで、そもそもデベロッパーエクスペリエンスとは何か？博士らの論文を引用しながら紐解きたいと思います。

デベロッパーエクスペリエンスの科学的な研究

Nicole Forsgren 博士らがデベロッパーエクスペリエンス（以降、DevEx）に関して発表した論文はいくつかありますが、今回は最近の2つの論文にフォーカスします。

1つ目は、昨年5月 Association for Computing Machinery（ACM）で発表された

"DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity"
『DevEx: 何が実際に生産性を向上させるのか：生産性を測定し改善するための開発者中心のアプローチ』

2つ目は、今年1月に発表された

"DevEx in Action: A study of its tangible impacts"
『実践的 DevEx：その具体的な影響に関する研究』

どちらの論文も、DevEx の「質」が、開発生産性に大な影響を与えているという仮説を、科学的に証明しようと試みています。

デベロッパーエクスペリエンスの3次元

DevEx とは、ソフトウェアエンジニア（ここで指す開発者）が日々経験している業務、言い換えれば「エンジニアの業務体験や環境」そのものを指しています。

そして、影響を与える要因を「DevExの3次元」フレームワークと呼びます。

DevExの3次元参照: Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.

それぞれ、

Feedback Loops (フィードバックループ)
Cognitive Load (認知負荷)
Flow State (フロー状態)

と言います。これを意識することで DevExの改善ステップがより具体的にできます。

Feedback Loops (フィードバックループ)

フィードバックループは、テスラのような自動運転の自動車をイメージすると分かりやすいでしょう。

自動運転車は、前方や左右の障害物、車間距離などを判断するために、センサーやカメラから得られる情報を高速で処理するフィードバックループが必要です。この処理が遅いと、障害物にぶつかってしまう可能性がありますよね。

Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons

ソフトウェア開発組織は、デリバリーの遅延を減らしてアウトカムの流れを最適化しようとしています。遅延が減ることで、フィードバックと学習が迅速に行われ、速やかな軌道修正が可能となります。

研究によれば、頻繁なデプロイとリードタイムの短縮がパフォーマンス向上に繋がるとされています。迅速なフィードバックループは、開発者が障害なく作業を進めるのに役立ち、逆に遅いフィードバックループは中断や遅延を引き起こし、開発者のフラストレーションを増します。

フィードバックループを高速にするための改善案として、次の点が挙げられます。

開発ツールの高速化：ビルドやテストの時間を短縮。
人の引き継ぎプロセスの改善：コードレビューや承認の迅速化。
組織構造の最適化：チーム間の相互作用を合理化し、遅延を減らす。

これらの改善により、ソフトウェア開発の効率と生産性を向上させることができます。

Cognitive Load (認知負荷)

2011年に旧Twitterで話題になった案内板がありました。

その案内板がこちら

新宿エルタワーの案内板
参照： https://note.openvista.jp/2011/redesigning-shinjuku-building-sign, CC BY-SA 4.0

さて、トイレに行くにはどちらに進めば良いのでしょう？前？右？左？と混乱する人が大勢いたそうです。

（正解は左）

少なくとも、ほとんどの人がぱっと見て分からない状態は「認知負荷が高い」と言えるでしょうね。

余談ですが、この案内板はその後認知科学の分野で研究もされ発表されました。

2016年度日本認知科学会第33回大会【矢印を用いた「組み合わされた方向サイン」のわかりやすさ：構造，アイコン，加齢の効果】：研究リンク

ソフトウェア開発は複雑であり、ツールや技術が増えることで開発者の認知負荷が増加しています。認知負荷とは、タスクを実行するために必要な精神的な処理量を指します。

難しいタスクや新しいフレームワークの理解に取り組む場合、この負荷は特に高まります。また、情報の提示方法や精神的な処理が必要な場合も負荷は増加します。

高い認知負荷は、開発者が顧客に価値を提供する妨げとなります。不十分なドキュメントや複雑なシステムにより、開発者はタスク完了に多くの時間と労力を費やすことになります。

認知負荷を軽減するには、次の改善案が挙げられます。

不要な障害の排除：開発プロセスから不必要な障害を取り除く。
整理されたコードとドキュメント：理解しやすいシステムを構築し、コンテキストやタスクの切り替えを減らす。
専任のDevExおよびプラットフォームチーム：使いやすいセルフサービスツールを提供し、開発とリリース手順を合理化する。

これにより、開発者の認知負荷を軽減し、効率的に価値を提供できる環境を整えることができます。

Flow State (フロー状態)

弓道における基本的な射法の8つの動作を射法八節（しゃほうはっせつ）と言います。

足踏み（あしぶみ）
胴造り（どうづくり）
弓構え（ゆがまえ）
打起し（うちおこし）
引分け（ひきわけ）
会（かい）
離れ（はなれ）
残心（ざんしん）

この中でも、6番目の「会」は、他が具体的な動作にも関わらず、これだけが少し違います。簡単解説！射法八節によると、

引分けが完成し、矢を放つ機会を待つのが「会」です。丹田に力を入れ、自然な呼吸を心がけます。肩と肘の高さに注意しましょう。体全体のバランス、重心に気を配り、的をしっかりと見つめます。

実際の動作は5秒ほどキープする必要があるそうですが、これがまさにフロー状態だと思います。周囲の音や考え事などの雑念があれば「会」とはならず、矢は的を外れてしまうでしょう。

Pierre-Yves Beaudouin / Wikimedia Commons

開発者は「フローに入る」や「ゾーンに入る」といった表現を使います。

これは、活動中に集中力と活力を持ち、完全に没頭するフロー状態を指します。この状態を頻繁に経験することは、生産性の向上、イノベーションの促進、従業員の成長に繋がります。研究によれば、仕事を楽しむ開発者はより高いパフォーマンスを発揮し、質の高い製品を生み出します。

フロー状態を妨げる主要な要因は、中断や遅延です。その他にも、自律性の欠如、目標の不明確さ、そして刺激的でないタスクが影響します。

フロー状態を作りやすくするためには

中断の最小化：会議をまとめて行い、計画外の作業を避け、支援依頼をまとめて処理する。
自律性の確保：開発者に自律性を与え、充実感のある挑戦的なタスクを提供する。
積極的なチーム文化の構築：リーダーはフロー状態を重視し、自律性とチャレンジの機会を提供する環境を作る。

これにより、開発者がフロー状態に入りやすくなり、生産性と製品の質を向上させることができます。

DevExの測定

「DevExの3次元」は、測定可能な領域を特定するためのフレームワークを提供します。開発者の認識やワークフローを捉えるだけでなく、全体的なKPI（主要業績指標）や「北極星指標」を含めることが重要です。表1では、包括的なKPI指標と3つの次元に沿った具体的な認識およびワークフロー測定の例を示しています。

表1

	フィードバックループ	認知負荷	フロー状態
認識 (人間の態度と意見)	- 自動テストの速度と出力に対する満足度	- コードベースの複雑さの認識	- 集中して中断を避ける能力の認識
	- ローカル変更を検証するのにかかる時間に対する満足度	- 本番システムのデバッグの容易さ	- タスクやプロジェクト目標の明確さに対する満足度
	- 本番に変更をデプロイするのにかかる時間に対する満足度	- ドキュメント理解の容易さ	- オンコールの際の中断性の認識
ワークフロー (システムとプロセスの行動)	- CI結果を生成するのにかかる時間	- 技術的質問に対する回答を得るのにかかる時間	- 会議や中断なしでブロックする時間の数
	- コードレビューのターンアラウンドタイム	- 変更をデプロイするために必要な手動ステップ	- 計画外のタスクやリクエストの頻度
	- デプロイリードタイム（変更を本番にリリースするまでの時間）	- ドキュメントの改善頻度	- チームの注意を必要とするインシデントの頻度
KPI (北極星指標)	- ソフトウェア提供の全体的な容易さの認識 - 従業員のエンゲージメントや満足度 - 認識された生産性

DevEx 改善のためにはどうやって組織に投資させるか

研究の結果、DevExの改善は個人、チーム、そして組織にとってプラスの結果を生み出すという証拠が明らかになりました。しかし、このデータを見ただけでは、組織が改善に向けて舵を切るとは限りません。

そこで、データドリブンかつ継続的な改善を始めるための5つのステップが提案されています。

現在の開発者体験のデータ収集
開発者の体験を把握するためにデータを収集する。これには、アンケートや専用ツールを使用して現在の課題や改善点を明らかにすることが含まれる。
データに基づいて目標設定
収集したデータを元に、改善すべきポイントを特定し、目標を設定する。ビジネスの優先事項とも照らし合わせる。
チームの成功をサポート
設定した目標を達成するために、チームに必要な支援を提供する。目標を共有し、進捗を定期的に確認する。
進捗を共有し、投資を評価
開発者や関係者に進捗を報告し、投資の効果を評価する。学んだことや驚いた点も共有し、改善策を調整する。
プロセスを繰り返す
再びデータを収集し、プロセスを見直して改善する。3～6ヶ月ごとにこのサイクルを繰り返す。

デベロッパーエクスペリエンス（DevEx）改善の重要性

日本では、デベロッパーエクスペリエンス（DevEx）の改善に関する研究はまだまだこれからだと言われています。しかし、これこそが今後のIT業界の競争力を大きく左右する重要な要素となるでしょう。

日本CTO協会が毎年実施している「開発者体験ブランド力」の調査は、すでに一部の企業にとって重要な指標となっていますが、今後はさらに実際のDevExに基づいたエビデンスデータを活用することが求められます。

例えば、アメリカやヨーロッパのIT企業では、DevExの改善が企業文化の一環として浸透しており、優秀な人材の確保や社員の満足度向上に直結しています。

論文 "DevEx: What Actually Drives Productivity" には実際のeBayとファイザーの実例が載っていますこれにより、企業のイノベーション能力や市場での競争力が劇的に向上しています。

日本のIT企業もこの潮流に乗り遅れることなく、DevExの重要性を認識し、積極的に改善に取り組む必要があります。

具体的な取り組みとしては、開発ツールやプロセスの改善、継続的なフィードバックループの確立、エンジニアの教育とスキルアップの支援などが挙げられます。これらの施策を通じて、開発者がストレスなく効率的に仕事を進められる環境を整えることができます。また、データに基づいた評価と改善を繰り返すことで、より具体的で効果的なDevExの向上が期待できます。

またチーム・トポロジーのイネーブリングチームとしてDevExチームを立ち上げてもよいかもしれません。

実際のDevExデータが調査されるようになれば、日本のエンジニアのDevExへの投資が見直されるかもしれません。

DevExの継続的改善サイクルが回り、結果として、企業全体の生産性や創造性も高まり、ひいては日本のIT業界全体の競争力が強化されるはずです。

経営者やマネジャーの皆様が率先してDevEx改善に取り組み、次世代のIT産業をリードする企業としての地位を確立するチャンスだと私は思います。

*1:Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations"（邦題「LeanとDevOpsの科学［Accelerate］テクノロジーの戦略的活用が組織変革を加速する」）