はじめに
こんにちは。マネーフォワード クラウド会計Plus 開発部に所属している段松です。私の開発チームでは、開発生産性の向上と可視化を実現するために、2022年からFour Keysを導入しています。本記事では、Four Keys導入の背景やそれぞれの指標の重要性に関する考察、実際に活用してみて感じたメリットと課題について、開発チームでの経験をもとに紹介します。
Four Keysとは？ なぜFour Keysを使うのか
Four Keysは、GoogleのDevOps Research and Assessment（DORA）が提唱している、ソフトウェア開発チームのパフォーマンスを示す以下4つの指標です。
- デプロイの頻度：組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム：commitから本番環境稼働までの所要時間
- 変更障害率：デプロイが原因で本番環境にて障害が発生する割合（%）
- サービス復元時間：組織が本番環境での障害から回復するのにかかる時間
Four Keysを利用する主な利点は、開発生産性の可視化にあります。開発生産性を測るための指標は多数存在しますが、Four Keysはその中でも特に認知度が高く、専用の測定サービスも提供されている点が魅力です。
可視化により自チームのパフォーマンスを過去のデータや他チームと比較することが可能となります。これまで感覚的な議論が行われている場面でも、数値という客観的事実にもとづいて話し合うことが可能です。
また、DORAが6年間を費やした研究調査にもとづいた指標であり、測定結果に対して、「Elite・High・Medium・Low」という分かりやすい評価基準があるので、開発プロセスの改善に活用しやすいことも魅力の一つです。
なぜこの4つの指標を測るのか
実はFour Keysがチームに導入されはじめた頃、私は「なぜこの4つの指標なのか」をしっかり理解できていませんでした。しかし、Four Keysを改善していく中で気づいたこととしては、これらの4つの指標を追っていくことは、ソフトウェア開発やDevOpsにおけるベストプラクティスを行うことにつながるということでした。一つひとつの指標を深掘りしながら、私の開発チームで実際に行った取り組みも交えて見ていきたいと思います。
デプロイの頻度
デプロイの頻度を高めるためには、デフォルトブランチへのマージを頻繁に行い、それを効率よく本番環境にデプロイする仕組みの構築が必要です。これを達成する中で下記のことに取り組みました。
- デプロイ作業の自動化：自動化し、デプロイにかかるコストが小さくなるほど頻度は上がります。私のチームでは自動化を進め、最終的にはSlackからのコマンド一発で本番環境へデプロイできるようにしたことで、デプロイの頻度を高めました。
- フィーチャーフラグの導入：フィーチャーフラグを導入することで、開発途中のPull Requestでもマージすることが可能になり、デプロイの頻度が上がります。ビッグバンリリースを防いだり、デグレーションの発生を抑えたりする効果も期待できます。私のチームでもフィーチャーフラグの導入を行ったことで、これまでは機能によってデプロイまで数カ月かかっていたものが、1日に複数回デプロイが行えるようになりました。
変更のリードタイム
変更のリードタイムを下げるためには、コードを書く時間、レビューにかかる時間、そしてApproveを得てから本番にデプロイするまでの時間をそれぞれ短くする必要があります。これを目指すために下記のことに取り組みました。
- Pull Requestを小さく保つ：コーディングにかかる時間は短くなりますし、レビュー時間も短縮することができます。これを意識し始めてからはプランニング時もどの程度小さいPull Requestに分割できそうかを議論してから実装に移るようになり、実際に指標も良くなりました。そのほか実装やレビューの際もスコープが分かりやすく、開発が進めやすくなりました。
- リファインメントにおいてストーリーの要件を明確にする：実現したい仕様を明確にしておくことで手戻りを防ぐことができます。エンジニア自身もドメインを理解し、POとのコミュニケーションが適切に取れているかも重要になってきます。
- ペアプログラミング・モブプログラミングの実施：チームメンバーと共同でコーディング作業を行うことで、レビュー時間の削減やスキルの共有によるコーディングの高速化が可能です。複雑な実装などは特にモブプログラミングなどを行うように意識しています。
- CI/CDの高速化：Pull Requestの作成・レビューがどれだけ速くても、CI/CDが遅ければ全ての変更のリードタイムに影響します。高速化することで、大幅にリードタイムを削減できます。
変更障害率
変更障害率は、開発スピードというより安定性の指標になります。下記は私のチームでも以前から意識しながら開発していたことで、変更障害率を下げる要因になると思います。
- 自動テストの拡充：自動テストをきちんと書いておけば、変更ごとに機能のデグレーションが発生していないかを確認でき、変更障害率は下がります。
- 変更用意性が高い設計：設計に関してはいろいろな書籍や記事などで議論されているのでここでは深掘りしませんが、適切に共通化されていないモジュールを作ったり、責務があやふやなクラスを設計したりすると、将来的に意図しない不具合が起こる可能性が高まります。
この指標があることで小手先の方法でFour Keysを向上させることが難しくなり、本質的な改善が必要になると感じました。例えば、テストを書くことをサボればコーディングの時間は短縮でき、変更のリードタイムは短くなりますが将来の変更障害率は下がるでしょう。
サービス復元時間
サービス復元時間も変更障害率と同じく安定性の指標になります。ただ、変更障害率に比べて開発していく上でのプラクティスというよりは、監視やチームの体制などの運用面についての工夫が必要になると感じました。不具合を迅速に検知し、必要なメンバーだけで素早く障害対応を行うことが可能になれば、他のメンバーは開発作業を継続することができ、全体の生産性が向上します。
- エラー検知とメトリクスの取得：システムの異常を迅速に検知できれば、復元までの時間も短縮できます。私のチームではエラー検知にRollbarを、サーバー監視にDatadogを使用しています。これにより、システムの不具合に素早く気づけるようにしています。
- チームの障害対応の体制整備：障害発生時の迅速な対応を支えるチーム構成やプロセスを整えることで、スムーズに対応に取り掛かることができます。私のチームでは、カスタマーサービスから上がった不具合をQAチームが一次対応し、コードの修正やより深い調査が必要なものはスクラムチームから選出されたエンジニアが障害対応を行う形で体制を確立しています。
