見出し画像

アイミツ開発チームの開発生産性をFindyTeams-DevOps分析してみた

アイミツ開発チームでエンジニアリングをしている deliku です!

弊社で導入している「Findy Teams」にて、開発生産性指標 ”Four Keys” を可視化・分析する「DevOps分析」機能の提供が開始されたので、計測結果をみていきたいと思います。

また下記記事にて Four Keys(記事中では キーメトリクス の名称) と企業分析結果について言及されておりますので、参考までに紹介しておきます。

▶︎ 前回の記事

▶︎ 他チーム(アイミツSaaS開発チーム)の分析記事

▶︎ デプロイ頻度

FindyTeamsにおけるデプロイ頻度の定義は、任意のブランチへのマージ回数または、任意のリリースタグ数 となっており、アイミツ開発チームの場合 mainブランチへのmergeを計測タイミングに設定しています。この設定はFindyTeams > スタッツ管理で設定できます。

DevOps分析 - デプロイ頻度

計測結果は0.9件となっていました。基本的に1日の最後にその日リリースするものをデプロイする運用にしているので、この値は想定値に近いものとなっています。main ブランチに merge したら自動でリリースするように変更すればこの数値は高くなるのですが、デプロイコストがかかってくるため現状このような運用になっていますので、デプロイコストを限りなく0(人的操作をなくす)にできれば、この値はより改善できるかなと考えています。

▶︎ 変更のリードタイム

FindyTeamsにおけるリードタイムの定義は、期間内にメインブランチにマージされたプルリクに紐づくすべてのコミットのマージまでの時間を平均値として算出されています。

DevOps分析 - 変更のリードタイム

数ヶ月前は 18h を推移していましたが、直近は 24h を超えてしまっています。これはタスクを細かく分割できていないことにより、数日かかるタスクが発生していることや、大きな機能の場合、統合ブランチを作成して並列で開発することで実際のマージされるまでのリードタイムが増加しているためと分析しています。

タスクを小さく分割するメリットは下記記事にある通りなのですが、まだ実践しきれていない部分があるので、明日以降のタスク分割で意識していこうと思います。

統合ブランチを作成するのではなく、リリースできる単位(ユーザに影響のない範囲)に分割してリリースしていくアプローチが考えられるのですが、チームの開発のしやすさの観点からそこまで踏み切れておりません。(この点については、FindyTeams上の数値を改善するよりも、開発のしやすさを優先する判断をすることもあり、ケースバイケースになるだろうと考えています)

▶︎ 変更障害率

FindyTeamsにおける変更障害率の定義は、期間内にメインブランチにマージされたプルリクのうち、hotfixブランチまたは、revertブランチが占める割合です。

DevOps分析 - 変更障害率
DevOps分析 - 変更障害率 - ランク分類


ほぼ毎日デプロイして、1.9%は非常に優秀な数値かと思います(自画自賛)
基本的にCIでテスト実行しており、テストケースが通らないとリリースできない運用になっているので、障害を気にせず安心してデプロイを行えているといえるのではないかと思います。

▶︎ 平均修復時間

FindyTeamsにおける平均修復時間の定義は、期間内にメインブランチにマージされたプルリクのうち、hotfixブランチまたは、revertブランチに紐づくコミットの最初のコミットからメインブランチへのマージまでの時間を平均値として算出されています。

DevOps分析 - 平均修復時間

障害はどんなに気をつけていても発生してしまいます(もちろん発生させないにこしたことはないのですが)。そのため、いかに素早く異常を検知し、素早く切り戻しできるかが重要と考えています。

基本的に障害発生は datadogsentry などの監視ツールからのアラートで検知するようになっています。また切り戻しはいくつかのパターンを想定して手順書をNotionにあらかじめ用意しています。

・hotfixでの対応基準 / 対応方法
・DBマイグレートをともなう対応
・Blue/Greenデプロイ&ロールバック対応

また障害対応をして2次被害が発生しないよう作業は1人でしない、周りに声をかける、落ち着くなど焦って作業しないようにすることが大事かなと思っていますので、障害対応のNotionに赤字で書いています。

デプロイ切り戻し手順 - 重要項目

▶︎ 最後に

”Four Keys” を数値指標とし、自分達の開発パフォーマンスを可視化することでコンディションチェックができるようになりました。ただし、開発速度が速いことはもちろん良いことですが、大事なことは顧客への価値提供がなされているかです。(私が定期的に見返している LayerXの榎本さんの資料を紹介しておきます)引き続きアウトカムを意識した開発を推進していきたいと思います!

▶ 【PR】ユニラボ に興味がある方へ

今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います!


この記事が気に入ったらサポートをしてみませんか?