サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
データ基盤チームの橋口です。この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム）ブログリレー2日目の記事です。 昨日は坂元さんの『冴えたClaude Codeの育て方（50本のSQLをdbt化した話）』でした。 私の所属するチームでは、社内のデータ活用サポート（データマート作成、分析支援など）を重要な業務の1つとしており、関連部門と一緒にプロジェクトを進める機会も多くあります。 関連部門とプロジェクトを進めていく中で、私は技術的な課題と同じくらい、ステークホルダーといかに上手く協業するかが大事だと学んできました。 なぜなら、データ利活用は「ビジネス課題の特定」から「どのデータを使うかの判断」、「技術的な実装」、「関係者との合意形成」まで幅広く、1人ですべてをカバーすることが難しい領域だからです。本記事では、私が日々の業務で学習した、ステークホルダーとの協業を円滑に
はじめに こんにちは。ucchi- です。普段は広告のデータを整えつつ、全社横断のデータ整備も行っています。 この記事では、以下 3 つのテーマについて紹介します。データ分析を自律的に行う「LLM Agent」 LLM Agent の能力を最大限に引き出す「LLM-Ready なデータ基盤」 LLM-Ready なデータ基盤を高速に構築するための「FlyWheel（改善サイクル）」 LLM Agent は対話を通じてデータ分析を行う まず、この記事における「LLM Agent」を定義します。これはデータ分析を自律的に行う大規模言語モデルであり、以下のように動作します。 LLM Agent に問いを投げかける LLM Agent は問いを解釈し、SQLクエリの生成、実行、結果の可視化、解釈を行う そこから自律的に分析を深掘りしたり、追加のフィードバックを求めたりする 参考）Google C
データ統合とは、組織の内外で管理されている多種多様なデータを1箇所に集約して利活用できる状態に整えたうえで、一元管理していくための取り組みです。 例えば企業では、営業部には顧客データ、経理部には会計データ、マーケティング部には分析データというように、さまざまなデータがそれぞれ異なるフォーマットで管理・運用されています。そうした多種多様なデータを統合して一元管理することで、最新データを安全に管理しながら利活用するための基盤が構築でき、迅速かつ正確な意思決定が可能になります。 データ統合は、IT部門や利用部門だけでなく企業経営においても重要な取り組みで、データ統合の実現可否が新規事業の創出や顧客体験の向上などの成果に大きく影響します。 この記事では、インターファクトリーでマーケティングを担当している筆者が、データ統合について解説します。 データ統合の必要性 経済産業省は「Society 5.0
背景: Data Vaultを運用し続けている事例の公開は多くない おさらい: Data Vaultとは何かデータ分析基盤におけるData Vault Data Vault自体の解説記事 Data Vaultを使った開発 withdbt Data Vaultを運用してよかったこと データモデリングを強制される ディメンショナルモデリングとの相性のよさ アリジティが高く、後から拡張ができるAIやLLM Agentとの相性がよい 履歴が使いやすい 運用する中で工夫が必要な点 データソースのスキーマに引っぱられないようにする すでに運用しているデータ分析基盤との付き合い方 Data Vaultの設計をできるメンバーをチーム内でどう増やすか full-refreshとどう向き合うか ハッシュキーの構成の順序問題 Data Vaultを採用すべきだったか? 宣伝: データエンジニアの採用やって
はじめに ナレッジワークでエンジニアをしている @_sisisin です 2025/04 にデータ基盤チームへ移ってきて初めてのデータ基盤屋さんをやっています 主に基盤の整備やデータ活用の支援をしたりしています この記事ではナレッジワークでのデータ基盤の現状を社内のメンバーへ共有する目的で書きました 内容的に公開できそうなので、Zenn に公開する形にしました ということで、この 2025/09 時点のデータ基盤の構成とその思想・経緯を残しておきます 前提の説明 - ナレッジワークのサービスについて ナレッジワークのサービス基盤について ナレッジワークでは主にGoogle Cloud 上にサービス基盤を構築しています 余談ですが、Poetics社とのM&Aからシステム統合を進めているJamRollというサービスがAWS上にあります こちらにもデータ活用のための基盤があるのですが、記事執筆
門脇（@satoru_kadowaki）です。2025年8月の「Python MonthlyTopics」は、データパイプラインやワークフロー、ETLで利用されるワークフロー・フレームワーク[1]「Prefect」について紹介します。 ワークフロー・フレームワークとは何か データを扱う現場では、定期的に実行する処理が必ず存在します。たとえば、指定した時間やタイミングでデータを集計したり、データがアップロードされたら自動でデータベースに反映したりするなど、一定のルールに基づいて処理を行うことがよくあります。 こうした処理は、最初はローカルでのスクリプト実行やLinuxであればCronジョブで十分に運用できます。また、AWSなどのクラウド基盤を利用している人は、Lambdaのようなイベント駆動による実行環境を作成して運用する事例も多いのではないかと思います。 しかし、シンプルな処理ではそれ
はじめに 「ダッシュボードを作りたい」「顧客の行動を可視化したい」「〜なKPIを追いたい」 データエンジニアなら必ず受けるこんな依頼。しかし、いざ作り始めようとすると「具体的に何のデータを、どの粒度で、どんな切り口で見たいのか？」が曖昧で、結果として使われないダッシュボードやデータマートを量産してしまった経験はないでしょうか。 私は過去1年間で、この「ビジネス要件をデータ基盤に落とし込む」という課題に対して3つの異なるアプローチを実践しました。監督者として、ファシリテーターとして、そして要件定義を委ねる形で。それぞれに成功と失敗があり、最終的に「戦略からの合意形成」の重要性にたどり着きました。 この記事では、それぞれのアプローチで何がうまくいき、何が失敗だったのかを素直に共有します。同じような課題に直面しているデータエンジニアの方に、少しでも参考になれば幸いです。 課題：ビジネス要件がわか
日本のプロ野球もデータで楽しむ時代に NPBがホークアイとGoogle Cloudで構築したシステムの仕組みは？：野球ゲームへの展開も視野に（1/2 ページ） 日本のプロ野球で、ホークアイのデータを活用した基盤システムの運用が始まっている。プロ野球の新たな楽しみ方を開拓していくという。これはどのような仕組みなのだろうか。 大谷翔平選手の大リーグでの活躍を追っている人たちは、ホームラン打球の軌跡を実写映像にオーバーレイしたビデオや、飛距離、打球速度、打球角度などのデータに基づく解説を日常的に目にしている。ピッチングに関しても、球種ミックス、速度、回転数、縦／横変化などが、選手自身の過去や他の選手とどう違うのかを知ることで納得したり、さらに興味がわいたりする。 日本のプロ野球でも、同様な楽しみ方を広げるデータ基盤の運用が始まっている。全12球団の球場で行われる全公式試合の詳細なプレーデータを集
データ分析基盤の構築において、個人情報保護とデータ活用のバランスは避けて通れない課題なのではないでしょうか。特に改正個人情報保護法により導入された「仮名加工情報」は、匿名加工情報よりも実用的（社内データ利活用において）で、企業内でのデータ活用を促進する上で重要だと思います。 ただし、実際の現場では「仮名加工情報と匿名加工情報の違いは何か」「仮名加工の技術はどのようなものがあるのか」といった疑問がよく出ると思うので、この機会に整理してみたいと思います。 具体的な技術だけではなく、設計に関しては以下の記事をご覧ください。 仮名加工情報の基本概念まずは仮名加工情報とは何なのかです。仮名加工情報とは、個人情報を他の情報と照合しない限り特定の個人を識別することができないように加工して得られる個人に関する情報です。 わかりやすい画像を拝借します。 情報の関係性（データプラットフォームにおけるパーソナル
データエンジニアが流行しだしてから数年が経過していますが、まだまだデータエンジニアリング分野は発展途上で、次々に新しいSaaSやツール、書籍が登場しています。 データエンジニアは、データの収集、分析、活用に必要なデータ基盤を構築・運用する職種です。企業によっては、データのマネジメントやその周辺知識も必要になります。データエンジニアとして活躍するためには、非常に幅広い知識と能力が求められます。 私がデータエンジニアとして業務を行う上で読んで良かったと心から思える本があったのでこちらで紹介します。どなたかの一助になれば幸いです。 初級向けデータエンジニアリング本ではありませんが、データエンジニアリングに必要な知識がスライドやPDFに綺麗にまとまっています。初めて学ぶ方には適しています。前半のデータエンジニアリングの箇所だけ参考にして下さい。（後半はAzure製品について記載されています） 注
はじめに生成AIの台頭とデータエンジニアリングへの影響生成AIが急速に発展しており、私だけではなく、恐らく全世界の知的労働に勤めている人々は衝撃や恐怖を感じているのではないでしょうか？ データエンジニアリングの分野でも、生成AIは既存の業務プロセスを大きく変わりつつあります。コード生成、データパイプラインの自動化、ドキュメント作成など、これまで手作業で行っていた作業の多くが、AIのサポートで効率化できるようになってきました。 データエンジニアの未来は明るいはず生成AIによって現状の仕事の代替は進んでいくと思いますが、それなりにキャッチアップをしていれば仕事が無くなるとは私は思っていません（どの職種にも言える部分はありますが）。 詳細は以下に書いていきたいと思います。 1.データエンジニアの現状と変化ETLパイプラインやコーディングの自動化GitHub CopilotなどのAIコーディング支
こんにちは。ウォンテッドリーでバックエンドエンジニアをしている市古（@sora_ichigo_x）です。 最近は Enabling チームとしての役割を持ち、Visit の新規開発や、バックエンドアーキテクチャの改善に取り組んでいます。 現在、Enablingチームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は冨永さんによる「AWSのSESとSQSを活用したメール受信機能の実装」 でした。今回は、GitHub x BigQueryで開発行動量を可視化する社内基盤の紹介をしたいと思います。 はじめに なぜ行動量を見るのか 新しい取り組みの変化はまず行動に出る 何を見ているのか 可視化する指標はシンプルにするGitHub 行動量を KPI 化してはいけない 余談：初期プロトタイプ時点での要求一覧 どうやって可視化しているか Big
こんにちは、おきゆきです。Ubieでデータ関連業務を担当しています。 4月9日に開催されたTokyodbt Meetup #13にて、「dbtとLightdashを社内へ浸透させるまでの取り組み」というテーマで発表させていただきました。当日は多くの方にご参加いただき、たくさんのご質問、誠にありがとうございました！ その中で特にコメントが多かったのは、「データエンジニアが1人の状況で、dbtとLightdashを利用する月間PR作成者が35人以上というのは、具体的にどのようにデータマート開発を進めているのか？」「品質はどのように維持しているのか？」「データモデリングの知見はどのように共有しているのか？」といったご質問でした。 具体的には、以下のスライドで示した数値についてです。 https://speakerdeck.com/okiyuki99/integrate-dbt-and-ligh
AWSのリソース全般とSnowflakeのテーブル以外のリソースはTerraformで管理し、Snowflake のテーブル関連リソースはdbtで管理。コードの自動フォーマットと本番デプロイする仕組みをGitHub Actionsで構築。 IaCとCI/CDにより、属人化予防とリリースサイクル高速化を実現。 Snowflakeは用途別（データ連携 / データ整形 /データ分析）で3アカウント作成し、Data Sharingでデータ共有する仕組みを構築。 アカウントを分離することにより、権限管理の簡素化を実現。dbtは開発環境にOSSのdbt Coreを採用し、本番環境にSaaSのdbt Cloudを採用。dbt Coreとdbt Cloudを使い分けることにより、dbt Cloudのランニングコストを抑制。 社内のデータ分析・利活用を目的として、2021年頃からデータ分析基盤の構築が
Dbt Labsのデータ分析ツールは、2020年まではフィラデルフィアにある小さなコンサルティング会社のサイドプロジェクトに過ぎなかった。ただ、ユーザーのエンゲージメントは当時から非常に高かった。 同社のCEOを務めるトリスタン・ハンディによると、それから5年の期間と1回のピボットを経て、このツールの有料顧客数は5000社以上、年間経常収益（ARR）は1億ドル（約152億円）以上にまで成長し、今では同社の中核事業になったという。 ハンディは、今から約10年前にデータアナリストとして不便なソフトウェアを扱うことに不満を感じたことから、その頃Fishtown Analyticsと呼ばれた企業を立ち上げた。当時は、アマゾンのRedshiftやFivetranなどのクラウドベースのデータツールが普及していたが、開発者たちはそれらを最大限に活用する方法を知らなかったため、彼はコンサルティングサービス
最近『データエンジニアリングの基礎』という本を読み始めた。 この本の冒頭で、データエンジニアリングやデータエンジニアの定義は曖昧で、人によって言っていることがバラバラだという話が出てくる。そこで著者たちは自分たちなりの定義を示し、それに則ってデータエンジニアリングの全体像を解説することを試みている。 「データエンジニアリング」が指すものが定まっていない、というのは自分も日々実感している。指すもの、イメージするものが、人や組織によって違いすぎる。 単に言葉の定義の問題ではなく、「データエンジニア」と称される人が実際に何をやっているのかは、組織によって本当にバラバラだと思う。 そんな状態なので、各組織の各データエンジニアが何をしているのか外からはよく分からないだろうし、データエンジニアが何に面白さを感じているのかも世間に伝わりづらいと思う。 この記事では、私が HERP のデータエンジニアとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
