経歴のスタート地点
新卒でtoC向けのEC企業に入り、マーケティング部門でデータアナリストとして3年が経った。SQLでDWHからデータを抽出し、TableauやLookerでダッシュボードを構築する。施策の効果測定、ファネル分析、コホート分析——分析の依頼は次々と来て、社内では「データのことならまず里沙さんに」と頼られる存在になっていた。
仕事は楽しかった。意思決定の現場に分析結果が反映され、施策が改善される瞬間は何度味わっても新鮮だった。けれど、ある時期から自分の仕事の天井が見え始めた。私は「すでに用意されたデータを取り出して可視化している」だけで、その源流であるデータ基盤のことを何も知らない——そう気づいたのは、3年目のある障害対応のときだった。
最初のつまずき
ある朝、ダッシュボードの数値が前日比で異常な値を示していた。私は焦ってデータエンジニアチームにSlackした。返ってきたのは「ETLパイプラインのジョブが昨夜失敗してて、再ラン中。1時間後にデータ揃います」という説明。ETLって何?再ランって何?ジョブが失敗するってどういう状態?——基本的な単語が、私には全く分からなかった。
そのとき初めて、自分が「データを使う側」の最末端にいて、データを「作る側」の世界が完全にブラックボックスだと痛感した。Pythonは少し書けたが、データパイプラインを設計したことなんてない。クラウド(AWS/GCP)は名前を知っているだけ。Linuxサーバーにssh一度もしたことがない自分に愕然とした。
転機
転機は、データエンジニアチームのリーダーが社内勉強会で話した一言だった。「データアナリストとデータエンジニアは、本来地続きの仕事です。SQLが書けるなら、データパイプラインも設計できる素養はある。むしろ、ビジネス文脈を理解しているアナリスト出身者が基盤側に来ると、最強です」
その言葉で、自分の進む道が見えた。データを「作る側」に行くことは、いまの分析スキルを捨てることではなく、上に積むことだ。社内のローテーション制度を使って、半年後にデータエンジニアチームへの異動希望を出した。上司は最初は反対したが、半年かけて学習計画と異動後の貢献ビジョンを資料化して説得した。
いま振り返る選書
異動を見据えて1年、計画的に本を読み込んだ。
- 『新しいLinuxの教科書』:sshでサーバーに入る、ログを追う、cronを設定する——アナリスト時代には触れなかった世界の入り口を作ってくれた一冊。
- 『AWS基礎からのネットワーク&サーバー構築』:S3、EC2、RDS、IAMといった基本概念を、手を動かしながら学べた。クラウド恐怖症が消えた。
- 『GCP実践ガイド』:会社のデータ基盤がBigQuery中心だったので、必須の本だった。BigQueryをSQLで叩いていた自分が、それを「動かす側」を理解する助けになった。
- 『LeanとDevOpsの科学』:データ基盤運用の文化を学んだ。Four Keysの考え方は、データパイプラインのSLO設計にも応用できた。
- 『継続的デリバリー』:データパイプラインのCI/CDという概念を初めて知った。それまでは「手動でジョブを回す」世界しか知らなかった。
- 『Docker/Kubernetes 実践コンテナ開発入門』:データエンジニアリングの現場ではコンテナが当たり前。手を動かして写経した。
- 『Infrastructure as Code』:Terraformでデータ基盤をコード管理する思想。「再現性のあるインフラ」という概念が衝撃だった。
現場での実践
異動後、最初に任されたのは既存ETLパイプラインの監視強化だった。失敗時にSlack通知が飛ぶ仕組みを、自分でPythonとAirflowで実装した。最初のプルリクエストは50箇所以上指摘を受けたが、レビューを通じてコードの作法が体に染み込んだ。
半年後、新規のデータマート構築を一人で任された。要件定義から設計、Terraformでのインフラ構築、Airflow DAG実装、SLOの設定まで——アナリスト時代には想像もできなかった広い領域を、一気通貫で担当できるようになった。「使う側」を経験している自分だからこそ、利用者目線で設計できるデータマートが作れた。
これから挑む人へ
データアナリストからデータエンジニア/SREに進みたい方へ。SQLが書けることは大きな武器です。多くのデータエンジニアは、データを「使う側」の文脈を知らないまま基盤を作っている。アナリスト出身者は、その文脈を持ち込める。
クラウドやLinuxは、後から学べる。ビジネス文脈を理解する力は、後から身につけるのが難しい。あなたが持っている武器を、私は信じています。

