はじめに
昨今よく話題になる開発生産性ですが、弊社新宿開発チームでもSPACEフレームワークを採用し、測定指標をもとにチームの生産性・パフォーマンスを日々改善しています。
今回は、その測定指標を決めて運用する際の工夫について、紹介できればと思います。
下記以降の章で挙げる具体例は実体験をべースにしたフィクションです。
対象者
- SPACEフレームワークでどのように測定指標を選定すればいいかよく分からない方
- これからSPACEフレームワークを導入する方
開発生産性とは？
本記事では、開発生産性そのものについてはあまり言及しません。
代わりにですが、2点参考資料を紹介します。
まず、私にマネジメントのイロハを教えてくださった方のスクラップを紹介します。
情報集約されており、開発生産性の概要や動向について学べます。
次に、DPE(Developer Productivity Engineering)についても紹介します。
Gradle Inc.が提唱するDeveloper Productivity Engineering（DPE）は、管理指標やベストプラクティスではなく、自動化技術やツールに焦点を当てた、ソフトウェア開発チームの生産性を向上させるアプローチです。具体的には、この新しいソフトウェア開発規律は、ソフトウェアのビルドとテストプロセスをスピードアップするためにアクセラレーション技術を使用し、トラブルシューティングとソフトウェア品質保証をより効率的にするためにデータ分析を使用します。その目的は、より速いフィードバックサイクル、より信頼性の高い実用的なデータ、満足度の高い開発者体験を実現することです。また、DPEは反復的なアジャイルアプローチと連動するため、フィードバックサイクルも高速化します。
SPACEフレームワークとは?
下記をベースにざっくり要点を説明します。
概要
開発者の⽣産性を単純なメトリックや次元で評価することは困難であり、その多様性と複雑性に対処するためにSPACEフレームワークが登場しました。
このフレームワークは、個⼈、チーム、システムの観点から⽣産性を理解し、バランスの取れた指標を提供することを目的としています。
多次元的なアプローチ
⽣産性は個⼈の活動だけでなく、エンジニアリングシステムの効率性も含みます。
(3観点で測定されます)
- Individual
- Team or Group
- System
SPACEフレームワークは、この多様性を反映するために下記5つの次元を提案しています。
- Satisfaction and well-being
- Performance
- Activity
- Communication and collaboration
- Efficiency and flow
各次元には具体的な指標があり、例えば、Activityではコミット数やコーディング時間、Efficiency and flowではコードレビューの効率などが考慮されます。これにより、開発者の全体像を網羅的に評価できます。
これらの次元を組み合わせることで、⽣産性の理解が可能となります。
(The SPACE of Developer Productivity より図を引用)
このフレームワークの注意点
チームや組織は、フレームワークを使って複数の次元にわたるメトリクスを収集し、⽣産性の全体像を理解する必要があります。知覚的な尺度も組み合わせ、全体的な認識を構築することが推奨されます。
一方で、フレームワークを実施する際には、次元を過度に含めないようにし、慎重に指標を選択する必要があります。
- 広範囲な指標と過多の改善⽬標のリストで構成されると達成不可能になる
- 遵守する意義をチームメンバーが持てなくなる可能性がある
また、バイアスや規範を確認する必要があります。これらは外部の影響で、測定値を変化させたり影響を与えたりする可能性があります。
例えば、
- あるチームではある指標が高い水準にあるが、別のチームではその指標が低い
- 性別によってコードレビューで否定的なコメントを受けやすく、肯定的なコメントを受けにくい
ベースラインの異なる観点に影響を受けすぎないほうが良いということです。
これらのポイントに留意することで、SPACEフレームワークの実装がより効果的で、組織やチームの生産性向上に寄与することが期待できます。
最初に測定指標を埋める時の工夫
さて本題ですが、このSPACEフレームワークを採用後、各次元の指標を設定する必要があります。実はこの埋める作業が意外と難しいです。特にSPACEのSやCの項目については、定量的に捉えることの難しい満足度やコミュニケーション度をチームの実態に合わせて指標化する必要があります。
例えば、PやA,Eであれば
- Performance : スクラムで計測しているベロシティ
- Activity : Four Keysの変更のリードタイム
- Efficiency and flow : Four Keysの変更障害率
のように開発生産性での取り組みをこちらに転写することである程度指標化が可能ですが、SやCにはそういった有効的なフレームワークは少ないと感じています。
SやCを埋める手法として、よく槍玉に上がるのはアンケートだと思いますが、下記のように埋めていたりしませんか？
確かに、「開発者満足度アンケート」や「開発者体験向上アンケート」として指標化すること自体は正しいと思っています。しかし、こういった埋め方をすると下記のようなデメリットが発生しやすいです。
- アンケート内容の精査が進みづらい(形骸化しやすい)
- どのように指標として評価されるのかが不明瞭
そういった状況にならないように、下記のように埋める方が指標として利用しやすいです。
アンケートの設問をSPACEにマッピングした結果です。内容自体は要約して記載すれば良いと思います。
(Systemは、色でマッピングするようにアレンジし直していますが、これは任意です。お好きなように)
「これ、指標は設問毎ですか？」といった質問が来そうですが、その通りです。
これをアンケート単位で指標化する場合、アンケート単位の指標を出すことになりますが、その指標がどうなると嬉しいのかが、結局設問を確認しないと議論しづらいです。
それに対し、設問毎に指標化する場合、それがどうなると嬉しいかが明確化され議論しやすくなります。
ちなみに、アンケートの設問についてですが、下記のようなことを設問としてしまって良いです。
- チームメンバーとの1on1で上がってきたこと
- マネージャーが確認したいこと
- 上層部から求められていること
大事なこと
最初は不要になった設問は後から削除してもいいため、ざっくりとした感じで問題ないです。また、わざわざ計測できることをアンケートの設問化しなくても良いと思います。SPACE開始初期でも、多角的に測定できるような指標を用意できていることです。
継続的に測定指標を改善する時の工夫
最初の測定指標をアンケートの設問を含めて、上手く埋めることができました。
では、SPACEでの生産性測定を始めてみましょう。
設定したアンケートの設問指標についてですが、実際にアンケートを取りましょう。取る感覚は月に1度程度が負担なく、変化を観測しやすいためおすすめです。
実際に、弊社新宿開発チームでは、月に1度Microsoft Formsを利用したアンケートを行っています。
上記のようなFormを用意し、実際に12項目ほど運用しています。
このようなアンケートを収集した後、下記のようなフローで測定指標の利用と改善を行います。
- アンケート結果を集計する
- アンケート結果を踏まえた1on1を実施する
- 全員との1on1後、アンケートのフィードバックレポートを作成し、振り返り等で共有する
- 共有内容を元にアクションプランや指標の改善プランを起こす
1に関しては、Microsoft Formsであれば勝手に集計と個人ごとのアンケート結果が取れます。2~4についてはどういったことをやっているか詳細説明します。
アンケート結果を踏まえた1on1
1on1では、アンケートの全体結果と個人結果を照らし合わせて下記のことを確認していきます。
- 設問の解答意図について
- チームメンバーとの得点の違い
- どうすればその数値を改善できるか？
例えば、下記の「設定されたミッションやKPIなどに価値貢献できているか？」といった設問があるとします。
この指標は高ければ高いほど価値貢献のできる満足度の高いチームといった感じになるのですが、分散がある場合は注意しなければならないです。
例として、今1on1でインタビューするのは星5を付けた基盤ライブラリのリファクタリングをしているエンジニアとします。
まず、設問の解答意図について聞いてみると、「自身の進めている基盤のリファクタリング業務は順調で、それがミッションやKPIの中心にあるプロダクトを支えているから」と答えました。
一見問題ないように見えますが、一方で2~3を付けているエンジニアも多く、何かチームと感じていることがズレているように見て取れます。
こういう時は、他のメンバーと異なる理由を一緒に考えてみると良いです。
- リファクタリング後にドメイン側のシステムに不具合が多かったため
- 計画外のリプレイス作業までしていて、不具合対応を手伝わなかったため
このように一緒に分析をしてみました。実は基盤のリファクタリングより外の業務が、その人にとって考慮外だったことがわかりました。
後々に他のメンバーに確認すると、「基盤側の仕様が変わり、運用時期にいくつかの機能が動かなくなったため、KPIの一部が達成できなさそう」といった話が上がっていました。
この指標の平均評価は3ですが、本質には2.5辺りかもしれないといった事がわかります。
アンケートのフィードバックレポート作成
SPACEのアンケート指標を利用し、1on1で個人間のすり合わせをしました。
今度はメンバー全体にこのアンケートで得たことをフィードバックレポートとして共有します。
先程の項目を報告内容をまとめてみると
設定されたミッションやKPIなどに価値貢献できているか？
少し、ネガティブ寄りのフィードバックをいくつか貰っています。
- 運用直前の基盤リファクタリングパッチ適用に伴う不具合が貢献度を低下させてしまった。
- 基盤ライブラリのリプレイス等、ミッションからズレているタスクの優先度を上げて着手していた。
これらを踏まえ、分析すると下記のような問題点があると思っています。- 優先順位付けが上手く出来ていない(マネジメントも含めて)。
- リリースのスケジュールやスパンを見直す必要がありそうです。
他にも問題点がありそうなため、時間をとって洗い出せたらと思います。
内容については、一例です。心理的安全性のレベル感を見ながら、どの程度配慮するかはマネジメント側の腕の見せ所だと思います。
大事なこと
これらは評価に直接利用せずに、アクションプランや指標改善に利用することを目的にしましょう。(評価を上げるためによく見せるみたいなことは、生産性を測定する障害だと思っています)
アクションプランや指標の改善
では、アクションプランや指標改善にどう繋げていけば良いでしょうか？
実際に、弊社新宿開発チームでは下記のことを行っています。
- スプリントレトロスペクティブや改善MTGでの問題提起
- SPACEの見直し
今回の例「設定されたミッションやKPIなどに価値貢献できているか？」では、レトロスペクティブに混ぜるのではなく、時間をとって議論することにします。ここで上がってきた内容はSPACEの測定指標や業務フローの改善に繋げます。
議論により、下記のような問題点とアクションプランが上がってきました。
- リリースまでのスパンが長い
→ CIだけでなくCD(継続的なデリバリー)のフローを明確化し、自動化する - 基盤側のバックログがメンテナンスされていない
→ PO=開発者だったため、マネージャーがPOを受け持つ - 不具合が起きた時の対応フローが確立されていない
→ 直近はhotfixでの運用で乗り切る。中期的に、検証環境の整備やログの収集・分析を行う。 - 基盤の一部がレガシーになりつつある。
→ 別途リプレイスの計画を立てる
これらを踏まえてSPACEの指標を変えていく必要があります。
例えばAの項目に「POの週あたりのバックログメンテナンス回数」やFour Keysで丸めていた指標からデプロイ頻度や変更のリードタイムをマッピングしなおす必要がありそうです。(なんとなくFour Keysの各指標を測っていたことが明らかになった)
また、今回の「設定されたミッションやKPIなどに価値貢献できているか？」はSatisfaction and well-beingの項目として抽象的すぎるといったことが分かってきたため、アンケート内容をプロダクトとミッションに狭めて実施することにしました。
大事なこと
開発生産性を多角的に測ることでこういったチームの改善に繋げていく。既存のDPEでは測定しにくいチームメンバーの思いや考えもアクションプランや指標に組み込んでいく。(チームで起こることを自然に自分ごと化してもらう)
おわりに
SPACEを取り入れてからつくづく思うのは、数値を補足しているだけでは開発生産性は上がらないということです。当たり前だろと言われてしまいそうですが、SPACEで指標をマッピングしてみると、ただ追っているだけの指標やとりあえず取っているだけの指標が浮き彫りになります。
これらの指標を有機的に運用していくのはなかなか難しいなと思いました。今回の工夫はアンケートという指標から、開発活動の改善と繋げ、それを満足度等に還元するといったことをイメージしています。
マネージャーとしては、まだまだ浅い身ですが色々と考えて実践している最中なので、本稿も温かく見てもらえるとありがたいです。