こんにちは、FANTECH本部の山下(@takecy)です。
エンジニアリング活動の計測や可視化、難しいですよね。
そもそもそんな事が可能なのか？と思いつつも、自分たちはこんだけやっているぜ、1年前と比べてこんだけ改善したぜ、というのが見えるのは、ドラクエのレベルアップと同じような楽しさがあります。(ドラクエ3予約しました)
紆余曲折を経てエンジニアリング活動を計測/可視化した後、開発フローなどを見直したら、結果的に指標が思った以上に伸びたのが目に見えて、テンションが上がったお話をご紹介します。
計測と可視化方法
エンジニアリング活動の計測方法は色々ありますが、まずは王道のFourKeysを使ってやってみることにしました。
2022/03月ごろからこの試みを開始しました。
FourKeysとは
色々なところで言及されているので詳細な説明は省略しますが、ソフトウェア開発チームのパフォーマンスを下記の4つの指標で計測しようというものです。
- デプロイの頻度 – 組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム – commit から本番環境稼働までの所要時間
- 変更障害率 – デプロイが原因で本番環境で障害が発生する割合（%）
- サービス復元時間 – 組織が本番環境での障害から回復するのにかかる時間
エリート DevOps チームであることを Four Keys プロジェクトで確認する
FourKeysの計測手法は現在はSaaSを含め色々ありますが、当時はあまり選択肢がなかったため、OSSのFourKeysリポジトリを活用して、自前でアプリケーションをホストすることにしました。
このアプリケーションは、開発関連のイベントを受信してGoogle Cloud BigQueryへデータを保存する機能と、イベントを送信するためのエンドポイントを提供します。そのエンドポイントをGitHubの各リポジトリのWebhookに指定し、GitHub上のイベントを記録していきます。
(このリポジトリは2024/01/24にアーカイブされました)
dora-team/fourkeys: Platform for monitoring the four key software delivery metrics of software delivery
可視化の実践
まずはリポジトリのREADMEにある手順のまま進めてみて、どうなるのかを確認してみることにしました。
このリポジトリ内にはTerraformファイルまで用意されており、業務で利用中のGoogle Cloud環境もあったため、比較的簡単にイベントを受け取り保存するアプリケーションを用意することができました。デフォルトではGrafanaを使って可視化されるようなので、イベントが少し溜まるのを待って見てみます。
な、何も出ていない…
我々の開発は全てGitHub上で行われているものの、このアプリケーションでFourKeysを計測するには、例えば障害発生時に incident ラベルを付けたissueをopenし解消したらcloseするなど、ルールに沿った開発フローの運用が必要になります。
これはなかなか前途多難な予感がします。
なぜエンジニアリング活動の計測と可視化するのか？
ここで、そもそもなぜエンジニアリング活動の計測と可視化をするのか？を改めて考えてみます。
この取り組みを開始する時に、下記記事を参考にさせていただいて、このような図を作成し事業責任者を含め共有しました。
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi
エンジニアリング組織の活動は、売上などのアウトカムに直接つながるものは少なく、アウトカムを生み出すための事業資産を作る (図のアウトプット部分) ことが多くなります。そしてエンジニアリング組織の成果とは、このアウトプット部分=事業資産を作り続けることと定義し、その能力の最大化を目標としています。
このような組織の性質については、事業責任者を含め多くの人が理解を示してくれていますが、どうしても組織外の特に非エンジニアの人から活動内容が見えにくくなりがちです。FourKeysは、エンジニアリング組織自身がよりよい組織になっていくための指標ではあるものの、俺たちこんなにやってるぜ！と組織外にアピールすることに活用しようというのもこの取り組みの動機と目的の一つでした。
しかし、今の開発フローではFourKeysが何も表示されないのは予想外で困りました。
そこで、まずは4つの指標のうち、図のアウトプットの矢印の太さを表す指標でもある「デプロイの頻度」のみを計測/可視化して追ってみることにしました。
デプロイフローの統一
デプロイの頻度のみを計測することにしたとはいえ、それも簡単ではありません。
デプロイ頻度を向上させるために実施した色々なアクションのうち、大変でしたが効果も高かったのが、デプロイフローの統一です。
当時は、チームやリポジトリごとにCI/CDの手段や手順が様々混在していている状態でした。
デプロイ前にgit tagをつける、デプロイ成功したらgit tagをつける、まずstaging環境へのデプロイを経由しないと本番にデプロイ出来ない、などなど。
CDのために使用しているツールもTravisCI, CircleCI, Jenkins, Shell Script, GitHub Actions…など様々でした。
そこで2つ方針を定めました。
- デプロイ前にGitHub Releaseを作る
- CI/CDは GitHub ActionsのSelf-hosted Runnerで行う
この作業を行うにあたり、多くのリポジトリにほぼ同じ設定を追加していくことが予想されます。
そのため、まず最初にGitHub Actionsのワークフローの再利用の仕組みを使って、新規の専用リポジトリに1と2のワークフローをテンプレートとして定義しました。
これで各リポジトリは、yamlファイルを作成する必要はありますが、このワークフローテンプレートを参照し固有の情報を引数に渡すだけでワークフローを作成でき、デプロイフローを統一できます。
また、これにより修正が容易になり、例えば後ほどデプロイ前にTrivyによるスキャンを追加したくなった場合でも、テンプレートを修正するだけで全リポジトリに適用できます。
1は、リリース(デプロイ)が行われたイベントを、デプロイ対象の各リポジトリのGitHub Release作成というイベントに統一してBigQueryへ記録することで、可視化を容易にする目的です。
PullRequestからリリースノートを自動生成してくれるAPIもあり、素直にGitHub Actions化することができました。
2は、外部SaaSに対しCI/CDに必要な認証情報(強い権限になりがち)を渡さなくてよくなるセキュリティ強化の観点や、強いインスタンスを用意することで課題の一つだったCIの高速化による開発速度の向上、前述の再利用ワークフローにより秘伝のタレ的な属人化CDの排除で認知負荷の軽減、などが目的です。
Self-hosted Runnerは丁寧なドキュメントがあり、CI/CDも処理自体はあったので、それをGtiHub Actions用に書き換えれば良いだけのはずです。
しかし、サーバチーム管理のリポジトリだけでも数十以上あり、それぞれのリポジトリでCI/CDの方法が微妙に異なるなど、認知負荷 x 物量の壁に対し黙々と地道な対応をする日々がしばらく続きました。
リポジトリの中には、特殊なことをしていてどうしてもSelf-hosted Runnerへの移行がうまくいかず、やむをえずGitHub HostedのRunnerを使用していたり、ほぼ触ることがないリポジトリは、見なかったことにして将来機会があったらついでにやろう、となっているものもあります。
その甲斐あって、現在我々の管理するリポジトリは、基本的にどのリポジトリでも同じ手段と手順でデプロイできるようになりました。
可視化ツールの変更
OSSのFourKeysアプリケーションの標準の可視化ツールはGrafanaでしたが、BigQueryにイベントデータが入っていること、元々Google Workspaceを使っていて権限管理がしやすいことなどの理由から、LookerStudioで可視化することにしました。
BigQuery内に蓄積されているGitHubのイベント情報から、GitHub Releaseの作成イベントを時系列で表示しています。
可視化にあたりチームのデータサイエンティストの方のお力を多分にお借りしました(というかほぼ丸投げ)。ありがとうございました。
結果
デプロイフローの統一以外にも、トイルの撲滅など大小様々な取り組みを試しましたが、それはまた別の機会にご紹介させていただくことにして、結果どうなったかを見てみます。
2022/05~ 本格的に計測できるようになっています。その後しばらく横ばいを維持しています。
2022/12~2023/06ごろは、新規機能などの開発が多く、開発環境の改善やシステムの保守などにあまり手が回っていませんでした。この期間にデプロイ頻度は下降しています。
新規開発ばかりに集中してしまうと、逆にデプロイ頻度が減ってしまうということが分かりやすく可視化されています。
2023/08ごろからは、エンジニアリング組織としてのアウトプットを最大化する取り組みの成果が出はじめたことに加え、開発スプリントで下記グラフを毎回共有し全体で向上させていく意識を高めるとともに、既存システムの保守工数が一定確保できたたことで増加に転じ、最大で前年比4.5倍の回数のデプロイを行うことができるようになりました。
その後もエンジニアをはじめ開発チームの継続的な様々な取り組みによって、デプロイ頻度上昇の傾向は続いており、「事業資産を作る能力の最大化」に少しづつ近づいています。
まとめ
FourKeysの指標を活用してエンジニアリング組織の生産性が向上した結果、事業への成果を増やすことが出来たお話を紹介させていただきました。
この取り組みを通じて、開発フローの見直しや、開発者体験を阻害する様々な要因を排除しエンジニアが開発に集中できる環境を整備することが必要になりました。
可視化すること自体が目的化することなく、事業成果の最大化とそれを可能にする理想の開発組織の実現という目標に対し、様々な課題への対応結果の変化を追う手段として可視化を活用することが大切だと感じました。
まだ4つの指標のうち1つしか追えていませんし、他にも課題は山積していますが、楽しい開発と事業成果を両立できる組織を目指して少しづつ進んでいけたらと思います。
最後まで読んでいただいてありがとうございました。