こんにちは、CTO室でアジャイルコーチをしている府川です。 今回は、スクラムマスターのパフォーマンスをどう定量的に分析するかを検討した内容になります。
はじめに
皆さんの会社では、スクラムマスターのパフォーマンスをどう分析していますか？ スクラムチームとしてのパフォーマンスであれば、スプリントゴール達成率、レトロスペクティブでの改善アクション数などの指標が使えることもあると思いますが、スクラムマスター個人の成果となると、どう可視化するのが良いのか迷っていました。
難しいと思う理由としては
- 成果の多くは、スクラムチームみんなで作られるため、スクラムマスター個人の成果を定量的に評価するのが難しい
- たくさんのフィードバックや改善施策の成果が積み重なることで、はじめて効果が見えてくるものが多く、その一つ一つの価値を定量的に測定することが難しい
- コミュニケーション能力のような定性的なスキルを定量的に評価することは難しい
などが考えられました。
もともとエンジニアをやっていたのもあって、これらを考えた時に「エンジニアの時も同じことを思ったな。エンジニアチームのパフォーマンスを測るための手法を使えないか？」と思い、調べた結果、FourKeysに行き着きました。
FourKeysとは
Four Keysは、以下の4つの指標を使った組織のパフォーマンス分析のための手法です。詳細はこちら。
- デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム - commit から本番環境稼働までの所要時間
- 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
- サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
本来はチームのパフォーマンスを分析するための手法ですが、スクラムマスター個人のパフォーマンス分析に転用したいと思います。
スクラムマスターのパフォーマンス指標として置き換えてみると
組織による正常な本番環境へのリリースの頻度
これは「問題に対して施策のうち、実際に問題を解消することのできた数」と解釈しました。 施策を打つほどチームにも少なからず負担を与えることになるので、単に施策の数を追うのではなく、成果を得られた施策数に注力するのが良いかと思いました。 もう少し細かく見るのであれば「施策を打った数」と「成果を得られた施策数」とで分けて見るのも良いかもしれません。
commit から本番環境稼働までの所要時間
これは「施策の提示から、チームが実行するまでの所要時間」と解釈しました。 ざっくりとした改善施策を提示しても、誰が・いつ・何をするかを具体的にしていないと、チームが実行するまで時間がかかってしまいます。それを解消するために、スクラムマスターが具体的なアクションプランを提示してあげたり、チームメンバーが主体的に考え動くような状態に導いてあげる必要があると思います。
デプロイが原因で本番環境で障害が発生する割合（%）
これは「施策を打ったことで、悪影響が出てしまった割合」としました。 ここの割合が高い場合は、事前の考慮不足が大きいと思います。考慮不足を減らすために、1on1などを通じてチームの状況をもっとしっかり把握したり、キーとなる人に事前に施策案の壁打ちをしたりすることで、割合を下げることができそうです。
組織が本番環境での障害から回復するのにかかる時間
これは「緊急度の高い問題が発生してから解消されるまでにかかる時間」としました。 ここの時間が短い人ほど、メンバーからの信頼度が高い傾向にあったり、施策を打つときのチームやスクラムマスター自身の心理的ハードルは下がると思います。 そのような状態になれば、改善サイクルが早まり、より良いチームを作っていけそうです。
終わりに
これがすべてではないと思いますが、部分的にも定量化していくことで、パフォーマンスの可視化ができ、目標設定やモチベーションコントロールにつながるのではないでしょうか。 今回はFourKeysをベースに考えましたが、世の中にはたくさんの手法があるので、それを「自分の抱えている問題解決に転用できないか」と考えてみると、ヒントを見つけられることあると思うので、是非やってみてください。
