はじめまして、シンクロ・フード開発部の眞田です。
今回、シンクロ・フードにおける開発生産性向上活動の一環として開発部 各開発チームのFour Keysを計測しパフォーマンスレベルを比較しました。Four Keysの指標値やデータの分布などを比較していくと各開発チームごとの差異が見られ課題も見えてきましたので、ご紹介しようと思います。
Four Keysの概要
Four Keysは、GoogleのDevOps Research and Assessment（DORA）チームの研究・調査により示されたソフトウェア開発チームのパフォーマンスを表す指標で、4つの指標と指標それぞれに対する4つのレベルで開発チームのパフォーマンスレベルを分類するものです。最近の開発生産性に関する議論ではFour Keysがよく参照されており、さまざまなソフトウェア開発企業でFour Keysが開発生産性の指標として採用されています。
開発チームのパフォーマンスを見るための4つの指標は下記となります。
| 指標 | 内容 |
|---|---|
| デプロイ頻度 | 本番環境への正常なリリースの頻度 |
| 変更リードタイム | 本番環境稼働への修正着手（First Commit）からリリースまでの所要時間 |
| 変更失敗率 | 本番リリースの内で障害が発生する割合（%） |
| サービス復元時間 | 本番リリースで発生した障害から回復するのにかかる時間 |
上記の各指標の値がどの範囲に含まれるかにより組織・開発チームのパフォーマンスをElite / High / Medium / Lowというレベルに分類します。
| Elite | High | Medium | Low | |
|---|---|---|---|---|
| デプロイ頻度 | 適時（1日複数） | 1回/日〜1回/週 | 1回/月〜1回/6ヶ月 | 1回 / 6ヶ月以下 |
| 変更リードタイム | 1時間以内 | 1日 〜 1週間 | 1ヶ月 〜 6ヶ月 | 6ヶ月以上 |
| 変更失敗率 | 0% 〜 15% | 16% 〜 30% | 16% 〜 30% | 16% 〜 30% |
| サービス復元時間 | 1時間以内 | 1日以内 | 1日〜1週間 | 6ヶ月以上 |
- Four Keys参考URL：エリート DevOps チームであることを Four Keys プロジェクトで確認する
Four Keysを用いる理由づけとしては一般的に下記のようなことが言われており、シンクロ・フードでの開発生産性を考えるスタート地点として適切であると判断し、今回Four Keysを計測することとしました。
- ビジネス面への好影響・関連が示されている
- Four Keysを提案したレポートにて企業の競争優位性とFour Keysに優れた開発チームを持つことの関連性が確認されているため、開発会社として取り組むべき意味付けや意義がビジネスサイドにも理解してもらいやすい
- エンジニアにとっても、Four Keysは最近のソフトウェア開発におけるトレンドに沿っているので、改善に取り組むことの意味を理解してもらいやすい
- 車輪の再発明をしなくて済む
- 多くの関係者が長期間に携わった（過去 7 年間で3万人を超える世界中の専門家が参加している）成果である
- Four KeysはアジャイルやDevOpsなど最近のソフトウェア開発に適用しやすい指標である
- 社内・社外の開発チームとの比較ができる
- Four Keysのパフォーマンスレベル「Elite」「High」「Medium」「Low」により、他の開発チームと比較して自分達がどのレベルにいるのかを客観的に把握できる
- それぞれの組織や開発チームに適合する開発生産性指標は様々あると思われますが、まずはFour Keysから始めれば良いのではないかと思われる
今回の計測におけるFour Keys定義
インターネットで調べてもFour Keysの指標値の算出に関する厳密な定義はされておらず、Four Keysを採用する開発企業にて少しずつ異なる定義でFour Keysの計測がされているようです。今回、シンクロ・フードでのFour Keys計測における各指標値の定義は下記としました。（集計期間は2023年4月から2023年12月としています）
| 指標 | 定義 |
|---|---|
| 変更リードタイム | 該当期間に本番リリースされたチケットに紐づく（複数の）PullRequestの中で最も古いCommit（First Commit）のタイムスタンプから本番リリースのタイムスタンプまでの営業日日数 |
| デプロイ頻度 | ある週内で、日毎に本番リリースされたチケット件数の中央値 |
| 変更失敗率 | 2023/4 - 2023/12に本番リリースされた全てのチケット件数中でバグ対応と分類されたチケット件数の割合 |
| サービス復元時間 | 2023/4 - 2023/12に発生したバグ対応チケットについて、修正に要した日数（チケット起票日から本番リリースまでの日数）の中央値 |
- ここでの変更失敗率・サービス復元時間はFour Keysとしては参考値として捉えています。 Four Keysの定義に基づくと、該当期間の本番リリースに起因して発生したバグに対する各指標値を算出すべきですが、正確な記録が現状では残っていないためチケット管理システムにバグとして記録されているものから集計できる値を算出しました。
Four Keys計測のためのデータ取得
シンクロ・フード 開発部では、ソースコード管理にはGitHub Enterprise、開発チケット管理には社内で内製した独自システムを使用しており、今回のFour Keysの算出に際してはそれぞれから必要な情報を抜き出し、各指標値を算出しました。
チケット管理システムからの情報取得
チケット管理システムには、チケット登録日、本番環境リリース日などが管理されており、Four Keys計測のためにチケット管理システムからは下記の情報を取得しました。
- チケットの起票日
- チケットの本番環境リリース日
- 対象期間における本番リリースされたチケット数
- 対象期間にバグとして登録されたチケット数
GitHubからの情報取得
GitHub Enterpriseからは、チケットに紐づけている複数のPullReqestに記録されてるCommitから最も古いものを特定し、そのタイムスタンプをチケットのFirst Commitタイムスタンプとして取得しました。（GitHubからのデータ取り出しにはGitHub API (GraphQL)を用いました）
シンクロ・フードの開発チーム
シンクロ・フードにはサービスの開発・運用保守を行っている開発チームが大きく4チームあり、各チームの概要は下記のようになります。今回のFour Keysの計測では、それぞれのチームそれぞれで指標値を算出しました。
| チーム | 担当サービス |
|---|---|
| チームA | 求人飲食店ドットコム関連サービスの開発・運用保守 |
| チームB | 求人飲食店ドットコムサービスに関連する業務システムの開発・運用保守 |
| チームC | 飲食店ドットコムサービスの開発・運用保守 キッチンカーやアパレルカーなど移動販売事業者に、出店場所の提供や出店・運営の支援サービスであるモビマルの開発・運用保守 |
| チームD | 店舗デザイン.COMなど飲食店出店時の内装を依頼するデザイン会社を探すサービスの開発・運用保守 |
シンクロ・フード各開発チームのFour Keysによるパフォーマンス比較
開発チームのFour Keysパフォーマンスレベル
各開発チームのFour Keys指標値を算出した結果は下記となりました。
| チーム | 変更リードタイム | デプロイ頻度 | 変更失敗率 | サービス復旧時間 |
|---|---|---|---|---|
| チームA | 9 営業日 | 1回/日 | 24% | 1 営業日 |
| チームB | 5 営業日 | 1回/日 | 15% | 3 営業日 |
| チームC | 7 営業日 | 3回/日 | 16% | 10 営業日 |
| チームD | 7 営業日 | 1回/日 | 20% | 2 営業日 |
この各開発チームのFour Keys指標値から判別されたパフォーマンスレベルは、下記のように全開発チームHighとなりました。Four Keysのパフォーマンスレベルをみるだけでは各開発チームの違いが見られませんでした。
Four Keysの定めるEliteパフォーマンスレベル以外の各レベル間の指標値レンジ幅が大きいため、開発チーム間の違いが現れにくくなっているように感じます。加えて、レンジの指標境界に隙間があり、指標値が隙間に位置する場合にはどのレベルかの判断しにくかったです。今回、シンクロ開発チームでも指標値がレベルの隙間に位置する場合もありましたが、下位のパフォーマンスレベル境界値との差を考慮してHighと判断している箇所があります。
| チーム | 変更リードタイム | デプロイ頻度 | 変更失敗率 | サービス復旧時間 |
|---|---|---|---|---|
| チームA | High | High | High | High |
| チームB | High | High | High | High |
| チームC | High | High | High | High |
| チームD | High | High | High | High |
インターネット上には自社開発チームのFour Keysパフォーマンスを公開されている企業も多くあり、その中にはある指標値に関してはEliteパフォーマンスレベルであったという報告も散見されます。シンクロ・フードはパフォーマンスレベルとしては総じてHighであり悪い結果ではないと考えられますが、まだまだパフォーマンス改善の余地があると感じました。
とはいえ、リードタイムのEliteレベルの定義をみると、修正着手から本番リリースまでの時間が1時間以内となっており、シンクロ・フードの開発フローや開発環境を鑑みるとその実現はあまり現実的ではないと捉えています。このことから、一律にEliteレベルを目指すというのではなく、適宜Four Keysの指標値を改善していくというのがシンクロ・フードとしての適切な改善スタンスだろうという見解になっています。
Foue Keys指標値による比較
パフォーマンスレベルは全ての開発チームでHighレベルとなりましたが、各開発チームでの違いを見てみるためにFour Keys各指標値を直接比較してみました。
各チームのFour Keys指標値（再掲）
| チーム | 変更リードタイム | デプロイ頻度 | 変更失敗率 | サービス復旧時間 |
|---|---|---|---|---|
| チームA | 9 営業日 | 1回/日 | 24% | 1 営業日 |
| チームB | 5 営業日 | 1回/日 | 15% | 3 営業日 |
| チームC | 7 営業日 | 3回/日 | 16% | 10 営業日 |
| チームD | 7 営業日 | 1回/日 | 20% | 2 営業日 |
Four Keys指標値を横並びで比較すると4チームでの課題が見られます。
| チーム | Four Keysによる評価 |
|---|---|
| チームA | 4チーム中で最もパフォーマンス改善の必要性があるように見える 変更リードタイム・変更失敗率・デプロイ頻度が他のチームの中では低いが、サービス復元平均時間は最良 |
| チームB | 4チーム中ではパフォーマンスは良好 変更リードタイム・変更失敗率が4チーム中最良 |
| チームC | デプロイ頻度は４チーム中で最良、一方でサービス復元時間については最下位 サービス復元時間についてパフォーマンスが課題と見られる |
| チームD | 4チームの中ではいずれの指標もパフォーマンスとしては中位 ただし、変更失敗率が課題と見られる |
より詳細な比較
さらに、Four Keys指標値だけでなく、各開発チームのリードタイム・デプロイ頻度データの分布からチームパフォーマンスを比較しました。
変更リードタイムの度数分布
各開発チームのリードタイムの度数分布は下記のようになりました。横軸は変更リードタイム（営業日）で、縦軸は度数です。変更リードタイム度数分布の評価観点としては、原点付近に度数が集まっている方がパフォーマンスが良好（全体的に変更リードタイムが短い）であると捉えられるため、中央値と80パーセンタイル値がなるべく小さい方がパフォーマンスが良好という評価をしました。
デプロイ頻度の週毎の分布
各開発チームのデプロイ頻度の分布は下記のようになりました。横軸は2023年4月から12月までの各週で、縦軸は該当週の各営業日のデプロイ回数の中央値です。評価にはデプロイ頻度の平均値と標準偏差を算出し、平均値がより大きく（デプロイ頻度が多い）、標準偏差の小さい（平均値付近の頻度で安定してデプロイできている）ものをパフォーマンスが良好という評価をしました。
| チーム | デプロイ頻度平均値 | デプロイ頻度標準偏差 |
|---|---|---|
| チームA | 0.86 | 0.68 |
| チームB | 0.74 | 0.69 |
| チームC | 3.37 | 1.22 |
| チームD | 1.47 | 0.88 |
このグラフ分布から変更リードタイム・デプロイ頻度の状況をまとめると下記のようになりました。
| チーム | 変更リードタイム評価 | デプロイ頻度評価 |
|---|---|---|
| チームA | リードタイム2週間以内が全体の半数 1.5ヶ月以上要している要件が10%強 |
平均的に週0.2〜1.6回程度のデプロイ頻度 |
| チームB | リードタイム1週間以内が全体の半数 1.5ヶ月以上要している要件は5%強 |
平均的に週0〜1.4回程度のデプロイ頻度 |
| チームC | リードタイム1週間強が全体の半数 1.5ヶ月以上要している要件は5% |
平均的に週2〜4回程度のデプロイ頻度 |
| チームD | リードタイム1週間強が全体の半数 1.5ヶ月以上要している要件は10%弱 |
平均的に週0.6〜2.4回程度のデプロイ頻度 |
変更リードタイムのチーム比較
変更リードタイムのデータの分布から、チームBの中央値が他のチームと比較して最も良く（80パーセンタイルも2番目に良い） 、次いでチームC、チームD、チームAというパフォーマンス順であるように見えます。
チームBの開発内容としては、比較的規模の大きな案件を定常的に数件開発しつつ細かい機能改修や不具合対応などを多く対応しており、前者はリードタイムが長い傾向にありますが後者のパフォーマンスが良好であることが現れていると考えています。チームAに関しては、サービスとしては機能も多くコードベースも大きいことから、影響範囲も大きくなりがちで改修・テストに時間がかかりリードタイム・デプロイ頻度に影響しているように思われます。チームCとチームDは中央値は同じですが、80パーセンタイルはチームCの方が小さいため、チームDよりもチームCの方パフォーマンスが良いと判断しています。
デプロイ頻度のチーム比較
デプロイ頻度からは、チームCが最もパフォーマンスが良い結果となりました、その他のチームはFour Keys指標値のみでの評価では同じように見られますが、週単位でのデプロイ回数データをみると違いが見られ、パフォーマンス順は、チームC＞チームD＞チームA＞チームBであるように見えます。（各チームの標準偏差は 0 .7〜1.2となっており、データの分布は平均値の±1営業日程度の範囲に収まっている状況であることがわかりました）
チームCは、サービスとしては若く多くの新規機能の追加を優先的・精力的に行なっているためリリース頻度が他のチームと比較して多くなっています。また、各機能の開発規模も小さく、細かいサイクルで開発を行なっているということもデプロイ頻度に影響していると思われます（ちなみに、Four Keysのサービス復旧時間が長く（10営業日）なっており他のチームと比較してパフォーマンスとしては良くありませんが、これは影響度の小さい・緊急度の低い不具合対応よりも新機能開発を優先しているという状況からきています）。チームBは2023年度前半はデプロイのない週も多く見られましたが、10月以降デプロイ頻度が上がってきている様子が伺え、チームAと同等レベルになってきています。
注：この比較では、リードタイム・デプロイ頻度の観点のみでシンクロ開発チームのパフォーマンスレベルを考察しています。FourKeysの残りの2つの指標：変更失敗率・サービス復元時間について、今回算出した指標値はFour Keysの定義からは外れていると思われるため、今回はこれらの指標では評価しませんでした。
まとめ
シンクロ・フード開発部 各開発チームのFour Keysを計測した結果、Four Keysの定義するパフォーマンスレベルとしてはどの開発チームもHighレベルと判断されました。ただ、Four Keysの指標値やデータの分布などを細かく比較していくと、各開発チームごとの状況の違いから差異が見られ、それぞれが異なる課題を持っていることが見えてきたと思います。
この結果に基づいて、今後は下記のような活動を予定しています。これらの改善活動を通じて新しい情報・知見などが得られましたら、またこのブログで紹介したいと思います。
1. Four Keys を開発生産性指標とした改善活動
開発チームにおけるFour Keys を開発生産性指標のうち、まずは変更リードタイム・デプロイ頻度にフォーカスして改善活動の実施していく予定です。
2. 企画チームを巻き込んだ改善活動
シンクロ・フードにおける開発では、Four Keysで計測される指標値は開発チームの作業のみならずサービスの企画を立案しているチームの作業も関わってくるため、開発チーム・企画チームが協調して改善活動をしていく必要があります。変更リードタイムは、企画チームの受入テストの時間・企画チームとのコミュニケーション・チケットの作業規模などにも依存していると考えられるため、企画チームを巻き込んだ改善が必要となると考えています。
3. 各開発チームへの横展開
改善活動はまずは一つの開発チームにて実施していく予定ですが、そこで成果が得られた改善活動は他の開発チームにも横展開していきます。
4. Four Keysを継続的・自動的に集計できる仕組みの整備
今回のFour Keys計測では、継続的・自動的に集計する仕組みは用意していません。開発・企画メンバーが常にFour Keysを収集・閲覧できる仕組みを構築していく予定です。
