データエンジニア ポートフォリオ

dbtを使ったデータ変換・モデリング、分析用データマート構築の専門家

一貫して「データを活用して社内チームをサポートする」ことにやりがいを感じてきました。

営業事務時代(2011-2013年):花苗メーカーで、前任者がExcelを扱えず目視確認のみで在庫管理していた課題を解決するため、Excel VBA・マクロを独学で習得。通販担当社員へのヒアリングから業務課題を明確化し、3つのデータソース(通販サイト在庫、社内在庫、卸元在庫)を統合する管理システムを構築。CSV取込により「添付するだけで瞬時に在庫バランスを可視化」できる仕組みを実現。システム導入により、通販商品全体で前年比120%、多い商品では前年比130%の売上を達成。営業部長を経由して社長から「正確ですごく早い」と評価され、通販事業部から「前任者ができないことをやってくれた!本当にありがとう!」と評価していただきました。これが私の「データエンジニアリング」の原点となりました。

旅行代理店時代(2014-2019年) - 💡 原体験その1:「データで人の役に立つ喜び」を知った原点:Google Analyticsで閲覧数・回遊率を分析し、Webページのデザインやメールマガジンのコンテンツを改善。独自選定ツアーのメルマガで前週比1.3倍の反応率を複数回達成(通常は0.8〜1.1倍)。上司から「作ったメルマガの反応良いよー!」と評価していただいた経験が、私にとって最も嬉しい瞬間でした。この「データ分析→施策実行→結果確認→評価」というサイクル全体に関わることで、自分の貢献が可視化され、社内チームの成果に繋がっていることを実感できました。データ分析で1.3倍の成果を達成し、チームから感謝された経験が、「データで貢献したい」という軸の出発点となりました。

産後・業務委託時代(2022-2023年) - 💡 原体験その2:「エンジニアリングが必要」と気づいた転機:子育てをしながら、ECサイトのマーケティング補助として、データ分析に触れ続けました。フルタイムは難しい状況でしたが、データに関わる仕事を完全に離れたくなかったのです。手入力で2時間かかっていた資料作成業務を、Excel数式・関数の活用により30分に短縮(75%削減)する業務効率化を実現。しかし、この期間中、私がまとめたデータがクライアント企業で全く使われていないことが判明しました。理由は、データの使い方が分からない、データ分析の方法が分からない、データよりも優先すべきことが多い、という3点でした。日本企業の多くが、市場にあふれる貴重なビッグデータを使いこなせていない現実に愕然としました。H.I.S.やサントリーフラワーズでの経験から、データを活かせば確実に効果が出ることを実感していたからこそ、このギャップが衝撃でした。この経験から、「データ分析だけでは不十分。データ基盤(エンジニアリング)がなければ、分析も活きない。だから自分自身がエンジニアになる必要がある」と気づき、データエンジニアを目指す決意を固めました。

データエンジニア時代(2024年1月~現在):データエンジニアとして1年11ヶ月、大手企業向けの分析用データマート実装に従事。アパレル4ブランドのマーケティングタグ管理基盤の統合移行(2,724項目のテスト実施、タグ発火率99.8%達成)、BIデータマート実装(分析リードタイム96%削減)、SFCC API連携のリトライ処理実装、モバイルアプリデータリカバリー対応、大手不動産企業空港事業部向けIPOCAレポートSQL作成・移動データ異常値補正など、技術的なスキルを習得しました。

しかし、データ整備だけでなく、「データを分析し、施策を提案し、チームの成果に貢献し、評価していただく」という一連のプロセスに関わりたいと強く思うようになり、転職を決意しました。また、現職では全体像(なぜこのデータが必要か、誰がどう使うか、どんな成果を目指すか)が見えず、最適な提案ができないことにも課題を感じています。

次のキャリアでは、BtoB SaaS企業で社内チームを支援する分析用データマートを構築し、dbtを使ったデータ変換・モデリングのスキルを活かしながら、企業向けサービスのデータ分析・施策提案まで一貫して関わり、全体像が見える環境で社内チームに貢献できる仕事を実現したいと考えています。

🔧 なぜ技術を磨くエンジニアの道を選ぶのか

データ基盤という「仕組み」で、チーム全体を支えたい

私がエンジニアとして技術を磨くことにこだわる理由は、「仕組みによる持続的な支援」を実現したいからです。

旅行会社時代、メールマガジン施策で前週比1.3倍の反応率を達成した経験から、「データ分析→施策実行→結果確認→チームへの貢献」というサイクルに大きなやりがいを感じました。しかし、その後のマーケティング補助の仕事で、私が整えたデータがクライアント企業で全く使われていない現実に直面しました。理由は、データの使い方が分からない、分析方法が分からない、優先順位が低い、というものでした。

この経験から、「分析だけでは不十分。データ基盤(エンジニアリング)がなければ、分析も活きない」と気づきました。

現職では、データエンジニアとして1年11ヶ月、この信念を実践してきました:

主な実績

  • 分析リードタイムを2日から30分に短縮(96%削減):マーケティングチームが毎日データで意思決定できる環境を構築
  • タグ発火率を95%から99.8%に改善:データ品質を根本的に向上させ、チーム全体の分析精度を向上
  • 月40時間の作業時間削減、完全自動化を実現:手動作業をゼロにし、チームがより価値の高い業務に集中できる環境を提供

個別の依頼に都度対応するのではなく、データパイプラインという「仕組み」を構築することで、チーム全体が自律的にデータを活用できる環境を作る。これが、私がエンジニアとして技術を磨き続ける理由です。

次のキャリアでは、dbtやBIツールを使った分析寄りのデータエンジニアリングを通じて、社内チームの成果を最大化し続けたいと考えています。

5件以上
大規模プロジェクト
96%
処理時間削減
99.9%
システム稼働率
500万+
日次処理レコード

技術スタック

BigQuery
Treasure Data
Python (3年以上)
SQL (6年以上)
Digdag
Cloud Functions
GA4/GTM
Tableau
ETL/ELT
JavaScript
Tealium
Braze
API連携
データモデリング
Claude/Cursor
GitHub Copilot

スポーツアパレル企業 SFCC API連携による大規模商品データ取込基盤構築

データエンジニア(実装担当)|期間:2025年8月~(現在継続中)|チーム規模:3名
Salesforce Commerce Cloud SCAPI Products APIを用いた商品マスタデータ自動取込システムを開発。1日あたり最大2万件の更新が発生する大規模データを、API制限やエラーに対応しながら確実に取得する仕組みを実装。 API制限(20件/リクエスト、レスポンスサイズ10MB上限、1,500件/期間)への適応的期間分割(バイナリサーチ)、Response Entity Too Largeエラーの自動処理(最大5回リトライ)を実装。

主な成果

  • OAuth 2.0認証(Client Credentials Flow)とトークン自動更新機能による長時間処理の安定化
  • バイナリサーチによる適応的期間分割アルゴリズムで、データ量に応じて日単位・時間単位を自動切り替え(1,500件超で自動分割)
  • 10万件単位のバッチ処理とメモリクリアによる効率的な大容量データ処理
  • 150項目以上のカラムマッピング辞書による自動変換(キャメルケース→スネークケース)
  • 5段階CTE処理による重複排除と完全なデータ正規化
  • 外部ベンダーへの技術質問文書の作成(主体で担当):大量データ取得における技術的課題を明確化
  • 外部ベンダーからの質問に対する回答文書の作成(主体で担当):やり取りの文章も主体で作成・管理
Treasure Data Digdag Python requests pytd pandas SFCC SCAPI OAuth 2.0 Presto SQL

大手不動産企業 空港事業部 GPS位置情報異常値検出・補正システムの開発

データエンジニア(実装担当)|期間:現在継続中|チーム規模:2名
国内旅行レンタルデバイスから収集されるGPS位置情報の異常値を自動検出・補正するシステムを開発。 時速1000km超の非現実的な移動、V字型異常パターン、座標の急激な変動により、正確な旅行経路分析が困難だった課題を解決。

主な成果

  • JavaScript UDFによるHaversine公式を用いた球面距離計算アルゴリズム
  • 時速1000km超の非現実的な移動検出、V字型異常パターン検出、適応的傾向分析による座標補正
  • Window関数(LAG/LEAD/FIRST_VALUE/LAST_VALUE)を活用した時系列データ処理と日付間の連続性担保
  • 450行超のSQLクエリを10段階以上のCTE処理に分解し、ARRAY_AGG/UNNESTによる配列データ処理
  • 旅行経路分析の精度向上により、ビジネス判断の質を改善
BigQuery Standard SQL JavaScript UDF Haversine CTE Window関数

学習管理システムとBigQueryを連携するETLパイプライン構築

データエンジニア
企業向け学習管理システムの利用データを分析基盤に集約するため、日次でデータを自動取得・変換・格納するETLパイプラインをGCP上に構築。 個人情報保護のためAES-256暗号化を実装。

主な成果

  • Cloud FunctionsでのPython ETLパイプライン開発(約6種類のデータ処理)
  • AES-256暗号化による個人情報保護(暗号化キーはSecret Managerで管理)
  • Cloud Loggingと連携した2段階アラートシステム(WARNING/ERRORレベル)
  • 日次バッチの安定稼働率99.9%を達成
  • エラー発生から対応までの時間を平均30分以内に短縮
BigQuery Cloud Functions Python cryptography AES-256 Secret Manager OAuth 2.0

アパレル4ブランド マーケティングタグ管理基盤の大規模統合移行プロジェクト

データエンジニア(実装・検証担当)|期間:2024年6月〜2025年1月|チーム規模:3名
アパレル4ブランドのタグ管理システム(Tealium、Braze、LINE STAFF START、Silver Egg、Repro等)をGoogle Tag Manager(GTM)に統合移行。 総作業項目数:2,400以上(変数:886個、トリガー:393個、カスタムHTMLタグ:646個、タグ構成:548個)、総テスト項目数:2,724項目。

主な成果

  • Tealium→GTMのマッピングシート作成(4ブランド中2.5ブランド分を担当)
  • カスタムHTML/JavaScriptタグ開発(646個のロジック移植)
  • GA4イベント設計・実装(11種類:view_item_list、view_item、sign_up、search、begin_checkout、add_payment_info、purchase、refund、remove_from_cart、add_to_cart、view_cart)
  • 網羅的テスト実施:2,724項目(変数テスト1,068項目、拡張機能テスト689項目、GA4タグテスト448項目、その他タグテスト519項目)
  • タグ発火率を95%から99.8%に改善(2,724項目の網羅的テストにより全タグの正常動作を確認)
  • 4ブランドの並行移行を完遂
Google Tag Manager GA4 JavaScript dataLayer Tealium Braze LINE STAFF START Silver Egg Repro

不動産投資会社向けBigQueryデータ分析基盤構築

データエンジニア(設計・実装担当)|期間:2024年2月(短期集中開発)|チーム規模:3名
物件評価・税務計算の自動化システムをBigQueryで構築。 Excel管理されていた物件情報(購入検討物件100件以上)の分析が属人化していた課題を解決。 固定資産税・都市計画税の計算が手動で、ミスが頻発(10%のエラー率)していた問題を自動化により解決。

主な成果

  • 90カラム以上の大規模テーブル設計(物件基本情報、税務情報、賃貸情報)
  • 700行超のSQLクエリ開発(5段階CTE)
  • 複雑な税務計算ロジックの実装(想定/実績の2パターン対応)
  • 文字化けデータ(Shift-JIS/UTF-8混在)、日付フォーマット不統一の完全クレンジング
  • 投資判断のスピードを3日から即日に短縮
  • 税務計算の正確性が100%に向上(手動計算時は10%のエラー率)
BigQuery StandardSQL Google Sheets API CTE

スポーツアパレル企業 BIデータマート実装・大規模データ集計基盤開発

データエンジニア(実装担当)|期間:2024年6月〜(現在継続中)|チーム規模:5名(エンジニア3名、アナリスト2名)
年月週日別・チャネル別・会員属性別の多次元集計データマートを実装。 経営層が必要とする売上分析が、複数のデータソースを手動で結合して行われており、分析に2日以上かかっていた課題を解決。

主な成果

  • 300行超の大規模SQLクエリ開発(12パターンのUNION ALLで多次元集計を実現)
  • 5段階CTEによる段階的データ加工とWindow関数(DENSE_RANK、ROW_NUMBER)による購買順序・顧客判定
  • 2018年以降の全取引データ(約500万レコード)を10分以内で集計
  • 分析リードタイムを2日から30分に短縮(96%削減)
Treasure Data Presto SQL Tableau CTEs Window関数 Digdag

大手玩具メーカー マーケティングデータ連携基盤の構築

データエンジニア(実装担当)|期間:2024年4月〜(現在継続中)|チーム規模:3名
Salesforce Marketing Cloud(マーケティングオートメーション)から分析基盤(Treasure Data)へのSFTP経由自動データ連携パイプラインを構築。 月40時間の作業時間が手動データ連携に費やされていた課題を解決。

主な成果

  • YAMLベースの設定ファイルとDigdagワークフローによる日次バッチ自動化(約10万レコード/日)
  • データ型不整合問題(Long型に空文字混入)を2段階処理で解決(L1層String型→L2層Long型変換)
  • ログ分析により2時間以内に問題特定し、3時間以内に本番環境修正完了
  • 月40時間の作業時間削減、手動作業ゼロの完全自動化を実現
  • 技術文書(テーブル定義書、ワークフロー仕様書、テスト項目書)を整備し、保守性を向上
Treasure Data Digdag SFTP Presto SQL YAML

スポーツアパレル企業 SFCC Customer APIリトライ処理実装

データエンジニア(実装担当)|期間:2025年11月4日~11月13日|チーム規模:3名
Salesforce Commerce Cloud(SFCC)からTreasure Dataへの顧客データ取込処理において、一時的なネットワークエラーやAPIサーバー側の問題により処理が失敗するケースが発生していた課題を解決するため、自動リトライ機能を実装。

主な成果

  • Digdagワークフローにリトライ設定を追加(リトライ回数上限:3回、リトライ間隔:120秒)
  • Pythonスクリプトで各エラーパターンに対する例外処理を実装
  • 検証環境での全エラーパターンテスト実施(0件エラー、4xx/5xxエラー、401認証エラー等)
  • 本番環境での実運用動作確認(500エラー発生時の自動リトライ成功を確認)
  • 一時的なエラーからの自動復旧機能を実現
  • 運用負荷の軽減(エラー発生時の手動リラン作業が不要に)
Treasure Data Digdag Python OAuth 2.0 SFCC API

スポーツアパレル企業 モバイルアプリ行動データ取込エラー リカバリー対応

データエンジニア(リカバリー実装担当)|期間:2025年11月7日~11月10日|チーム規模:2名
モバイルアプリ行動データ連携基盤において、データ提供元がS3バケットへのデータ配置を行わなかったため、行動データの取込が0件となるインシデントが発生。データ復旧後のリカバリー対応を実施。

主な成果

  • Embulk設定ファイル(behavioral_data.yml)の修正(リカバリー対象日の固定値設定)
  • timeカラムの固定値設定(UNIXタイムスタンプ:1762441200 = 2025-11-06 00:00:00 JST)
  • ワークフロー手動実行によるリカバリー処理実施
  • 11/6分の行動データ(787,303レコード)を正常に取込
  • データの連続性を維持
  • 実作業時間1時間でリカバリー完了
Treasure Data Digdag Embulk AWS S3 Presto SQL Hive
💻

SQL Analytics Toolkit

実務で使用した分析SQLクエリ集

BigQuery Presto SQL
コードを見る →
🐍

Python Data Pipeline

ETL/ELTパイプラインの実装例

Python BigQuery API
コードを見る →

💫 キャリアストーリーと価値観

私のキャリアは、一見バラバラに見えるかもしれませんが、すべて「データを通じて一緒に働く人をサポートし、評価していただく」という一貫した価値観で繋がっています。

営業事務時代(2011-2013年)
花苗メーカーで、前任者がExcelを扱えず目視確認のみで在庫管理していた課題を解決するため、Excel VBA・マクロを独学で習得。通販担当社員へのヒアリングから業務課題を明確化し、3つのデータソース(通販サイト在庫、社内在庫、卸元在庫)を統合する管理システムを構築。CSV取込により「添付するだけで瞬時に在庫バランスを可視化」できる仕組みを実現。システム導入により、通販商品全体で前年比120%、多い商品では前年比130%の売上を達成。営業部長を経由して社長から「正確ですごく早い」と評価され、通販事業部から「前任者ができないことをやってくれた!本当にありがとう!」と評価していただく。「データで需要と供給のバランスを取ることで、売上に貢献できる」「一緒に働く人をサポートする喜び」を実感。これが私の「データエンジニアリング」の原点:複数データソース統合、業務理解に基づく設計、ビジネス価値の創出。
大手旅行代理店時代(2014-2019年) - 💡 原体験その1:「データで人の役に立つ喜び」を知った原点
💡 原体験その1:「データで人の役に立つ喜び」を知った原点
Google Analyticsで閲覧数・回遊率を分析し、Webページのデザインやメールマガジンのコンテンツを改善。独自選定ツアーのメルマガで前週比1.3倍の反応率を複数回達成(通常は0.8〜1.1倍)。上司から「作ったメルマガの反応良いよー!」と評価していただいた経験が、私にとって最も嬉しい瞬間でした。
この「データ分析→施策実行→結果確認→評価」というサイクル全体に関わることで、自分の貢献が可視化され、社内チームの成果に繋がっていることを実感できました。データ分析で1.3倍の成果を達成し、チームから感謝された経験が、「データで貢献したい」という軸の出発点となりました。
SQLでこれまで整理しきれていなかった分析データを抽出。Pythonでデータ整形・集計し、予測を立ててWebデザインに活用。データドリブンなWebデザインにより、閲覧数や回遊率が如実に変化。「全体像(なぜこの施策が必要か、誰のためか、どんな結果を目指すか)が見えるから、最適な提案ができる」ことを実感。
産後・業務委託時代(2022-2023年) - 💡 原体験その2:「エンジニアリングが必要」と気づいた転機
子育てをしながら、ECサイトのマーケティング補助として、データ分析に触れ続けました。フルタイムは難しい状況でしたが、データに関わる仕事を完全に離れたくなかった。検索連動型広告管理のデータ整理・集計・分析、売上管理のデータ整理・集計・分析、Google Analytics・キーワードプランナーを活用したSEO対策資料作成。手入力で2時間かかっていた資料作成業務を、Excel数式・関数の活用により30分に短縮(75%削減)。重要な気づき:私がまとめたデータがクライアント企業で全く使われていないことが判明。理由は、データの使い方が分からない、データ分析の方法が分からない、データよりも優先すべきことが多い、という3点でした。日本企業の多くが、市場にあふれる貴重なビッグデータを使いこなせていない現実に愕然としました。H.I.S.やサントリーフラワーズでの経験から、データを活かせば確実に効果が出ることを実感していたからこそ、このギャップが衝撃でした。決意:「データ分析だけでは不十分。データ基盤(エンジニアリング)がなければ、分析も活きない。だから自分自身がエンジニアになる必要がある」と気づき、データエンジニアを目指す決意を固めました。
データエンジニア時代(2024年1月~現在)
データエンジニアとして1年11ヶ月、大手企業向けの分析用データマート実装に従事。アパレル4ブランドのマーケティングタグ管理基盤の統合移行(2,724項目のテスト実施、タグ発火率99.8%達成)、BIデータマート実装(分析リードタイム96%削減)、SFCC API連携のリトライ処理実装、モバイルアプリデータリカバリー対応、大手不動産企業空港事業部向けIPOCAレポートSQL作成・移動データ異常値補正など、技術的なスキルを習得。しかし、データ整備だけでなく、「データを分析し、施策を提案し、チームの成果に貢献し、評価していただく」という一連のプロセスに関わりたいと強く思うようになる。

転職を決意した理由

データエンジニアとして技術的には成長していますが、3つの大きな課題を感じています:

1. 全体像が見えない

何が見えないのか:Why(なぜこのデータ基盤が必要か)、Who(誰がどう使うか)、What(どんな成果を目指すか)

何が問題なのか:全体像が見えないと、最適な提案ができない。「このデータ構造の方が、後で分析しやすいのでは?」と提案したくても、誰がどう使うか分からないので提案できない。全体像が見えないことで、齟齬が生まれて無駄な作業が増え、会社にとって不利益

大手旅行代理店時代との違い:大手旅行代理店では、メルマガの目的(ツアーの予約数増加)、対象(過去の顧客)、成果指標(誘客率)がすべて明確だった。だから、データを見て「こういうツアーを紹介すべき」と施策を考えられた

2. 貢献実感がない

何が見えないのか:このデータが、どう分析されているのか、どんな施策に繋がっているのか、どんな成果が出ているのか、マーケティングチームや営業チームが、どう活用しているのか

何が問題なのか:データを整備しても、それがどう役立っているか分からない。「データを整備する」だけで終わってしまい、「データを使って施策を考え、結果を確認する」という一連のサイクルに関われない。貢献が可視化されないため、成長実感が得られない

大手旅行代理店時代との違い:大手旅行代理店では、「データ分析→施策実行→結果が数値で見える→上司から評価していただく」という完結したサイクルがあった。自分の貢献が可視化され、上司から「私のメルマガの反応良いよー!」と評価していただいた

3. フィードバックが得られる機会がない

現職の状況:ミスの指摘や注意の言葉は来るが、ポジティブなフィードバックがほとんどない。「データ基盤を整備した」という技術的な貢献はしているはずだが、誰からも評価していただけない

自分にとって重要な理由:自己肯定感が低いため、評価していただくことで「自分の存在価値」を実感できる。大手旅行代理店時代の「私のおかげで反応良いよー!」という言葉が、最も嬉しい瞬間だった。一緒に働く人から評価していただくことが、仕事のモチベーションになる

大手旅行代理店時代との違い:大手旅行代理店では、上司や同僚から直接「ありがとう」と言われる環境だった。社内チームへの直接貢献だったからこそ、評価していただく機会があった

理想の職種:「データエンジニア + アナリスト(マーケティング支援)」

  • データに触れる時間:80-100%
  • 仕事内容:dbtを使ったデータ変換・モデリング + データ分析 + 施策提案
  • 貢献先:社内チーム(マーケティング・営業等)への直接貢献
  • 成果確認:結果を数値で確認し、評価していただける環境

大手旅行代理店時代の「データ分析→施策実行→結果確認→評価」というサイクルをもう一度経験したい。データエンジニアリングのスキルと、以前の分析経験を組み合わせることで、社内チームに対してより大きな価値を提供できると考えています。

💡 新たな気づき:本当にやりたいこと

データエンジニアとして働く中で気づいたこと:

  • 「データに触れるだけでは足りない」:データ変換・モデリングだけでは、満たされない。大手旅行代理店時代の「データ分析→施策→結果確認→評価」というサイクル全体に関わりたい
  • 「全体像が見える環境で働きたい」:Why/Who/Whatが分からない状態で作業をするのは、自分にとって苦痛。全体像が見えて初めて、最適な提案ができる
  • 「社内チームへの直接貢献がしたい」:エンドユーザーの反応よりも、一緒に働く人から「私のおかげで」と評価していただきたい。マーケティングチームや営業チームが「データのおかげで分析が楽になった」「施策が成功した」と喜んでくれる環境
  • 「データエンジニアリング + 分析・施策提案 = 理想の仕事」:dbtを使ったデータ変換・モデリングのスキル(強み)を活かしながら、データ分析・施策提案まで一貫して関わる。これが、自分にとって最も価値を発揮できる働き方

転職先に求める環境

Must条件

  • ✅ フルリモート・フルフレックス
  • ✅ 全体像が見える環境(Why/Who/Whatが明確)
  • ✅ 社内チームへの直接貢献
  • ✅ 結果が数値で確認できる
  • ✅ ポジティブなフィードバック文化(評価していただける環境)
  • ✅ データに触れる時間が80%以上

Want条件

  • ✅ 分析・施策提案の機会がある
  • ✅ データエンジニアリング + アナリスト業務のハイブリッド型
  • ✅ 提案できる余地がある