Beyond Your Data Engineering 2026 - お前の考える狭いデータエンジニアリングの枠組みを越えてゆけ #data_summit_findy by @Kazaneya_PR
10.6K Views
October 09, 26
スライド概要
技術カンファレンス「Data Engineering Summit」の資料です。
本資料内で紹介しているサービスの一部はプライベートβ版（非公開）となります。
https://kazaneya.com/3b370d0c5ac8804c9c24c3f6ec850085
関連スライド
各ページのテキスト
Data Engineering Guide 2026 with AI Agent Beyond Your Data Engineering 2026 （お前の考える狭いデータエンジニアリングの枠組みを越えてゆけ） 2026-10-09 Data Engineering Summit 基調講演 Keynote 株式会社風音屋 横山 翔（Sho Yokoyama） @yuzutas0 #1
注意事項① 1. 2. 3. 4. 本資料は許諾した範囲内でのみご利用ください。無断転載ならびに複写を禁じます。 本資料に記載されている会社名・製品名などは、一般に各社の登録商標または商標、商品名です。 資料内では ©, ®, ™ マーク等は省略させていただいております。 本資料は特定企業の情報公開や称賛・批判を意図するものではありません。社名が提示されていない ケーススタディやシステム構成は、原則的に複数企業の事例を踏まえたダミー情報となります。 説明を簡略化するために、用語やツールの紹介は厳密な定義に則っていない場合があります。ご自身 や所属チームでの理解・解釈が紹介内容と異なる場合は、適宜読み替えていただけると幸いです。 #2
注意事項② 1. 2. 3. 4. 5. データエンジニアに向けた講演であり、他職種が読むことを想定しません。業界への愛ゆえの叱咤激 励が続きます。他職種を対象とした講演では今回とは大きく異なるメッセージをお伝えしています。 宣伝が主目的ではありませんが、どうしても宣伝のようになってしまう点はご了承ください。 ○ 風音屋は「データエンジニアリング業務で必要となる知識・武器」を提供している会社です。 ○ 代表が「こういう会社が世に必要なはずだ」という信念を持って立ち上げ、運営しています。 ○ データエンジニアリングについて話をすると、どうしても「こういう点が課題になりやすい」 「だから風音屋ではこういうソリューションを提供している」という説明になってしまいます。 データエンジニアリングに関するカンファレンス講演ですが、強いて技術面でキーワードを挙げると するなら「Markdown」「Cloudflare」「Rust」への言及がメインになります。ご注意ください。 ○ 本資料の作成後、10/1にCloudflareが分析基盤「Basin」の提供を発表、9/24のRails Worldに てRails作者のDHHがRustで担当製品を作り直した旨を発表し、両技術ともに業界の中心地にあ ることが再認識されています。 生成AIによる「毒にも薬にもならないコンテンツ」が溢れている現状との差別化を図り、メッセージ を伝えるために、インターネットミーム・パロディ・漫画の引用を意図的に多用しています。 災害、紛争・戦争、事故・事件、難病といった人命に関わる出来事に言及しています。登壇者自身が 業界貢献の動機としているためです。こうした内容に抵抗感がある方はご退出をお願いします。 #3
本講演の概要（当初の予定） https://data-engineering-summit.findy-tools.io/2026 #4
#ultra_soul ギークなエンジニアくんが本当に欲しいのは、これ。 ネットミームや少年漫画のパロディまみれでホッカホカにしてさ、冷えたビールでやりたい。だろ？ だけど今のご時世、迂闊なことを言うとあまりに叩かれるから ● ● AIがそれっぽくまとめた小綺麗なスライド ベンダーのブランドレビューが通った無難なトーク で、ごまかそうっていうんだ。ダメなんだよそれじゃ。 せっかく冷えたビールでスカッとしようって時に。 🍻 そんなんじゃかえってストレスが溜まる。 聞けなかった本音（リアル）がちらついてさ。全然すっきりしない、心の毒は残ったままだ。 登壇ってのはさ、小出しじゃダメなんだ。やるときはきっちりやった方がいい。 Note：スベったときは「（会場が）キンキンに冷えてやがる」でもう一勝負。倍プッシュだ……！ 参考：福本伸行『逆境無頼カイジ 破戒録編』 #5
本講演の概要（変更版） ＜タイトル＞ Beyond Your Data Engineering 2026 お前の考える狭いデータエンジニアリングの枠組みを越えてゆけ ＜趣旨＞ 「二宮金次郎」型のデータエンジニアが報われる時代ではないか。 “職域を与え、越境を免ずるのはデータエンジニアを救う道ではない。 それはただ貪欲と無頼を招くだけであり、 勤勉と自助だけがこれらのキャリアを救う道である。” ＜目次＞ 1. 去年のおさらい＋Diff 2. 扱うデータの話 3. 技術選定の話 4. アーキテクチャの話 5. 人材・キャリアの話 https://www.ninomiya.or.jp/kinzirozo/ #6
偉人の言葉をお借りして、今日のメッセージをまとめると…… 戸愚呂（弟）：おまえもしかして、まだ自分が死なないとでも思ってるんじゃないかね？ →耳障りの良い「AI時代でもデータエンジニアは大丈夫」に甘えるな！油断すると未来はないぞ！ アンディ・グローブ：もし我々が解雇されて、新しいCEOが連れて来られたら、その人は何をするだろう？ 今から一度この部屋を出て、新しいCEOになったつもりで戻ってきて、自分の手でそれをやるのはどうだ？ →もし今のデータエンジニアたちが失職する（あるいは就職・転職できなくなる）未来になったとして、 別の誰かがデータエンジニアリング業務を担っているのだとしたら、その人は何をしているのだと思う？ 二宮金次郎：金銭を与え、租税を免ずるのは彼らを救う道ではない。 それはただ貪欲と無頼を招くだけであり、勤勉と自助だけがこれらの村を救う道である。 →データエンジニアやアナリティクスエンジニアと職種名を区切り、ラクな形に担当範囲を区切り、 「これが自分の業務だ（これ以外はやらない）」「このツールの利用経験者は世に少ないから安泰だ」と 甘ったれたことを言って「聖域」化しても、中長期を見据えるとポジティブな未来にはならない。 マジメに日々の学習や挑戦を積み重ねて、価値貢献をしていくしか自分のキャリアを守る道はねぇんだよ！ ミッキーマウス（王様）：助けてもらうことじゃなくて、助けることを考えるべきだったんだ！ →どうやったら自分のキャリアを守れるかじゃなくて、どうやったら社会のニーズに応えられるかを考えろ！ 『幽遊白書』『パラノイアだけが生き残る』『二宮翁夜話』「Kingdom Hearts Ⅱ」およびその解説記事を元に一部記載を調整 #7
自己紹介 #8
自己紹介 https://data-engineering-summit.findy-tools.io/2026 #9
風音屋（かざねや） データエンジニアリング＆データマネジメントの実践フレームワークを提供する「知識インフラ」企業 クライアント 下調べ 理 解 風音屋の提供サービス 担当者はデータ基盤を 知っている？ NO 一部抜粋 YES 普及・ 人材育成 社内ではデータ基盤の 理解が進んでいる？ YES クライアント 内製組織で 体制化 基盤構築を進める？ 講演資料や書籍 例：データマネジメントが30分でわかる本 NO NO 研修・学習プログラム 例：風音屋データマネジメント検定、K-DEC 育成 プロフェッショナルサービス 例：データ基盤構築・保守運用 運営 世の既存ツールで ムリなく運営できる？ NO 知識プラットフォーム 「Data Samurai」 システム 開発 YES 実 践 コンテンツ提供 知見 業務支援ツール 例：NOXAS Sheets Lineage 加速 YES データエンジニアリングAIエージェント 例：風音屋MCP、風音屋Agent Skills Skills/MCP化 #10
知識プラットフォーム「Data Samurai」 ● ● ● テーマごと＆ステップごとに「10分動画」＋「理解度チェックテスト」による知識習得。 Agent Skills & MCPを提供し、学習内容を実践に繋げる。メンバーは内容を理解した上でAIに指示。 「自社はこの内容を実践できているか」サーベイ回答やスキルマップによる組織アセスメント支援。 #11
風音屋データマネジメント検定 新卒・全社研修で使えるように、Excel業務を題材にデータマネジメントの全体像と勘所を解説。 https://prtimes.jp/main/html/rd/p/000000007.000057831.html #12
データ基盤構築のハンズオン教材「K-DEC」 累計260ページ・18万文字の超豪華な研修教材を読み、データ基盤構築のハンズオンを実施。 https://prtimes.jp/main/html/rd/p/000000005.000057831.html #13
業務支援ツール「NOXAS」シリーズ 例：1クリックでスプレッドシートの依存を可視化する「NOXAS Sheets Lineage」 #14
支援実績（一部抜粋） ※許諾を得た 一部事例のみ公開 https://kazaneya.com/case #15
去年のおさらい #16
Data Engineering Summit 2025 基調講演 スライド235枚でデータエンジニアリングの全体像を解説した。 https://speakerdeck.com/kazaneya/20251106 #17
‘25で話したこと：データ活用の事例 KPIモニタリング、政策/経営/投資戦略、マーケティング施策、オペレーション改善/RevOps、異常検知、 レコメンド、ダイナミックプライシング、経路探索、月面探査、古文書解読、環境保護/農作物管理etc… https://speakerdeck.com/kazaneya/20251106 #18
‘25で話したこと：データ整備の意義 複数のデータと利用者を繋ぎ、SSoTを実現することで、データ活用のサイクルを回せるようになる。 ディメンショナルモデリングやセマンティックレイヤーはそのための仕組み。 https://speakerdeck.com/kazaneya/20251106 #19
‘25で話したこと：データテクノロジーのシステム構成 BIツール、DWH、ストレージ、ETL/ELT/ReverseETL、 ワークフローエンジン、データカタログ、IaC、CI/CD、 データ取得（API/DB/ログ/ファイル）、データ仮想化、 レイヤリング/データモデル etc… https://speakerdeck.com/kazaneya/20251106 #20
‘25で話したこと：利用促進・保守運用の勘所 ● ● ● ● データ品質、SLO、テスト、監視、チューニング コスト管理・モニタリング セキュリティ、権限管理、監査ログ 利用状況、ガイド、問い合わせ対応 etc… https://speakerdeck.com/kazaneya/20251106 #21
【理解→実践】を【組織化】する これらの内容のうち、何％を実現できているか？ 1. 2. 3. 4. 実践していくにはどうしたら良いか？ 自組織におけるデータエンジニアリングの「業務一覧」および各「業務手順書」を作成する。 各業務に必要な「知識・技能」を一覧化し、それぞれの「学習ガイド」を整備する。 各メンバーの「知識・技能」の習熟度（スキルマップ）や「業務」の担当状況（アサインシート）を 書き出し、誰がいつまでにどうステップアップするのか、育成計画・アサイン計画を立てる。 メンバー1人1人がガイドに沿って学習し、知識習得・技能向上に伴って担当できる範囲が広がると、 結果として、データ組織の価値創出・事業貢献が広がったり、深まったりする。 データエンジニアリング組織の立ち上げやデータエンジニアの採用・育成・評価には上記が必要となる。 「上記を推進できるマネージャー」と「素直に自己学習・挑戦できるメンバー」が揃うのが理想。 …だが、現実としてサポートが必要になることは多い。 風音屋の技術顧問・コンサルティングでは各社ごとに上記をカスタマイズ整備＆伴走してきた。 それをパッケージ化・プロダクト化したのが「Data Samurai」の学習支援・スキルマップ機能。 #22
1. 去年のおさらい + Diff #23
風音屋のデータエンジニアリングAI さらに「業務一覧」「手順書」を整備できれば、そのままAIエージェントに仕事を渡すことができる。 一連のデータエンジニアリング業務はAgent Skillsで担えるようになった。 例えば、風音屋ではデータエンジニアリングエージェントで仕様調査・基盤構築・運用保守を行っている。 （本資料作成時の）直近1週間で @yuzutas0 が使った Agent Skills の例は以下。一部抜粋。 Snowflake管理 Skill、BigQuery管理 Skill、DWHコストチューニングSkill、dbt管理 Skill、Dataform 管理 Skill、 Airflow管理 Skill、Step Functions管理 Skill、Digdag管理 Skill、データリネージ調査 Skill、 RDSデータ連携 Skill、HubSpotデータ連携 Skill、Notionデータ連携 Skill、データ品質管理 Skill、 Lightdash管理 Skill、Redash管理 Skill、データ可視化・グラフ作成 Skill、分析レポート作成 Skill、財務分析 Skill、 SQLリファクタリング Skill、データモデリング Skill、Open Metadata管理 Skill、DataHub 管理 Skill、 メタデータ管理・更新 Skill、オントロジー管理・更新 Skill、権限設計・管理 Skill、データ利用者サポート Skill etc… ※データ利用者向けのガイド、サポート、チュートリアルも専用Skills（/guide, /support, /tutorial）を 整備・配布することで、データ利用者がAIエージェントの補助を受けられるように促せる。 ※「Data Samurai」のAIエージェント機能では、これらの一部をMCPとして提供している。 ※フィジカルAIやロボット時代には物理世界に作用するための手順が同様にSkillsされていくはず。 #24
「データ活用」の業務フロー＆サイクルを描き、AIネイティブなDataOpsに切り替える ヒアリング、連携依頼、QA（テスト・検算）など専門書から漏れがちな「熟練者の手順」まで組み込む。 次の仮説・課題 担当者 業務ステップ エージェント スキル ーーーーーーーーー 作業手順書 + スクリプト + テンプレート コンテキスト 依頼者 分析者 データ分析を依頼 要件定義 ソフトウェアエンジニア 分析者 データ取得 データ加工 データ分析・報告 ＜アウトプットのイメージ確認＞ ・過去にこういうレポートがあるけど近い？ ・こういうデータがあるけど近い？ ＜依頼＞ ・関連部署へ データ連携依頼 ＜ELT開発＞ 設計→実装→テスト →リリース ＜分析＞ 集計→検算→可視化 →考察→レポート ＜背景・意図・ゴールの確認＞ ・目的Aと目的Bで見るべきデータは違うが今回は XXXだからAであっている？ ・あなたの所属部署はC、担当業務はDだから、 ゴールはEで、◯年分のデータFを取得して、 こうやって活用したいという理解でOK？ ・基幹システムへ データ連携依頼 ＜ETL開発＞ 設計→実装→テスト →リリース ＜詳細の確認＞ ・データFはH業務で作られているので、 J項目だけはK日後に反映されるけど問題ない？ 組織図、業務一覧・詳細、システム一覧・詳細、データ一覧・詳細、過去の分析レポート etc…… #25
エージェントスキル（業務手順書） ● ● ● ● AIエージェントに渡す業務手順書をエージェントスキル（Skills）と呼ぶ。 「メール返信をしたい」と指示すると、自動でSkillsを読み込んで、手順に沿って作業を行う。 ○ 新入社員が指示を受けて自分でマニュアルを読むようなイメージ。 エージェントスキル自体をAIエージェントに改修させることもできる。 ○ 新入社員がマニュアルの不備を見つけたらその場で直してもらうようなイメージ。 テキストファイルに書き出す。 ○ 人間が読みやすい手順を作れば、 AIにも読みやすいスキルになる。 #26
あらゆる業務手順をエージェントスキル（Skills）にまとめる 風音屋のバックオフィス部門で使っているSkills ● ● 定例会議の録画ファイルを読み込んで、部署のロードマップを更新するための手順。 経理データを読み込んで、毎月のコスト上位をリストアップし、中身を精査するための手順。 企業のあらゆる業務をAI前提（AIネイティブ）に作り変えることができる ● ● 業務一覧 = エージェントスキルの一覧 業務手順 = エージェントスキル 定期トリガー どのみち誰かがやっていることを改めて明らかにするだけ ● ● ● 担当者の脳内で管理するのか Wordに手順書として書き出すのか AIエージェントが読める場所に書き出すのか 人間 Skills PC端末 AIエージェント 対象業務 ……の違いでしかない。 #27
その業務の【入力】【処理】【出力】を定義し、AIエージェントにコンテキストを与える ● 人材採用業務なら「採用基準」と「社内記録」と「履歴書」を照らし合わせて判断する。 ○ 例：風音屋が採用業務で使っているスカウト判定AI。 選考 結果 #28
HITLによるコンテキスト拡充 ● ● AIのアウトプットを人間が確認・修正し、社内ルールや過去のメッセージ例に追加する。 例：年末年始のメール返信なら「今年もお世話になりました」「来年もよろしくお願いします」と 添えることが望ましい。 メールの 返信文を作って プロンプト 社内ルール、過去の文例集 署名欄テンプレ コンテキスト アウトプット AIエージェント （作業を行う） 人間が手直し #29
AIで半自動化できる箇所を特定する AI導入によって「人間」の作業＆判断を減らし、ムダ・ムラ・ムリを解消する。 Input 入力 Processing 加工 Output 出力 契約書PDF 内容確認 署名済みPDF 自社署名 締結 取引記録 相手署名 NEW! ■ヒトがやるべきこと （入力と確認） ■AIが一部担えること （草案作成＆懸念指摘） ■DXで実現できること （加工と出力） #30
今のところ「手順書をベースにしたワーカー」として扱うのが（自分には）向いている ● ● ● CxOクラスの人材とのミーティングや飲み会でスムーズに会話が進む「あの感じ」に至っていない。 「手順に沿って作業や判断をする」という観点だと、人間よりも高性能なワーカーだと感じる。 平均的な人間の労働者も、連休明けにコンテキストがリセットされたり、体調やモチベーションでレ スポンスエラーが増えたり、複数の話題やキーワードが混入するとコンテキスト汚染でパフォーマン スが劣化する（＝マネジメントによるサポート介入が必要になる）ので、そこの差は感じない。 真面目さが必要な（手順が多い／チェックが細かい）業務 「Aさんが頑張って調べてくれたなら一旦それで行こう」と言われる業務 DocsとSlackから 会話を洗い出して メタデータ入力する 新規ツールの 使い方を手順化する 今のAIが強い箇所 今のAIをシバけば出来る範囲 エラー通知から バッチ失敗の原因と 解消方法を調査する 設計ポリシーや 命名の社内標準を ゼロから作る ノールックApproveは まだムリかな〜って範囲 要領の良さ（何を省けるか／何を抑えるべきか）が必要な業務 「Bさんが比較検討して決めてくれたなら一旦それで行こう」と言われる業務 #31
ベテラン視点だと「早くなる仕事／早くならない仕事」があるが、どちらも恩恵が大きい ● ● ● ● ベテランが1日で行う設計にAIは2日かかる。ベテランがショートカットする検討までやってしまう。 ベテランが1週間かけるサーベイをAIは半日で行う。物量が多い作業をマジメに進めてくれる。 ベテランが1度に1つしか集中できない一方で、AIは複数セッション同時かつ24/365で動ける。 ベテランが作業タイムを確保して集中モードに入るまでの時間で、AIはセッションを開始できる。 月曜 火曜 水曜 木曜 金曜 ベテラン 設計 AI（ベテラン指示） 平均的なワーカー ベテラン サーベイ AI（ベテラン指示） 平均的なワーカー #32
AI時代に再評価すべき「良い習慣」by 🍊 ● 朝の参拝⛩ / 黙想🧘 - 今日フォーカスすべき目標を絞り込んで宣言する。 ● ポモドーロ🍅 - ダラダラとAI作業を続けるのではなく25分で強制的に切り上げる。 ● シャワー🚿/ 散歩/ 筋トレ💪/ トイレ🚽 - 作業の合間に脳をリフレッシュさせる。 ● 読書📖 / 映画🎥 - マルチタスクではなく1つのコンテンツにじっくり集中する。 ● 睡眠 🛏 / 食事🍴/ 有酸素運動 🏊 - 脳の老廃物を流して血流と酸素が巡るようにする。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ※1日10時間AIエージェントを使う前提での話です。 ● ● AIエージェント漬けの生活を送った上で、副作用を乗り越えるために良い習慣を取り戻せという話。 AIエージェントを使えていない状態で「毎日ちゃんと◯◯やっています」は当たり前。 #33
スクラムによるAIシフトの優先順位付け（ROIの最大化） スプリントプランニング ● その週の作業計画を立てる。 ● 【想定工数ｘ繰り返し頻度】等から優先順位をつけて、それらの業務をSkills化する。 レトロスペクティブ ● その週の作業を振り返り、各作業の【貢献成果ｘ実績工数】等から改善すべき箇所を特定する。 ● 人間による軌道修正や追加作業に時間を費やした箇所があれば、Skillsを改修する。 ○ 「やらなくていいこと」（ムダな作業）を先に取り除くと尚良し。 この繰り返しでAIシフトを進める ● 「実際に必要な作業」から順に AIエージェントに渡せるので、 結果的にROIが最大化される。 What 何をするか スプリント プランニング スプリント レビュー デイリー スクラム どうやってするか How レトロ スペクティブ #34
「手順化」を求められる環境＋素直に「手順化」に挑める人材 風音屋が公開した「SQLの組み立て方」のように「ベテランが無意識でやっていること」を「新入社員が再 現できる手順」に落とし込む、「センスや経験」で片付けずに「手順やノウハウ」に落とし込む。 ● ● 書籍や記事の執筆、取引先や他部署への説明資料の作成、手順書や研修資料の整備を繰り返している 人は、この技能を習得しやすい。フィードバックを受けて見直していると尚良し。 ○ ジュニア層なら自発的にTechBlogを書きまくって先輩にレビューをもらうのが最短ルートか。 逆に「エンジニアなのに資料作成や顧客折衝をやらされるのは勘弁だ」と言って逃げてきた人は逆境 に陥ってしまうかも。コードを書くことだけがエンジニアリングではないと見直す機会かも。 https://techblog.kazaneya.com/20241208-design-of-analytical-sql-queries/ #35
「ドキュメント化」を求められる環境＋素直に「ドキュメント化」に挑める人材 ● ● 風音屋の採用ページでもお伝えしているように「ドキュメントを書くこと」=「記録を取ること」= 「データを整備すること」なので、データ活用を推進する立場、データエンジニアリングやデータマ ネジメントの業務を担う立場なら、ドキュメンテーションを重視するのが自然な発想のはず。 「なぜ自分がドキュメンテーションをしないといけないのか」「それはテクニカルライターの仕事 だ」と言って逃げてきた人は逆境に陥ってしまうかも。「ETLツールやBIツールを使うことだけがデー タエンジニアリングではない」と見直す機会かも。 https://kazaneya.com/ad7aec5c2920428cb293ae5d7e876b60 #36
「ノウハウ化」を求められる環境＋素直に「ノウハウ化」に挑める人材 風音屋のようなクライアントワークだと、A社の案件を通してノウハウ化（＝Agent Skills化）した後、 B社の案件でAIエージェントによる安定デリバリーが可能になる。 ● ● A社の案件も他案件で確立されたノウハウにもとづいているので、社内で1から始めるよりも効率的と 言える。B社やC社でのノウハウも後にA社に還元されるので、継続的に恩恵を受けられる。 従来であれば、ジュニア人材3人ｘ3チームｘ3ヶ月（＋@yuzutas0が睡眠時間を犠牲にして伴走）で ようやく出せるような成果を、1人ｘ1ヶ月で安定して出せるようになった。27倍以上の生産性向上。 たとえ内製化してもコアメンバーの離任・転職で知識が断絶するので、担当者の脳内に依存するのではなく 「再利用可能なツールキット」をベースにして業務を回せると望ましい。そのための寄る辺が必要。 ● ● ● 風音屋では「Data Samurai」にて「人間が学習・参照できるコンテンツ」ならびに「AIエージェント が利用可能なSkills / MCP」として、再利用可能なツールキットを配布している。 ユーザーはメモ機能＆カスタム機能やコントリビュート＆フィードバックを通して、自分なりのノウ ハウを反映できる。転職先でも「Data Samurai」を使えば前職での成功パターンを使い回せる。 将来的には月1万円まで利用料を下げて、データを扱う世界中の組織の知識インフラとして風音屋の データエンジニアリング＆データマネジメントのテンプレートを浸透させたいところ。 #37
2. 扱うデータの話 #38
社内コンテキストを管理・集約する 日々の仕事で人間は「非構造化データ」を無意識のうちに処理している ● ● ● ● ● ● ビジネスモデル、事業計画、沿革、創業者の口癖 お客様の声（VoC）、契約理由・解約理由、クチコミ・評判 稟議ワークフローのメモ欄、会計ソフトのメモ欄 体制図、会議体、関係者一覧、Aさんとの会話のコツ カレンダー、メール、チャット 業務マニュアル、作業手順書、作業記録 先輩社員が新入社員に口伝で引き継ぐような知見をドキュメント化し、AIのインプットにする L 全体広報 ● ● ● ● 新入社員向けの「これを読んでおけ」リスト オンボーディング資料 ◯◯業務 虎の巻 Bさんの自分用メモ（部署の全員が参考にしている） L ビジネス L リソース L システム # 戦略、KGI/KPI # ヒト、モノ、カネ、情報（新規メンバーのJoinメニューやエンジニアレジュメは「ヒト」の下） # アプリやインフラの構成など（あくまでもロゼッタストーン） L 施策 L 運用 # プロダクト・システム・プロセスを改善する施策 # カスタマーサポート、プッシュ通知の配信、インフラ保守といった個別作業 L プロセス L イベント # 立案から価値創出までのバリューストリーム（→ KPTを通して改善する） # 定期的な打ち合わせや指標確認（→ 組織全体で可視化すると重複や無駄が目立つようになる） L 個人 # Inbox代わり #39
2種類のコンテキスト ①業務のルール・定義・前提 ● ● ①基礎 社内用語、業務の流れ、マニュアル、担当部署といった基礎となる情報。 配属された新人に一刻も早く覚えてほしい内容。 ⇒SharePointやGoogleDrive、社内Wikiに書いて、リンク集からパス・URLを参照できるようにする。 ⇒データエンジニアリング業界は「メタデータ」「オントロジー」といった概念で扱おうとしている。 ②個別の記録・数値・実績 ● ● ②記録 契約書、議事録、取引記録、仕訳表など1件1件のデータとして蓄積された情報。 ベテランでも1件1件を暗記しているわけではなく、毎回調べたり読み直すような内容。 ⇒条件に応じて検索できるようにデータベース化する。 ⇒従来のデータ基盤（ストレージ、DWH製品、BIツール等）が主に対象とした「データ」はこれらを指す。 #40
データエンジニアリングはコンテキスト管理を含むか - 【②記録】について ②記録 A：構造化データのみを扱うパターン ● ● 従来のデータエンジニアの多くが「これが私の仕事のスコープです」と言いがちだった。 さらに言うと、データ取得箇所をデータエンジニア、データ加工箇所をアナリティクスエンジニアと いった職域に分けて、ただでさえ狭い仕事をさらに狭くすることが「この業界の当たり前」だった。 B：非構造化データも扱うパターン ● ● DWH + BIで実現したかったことは「集計ができる」ではなく「分析／活用ができる」だったはず。 広告のクリック件数だけでなくマーケキャンペーンの企画書も扱えたほうが分析精度は上がるはず。 （という考え方） ⇒クラウドストレージの自動メタデータ付与機能やベクトル検索ソリューションは日々充実している。 ⇒不動産やインフラ系の事業者では、紙の契約書を取り込んで検索・参照できるようにするプロジェクトを データエンジニア職のメンバーが担当しているケースもある。同様のケースは今後も増えていくはず。 #41
38億年のデータ管理の歴史のうち、従来のデータエンジニアリングが対象とした領域 AIによる 狭い、狭すぎる…！ 磁気・光・電子によるデータ管理の時代 対応力向上 ● 35年前 - 1990年代：IT革命による一般家庭への通信技術の普及 ◯：表形式のデータベース ● 45年前 - 1980年 ：DAMA Internationalの設立 ● 65年前 - 1960年代：リレーショナルデータベースの台頭 △：ファイルストレージ （画像ファイル等） ● 85年前 - 1940年代：現代のコンピュータ及び周辺技術が台頭 日本にて紙によるデータ管理の時代 ● 300年前 - 江戸中期：文書主義で各地の記録が始まり、データ経営が可能になる △：撮影、スキャン、OCR ○ 例：裾野市 横山家、600の村を経営再建したコンサルタント 二宮金次郎 ○ 例：収穫高（事業KPI）、住民台帳（人事マスタ）、取引明細（経理トランザクション） ● 1300年前 - 奈良時代：天皇家を中心に記録が始まる（例：横山姓が祖と称す小野氏＠古事記） 人類文明にて外部装置によるデータ管理の時代 ● 5千〜3千年前 - 「粘土板＠メソポタミア」「パピルス＠エジプト」「竹簡/木簡＠中国」に記録 ● 1万年前 - メソポタミアの粘土片（トークン）で家畜や穀物を記録・計測 地球にて生体によるデータ管理の時代 △：バイオインフォマティクス etc… ● 5億年前 - 脊椎動物が経験データを記憶するための脳を持つようになる ● 38億年前 - 原生生物がRNAから遺伝子記録（DNA）と生命活動（タンパク質）を分離する 他にも印刷技術（データの移動・複製）や複式簿記（ACID特性を伴うリレーショナルモデリング）など歴史的な転換点は多数！ #42
非構造化データの置き場（ストレージ）等のテクノロジー選定における地政学的リスク 一方で、技術発展と裏腹に、情報技術やデータ管理における地政学的リスクが顕在化した1年でもあった。 ● ● ● ● アカウントの検閲・介入・削除（例：Googleアカウントや決済サービスが突然使えなくなる） データの検閲・介入・削除（例：政府が各事業者に相手国ユーザーのデータを提出させて軍事利用） クラウドベンダーの利用停止・制限（例：Claude Fable のリリース停止措置） データセンターの破壊（例：AWSの中東リージョンが爆撃によってデータ復旧不可） これらも昔から続く問題で、WWⅡ後にはGHQが各地の神社に保管された古文書を消している。 静岡県小山町の岩田氏（yuzutas0の先祖筋の1つ /『太平記』の新田氏を祖と称す）による 1498年の南海トラフ地震の記録も原本が失われ、地震研究では在野研究者の写しが流用される。 リスクヘッジとして以下の関心が高まるが、実用性とのトレードオフも無視できない。 ● ● ● GoogleDriveではなくProton Driveを使う。 クラウドAIではなくローカルAIを使う。 国産のデータセンターやAIサービスを使う。 『御殿場市史 第1巻 (古代中世・近世史料編)』、『防災科学技術研究資料 第35号（1979）』 #43
データエンジニアリングはコンテキスト管理を含むか - 【①基礎】について A：読み取りだけを担うパターン ● ● ①基礎 @yuzutas0は8年前（2018年）時点でデータ組織に社内留学制度（業務理解を深める仕組み）を整備したり、登壇資料で事業理 解のステップを述べたのだが、「大事なのは分かるけどNot for meだ」という（自称）データエンジニアがあまりにも多かっ た。とにかく仕事を狭めたいらしい。残念ながらこの世界・この時代はそうした姿勢の人材のあり方を望まないようだが……。 業務知識をマークダウン化したり、オントロジー管理ツールに反映する。 従来のデータエンジニアの多くは「それはデータエンジニアがやることなのか」（＝自分は◯◯だけ やっていたい）といった反応をしがちだった。「オントロジー」というワードやツールが注目されて ようやく「これからはこういうことをやらないといけないのかなぁ」と言い始めたところ。 B：書き込みまで担うパターン ● ● ログ設計に不具合があれば、データエンジニアがフロントエンドにPull Requestを出す現場もある。 同じように「業務フロー」自体（ある意味では会社運営そのもの）のメンテナンスや改善を担う。 （という考え方） ⇒AIエージェントの土台、自社のナレッジ管理、会社の運営そのものがデータエンジニアリング化する。 ⇒プロダクト仕様に詳しい人、エンタープライズ営業が強い人がCEOに抜擢される会社があるように 「コンテキスト管理」に精通したデータエンジニア出身者が新時代のCEOになる未来。（後述） #44
Google Cloud Next '26 風音屋 Recap ● ● オントロジー、ナレッジグラフ、セマンティックレイヤーについては 6月に開催したプライベート勉強会で解説を行いました。 講演資料やnote記事を公開しているのでぜひ読んでください。 https://speakerdeck.com/kazaneya/20260604 https://note.com/kazaneya/n/n320e9d98607f #45
ドメインモデリングならびにオントロジー管理 業務に登場する主要概念をモデルとして言語化・処理する。 左は @little_hand_s さんの記事で紹介されている図。右はオントロジー管理ツールの参考イメージ。 https://little-hands.hatenablog.com/entry/2022/06/01/ddd-modeling #46
会社経営・事業運営そのものを言語化し、OS（オペレーションシステム）として動かす 「子どものお弁当を作ろう！」を業務とみなした場合のEA（エンタープライズ・アーキテクチャ）の例 器具が あるか？ ビジネス アーキテクチャ レシピ動画 を見比べる 料理を 決める 通販サイトで 器具を買う 料理 する 食べて もらう ・食べ残し ・食べる速さ ・感想を聞く 振り返り 材料が あるか？ スーパーで 材料を買う データ アーキテクチャ 動画視聴 データ アプリケーション アーキテクチャ Youtube iOSアプリ テクノロジー アーキテクチャ Youtube サーバDB 通販注文 データ POS注文 データ 通販サイト 電気 利用量 食事記録 電気 メーター 紙の手帳 電力会社 DB 紙の手帳 スーパーの POSレジ 通販サイト DB POS会社 DB #47
AIネイティブな時代の「ビジネス」や「オペレーション」の行き着く先 あらゆる事業（ビジネス）や業務（オペレーション）は以下の一連の活動と言える。 ● ● ● 何らかのリソースを投入（Input）して 何らかの価値を付加（Processing）して 何らかの財・サービスを提供（Output）する AIエージェントによって「情報」（データ）の担う部分が拡大する。 結果、あらゆるビジネスやオペレーションが「データエンジニアリング」化する。 ● ● 「情報」（データ）の流れを制御する中核システムが「データ基盤」 「情報」（データ）の流れを制御する活動が「データエンジニアリング」 ⇒Development（仕組みの構築） 「データエンジニアリング」と「AIエージェント導入」と「業務定義」と「経営」とが一体化する。 ⇒Operations（仕組みの運営） 「データ基盤」と「AIエージェント」と「業務フロー」と「事業運営」とが一体化する。 将来的にはロボット（フィジカルAI）技術の発達によって、デスクワーク以外も同様に扱えるようになると期待されている。 #48
データチームの立ち上げに先立ってドキュメント整備を行った リクルート社で @yuzutas0 がデータチームを立ち上げる直前にやったのが、担当プロダクトのWikiを整備 することだった。システム開発者だけでなく事業部・マーケ・CS担当も参照する場として、プロダクト成長 ・運営のためのあらゆるコンテキストを整えた。ミニCEOとして全業務を管理するつもりで可視化した。 以前の担当業務 データチームの立ち上げ プロダクト開発チーム （iOS・Android・FE・BE） TechLead職 SRE・アーキチーム （アプリケーション基盤・クラウドインフラ） ドキュメント整備 ＆ 業務標準化 データ基盤構築 ＆ データ利活用促進 スクラムマスター （チームの立て直し・プロセス改善） https://speakerdeck.com/yuzutas0/ #49
Document Design Pattern（ドキュメントデザインパターン）® ● ● ● ● GoFデザインパターン等を参考に、効果的なドキュメント管理手法を体系化したフレームワーク。 MVCパターン：「今回の作業に関するメモ」（View）と「その作業の手順書」（Controller）と 「その作業で使う道具の説明」（Model）とは分けて管理する。 ○ 例：「202610_月次報告_作業記録」と「月次報告手順」と「Slack利用ガイドライン」は別。 ○ 「作業手順書」と「今回のメモ」を分けておかないと、次の作業時にはメモから作業手順を 読み解かなければいけなくなってしまい、トラブルや手順漏れの温床となる。 ○ 「その作業の手順書」に「道具の説明」を書いてしまうと、他の作業で同じ道具を使うときに 探せなくなってしまったり、同じ説明が複数個所に散在して更新漏れのリスクとなる。 Iteratorパターン：繰り返しが生じるドキュメントは反復子（例：作業日付suffix）を設ける。 ○ 「◯◯定例_議事メモ_20261008」 View Controller Model 「◯◯定例_議事メモ_20261009」 ○ 「260901_受領資料」「260902_検討メモ」 リリース記録_201704XX リリース作業手順書 インフラ環境一覧 SonarQubeによる静的コード解析のように リリース記録_201705XX 風音屋「Data Samurai」のSkills/MCPで ドキュメント品質を計測・改善できる（予定） リリース記録_201706XX Jenkinsログイン情報 ○ 鋭意開発中です💪 ※Document Design Pattern®は株式会社風音屋の登録商標です。 #50
3. 技術選定の話 #51
‘25で話したこと：データテクノロジーのシステム構成（再掲） BIツール、DWH、ストレージ、ETL/ELT/ReverseETL、 ワークフローエンジン、データカタログ、IaC、CI/CD、 データ取得（API/DB/ログ/ファイル）、データ仮想化、 レイヤリング/データモデル etc… https://speakerdeck.com/kazaneya/20251106 #52
コンテキスト管理のShift Left ● ● ● AIエージェントからアクセスしやすい箇所にコンテキストを整備する。 これまでは集計ロジックの置き場はDWHとBIツールのどちらでも特に問題なかった、という組織でも AI時代になってDWH側に集計ロジックを置く（データモデルを用意する）メリットが増えた。 風音屋の支援先であるレンティオ株式会社様にてデータモデリングのプロジェクトを推進中。 ○ BIツールで試行錯誤→DWHにデータモデルを移行→AI/BI両方から同じ指標にアクセスできる。 Before データウェアハウス データウェアハウス After 指標定義 集計ロジック https://recruit.rentio.co.jp/engineer BIツール 指標定義 集計ロジック AIエージェント エンジニアを 募集中だそうです！ BIツール AIエージェント #53
「フルマネージド」至上主義の終焉 AIエージェントがデータエンジニアリング業務を担うと、以前の「フルマネージド」重視は不要になった。 あらゆる業務は IaC / CLI が前提となる。 ● ● ● やろうと思えばブラウザ作業やComputer Useも可能だが、トークン効率が芳しくない。 設定内容をコードで管理さえできれば、後から他のツールに移植することは可能。 例：LookerStudio や PowerBI より Lightdash を選ぶ。CLIに対応したら、後で移植すれば良い。 Un-Controllable なクラウドサービスの仕様に追従すべきか。 ● ● クラウドプラットフォームのマネージドサービスだとAPIの対応有無が揺れたり、同じ関心事項を1つ の場所で管理できない（Terraformとサービス用のリポジトリが分かれる）といったケースがある。 ○ 「OSS」＋「ホスティング or サーバレス実行」のほうが管理しやすいケースが増えた。 ○ クラウドインフラの保守運用はAgent Skillsやスクリプトを整備できる。 わざわざデータ転送SaaSを契約せずとも、自前のプログラムでデータを集めれば良い。 ○ むしろスクレイピングや社内ストレージ巡回も1つのシステムに乗せて管理がシンプルになる。 #54
「AIエージェント経由でのBIツール操作」に慣れると、従来の画面操作は苦痛になる コード管理できないツールを使うというのは、 「ハロウィンなのでディズニーランドに行きたいね」 「自動車や電車を使わずに自宅から徒歩で行こうか」 と言われているような気分になる。 せっかく素敵なビジョンを実現しようとしているのだから、 せめて現代のテクノロジーを使わせてくれよ！ 頑張るポイントはそこじゃないだろ！と思うわけです。 #55
専用ツールではなく .md でデータエンジニアリングを行う ● 論理的な実装をマークダウンで行うことが可能になった。そもそも高級言語は物理層をラップするた めのもの。PythonやRustといったプログラムを書くと（略）トランジスタのON・OFFが切り替わっ て（略）指示した通りに挙動する。AIエージェントという変換装置の普及によって、従来のプログラ ミング言語のさらに一歩外側にマークダウン（.md）ファイルで指示を出すという手段が確立された。 ● マークダウンやExcelのRules機能でセマンティックレイヤーを実装している会社もある。dbtや Snowflakeの専用機能を使わなくても、論理的なデータモデルをAIネイティブに管理できる。「この FactはこのSQLで取得する」「このDimはこのSQLで取得する」と.mdに書いてAIに集計させる。 ダッシュボードやグラフ描画の定義をSkills配下に書いておいて、ローカルで集計＋HTMLレポートを 出力するといった運用をしている会社もある。風音屋の経理業務（月次C/Fチェック）はこの仕組みで 回して、Skillsを起動すると5分後には当月のコスト削減余地を分析・レポートしてくれている。 ● ● ● BIツールをホスティングしたり画面編集するのではなく、マークダウンで社内配布して各自が手元で可 視化する。GitHub経由でソースコードを共有して手元でビルドするのと同じ。 「Tableauで模索してからデータマートを作る」の現代版。マークダウンで試行錯誤してから、クラウ ド側で扱うべきものだけを、DWHやBIに反映する。例：複雑で重い共通集計、URLで開きたい画面。 #56
例：オントロジーを専用ツールで管理する場合 ● ● 導入にあたってツールの比較検討、できること・できないことの確認、セットアップ作業が必要。 人間が画面操作を行うか、AIエージェントがAPI経由で入力・編集を行う。 注：架空の画面イメージです。このくらいの簡易ツールならすぐにプロトタイプを動かせるようになったのは最高ですね。 #57
例：オントロジーをSkills配下のファイルで管理する例① ● ● ● マークダウンやyaml、mermaidで記述して、人間用には図をレンダリングする。 ツールの比較検討やセットアップを飛ばせる。後から専用ツールに移植できる。小さく始められる。 この講演の後に八重洲のカフェで10分だけ作業してAIエージェントに指示すればすぐに再現できる。 yaml mermaid メタデータの付与が少ないうちは yamlを省略して初手でこちらを作る IDEやGitHub、ブラウザ拡張で 図をレンダリング表示 スクリプトで変換 （またはAIにEditさせる） #58
例：オントロジーをSkills配下のファイルで管理する例② ● さらに言うと数行のマークダウンで済ませることもできる。 ● 専用ツールの導入可否を議論したり、専門用語の解説記事を読んだり書いたりする時間があるなら、 さっさと手元で.mdに反映して他の作業を進めたほうが建設的だ、という考え方もあるだろう。 ○ オントロジーの議論は3分で終わらせて、本題のプロジェクトを進めよう。 - 顧客 -> (1:N) -> 購入 -> (N:1) -> 商品 - 顧客：顧客ID、氏名、メールアドレス、会員ランク - 購入：購入ID、購入日時、数量、購入金額 - 商品：商品ID、商品名、カテゴリ、価格 #59
マークダウンでセマンティックレイヤーを実装する例 ● ● 風音屋の支援先である「株式会社日本経済新聞社」様にてPoCを実施中。 代表的なデータカタログのOSSである「DataHub」で「Dimension」や「Fact/Measure」を定義。 ○ Glossary機能を用いて、用語名、定義・意味、SQL、利用案内、注意事項をマークダウン化。 ○ AIエージェントにデータ分析を依頼すると、DataHubのGlossaryを読んでSQLを組み立てる。 分析依頼 定義の確認 AI エージェント 人間 DataHub GitHub Dim/Factについて 用語＋クエリ定義 マークダウン ファイル クエリ構築 テーブル定義や ジョブ情報 クエリ実行 BigQuery 結果報告 自動反映 更新 自動反映 齟齬・不備を指摘 #60
選球眼・審美眼 > @yuzutas0 が重要だと考える例① テクノロジーの選定・利用にあたって（CxO｜アーキテクト）は（自社｜自分）なりのポリシーを持つ。 【1】常に Usecase / Workload（用途）から技術を選ぶ。 システムは使われて初めて価値を生む。手段と目的を入れ替えないように、ゴールから逆算して設計する。 ⇒キーワード網羅ではなくユースケース対応を目指す！（NG例：うちもオントロジーに対応すべきか） 【2】なるべくEasyな（使いやすい・運用しやすい）技術を選ぶ。 複雑な道具を扱えるのは一部の人だけで、ゆくゆくは他のEasyな選択肢によって置き換えられてしまう。 ⇒カスタマイズ開発や独自運用をギリギリまで避ける！（NG例：MCPハブの仕組みを内製化しよう） 【3】なるべくPortable（移植可能）な技術を選ぶ。 最適な技術は移り変わる。移植のハードルが高いと、固定費だけがかかるゾンビと化してしまう。 ⇒データをエクスポートできるもの、画面操作だけではなくコード管理できるものを選ぼう！ #61
選球眼・審美眼 > @yuzutas0 が重要だと考える例② 【4】なるべくMatureな（枯れた・枯れる）技術を選ぶ。 使う技術が頻繁に変わってしまうと、移行プロジェクトばかりが続いて、投資回収・恩恵を受けられない。 （NG例：ベンダーの新機能に全てを賭ける ⇔ OK例：まずはマークダウンで管理する） 【5】なるべくContemporaryな（時流に沿った）技術を選ぶ。 時代によってシステムが「クライアント中心」か「サーバ中心」かは振り子・螺旋のように変わっていく。 クライアント中心の時代なのであれば、無理にサーバ中心の仕組みを作ろうとすると過剰投資になる。 ⇒現在はデスクトップAIツールが技術の中核で、クラウドベンダー側の各機能が充実するのはこれから。 【6】なるべくHolistic（包括的）な技術を選ぶ。 データ分析者が特定のBIツールをデータ基盤にするとライセンス節約やAIツールを使うときに困るので、 複数ツールから参照できるDWHやストレージを活用すべし。自分の職種から一歩引いた全体像を描くべし。 ⇒同様に、データエンジニアリング特化のツールばかり見ていると「黒船」にひっくり返されるかも。 #62
4. アーキテクチャの話 #63
業務システム・Excel・DWHのシステムライフサイクル 1. 2. 3. 4. 全てを事前予想できず、開発リソースは限りがあるので、基幹システムやSaaSには漏れが生じる。 ニーズへの対応を優先するために、現場ではExcel業務による工夫が生じる。 システムやデータが散らばると、それらを横断活用するニーズが生じ、データ基盤が必要になる。 本来は基幹システムで実現すべきだったよねという話になり、取捨選択の上で一部が取り込まれる。 ①トップダウンで 全体最適な システムを整備する バイモーダルIT 【SoR】 基幹システムや 業務ツール Tier 1 経営管理 Tier 2 現場業務 ②ボトムアップで Tier 1が拾えなかった 細部をカバーする 【SoE】 Excelシートや NoCodeアプリ 顧客価値の提供 ④特に重要な領域を 取捨選択して取り込み アップデートする 【SoI】 Data Platform系 ソリューション ③社内外に散在した データを集約・統合して 柔軟に活用する #64
SoE/SoR側：AIエージェントを前提とした技術選定がなされる ● ● API / CLI / MCP経由でCRUDできる各分野の専門SaaS（例：会計ツール）が選ばれるようになる。 または既存のソリューションベンダーがこれらのエンドポイントの提供を始める。 一部のシステムやシートは「お手製Vibe Codingツール」に切り替わっていく可能性がある。 バイモーダルIT API対応 お手製 Vibe Coding ツール 【SoR】 基幹システムや 業務ツール Tier 1 経営管理 Tier 2 現場業務 【SoI】 Data Platform系 ソリューション 【SoE】 Excelシートや NoCodeアプリ #65
SoI側：System of Insight から System of Aciton / Data App へのシフトが進む ● ● データを分析・可視化するだけではなく、業務システムへの連携やアプリケーション提供まで行う。 ○ 従来から ReverseETL や Data Activation と呼ばれるワードで実現されてきた役割。 Palantir Foundry や Databricks がグローバルで注目される理由の1つ。 ○ SnowflakeもStreamlit（SiS）やApp Runtimeによるシステム構築支援機能を強化している。 ○ AWSやGoogle Cloudは元からアプリケーション構築に強いプラットフォームだが、Redshiftや BigQueryを担うデータエンジニアが「そこは自分の仕事ではない」と職域を狭めやすい。 ○ Microsoftは時流に準拠。データ系ソリューションをAzureからFabricに移し、データ担当者の 管理下にDWHとAppsが併存。 【SoR】 基幹システムや 業務ツール Tier 1 経営管理 Tier 2 現場業務 System of Action Data App 【SoI】 Data Platform系 ソリューション 【SoE】 Excelシートや NoCodeアプリ #66
軽量アプリケーションを構築できる「Cloudflare」が黒船になるか ● ● こうした「軽量なアプリケーションを簡単に作って動かせる仕組み」が各所で台頭している。 データエンジニアリングの狭い世界に閉じずに、テクノロジー業界全体を見ると、圧倒的にポテン シャルがあるのが「Cloudflare」だと思われる。現時点で「黒船」の最有力候補と言える。 Cloudflareで軽量アプリケーションを簡単に作って動かせる！ バイモーダルIT お手製 Vibeツール 【SoR】 基幹システムや 業務ツール Tier 1 経営管理 Tier 2 現場業務 System of Action Data App 【SoI】 Data Platform系 ソリューション 【SoE】 Excelシートや NoCodeアプリ #67
2026年で最も注目するテクノロジーはCloudflare ● AIエージェント時代に適した機能・I/Fを提供し、現代の開発ニーズの痒いところに手が届くような新 機能を次々とリリースしている。従来のCDN事業の枠を超えて、次世代のAWSやGoogle Cloudに近い 立ち位置になりうる。AWSを初めて使ったとき、BigQueryを初めて使ったときのような「これすご い！」「もっと使いたい！」という気持ちになる。 ● ドメイン周りの制限など、CxOやクライアントに説明・提案しにくい地味なネックは多数ある。まだ アーリーアダプター向けの施策・機能・価格設定がメインだが、エンタープライズセールスに舵を 切ったら一気に風向きが変わるのではないか。多分だけど財務改善で株価も上がるような気がする。 @shodaiiiiiiさん、@shinoyu___さん、@minicooheiさんのXポストより #68
GAS や Microsoft Access の代わりに Cloudflare を使おうぜという話 Microsoft や Google アカウントでの認証・認可など、業務ツールで地味に面倒な箇所が解消される。 @shodaiiiiiiさん、@yusukebeさんのXポストより #69
社内ツールのデプロイ先として Cloudflare が強いという話 ちょっとした社内ツールを動かすために必要な機能は全部揃っている。デプロイもAIに任せられる。 @sarukun99さんのXポストより #70
AIエージェントを動かすプラットフォームとして Cloudflare が強いという話 データ分析のレポート作成やチーム共有に関するリッチな機能もしれっと実装されている。 @iwashi86さん、@na0fu3yさんのXポストより #71
自前エージェントやワークフロー実装も Cloudflare が強いという話 スクリプトで処理させたければスクリプトで動かせるし、 AIエージェントで処理させたければAIエージェントで動かせるし、 定期実行や状態管理もできるし、我々が社内システムと呼ぶものは Cloudflareに乗せておけば、よしなにチューニングできる。 @sarukun99さんのXポストより #72
Cloudflare の技術的優位性が圧倒的だという話 価格の安さばかりが取り上げられることがあるけど、その安さは技術的な背景に基づいているという解説。 @mizchiさんのXポストより #73
ケイパビリティが制約になる（そして、制約は工夫・発明を生む） 一連の話はソフトウェアエンジニアリングやAIエージェントの知識・技能を有していることが前提となる。 ● ● ● ● 「今の時代はGUIよりCUIが良いよね」と言われて心から共感できる人は多くはない。 全国平均だとデータ利用者は Excel の VLOOKUP が関門になる。Cloudflareどころではない。 「いざとなったら担当者がメンテナンスできるか？」という懸念は残るので、従来のSaaSやマネージ ドサービスは使われ続けるだろう。むしろそれ以前のフェーズの組織も多数あるだろう。 AIエージェントの恩恵をどれだけ享受できるかは、組織や個人によって差が出る。 事務員や営業職がメインの組織でAIエージェント前提の仕組みをどこまで作れるか／普及できるか。 ● ● 従来型のSaaSやGUIの中にAIエージェントを組み込むアプローチ。 ○ 例：自社の経理部門ポータルを作り、そこで業務を完結・効率化する。NOXASやCloudflare。 業務で必要となる「知識・技能」を定義して学習ガイドを提供するアプローチ。 ○ 例：「Data Samurai」>「データ分析の作法」「Excelデータ管理の勘所」を経理部で受講し、 10分動画＆理解度チェックテストで全員が満点を取れるところまでトラッキング。 #74
再掲：業務システム・Excel・DWHのシステムライフサイクル この話に戻します。 ①トップダウンで 全体最適な システムを整備する ②ボトムアップで Tier 1が拾えなかった 細部をカバーする バイモーダルIT 【SoR】 基幹システムや 業務ツール Tier 1 経営管理 Tier 2 現場業務 【SoE】 Excelシートや NoCodeアプリ 顧客価値の提供 ④特に重要な領域を 取捨選択して取り込み アップデートする 【SoI】 Data Platform系 ソリューション ③社内外に散在した データを集約・統合して 柔軟に活用する #75
リバースエンジニアリング／リバースモデリングへの期待が高まる ● 各業務システムにおけるモデル設計（クラス設計、ER設計、DDD）は、その業務を実現するための個 別要件に引きずられて断片的になってしまう。複数のデータを集約・統合したデータ基盤上で改めて モデリングをし直すことで、横断的なモデルを確立し、SSoTを実現できる（と期待されている）。 ● Palantir Foundryがグローバルで注目される理由の1つ。AIエージェントが仕様を理解するにはコン テキストが必要で、オントロジー管理機能によるリバースエンジニアリング（正確に表現するなら @gura105 氏の「リバースドメインモデリング」という命名が芯を食っている）が必要だとされる。 ● トップダウン計画に基づいたTier 1の モデリングよりも、ニーズと現場感に 基づいて後からデータ基盤で整備された モデリングのほうが役立つことがある。 【SoR】 基幹システムや 業務ツール Tier 1 経営管理 【SoI】 Data Platform系 ソリューション Tier 2 現場業務 【SoE】 Excelシートや NoCodeアプリ リバース モデリング #76
風音屋の「軽量リバースモデリング」ソリューション① 再掲：1クリックでスプレッドシートの依存を可視化する「NOXAS Sheets Lineage」 #77
風音屋の「軽量リバースモデリング」ソリューション② 1クリックでスプレッドシートの依存を可視化する「NOXAS Sheets Lineage」 + （一部まだ）補助Skills Tier 1（基幹システムや業務SaaS）のデータや処理ロジックを取り込むのは容易。 ● 従来のデータエンジニアリングがノウハウを確立してきた領域。 Tier 2（Excel作業）に関するデータやドメイン知識をかき集めるのが大変。ここが課題になる。 ● DocsやExcelから参照関係を機械的に抽出し、AIエージェントで意味解釈を行う。これまでは管理職 や業務コンサルタント、FDEが時間をかけて整理しないといけなかったが、1クリックで代行可能に。 ● 新しいワークフローツールを導入・移行するのは大変だ（挫折したりスコープが狭まる）が、既存の ツールや運用は変えずに、1クリックでワークフローとして可視化・参照するだけなら成り立つ。 ● 「このExcelが重い」「この手順でミスしやすい」と記録すれば、AIエージェントが分析して、業務手 順のショートカット・分割・統合・入れ替えを提案し、Input/Outputに影響がないことをテスト。事 務員が日々の業務内でBPR（Business Process Re-engineering）を進められるように補助。 ※将来的にはプラットフォーム上で実行支援を行えるように進化させたいところ。担当者が当月分の作業を どこまで進めたかチケット管理したり、LinearのようにAIエージェントをアサインして作業をさせたり。 #78
風音屋の「軽量リバースモデリング」ソリューション③ ● AI時代には「AIモデルやクラウドインフラを提供できる胴元の会社」「IT以外の実業を持っている会 社」「業種特化＆コアなシステムを抑えた上でデータを蓄積・展開できる会社」が強いと言われる。 ● 一方で、こういった「システムアーキテクチャ」と「業務コンサルティング」と「データエンジニア リング」と「プロダクト開発」が入り混じったような、AI時代らしいソリューションにも大きな可能 性があるのではないだろうか。世界10万社に月1万円でプロダクトを提供して、数人の開発チームで年 商120億円を突破できる未来があってもおかしくはない。 ● データエンジニアだからと言って、ETLやDWHやBIツールに閉じなくても良い。ちょっとしたツール やこういうプロダクトをささっと作れると楽しいよ。「NOXAS Sheets Lineage」はRust実装による 高速挙動で、作っていても使っていても、とにかく心地良い。やたらRustを好きだと言い張る人の気 持ちが今ではよく分かる。正直なところ日々の作業も全部Rustに寄せたく（RIIR🦀）なってしまう。 ● メガベンチャーや大手IT企業でプロダクト開発を実際に担当してきたエンジニア出身の社長だと最高 かもね。過去にセキュアな決済機能を実装したり、デザイナー不在時は代わりに画面デザインを巻き 取ってきたパワフルな人だとベストだね。そんな会社が下町にあるらしいよ。そう、風音屋です。 #79
5-①. 人材・キャリアの話（データエンジニア職） #80
AI時代に世界が求めるのは「二宮金次郎」型の人材（たぶん） データエンジニアのあり方は変わる？ →「二宮金次郎」型のデータエンジニアが活躍 ジュニア人材は採用されなくなってしまう？ →「二宮金次郎」型のジュニア人材が活躍 ゆずたそコラム：二宮金次郎ってどんな人？ ● ● ● ● ● 家族や土地など全てを失った後、周りにムダな努力だと言われてもコツコツと学習を続けて、 ついには故郷の経営再建を達成した。そのノウハウを600の村に横展開して日本中を豊かにした。 小さな努力を積み重ねて大きな成果を出す「積小為大（せきしょういだい）」という思想を説いた。 「まぁ大丈夫だろ」と油断した村はあっという間に経営悪化して二宮金次郎にボロクソに叱られた。 ○ 例：1807年 駿東郡 神山村（現在の静岡県 御殿場市 神山） 日本全国で村長さんが地域の記録（データ）を取るようになって、経営改善やコンサルティングが 行えるようになった時代だった。見る人が見ればサボっているのも筒抜け、創意工夫も読み取れる。 データエンジニアが参考にすべきロールモデルと言える人物。 ○ というか日本人全員が参考にすべき偉人。全国の学校に銅像を立てるべき。 https://www.ninomiya.or.jp/kinzirozo/ 『御殿場市史 第3巻 (近世史料編)』より #81
データエンジニアは「データ収集」（Ingestion）を担う人？ ……という共通見解に対して、当時から違和感があった。 少なくとも今は、WebAPIでデータを取得するだけならバックエンド開発者だけで事足りる時代になった。 「データ収集」や「データ加工」を1つ追加するだけなら、最小限の工数に抑えられるので、逆に言うと、 本質的なデータ活用支援や付加価値創出に挑戦しやすくなった。「データ活用を推進したい人」には朗報。 拙著『実践的データ基盤への処方箋』より。「この図が実態に一番近い」と好評だったが、本当にこれでいいんだっけ？という思いもあった。 #82
「データ分野のツールを使う人」ではなく「データを整備する人」 ● ● ● 「役所に届け出しているはずの情報を何度も記入させられる」問題解決に向けてプロジェクト推進。 仕事を選り好みせずにゴール達成に必要なアクションやコミュニケーションを積み重ねる姿勢。 「dbtを使う人」ではなく「データの課題を解決する人」（そのためにdbtも使う人）が求められる。 風音屋アドバイザー 『データマネジメントが30分でわかる本』共著者 https://media.herp.cloud/posts/sugoihongyo_digital_3 まさに現代の二宮金次郎…！ #83
「独自の専門性」や「独自の目的意識」が伴う職種のはずだが、その視点を有する専門家は少数 （一部のエース人材たちを除いて、日本全体のリアルな平均水準を客観視するならば） データエンジニアは「Ingestionを担う人」、アナリティクスエンジニアは「Transformを担う人」、 データアナリストは「SQLを書いてデータを集計する人」というのが多くの現場の実態ではないだろうか。 データアナリスト アナリティクス エンジニア データエンジニア ある意味「優秀なソフトウェアエンジニアが片手間で出来る作業」で食いつなぐ下位互換に見えてしまう。 AIがスクリプトやSQLを書けるようになれば「本当に専門職が必要か？」という疑問が生じるのも自然。 拙著『実践的データ基盤への処方箋』より #84
AI時代に活躍できる「データアナリスト」や「データ分析まで担うデータエンジニア」とは？ ● そもそも経営陣が直接データを見るほうが明らかに筋の良い分析ができる。AI時代なら尚更。 Indeed CEO（現リクルートCEO） ● 「SQLを書ける／BIツールの使い方を知っているだけの人」がデータ分析の真似事をしたとして 「ビジネスやプロダクトを24h/365dずっと考え続けている経営陣やPdM」に価値提供できるか？ ○ ● 「在庫データの異変、俺じゃなきゃ見逃しちゃうね」という「計測魔」なら頼りになるだろう。 例えば、この建物（東京建物 ぴあ シアター＆カンファレンス）のP/LとB/Sの構造を考えて、 想定される今後のビジネス展開について今から10分で説明しろと言われたら、すぐ回答できるか？ ○ ● 一休 CEO 「クセになってんだ、外食先で店のKPIを推計するの」という「分析中毒者」なら即答できる。 経営陣と対等に会話できるような人材でないとビジネスに資する（まともな）分析はできないが、 経営陣と対等に会話できるような人材は簡単に採用・育成できない。 ○ 「右上がりのグラフ♡興奮しちゃうじゃないか♡」という「グロース狂」なら愛されるかも。どんな逆境でも「完璧に勝 つ。だろ？社長♡」と最後まで粘り、「ボクの見込んだ通りこの会社はどんどん伸びる♡」と言い出すような狂人なら。 https://note.com/masa_kazama/n/nf70ba7dccd4a / https://bcg-jp.com/article/7942/ / 冨樫義博『HUNTER x HUNTER』 #85
Data Appsを作るのは誰？ ● ● 従来だとデータエンジニア職ではなく一般的なソフトウェアデベロッパーやアプリケーションエンジ ニア職がData Apps（に相当するアプリケーション）の開発を担うことが多かった。 Streamlitなど、データサイエンティストやデータエンジニアがWebアプリケーションを作れるツール が普及。最初はダッシュボードの延長のような簡易画面がメインだったが、徐々に本格化。 ● （前述）DatabricksやSnowflake、Microsoft FabricではAppsを作る機能が充実し、「Databricks を担うデータエンジニア」が「Appsの開発」まで指示される流れになりやすい。プラス面ではデータ エンジニアの貢献範囲が広がる。マイナス面ではAzureやAWSに寄せるべきものまで散らかりがち。 ● 本来はWebアプリ開発に最も適しているはずのAWSや Google Cloudを扱っているデータエンジニアの中には 「AthenaやGlue」「BigQueryやLooker」だけに閉じて （良くも悪くもモジュールで役割分担されて）しまって 「Data Appsの担当は自分ではない」と狭まることも。 ○ ソリューションの機能差ではなく職域定義の問題。 ○ 前述のLightdashホスティングから始めるのも手。 拙著『実践的データ基盤への処方箋』より データアナリスト アナリティクス エンジニア Data Apps データエンジニア #86
データチームが業務システムまで担う世界観 ● リクルート時代の @yuzutas0 の事例。データチームが広告配信システムの開発・運用を担い、 広告データと売上データを統合することで、登録CPAではなくROASで最適化しながら デジタルマーケティング施策を展開＆継続改善できる状態（DataOps）を実現。 ● 費用対効果を厳しく問われる事業会社だと データチームをコストセンターではなく プロフィットセンターとすることが 求められやすい。そうした経歴の人材が 立ち上げた会社が強いか。つまり風音屋。 ● 分析部門やコンサル出身に比べると、 エンジニアリング部門でTechLeadとして プロダクト開発を経験した人材のほうが 強みを発揮しやすい領域。そういう人材が 立ち上げた会社が強いか。つまり風音屋。 https://speakerdeck.com/yuzutas0/20180727 #87
データアプリケーション（プロダクト）開発者の募集が今後は増えるか 日本経済新聞社の募集事例 ● 事業部門・編集部門の業務変革につなげる データプロダクトの開発を行う職種 ● 記事・画像といった非構造化データを いかにデータ基盤で活用するか ● 1日450GB以上の大規模データの連携や 先ほどのセマンティックレイヤー整備など、 国内有数の技術的な取り組みを行っている https://herp.careers/v1/nikkei/H1WiO9mjDtb8 #88
2026年のデータエンジニアリングを象徴する他社事例（クラシルさん①） まさに現代の二宮金次郎…！ ● ● CEO @yusuke_horie さんのnote記事 ○ https://note.com/yusukehorie/n/ned652c8c02b0 消費財サプライチェーンの労働力不足（SAM 11.5兆円）に対して「Kurashiru AI OS」なる事業戦略 を提示し、「FAXや商談記録といった非構造化データ」や「Palantir Foundry流のオントロジー」と いったデータエンジニアリングの取り組みが土台になるとプレスリリースで発信。 ○ https://prtimes.jp/main/html/rd/p/000000468.000019382.html ○ https://prtimes.jp/main/html/rd/p/000000483.000019382.html #89
2026年のデータエンジニアリングを象徴する他社事例（クラシルさん②） まさに現代の二宮金次郎…！ ● ● ● データエンジニア @gappy50 さんの登壇スライド https://speakerdeck.com/gappy50/bs5227-snowflake-world-tour-tokyo-ontology-harry Snowflake App Runtimeで業務システムを構築し、オントロジー管理、在庫管理、需要予測、 AI発注提案まで実施。人間が承認したらERPに連携して発注を指示。 本日ご紹介してきた「データエンジニアリングが今後注力すべき領域」について実践・発信し、 なおかつ顧客価値・事業成果から逆算して過不足を感じさせないエンジニアリングを徹底している。 ゆずたそ補足：私よりも@gappy50さんに基調講演を打診すべきではないか、と今でも思っています。2026年の日本において最も素晴らしいデータエンジニアです。 #90 日本中のデータエンジニアに「事業会社における2026年のデータエンジニアリング事例」を発信し、次の1年の行動指針を示すならこの方がベストだろうなと…！
データがビジネスのコアになる時代 風音屋の支援先であるNE株式会社様は「コマースOS」への事業転換をプレスリリースにて告知。 ● ECの購買・運営をAIエージェントが代行する時代に向けて AIから接続可能なデータインフラを提供する。 ● 問い合わせ対応や業務アプリ構築をエージェント化して提供、 AIにEC運用を任せるためのAPIやMCPサーバを構築、 受注・売上データを確認できるモバイルアプリをリリース、 CVC出資やアライアンスなども行い、怒涛のアップデート。 https://prtimes.jp/main/html/rd/p/000000052.000125456.html / https://prtimes.jp/main/html/searchrlp/company_id/125456 #91
データ人材がビジネス推進のコアになる時代 こうした怒涛のアップデートを支える組織、文化、技術力、人材。 ● ● ● 執行役員CDO（Chief Data Officer）によるデータ戦略の推進 顧客価値や利益向上に繋がるデータ活用施策を追及する姿勢 大規模データを支えるエンジニアリング面での創意工夫 そして小田原で創業、Hamee社からスピンオフ上場後、横浜へ移転。 ● ● ● 二宮金次郎が江戸時代に600の村を経営再建したのは小田原藩 横山家当主が室町時代に功績を挙げた（と称す）のは小田原城 黒船来航後に開港し、明治維新と国際貿易の中心たるは横浜港 データ経営ゆかりの地で土台を構築し、いざ世界へ開国…ってコト!? ※本頁後半についてはyuzutas0が1人で好き勝手に話しているだけで NE株式会社様の公式見解とは一切関係ございません。 https://zenn.dev/neinc_tech/articles/195d260ddd127a #92
🚀🚀🚀 戦国時代の最終決戦「小田原包囲網」（1590）の如く、デスクワーカーがAI包囲網に追い詰められる中で 風を切って未来（ソコ）へ進むか、腹を切って現状（ココ）で諦めるか。 - https://mindtrip.ai/attraction/nakanojo-machi-gunma/jiettoergongjincilangxiang/at-Cb0YpE5T - https://www.youtube.com/watch?v=mxaL2IsCG0w /『千福 横山家文書』 #93
データ職の担い手がビジネスや組織の中心となった事例（順不同・便宜上の呼称を含む） まさに現代の二宮金次郎…！ 笹川裕人さん（風音屋アドバイザー） リクルート社で機械学習→エムスリー社でデータエンジニア→Sansan社で開発部長→執行役員CTO 伊藤徹郎さん（『実践的データ基盤への処方箋』共著） まさに現代の二宮金次郎…！ 大手金融で営業→分析会社でコンサル→SaaS開発→Classi社でデータサイエンス→プロダクト部長→取締役 渡部徹太郎さん（『実践的データ基盤への処方箋』共著） まさに現代の二宮金次郎…！ NRI社で開発→リクルート社でデータエンジニア→GO社でデータ基盤＆機械学習→マネージャー→部長 西場正浩さん まさに現代の二宮金次郎…！ 大手金融でクオンツ→エムスリー社で機械学習エンジニア→リーダー/PdM→Sansan社で部長/VPoE/VPoP 近森淳平さん まさに現代の二宮金次郎…！ CARTA社（旧ECナビ/VOYAGE）にて新卒入社で広告システムを開発→データエンジニア→VP of Data 平野雅也さん まさに現代の二宮金次郎…！ Retty社にてインターン→新卒でバックエンド開発＆データ分析→分析チームの立ち上げ→代表取締役社長 Jeff LeBeauさん まさに現代の二宮金次郎…！ メルカリ社にて配送コスト分析を担当→Analyticsチーム発足→’22年にJapan CEO→’26年にグループCEO #94
データエンジニア（リング）の分かれ道 データエンジニアリング業務は開発部門のメンバーが片手間で済ませるニッチな作業に過ぎないのか？ データエンジニア職はバックエンドエンジニアの下位互換に過ぎないのか？ かつて消えていった仕事（電話交換手、蒸気機関車のかま焚き、ボウリングのセット係）と同じなのか？ それともデータ時代／AI時代におけるビジネスの中心的な役割を果たす「コア業務」になるのか？ 会社経営・事業運営そのものをOS化・コンテキスト化する「新時代の花形職種」に昇化されるのか？ データエンジニア職で活躍したメンバーがCxOやVPへと抜擢されるような流れを作っていけるか？ データエンジニア（リング）は時代の岐路に立っているのではないか。 社会が必要とする「データエンジニア（リング）」は後者ではないだろうか。 次の二宮金次郎になるのはキミかもしれない。 しかし、今の「データエンジニア」たちが、その仕事をやりたいと望むか？ 仮にその仕事を任されたとして、周囲や社会の期待に応えることができるか？ 先ほど紹介した10人の二宮金次郎たちに追いつき、そして追い越していけるか？ 次の二宮金次郎になる勇気はあるか？ そのために毎日の努力を積み重ねる覚悟はあるか？ #95
人（データエンジニア）の心（プライド）とかないんか？ 1,000年後の人類がこのAIシフトの時代を「データ黎明期」と呼び、今まさにデータエンジニアリングに 打ち込んでいる者たちを「偉人・英雄」として教科書で紹介するような未来があってもおかしくない。 『呪術廻戦』『僕のヒーローアカデミア』『ジョジョの奇妙な冒険』『ONE PIECE』『ヒカルの碁』より #96
「従来のデータエンジニアリング業務」を広く・深く学ぶことは大前提 土台すら出来ていない状態で、その先を学ぼうとしても意味がない。まずは基礎知識・技能を習得すべし。 https://speakerdeck.com/kazaneya/20251106 #97
再掲：データ基盤構築のハンズオン教材「K-DEC」 累計260ページ・18万文字の超豪華な研修教材を読み、データ基盤構築のハンズオンを実施。 https://prtimes.jp/main/html/rd/p/000000005.000057831.html #98
「データエンジニアリング業務」の先にある「データ活用による価値創出」まで見据える ● ● ● ● 期待されるQCDSでアウトプットを提供できることが第一歩。 「dbtの使い方が分からない」「複雑なSQLを書けない」は業務として成り立たないので論外。 その上で、データ活用が進んだのか、ビジネスに寄与したのかというアウトカムを追及する。 「SQLを書くのが自分の役割だ」といった「作業」視点に閉じると、本題からズレてしまう。 風音屋でジュニアデータエンジニアが作る社内報告書は「成果物」（アウトプット）と「価値貢献」 （アウトカム）の両方を問い直すフォーマットにしている。定期的にこの報告を繰り返すと、着実に リーダー視点が身につくのでお勧め。 そもそも「仕事の目的を考える」＋「結果を振り返る」は新卒1年目で叩き込まれるはずの作法。 それすらできないデータエンジニアが会社のKPI計測を担えるわけがない。先に自分のPDCAを回せ。 『図解&事例で学ぶ入社1年目の教科書』より #99
5-②. 人材・キャリアの話（ジュニア／シニア） #100
AI時代に「人を雇う側」「仕事を依頼する側」が（たぶん）考えていること AI時代における人材の要否について世間で言われていることは、下図で（たぶん）説明できる。 ● 「ジュニア不要」論は「名目上のジュニア」（実質的なノービス）の育成が割に合わないという話。 ● 「シニア不要」論は（年数だけの）「名目上のシニア」より「実質的なジュニア」に期待する話。 ● 「少数精鋭」論は「戦力になる人材」の潜在数が少なくて採用・育成の期待値がマイナスになる話。 ● 「だからこそ拡大すべき」論は「戦力になる人材」という希少資源が競争優位に繋がるという話。 知識・技能 コンピテンシー 大 少 数 1ヶ月の学習＆OJTで 要領を掴んで小さな作業を 任せられるようになる 半年〜1年で Good＆Moreの学びを重ね 大きなプロジェクトまで 任せられるようになる （実質的な） ジュニア人材 小 ノービス人材 小 多 数 （名目上の） ジュニア人材 入社できたけど 手取り足取りサポートが必要 2年〜3年で 修羅場や勝負処を乗り越えて 複雑な組織やシステムの 全体最適の門番になる （実質的な） リーダー人材 この水準の人材にしか 任せられない仕事がある ＋ そういった仕事ばかりに 今後なってしまいそう ＋ 「周囲をケアできる人材」 「仕事を教えられる人材」も このラインにしかいない （実質的な） シニア人材 AI時代で主体的な活躍を 期待できる下限ライン （名目上の） シニア人材 （名目上の） リーダー人材 人事投資できる下限ライン ＝マネージャーが労力を割いて ケアすることが合理的な水準 年数を重ねる中で少しずつできることが増えたり 転職を繰り返せば一時的に給料は上がるが、 仕事のOSを根本的にアップグレードするような自己変革には至らず 「一線を越えてきた人たち」とのギャップが広がり続ける状態 少 数 大 経験年数 人件費 #101
ジュニア（実質的にはノービス）なデータエンジニアに仕事を渡せなくなった？ ● データエンジニアリング業務に閉じて話すのであれば、「名目上のジュニア人材」（実質的にはノー ビス人材）が3ヶ月かけてできなかったことを、リーダー級のバックエンド開発者（データエンジニア リングの知識なし）がAIエージェントを使えば1ヶ月で（最低限なら）対応できる時代になった。 ● 別分野のリーダー級の人たちからすると、データ分野の専任人材を雇う必要があるのか、十分に期待 するような活躍をしてくれるのか、ミスマッチが生じたときに十分なサポートやガイドを提供できる のか etc… が見えにくい。わざわざ雇ったり開発委託しなくても、数ヶ月だけアドバイザーを招いて ドキュメントやAgent Skillsを整備（たまに更新）してもらうだけで十分ではないか。 ⇒なので風音屋は「Data Samurai」で「学習ガイド / テンプレート集」や「Skills / MCP」を各社に提供 し、専任人材以外がデータエンジニアリング業務を行えるようにしている。必要に応じてFDE的にプロジェ クト支援を行い、そこでのフィードバックを「Data Samurai」に取り込む。 #102
「名目上のジュニア人材」（実質的にはノービス人材）を優遇する時代の終焉？ ● ● ● ● シンプルに頭数が必要な現場は多々あるだろう。いわゆる大手SIが複数人チームでアサインしないと回 らないような環境。一方で、そういった現場も、細かく見てみると、結局は一部のリーダー人材のパ ワープレイで最終的な辻褄を合わせていたりする。 ジュニア人材（実質的にはノービス人材）5名のチームに仕事を依頼しても、結局はリーダー／シニア 人材がカバーすることになる。「組織のスケール」「60点での妥協」「属人化の排除」など「正論」 が謳われるが、どの会社も実態としては一定の属人性／マンパワーに依存しているように思える。 「戦力となる人材」の負担を減らして働きやすい環境を整えることが重視されつつある。リーダー人 材からすると、どのみち面倒を見るのであれば制限・リスクの多い人間よりもAIエージェントのほう がラクだったりする。 リーダー人材によるフォローが不要な業務（スキルの低い人材が担えるレベルまで細分化・手順化が なされているもの）であれば、なおさらAIエージェントで回せるので、わざわざ頼む必要がない。 ⇒なので風音屋は少人数＆AIエージェントの体制に切り替えて、月10万円〜でデータ基盤の開発・運用を担 えるようにした。結果としてプロジェクトのQCDSが向上し、ベテランの負担が減り、利益率が向上した。 #103
「雇用・報酬」は「価値貢献」への期待が前提（新卒1年目の研修で学ぶこと） 髪を切れない美容師にお金を払えるか？ いつまでも発進しないタクシーにお金を払えるか？ ラーメンが出てこないラーメン屋にお金を払えるか？ ラーメンが出てこなかったら「お代は結構です」となるはず…！ 「活躍する」「人の役に立つ」「価値を提供する」からこそ 商品（自分の労働力）を売り込んで、お金をもらうことができる。 逆に言うと、修行中は赤字を垂れ流す（投資を受けている）状態。 「名目上のジュニア人材」（実質的にはノービス人材）を 数年以上にわたって優遇し続けるには、相当な企業体力・胆力と サポートする側の時間・体力・精神的な余裕が必要になる。 管理職やリーダー層は、好奇心旺盛で探究熱心な自分の子どもに 絵本を読み聞かせたり一緒に調べ物をするための時間を削って、 未経験者をフォローしている。この状態が恒常化すると……。 自宅の3歳児が宿題プリントを毎日こなす一方、職場の部下が仕事の本すら読まないなら、 管理職は人材投資を減らして家庭学習を重視したくなるし、そのほうが社会的にも有益かも。 『図解&事例で学ぶ入社1年目の教科書』より #104
データ専門職やエンジニアリング専門職にお金を払う意味（新卒1年目の研修で学ぶこと） カフェ店員のように美味しいコーヒーを淹れるわけでもなく、 引っ越し業者のように汗をかいて重い荷物を運ぶわけでもなく、 警察や消防隊員のように市民の安全を守るために命をかけるわけでもなく、 医者のように年月をかけて難関資格を取得した上で医療行為を行うわけでもなく、 ☕ 冷暖房の効いた部屋で、フレックスタイムで、ラフな格好をして、お菓子や飲み物を頬張りながら、 データをガチャガチャといじるだけで、毎月何十万円もお金を振り込んでもらおうとしている。 たいした努力もせずにそんな生活を得られると、そんな生活を続けられると、本気で思っているのか？ 私たちの仕事に対して誰かがお金を払ってくれるのだとしたら、 それは私たちの仕事が沢山の人たちの人生を（間接的に）豊かにできると期待していただいているから。 データ活用によって顧客価値の創出に貢献することでしか、私たちの存在意義を示すことはできない。 「あなたの今日1日の成果」は「今日500円で買った1杯のコーヒー」以上に誰かを幸せにできているか？ 1秒でも早く「1人前の専門スキル」を身につけることは大前提。その上で価値貢献を問われている。 「いつか1人前になれたら良いな」は遅すぎる。AI未満のパフォーマンスでも、せめて気概は持たないと。 https://yuzutas0.hatenablog.com/entry/2024/10/30/121916 #105
未経験から短期間で「ジュニア人材」として活躍している人の特徴（あくまで一部の例） 1. 要領が良いパターン。応用情報やAWS SAAを2〜3週間で取るような人。高校3年秋の部活引退後に受 験勉強を始めて東大に現役合格した人、連日深夜までFF8をやって寝坊＆入試に遅刻したけど慶應経済 に合格した人はこのルート。このタイプは多分どの分野でも活躍できるから好きに生きろ。 2. 1人で勝手に学習・成長するパターン。ラーニングアニマル。プログラミング学習で変数を宣言したと きに「内部的には何が起きているのか」とつい気になってキャパシタ（に｜から）電荷が（蓄積｜放 出）されるところまで仕組みを調べたり、年末年始にGPUサーバを組み立ててローカルAIで遊んでい たら50時間ほど寝食を忘れてフラフラになってOS-1（経口補水液）を家族に飲ませてもらったりする ような人はこのルート。このタイプは多分どうにかなるから好きに生きろ。周りを大切にしろ。 3. 職人の弟子として厳しい修行をこなすパターン。凡人にとって（おそらく）最も再現性が高いルー ト。「品質の低い仕事」を良しとせずに「当たり前」の水準を高めることを要求されながら、必死で 食らいつく。師匠に推薦図書や演習課題をもらって（※）【毎日3h（始業前の8:00-9:30と終業後の 20:30-22:00）ｘ週7日】+【4.5h（朝10:00-11:30と昼13:00-16:00）ｘ土日】＝【週30h】行 う。最初の1年だけでも素直に続けて【週30hｘ50週＝1,500h】を達成すると【週末に3hｘ50週 ＝150h】だけの人より10倍の基礎力がつく。睡眠・食事・運動など健康管理を怠らないよう注意。 ※風音屋「Data Samurai」の学習コンテンツや「データマネジメント検定」「K-DEC」なども師匠代わりに活用可能。 #106
凡人が確実にできるのは「量をこなす」こと あなたが天才なら不要かもしれないが、凡人なのであれば、圧倒的な量をこなすことがプロへの最短経路。 ● ● ● 新卒1年目：配属直後の4ヶ月で19チームからの依頼を（泣きながら）120案件ほど捌いた。 新卒3年目：1ヶ月で50件のトラブル（システム障害）を（泣きながら）捌いた。 新卒4年目：4人のデータチームを立ち上げて半年間で300件の集計業務を（泣きながら）捌いた。 @yuzutas0は自分を「人間のクズ」だと思っているが、それでも幸運なことに、今日まで衣食住を満たし、 人並みの仕事をいただけているのは、クズなりに試行錯誤し、人並み以上の量をこなしてきたから。 https://speakerdeck.com/yuzutas0 #107
プロと同じ練習量を積み重ねずに、素人がプロに追いつけるだろうか 趣味や学生なら、無理せず 自由なペースで進めれば良い。 未経験者が何百万円ものお金を もらって仕事をするなら、 （＝トータル数億円を望むなら） （＝プロとして生きるなら） 1年目は全力でスキルを伸ばし 早めに壁を乗り越えるしかない。 楽しいかどうかは関係ない。 モチベーションも関係ない。 「これを自分の仕事にする」 「これで誰かの役に立とう」と （仮でもいいので）決めたならば 動物が息を吸って吐くのと同様に、プロとして専門分野のインプットとアウトプットを淡々と繰り返す。 勝木光『ベイビーステップ』より #108
量をこなす→審美眼が養われる→AIのアウトプットを10秒で指摘・判断できるようになる なぜ10秒で気付けるのか？ ● ● ● なぜ10秒で判断できるのか？ 同じようなミスを過去にしたことがあるから。 同じような内容を過去に考えたことがあるから。 同じような課題を過去に解決したことがあるから。 あなたの10倍の量をこなしている人たちは あなたがキャリア10年目にようやく辿り付く「審美眼」を 新卒1年目のうちに既に獲得していることになる。 新卒5年目になると、あなたの50年後のステージにいる。 10秒で判断できるのは、普段から10秒で判断しているから 様々なタイプの業務をこなさなければならない現代の仕事。そこで最も大切な技術とは”思考の瞬発力”!! 「いかに対処するか」をすばやく幾通りも考え、取捨選択し、適切な対処法を即座に実行に移す。 まずは専門分野のツールや考え方に慣れ、それを限りなく反射へと近づける訓練!! 冨樫 義博『HUNTER x HUNTER』より #109
「平均的な人材」が「平均的な努力」でやっていこうとするならば…… 「優先度の高い業務」にフォーカスして1日30分でもアドオンで学習や改善を積み重ねるしかないのでは。 少なくとも後悔だけはしないように、自分なりにベストを尽くすしかないのではないか。 「それだけやれば十分だ」とは言わないが、「それすらできないなら厳しい」とは言わざるを得ない時代。 葦原 大介『ワールドトリガー』より #110
1日30分だけでも学習や改善を積み重ねる https://yuzutas0.hatenablog.com/entry/2026/02/10/213000 / 『富岡村史』 #111
それができない人、できなかった人たちの分まで @yuzutas0の仕事部屋には 曽祖父の戦時品が飾ってあります。 「死を忘るるなかれ」（Memento mori） 「その日の花を摘め」（Carpe diem） と心に刻み続けるために。 http://yozvox.web.fc2.com/ 有志訳「もしも世界が100人の村だったら」、BBC NEWS JAPAN、CNN.co.jp NHKアーカイブス「中国大陸打通 苦しみの行軍１５００キロ ～静岡県・歩兵第３４連隊～」「紫雲丸沈没 修学旅行生ら死者多数」「地震発生から72時間 東日本大震災復興10年年表」 #112
「死に物狂いで生きるのは、権利じゃなくて、義務だ」 『終末のフール』『喧嘩商売』『逆境無頼カイジ 破戒録編』『魔王 JUVENILE REMIX』『ジョジョの奇妙な冒険』『鋼の錬金術師』より #113
自分で自分の背中を押せないか？ これまで知らなかったことを知る。 これまで出来なかったことが出来るようになる。 自分の中の世界が広がっていくことに充実感を覚える。 試行錯誤してプログラムが期待通りに動く。 データを確かめたら気になっていた結果が分かる。 自分が外の世界に介入していけることに高揚感を覚える。 それを仕事にして、周りの人達に貢献して、 巡り巡って世のため人のために価値を提供して 自分のクソみたいな人生を少しだけ肯定できるようになって 「自分なりに自分の人生を全うした」と最期に胸を張れるようになる。 この仕事に興味を持ったときに、この仕事と縁ができたときに（それが自分の意思でなかったとしても）、 心の奥底で1mmくらいは「そういう人生も悪くないかな」「今よりマシかもしれない」と思えなかったか？ そのために1日30分だけでも努力を上乗せしようと思えないか？ 自分で自分の背中を押せないか？ 諫山創『進撃の巨人』より #114
「平均的な組織」と「平均的な人材」の妥協点を探る 期待される役割・業務のうち、何％を実現できているか？ 1. 2. 3. 4. 実践していくにはどうしたら良いか？ 自組織におけるデータエンジニアリングの「業務一覧」および各「業務手順書」を作成する。 各業務に必要な「知識・技能」を一覧化し、それぞれの「学習ガイド」を整備する。 各メンバーの「知識・技能」の習熟度（スキルマップ）や「業務」の担当状況（アサインシート）を 書き出し、誰がいつまでにどうステップアップするのか、育成計画・アサイン計画を立てる。 メンバー1人1人がガイドに沿って学習し、知識習得・技能向上に伴って担当できる範囲が広がると、 結果として、データ組織の価値創出・事業貢献が広がったり、深まったりする。 ⇒マネージャーがこれを推進できるような余裕がないから困っている。 既存のテンプレートやアセットから取捨選択したり、気軽にリクエストできる土台がほしい。 ⇒メンバーが素直に自己学習・挑戦してくれないから困っている。 学習のハードルを下げて10分動画を視聴させつつ、理解度チェックテストで細かく確認したい。 さらに欲を言えば、データエンジニアリングの著書がそれなりに売れていて、企業研修の実績も豊富で、 東京大学で学生向けの授業を担当したり、国家試験の委員会を歴任した人が監修しているとベストでは？ 果たしてそんな人間がいるのか…！？ 今の日本には幸運なことに該当者がいる……！ そう @yuzutas0 が……！ #115
再掲：知識プラットフォーム「Data Samurai」 ● ● ● テーマごと＆ステップごとに「10分動画」＋「理解度チェックテスト」による知識習得。 Agent Skills & MCPを提供し、学習内容を実践に繋げる。メンバーは内容を理解した上でAIに指示。 「自社はこの内容を実践できているか」サーベイ回答やスキルマップによる組織アセスメント支援。 #116
再掲：本講演の概要 ＜タイトル＞ Beyond Your Data Engineering 2026 お前の考える狭いデータエンジニアリングの枠組みを越えてゆけ ＜趣旨＞ 「二宮金次郎」型のデータエンジニアが報われる時代ではないか。 “職域を与え、越境を免ずるのはデータエンジニアを救う道ではない。 それはただ貪欲と無頼を招くだけであり、 勤勉と自助だけがこれらのキャリアを救う道である。” ＜目次＞ 1. 去年のおさらい＋Diff 2. 扱うデータの話 3. 技術選定の話 4. アーキテクチャの話 5. 人材・キャリアの話 https://www.ninomiya.or.jp/kinzirozo/ #117
再掲：偉人の言葉をお借りして、今日のメッセージをまとめると…… 戸愚呂（弟）：おまえもしかして、まだ自分が死なないとでも思ってるんじゃないかね？ →耳障りの良い「AI時代でもデータエンジニアは大丈夫」に甘えるな！油断すると未来はないぞ！ アンディ・グローブ：もし我々が解雇されて、新しいCEOが連れて来られたら、その人は何をするだろう？ 今から一度この部屋を出て、新しいCEOになったつもりで戻ってきて、自分の手でそれをやるのはどうだ？ →もし今のデータエンジニアたちが失職する（あるいは就職・転職できなくなる）未来になったとして、 別の誰かがデータエンジニアリング業務を担っているのだとしたら、その人は何をしているのだと思う？ 二宮金次郎：金銭を与え、租税を免ずるのは彼らを救う道ではない。 それはただ貪欲と無頼を招くだけであり、勤勉と自助だけがこれらの村を救う道である。 →データエンジニアやアナリティクスエンジニアと職種名を区切り、ラクな形に担当範囲を区切り、 「これが自分の業務だ（これ以外はやらない）」「このツールの利用経験者は世に少ないから安泰だ」と 甘ったれたことを言って「聖域」化しても、中長期を見据えるとポジティブな未来にはならない。 マジメに日々の学習や挑戦を積み重ねて、価値貢献をしていくしか自分のキャリアを守る道はねぇんだよ！ ミッキーマウス（王様）：助けてもらうことじゃなくて、助けることを考えるべきだったんだ！ →どうやったら自分のキャリアを守れるかじゃなくて、どうやったら社会のニーズに応えられるかを考えろ！ 『幽遊白書』『パラノイアだけが生き残る』『二宮翁夜話』「Kingdom Hearts Ⅱ」およびその解説記事を元に一部記載を調整 #118
ご清聴ありがとうございました 改善サイクルを回し、今日よりも良い明日を。 https://kazaneya.com/contact #119