これはなに
Uniposアドベントカレンダー2022 3日目です。
開発組織をマネジメントする部隊に所属しています。
今回は弊社の開発組織の生産性計測についてお話ししていきます。
課題
組織マネジメントする上で開発の健全性を定量的に評価できていない状況にありました。
開発の健全性
開発の健全性が高いとは
- プロダクトの価値が素早く顧客に届けられること
- プロダクトの品質が高いこと
が満たされている状態のことと解釈しています。
これら2項目を同時に高めるための手法について、
LeanとDevOpsの科学という書籍を参考にしました。
また、以降でお話しする内容は本書の語る結果だけ引用しているので、前提知識を知りたい方は是非読んでもらえるとこの記事が読みやすくなると思います。
忙しい人のために、簡単にまとめられている記事もありますので一応貼っておきます。
『LeanとDevOpsの科学』まとめ (Qiita)
一般的に品質とスピードは相反すると思われがちですが、そうでないということを本書では語られています。
では、どのような指標を評価し改善することで健全性を高められるかについて話します。
何を見るといいの?
本書では
- リードタイム
- デプロイ頻度
- 変更失敗率
- 平均復旧時間
の4指標を見ると良いとしています。
この4指標をまんべんなく高いと、品質の高いプロダクトをすばやく提供できる状態にあると評価できると述べられています。
それぞれの指標の定義と弊社での算出方法について話します。
指標 | 定義 | 算出方法 |
---|---|---|
リードタイム | コードのコミットから本番稼働(リリース)までの所要時間 | github上の最初のコミットからマージ完了までの時間 |
デプロイ頻度 | リリースの頻度 | github上のリリースタグ数 |
変更失敗率 | リリースした結果、品質低下し修正する必要が生じた割合 | github上の バグissue / 上記デプロイ頻度
|
平均復旧時間 | インシデント等の不具合が発生した際のサービス復旧に要する時間 | インシデント報告書からヒアリング |
現状の評価
平均復旧時間以外は取得できるような体制が整いました。
残る課題と展望
一方で算出対象の妥当性については開発チームのgithub運用次第でちょろまかすことも可能になってしまう懸念があります。
また平均復旧時間は人力でかつ曖昧な定量情報になってしまっています。
そのため、githubの運用ルールやインシデント報告フローの整備・合意をしていく必要があります。
これらの指標が見える化されることで、ビジネスサイドとのコミュニケーションがより円滑になったり、開発組織内のモチベーションアップに繋がる良い体験が社内に増えることを期待しています。