この記事はうるるAdvent Calendar2024の記事です。
エンジニアより開発に詳しいウルトラ採用担当👩💼の
たえPこと@Taeko_ito よりバトンをつないでいただきました。
(ちなみに、たえPは僕の1万倍くらい滑舌が良いです)
さて、笑
出張撮影のフォトグラファーマッチングプラットフォームのOurPhotoでエンジニアリングマネージャーをしているdoueです。
当社では珍しいtoCサービスを担当しています。
toCはマジでむずい…と日々実感する毎日です。
最後までぜひ読んでいただけると幸いです。
はじめに
今回は、開発生産性とFour Keysのおはなしです。
「チームで取り入れたいけどどう役立つのかわからない」みたいな悩みを持ってる方へ
何かのきっかけになれると嬉しいです。
今までの開発チーム目標
エンジニアリングマネージャーとしては
まずは「高い開発生産性を持つチームを創る」というミッションを持っているということはいうまでもありません。
元々、私のチームでは以下のような目標を開発チームで設定することが多かったです。
- 半期単位で設定したプロジェクトの達成
- テストカバレッジ
これらは、いわゆるQCDに基づいて設定されている指標です。
C:コストについては、基本的にチーム予算が予め設定されているため省いていますが
AWSのコストについての施策を行うことももちろんあります。
エンジニアリングチームは、直接的な成果につながる指標化をできない仕事が多いため
ぶっちゃけ数値化は頑張っていなかったですが
根っこの考え方は「事業貢献する開発チーム」を目指しています。これはいつでも揺るぎません。
スピード重視で駆け進んだ半年間
ある時期、とにかく事業を前に進めるため
複数のプロジェクトをゴリゴリ進めていこう！という半年間がありました。
若手やベテラン総動員でプロジェクトを爆速で進め
差し込みプロジェクトもやりきり、普段はやらない深夜リリースもし、順調に見えました。
しかし、蓋を開いてみると
半年間でサービス障害を数回起こしてしまっており、ユーザーや事業に大きなご迷惑をかけてしまうことになります。
その背景には検証不足といえる、バグの多発...
サービス提供そのものにも大きな影響を与えました。
これでは、生産性どころか事業貢献すら全くできていないと
マネージャーとして猛省することになります。
Four Keysへの気づき
サービス障害の原因たるものは、「検証不足」ですが
それだけで終わらすにはあまりにも勿体無いです。
そこで色々な角度から整理した結果、以下のような分析ができました
- 2,3ヶ月単位で実装したものをビックバンリリース
- 一気に大量のテストケースの確認はもはや人間にはムリ。絶対漏れる。
- リリース後、すぐに検知できたエラーにもっと早く対応できた
- 調査→hotfixの準備・リリースにほぼ一日を要している
こんな分析をしている中、ふと頭に浮かんだものがありました。
「Four Keys」です。
つまり、いかに「スピーディ」「安全に」ユーザーへ届けるか。
これがチームにとっての生産性を表す指標として意味があるものと気づきました。
Four Keysとは
Four Keys（フォーキーズ） は、GoogleのDevOpsチームが開発したソフトウェア開発と運用における生産性と成功を評価するためのフレームワークです。これは、DevOpsの有効性を測定するための4つの主要指標（Key Metrics）を示しており、ソフトウェア開発チームが目標達成に向けて進捗を評価するための指標として活用されます。
Four Keysの4つの指標はこちら
1. デプロイ頻度（Deployment Frequency）
- 意味: コードを本番環境またはステージング環境にデプロイする頻度。
- 目的: チームのリリーススピードを評価します。頻繁にデプロイできることは、チームが小さな変更を迅速にリリースできていることを示します。
高頻度のデプロイは、アジャイルな開発と迅速なフィードバックループを実現します。
例: 1日1回以上のデプロイを目指す。
2. リードタイム（Lead Time for Changes）
- 意味: コード変更のコミットから本番環境にリリースされるまでの時間。
- 目的: アイデアから顧客価値を提供するまでのスピードを評価します。
短いリードタイムは、効率的な開発プロセスと迅速なリリースを示します。
例: 数時間から1日以内が理想的。
3. 変更失敗率（Change Failure Rate）
- 意味: 本番環境にリリースされた変更が失敗（バグ、ロールバック、ホットフィックスの必要など）する割合。
- 目的: デプロイの信頼性と品質を評価します。
低い失敗率は、品質の高いリリースを維持していることを示します。
例: 変更失敗率が15%未満が望ましい。
4. サービス復旧時間（Time to Restore Service）
- 意味: システム障害やインシデントから復旧するまでの時間。
- 目的: 問題発生時の迅速な対応能力を評価します。
短い復旧時間は、信頼性と危機対応力を示します。
例: 数分から数時間以内に復旧することを目指す。
※↑ChatGPTによる説明です
チームにおけるFour Keysの意味づけ
サービス障害の対策を踏まえつつ、チームの考えとFour Keysを紐づけてご説明します。
デプロイ頻度と変更失敗率
- 大きなプロジェクトを小さく分解する
- 複数回（できれば1,2週間）でリリースできる単位にスケジューリング
- できればMVP的観点も取り入れ、意味のある最小単位でリリース
これにより、リリース前の動作確認量が必然的に少なくなり、確認が隅々まで行き届きます。
結果、人為的ミスの発生率が減らせました。
またPRの単位も小さくできるので
コードレビューがしやすく、レビュワーも助かります。
実装者も、テストコードのカバレッジを高水準で維持しやすく
コードの複雑性にもしっかりと着目して実装しやすくなりました。
結果的にはリリース頻度が高く
なおかつ、品質の高いコードがデプロイできます。
デプロイ頻度とリードタイム
- ユーザーからの問い合わせによる緊急対応（非常に小さい修正）はいち早く対応し、臨時リリースを検討する
前段のプロジェクト分割だけでも十分な効果でしたが
チームがFour Keysに焦点を当てることで、緊急対応にも精が出ます。
結果的には、振り返り前後で数値が大きく変わりました。
デプロイ頻度：ほぼ1回 → 1.6回/週
リードタイム：9日 → 5日
サービス復旧時間
もし、リリース後、サービス障害レベルのバグなどが起きてしまったら？
とにかく何がなんでもすぐに解消が必要です。
そこで活躍する（予定）なのが
Blue/Greenデプロイです。
元々、我々のプロダクトにはBlue/Greenデプロイを導入していましたが
待機時間が20分と短く、デプロイ後、障害を検知して戻すには短すぎる設定でした。
そのため、Blue/Greenデプロイの待機時間を1時間に伸ばすこととしました。
(予定というのは、まだ実際にはやったことがないからです。笑)
とはいえ、migrationやデータの変更などを伴うリリースが発生すると
巻き戻しができないパターンもあるので注意が必要です。
【計測を細分化】
復旧時間といっても、発生したエラーの性質により求められるレベルも変わってきます。
- ユーザーのサービス利用ができない状態:数分〜数時間
- 一部のページで一部の条件でのみエラーになる:数日
デプロイ後のエラーの対応時間を記録するわけですが
全てを一色単に平均すると、実態がよくわかりません。
そのため、「軽微なバグ」と「重大なバグ」のように分類して計測するようにしています。
ちなみに、これらの数値はだいたい手作業でスプレッドシートに記録しています。
Findyさんなどのツールもございますが、試験的かつ小さいチームなので、まずは手作業です。（自動化できる部分は自動化してますが）
さいごに
いかがでしたでしょうか。
我々のチームで、Four Keysを取り入れたばかりで
組織文化の醸成というと、まだまだこれから！という感じですが
このように、数字を単に数字としてみるわけではなく
その数字と仕事に意味を持たせていけば
指標としてもしっかり機能していくと感じています。
エンジニアが抱える永遠の悩み
「開発生産性とは？」
何かの気づきになれば幸いです。
さて
明日は、僕の一個下の後輩である @KawamotoShuji の投稿です！
新卒6年目（たぶん）にもかかわらず
あの頃のキラキラ✨が全く霞まないスーパーイケイケエンジニアの記事を
どうぞお楽しみください！