ID:85092さん

【概要】 ECサイト運営企業向けに、EC実績・広告実績・GA4等の複数データをGoogle Cloud上へ統合し、BI・AIによる分析まで利用できるデータ基盤を構築。 体制：4名 役割：データ基盤の技術設計・実装を主担当 【課題】 ・約150件の既存ファイル・データ群が散在し、必要／不要、重複、統合キー、データ粒度が整理されていなかった ・データソースごとにAPI、Spreadsheet、Cloud Storage等、取得方法や更新頻度が異なっていた ・BIだけでなく、将来的なAI分析にも利用しやすいデータ構造が必要だった 【担当・実装】 ・約150件のデータについて、利用目的、項目、粒度、重複、統合キー、更新頻度、取得方法を調査し、必要データを選定 ・データ同士の統合方法を整理し、60以上のBigQueryテーブルをほぼ全て設計・実装 ・10以上の外部サービスについてAPI仕様を調査し、API利用可否、取得可能データ、利用方法を整理 ・顧客側でAPI連携を実装できるよう、サンプルコードを含む実装手順書を作成 ・DataformでSQLX、テーブル間の依存関係、実行スケジュール、テストを設計・実装 ・Looker Studioによる分析環境を構築 ・Conversational Analyticsの管理画面をカスタマイズし、自然言語で分析できる環境を整備 ・BQMLによる売上予測について、モデル選定、学習、評価まで一連の検証を実施。顧客側の検証に対する技術的な質問対応・アドバイスも担当 ・PLとして技術設計・レビュー・メンバーへの技術的な指示を担当。スケジュール管理や顧客対応等は他メンバーと協働 【成果】 ・散在していたEC・広告・GA4データを一元化し、売上と広告実績を横断分析できるデータ基盤とダッシュボードを構築 ・データの重複、統合キー、粒度から整理することで、BI・AI双方から利用しやすいデータ構造を実現

【概要】 HubSpotデータを中心としてBigQuery上に構築された、売上実績・KPI・案件進捗・商談管理等のデータ基盤および12ページ構成の日次更新Looker Studioダッシュボードの保守・改善を担当。 体制：3名 役割：BigQuery / SQL / TROCCO領域を主担当 【課題】 ・約200テーブルが存在し、実際に利用されているテーブルや依存関係が整理されていなかった ・命名規則やSQLの記述方法が統一されておらず、変更時の影響範囲を把握しづらかった ・過去データの修正・確認作業に毎月約8〜30時間を要していた 【担当・実装】 ・Looker Studioの参照データソースを起点に、BigQuery Table / View、Scheduled Query、TROCCOの処理を遡って依存関係を調査 ・クエリだけでは判断できないテーブルについてはBigQueryのメタデータ等も確認し、実利用テーブルを特定 ・既存SQLを解析し、売上、案件進捗、KPI、商談管理等の集計ロジックを改修 ・代表例として、クーポンによる値引きを売上へ反映する集計ロジックを変更 ・お客様の入力ミスによる修正対象をGoogle Sheetsへ入力し、TROCCO Workflowを実行することでBigQueryへ反映できる仕組みを設計・実装 ・再実行時に二重反映等が発生しないよう冪等性を持たせて実装 ・BigQuery / SQL / TROCCO領域は主に単独で担当 【成果】 ・約300テーブルの実利用状況と依存関係を整理し、変更時の影響範囲を把握しやすい状態へ改善 ・毎月約8〜30時間発生していた過去データの修正・確認作業を約2時間まで削減 ・手作業を減らし、修正ミスのリスクも低減

【概要】 Looker Studioを利用する社内業務を効率化するため、Chrome拡張機能を2種類単独で設計・開発。 開発体制：単独開発 利用者：約10名 【開発① フィールド定義Collector】 【課題】 ・レポートの仕様確認時に、各ページ・グラフの使用フィールド、集計方法、データ型、フィルタ条件等を手作業で確認していた ・必要な情報の一部はDOMから取得できなかった ・収集した指標定義を、AIエージェントやBigQuery上の元データと対応付けやすい形式にする必要があった 【担当・実装】 ・Looker Studio内部のNetwork通信を調査し、通信レスポンスから必要情報を取得する方式を採用 ・全ページ・全グラフのフィールド定義を自動取得 ・Google Apps ScriptをバックエンドWebアプリとして実装し、Google Sheetsへ自動出力 ・AIエージェントへ渡しやすいよう、指標定義をBigQueryのカラム名に統一 ・指標定義をSQL表現として自動生成する仕組みを実装 ・SQL表現とすることで、自然言語による定義の曖昧さを減らし、元となるBigQueryのテーブル・カラムやテーブル生成SQLとも照合しやすい構造に設計 【成果】 ・従来手作業だった仕様確認・指標定義整理を自動化し、1回あたり約2時間の作業を削減 ・AIを利用した後続処理にも接続しやすい、構造化された指標定義を作成可能にした 【開発② Looker Studio Formatter】 【課題】 ・複数指標の数値、%、通貨等の表示形式を手作業で設定していた ・レポート自体を操作・変更するため、誤操作による意図しない変更を防ぐ必要があった 【担当・実装】 ・Chrome Extension Manifest V3を利用して実装 ・MAIN world、ISOLATED world、background service workerを役割に応じて使い分け ・「選択グラフ」「現在ページ」「レポート全体」の3範囲で表示形式を一括変更できる機能を実装 ・処理前後の状態を確認し、想定した状態と一致しない場合は処理を停止する安全制御を実装 【成果】 ・表示形式変更の手作業を1回あたり約10分削減 ・設定作業の標準化と人的ミス低減に寄与

【概要】 欠品によって観測できない潜在需要を推定し、商品ごとの適切な仕込み数量を算出するため、Python / PyMCによる需要推定・在庫最適化モデルのPoCを実施。 体制：2名 対象：約500商品以上、約1年間の実データ 【課題】 ・完売した商品は、その後に発生した可能性のある需要を売上データから観測できない ・単純に実績売上を需要として扱うと、欠品商品の需要を過小評価する可能性があった 【担当・実装】 ・商品・カテゴリの階層構造、曜日、気温等を考慮した階層ベイズ・負の二項回帰モデルを設計 ・完売データを右打ち切りとして扱う尤度を実装 ・完売時刻を需要発生過程へ組み込むモデルへ拡張 ・MCMCによるパラメータ推定・収束診断、シミュレーションデータによる検証を実施 ・実データへモデルを適用 ・推定需要分布と欠品・過剰在庫コストを組み合わせ、商品別の推奨仕込み数量を算出するロジックを実装 ・2名でモデル設計・検証を実施し、私は検証方針や追加で確認すべき事項を整理して共有するとともに、追加検証を担当 【実データ検証後の対応】 ・実データに異常値が含まれており、十分な予測精度を得ることが難しいことを確認 ・モデルの複雑化だけで対応せず、今後予測精度を高めるために取得・改善すべきデータを整理して顧客へ提案 ・現状では需要予測の高度化よりも、廃棄ロス削減施策の方が短期的な利益改善につながりやすいと判断し、施策の方向性も提案 ・実データ検証まで実施し、本番運用への導入は未実施

【概要】 複数クライアントを対象に、広告媒体の実績データとGA4で計測したWebサイト上の行動・成果データをBigQuery上で統合し、Looker Studioで広告成果を確認できるレポートを構築・運用。 新規構築期間：1案件あたり約1〜2週間 体制：主に単独担当 実績：新規構築10件、保守・運用30件以上 【課題】 ・広告媒体側の実績とGA4側の成果データを同一キャンペーン等として紐付ける条件を事前に設計する必要があった ・運用担当者のUTMパラメータ設定によっては、想定した条件で正しく統合できない場合があった ・既存案件の数値差異やエラーについて、初見のSQLやデータ構造から原因を調査する必要があった 【担当・実装】 ・広告データとGA4データを統合するためのUTMパラメータ等の条件を整理し、広告運用担当者へ共有 ・BigQuery上で広告実績とGA4成果を統合・集計するSQL、テーブルを設計・実装 ・Looker Studioで広告成果を確認できるレポートを構築 ・数値差異発生時には、Raw Data、SQL、統合条件、GA4で計測されたパラメータ、広告側のUTM設定を確認して原因を調査 【エラー対応例】 UTMパラメータの設定誤りにより、本来とは異なるデータが結合され、実績値が過大に表示される事象が発生。 広告運用担当者へ設定意図を確認した上で、その意図どおりの結果になるようSQLおよびテーブルの統合ロジックを修正しました。あわせて設定ミスを共有し、以後正しいパラメータを設定するよう運用面も修正しました。 【成果】 ・広告運用担当者が顧客向けの広告成果を集計・レポーティングする作業を効率化 ・クライアント側も同じレポートを参照できるようにし、広告代理店とクライアント間で数値・成果認識を共有しやすい環境を整備 ・複数案件の保守を通じ、初見のSQL・データ構造でも処理ロジックを読み解き、数値差異やエラーの原因を調査・修正する経験を蓄積