タイトル

はじめに

こんにちは！社内の「エンジニアブログの更新を絶やさない会」の方から圧を激を貰っている Keeth こと桑原です！現在はEngineering Manager の見習いをしております．

私が所属しているサービスの開発運用に携わるチーム(Eng + PM + PD で構成。以下「サービスチーム」)では，OKR（目標と成果指標）を設定して取り組んでいます．本記事では， KR に盛り込んだ「変動係数」というあまり聞き慣れない指標を導入してみた感想や，その運用方法について振り返りたいと思います．他のエンジニアチームの運用の参考になれば幸いです．

※だいぶ文字文字しい記事になっています

どのような KR をたてたのか？

前クォーターでは，サービスチームにおけるエンジニアリングの KR を定め，定期的に振り返りながら達成を目指していました．KRの内容は以下の通りです．

6月末のコード変更差分の変動係数が全て 0.5 以内に収まっている状態（Eng が偏りなくプロダクトを開発している ※0.7 が70%の目標でした

我々のチームは新規プロダクトの立ち上げフェーズにあることで，まだソフトウェアエンジニア(以下、エンジニア)の人数が少なく，前クォーターでは本格リリースに向けての大きな節目でもありました．その状況でどのような KR を設定しようかと話し合った結果，「定量的に追えることは前提として、全員がどのような技術的な質問にも回答でき、全員が議論に参加できるような体制を整えたいねー」という意見がメンバーから上がりました．

というのも，今開発しているプロダクトでは，フロントエンドのリポジトリが２つ（*1），バックエンドのリポジトリが１つ，インフラ管理のリポジトリが１つ．またSWE（以下，エンジニア）は３名（*2），という体制です．今までは短期的なスループットを上げるために，各メンバーが得意な領域にコミットしていた背景があり，KR を決める時点でメンバー毎のコミットに偏りが生じていました．バックエンドについては比較的各メンバーがコミットしており，偏りはあるもののまだ比較的小さかったのですが，フロントエンドについては ある１名のメンバーが約82%のコードを変更 しておりました．これの弊害として

コードレビューの質が落ちる
- そもそも他者が書いたコードは解像度に差がある
- さらにフロントについてはその差が著しく，比例してレビューの質は下がる
レビューの質が落ちれば，長い目で見て開発速度もデリバリーもスピードが下がる
視点も依存度が高くなってしまう

ということが挙げられます．

今後我々は正式リリースに向けて早くデリバリーをできるようにしていきたい．そのためには全員が幅広い領域にコントリビュートできるような体制が不可欠です（*3）．この改善の副次効果として，もし誰かが休むことになってもチームでカバーができるようになる．そのような背景があり，全員が納得のうえ，上記のような KR が決まりました．

変動係数とは？

おそらく日常的には出会うことのない概念だと思いますので，簡単に触れておきます（*4）．

変動係数（へんどうけいすう、英: coefficient of variation）とは、標準偏差を算術平均で割ったもの。相対的なばらつきを表す。単位のない数となり、百分率であらわされることもある。相対標準偏差 (RSD, relative standard deviation) とも呼ばれる。平均値が異なる二つの集団のばらつきを比較する場合などに用いられる。(Wikipedia より引用)

参考：変動係数計算サイト https://miniwebtool.com/ja/coefficient-of-variation-calculator/

要はどれくらい対象のデータがバラついているか，偏っているかを数値化したものです．今回立てた KR と照らし合わせてみた時，

エンジニア全員が同じように実装を進めていくと，コードの変更行数のばらつきは抑えられ、数字は小さくなる
逆に，あるリポジトリを特定のエンジニアばかりが実装していたり，実装はするけど「リファクタリング専門」のような人がいると，数字は大きくなる
さらに，エンジニアの業務は実装だけではなく，議論の参加やチームの動きの改善などもある．そのため，特定の人が実装以外のタスクをやっているような場合も同様に，数字が大きくなってしまう

となります．つまり，この変動係数の数字が小さくなることを目指すことで、エンジニア間の技術領域の偏りを減らす力が働きます．定量的な指標に困っていたので，この概念の提案をくださったチームメンバーの a2さんに助けられました！ありがとうございます！

運用方法

そもそも，この数字を追えば本当にメンバーの技術力の平滑化や全体感の把握ができるのか？という疑問があると思いますが，それはやってみないと分からないし，他に良さそうな定量評価できるものも考えつかなかったので，カミナシのバリューの一つでもある「β版マインド」の精神でやってみることにしました．

①最初の運用

最初っからスクリプトを書いたり，ワンライナーを書いたりはせず，愚直に Contributors のページ（https://github.com/OWNER/REPO/graphs/contributors）にアクセスし，各メンバーの変更行数を計算．それを Notion のデータベースに追記してました（なんて手間をかけていたんだ…）．

欲しい変動係数の値そのものは Notion のデータベースの Formula を使って自動計算しています（*5）．これを定期的に見ながら振り返りつつ追っていました．

②面倒くさかったのでワンライナーで

はい．やはりだんだん面倒になってきてしまいました．エンジニアならスクリプトなり，ワンライナーなりで自動化，少なくとも半自動化はしたいものですよね．ということで，お決まりの ChatGPT 4o くんに書いていただきました！ ※各変数やリポジトリの OWNER と REPO は適宜皆さんのもので置き換えてください．

・デフォルトの期間の変更行数を取得

curl -s -H "Authorization: token $GITHUB_TOKEN" "https://api.github.com/repos/OWNER/REPO/stats/contributors" | jq -r '.[] | "\(.author.login) \(.weeks | map(.a + .d) | add)"'

・期間を指定して

curl -s -H "Authorization: token $GITHUB_TOKEN" "https://api.github.com/repos/OWNER/REPO/stats/contributors" | jq -r --arg from "2024-07-01" --arg to "2024-07-05" '.[] | {author: .author.login, total_changes: (.weeks | map(select(.w >= ($from | strptime("%Y-%m-%d") | mktime) and .w <= ($to | strptime("%Y-%m-%d") | mktime)) | .a + .d) | add)} | select(.total_changes != null) | "\(.author) \(.total_changes)"'

・実行結果例とあるリポジトリの 2024-06-01〜2024-06-30 までの変更行数

memberA 2724
memberB 3932
memberC 4 // ←エンジニア以外のメンバーからのコントリビューション！👏
memberD 2615
kkeeth 64  // ←私

各ワンライナーの詳細な解説は割愛しますが，要は GitHub の API を叩き，みんな大好き jq コマンドを用いてデータをフィルタリング，計算して表示，という感じです．これでかなり計算が楽になりましたね！やっぱり最初っからやればよかったなと（笑）

やってみた結果と変化

まずはどれくらい数字が変わったのか見てみましょう．開始時の数字はこんな感じです．

・開始時

admin, api のリポジトリが約 1.0〜1.1 なのに対しfront のリポジトリが 1.5 と顕著に偏っていることが分かります．また，私はマネジメント業務が中心にあることでコミットする量も少ないため，私を除外した場合の数字も載せていますが，それでもやはり front リポジトリがだいぶ偏っていますね．では，4Q 全体ではどうなったのか見てみましょう．

・4Q終わり時点

結果としては，

admin: 1.132 → 0.89 (≒ -0.242)
front: 1.536 → 1.191 (≒ -0.345)
api: 1.058 → 0.704 (≒ -0.354)

と改善しました．

この数字から，各メンバーの技術力の平滑化ができたのか，という点ですが，正直なところ達成したかの評価は難しいとは今も感じています（そもそものエンジニアの技術力の定量評価が難しい）．特に課題だったフロントエンドの開発について，各メンバーが自信を持って開発できるようになるにはもう少し時間がかかりそうで，これはチームの継続課題です．

しかし，目に見えて変わったものとして，Slack 上でのフロントエンド開発に関する課題や，実装の相談スレの量が目に見えて増えました．また，front, admin リポジトリに関する開発をする際，フロントエンドの領域に興味関心が強く，かつ同リポジトリに多くコミットしたエンジニアメンバーとのペアプロを多用していたのですが， チーム全体のベロシティはほとんど変わらず，連続してスプリントゴールを達成 できました！（*6）この事実もとても大きく，時間の問題で解決する確信も得られました．

おわりに

チームの技術力やドメイン知識のバランスをある程度定量的に測るための指標として，「変動係数」という選択肢をご紹介してみましたが，いかがでしたでしょうか？

「この数値が下がれば大丈夫！」というものではありませんが，強いチームを作るための指標として，選択肢の１つにはなるなと個人的には感じております．また，もちろん数字のハックは可能ですが，思ったよりは防げると思います．というのも，そもそもの計算ロジックが 標準偏差 / 平均 ですので，一人がよっぽど飛び抜けて数字を稼がないと変動係数へのインパクトはなく，かつそのような Pull Request はチームメンバーからリジェクトされると思います（笑）また，我々は性善説によった運用の仕方をしましたが，逆に性悪説に基づいた使い方も考えられます．

これまた釈迦に説法かもしれませんが，人の行いに銀の弾丸などありません．チームを良くするのも強くするのも，そのチームのメンバー次第です．本記事がチームビルディングの一助になれば幸いです．