Zenn
🌡️

開発健全性(生産性ではないよ)のメトリクスを設計して運用してみた

2023/12/22に公開
DevOps
metrics
Four Keys
tech

この記事は、Magic Moment Advent Calendar 2023 22日目の記事です。

こんにちは、Magic Moment で QAE をやっている yano です。
本記事では、開発チームの健全性を示すメトリクスを設計し、計測と運用を始めて3ヶ月ほど経とうとしているタイミングなので、振り返りを兼ねて気づきをまとめさせていただこうと思います。

なぜ生産性ではなく健全性のメトリクスなの?

最初は生産性メトリクスの設計を考えていましたが、例えばコードの記述量や、スプリントにおけるベロシティなどアウトプットの質を度外視して量だけを追っていくような、ビルドトラップに繋がりかねないメトリクスを計測することは回避したかったという考えがありました。

一方で、 “If you can’t measure it, you can’t improve it.” の考え方にもあるように、カイゼンのためにはまずは計測することは必要不可欠です。

そして DevOps における CAMS (Culture, Automation, Measurements and Sharing) の Measurements を推進していくことは重要な活動であると認識しています。

そこで、生産性を示すメトリクスではなく、開発メンバとして真摯にプロダクト開発と顧客へのサービス提供ができているかを示すような健全性メトリクスを設計し運用することにしました。

健全性メトリクスの設計において参考としたもの

メトリクス設計において主に参考としたものは次の2つになります。

1つ目は DORA(DevOps Research and Assessment) の Four Keys です。

これらの指標は生産性ではなく、エリートな DevOps チームであるかどうかを示すメトリクスと捉えることができ、今回設計したいメトリクスのコンセプトとも相違がないですし、日本でもモダンな開発組織が追っている鉄板のメトリクスとして参考にしました。

2つ目はメトリクス設計におけるアンチパターンを避けたかったので 鷲崎弘宜 氏の実践的ソフトウェア品質測定評価のための4つの「落とし穴」と7つの「コツ」を参考にさせていただきました。

これは品質のメトリクスに関するものですが、メトリクス設計におけるアンチパターンとしては類似点が多いと考えられたので、落とし穴を避けるように注意しています。

  • 負のホーソン効果
  • 組織上の不整合
  • オレオレ品質
  • 未来が今の延長とは限らない

健全性メトリクスのコンセプト

メトリクスを設計する上でまずはコンセプトとスコープを決定し、次の5点を定めました。

  • ビジネス的に価値のある開発の健全性を測定できること
  • メトリクスのフィードバックにより、チームにカイゼンを促せること
  • 個人の評価に使うものではないこと
  • 生産性効率ではないこと
  • NSM (North Star Metric) までは本スコープに含めない(あくまで開発チーム内で取り扱う指標)

健全性メトリクスの設計

健全性メトリクスに興味のある有志メンバを集めて、メトリクスの案を持ち寄り、実際に取得できるものなのか、継続的なフィードバックする指標として使えそうかを検討しました。

そして次の7つのメトリクスを取得することにしました。

dogfooding における不具合対応の Turn Around Time (TAT)

dogfooding (プロダクトに対するフィードバックが Notion 上で起票される)における不具合対応のチケット起票から対応完了になるまでの Turn Around Time を通じて、流出した不具合に対する感度と対応速度のカイゼンを促すことを目的としています。

dogfooding における不具合率

dogfooding の不具合率を通じて、不具合起票を減らしていきユーザ目線での利便性や有用性といった魅力的品質の向上を目的とした起票ができるようにカイゼンを促すことを目的としています。

アラート数

アラート数を通じて、アラート疲れやアラートマヒを起こさずに、対応が必要なアラートに対する感度と対応速度のカイゼンを促すことを目的としています。

エラー残存期間

エラーの残存期間を通じて、未解決エラーに対する感度と対応速度のカイゼンを促すことを目的としています。

Pull Request (PR) のリードタイム

PR の初回コミットからマージされるまでのリードタイムを通じて PR の粒度やレビュー体制のカイゼンを促すことを目的としています。

変更失敗率

変更失敗率を通じて、サービスの信頼性 (Reliability) と安定性 (Stability) のカイゼンを促すことを目的としています。

Mean Time To Recovery (MTTR)

Mean Time To Recovery を通じて、サービスの信頼性 (Reliability) と回復性 (Resilience) のカイゼンを促すことを目的としています。

健全性メトリクスの運用

これらの設計したメトリクスは、Notion と Datadog 上で集計できるもので、開発組織の OKR として追っているメトリクスも一部あります。

現在は設計したメンバが月次で前月分のメトリクスに関してふりかえりを行い、開発者全体の MTG で Good だったポイントと Motto だったポイントを共有しています。

特に不具合対応の TAT に関しては短くなったことで、社内でポジティブなご意見をいただくこともあり、開発における健全性を実感できることがありました。

健全性メトリクスで今後やりたいこと

運用を始めて約3ヶ月経ったところですが、課題も感じており、今後やりたいことも出てきている段階です。

現状の開発体制とは合わずイマイチなフィードバックになっているものや、開発体制やフェーズが変わることで陳腐化していくものもあると考えており、定期的なメトリクスの見直しは必要になってきます。

メトリクスの中にはより詳細を分析したいものもあり、例えば不具合報告が多い機能は分析をして対策ができるようにならなければ根本的な解決になりません。

今回の健全性メトリクスではスコープ外にした NSM を設計し、健全性メトリクスと合わせでフィードバックと分析ができる状態にする必要が出てきています。

また SPACE フレームワークをベースにしたサーベイを活用し、自動的に取得することが難しいメトリクスとも合わせて運用できると良いなと思います。

メトリクスから継続的で素早いフィードバックループを構築し、能動的に必要なカイゼン活動をし続けることのできる体制ができればと考えています。

明日のアドベントカレンダーは ytoppoさん の「GoエンジニアがReactにチャレンジして驚いた5つのこと」です。

Discussion