3.0 第3部序論:開発者体験とSPACEフレームワーク

第2部は外側から提供を測定しました。コードがどれだけ速く、どれだけ安全にパイプラインを通じて動くかです。このパートは、そのコードを生み出す人々の体験を測定します。それが存在するのは、提供指標群だけでは、その背後にいる人間が燃え尽き、中断に溺れ、あるいは静かに関与を失っている間でさえ、優れて見えることがあるからです。DORA指標だけを見ている組織は、1年か2年の間、チームをより強く絞り上げることでそれを改善できますが、離職、品質の崩壊、あるいは燃え尽きがその利益を一気に消し去るまでのことです。このパートはその対抗力です。

その中心は、マイクロソフト、GitHub、ビクトリア大学の研究者たちによって、行の数やコミット件数のような単一で簡単に操作される代理を通じて開発者の生産性を測定するという業界の習慣への矯正策として特に開発された、SPACEフレームワークです。SPACEは五つの次元にまたがります。満足度と幸福感、パフォーマンス、活動、コミュニケーションと協働、そして効率性とフローです。このフレームワークの中心的な規律、そしてこのパートが第2部が自らのフロー指標に適用するのと同じ厳密さでそれを扱う理由は、どの単一の次元もそれ自体では信頼できないということです。その価値は特に、五つすべてを一緒に視野に入れ続けることから来ます。そうすれば、あるチームが別の軸を静かに損なうことで一つの軸で良く見せることができなくなります。

大規模なチームにとって、開発者体験の指標は、DORAには答えられない問いに答えます。この提供の業績は持続可能か、そして組織はそれを生み出す人々を保持しているか。このパートを無視する企業組織は、たいてい、損害がすでに生じた後に、離職データと退職面談を通じてそのコストを発見する傾向があります。純粋に報酬だけで競争する能力を制限する公共部門の給与の制約のもとで運営されることが多い政府組織には、開発者体験を後付けではなく第一級の能動的に管理される関心事として扱う、特に強い理由があります。

本パートの各トピック

3.1 SPACEフレームワーク: 五つの次元を一緒に、なぜ単一のものだけでは信頼できないのか、そしてそれらから本物にバランスの取れた指標群をどう構築するか。
3.2 満足度と幸福感の指標: 充実感、苛立ち、燃え尽きのリスクを測定すること。これは、どんなシステムのテレメトリも直接観察できない次元です。
3.3 パフォーマンスの指標と成果の代理: 活動と最も混同されやすい次元、そして代わりに本物の成果への貢献をどう測定するか。
3.4 活動の指標とその限界: コミット件数、コード行数、そしてなぜこれが過剰に重みづけするのに最も危険な次元なのか。
3.5 コミュニケーションと協働の指標: 情報が人とチームの間を実際どう流れるか、そして健全なパターンがどのようなものか。
3.6 効率性とフロー:深い仕事と中断: 本物のエンジニアリングの仕事が必要とする中断されない時間を守ること、そしてそれを蝕む摩擦を測定すること。
3.7 開発者体験の調査とDevEx指標: 人気投票ではなく信頼できる信号を生み出す調査をどう実施するか、そしてそれを客観的なデータとどう組み合わせるか。

各トピックのつながり

トピック3.1はSPACEの五つの次元すべてを一緒に紹介し、トピック3.2からトピック3.6は、SPACEの研究者がそれらを提示する順序で、それぞれの次元を順番に本物の深さで扱います。トピック3.7は、調査設計の実践的な仕組みでこのパートを締めくくります。なぜなら、満足度、パフォーマンス、協働はすべて部分的に自己申告のデータに依存しており(トピック1.5の計測基盤対自己申告の区別は、このパート全体を通じて直接関連します)、悪く設計された調査は前のトピックすべてを損なうからです。

このパートの中心的な規律、つまり一つの次元での強さではなく次元を横断したバランスは、人に適用された、提供パイプラインにではなく、トピック1.3の資産より成果を優先する原則の、本書における最も明確な実例です。活動(トピック3.4)は、純粋なアウトプット指標に最も類似したSPACEの次元であり、このパートはそれに応じてそれを扱います。五つのうちの一つの入力としては有用ですが、単独の信号としては危険です。第2部と並んで読むと、このパートは、ソフトウェアが速く安全に出荷されるかどうかだけでなく、それを出荷する人々がそのペースを持続できるかどうかという、DORAだけでは提供できない全体像を完成させます。