これが、ニコール・フォースグレンらによる論文 "The SPACE of Developer Productivity: There's more to it than you think." を読んだ時に私が感じたことです。
本稿は、上述論文に基づいてSPACEフレームワークを解説するとともに、その活用方法についても考察しています。
特に、5つのディメンションについては、論文から読み取りづらい点をフォローするようにしました。ここが理解できないと、フレームワークの魅力がなくなってしまいます。実際、開発チームのマネージャーらやメンバーらと話していると、SPACEフレームワークが定義する5つのディメンションと、具体的な指標とがどう対応付けられるのかが判別しづらいという声も聞こえます。このような悩みが解消されることも、本稿を書くことにした動機です。
SPACEフレームワーク
SPACEフレームワークは、開発生産性（developer productivity）を計測する指標の選択に、多次元的（multidimensional）な視点をもたらすフレームワークです。DORAによって開発され、書籍『LeanとDevOpsの科学』の著者でもあるニコール・フォースグレン（Nicole Forsgren）らによって、2021年に論文が公開されています。
開発生産性の計測はこれまで、エンジニア個人の活動を計測するたった1つの指標で表せるといった誤解や誤認も多く、不適切・不正確に評価されたり、あるいはその難しさゆえに諦められていた領域です。ニコール・フォースグレンらの論文では、この領域における誤解を5つの「神話（myth）」として指摘しています。
Myth: Productivity is all about developer activity
（日本語訳）神話: 生産性は開発者の活動だけに関するものである
Myth: Productivity is only about individual performance
（日本語訳）神話: 生産性は個人のパフォーマンスだけに関するものである
Myth: One productivity metric can tell us everything
（日本語訳）神話: 1つの生産性メトリクスが全てを教えてくれる
Myth: Productivity Measures ARE useful only for managers
（日本語訳）神話: 生産性指標はマネージャーにとってのみ有用である
Myth: Productivity is only about engineering systems and developer tools
（日本語訳）神話: 生産性はエンジニアリングシステムと開発者ツールだけに関するものである
前述の論文では、これらの神話を踏まえたうえで、開発生産性を計測するために3つ以上の観点を組み合わせるべきだと説いています。SPACEでは、その観点となるものを5つのディメンションに分類し、次のように命名しました。これらの頭文字を繋いで "SPACE" なのです。
- 満足度と幸福度 / Satisfaction and well-being
- パフォーマンス / Performance
- 活動 / Activity
- コミュニケーションとコラボレーション / Communication and collaboration
- 効率とフロー / Efficiency and flow
※日本語表記は、書籍『エンジニア組織を強くする 開発生産性の教科書』に準じています。
またSPACEでは、定量的な指標だけにこだわらず、主観的な経験や感情を評価する知覚的指標を含めることも推奨しています。定量化された指標より、状況を正しく反映した情報を与えてくれる領域もあるからです。特に、「満足度と幸福度」の計測は、アンケートなどを用いた知覚的指標に頼ることが多くなる領域でしょう。
さらに、選択しようとする指標が扱うスコープが「個人レベル」「チームレベル」「システムレベル」のいずれに該当するかを意識することも重要です。いずれかのレベルに偏ってしまうこともまた、正しい情報を得られなくなる要因となるからです。なお、「システムレベル」とは、「チームレベル」より広い範囲のフローを指しています。チーム間やプロセス間での仕事の受け渡しを含む範囲だと考えてください。
満足度と幸福度 / Satisfaction and well-being
「満足度と幸福度」の指標は、開発者らが自分たちの仕事に対してどれだけ充実し、幸福であり、健康的であるかという観点で計測されます。アンケートで計測される「従業員満足度」や、「燃え尽き症候群（バーンアウト）」、「開発に必要なツールを持っているか」といった項目がその対象です。「開発者体験（developer experience, DevEx）」と言い換えることもできるかもしれません。「満足度と幸福度」はおそらく、その多くが知覚的指標になると考えられます。
満足度と生産性の間には相関関係があり、前者は後者の先行指標になるとも言われています。ジェフ・サザーランド（Jeff Sutherland）も自著の中で、その体験について述べています。彼のスクラムチームでは、スプリントが終わるごとに「幸福度の計測」と呼ばれる方法で振り返り（レトロスペクティブ）を実施していました。それは、次の4つの質問に対し、メンバーが順に答えていくというシンプルなものです。そして、4で得られた回答の中から1つだけをチームで選択して改善を進め、次のスプリントでその結果を確認するようにしたのです。
- 会社内での自分の役割について、一から五のスケールで表すとどう感じているか。
- 同じスケールで、会社全体についてどう感じているか。
- なぜそう感じるのか。
- 何を一つ変えれば次のスプリントでもっと幸せだと感じられるのか。
この取り組みを続けたところ、計測された幸福度が、チームのベロシティの変化の先行指標になっていることに気づいたのです。幸福度の上下が、そこから何回か先のスプリントでのベロシティの上下に連動する傾向がみられました。ベロシティ単体の指標を指して「生産性」と呼ぶことはできませんが、少なくともジェフ・サザーランドの観察からは、幸福度とベロシティの間に相関性がみられたのです。
パフォーマンス / Performance
「パフォーマンス」に含まれる指標は、アウトプットではなく、アウトカムを評価する観点で計測されます。何らかの作業の完了ではなく、その先にある成果をみるものです。指標例として挙げられているのは、信頼性やバグの少なさ、サービスの健全性、顧客満足度、顧客獲得やリテンション、機能の利用状況、コスト削減などです。
対象がアウトカムであると聞くと、本番リリースした後に計測可能となる指標のみが対象になるように感じてしまいますが、そんなことはありません。システムレベルでのアウトカムはその通りですが、チームレベル、個人レベルでのアウトカムも対象です。
個人レベルならば、誰かの作業のアウトプットに対して、その価値や成果を計測することができます。たとえば、設計・実装したコードの品質の評価は、パフォーマンス指標です。チームレベルでも同様です。あるチームによるプロセスのアウトプットの価値や成果を計測すれば、それはパフォーマンス指標となります。
活動 / Activity
アクションやアウトプットの数を計測する指標が含まれるのが、この「活動」です。5つのディメンションの中でもっともイメージしやすいのではないでしょうか。例として挙げられている指標は、設計文書や仕様書、作業項目、プルリクエスト、コミット、コードレビューの量や数です。また、CI/CDに関するビルド、テスト、デプロイメント/リリースの数も「活動」に含まれる指標です。
「活動」と「パフォーマンス」の違いがわかりにくいという声を聞くことがあります。たとえば、バグの数はパフォーマンス指標ですが、数えているのだから活動指標ではないのかと悩むマネージャーがいました。しかし、バグはアウトプットではなく、アウトプットされたコードの質を評価するために数えられるものです。だから、活動指標ではなく、パフォーマンス指標に位置づけられるのです。このように、アウトプットそのものを数えているのか、アウトプットの質を評価するために数えられたものなのか、そのどちらであるかを考えることも判断軸になります。
もう1つ興味深い例としては、「ストーリーポイントの合計」があります。完了したストーリーポイントの合計であれば活動指標なのですが、リリースしたストーリーポイントの合計ならパフォーマンス指標なのです。これはとても分かりにくい切り分けです。しかし前者はやはり、単なる活動状況をあらわしているだけなのです。作業が完了していたとしても、それがリリースされるまでは、その数字はプロジェクトの中での作業の進捗を表しているだけです。一方で後者は、実際にユーザーや顧客に提供されたプロダクトや機能の価値の大きさを測る代替指標のひとつとして考えられます。この違いが、どちらのディメンションに含まれるのかという違いになっているのです。
コミュニケーションとコラボレーション / Communication and collaboration
「コミュニケーションとコラボレーション」は、個人間やチーム内、チーム間の協力関係や情報連携の質を評価するディメンションです。効率的で効果的なコミュニケーションとコラボレーションは、パフォーマンスを高めるポジティブな要因となり得ます。だからと言って、単に多ければ良いものではなく、逆に少なければ良いというものでもありません。そこに、質や量、頻度、タイミングが問われるのです。
このディメンションに含まれる指標は、定量的に計測しにくいものが多いようです。
たとえば、「作業に対するレビューの質」や、「組織内のソーシャルネットワーク」を示す指標は、どうやって計測すべきか、ぱっと思い浮かびません。コードレビューにおけるレビュアーとレビュイーのネットワーク程度であれば、バージョン管理ツールのログからデータを得ることはできます。しかし、そのデータを利用してどのような指標を設計すれば有用な情報を得られるのかは、頭を悩ませることになるでしょう。
他にも、「ドキュメントと専門知識の発見容易性」という指標もあります。確かに、大量の新しいドキュメントや古いドキュメントが混在する社内wikiから、目当ての情報を検索で見つけ出すことは難しかったりもします。しかし、これを指標化するためには、検索エンジンに対する評価が必要となり、その実施にはそれなりの労力を要します。
あまりコストをかけすぎるより、計測しやすい定量指標や、アンケートなどを活用した知覚的指標を採用する方が良い結果がでるかもしれません。
効率とフロー / Efficiency and flow
「効率とフロー」は、フローの滞留や手戻りを抑え、どれだけ効率的にフローを進められているかを示すディメンションです。
リードタイムや、そこに含まれる待ち時間と付加価値時間は、このディメンションの代表的な指標でしょう。リードタイムは、何らかの作業やプロセスのフローが開始してから終了するまでの時間です。待ち時間は、リードタイムの中で、実際の作業が行われず、フローが停滞していた時間の合計です。付加価値時間はその逆で、実際に作業が行われ、フローが進んでいた時間の合計です。待ち時間が大きいほど、このフローの効率が悪かったと言えます。
テストやデプロイまで含む開発プロセスのリードタイムには、フェーズによって特性があるため、指標化する際には注意が必要です。
まず、開発プロセスが開始し、「設計と実装」開始から「コードレビュー」終了までのリードタイムは、開発項目によって大きくばらつき、そして正規分布に従わず、左に歪みます。この範囲のリードタイムは、付加価値時間を縮めることを考えるより、待ち時間を縮めることに集中した方が、リードタイム短縮に効果的です。付加価値時間が、開発項目の難易度やサイズに大きく影響されるからです。ここでのボトルネックの多くは「設計と実装」完了から「コードレビュー」開始までの待ち時間です。ここを削減することに力を注いだ方が良いでしょう。もちろん、1つあたりの開発項目のサイズがあまりに大きいようなら、それを小さくする努力をすることで付加価値時間と、リードタイムを短くすることも必要です。生存期間の長いブランチは、統合時のコンフリクト解消コストも大きくなるからです。
残りの「ビルド」開始から「デプロイ」完了までのリードタイムは、CI/CDによる自動化が進むほど安定し、一定になります。従ってこのフェーズは、自動化率と効率性を高め、品質を安定させることに注力することが、リードタイム削減に対して効果的に働くはずです。
指標の選択方針
SPACEを使って開発生産性を計測するなら、まずテーマを決め、それを計測する代表的な指標を1つか2つほど選び、そこからさらにテーマに沿って他のディメンションの指標を付け足していくアプローチが良いでしょう。テーマも目的も決めず、数多くの指標をただやみくもに集めて計測しても、役に立つ情報が得られるものにはなりません。関心事に基づいて指標選びに関連性と一貫性を持たせ、絞り込むことがポイントとなるのです。
フローを増やすための指標選び例
たとえば、組織のバリューストリームを通るフローを増やすことを考えているのなら、それを観察する指標を選びます。もっとも関心を向ける指標は、「効率とフロー」に位置する「デプロイの頻度（deployment frequency）」でしょう。そこを中核にして指標選びをするなら、次のようなラインナップが考えられます。
| ディメンション | 指標 |
|---|---|
| 満足度と幸福度 | チームの幸福度 |
| パフォーマンス | 変更失敗率 |
| 活動 | プルリクエストのサイズ、勤務時間の長さ、チームの稼働率（リソース効率） |
| コミュニケーションとコラボレーション | プロセス間の手戻り率 |
| 効率とフロー | デプロイの頻度、コードレビューの待ち時間、継続的デリバリーの自動化率とリードタイム |
「満足度と幸福度」の指標としては、「チームの幸福度」が良いでしょう。いくらフローが増えても、無理を強いて実現した効率性であれば、これらの指標が悪化すると考えられるからです。特に、やりがいを持って仕事ができていないようなら、達成感が低くなります。こういった指標は、専用のツールを使って計測することをおすすめしますが、ジェフ・サザーランドがやったように、簡単な質問をチームメンバーらに投げかけるだけでも簡易に計測できます。
「変更失敗率」は、スピードを重視し過ぎて品質が犠牲になっていないかを観察するための指標として配置しています。
「プルリクエストのサイズ」は、それが大きすぎることがフローを遅くしている可能性を探るものです。大きすぎるプルリクエストは、コードレビューまでの待ち時間を長くしたり、コードレビュー自体に要する時間を長くします。また、ブランチの生存期間も長くなるため、統合ブランチへのマージ時に、コンフリクトを起こして大きな修正コストを支払うことにもなりかねません。
「勤務時間の長さ」と「チームの稼働率（リソース効率）」は、仕事量を時間でカバーしていないか、メンバーの健康面やプロジェクトの健全性を観ようとしています。後者のメトリクスは特に、チームやメンバーの勤務時間が、プロジェクトの仕事だけで埋め尽くされていないか、その余裕（遊び）を観るために使用します。私の経験では、この指標が75%から80%を超えたあたりから、メンバーらが披露や不満を頻繁に訴えるようになります。また、稼働率があまりに高すぎると、自分のタスクをこなすことだけで精一杯になり、たとえば、他のメンバーのコードレビューを放置する様子が散見されるようになります。プロジェクトやチームの問題に気づいても改善に取り組もうとしないといった状況にも陥るでしょう。チーム思考を失うのです。その結果として、フローが遅くなります。
「プロセス間での手戻り率」は、本来なら「効率とフロー」に位置づけられますが、「コミュニケーションとコラボレーション」指標としています。ここではコミュニケーションの質や量を計測するための代替指標として評価したいためです。
ソフトウェアの内部品質を改善するための指標選び例
例としてもう1つ、ソフトウェアの内部品質についても指標選びを検討してみましょう。ここでは、内部品質の指標として、「パフォーマンス」に位置する「コードカバレッジ」と「チームによる保守性の評価」という、定量指標と知覚的指標を組み合わせて計測することにします。
「コードカバレッジ」を選択する理由は、ソフトウェアの保守性を構成する3つの品質特性の1つであるテスト容易性の代替指標として、定量的に計測しやすい指標だからです。残りの2つの品質特性である理解容易性、変更容易性も、静的コード解析ツールで計測できますが、それをもってコード品質の良し悪しを判断することが難しいと感じます。いくつかの指標を組み合わせて複合的に観察することになるからです。ただし、参考情報として利用するのはとても有用でしょう。
「チームによる保守性の評価」を加えるのは、理解容易性と変更容易性を定量化しないことに対する補完です。イテレーションごとの振り返りで、チーム全員で保守性を5段階評価するといった運用を想定しています。これは、ヘンリック・クニバーグ（Henrik Kniberg）が技術的負債に関する自身のブログ記事で紹介していた手法です。日常的にコードに触れるチームメンバーらだからこそ、保守性に関する正確な状態を評することができるというわけです。
その他の指標は次の表のとおりです。
| ディメンション | 指標 |
|---|---|
| 満足度と幸福度 | チームやプロダクトに対する誇り |
| パフォーマンス | テストカバレッジ、チームによる保守性の評価、欠陥の数、変更失敗率、計画予実 |
| 活動 | プルリクエストのサイズ、コントリビューター数、マイナーコントリビューター数 |
| コミュニケーションとコラボレーション | 他チームからのプルリク受け入れ数 |
| 効率とフロー | 開発と保守・運用の投下工数比率 |
「チームやプロダクトに対する誇り」は、eNPS（従業員ネットプロモータースコア）などを使って計測できます。内部品質が悪いソフトウェアを抱えるチームのメンバーは、所属するチームのやり方に否定的であったり、プロダクトそのものについて自信を失っていたりします。チームやプロダクトに誇りが持てないのです。この指標を用いるのは、その点について計測する目的です。
「欠陥の数」を計測する背景は、低品質なコードに含まれる欠陥の数が、高品質なコードに比べて多いという調査結果があるからです。ここでは、リリース前に検出した欠陥も、リリース後に見つかった欠陥も両方をカウントします。また、同じ研究調査の中で、コードの品質が低いほど開発時間の予測可能性が低くなるという結果も出ています。つまり、見積りや計画どおりに開発が進まないということです。そのため「計画予実」を指標として含めています。
「プルリクエストのサイズ」はフローを遅くする原因でもありますが、コード品質との関係もあると考えられます。まず、あまりに大きなプルリクエストは、コードレビューを進めるうえで細部に目が行き届かなくなります。品質上の問題を見逃す可能性が高まるのです。次に、マージ時のコンフリクトが多くなる点です。コンフリクトの修正は、場当たり的になりがちです。コンフリクト先の設計方針との整合性をとるためには、それなりに時間を要してしまうからです。急いでいる時は特に、その時間を惜しんでしまうでしょう。また、プルリクエストのサイズが大きくなる理由は、そもそも内部設計がまとまっていないことにあるかもしれません。クラスやメソッドの切り出しが繁雑になり、互いの結合度が高すぎるために、プルリクエストを小分けにできなかったのです。
「活動」に含まれる「コントリビューター」という言葉は、コンポーネントに変更を加えてcommitした人を指しています。多くの人が変更を加えているコンポーネントは、設計の一貫性を失っている可能性があります。また、他チームメンバーによるコントリビュートが多いようなら、コンポーネントの境界が正しくない可能性もあるでしょう。
もうひとつの「マイナーコントリビューター」というのは、コンポーネントに記録されたcommitの数が特に少ないコントリビューターを指しています。つまり、コントリビューターの中でも、そのコンポーネントを扱った経験が乏しい人を指しています。マイナーコントリビューターが加えた変更は、その設計が適切でない可能性が高いということです。
「コミュニケーションとコラボレーション」に含まれる「他チームからのプルリク受け入れ数」を計測する目的は、「活動」指標の「コントリビューター数」や「マイナーコントリビューター数」と同じです。どちらか一方のディメンションの指標に絞って計測しても良いでしょう。
「開発と保守・運用の投下工数比率」は、内部品質を改善するまとまった時間を確保する時に、チームが関係者と交渉する材料にできる指標です。内部品質が低いソフトウェアを担当するチームは、保守・運用の負荷が高く、開発時間が少なくなる傾向があります。つまり、新しい価値をユーザーや顧客に届ける開発時間をチームが十分に確保できなくなるのです。また、保守・運用工数の増加は、損益計算書（PL）を悪化させる要因にもなり得ます。内部品質を起因とするプロダクト開発上の問題の可視化は、この指標が欠かせません。
アウトカムが最優先
組織やチームがもっとも優先すべきは、ユーザーや顧客の価値に資するアウトカムです。開発生産性をモニタリングし、継続的に改善していくことは重要ですが、この点を見失うわけにはいきません。
ケント・ベック（Kent Beck）は、自身のブログ記事の中で、エフォート（effort）、アウトプット（output）、アウトカム（outcome）、インパクト（impact）を次のように定義したうえで、もっとも注力すべきはアウトカムだとしています。
- Effort. How hard are we working?
- Output. How much are we delivering to customers?
- Outcome. How much value are customers realizing?
- Impact. How much value flows back to us?
（日本語訳）
- エフォート. 我々は、どれだけ一生懸命働いているのか？
- アウトプット. 我々は、顧客にどれだけのものを提供しているか？
- アウトカム. 顧客は、どれだけの価値を実現しているのか？
- インパクト. どれだけの価値が私たちに戻ってくるか？
まずは、ユーザー価値や顧客価値を実現し（アウトカム）、その対価としてビジネス価値を得ます（インパクト）。これは、価値の交換です。サービス提供者である私たちが、先に価値を提供します。そうすることで、ユーザーや顧客から直接的、あるいは間接的に、ビジネス価値がもたらされるようになるのです。
インパクトやアウトカムを得るためには、先にアウトプットが必要です。ユーザーや顧客がそのアウトプットを選び、利用することで初めて、彼らに価値がもたらされるからです。それは、新しいソフトウェアプロダクトであるかもしれないし、新しい機能かもしれません。
そして、そのアウトカムを作り上げる活動が、エフォートです。
開発生産性を高める活動は、アウトプットを増やしたり、そのリードタイムを短くすることにばかり注意が向けられ、アウトカムが蔑ろになりやすいという問題を抱えています。また、「エンジニアの人数」といった、生産性指標の分母たる「インプット」も、見落とされやすい対象でしょう。ケント・ベックの提言は、何に注力して生産性を高めるとしても、アウトカムを最優先に置いて判断すべきだと訴えているのです。
しかし、忘れてはならないのは、プロダクトに対するアイデアの多くは想定通りの価値にはならないという現実です。正しく価値を提供する鍵は、アイデアをあくまでも仮説だと自覚することです。そしてその仮説をすばやく検証し、そこから学びを得て、また新たなアイデアを試す。このサイクルを回し続けることです。アウトプットを多く、そして速くする試みは、これを実現するための手段として必要なのです。
SPACEのディメンションを活用することで、アウトカムとアウトプットの両方の観点を持つことができます。これこそ、本フレームワークの大きな魅力の1つでしょう。チームや組織が取り組むべき課題がアウトプットやエフォートにあったとしても、それらの指標とともに、アウトカムの指標をモニタリングできるからです。
SPACEのシステムレベルでの「パフォーマンス」は、アウトカムやインパクトに位置づけられる指標を扱うディメンションです。一方で、「活動」ディメンションで扱うのはエフォートやアウトプットであす。また、「コミュニケーションとコラボレーション」や「効率とフロー」は、アウトプットに至るフローを観察するものです。
つまり、組織やチームが取り組む対象が「活動」や「効率とフロー」などであったとしても、適切な指標を「パフォーマンス」にも配置しておくことで、アウトカムを最優先にして生産性向上に取り組むことが可能になるのです。
多次元的（multidimensional）な観点で生産性を計測する利点は、ここにあったのです。そのポイントは次のとおりです。
- 指標選びは、網羅しようとするのではなく、チームや組織の関心事に基づいて関連性と一貫性を持たせ、絞り込むようにする
- アウトカムをシステムレベルのパフォーマンス指標として設定し、それを意思決定のためのガイドとする
これさえ押さえておけば、SPACEフレームワークを最大限に活用して成果を出すことが可能になるでしょう。
