こんにちは！マネーフォワード クラウド会計Plus（以後、会計Plus）開発部の段松です。
Four Keys を活用しながらチームの生産性の改善活動を行ったので紹介します。
Four Keys とは
Google が提唱しているソフトウェア開発チームのパフォーマンスを示す 4 つの指標です。
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ によると
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performancecloud.google.com
下記の4つの値を測定し継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができると提唱されています。
デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
会計Plusにおける Four Keys
マネーフォワード CTO が考えていること（2022 年 12 月）に記載の通り、マネーフォワードでは Four Keys 測定のための全社基盤を構築中です。
我々の所属する会計Plus開発部では Findy Team+ を利用して Four Keys を計測しています。
直近数ヶ月は Findy Team+ を指標に開発を改善してきました。(昨年は『Findy Team+ Award 2022』を受賞いたしました！)
この記事では、Findy Team+ 上で計測した Four Keys をどのように活用して生産性を向上させたかを紹介します。
会計Plusの開発の進め方
本題に入る前に私のチームの開発の前提を知っていただくため、まず会計Plusでの開発の進め方について紹介します。
LeSS(Large-Scale Scrum)と呼ばれる大規模スクラムの開発スタイルをとっており、複数のチームで開発を進めています。
1チームのメンバーの数は大体3~5人で、私はその中の1チームに所属しています。
1週間のスプリント毎にPBI(Product Backlog Item)という優先度順にリスト化された開発タスクをいくつか取り、順に進めていく、というのを毎週繰り返します。
スプリントの中では下記のようなプロセスで一つ一つのPBIの開発を進めています。
- プランニングでPBIの設計や実装の方針を議論しチームで合意を取る
- 機能を実装する(Pull Requestを作成する)
- チームメンバーにコードレビューをしてもらい、アプルーブをもらったらマージする
- 結合テストを行う
- ステージング環境で PO に機能のレビューしてもらい、OKだったらそのPBIを完了とする
改善活動前後の Four Keys の比較
改善活動前
改善活動を始める前の Four Keys の計測結果です。
この頃のチームの課題としてはスプリント期間内にPBIが完了せず、いわゆる仕掛かりが続いており生産性という観点で良くない状態が続いていました。
- デプロイ頻度: 0.2件/日
- 変更のリードタイム: 175h
- 変更障害率・サービス復元時間: 0
この計測結果は、エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ によると、
デプロイ頻度・変更のリードタイムは High、変更障害率・サービス復元時間については Elite になります。
デプロイ頻度・変更のリードタイムを Elite を目指すことでチームの課題を改善できるのではと考えました。
改善活動後(3ヶ月経過後)
下記は改善活動を行った後の Four Keys の計測結果です。
- デプロイ頻度: 1.8件/日
- 変更のリードタイム: 19h
- 変更障害率・サービス復元時間: 0
つまり
- 週に1回程度だったデプロイが、毎日1回以上になった。
- 1つのPull Requestが作成から本番反映まで1週間かかっていたのが、1日で済むようになった。
- 障害発生率や復旧時間は悪化しなかった。
Four Keys の数字上も良くなりましたが、この頃のチームの状況としても仕掛かりが少なくなり、予定していたPBIを早く完成させさらに追加でPBIに着手できるようになることが多くなりました。
POやスクラムマスターからも「最近チームの調子が良いですね」と声をかけられたりすることもありました。
グラフも見てみましょう。
(変更障害率・サービス復元時間に関しては直近3ヶ月どちらも0だったため割愛しています。)
デプロイ頻度頻度が開始時点の1月では約0.2件/日でしたが、4月には1.35~1.8件/日になり、頻度が約6~9倍に向上しました。
リードタイムが開始時点の1月では約170hでしたが、4月には約20hになり、リードタイムが約1/8に減少しました。
次に以下の内容を紹介します。
- Four Keys の向上に効果があった改善
- Four Keys の計測結果を活かしてどのようなプロセスでその改善策を講じていったのか
Four Keys の向上に効果があった改善を2つ紹介します
いくつかの改善を行いましたが、その中で特に効果を感じた改善を2つ紹介します。
どれもよく言われている基本的なことではありますが、Four Keys の値を意識し課題感を持って取り組むことでより効果的になったと思います。
1. Pull Request を小さく分割する
Pull Requestを小さく分割して、それぞれの変更が少ない状態でレビューを行うことに取り組みました。これにより下記のメリットがありました。
- レビュアーが修正内容を理解しやすくなり、レビューの速度が向上する。
- 多忙なメンバーがいても短時間でレビューができるので、ボトルネックになりにくくなります。
- 作業を分割する中で、開発タスクに対する解像度が上がる。
- 必要な作業や作業の順番、クリティカルパスなどを理解しやすくなります。 スプリントプランニングの時点で具体的な作業計画ができて、スムーズに作業が実施できます。
- 作業を細かく分割することで、メンバーが並行で作業を進められるようになる。
- 優先度の高い機能の開発に人的リソースを割きやすくなったり、引き継ぎが少なくて済むといった効果もありました。
上記はスプリントプランニングの一例です。
Miro を使って、ストーリーチケットに紐づく1つ1つのタスク(Pull Request を含む)を付箋に書き出して「どのタスクが並行で進められるのか」や「より細かく分割できないか」を以前より議論するようになりました。
2. モブプロ(モブプログラミング)を行う
リードタイムが伸びる原因の一つとしてレビューで何度もやり取りが発生し、書き直しが繰り返されることがありました。
設計の選択肢が多い場合や複雑なケースは、一人でコードを書くとメンバーとのやり取りや手戻りが発生する可能性があります。
そのためプランニングの時点でモブプログラミングを行い、方針をチーム内でコードレベルで合意し、その後は個別の Pull Request で担当するように変更しました。
これにより、レビューがスムーズに進むようになり、書き直す回数が減少し、結果としてリードタイムも短縮されました。
Four Keys の計測結果を改善に活かすためのプロセス
先ほど2つ改善の例をあげました。しかし、具体的にどのような改善を行うべきかは開発チームによりけりです。
次は私たちのチームがどのようなプロセスで、 Four Keys の計測結果を把握し、次の改善へ活かしていくのかを紹介したいと思います。
1. Four Keys のボトルネックの Pull Request を特定し、個別に振り返る
会計Plusではスクラム開発を採用し、毎週「レトロスペクティブ」という振り返りミーティングを実施しています。そこで次の改善のためのアクションを決めています。
レトロスペクティブの冒頭10分を使って、チームで Four Keys の値を確認するようにしました。
悪化している部分や思ったように改善していない部分があれば、下記のように Findy Team+ 上でPull Request毎の計測値を確認することができるので、1つ1つのPRを深掘りながらボトルネックの特定や改善可能な点をチームメンバーと共有します。
2. 次のアクションを決定
振り返った内容に基づいて、改善のためのアクションを決定します。
例えば「レビューのやり取りが長く続いたため Approve がなかなか付かなかった」という問題があった場合、メンバーにヒアリングしなぜレビューのやり取りが長引いたのかを深ぼっていきます。
深ぼっていくと「ここの関数が複雑だったのでプランニングの段階で先に話し合っておけば良かった」「実装イメージの認識がメンバー間で異なっていた」などの具体的な課題感が出てくるのでそれに対して、
「難しそうな実装についてはチーム内でモブプロ実施し、設計方針に合意を取りながらコードを書いてみる」
というようなアクションを決定します。
そして、アクションがうまくいっているかどうかをまた次のレトロスペクティブで Four Keys の値を見て確認し、効果が感じられなかった場合は次のアクションを考えるということを繰り返します。
3. デイリースクラム(朝会)の中でレトロスペクティブで決めたことをチームメンバーで確認する
せっかくアクションを決めても忘れてしまっては何も改善しません。
レトロスペクティブで決めたアクションの確認をデイリースクラムのアジェンダとして組み込んで定期的に状況を確認するようにしました。
まとめ
開発生産性の改善もアプリケーションのパフォーマンスチューニングと同じく、計測した上でボトルネックを改善するのが大事だと感じました。
これからも Four Keys を活用しながら、さらなる生産性の向上を目指していきたいと思います。ぜひ、皆さんのチームでも Four Keys の導入を進めてみてはいかがでしょうか。
おまけ. その他の Four Keys に良い影響を与えている取り組み
下記は Four Keys を元にした改善活動を始める前から会計Plusチームで取り組んでいることになりますが、それも併せて2つ紹介させていただきます。
1. Slack のコマンドからデプロイが行えるようになっていること
チームでは、Slack上でデプロイが簡単に行えるようにコマンドを作成しました。
これにより、以前は GitHub 上でタグを打つことでデプロイしていたのですが、その手間が軽減され、デプロイの頻度が向上しました。
2. フィーチャーフラグの導入
フィーチャーフラグとはソフトウェア開発において新機能や変更を段階的に導入・無効化するための方法です。
フィーチャーフラグを導入することで、リリース前のコードも master ブランチにマージできるようになりました。これにより、頻繁にデプロイできるようになりました。
また、リリースの際はフィーチャーフラグを切り替えるだけで良いので機能のリリース時のリスクも低減されました。
※ フィーチャーフラグの詳細や会計Plusで導入した背景は チームをスケールさせるのに近道はない。でもやるしかないんだ。に書かれています。
最後に
マネーフォワードではエンジニアを募集中です。
この他にも様々な取り組みをおこなっていますので興味を持っていただけましたら、ぜひカジュアル面談などで一度お話して雰囲気を知ってもらえれば幸いです。
また、マネーフォワードの関西拠点のメンバーが今月下記のイベントに登壇しますので、Kotlin や JavaScript に興味ある方は是非ご参加ください。
