これは TECHSCORE Advent Calendar 2019 の5日目の記事です。
最近スター・ウォーズを見始めた小野寺です。公開順で見ています。
私は2018年からエンジニアリングマネージャーをしています。マネージャーの役割の一つに組織目標の設定があります。1年目は「新規プロダクトの開発」と「開発体制の冗長化」という目標設定をしていました。2年目は初めての目標設定ではないので、1年目よりはうまくできるだろうと思ったのですが、とても苦しんだ話をしようと思います。
2年目のお題「定量指標」
開発も定量指標がほしいよねー。という上司からのオーダーがありました。
この定量指標という言葉の定義に苦しみます。
チームの構成
私がマネージャーを務めるチームは、2つのサービスの開発・保守を担っているエンジニアチームです。各サービスはそれぞれにビジネスチームがあり、エンジニアチームと合わせて一つのサービスを8名程度で運用しているスモールチームです。いずれのサービスも、フィジビリや新機能開発がビジネスを成功させるために大きな役割を担うフェーズです。
指標の検討
△ 工数稼働率
定量指標として真っ先に思い浮かんだのは工数稼働率でした。ですが、仮に目標が「工数稼働率80%」だとして、これが達成されたからと言って、サービスが成長するか？というと今のフェーズとしてはしっくりきません。工数管理はしているものの、あくまで健康指標の一つに過ぎないと思いました。
△ リリース数
次に思い浮かんだのはリリース数です。しかし、リリースといっても様々な要因があるため、単純に回数を目標にするのも合わないと考えました。新機能のリリースと小さなバグフィックスのリリースでは同じ1回のリリースでも中身が大きく変わってくるでしょう。
？ システム開発以外の貢献
私のチームでは、他の部署への改善提案やデータ活用のフィジビリ、効果検証など、自分たちでシステム開発はせずとも、サービスを成長させるための役割もあります。そのため、システム開発以外の取り組みも評価されるようにしたいと考えました。
実際の指標
検討の結果、施策貢献数を指標にすることにしました。
施策貢献数は、リリースだけでなくサービスに貢献した回数をすべて数え上げたものです。システム開発以外も含めるというニュアンスを込めたかったので、施策貢献という言葉にしました。リリースも施策貢献ですし、効果検証も施策貢献です。数だけでは、中身が伴わなくなる可能性もあるので、施策に 期待値 と 起因 という項目を付けることにしました。
期待値 は、その施策がサービスに与える影響度を表現するもので、SからCまでの4段階で評価します。
- S：素晴らしく期待できる / 重要な影響
- A：とても期待できる / 影響大
- B：そこそこ期待できる / 影響中
- C：少し期待できる / 影響小orなし
重要なのは期待値であって、結果ではないというところです。結果はあとからついてくるものなので、これで必ずうまくいくという保証はありません。ありません、が、一定の根拠と成功させる意思を持ってやってみることが大切だと思います。
一方で、新しい企画だけではなく、サービスを維持するための保守や運用業務も怠るわけにはいきません。課題の管理にBacklogを使っているのですが、ビジネスチームが要望登録するのと合わせて、エンジニアチームも必要な課題を登録します。
そこで、その課題が何きっかけのものなのかを区別するのが 起因 です。GitHubのIssueで定義されているラベルを参考にしました。
- enhancement - ポジ起因の開発
- bug - ネガ起因の開発
- operation - 運用作業
- maintenance - 保守
- invest - 調査のみ
これらをかけ合わせると、
- S x enhancement は、素晴らしく期待できる新機能
- A x bug は、致命的ではないもののできるかぎり早く修正が必要
- B x operation は、定常業務
- S x maintenance は、やらないとサービス存続できないような保守（深刻な脆弱性など）
になるので、課題の優先度が見えてきます。
- S x bug, maintenance
- S x enhancement, A x bug, maintenance
- A x enhancement
のような感じです。
B,C x enhancement は小さな改善なのでやったほうがいいものではあるのですが、
S,A x enhancement が無い状態が続くのは今のサービスのフェーズとしては黄色信号です。
その場合は、B,C を止めてでも、S,A を生み出す方向に思考を持っていくようにします。
私達のチームでは色々考えた結果、目標を S x enhancement 数にしました。
サービスやチームのフェーズによってどの掛け合わせを指標にするかは変わると思います。
運用の工夫
Backlogに期待値や起因、その他のカスタム項目を作ったのですが、課題登録時にどれが必須かわかりにくくなりました。その解決策として、Chrome拡張機能を使うことでCSSでロールごとの入力項目がわかりやすくなるようにしました。
Backlog : https://backlog.com/ja/
Stylus : https://add0n.com/stylus.html
|
1 2 3 4 5 6 7 8 9 10 11 12 |
/* 次で始まるURL: https://crms.backlog.jp/add/YOURS * 正規表現に一致するURL:https://crms\.backlog\.jp/view/YOURS-.+/edit */ .-priority button, .-assigner button[role="combobox"], .-category button[role="combobox"], .-milestones button[role="combobox"], input[name="attribute_51217_3_1555651319000"], input[name="attribute_50535_4_1555651319000"]+label::before { border: 2px #f97e7e solid !important; } |
実際にやってみて
ビジネスチーム、エンジニアチームに施策貢献数のイメージを伝えて、合意を得るところが大変でした。
最初のバックログ整理をしたときにでた課題で、開発の難易度が高い あるいは 工数が多い 施策が必ずしも期待値の高さ ではないというところに中々納得してもらえませんでした。エンジニアであれば難しいものや時間がかかるものは評価されたいと思うところだと思いますが、それとサービスとしての期待値が必ずしも一致するとは限りません。何度かの話し合いを通して納得感のある指標にすることができました。
このビジネスチームとエンジニアチームのすり合わせを期初に時間をかけてできたのは年間を通して良かったと思います。ビジネスチームは開発への要望が達成されたときのサービスの影響度を説明しますし、エンジニアチームはこの開発がどれだけサービスに影響を与えるかを意識します。もともとメンバーもビジネスへの意識が高いこともあるのも大きな後押しとなりました。
課題
期待値の定義はすごく曖昧なので、AやBのバックログの比率が多かったです。この線引に時間を掛けるのは本意ではないので、A,B,Cのように区分を減らしてもいいかなと思いました。また、AはSになぜならないのか、AやBの施策は実は大きなSっていう施策に向かってのものなのではないか、など、指標の数やタスク管理からもう一歩踏み込んだ実用に繋げられるための動きをすればよかったなと思いました。
評価の探求はつきませんね。
