ソフトウェア開発の指標でFour Keysも計測できるFindy Team+の開発チームは何から改善を始めたか

ソフトウェア開発チームのパフォーマンスを測る指標、それがFour Keysです。「Four Keysはすぐに上がる数字ではなく、地道で本質的な取り組みをしながら、数値を見ることで自分たちはうまくやれていることを確認するもの」と語るのは、Findyのプロダクト開発部でエンジニアリングマネージャーを務める栁沢正二郎さん。

栁沢さんが開発に携わっているFindy Team+は、エンジニア組織がパフォーマンス改善に利用できるSaaSです。GitHubのリポジトリやJiraのイシュートラッキングなどを解析して、エンジニアやチームのパフォーマンスを数値化できます。2022年8月には、Four Keysについても可視化・分析できる「DevOps分析」機能をリリースしました。

注目したい点は、Findy Team+の開発組織自身がFindy Team+をドッグフーディングしていること。つまり、Four Keysなどの指標を計測するSaaSを開発・提供するだけでなく、指標をもとにした開発チームの改善も実践しています。今回はそのような視点から、指標をサービス改善に生かす上での勘所を栁沢さんに聞きました。

Four Keysは地道で本質的な取り組みを可視化する

Findy Team+がFour Keysを採用したのは、世の中のニーズを実感したためだと言います。「開発・運用の活動の中で、見えづらいアクティビティを数値化したいというニーズはもともとありました」と栁沢さんは説明します。これまでソフトウェア開発の現場では、インシデント数やバグ数といった品質に関わる指標を取っていました。しかし、体系立てて使える方法論がなかなか見当たらなかったのです。

Four Keysは、GoogleのDORA（DevOps Research and Assessment）チームの研究から生まれた考え方で、「デプロイの頻度（deployment frequency）」「変更のリードタイム（lead time for changes）」「変更障害率（change failure rate）」「平均修復時間（time to restore service）」の4つを指標とします。

参考: エリートDevOpsチームであることをFour Keysプロジェクトで確認する - Google Cloud公式ブログ

このうちデプロイの頻度と変更のリードタイムは速度（velocity）の指標です。一方、変更障害率と平均修復時間は、ソフトウェアの安定性（stability）を表します。つまり、密接に関係する2種類の指標を同時に可視化しているため、Four Keysの各指標を継続的に向上させることは、チームが健全性を保ちながら能力を持続的に向上させていることを意味します。

このように複数の指標を体系立てて整理し、チームの改善に結びつけられるところが新しく、Findy Team+でも利用企業からそういった動向をキャッチして、サービスに取り入れました。同社では、Four Keysはハックで数値を上げることは難しく、地道で本質的な取り組みの成果を可視化できる指標だと捉えています。

メトリック	エリート	高	中	低
デプロイの頻度	オンデマンド （1日に何度も）	1週間から1カ月に1回	1カ月から半年に1回	半年以上の間隔
変更のリードタイム	1時間未満	1日から1週間	1カ月から半年	半年以上
平均修復時間	1時間未満	1日未満	1日から1週間	半年以上
変更障害率	0％〜15％	16％〜30％	16％〜30％	16％〜30％

▲ Four KeysについてGoogle DORAがまとめた4ランクのプロファイルより（上記参考リンクを参照）

開発組織にとってパフォーマンスの指標を可視化する意味

Four Keysの特徴はいくつかあります。まずは前述したように、速度と安定性という両立させなければならない指標をバランスよく見ることができます。

栁沢さんも「『推測するな、計測せよ』という言葉があるように、指標があることで事実を把握して、生産性を向上する取り組みが可能です」と語ります。その際には「生産性の高さにつながるロジックがしっかりしていないと、気分で戦略を決めることになってしまいます。そうならないようパフォーマンスを可視化し、同じ数値を見て善し悪しを把握することが大事です」（栁沢さん）。

パフォーマンスの指標として機能させるには、チームが納得できるような合理性が重要です。例えば「コミット数」のように計測はしやすいものの、パフォーマンスを測るには開発現場の実情にそぐわない指標もあるなかで、Four Keysが採用するデプロイの頻度や変更のリードタイムは「より合理的な指標」だと栁沢さんも考えています。

また、もともとGoogleでDevOpsを研究するチームの成果であることから分かるように、DevOpsとの相性の良さにも特徴があります。チームでDevOpsを推進し、開発と運用が健全に噛み合っていれば、Four Keysの数値も改善されます。栁沢さんの経験としても「自動テストのカバレッジを増やし、CI/CDを整備し、インフラ基盤の構築を進めることで、1年を通してみるとFour Keysは向上する」とのことです。栁沢さんの開発チームでの取り組みはこの後で紹介します。

そして、アジャイル開発のプラクティスとも相性が良いところがあります。デプロイの頻度や変更のリードタイムの改善により、バッチサイズを小さくし、イテレーションを小刻みに行うようになります。「継続的デリバリーや可視化を重視するといった点でも、アジャイル開発とFour Keysは親和性がある」と栁沢さんは語ります。「最近は、書籍『チームトポロジー』のストリームアラインドチームのようにワンチームでデリバリーまで一気通貫で実施する風潮もありますが、そういう考え方とも相性がいい」とのこと。

GoogleのDORAチームによれば、Four Keysはビジネス組織のパフォーマンスや社員のエンゲージメントとも相関関係があります。つまり組織の健全性、社員の満足度にも影響する指標だと言えるでしょう。

プルリクエストの粒度から始まるチーム改善の取り組み

ここまでFour Keysなどの指標をもとに生産性を改善することの重要性を見てきましたが、実際にFindyの開発チームでは、そういった指標をどのように用いて改善に取り組んできたのでしょう。Findy Team+となるサービスを2020年4月にベータリリースした当時から、Four Keysを導入した2022年初頭、そして2022年末までに、大きく3つのステップがありました。

当初の問題点としては「大きなプルリクエストが常に数十件は溜まっていた状況でした」と柳沢さんは振り返ります。それだけでなく「ユニットテストもあまりなく、セキュリティパッチやライブラリのパッチも当たっていない。リリース頻度も週1回が限界。全てにおいて遅い状況でした」（栁沢さん）。

そのため、最初のステップは「プルリクエストの粒度を小さくする」ことでした。施策を進めて「バッチサイズを小さくして開発するベースが少しずつできてきた」ことで、プルリクエストをクローズするまでの時間も短くできたと言います。「デプロイの頻度を高める」という目標も、個々の開発者の目線では「プルリクエストの粒度を小さくしよう」と考えた方が分かりやすかったかもしれないと栁沢さんは振り返っています。

また、ライブラリアップデートを容易にするため、ユニットテストを増やして品質が守られるようにしました。ライブラリのパッチの適用を進める上で、さらにデプロイ頻度の向上にも、ユニットテストの充実は欠かせません。「品質を担保できないと、デプロイの心理的安全性が下がってしまいます」（栁沢さん）。

アーキテクチャを見直してインフラの自動化を図る

2番目のステップは「フロントエンドとバックエンドのアーキテクチャを分ける」ことでした。当初は開発チームもそれほど大きくなかったので、フロントエンドとバックエンドが同じサーバーで動いていました。

しかし、チームの人数が増えてくると「APIと画面設計が密結合で、つらい状況になりました。そこでプロダクトのアーキテクチャを疎結合になるよう変更したところ、それぞれ独立して修正できるようになりました」（栁沢さん）。これにより、リリース頻度も週1回から毎日に向上したそうです。

3番目のステップは「CI/CDやインフラの整備」です。CI/CDやインフラには以下の課題がありました。

• デプロイやロールバックに時間がかかる
• デプロイに手間がかかる
• 障害に気づきづらい

この解決のため、まずインフラをコンテナベースに変更し、その上でテストとデプロイの自動化を進めました。「E2Eテストの導入、システムモニタリングやアラート、オンコール体制の整備などは『変更障害率』や『平均修復時間』に効いてくるので、安定性を保ちつつ速度を高めることができ、Four Keysの各指標が上がっていく実感がありました」（栁沢さん）。

これで1日2回のリリースを実現。フロントとバックエンドそれぞれなので、1日計4回のリリースになります。

こうした3つのステップを2年かけて実施するうちに、開発チームメンバーも15人ほどに増えましたが、指標の数字は引き続きチームで毎週見て改善を進めたと言います。「変化が数字で分かるのはよいことですが、数字だけにとらわれず、チームで話し合いました」と栁沢さんは語ります。「ただ数字を上げるだけでなく、ベストプラクティスを取り入れ、自動化、省力化を進めて、価値あるところに集中できることが重要です」（栁沢さん）。

▲ Findy Team+で「デプロイ頻度」のグラフに見るFindy開発チームの改善状況と関連施策

組織をスケールできる基盤に指標をつなげる

ここまで述べてきたように、Findyが開発組織としてチームで取り組んできたのは「プルリクエストの粒度を小さく」「アーキテクチャを疎結合に」「ユニットテストを充実させる」「CI/CDで自動化を進める」といった普遍的な施策でした。その後でFour Keysの指標が見れるようになりましたが、その改善にも「『それはそうだよね』と思うような普通の施策を『やりきる』ことが大事だった」と栁沢さんは話します。Four Keysは小手先の施策ではなく、本質的で普遍的な改善で改善される指標だからでしょう。

Four Keysを導入してからも、何か施策を実施しても指標に変化が見られず、横ばいになることは基本的によくあると言います。施策を打っても改善が見られない場合は、「いいやり方がないか話し合う」ことで施策の改善を進めます。また、リファクタリングのように短期的にはFour Keysの指標に直接反映されない施策もありますが、栁沢さんたちは「放置すれば長期的にマイナスだと判断して、リファクタリングに取り組んだ」そうです。

このようにFour Keysを指標として取り入れることで、「組織をスケールできる基盤ができあがった」と言います。開発チームが大きくなっても開発のスピードが落ちることはなく、またチーム開発の「風土」にも良い影響を与えているようです。新たにチームにジョインしたメンバーから「レビューが早い」と称賛されたというのはそれを表していると言えるでしょう。「コードレビューに時間がかかると、開発者の満足度が下がると言われています。作ったものがすぐマージされれば、次のタスクにすぐ取りかかることができます」（栁沢さん）。

Four Keysはチーム全体で取り組んだ結果として向上する

Four Keysは、速度と安定性を全体的に見る指標です。改善にあたって、どの順番・優先度で取り組めばよいのでしょうか？ 栁沢さんは「基本はデプロイ頻度の改善でしょう」と語ります。

「デプロイ頻度が上がると、変更のリードタイムも短縮されます。また、その改善を進める中で、変更障害率と平均修復時間が上がらないように注意します。もし後者の指標が上がってしまうなら、先にテスト改善などで品質向上を進めたり、障害に早く気づいて切り戻せるよう障害監視を強化したり、切り戻し速度を向上させたりしたほうがいいでしょう」（栁沢さん）。

安定性が担保されているならデプロイ頻度を上げる。もし安定性がよくないなら、テストなど改善をしてから次に取り組む──その判断にFour Keysは使えるわけです。

ひとつ気になることは、チームのパフォーマンスを指標にするということは、人事評価に使われることもあるのではないかという点です。栁沢さんは「Four Keysの思想としてチーム全体のため、みんなの生産性を上げる方向で使ってほしい。個々人の評価に使うと、数字を上げるハックが横行してしまうおそれがある」と指摘します。

Four Keysはパフォーマンスを競うものではなく、チームを改善するための指標です。プルリクエスト粒度の小ささ、ユニットテストの充実、テストとデプロイの自動化、そしてチームの風土醸成と、チーム全体で取り組んだ活動の成果としてFour Keysの指標は向上します。

「Four Keysの知識が広まって有効に活用されれば、チームの生産性だけでなく健全性や、メンバーの満足度も向上するでしょう。そしてプロダクト全体が良くなり、最終的にユーザーに価値を届けられる」。それが最も大事なことだと栁沢さんは考えています。

取材・執筆：星 暁雄（ITジャーナリスト、@AkioHoshi）
編集：はてな編集部

栁沢 正二郎（やなぎさわ・しょうじろう） nipe0324

ファインディ株式会社 プロダクト開発部 エンジニアリングマネージャー
ベンチャー企業複数社を経て、2021年にFindyに入社。Findy Team+の開発・運用に携わり、現在はエンジニアリングマネージャーとしてサービスに携わる。