はじめに
この記事はうるる Advent Calendar 2022の6日目の記事です。
こんにちは！うるるの技術戦略課の古賀と申します！
Four Key Metrics（FKM）の導入を現在取り組み中です。
（全ての情報を出せるわけではないので、
濁している部分はお察し頂ければと思います。）
AdventCalendar書け〜！という司令があったので、
ちょうど今期の取り組みをアウトプットすることで、
AdventCalendarを消化しつつ、
現状や、これからの取り組みまとめを一緒にやっちゃおう！
というワケです。
FKMってなに？
FKMについて概要を簡単に説明させて頂きます。
といってもFKMついての記事は、
他にも無数にあると思うので、あっさりといきます。
開発チームの生産性に関するメトリクスを
「4」つの指標と「4」段階で評価したものです。
(Qiita初めてで何がアウトかわからなかったから意味もなく自前で図を作りました。)
デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
を可視化し、計測し、評価し、改善する。
そのサイクルを回してみんなでEliteな開発チームを目指そうぜ！
詳しくはここを参照ください。
指標の理由
高パフォーマンスなチームはデプロイ頻度と、
デリバリ速度が他社より優れる傾向にある。（LeanとDevOpsの科学 p27より）
市場での競争力が激化する昨今、
SNSの発達など、昔よりユーザーの声を集めやすくなった背景などがあります。
リードタイムが長い大規模プロジェクトよりも、
短期開発開発
↓
市場への投入
↓
ユーザーからの声をフィードバック
↓
プロダクトにアップデート
↪またユーザーの声をフィードバックのサイクル
のようなアジャイル開発チームの方が、
高業績なパフォーマンスを発揮しやすい傾向にあります。
そのため、このチームのパフォーマンス解析に適した、
下記2点を計測するためにこの定義にしております。
・スループットの高さ
デプロイの頻度
変更のリードタイム
・品質の安定性
変更障害率
サービス復元時間
なので、この4つがユーザーへのデリバリ速度を測ることができ、
変動要素が比較的少ないため、指標として適している、というわけです。
デブサミ2022夏でもFKMの名前を出さずとも、
ソフトウェアデリバリーに関する主要な指標としてこの4つが挙げられています。
https://codezine.jp/article/detail/16344
FKMを取り組む上での注意点
（これはLeanとDevOpsの科学で取り上げられていることではなく、
様々な人から意見を頂いて議論した中での私個人の意見です。）
実際に導入するにあたり、「こういうことが問題になるよね」
と、MTG時によく話が出た内容を記載したいと思います。
FKMについての記事は多くありますが、
導入するにあたり、組織的な障害についてはあまり記載がなかったので、
そのあたりを詳しくお話できればと思います。
・可視化できるのはパフォーマンスであること。
開発チームの開発パフォーマンスの可視化ができる。
直接的な業績アップの取り組みではない。
（受託開発とかだったら直接的な業績アップかも）
物を生み出せるかどうか、と、売れるかどうか、は別問題、ということです。
ただし、デリバリパフォーマンスを向上させることで、
社内の営業部門や非営利部門にも良い影響を与えることはできます。
・無闇にチーム同士を比べない。
特に開発部署以外の人たちに数字を見せる時は要注意、
特に開発方式や規模が違うチーム同士では、
チームのパフォーマンス以外の要素で変動が起こるため、得策ではありません。
「向こうの開発部署はEliteなのになんでウチはLowなんだ！なんとかしろ！」
とか、現場にいない偉い人に怒られたら、
現場のエンジニアのモチベーションダウンは確実。
競争し合うのが文化の企業であれば、いいかもしれませんが...
出し方は非常に気をつけた方がいいです。
・数字だけで見ない
大事なのは変化した時に何があったときに、
定性的な情報を参照しながら、
原因が何かを突き止めて改善していくこと。
例えば↓こんなパターン
ケース①数値が下がった！
→属人化解消のため、一時的に業務を分担し合っている途中なので下がってもOK。
一時的な低下はあれど、これからアベレージが上がっていくはず。
ケース②数値が上がった！
→チームリーダーが100時間くらい残業したからで、チーム自体が成長しているわけではく、この状態は長続きしないと予想されるので対策が必要。
推移のウォッチと原因の究明、必要に応じた改善とそれを行う文化・習慣が大事。
なので、ケース①でも②でも、
マクロに見る視点とミクロにデータを解析する視点、両方が必要になります。
取り組むメリットとゴールについて。
効果としては、
・可視化した指標を改善することで、ユーザーに素早くプロダクトを届けられる。（前述）
・可視化した指標を踏まえた継続的な改善サイクルに取り組める。（※重要）
（他にもいっぱい！ここでは省略）
チームのパフォーマンスが悪い気がする！
でもどこから改善すればいいんだろう...
といった時、Four Keyを可視化しチームの現状を把握していきましょう。
その時に、データを見ながら改善するための仮説を立てて実行、
成功し、指標が改善されたら次なる改善に、
失敗し、指標が維持or低下したら、何故失敗したのか仮説を持って次なる改善に、
そのサイクルを何度もグルグル繰り返すこと。
そのサイクルを自然に回す文化を作ること。
これが今回のFKM施策の目指すべき姿だと私は考えています。
「LeanとDevOpsの科学」によると、
デリバリ重要なのはテストとデプロイの容易性、
なので、まず改善するのであれば、
自動化していないプロセスがあれば自動化する、などで
飛躍的に数値が改善されることが期待されます。
その他にも手法としてリーンマネジメントとか継続的デリバリとか、色々あるので、
身も蓋もないことを言うと、詳しくは「LeanとDevOpsの科学」を参照！
実際に上がった問題点
・アジャイル開発じゃないと採用出来ないのでは？
→ウォーターフォールでもFour key意味あるよ！
リリース自体は最後のローンチのタイミングだけど、
継続的に開発用のブランチにコミットしているから、
その数字を計測すればメトリクスは取れるので、
ウォーターフォールでも採用できる。
・Google指標のレベルが高すぎてor開発方式の形式上、採用できない。
それぞれの開発チームに合わせた指標にする。
or
計測する時の定義を開発方式に合わせた内容にする。
取れない評価レベルを掲げてもしょうがない、が、
いかようにも出来る評価レベルにして、
「常にElite、みんなハッピ〜」だと意味がないので、
そのあたりの妥当性はバランスを取っていく必要があるかなと考えています。
どうやって可視化したの？
可視化に使っているツールが各事業部によって違うので、
それぞれで実現をしようと試みています。
（詳細についてはそれだけで記事１本分になってしまうので割愛させていただきます。）
1. Findy Team+編
FindyTeam+には、最初からFour key Metricsに非常に適したメニューが存在するので、
それをほぼそのまま流用することにしました。
ただし、本番運用が始まっていないプロダクトもあるので、
そのプロダクトは、障害に関する項目を外すなど、
その場に適した対応を取って頂いています。
2. New Relic編
幸いNew RelicにもFour key、DevOpsを意識した造りがあり、
APIをカスタムする・作成する、などを行うことで、
現場に適した形にしています。
New RelicのDevOpsへの役立て方に関して下記ご参照ください。
DevOpsを評価する
これからの取り組みについて
・適正な評価レベル作り
・アジャイル開発出ないチームへの導入の仕方について
・詳しい運用方法の策定。
・現状の改善を常に意識した組織文化作り。
可視化することはおおよそ出来ましたが、走り始めたばかりで、
継続的な改善を行う文化を浸透させるには、まだまだ時間がかかりそうです。
継続的に改善する必要性を認識しているチームは、
そうでないチームよりも組織のパフォーマンスが高い傾向があります。
とのこと、
そりゃそうだろ
うるるのベンチャースピリットを持って成長し続けるという組織文化とも合っている！
全開発部への浸透を継続的に頑張っていきまーす。
次回は@kumiko_suzuki さんです！
参考
LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)
エリート DevOps チームであることを Four Keys プロジェクトで確認する
DORA 2022 度版 State of DevOps Report
DevOps 技術: トランクベース開発
ソフトウェアデリバリーで重要な4指標をCircleCIの統計値から読み解く【デブサミ2022夏】
DevOpsを評価する