開発生産性 Conference で宇宙の謎に迫る
コロナ禍以降、かなり久々にカンファレンスへ向かった。オフラインで。感覚的には一億年ぶりくらい。勢い余ってテックブログを開設してしまう程度にはモチベーションが高まってきている。
ファインディ株式会社の主催する、開発生産性にフォーカスしたイベントだ。
目的は Dr. Nicole による Keynote で、SPACE の話を聴けるとのこと、これは行くしかないと仕事をサボって意気揚々と現地へ向かった。とくに、DORA (DevOps Research and Assessment) の Four Keysとの違いについて筆者自信イマイチ整理しきれていないこともあり、From Metrics to Mastery: Improving Performance with DORA and the SPACE Framework というタイトルが刺さった。
DORA の Co-Founder である彼女がこれまで提唱してきた Four Keys、そして 2021 年に発表した SPACE、この記事ではそれらの関係性について迫りたい。
先ずは Four Keys、SPACE についてそれぞれ概要をまとめていく。
Four Keys
ソフトウェアデリバリーの効率性、効果、品質を測定するメトリクスだ。名の通り、4 つの指標を定量的に計測し、チームのパフォーマンスを評価する。ChatGPT に依頼すると下記のように表してくれる。
- Lead Time
- コードがコミットされてから本番環境にデプロイされるまでの時間。開発プロセスが効率的であることを示す。
- Deployment Frequency
- 新しいコードが本番環境にリリースされる頻度。高いデプロイ頻度は、チームが迅速に価値を提供できることを示す。
- Change Failure Rate
- 新たなリリースが失敗して、修正やロールバックが必要となる割合。より低い変更失敗率は、より高品質なソフトウェアを安定して展開し、維持する能力を示す。
- Time to Recover
- 変更によりシステムに障害が発生した場合、その障害を修正して正常なサービスを回復するまでにかかる時間を示す指標。より短い復旧時間は、組織が問題に対して迅速に対応できる能力を示す。
大きく分類すると前者 2 つが、ソフトウェアデリバリーの速さを、後者 2 つが安定性を表す。これらはトレードオフの関係ではなく、両立させるようパフォーマンスを高めていくと良いとされている。
シンプルなメトリクスセットではあるが、筆者の経験から言うと、アーキテクチャ、コードベース、プロセス、コラボレーション等々、開発や運用といった業務にかかる総合的な品質や能力と相関があるように考えられる。なにかひとつの側面でも問題を抱えている場合、いずれかのメトリクスに跳ねてくるだろう。Four Keys を継続的に計測し、フィードバックループを回すことで、チームやグループの自己強化につなげることが期待される。
SPACE
ソフトウェア開発の生産性を理解し、予測するために、開発者や生産活動を複数のディメンションから観察する「フレームワーク」として説明されている。このフレームワークを用いることで、より良いメトリクスを作成し、開発者の成果と幸福のためにポジティブな影響をもたらすことが目的とされている。
詳しい内容は Dr. Nicole の論文を読むと良いだろう。長い文章ではないので、日本語翻訳にかけたり、ChatGPT などに要約させたりすることで、概ね理解できるはずだ。
SPACE の Why・What は論文内容に任せるとして、ここでは以降の段落のために How に着目したい。SPACE では各ディメンション、レベルのマトリクスをベースにメトリクスを定義する。
- ディメンション
- Satisfaction and well-being
- 開発者が自分の仕事、チーム、ツール、文化に対してどの程度充実感を得ているか。
- Performance
- システムやプロセスの結果。例えば、開発者のアウトプットが価値の提供対象に対して期待する結果をどれだけ得たか。価値提供の品質や影響など。
- Activity
- 開発者の作業により完了したアクションの数。
- Communication and collaboration
- 人々とチームがどのようにコラボレーションし、協力するか。広範かつ効果的なコミュニケーション、調整、共同的な創造的タスクを実施しているか。
- Efficiency and flow
- 開発者が中断や遅延を最小限に抑えて作業を完了できるか。どの程度効率的に開発者の活動が調整されているか。
- Satisfaction and well-being
- レベル
- Individual
- 開発者個人
- Team or group
- 共同作業するチームやグループ
- System
- 作業に用いられるシステム
- Individual
開発生産性を表すメトリクスを定義するにあたり、少なくとも 3 つ以上のディメンションを満たすことが推奨されている。例えば Activity のみを測定するのでなく、その他 2 つのディメンションを選択し、生産性への理解に役立てる。
また、少なくとも 1 つのディメンションで定性データを計測することも推奨されている。機械的な定量データだけでなく、感覚的な定性データを求めることで、より立体的な全体像を把握するのに役立てる。
といったように、SPACE は広範なソフトウェア開発の活動から生産性を理解するために、より良いメトリクスを定義するための抽象的なフレームワークのようだ。具体性を持って「このメトリクスを測定すると良い」と提唱している訳ではなく、チームやグループ、個人が生産性について考え、より良い生産活動を行うためのメトリクス定義をサポートするものと考えられる。
Four Keys and SPACE
ここからは Dr. Nicole の Keynote の内容も踏まえて、これらの関係性について考えていきたい。筆者自身の解釈も含まれるので、この点は注意してほしい。
Dr. Nicole は SPACE を Four Keys の進化版では無いとしていた。Four Keys は SPACE と補完関係にあるという。
これは Four Keys が SPACE の観点では 3 つのディメンションを満たしているからだそうだ。おそらく、Performance・Activity・Efficiency and flow になるだろう。
思うに、Four Keys は SPACE の包含関係にあるということで、当事者が判断するのであれば、開発生産性のメトリクスとして Four Keys を選択できるということだ。Four Keys は、直接的にはソフトウェアデリバリーの能力を評価するもので、測定対象の集団が一つの単位として開発・運用に携わるケースで特に有効だろう。例えば、SaaS プロダクトを扱うチームなどが挙げられる。（余談だが、Satisfaction の観点から、併せて eNPS なども測ると良い）
一方、Four Keys を選択しないこともできる。メトリクスとして Four Keys がマッチしないこともあるだろう。企業やチームによっては、例えばプロダクトよりもプロジェクトを扱っているなど、継続的なソフトウェアデリバリーを軸とした生産性の測定が適していない場合もあるはずだ。この辺りの事情は千差万別なため、そのようなケースでは自身が定義したメトリクスを用いると良いだろう。検討にあたっては SPACE がきっと役に立ってくれる。
Conclusion
Dr. Nicole の提唱する Four Keys と SPACE の関係性について、筆者自身の解釈をまとめた。
開発生産性 Conference は他にも多くの登壇があり、どのセッションも良いインスピレーションを与えてくれるものだった。このようなイベントを開催してくれたファインディ株式会社には感謝したい。
すごいなと思いました。楽しかったです（小並感）
