プロダクト開発組織・人材を対象に、開発パフォーマンス・生産性の最大化インフラ Offers MGR と副業転職プラットフォーム Offers を運営する株式会社 overflow のエンジニアの shun です。今回は弊社でローンチしている Offers MGR を活用し、半年間開発チームの運営をしてきて取り組んできたことと、その成果について話せればと考えています。書き出すとかなりの量となったため、今回は一旦「変更障害率」の数値を見つつ改善した話をしたいと考えています。
モチベーション
2023年4月から、主にtoC側のプロダクト開発をするチームのリードとして振る舞うこととなりました。正直何もわからなかったので、一旦チームとしてのアウトプットは如何なる時でも重要であろうと考え、ちょうどリリースされたばかりの Offers MGR の FourKeys を用いて眺め、改善してみようと考えたのが主です。また、社内で積極的に自社サービス使うことでフィードバックを Offers MGR チームに還元できるので、一石二鳥とも考えています。
FourKeysとは
「Four Keys」とは、GoogleのDevOps Research and Assessment（https://dora.dev/）チームが提唱した開発生産性を計測するためのフレームワークで、以下4つの指標で構成されています。
| 指標 | 概要 |
|---|---|
| デプロイの頻度 | コードを本番環境にデプロイまたは、エンドユーザーにリリースした頻度 |
| 変更のリードタイム | コードが commit されてから本番環境で正常に実行されるまでの時間 |
| 変更障害率 | 本番環境に変更を加えた、またはユーザーへのリリースを実施した結果サービスが低下し、その後修正する必要が生じた割合 |
| サービス復元時間 | サービスインシデントまたは不具合が生じた際にサービスの復元にかかる時間 |
Offers MGR では、Four Keys を GitHub と連携して可視化するページがあります。
（詳細はこちらのプレスリリース記事をご覧ください。）
「変更障害率が高い」
ある日 Four Keys を眺めていると、「変更障害率」 が異常に高い状態でした。ほとんどマージされたPRが修正リクエストとなっていたのです。スコアとしては 「Low」 となっていました。
思い当たる節としては、直近で行ったファイル差分300を超えるデカ目リリースです。動作確認の時には出てこなかった細かいエラーがポツポツと出てきており、修正することに。チームで発生事象を共有しつつ、即座に対応を進めます。しかし、実際にバグ発生箇所を見ると 「これ動作確認やコードレビューちゃんとやってたら払拭できたのでは」 という感想を抱くものばかりでした。
原因：「PRが、でかい」
結論として、「クソデカPR 大規模プルリクエスト」が及ぼしたものではないかという仮説に落ち着きました。例えば、300ファイル差分のPRに対して「コードレビューお願いします」と言われた時、レビュワーとしては最初の10分くらい以下のようになると考えています。
要は、でかいPRに対して人はやる気にならないのです。 とはいえ仕事なので、ちゃんとレビューします。しかし、GitHub 上の diff 画面だけでは、他ファイルとの依存やエッジケースまで考慮した 「コード品質を保ち、互いの成長に寄与するような高度なコードレビュー」 を実施しづらいです。手元でレビューするにも時間がかかります。
改善案：「PRは小さくしよう」
例えば、ファイル差分5のPRレビューを依頼された場合はどうでしょう。
「サクッと見てレビューしちゃおう」 となります。
レビュー依頼を受け取るタイミングでは心的障壁は皆無です。
中身を見に行く時はどうでしょう。
- 「この処理はxx側でも使ってるから、共通化できそう」
- 「あえて自前で作らなくても、ライブラリのメソッド使えばいけそう」
- 「これやっちゃうと別ページがぁぁぁ」
- 「Aというinputが来た時にも対応できてるかな」
など、コードから自分が持っているドメイン知識や経験と紐付けた 「事故らない」 レビューができます。仕事でもプライベートでも、余裕 が大事。とはいえ、1回でリリースしないといけない機能も当然あります。
なので、「結果的にはファイル差分300だが、子タスクとなる実装は細かくPRを出してレビューしてもらう」 ということをチームで実施しました。
例）ログイン機能の実装の場合。
- タスク
- ログイン画面の実装 => これで1PR
- フロント側バリデーション追加 => これで1PR
- ログイン機能自体の実装 => これで1PR
成果
弊社では大きめの差分を生むタスクが高頻度で発生しますが、その期間を含めた平均値で 「High」 の基準（15%以上30%未満）を維持できるようになりました。「小さいPRをレビュー回数的には増えるが、それぞれの質が高いため、変更障害率の低下に寄与できた」 と感じています。
予期してませんでしたが、PRを小さくすることを意識し始めたエンジニアの心理に、以下のような良い変化がありました。
-
タスク分割する癖
- 分割することで、バックログ上の透明性もよくなり、誰しもが進捗を確認できる状態に
- また、分割されていることで、「この子タスク、お願いしてもいいですか」というパス回しもできるように
-
タスクの要件定義のうち、先に商用環境へリリースできそうなものを探る癖
- エンジニアからPdMやデザイナーに対する共有や提案機会が増え、チーム内コミュニケーションが活発に
-
リファクタリングが必要と判断し、先に商用環境へリリースしてしまおうという癖
- リファクタリングだけのPRを先に商用環境へ反映し、整理された状態において実装することで事故を未然に防ぐことができた
結果的に 小出しに出せるものは出すというスタンス で Four Keys の「デプロイ頻度」も 「Elite」 となったので、これがあるべき姿なのかなぁと思った次第です。また、細かく毎日デリバリー・タスク消化することがモチベーション向上に繋がりやすいチームメンバーだったという気づきにもなりました。
まとめ
私がDev Leadにアサインされ、半年間 Offers MGR の Four Keys を眺めつつ 「変更障害率が高い」 という問題へアプローチした話でした。最近では CodeRabbitのような、AIにコードレビューを任せる時代になりつつあります。ただし、しばらくはAIからのレビューで承認がされた後でも、人間が最終チェックするという流れは続くと感じており、今後も本記事で話したようなアプローチは継続していく所存です。
また、「AIが読みやすいコード」というAIファーストな時代も来ると感じており、「AIが読みやすい ≒ 人間が読みやすい」ということは忘れずに今後もコードを書いていく所存です。
次回は Four Keysを半年間眺めて取り組んだこと -「リードタイムが長い」編 をお話しできればと考えています。
関連記事
副業転職の Offers 開発チームがお送りするテックブログです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 jobs.overflow.co.jp
Discussion