こんにちは、VPoEの川田です。
今回はVPoEらしく、エンジニア組織っぽいことを書きます。
エンジニアチームのパフォーマンスを定量的に計測する方法についてです。
なぜ計測しようと思ったのか
課題が大きく2つありました。
1. エンジニア個々人の事業目標が立てづらい
HRBrainでは、エンジニアの立てる目標の中に事業目標というものがあります。
事業に対してどういう貢献をするために、何をやるのかを毎月頭に各メンバーに決めてもらっています。
全社である程度の方針は決めているので、その中から自分がやりたいものを拾うというのが基本的な流れですが、決めた内容がどれだけ事業に貢献するかが分かりづらいという問題がありました。
例えば、今月はSSOを実装するぞという目標を設定したとします。
そうした場合に、SSOがどれだけのお客様に利用してもらえるのか？新しく営業に行った場合にどれくらいのお客様に刺さるのか？MRRにどれだけ貢献するのか？などは出してみないと分からないといった部分が大きく、「SSOを実装した」ということに対する事業へのインパクトを計測するためにはしばらく時間を置かないと分からないという状況でした。
また、時間をかけて計測した結果あまりお客様に響かず、MRRに全く貢献しなかったとしたら、それは実装したエンジニアの責任なのかという問題もあります。
例え汎用的な設計や関連する既存部分のリファクタリングなどを頑張っても、大前提のSSOが受け入れられるかどうかによって評価が大きく変わってしまうというのはあまり良い状態ではありません。
このような課題は多くの企業が抱えているのではないでしょうか。
2. ある機能をいついつまでにリリースしよう、という動機が弱い
とにかくクソコードでもいいからスピード重視で書き捨てるように実装しまくる、というのは弊社では行っていません。
お客様に長く使っていただくサービスを作っているので、スピード感は意識しつつ、メンテがしやすく、新しく入ってきたメンバーが困惑しないような作りを意識しています。
しかしそのバランスをどこに置くかが、メンバーによってまちまちになっていました。
そのため、ある機能を実装する場合にクオリティにこだわりが強い人であれば、いつまでも同じ機能を実装することが可能でした。
設計を意識するのはもちろん大事ですが、使われるかどうか分からなくて他の機能と関連が少ないような機能にも可読性を意識し、汎用性を持たせ、長期的な運用を視野に入れた設計に時間を思いっきりかけるのが正解ではないケースもあります。
リリースした上で使われそうならリファクタする、使われなさそうならrevertする、という選択肢を取れる状態にすべきかもしれません。
どういう指標を定めたのか
上記2点の問題を抱えていたところ、あるレポートに出会いました。
DevOps Research and Assessment (DORA)という組織が、世界の様々な企業を6年間調査した結果をまとめたレポートです。
成果が出ている組織は具体的に何が優れているのか、ということが書かれています。
LeanとDevOpsの科学では更に詳細な調査方法などが書かれています。
このレポートで示されている4つの指標を参考にし、弊社に合うように少しカスタマイズして用いることにしました。
示されている4つの指標は以下です。
1. デプロイの頻度
そのまま、どのくらいの頻度でデプロイをしているかということです。
2. 変更のリードタイム
レポート内では、コードのコミットから本番環境で正常に実行されるまでの時間とあります。 恐らくremote repositoryに対してのコミットからの計測ということかなと思いますが、弊社の開発フローに当てはめると計測が煩雑になってしまうので、一旦はリリースタグを切ったタイミングから本番環境で正常に実行されるまでの時間、という定義にしました。
3. 平均修復時間
サービスインシデントが発生したときに、復元するのにかかった時間です。 弊社では、リリース後即座に修正が必要な緊急度の高いbug、アクセスできないような障害が発生した場合に、そこから復旧するまでの時間を計測することにしました。
4. 変更失敗率
本番環境にデプロイしたあとで、修復を必要とするものの割合です。 細かい定義はレポートでは書かれていなかったので、弊社では1チケットにつき発生したbugの割合を計測することにしました。 A, B, Cというチケットをまとめてリリースした際、Bに対して問題が(何個でも)発生した場合は33%、といった具合です。 リリース後しばらくして発見されるbugもあるので、時間経過と共に増加する可能性があります。
なぜこれらの指標で課題が解決できるのか
1の課題で書いたとおり、どんな機能がヒットするかということを事前に把握することは現実的ではありません。 どの機能がヒットするかという部分をなんとか頑張って考えるのではなく、bugが少ない質の高いアウトプットを早いサイクルで回す状態を作ることで、結果的に最短で最大のパフォーマンスを出せるというアプローチです。
これらの指標を追うということは、使われるかどうか分からない機能に時間を多くかけて様々な仕様を盛り込むことはせず、最小単位でリリースして少しずつ試すということも意味しています。
2の課題については、デプロイの頻度を指標に置くことで、以前のデプロイ数よりもより多くしたいというモチベーションが高まるので、結果としてより早く実装されることになるはずです。 もちろん闇雲に急ぐだけだと変更失敗率が高くなってしまうので、そのバランスは取っていく必要があります。
目標と計測結果
レポートでは、以上の4つの指標を世界の様々な企業で調査した結果が以下のように示されていました。
我々のチームではエリートパフォーマーレベルを目指すことにして、実際に8月から計測をはじめました。
という結果になりました。
8月の計測結果を受けて
1. デプロイの頻度
デプロイの頻度については、目標を人数*回/週と定めました。 固定のリリース回数を定めても良いのですが、その場合人数が増えるたびに簡単になっていくので、毎週、人数回数分をリリースすることを目標に置きました。
現状は原則毎週火曜と木曜にまとめてリリースしている状態なので、
- 実装、debugが完了した時点でいつでも誰でもデプロイできるようにする
- リリースフローの手作業を無くす
- debugフローを整える
といったことに取り組む必要があります。
2. 変更のリードタイム
変更のリードタイムは、わかりやすく改善の余地ありです。 現状だとリリースタグを切ってstgにデプロイして最終動作確認をしているのですが、そのタイミングで見つかるbugが多かったり、仕様の漏れが見つかって修正が入ったりということが起こってこのような時間になっています。 この課題に対しては、例えば
- デグレが発生しないようにテストを書く
- bugが入らないように複雑な部分のリファクタリングをする
- branch環境をdevにデプロイできるようにして、debugのタイミングを前倒す
といったようなことで改善できそうです。
3. 平均修復時間
4. 変更失敗率
平均修復時間は0、変更失敗率については?%と表記しました。 ?%と書いたのは、8月にリリースしたチケットを対象にしているので、もしかしたら今後見つかった不具合等で増える可能性があるという意味でこうしました。 現状は8月にリリースしたチケットに紐付くbugは見つかっていないので、特に気にしないことにします（とはいえ、できるだけbugが見つかった段階ですぐに紐付きが分かるようにする仕組みは考えたほうが良さそうですが）。
上記のようなものがチームの課題として明確になったので、あとはこの課題に対して何を取り組んでどれくらいパフォーマンスを上げるかを各個人の目標に設定することで、チームのパフォーマンスを上げていくことができそうです。
まだ計測をする環境がやっと整ってこれから追っていく段階です。 今後個人の目標設定と合わせて、チームのパフォーマンスを上げていければと思います。
