開発生産性フレームワーク Four Keys vs SPACE
はじめに📘
「開発生産性の未来：世界と日本の最前線事例から学ぶFour Keys向上〜ハイブリッドカンファレンス〜」というイベントにオンラインで参加しました💪
このカンファレンスでは、Four Keys を用いた生産性向上とその課題及び、SPACEフレームワーク という Four Keys に変わる指標を知ることができました。
備忘録の為にカンファレンスの内容を、Four Keys と SPACEフレームワーク の2つに焦点を当てながら内容をまとめていきたいと思います。
記事対象者
- Four Keys を用いた生産性向上の課題に興味がある方
- SPACEフレームワークの基礎を知りたい方
Four Keys と SPACE の概要紹介
Four Keys とは
Four Keysに関しては、既に多くの解説記事が存在していますので詳細な説明は他の記事を参照ください。
特にGoogleが公開している関連記事は、Four Keysについて分かりやすくまとめられていると思います。
SPACE とは
SPACEフレームワークは、Microsoftの研究チームによって開発された、開発者の生産性に対するアプローチ
個人、チーム、組織レベルで生産性に影響を与える5つの要素をまとめている。
SPACEに関する論文
生成AIを通した論文の要約
論文タイトル: The SPACE of Developer Productivity: There's more to it than you think.
著者: Nicole Forsgren (GitHub), Margaret-Anne Storey (University of Victoria), Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler (Microsoft Research)
概要:
この論文では、ソフトウェア開発者の生産性に関する複雑さと繊細さを掘り下げ、高品質なソフトウェアの効率的な開発を目指す組織、マネージャー、開発者にとっての重要性を強調しています。
主なポイント:
開発者の生産性の定義と測定の難しさ: これまでの研究や実践経験にもかかわらず、生産性の測定方法や定義は依然として曖昧であり、多くの誤解や迷信があります。
生産性測定の複数の側面: 個人の認識や満足度が重要な生産性の指標であり、開発者の幸福感と満足度は生産性と密接に関連しています。
Covid-19パンデミックによる影響: 多くの開発者が在宅勤務に移行し、生産性に関する新しい課題が浮き彫りになりました。
SPACEフレームワークの導入: 生産性を単一の次元や指標で測ることの限界を超え、多次元的な枠組みを提案します。SPACEは次の5つの次元で構成されます: 満足度と幸福感 (Satisfaction and well-being)、パフォーマンス (Performance)、活動 (Activity)、コミュニケーションと協力 (Communication and collaboration)、効率とフロー (Efficiency and flow)。
誤解に基づく神話の解体: 開発者の生産性に関する一般的な誤解を取り上げ、これらの誤解がどのように生産性を誤って理解させるかを説明します。
実践におけるフレームワークの使用: このフレームワークを使用して生産性を包括的に理解し、チームがより効果的な意思決定を行うための道筋を示します。
SPACE と Four Keys の比較(カンファレンスの内容まとめ)
SPACE と Four Keys の違い
SPACE フレームワーク
5つのカテゴリーによって成り立ち。
それぞれのカテゴリーは個人・チーム・システムのコンテキストで計測。
少なくとも３つの指標を取得することを推奨しているとのことです。
カテゴリー✖️コンテキスト
| カテゴリー | コンテキスト | 指標 |
|---|---|---|
| Satisfaction and well-being | 個人 | 開発者の満足度、コードレビューへの満足度、必要なツールやリソースの有無、ストレス度 |
| チーム | チームへの満足度、チームの推奨度 | |
| システム | 開発フローへの満足度（例：CI/CDパイプライン） | |
| Performance | 個人 | コードレビュー速度、バグ消化数、コードクオリティ |
| チーム | コードレビュー速度、ストーリポイントの消化率 | |
| システム | 顧客満足度、サービス稼働時間、コスト削減、レビュー受け入れ率 | |
| Activity | 個人 | ドキュメント作成数、PR数、コミット数、コードレビュー完了数 |
| チーム | 消化したストーリポイント | |
| システム | デプロイ頻度、変更障害率、平均修復時間、オンコール対応数 | |
| Communication and collaboration | 個人 | PRマージ時間、MTGの質、仕様ドキュメント発見時間、ドキュメントの質 |
| チーム | MTGの質、ドキュメントの質、新メンバーのオンボーディング時間、体験 | |
| システム | 仕様ドキュメント発見時間、ドキュメントの質 | |
| Efficiency and flow | 個人 | 中断のない集中時間（コード開発できている時間） |
| チーム | 自チームのMTG数、時間、他チームとのMTG数、時間、コードレビューにかかる時間 | |
| システム | ベロシティ、CI/CDフローでのトイル解消 |
メトリクスの集計方法(「株式会社ワンキャリア」の例)
| カテゴリー | メトリクスの集計方法 |
|---|---|
| S (Satisfaction and well-being) | 開発メンバー向けアンケート（Google Formを使用） |
| P (Performance) | マージ済みPR（Pull Request）の数（Findy Team+を使用） |
| A (Activity) | レビューしたPRの数（Findy Team+を使用） |
| C (Communication and collaboration) | なし（適した指標が見つからなかったため） |
| E (Efficiency and flow) | PR作成からレビューまでの平均時間（Findy Team+を使用） |
Four Keys の問題点と限界
- Four Keysにおける指標が目標化され、本来のビジネスや事業の改善とは乖離することがある。
- Four Keysでの改善が必ずしも全体のプロダクトや開発サイクルの改善につながらないことも。
- 開発チーム内部のみにフォーカスするとプロダクト全体の改善が見逃されるリスクがある。
- Four Keysはハック可能な指標であり、個人の評価に直接用いることにはリスクが伴う。
- Four Keysの数値は、実際の改善よりも見かけ上の改善を示す場合も。
- 定量的なデータに偏重し、定性的なフィードバックが不足しがち。
- チームの生産性や健全性を測る指標としての役割を果たすが、実態に即していない可能性も。
- 技術者とビジネス側の共通言語としてのポテンシャルは持ち合わせている。
SPACEフレームワークの有用性
- SPACE は、生産性測定を超えて、その生産性がビジネス目標にどう貢献しているかを明らかにする。
- 定量的と定性的な指標を組み合わせることで、ビジネス目標の達成とチームの幸福度を両立させる。
- SPACE は、Four Keys では捉えられない開発生産性の課題を明らかにする。
- Four Keys では見過ごされがちな、開発生産性に関する問題点を浮き彫りにする。
- 定性的なフィードバックを通じて、認識されていなかった課題に気づくきっかけを提供する。特に「S（幸福と満足）」を計測することにより、定性的な課題を発見できたという意見もある。
- Four Keys と違い測定すべき指標はFIXしていない。企業や開発体制によって最適な指標は変わるため、定期的に指標が妥当かを見直す必要がある。
まとめ
- Four Keys と SPACEフレームワークの組み合わせにより、ソフトウェア開発チームの生産性向上が可能。
- Four Keys はチームのダイナミクスと健全性に焦点を当てる。
- SPACEフレームワークは、個々の開発者の幸福度や生産性を多次元的に評価する。
- 両フレームワークを組み合わせることで、開発チームの内部改善とプロダクト全体のビジネス目標達成の両方を促進。
- Four Keys の定量的評価と SPACE の定性的フィードバックを併用することで、従来見過ごされがちな問題点を明らかにできる可能性がある。
Discussion