はじめに
はじめまして、食べログシステム本部のDeveloper Productivityチームでテスト自動化ユニットのリーダーをしているhagevvashiです。 2022年9月29(木)に緊急Ques 「食べログの品質ダッシュボード」という勉強会に私を含む食べログのエンジニアが登壇しました。
QuesとはSoftware品質保証に関わるQAエンジニアの活性化を目的としたQA専門イベントです。今回は特別回として「食べログの品質ダッシュボード」と題して、ソフトウェア開発に関する品質を可視化し改善する取り組みについての勉強会を開催しました。 勉強会の様子については本勉強会の発起人である荻野が書いたレポートをご参照ください。
本記事は私の発表である「マトリクス型組織の導入後の変化を定量的に捉える」の後半パートを文字起こししたものです。発表概要としては、食べログの開発プロセス品質について、実際の開発プロセスの改善事例をもとに品質の変化を定量的に分析した結果の紹介になります。後半パートでは、改善による変化を定量的に捉えるために、開発チケットやPull Requestのデータの集計・可視化し、分析した結果を紹介しています。本発表は前後半で分かれており、具体的なマトリクス型組織の構成や取り組みについては前半パートで話していますのでご興味のある方は関戸の記事をご覧ください。
本記事は、発表に興味があったものの参加できなかった方や、テキストで読みたい方向けに作成しています。発表スライド、YouTube動画やTogetterまとめを作成していますので、実際の講演や当時の反応を見たい方はこちらも合わせてご確認いただければ幸いです。
GitHubデータを用いた開発プロセス改善の取り組みの定量化
食べログのDeveloper Productivityチームに所属しているSoftware Engineer in Test (SET)のhagevvashiと申します。SETの活動としてテスト自動化の推進を行っております。 そのテスト自動化については「食べログのソフトウェアテスト自動化デザインパターン」というタイトルで、過去にもこのQuesで発表しております[1]。
よろしくお願いいたします。
それでは改めてここまでの発表のおさらいをしていきたいと思います。
本発表の主題は「マトリクス型組織を導入して、開発プロセス改善に取り組んできたが、改善による変化を定量的に捉えられるか？」というものでした。
開発プロセス改善の内容として「リリース数」の増加、「リリースサイズ」の縮小、そして「障害数」を増やさない取り組みを紹介しました。
後半パートの目的は、改善活動による変化の実感をデータを用いて実証することです。
この実証のため、関戸のプロジェクトをスコープとしてPoCを実施し、分析しました。
各測定対象のメトリクスは以下のように設定しました。
| 測定の対象 | メトリクス | 開発チームの取り組み | 期待する効果 |
|---|---|---|---|
| リリース数 | Pull Requestのマージ数 | 小さく高速なPDCAサイクル | 増加 |
| リリースサイズ | 実装・レビュー・テストの合計日数（開発チケット上の記録から取得） | ABテストを活用した小さな改善の繰り返し | 縮小 |
| 障害数 | Pull Requestのリバート率※ | 非機能要求の早期の洗い出しとノウハウ共有 | 減少 |
※障害数のメトリクスについての補足説明
今回の取り組みではリリース数を増やすことを目的としています。しかしリリース数が単純に増えるだけだと、障害数も比例して増えてしまいます。リリース数が増えても、障害数が増えるのは嬉しくないですよね。リリース数の増加に対して障害数を抑えるためには障害率を下げる必要があります。そのため、障害率をメトリクスとしました。また、PoCのフェーズでは精緻な数値を算出することよりも形になるまでのスピードを重視したため、Pull Requestのリバート率を障害率の代替メトリクスとして利用することにしました。
1.28倍に増加したリリース数。Four Keysの分類ではElite
それではリリース数としてPull Requestのマージ数の分析結果をお見せしていきます。
分析の目的 改善活動によりリリースが増えたことの確認が分析の目的です。
評価指標
実測値は年毎のリリース数です。
計測方法はPull Requestのマージ数となっております。
今回の取り組みでは業界標準での食べログの立ち位置を知るため、Four Keysの統計データとの比較を行いました[2]。Four Keysでリリース数に該当する指標はDeployment frequencyです※。この指標が1日1回以上であるとEliteに分類されます。また、Highの基準は1ヶ月に1回以上です。
※Pull Requestのマージ数をFour KeysのDeployment frequencyと比較することについての補足説明
Four KeysのDeployment frequencyのメトリクスはデプロイ数です。食べログでは1回のデプロイで複数のPull Requestをマージしてリリースしています。1回のデプロイでリリースされるPull Requestの数が1に近いほど、デプロイ数の代替メトリクスとしてPull Requestのマージ数を利用する妥当性は高くなります。それぞれのプロジェクトにおける1回のデプロイあたりのPull Requestのマージ数を標本として抽出し、各年度ごとに標本集団の平均値を算出したところ、0.7から0.9を推移していました。そのため、Pull Requestのマージ数をデプロイ数の代替メトリクスとして利用し、Four KeysのDeployment frequencyと比較することにしました。
結果 改善活動によりリリース数が1.28倍に増加しました。またFour Keysの分類ではEliteでした。
1/2以下に縮小したリリースサイズ
続いてリリースサイズとして実装・レビュー・テストの合計日数の分析結果をお見せしていきます。
分析の目的 リリースサイズが小さくなったことの確認が分析の目的です。
評価指標
実測値はリリースサイズです。
実装・レビュー・テストの合計日数をそれぞれのプロジェクトに対して計算したものを標本として抽出し、各年度ごとに標本集団の中央値を算出しました。
業界標準としてのFour Keysには該当項目がございませんでしたので比較は行っておりません。
結果 リリースサイズが1/2以下に削減されました。
Eliteの中を推移している障害率
最後に障害率について代替メトリクスであるPull Requestのリバート率を分析した結果をお見せいたします。
分析の目的 目的は2つあります。1つ目は、Pull Requestのリバート率が業界標準でのEliteの中を推移していることの確認です。もう1つがPull Requestのリバート率が下がったことの確認です。
評価指標
計測方法はPull Requestのリバート率です。
業界標準のFour KeysではChange failure rateが該当しまして、その基準はEliteが15%まで、Highが16%から30%までとなっております。
結果 Eliteの中を推移していることが分かりました。また、2022年のPull Requestのリバート率が2021年に比べ減少したことが分かりました。
改善活動によってプロセス品質が向上したという仮説がデータ分析で実証できた
ここまでの分析結果をまとめると、「リリース数」の増加、「リリースサイズ」の縮小、そして「障害数」を増やさない取り組みという開発プロセスの改善によってプロセス品質が向上したという仮説がデータ分析によってサポートできることがわかりました。
後半パートの目的は、前半パートの最後のフレーズ「リリース数の増加や効果を見ながらの検証、職種を超えた一体感など、マトリクス型組織の導入による変化は実感できている」を、データを用いてサポートすることであり、今回の分析ではこれを実証できたことになります。
では、分析によるサポート結果をおさらいしましょう。
リリース数は1.28倍の増加でした。リリースサイズは1/2に縮小されました。障害率の参考として用いたPull Requestのリバート率はEliteの中を推移していました。
テストからリリースまでのリードタイムに改善の余地があることが分析により判明
データを活用していく取り組み自体の目的は、改善活動による変化の実感を実証することだけではなく、開発プロセスのボトルネックを見つけてさらなる改善の余地を探ることにもあります。
分析の目的 今まで挙げたもの以外にも指標を探索し、開発プロセスの改善の余地を見つけることが分析の目的です。
評価指標
実測値はテストからリリースまでのリードタイムです。
テストからリリース完了までのリードタイムをそれぞれのプロジェクトに対して計算したものを標本として抽出し、各年度ごとに標本集団の中央値を算出しました。
業界標準のFour KeysではLead time for changesが該当します。その基準はEliteが1時間以内、Highが1日から1週間となっております。
結果 Highの中を推移していること、そして、Eliteへの改善の余地があることが分かりました。
解決優先度の高い課題は、開発プロセスにおいてボトルネックとなっている箇所にあります。食べログの開発プロセスのメトリクスをFour Keysと比較して分析すると、Lead time for changesに課題があることが分かりました。Lead time for changesのボトルネックは手動のテストであり、この手動テストを自動化することが一番効果的なLead time for changesの解決策です。テスト自動化はDeveloper Productivityチーム発足時から最優先として取り組んできた改善活動です。この分析を通して、テスト自動化を最優先として取り組んできた優先度判断の裏付けができました。
QC7つ道具等を用い適切な統計量を選ぶことが大切
「プロセス改善の取り組みの定量化の次のステップはさらなる変化の機会の発見」のセクションで考察した通り、本発表では開発プロセス改善による変化を定量的に捉える試みを実現できました。
その過程で次の2点の学びを得ることができました。1つ目が「データ分析上の学び」、2つ目が「試みの実現を推進する上での学び」です。この2つの学びについて1つずつ紹介していきます。
まずはデータ分析上の学びから紹介していきます。
このデータ活用の取り組みでデータ分析をすることは私にとって初めての挑戦でした。その挑戦で困ったこと、その解決策としてQC手法である「QC七つ道具」を用いたこと、そこから得られた学びを紹介します。「QC七つ道具」は、Developer Productivityの源流である日本の全社的品質管理（TQC）で、全部門でトップからQCサークルまで広く活用されているQC手法・統計的手法の中でもっとも重要な手法です[3]。QC活動では現状の分析や要因の分析において、品質のバラツキを可視化するため「QC七つ道具」のヒストグラムを用います。
データ分析を始めてみると、外れ値がノイズになり平均値が使えないケースがありました。具体的には、テストからリリースまでのリードタイムの平均値をとった時、開発チームの感覚より6倍近く長い5.8日になってしまったケースです。この問題の原因はテストからリリースまでのリードタイムというプロセス品質のバラツキです。この品質のバラツキという問題に「QC七つ道具」のヒストグラムを利用しました。テストからリリースまでのリードタイムのデータの分布をヒストグラムとして表現し、中央値や平均値などの統計量をマッピングすることで、このデータの特性を正しく把握できました。今回のケースではヒストグラムの利用により、平均値が外れ値に引っ張られていたこと、一方で中央値が外れ値に対して頑健なことが分かりました。
正しい数値の扱い方や適切な統計量の選び方は統計学やQC七つ道具のようなもので学べます。
チームを超えたQAエンジニアと開発エンジニアのコラボレーション
続いて、試みの実現を推進する上での学びについてお話します。
前半パートにお話のあった組織のサイロ化は実は案件開発に限った話ではありませんでした。この取り組みを推進する上でも組織のサイロ化が問題となりました。
開発チームはマトリクス型組織導入後の開発プロセス改善による変化を定量的に捉えるため、そして、改善の余地を探すための一歩目として、GitHubの開発チケットやPull Requestのデータを集計ツールであるBigQueryに正規化して保存する試みを始めていました。しかし、集計したデータを活用して分析するイメージを持てていませんでした。
その一方でQAエンジニアは、品質ダッシュボードを導入することでプロセス品質のモニタリングを始めようとしていました。しかしながらどのようなダッシュボードが現場に求められているのかイメージを持てていませんでした。
ミッションの達成に向けたデータ活用を実現する第一歩を踏み出すきっかけとなったのは、開発エンジニアとQAエンジニアのチーム間での定例会議でした。その定例会議での情報交換を皮切りに一緒に取り組もうということになり、開発エンジニアは「What」「Why」にあたる「開発プロセス改善」、QAエンジニアは「How」にあたる「データ分析」のノウハウを持ち寄りました。
チームを超えた課題やノウハウの共有が、第一歩を踏み出すにあたって大切な要素であるという学びを得ました。
まとめ
では、本発表全体のまとめをして終わりたいと思います。
マトリクス型組織の導入後、リリース数・リリースサイズ・障害数についての開発プロセス改善の取り組みがありました。
改善による変化は、開発チケットやPull Requestのデータを集計・可視化し、以下の観点で分析することで定量的に捉えることができました。
- 改善前後の傾向の変化を確認するために1,2年前と比較
- 業界標準での食べログの立ち位置を知るためにFour Keysの統計データと比較
開発チーム、QAチームとチーム構成が分かれている組織では、チームを超えた課題やノウハウの共有が実現に向けた第一歩となるという学びを得ることができました。
これにて発表を終わりたいと思います。ご清聴ありがとうございました。
