この記事は GMOアドマーケティング Advent Calendar 2023 11日目の記事です。

はじめに

こんにちは。GMOアドマーケティングのM.Nです。

先日、開発本部本部長のクリスよりFour Keysの導入に関する記事がありました。

Four Keys導入で変わる？エンジニア組織の生産性可視化と現場マネージャーの本音

この記事は GMOアドマーケティング Advent Calendar 2023 1日目の記事です。はじめに皆さん、こんにちは。開発本部本部長のクリスです。昨夏、エンジニア組織の生産性を可視化するため、Four Keysの導入を検討していることをお伝えしました。様々なツールを比較した結果、オープンソースの「Four Keys」を採用しました。指標の設定導入にあたって他社の事例に学びつつ、Four Keysの一般的な指標をそのまま採用するのではなく、私たちの実情に合わせて、以下の指標を選定しました。PR数と変更行数：各PR（プルリクエスト）の変更行数を...

開発本部では「PR数と変更行数」、「レビュー開始までの時間」という2つの指標を基準にしていますが、今回はFour Keysの計測方法や可視化について深掘りしてみようと思います。
実際は開発本部では上記2つの指標を使用しているためあまり活用できていないのですが、せっかくなので調査内容をブログに残しておこうと思います。

データの収集と可視化

Four Keys プロジェクトではデータを収集するための仕組みを公開しているので、それに沿って構築しています。

出典：Google Cloud 公式ブログ｜エリート DevOps チームであることを Four Keys プロジェクトで確認する

GitHubのイベントを、Cloud RunでホストされているWebhook ターゲットに送信するように設定します。Four Keysの環境をプロダクト単位で構築するのは大変なので、OrganizationのWebhooksに設定しています。

Webhookを設定すると、Pub/Subを経由してBigQueryにデータが入ってくることが確認できます。
BigQueryには生データのevents_rawテーブルとGrafanaのダッシュボードで表示するためのビューが3つ（deployments、changes、incidents）用意されています。

Grafanaのダッシュボードはこんな感じで表示されます。
Lead Time for ChangesとDaily Deploymentsは問題なく表示できていそうです。
後述しますが、現状はTime to Restore ServiceとDaily Change Failure Rateはうまく計測できていません。

events_rawを読む

先程OrganizationのWebhooksに設定したため、events_rawには全てのリポジトリのデータが入っています。
弊社では各プロダクトのリポジトリ構成は以下のようになっています。

GMOSSP
└ gmossp-repo1
└ gmossp-repo2
└ gmossp-repo3
TAXEL
└ taxel-repo1
└ taxel-repo2

試しに1つのリポジトリにどんなデータが入っているか確認する場合、以下のようなクエリで見ることができます。（events_rawのスキーマはこちら）

SELECT
  *
FROM
  `${PROJECT_ID}.four_keys.events_raw`
WHERE
  JSON_EXTRACT_SCALAR(metadata, '$.repository.name') = 'taxel-repo1'
ORDER BY
  time_created

SELECT

FROM

`${PROJECT_ID}.four_keys.events_raw`

WHERE

JSON_EXTRACT_SCALAR(metadata, '$.repository.name') = 'taxel-repo1'

ORDER BY

time_created

現状github以外で連携していないため source = github のイベントばかりでしたが、Pull Requestの情報やGitHub Actionsの情報も取れていました。

中身を見た感じ、Pull Requestの回数やレビュー開始までの時間も計測できそうです。

Deployment frequencyを計測する

Deployment frequencyを計測するにはDeployements API のCreate Developmentを叩く必要があります。
例えばGMOSSPではデプロイスクリプトを使ってデプロイしているので、スクリプト内でデプロイ成功時にCreate Developmentしてあげるのが1番簡単そうでした。
また、プロダクトによってはGitHub Actionsで特定のブランチにマージされたときにデプロイしているケースなどもあるかと思いますので、GitHub Actionsからデプロイ成功時にCreate Deployementしてあげてもよいと思います。

また開発チーム側でCreate Deploymentを仕込めない場合でも、例えばmainブランチにマージされたときの情報はevents_rawにあるので、何をトリガーにデプロイとするかを取り決めることができればビュー側で頑張ってクエリを書くことで計測できるかもしれません。
Grafanaでは以下のクエリでDaily Developmentを表示していたので、容易にカスタマイズできそうです。

SELECT
TIMESTAMP_TRUNC(time_created, DAY) AS day,
COUNT(distinct deploy_id) AS deployments
FROM
four_keys.deployments
GROUP BY day
ORDER BY day

SELECT

TIMESTAMP_TRUNC(time_created, DAY) AS day,

COUNT(distinct deploy_id) AS deployments

FROM

four_keys.deployments

GROUP BY day

ORDER BY day

Lead time for changesを計測する

Lead time for changesはブランチのpushイベントを収集しているようなので何もしなくても計測できるようになっています。

ただし、注意点としてpushイベントが発生してから計測開始になるのでブランチを切ってローカルで開発してもpushしないと計測が開始されない点に注意が必要です。

Time to Restore Services、Change Failure Rateを計測する

現状は計測できていない項目になりますが、これらはGitHub Issuesでissueを作成しIncidentラベルを貼ると計測対象になるようです。
しかし、弊社では障害管理票をエンジニア以外のメンバーも参照できるようにBacklogを使って管理しています。そのため、以下のような対応が必要だと思いました。

Backlogで課題作成やステータスを完了に変更した際にGitHub Issueと連携する（ただし、Backlogは全プロダクト共通なので連携先のリポジトリもどこかに集約しないといけない）
デフォルトで用意されているincidentsを使わずに別のテーブルを用意して、そこにレコードを追加するようにする（その場合はGrafana側にも影響が出る）

現実的には1の対応のほうが楽そうですが、例えばブランチ名で障害対応かどうかを分類できる（ブランチ名にhotfixやrevertという文字列がある場合は障害とする等）場合、クエリ側を修正することでGitHub Issuesを使用せずともincidentsを取得することができそうでした。

プロダクト単位で計測できるようにする

デフォルトで用意されているビューはプロダクト（またはリポジトリ）単位で計測することができないようになっています。そのためビューをカスタマイズする必要があります。

まず、プロダクト単位で集計できるようにするためプロダクト名を表示できるようにしていきます。
metadataにはリポジトリ名が含まれており以下のように取得できます。

JSON_EXTRACT_SCALAR(metadata, '$.repository.name') AS repository_name,

1	JSON_EXTRACT_SCALAR(metadata, '$.repository.name') AS repository_name,

また、プロダクトと紐付けられるようにクエリを変更します。
リポジトリ名にプロダクト名が入っていればこんな感じでできます。

SELECT
  *
FROM (
  SELECT
    SOURCE,
    CASE
      WHEN repository_name LIKE '%gmossp%' THEN 'gmossp'
      WHEN repository_name LIKE '%taxel%' THEN 'taxel'
      WHEN repository_name LIKE '%reemo%' THEN 'reemo'
    ELSE
      'unknown'
    END AS product_name,
    repository_name,
    deploy_id,
    time_created,
    main_commit,
    ARRAY_AGG(DISTINCT JSON_EXTRACT_SCALAR(array_commits, '$.id')) changes,
  FROM
    deployment_changes
  CROSS JOIN
    deployment_changes.array_commits
  GROUP BY
    1,2,3,4,5,6 )
WHERE
  product_name = 'taxel';

SELECT

FROM (

SELECT

SOURCE,

CASE

WHEN repository_name LIKE '%gmossp%' THEN 'gmossp'

WHEN repository_name LIKE '%taxel%' THEN 'taxel'

WHEN repository_name LIKE '%reemo%' THEN 'reemo'

ELSE

'unknown'

END AS product_name,

repository_name,

deploy_id,

time_created,

main_commit,

ARRAY_AGG(DISTINCT JSON_EXTRACT_SCALAR(array_commits, '$.id')) changes,

FROM

deployment_changes

CROSS JOIN

deployment_changes.array_commits

GROUP BY

1,2,3,4,5,6 )

WHERE

product_name = 'taxel';

あとはGrafanaのVariablesを使ってフィルタを作成し、フィルタを使用できるようにクエリを修正してあげればプロダクト単位で表示させることもできるようになると思います。

さいごに

Four Keysを使うと開発生産性を簡単に可視化することはできますが、これをどう活用するかが最も大切なことだと思います。
メトリクスの値を改善すること・評価することを目的にしてはいけません。それをやってしまうと必ずチートされます。
それよりも

メトリクスの値をどうやって改善するか
改善活動の結果、チームの成果や開発者体験が向上したか

などに着目するとよいと思います。

告知

明日はhigasunさんによる「【React】並び替えられるTodoアプリを作ってみた」です。
引き続き、GMOアドマーケティング Advent Calendar 2023 をお楽しみください！

■採用ページはこちら！
https://recruit.gmo-ap.jp/

■GMOアドパートナーズ公式noteはこちら！
https://note.gmo-ap.jp/

M.N

はじめに

データの収集と可視化

events_rawを読む

Deployment frequencyを計測する

Lead time for changesを計測する

Time to Restore Services、Change Failure Rateを計測する

プロダクト単位で計測できるようにする

さいごに

告知

おすすめ

Railsのタグ機能でN+1問題解消

Professional Scrum Master ⅠとⅡに合格しました

background-imageを活用して、アップする画像を1個で済ませたい