はじめに
こんにちは、データシステム部MA推薦ブロックの佐藤（@rayuron）です。私たちは、主にZOZOTOWNのメール配信のパーソナライズなど、マーケティングオートメーションに関するレコメンドシステムを開発・運用しています。本記事では、GitHub Projects、BigQuery、Looker Studioを組み合わせて作業工数を可視化し、改善サイクルを回すための仕組みを構築した取り組みについてご紹介します。
背景と課題
MA推薦ブロックはこれまでGitHub Projectsでタスクを管理してきましたが、担当者やリポジトリごとに記入フォーマットが異なり、運用ルールが統一されていませんでした。そのためGitHub Projectsによる進捗確認はできるものの、工数の集計や振り返りなどに活かせていませんでした。具体的には以下の3つの課題がありました。
1. ボトルネックの特定に手間がかかり改善に着手しにくい
プロジェクトを進める中で「なんとなく時間がかかった」という感覚はあっても、どの工程に工数が多くかかっているのか、予想と実際の工数の差が大きい箇所はどこなのかを把握できていませんでした。また、当時の状況やドキュメントがSlack、Confluence、GitHubに点在しており、ログが散逸していたためボトルネックの特定に時間がかかり改善に着手しにくい状況でした。
2. 工数に対する事業価値を把握できていない
プロジェクトの事業価値や投資対効果を把握するために必要となる、過去のプロジェクト工数と事業KPIの変化を紐付けて記録できていませんでした。
3. AI活用の効果測定とナレッジの蓄積ができていない
あるタスクに対してどのようなAI活用が効果的だったかというナレッジを蓄積・共有する仕組みがありませんでした。そのため人によっては効率的にAIを活用している一方で活用が進んでいないメンバーもおり、チーム全体でのAI活用の波及が進んでいない状況でした。
解決策
これらの課題に対して以下の解決策を考えました。
| 課題 | 解決策 | |
|---|---|---|
| 1 | ボトルネックの特定に手間がかかり改善に着手しにくい | 施策の工数予実を可視化し振り返ることでボトルネックを特定し改善する仕組みを作る |
| 2 | 工数に対する事業価値を把握できていない | プロジェクトごとの工数と事業KPIの変化を関連付けて振り返る仕組みを作る |
| 3 | AI活用の効果測定とナレッジの蓄積ができていない | タスクごとにAI活用のナレッジを蓄積・共有する仕組みを作る |
上記の解決策を実現するため、GitHub Projects + BigQuery + Looker Studioを組み合わせた仕組みと、振り返り会を導入しました。
1. GitHub Projectsの運用整備
まず初めに、タスクに紐づく工数予実などのデータを取得する必要がありましたが、これには引き続きGitHub Projectsを活用することにしました。GitHub Projectsではカスタムフィールドを活用することで、タスクに任意のメタデータを付与できます。さらにGitHub Actionsとの連携により、様々なオートメーションの構築も容易です。社内では既にFindy Team+が導入されており主にPRベースで定量的な工数集計と可視化が可能ですが、PRに紐づかないタスクの工数集計や拡張性の観点で最終的にGitHub Projectsを選択しました。
カスタムフィールドの作成
GitHub Projectsにカスタムフィールドを設定しIssueに紐付けます。先述の工数やAI活用度合いを計測するため、以下のカスタムフィールドを用意しました。
| フィールド名 | 種類 | 説明 | 入力 |
|---|---|---|---|
| 案件 | 単一選択 | どの案件に紐づくタスクかを選択 | 必須 |
| 作業内容 | 単一選択 | どの工程のタスクかを選択 | 必須 |
| 予定開始日 | 日付 | タスクの開始予定日 | 必須 |
| 予定完了日 | 日付 | タスクの完了予定日 | 必須 |
| 開始日 | 日付 | タスクの実際の開始日 | 必須 |
| 完了日 | 日付 | タスクの実際の完了日 | 必須 |
| AI活用 | 単一選択 | AI活用方法を記録 | 任意 |
| AI削減時間 | 数値 | AI活用による削減時間 | 任意 |
工数予実を記録するために開始予定日と完了予定日、開始日と完了日の入力を必須としています。また、作業内容と工数の紐付けを行うため、案件と作業内容の入力も必須としました。さらに、Issueのテンプレート機能を活用し、概要と完了条件を必須項目として設定し最低限のコンテキストがIssueの中で整理されるようにしました。
自動入力の仕組み
上記のように多くのフィールドを用意したことで手動での運用負荷が増加します。これを軽減するためGitHub Projectsに紐づくステータスやIssueに紐づくイベントとGitHub Actionsを連携させることで解決を図っています。具体的には以下の自動入力の仕組みを作成しています。
- Issueをオープンした時に、オープンした人をassigneeに自動設定する
- Issueのステータスを「進行中」に変更すると「開始日」が自動入力される
- Issueをクローズすると「完了日」が自動入力される
- Issueのステータス変更時にin-progress, in-reviewなどのラベルが自動付与される
- Issueに紐づくPRでレビューリクエストをするとIssueのassigneeとステータスが自動更新される
- Issueに紐づくPRをApproveするとIssueのassigneeとステータスが自動更新される
上記に加え、Issue作成のためのClaude CodeのSkillsを作成して運用しています。Skillsでは、GitHub CLIとClaude CodeのAskUserQuestion Toolを組み合わせています。Issueの作成や編集を選択式で行えるため、コンテキストの整理や運用負荷の軽減につながっています。
2. データ収集の自動化
上記で紹介したGitHub Projectsの情報はGitHub GraphQL APIを通して取得可能なため、BigQueryに自動的に保存する仕組みを作成しました。
BigQueryへのデータ保存
まず初めにGitHub GraphQL APIを使用して、GitHub Projectsのデータを取得するスクリプトを作成しました。GitHub Projectsから取得したデータは社内でよく使用するBigQueryに以下のようなカラム構成で保存しています。この時、簡単な集計や営業日計算もスクリプト内で実装しています。
| カラム名 | 説明 |
|---|---|
| url | IssueのURL |
| title | Issueのタイトル |
| body | Issueの本文 |
| comments | Issueのコメント |
| assignees | 担当者 |
| labels | Issueのラベル |
| in_review_label_duration_days | レビュー中ラベルが付与されている日数 |
| in_progress_label_duration_days | 進行中ラベルが付与されている日数 |
| review_started_at_jst | レビュー開始日時 |
| review_ended_at_jst | レビュー終了日時 |
| progress_started_at_jst | 進行開始日時 |
| progress_ended_at_jst | 進行終了日時 |
| created_at | Issue作成日時 |
| closed_at | Issueクローズ日時 |
| github_project | GitHub Project名 |
| status | Issueのステータス |
| project | 案件名 |
| planned_start_date | 予定開始日 |
| planned_end_date | 予定完了日 |
| actual_start_date | 実際の開始日 |
| actual_end_date | 実際の完了日 |
| work_type | 作業内容 |
| ai_success_failure | AI活用方法を記録 |
| ai_hours_reduction | AI活用による削減時間 |
| actual_days | 実績日数 |
| planned_days | 予定日数 |
| delay_days | 予実差（日数） |
| estimation_accuracy | 見積もり精度（実績日数/予定日数） |
| project_work_type | 案件×作業内容の組み合わせ |
| year_month | 年月（YYYY-MM形式） |
| FYH | 会計年度と半期（例：FY24H1） |
GitHub Actionsで日次エクスポート
次に上記のスクリプトをGitHub Actionsで日次実行し、BigQueryにエクスポートする仕組みを構築しました。
name: Export GitHub Project to BigQuery on: schedule: - cron: '0 0 * * *' workflow_dispatch: jobs: export-to-bq: runs-on: ubuntu-latest permissions: contents: read id-token: write steps: - uses: actions/checkout@v4 - name: Install uv uses: astral-sh/setup-uv@v4 - name: Generate GitHub App Token id: generate_token uses: actions/create-github-app-token@v2 with: app-id: ${{ secrets.APP_ID }} private-key: ${{ secrets.APP_PRIVATE_KEY }} owner: your-org repositories: | target-repo-1 target-repo-2 - name: Authenticate to Google Cloud uses: google-github-actions/auth@v2 with: workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER }} service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }} - name: Set up Cloud SDK uses: google-github-actions/setup-gcloud@v2 - name: Export data to BigQuery env: GH_TOKEN: ${{ steps.generate_token.outputs.token }} GCP_PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }} BQ_DATASET: github_aggregation BQ_TABLE: github_project_items GITHUB_ORG: your-org GITHUB_PROJECT_NUMBER: 123 run: uv run export_github_project_to_bigquery.py
3. ダッシュボードと振り返り会の運用
上記のようにして収集したデータをもとにLooker Studioでダッシュボードを作成し、以下の振り返り会で活用しています。
| 振り返り会 | 頻度 | ダッシュボード | 用途 |
|---|---|---|---|
| 週次振り返り | 毎週20分 | WBS、AI活用状況 | タスク進捗確認、AI活用ナレッジ共有 |
| 施策完了時の振り返り | 施策完了時 | 振り返り用 | 予実差の確認、ボトルネック特定 |
| 半期振り返り | 半期ごと | 半期振り返り用 | プロジェクト横断での指標振り返り |
| 工数入力 | 月初 | 工数管理システム入力用 | 工数割合の可視化 |
以下では、各振り返り会について説明します。
週次振り返り
週次振り返りでは毎週20分のミーティングで、WBSとAI活用状況を確認します。WBSはGitHub Projectsの予定開始日と予定完了日フィールドとRoadmap viewを活用して作成しています。
WBSを確認することで、メンバー同士がお互いのタスク進捗を把握でき、タスクが遅延している場合にその理由を知ることができます。さらに他メンバーの補助やタスクの分散を検討することで、遅延の早期解消につなげています。
次に、AI活用状況ダッシュボードを見て、AI活用の目標に対する進捗の確認とタスクごとのAI活用事例を共有します。その週最もAI活用が効果的だった事例をピックアップし、社内のピアボーナスアプリで表彰する運用をしています。
施策完了時の振り返り
施策が完了した際に、施策振り返り用ダッシュボードを参照して振り返りを行います。具体的には以下の指標を確認します。
- 作業内容別の予定日数と実績日数の比較
- 作業日数合計に対して各作業内容が占める割合
- タスク一覧と予実差の確認
- 予定日数と実績日数の散布図による見積もり精度の確認
※一部の情報はマスクしています。
上記のダッシュボードを参照しながら、以下の観点で振り返りを行います。
| 項目 | 説明 |
|---|---|
| 施策の効果 | 施策が事業KPIにどれだけ貢献したかを確認 |
| 開発工数 | 予定と実際の工数のずれを確認しボトルネックとなった工程を特定 具体的な原因の深掘りと次回の改善点を議論 |
| 施策KPT | 継続すべき事、問題点、改善案を整理し、次回施策に向けたアクションを決定 |
半期振り返り
半期振り返り用ダッシュボードを使用して、半期の活動を振り返ります。施策振り返り用ダッシュボードが1案件単位での振り返りに特化しているのに対し、こちらはプロジェクト横断で同様の指標を振り返りできるようにしています。
上記のダッシュボードを参照しながら、以下の観点で振り返りを行います。
| 項目 | 説明 |
|---|---|
| 案件とタイムライン | 半期に取り組んだ案件の一覧とスケジュールを振り返る |
| 事業KPI | 案件毎の事業KPIの変化を確認 |
| 事業KPI 以外での貢献 | 登壇、チームの仕組みづくりによる影響などKPI以外の価値を評価 |
| コスト | インフラコストの変化を把握 |
| 開発生産性 | 案件や作業内容の割合、予定日数と実績日数の差を分析 |
| ブロックのテーマ | チームとして注力したテーマを振り返る |
| 半期KPT | 継続すべき事、問題点、改善案を整理し、次期半期に向けたアクションを決定 |
工数入力
社内では工数管理システムへの工数登録が必要なため、入力支援用のダッシュボードを作成しています。案件×作業内容についての工数割合を円グラフで可視化しています。担当者と年月でフィルタリングをすると、各カテゴリの工数割合が一目でわかり入力の補助になります。
効果
これらの取り組みにより当初の課題が解決されただけでなく、副次的な効果も得られました。
課題に対する効果
1. ボトルネックの可視化と改善
施策振り返り時に、予定と実際の工数のずれや、工数がかかっている箇所が可視化されるようになりました。感覚的に捉えていたボトルネックをデータで把握できるようになりました。振り返り時にはIssueからその時のコンテキストを参照できるので、解像度の高い課題の特定と正確なネクストアクションの設定が可能です。これまで具体的に以下のようなアクションを設定できました。
- 要件の抜け漏れによる手戻りの発生に対して、テンプレートとなるドキュメントの更新
- 実装後にコストが想定外となり調整に時間がかかった課題に対して、コスト試算フローの追加
- コードが複雑なので可読性が落ち理解に時間がかかったり、バグを埋め込み手戻りが発生したりするという課題に対して、コードの複雑度を自動計測する仕組みを導入
忘れかけていたボトルネックを振り返り会で再発見することもあり、改善に向けた具体的なアクションを設定できるようになりました。
2. 工数と事業価値の関連付け
施策振り返り時や半期の評価時に、施策ごとの工数と事業価値の関連を確認できるようになりました。特定の案件の工数とKPIの変化を紐付けて振り返ることで、投資対効果の高い施策を記録し説明できるようになりました。
3. AI活用の効果測定とナレッジ蓄積
AI活用フィールドにより、どのタスクでAIを活用したか、どの程度の工数削減につながったかを記録・可視化できるようになりました。IssueあたりのAI活用率は2025年4月の44％から12月には73％へと上昇しました。また、Issueの作成単位は作業内容により異なりますが、平均的な削減時間は分析・レポーティング（3.8h）、執筆・登壇業務（3.7h）、モデル開発（2.8h）、システム開発（2.7h）の順で大きい傾向があります。
さらに、AI活用事例がBigQueryに蓄積されているため、過去の成功パターンを簡単に参照できます。以下は実際に蓄積されたAI活用事例の一部です。
- marimoのドキュメント調査をした。marimoはcurlでCLAUDE.mdを取得可能で体験がよかった。分析手法の計画とクエリ作成、分析は全てClaude Codeに任せてその後自分で調整と確認をした
- Claude Codeを使ったドキュメントの推敲をした。目次と参考資料からドキュメントを生成してもらいそれを推敲した。画像はVS CodeのDraw.io Extensionでプレビューを確認しつつ、ローカル上でClaude Codeに作成してもらいそれを手動調整した
副次的な効果
当初の課題以外でも以下のような副次的な効果が得られました。
- GitHub ProjectsとGoogle SpreadsheetでのWBSの二重管理が解消された
- SlackでのPRレビュー依頼がなくなり、必要のないコミュニケーションが減少した
- 過去のプロジェクトデータにBigQueryを通してアクセスできるようになり、深掘り分析が容易になった
- 週1の定例でプロジェクトの遅延を可視化でき、早期のフォローが可能になった
- AI活用の定量的な目標設定と振り返りが可能になった
- AI活用事例を他チームと共有しやすくなった
- 社内の工数管理システムへの入力が効率化された
今後の展望
フィールド入力の自動化
Issue作成には先述したオートメーションを活用しているものの、まだ運用負荷が高いためフィールド入力のさらなる自動化を検討しています。また、AI活用事例も現在は自己申告ベースのため、自動化や精緻な効果測定の仕組み作りを考える必要があります。
施策の優先度決めでの活用
工数と事業価値の関連付けと記録は可能になりましたが、それを用いた将来的な施策の優先度付けは感覚的な活用に留まっており十分ではありません。今後は、工数と事業価値の関連データを活用した施策の優先度決めの仕組み作りを進めていきたいと考えています。
AI活用のさらなる促進
また、Issueに「概要・完了条件」を構造化して記載する運用によりGitHub CopilotやClaude CodeがIssueを読み取ってPRを作成するワークフローとの相性も良くなっています。今後はAIによるタスク自動達成ケースの分析・評価と仕組み作りを進め、AI活用のさらなる促進を目指します。
おわりに
本記事では、GitHub Projects、BigQuery、Looker Studioを組み合わせて作業工数を可視化し、改善サイクルを回すための仕組みを構築した取り組みについてご紹介しました。本仕組みにより、ボトルネックの可視化と改善、工数と事業価値の関連付け、AI活用の効果測定とナレッジ蓄積が可能となりました。
ZOZOでは一緒にサービスを作り上げてくれる方を募集しています。ご興味がある方は以下のリンクからぜひご応募ください！
