はじめましての方ははじめまして、iOSエンジニアのtanakoです。
この記事はタイミーのアドベントカレンダー10日目の記事となります。
今回はiOSチームで運用にトライしているFour Keysについて、なぜ運用しているか、運用してどうだったかを書いてみます。（iOS固有の話は少ないです）
Four Keysとは何か
Four Keysとは開発チームのパフォーマンスを示す4つの指標を定義したもので、ビジネス成果と相関関係があります。詳しい説明は次の記事や書籍を参照してください。タイミーもFour Keysを重要視していて過去同テーマで勉強会も行っています。
- LeanとDevOpsの科学
- エリート DevOps チームであることを Four Keys プロジェクトで確認する（Google Cloud Blog）
- Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について
- Four Keysで進める改善サイクル - Techmee vol.4（タイミーが開催した勉強会）
タイミーのiOSエンジニア組織とFour Keys運用の背景
タイミーにはプロダクト開発軸のチームと別に技術軸でChapterと呼ばれる仮想組織が存在します。iOS ChapterにはiOSエンジニアが所属しており技術的な課題の探索や負債の解消、エスカレーション、実組織へのデリゲーションなどを責務としています。
実はiOS Chapterは元々週1,2アプリをリリースしていたのでリリース頻度は十分高い状態でした。しかしそれは感覚的なもので定量的には計測をしておらずチームのパフォーマンス低下を検知できないという課題が残っていました。スタートアップにおいて事業成長に伴うメンバーの急増でチームに混乱が生じ、開発生産性が低下し、バーンアウトを招くことは再現性のある問題です。その問題に備えるためにもメンバー急増の前に自律的にパフォーマンスの健全性を検査して適応する能力を持つことが急務と考えたことがFour Keysの運用に至った背景となります。
運用方針
ここからは運用の方針についてご紹介します。まずはFour Keysを計測する上でのアンチパターンを避けるため3つの方針をたてました。
- 数値を上げることを目的化しない
- 行動変容につなげる
- チームに合わなければ別の方法を選ぶ
それぞれ詳細を述べていきます。
1. 数値を上げることを目的化しない
あくまでiOS Chapterとしてあるべき姿に近づくために運用しているため、良いプラクティスの適用など、本質的な改善活動の”結果として中長期的に数値が上がる”ことを意識する。数値向上自体の目的化はPRを作り直してリードタイムを短縮するなど本末転倒な運用を招く。
2. 行動変容につなげる
眺めるだけの数値には意味が無いので数値を解釈して必要な改善アクションを実行する。Action Requiredな変化をプッシュできると望ましいが難しければ閾値を決めて定期観測する。
3. チームに合わなければ別の方法を選ぶ
Four Keysは開発パフォーマンスに統計的に強い相関関係があるが、全てのチームにフィットするとは限らない。思考停止で運用せずフィットしないなら別の手段を選ぶ。
なお、これらの方針を立てる際には以下の記事を参考にさせていただきました。
- Four Keysと向き合うとはどういうことか
- メトリクスの数値を追うことが目的化してしまってはいけない
- "When a measure becomes a target, it ceases to be a good measure”
運用設計
ここからはFour Keysの運用設計について書いていきます。
試験的な運用ですし計測コストも抑えたかったため、簡単にFour Keysを計測できるFindy Team+で次の運用を実施することにしました。
- パフォーマンス低下の検知とアクション要否の判断（月次）
- パフォーマンス維持改善に関する共有と相談（月次）
尚、Four Keysは遅行指標で短期的な問題のスパイク検知には適していないため、日次と週次で短時間の同期的なミーティングも行い、各自の困りごとや課題感を早期に解決する仕組みも並行で運用しています。
運用1: パフォーマンス低下検知のためのガードレール指標の運用
Findy Team+のDevOps分析という簡単にFour Keysを集計表示できる機能を活用します。
過去28日間の集計結果からiOS Chapterで定めたガードレール条件に指標が1つでもマッチした際にパフォーマンス低下として扱うことにしました。
以下が具体的なガードレール条件となります。
デプロイ頻度が隔週以上になった時
ビッグバンリリースを避け週1,2回は新しいアプリをStoreにリリースできていれば健全、隔週リリースでは非健全と設定しました。なお、Findy Team+のデフォルトではmain|masterブランチのマージでデプロイ頻度が集計されます。iOSアプリではストア公開=本番環境デプロイなので、実態に近くなるようにリリースタグで集計するよう設定しています。これによりCI/CDの問題にも気づきやすくなります。（デプロイ関連の負荷はバーンアウトとも強い相関があるので重要です）
変更のリードタイムが90h以上になった時
先月値をベースに厳しすぎないラインにした結果です。
はじめのコミット〜mainブランチにマージされるまでの時間を正確に計測するためサイクルタイム分析の合計値を参照しています。（DevOps分析のリードタイムもタグベースで集計されてしまうため）
変更障害率が5%以上になった時
根拠の無い15%決め打ちでしたが、計測開始から変更起因の障害が起きていないため5%に変更して様子を見ています。過去仕様をブラッシュアップしたケースなども含めると際限なく変更障害率が上がってしまうので社内の仕組みで障害報告されたものだけを計測しています。
平均修復時間が24h以上になった時
hotfixブランチの最初のコミットからmainブランチへのマージまでの時間です。当日中に検知〜修正ができる想定なら一定妥当性はありますが調整の余地はありそうです。（Feature Flagの運用をしているので正確な計測が難しい部分もあります）
運用2: 計測結果からの原因特定や条件見直しのアクション
計測結果に応じて以下のアクションを定めました。
結果と必要なアクション
☀️ 良好: アクション不要
☁️ 1つ以上の指標がしきい値が以下: 早期アクションが必要、iOS Syncで議題とする
☔ 2つ以上指標がしきい値以下: 緊急でアクションが必要、Syncを待たずHuddleで相談する
※ iOS SyncはiOS Chapterが週次で実施している困りごとの気軽な相談や自由な共有をする場です。
なお、計測→判断→共有までは5分で済むため自動化はしていませんでした。
運用3: パフォーマンス維持改善に関する共有と相談
改善余地がある指標について、より良いプラクティスや実施の状況について月次で共有相談することにしました。共有相談の例は次のとおりです。
現在以下が維持改善の余地がありうる指標として捉えています。
- デプロイ頻度
- 現在毎週リリースできているが属人性を減らすアイデアを募りたい
- 変更のリードタイム
- 現在88h、レビュー着手速度の改善に対してアイデアを募りたい。
運用してみて
まだ3ヶ月の運用ですが、メンバーの急増にも関わらず3ヶ月連続で全てのガードレール指標を下回らずに済んでおり悪くない状況です。
参考までに過去3ヶ月の分析結果をのせておきます。（DevOps分析のデプロイ頻度0.3件は週1,2回のリリースが出来ていることを示しています。変更のリードタイムは先述の通りリリースタグベースなので正確な値はサイクルタイム分析の方を参照してください）
良かったこと
低コストで開発生産性における安心感が得られる
「運用1: パフォーマンス低下検知のためのガードレール指標の運用」は低コストでありつつも、開発パフォーマンスの健全さについて一定安心感を持った状態で働けていると感じています。「運用3: パフォーマンス維持改善に関する共有と相談」については直近数ヶ月でパフォーマンス低下が起きていないので温度感があがらず運用していません。
開発生産性を高める力学が働きやすい
アプリのリリースや依存関係の自動更新PR作成などは元々自動化されていましたが、その他以下の活動や仕組み化、トイルの削減などが進んでいます（一部抜粋）。
- リリース作業のランダムアサインを自動化
- 動作確認コストを軽減するためのE2Eテストツールの導入検証
- 静的解析ツールのメリットと生産性に与える影響を加味した設定の見直し
- Code ClimateはSwiftや宣言的UIにマッチしていないと判断して運用を止めています
- SwiftLintのCI上での一部運用を見直し（ルールの再整備などはこれから）
- TestFlightのテスター登録を半自動化するSlack Workflowの作成
- 早い段階でのHuddleによる同期的な設計方針のすり合わせ
- レビューされていないPRのアラートを通知するようにした
改善点、今後の展望
仕組み化、省コスト化
手順が個人に依存しているため、属人性を下げたいとおもっています。運用継続をメンバーと議論した結果、モバイル開発のパフォーマンス低下検知の文脈ではデプロイ頻度は十分安定しており数ヶ月に1度見れば十分と感じてきています。そのためFindy Team+の機能でslackに通知されるリードタイムレポートだけでアクション要否を判断してみるトライをする予定です。
変更のリードタイムの閾値を調整した実験
「運用1: パフォーマンス低下検知のためのガードレール指標の運用」の閾値は若干余裕を持って設定しているため調整の余地があります。今は変更のリードタイム「オープンからマージまでの平均時間が65h以上かかっていないか」を週次でみる実験をして偽陽性の混ざり具合などを確認してみようと考えています。
変更障害率、平均修復時間の計測は現状維持
今は大きめの障害だけ計測しているので、アプリに元々ある細かい不具合は計測できていません。とはいえ事業上影響があるレベルの障害はきちんと計測できていること、その際のポストモーテムの運用で継続的な改善が回っていることから大きな問題は無いと考えています。（もちろん既存の軽微なバグも適宜修正されています）
パフォーマンス改善のための活用
「運用3: パフォーマンス維持改善に関する共有と相談」は運用できていませんが、各会で「PRレビューお願いします」や「これからPRみます」などの会話は増えていて、ガードレール運用だけでも一定価値は感じました。パフォーマンス改善の文脈で活用する際はiOS Chapterとしてのあるべき姿を改めて考え、そこに到達する手段としてのFour Keys活用を意識していきたいと思います。
まとめ
iOSチームでFour Keysの運用にトライしている話でした。iOS固有の話は少ないですが、Findy Team+でライトに始めることで開発生産性の認識を揃え、建設的な議論をしやすくなります。「これからチームが大きくなるので心配」という方は是非ガードレール指標の運用から試すと良いかと思います。最後までお読みいただきありがとうございました！