.table-of-contents > li > ul > li > ul { display: none; } はじめに こんにちは。データシステム部・MA推薦ブロックの伊藤（ @rabbit_x86 ）です。私たちのチームでは、メール配信などのマーケティングオートメーション（MA）に関する推薦システムを開発・運用しています。 従来、ZOZOTOWNのMA施策における推薦システムでは、 開発リードタイムと推薦精度のトレードオフ が課題でした。この課題を解決するため、ユーザーとアイテムをベクトルで表現したEmbeddingとBigQuery Vector Searchを活用し、施策を横断して利用可能な 汎用推薦システム を開発しました。本システムにより、開発リードタイムを 約1/3 に短縮し、A/Bテストで 配信当たりのMA経由流入数・購入数の改善 を達成しました。 本記事では、このシステムの設計思想・アーキテクチャ・構築時の技術的な課題と工夫、そして実際の事例を紹介します。 目次 はじめに 目次 背景と課題 従来の推薦アプローチとそのトレードオフ 機械学習ベースの開発リードタイム ルールベースによる推薦の限界 システム要件 アプローチ 前提知識：EmbeddingとEmbedding基盤 汎用推薦システム 全体構成 1. セグメント抽出 2. Embedding取得 3. Vector Index作成 4. Vector Search 5. スコアブースト・フィルタリング 6. 評価・バリデーション 技術的な課題と工夫 Vector Indexの非同期構築への対処 Vector Searchのスロット消費問題 運用事例 開発リードタイムの短縮 推薦精度の向上 まとめ 今後の展望 最後に 背景と課題 従来の推薦アプローチとそのトレードオフ MA施策では、対象ユーザー（ユーザーセグメント）と対象アイテム（アイテムセグメント）を施策ごとに定義し、パーソナライズされた商品を提供しています。その推薦システムは、「ルールベース」と「機械学習ベース」の2つのアプローチで構築されています。ルールベースは閲覧したカテゴリの商品を推薦するなど、行動ログに基づくルールでスコアリングするアプローチです。機械学習ベースは行動ログを活用しつつ、モデルが学習した潜在的な嗜好をもとに推薦するアプローチです。 これらのアプローチには精度と開発リードタイムのトレードオフが存在し、ルールベースは 高速だが推薦精度が低く 、機械学習ベースは 精度が高い一方で開発リードタイムが長い という課題がありました。 ルールベース 機械学習ベース ロジック 閲覧履歴・お気に入りなどの行動ログに基づくヒューリスティクス 専用の推薦モデルが学習した潜在的な嗜好に基づくスコアリング 開発リードタイム 短い 長い 精度 低い 高い 機械学習ベースの開発リードタイム 機械学習ベースの推薦にはモデルを実装する必要があり、施策ごとに以下の一連の開発工程を繰り返します。 工程 所要期間 探索的データ分析 約2週間 モデルの設計・実装 約3週間 パイプラインの設計・実装 約2週間 実験・評価・チューニング 約3週間 この結果、 1施策あたり約10週間の開発リードタイム が必要となり、仮説検証のサイクルが遅くなっていました。 ルールベースによる推薦の限界 一方、ルールベースのロジックでは、閲覧履歴やお気に入りブランドなど、ユーザーの顕在的な嗜好に基づく推薦が中心です。たとえば、「ブランドAを閲覧したユーザーにブランドAの値下げ商品を推薦する」といったルールなどです。こうしたルールは設計が容易な反面、ユーザーが触れた商品のみを推薦し、ユーザーの潜在的な嗜好を考慮した推薦ができないという課題がありました。 システム要件 そこで、 高速なモデル構築と高い推薦精度を両立 する仕組みが必要でした。 要件をまとめると以下のとおりです。 要件 詳細 高速な推薦システム構築 推薦システムを短期間で構築できること 高い推薦精度 ユーザーの潜在的な嗜好を捉えた推薦ができること アプローチ 上記の要件を満たすため、社内のEmbedding基盤とBigQuery Vector Searchを活用した汎用推薦システムを開発しました。 前提知識：EmbeddingとEmbedding基盤 Embeddingとは、データを固定長のベクトルとして表現する手法です。社内のEmbedding基盤では、ユーザーの行動履歴をもとにTwo-Towerモデルを使い、ユーザーとアイテムの類似度が意味を持つように共通の次元数の埋め込み空間へそれぞれエンコードします。ベクトル間のコサイン類似度を計算することで、ユーザーの潜在的な嗜好に近いアイテムを特定できます。 Embedding基盤については、推薦基盤ブロックで執筆した以下の記事で詳しく紹介しています。 techblog.zozo.com 汎用推薦システム 本システムは1つのモデルで複数の施策に対応できる汎用的な仕組みです。セグメントを定義してEmbeddingを抽出し、BigQuery Vector Searchで類似度を計算することで、パーソナライズされた推薦結果を生成します。従来必要だった 特徴量作成やモデル学習が不要 になるため、開発リードタイムを短縮できます。 さらに、Embeddingを利用することで、ルールベースでは捉えられなかったユーザーの潜在的な嗜好を反映した 高い推薦精度 を実現します。施策の目的に応じて関連スコアの調整やフィルタリングなどの後処理も適用でき、細かなチューニングにも対応できます。 全体構成 本システムは、社内のMLパイプライン基盤であるVertex AI Pipelinesで実行されます。 パイプラインの主要ステップを以下の表にまとめます。 ステップ 処理内容 実行環境 1. セグメント抽出 ユーザーセグメント・アイテムセグメントをSQLで抽出 BigQuery 2. Embedding取得 セグメントに対応するEmbeddingをEmbedding基盤から取得 BigQuery 3. Vector Index作成 アイテムEmbeddingにTREE_AHインデックスを作成し、完了まで待機 BigQuery 4. Vector Search ユーザーEmbedding × アイテムEmbeddingの関連スコアを算出 BigQuery 5. スコアブースト・フィルタリング 関連スコアのブースト・ペナルティによるリランキング BigQuery 6. 評価・バリデーション 定量評価（Vertex AI Experiments）、ポリシーチェック BigQuery / Vertex AI 1. セグメント抽出 施策ごとに定義されたSQLクエリで、対象ユーザーと対象アイテムを抽出します。たとえば、「過去30日以内にアクティブなユーザー」や「特定カテゴリの新着アイテム」などです。このSQLを差し替えるだけで、さまざまな施策へ対応できる設計です。 2. Embedding取得 Embedding基盤から、抽出したユーザー・アイテムに対応するEmbeddingを取得します。 3. Vector Index作成 Vector Searchの高速化のため、アイテムEmbeddingテーブルへ CREATE VECTOR INDEX でインデックスを作成します。本システムでは大規模バッチ向けの TREE_AH （GoogleのScaNNアルゴリズムベース）を採用しています。Vector Indexの構築にまつわる課題と対処法は、後述の「技術的な課題と工夫」で説明します。 4. Vector Search BigQueryの VECTOR_SEARCH 関数を用いてユーザーEmbeddingとアイテムEmbeddingのコサイン類似度を計算し、ユーザーごとに関連スコアの高い上位N件のアイテムを取得します。 -- Vector Searchの実行例（簡略化） SELECT query.member_id, base.product_id, distance FROM VECTOR_SEARCH( ( SELECT * FROM candidate_embeddings), -- アイテムEmbedding ' embedding ' , ( SELECT * FROM query_embeddings), -- ユーザーEmbedding ' embedding ' , top_k => 100 , distance_type => ' COSINE ' ) 5. スコアブースト・フィルタリング Vector Searchで得られた関連スコアは、そのままでは施策の目的に最適化されていません。そこで、ブーストやペナルティによるリランキングとフィルタリングを行い、最終的な推薦結果を生成します。 生成された推薦結果はBigQueryのテーブルに保存され、MAの配信システムがこのテーブルを読み込むことで連携します。 6. 評価・バリデーション パイプラインの最終ステップとして、推薦結果の品質を評価・検証します。 評価種別 内容 記録先 定量評価 NDCG、Precision、Recall等の指標を記録 Vertex AI Experiments ポリシーチェック 推薦結果がセグメント条件を満たすか、1ユーザーあたりの推薦数が閾値以上かなどを検証 BigQuery 技術的な課題と工夫 Vector Indexの非同期構築への対処 BigQueryのVector Indexは 非同期で構築 されるため、実行直後にはインデックスが利用可能になりません。インデックスが未完成の状態でVector Searchを実行すると、ブルートフォース（全件スキャン）で計算するため、実行時間とスロット消費が膨大になります。 この問題に対処するのが、全体構成図における Index完了待ち のコンポーネントです。以下のクエリで INFORMATION_SCHEMA.VECTOR_INDEXES の coverage_percentage を定期的にポーリングし、インデックス構築の完了を確認しています。 SELECT table_name, coverage_percentage FROM `{project_id}.{dataset_id}`.INFORMATION_SCHEMA.VECTOR_INDEXES WHERE table_name IN UNNEST(@expected_tables) coverage_percentage が100％に達した後、Vector Searchステップへ進むことでブルートフォース計算を回避しています。 Vector Searchのスロット消費問題 もう1つの大きな課題は、 共有スロット の大量消費による他ジョブへの影響 でした。Vector Searchはユーザーとアイテムの全組み合わせに対してコサイン類似度を計算するため、1回の実行で大量のスロットを占有します。 社内ではBigQueryのジョブを共通の容量ベースプロジェクトで実行しています。そのため、Vector SearchがBigQueryの共有スロットを圧迫すると自チームの実行時間の増大やSLO超過だけでなく、他チームのクエリ遅延・タイムアウトを引き起こすリスクがありました。 また、今回のケースではBigQueryのスキャン量が少ないという特徴がありました。そこで、 オンデマンド課金用の専用プロジェクト を用意してVector Searchのみをそのプロジェクトで実行するようにしました。オンデマンド課金はスキャン量に対して課金されるため、コストを抑えつつ共有スロットへの影響を回避し、十分な計算リソースを確保できました。 運用事例 上記の汎用推薦システムを実際のMA施策に適用し、開発スピードと推薦精度の両面で効果を検証しました。 開発リードタイムの短縮 施策ごとに約10週間かかっていた推薦システムの構築が 約3週間 で完了し、 約1/3 に短縮されました。以下の表に、従来と汎用推薦システムの工程比較を示します。 工程 従来 汎用推薦システム 探索的データ分析 約2週間 不要（Embedding基盤を利用） モデルの設計・実装 約3週間 不要（Embedding基盤を利用） パイプラインの設計・実装 約2週間 約1週間（セグメント設定と既存パイプラインの利用） 実験・評価・チューニング 約3週間 約2週間（後処理によるチューニング） Embeddingを活用することで、探索的データ分析やモデルの設計・実装が不要になりました。また、パイプラインの設計・実装についても、セグメント抽出用のSQLを変更するだけで新しい施策に対応できるため、短期間で実装できるようになりました。さらに、実験・評価・チューニングではモデルのパラメータの調整が不要であり、過去の評価コンポーネントや実験の仕組みも再利用できるため、後処理のチューニングへ集中できるようになりました。 推薦精度の向上 従来のルールベースの推薦（Control）と汎用推薦システム（Treatment）のA/Bテストを実施し、以下の結果を得ました。 指標 有意差の有無 配信当たりのMA経由流入数 有意差ありの勝ち 配信当たりのMA経由購入数 有意差ありの勝ち 配信当たりのMA経由受注額 有意差なしの勝ち 主要KPIである配信当たりのMA経由流入数・購入数で統計的に有意な改善を確認したため、汎用推薦システムの本番導入に至りました。 まとめ 本記事では、ZOZOTOWNのMA施策向けに構築した汎用推薦システムについて紹介しました。 本システムは、EmbeddingとBigQuery Vector Searchを活用し、施策を横断して利用できる汎用的な推薦システムです。従来必要だった特徴量作成やモデル学習が不要になることで開発スピードを向上させつつ、Embeddingによりユーザーの潜在的な嗜好を反映した高い推薦精度を実現しています。 実際のMA施策への適用では、開発リードタイムを約10週間から約3週間に短縮しました。さらに、A/Bテストでは配信当たりのMA経由流入数・購入数の改善を確認し、本番導入に至っています。 今後の展望 今後は以下の取り組みを予定しています。 Rerankerの導入 : 現在のスコアブースト・フィルタリングはルールベースで煩雑なため、機械学習ベースのRerankerを導入し、MA施策に最適化されたチューニングを実現する セグメント設定の効率化 : セグメント定義をviewなどで共通管理し、パイプラインごとの再実装をなくす 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

CRM（顧客管理システム）、SFA（営業支援システム）、MA（マーケティングオートメーション）ツールの役割、機能、活用方法、選定ポイントを紹介しています。各ツールの目的や管理対象、主な機能を比較し、企業の活用事例や選定時のポイントを解説しています。

.table-of-contents > li > ul > li > ul > li { display: none; } はじめに こんにちは、データシステム部MA推薦ブロックの佐藤（ @rayuron ）です。私たちは、主にZOZOTOWNのメール配信のパーソナライズなど、マーケティングオートメーションに関するレコメンドシステムを開発・運用しています。本記事では、 GitHub Projects 、 BigQuery 、 Looker Studio を組み合わせて作業工数を可視化し、改善サイクルを回すための仕組みを構築した取り組みについてご紹介します。 はじめに 背景と課題 1. ボトルネックの特定に手間がかかり改善に着手しにくい 2. 工数に対する事業価値を把握できていない 3. AI活用の効果測定とナレッジの蓄積ができていない 解決策 1. GitHub Projectsの運用整備 カスタムフィールドの作成 自動入力の仕組み 2. データ収集の自動化 BigQueryへのデータ保存 GitHub Actionsで日次エクスポート 3. ダッシュボードと振り返り会の運用 週次振り返り 施策完了時の振り返り 半期振り返り 工数入力 効果 課題に対する効果 1. ボトルネックの可視化と改善 2. 工数と事業価値の関連付け 3. AI活用の効果測定とナレッジ蓄積 副次的な効果 今後の展望 フィールド入力の自動化 施策の優先度決めでの活用 AI活用のさらなる促進 おわりに 背景と課題 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では一緒にサービスを作り上げてくれる方を募集しています。ご興味がある方は以下のリンクからぜひご応募ください！ corp.zozo.com