BigQuery × GitHubで始める行動量の可視化【AI導入後の変化をラフに捉えるために】

こんにちは。ウォンテッドリーでバックエンドエンジニアをしている市古（@sora_ichigo_x）です。
最近は Enabling チームとしての役割を持ち、Visit の新規開発や、バックエンドアーキテクチャの改善に取り組んでいます。

現在、Enablingチームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は冨永さんによる「AWSのSESとSQSを活用したメール受信機能の実装」 でした。今回は、GitHub x BigQueryで開発行動量を可視化する社内基盤の紹介をしたいと思います。

はじめに

最近では、DevinやCursorなどのAIツール導入が進みつつありますが、それがどれだけ活用されているのか、具体的に説明するのは意外と難しいと感じる方も多いのではないでしょうか。

そこで今回は、ウォンテッドリーで実践しているGitHubのPRやIssueの“行動量”をBigQueryとLookerで可視化する仕組みと、その活かし方について紹介します。

なぜ行動量を見るのか

新しい取り組みの変化はまず行動に出る

AIツールの導入やレビュー文化の改善など、チームで何か新しい取り組みを始めたとき、すぐに成果として表れることは多くありません。しかし、だからと言って「変化がない」とは限りません。新しい取り組みの変化は、まず行動に出るものです。

たとえば「レビューの質を上げよう」とチームで話し合ったとします。すると、翌日からバグ数が減るわけではありませんが「レビューまでの所要時間が短くなった」「レビューがスムーズに通るようなった」など PRレビューのリードタイムやレビューのやり取りの量には少しずつ変化が出てきます。

Four Keys（デプロイ頻度や変更リードタイムなど）も参考にはなりますが、「意図した行動の変化」にフォーカスするにはやや粗いです。そこで、本記事ではより身近なGitHub上の行動データに注目しています。

何を見ているのか

可視化する指標はシンプルにする

私たちが可視化しているのは、GitHub上の次のようなシンプルな行動量です：

• PR作成数、マージ数
• Issue作成数、クローズ数
• Issueのリードタイム（作成〜クローズまでの時間）
• PRのリードタイム（作成〜マージまでの時間）

これらは「成果」ではなく「プロセスの出力」として捉えています。体温や心拍数のようなもので、それ自体をKPIにするのではなく、あくまでチームの状態を知るための“健康指標”的な位置づけです。

GitHub 行動量を KPI 化してはいけない

重要なのはこれらをKPI化しないことです。例えば「デプロイ頻度を増やそう」を目標にすると、とにかく細かく分割したPRを量産することでKPIハックできてしまいます。これは一定の効果はあるかもしれませんが、デプロイを分けすぎて施策全体のリードタイムが悪化していたら本末転倒です。

GitHubの行動量はあくまで "行動" であり "成果" ではありません。何かの改善活動の評価をする際は "成果" を生み出すために必要な行動量を事前に想定して、その想定と比較する形でデータを見ることを意識します。

余談：初期プロトタイプ時点での要求一覧

以下は初期プロトタイプを実装する際にまとめた要求一覧です。実装したのは2023年ですが、直近でもDevin等のAIツールのアクティビティを可視化する際にも役立っています。

どうやって可視化しているか

ここからは具体的にGitHubの行動量をどうやって可視化しているか解説します。

SaaSやOSSもいくつか検討しましたが、コストやカスタマイズ性を考慮して、最終的には社内向けにGoで小さな基盤アプリケーションを実装しました。

（社内では github-data-bq-exporter (internal) という名前で動いています）

BigQuery で可視化する

ウォンテッドリーでは以前からBigQueryを社内の共通データウェアハウスとして活用しており、開発者もBigQueryへの理解がある程度前提になっています。

なので、新しい分析を始めるときにも「とりあえずBQで見てみるか」という文化が根付いています。GitHubの行動量も例外ではなく、開発者がBQクエリを書くだけで試せるようにしました。

加えて、BIツールにはLookerを使っており、必要なView・Explore・Dashboardを用意しておくことで、非エンジニアでも手軽に傾向を確認できる状態にしています。

Goを採用する

Goは静的型付け言語であり、依存をすべて含んだ単一バイナリとしてデプロイ可能な特性から、「時間が経っても壊れにくく、どこでも動く」信頼性があります。

このためウォンテッドリーでは、開発効率や柔軟性を重視するプロダクトコードにはRuby（主にRails）が使われる一方で、CLIツールや長期運用を前提とした基盤系コードには、保守性と実行信頼性を重視してGoが選ばれることが多くなっています。

• 技術選定
• • Go
  • GitHub GraphQL API / shurcooL/githubv4
  • BigQuery API / cloud.google.com/go/bigquery

処理フロー

処理フローは最低限のシンプルな作りにしています。以下の3つが処理フローの要点です。

1. GitHub Action の schedule イベントで定期呼び出し
2. GitHub GraphQL API の search クエリで issue / pull request のデータ取得
3. bigquery パッケージの Query.Read 関数 を用いて Upsert 処理を実現

GitHub GraphQL API は https://docs.github.com/ja/graphql/overview/explorer から実行することができるため、自動化を試みる際は活用してみると良いでしょう。

おわりに

行動量の可視化は、チームを“正しく振り返る”ための土台になります。

成果を測るものではなく、変化を捉えるための道具として使う意識を持つことで、チーム内の会話がより具体的になり、意思決定も速くなります。