「だいたい動く」では足りない ― データの人がプロダクト開発に入るとき
1.4K Views
March 03, 26
スライド概要
関連スライド
各ページのテキスト
SWEとDSがLLMエンジニアになるための会 Vol.1 「だいたい動く」では⾜りない ― データの⼈がプロダクト開発に⼊るとき 株式会社IVRy アナリティクスエンジニア 吉⽥勇太 @IVRy Inc. All rights reserved.
⾃⼰紹介 吉⽥ 勇太 ■ 2015年: 株式会社ブレインパッド データサイエンティストとして様々なドメインのPJに参画 ■ 2023年: 株式会社10X ネットスーパーのデータプロダクト開発に従事 ■ 2025年: 株式会社IVRy IVRy Data Hub 新規事業サービス開発に参画 営業活動⽣産性向上のためのAIツール/プロダクト開発 ⇒ 分析からはじまり、プロダクト開発をやって、 今は社内AIツールの開発や新規事業開発をやっている人間です 22
LLMエンジニア？？ >正式名称はSWEとDSがLLMエンジ ニアになるための会です。 https://note.com/nash_efp/n/n6c498f7d4914 この登壇での定義は、 AI的な挙動 （決定論的ではない処理 /アウトプットを含むもの。 LLM処理や自 律的/Agenticな処理。）を実装できるエンジニア くらいの適当な言葉として話します @IVRy Inc. All rights reserved. 3
LLMエンジニア的要素？ データ的要素 ● 確率的挙動をするものの評価をする ● inputするデータの作成・更新（前処理や統計的品質チェック , 権限管理） ● etc… ソフトウェアエンジニアリング的要素 ● 数千人,万人に安定して使えるための設計（コスト設計含む） ● 障害が起きたときの復帰の仕組み 改善の仕組み ● チームでの開発・運用（プロジェクト管理 , チーム開発, チームビルディング） ● etc… これらのかけ合わせを LLMエンジニア としてみます なぜこれができる人が今アツいのか？ @IVRy Inc. All rights reserved. 4
AI時代のプロダクト論 従来 ・ユースケースを絞る ・MVPを作る ・うまくいったら横展開する ↓ AI時代 ・ある程度複雑なプロトタイプを高速で作り ・実際の業務データで試し ・使われた部分を抽出し ・不要な機能・コストを削ぎ落とす 引用: IVRy のデータ組織のこれまでとこれから- note @jxnlco 2025/6/6 post - X @IVRy Inc. All rights reserved. 5
LLMエンジニアは業務変⾰を起こせる AIエージェントを「機能」として提供しても、顧客の業務は本質的には変わりません。 重要なのは、 ● 顧客業務を分解し ● AIを前提に再設計し ● 組織の意思決定構造まで踏み込む ことです。ここにこそ、データ組織が事業をやる意味があります。なぜなら、 ● ● ● ● データ構造を理解し AI のできることを理解し 評価の難しさを理解し コスト構造を理解している これらを横断的に理解していることが必要だからです。 AI時代のプロダクトは、 データ構造と業務構造を同時に設計できる人間 立しません。 @IVRy Inc. All rights reserved. 引用: IVRy のデータ組織のこれまでとこれから- note が中心にならないと成 6
LLMエンジニアの登り⽅ たぶん、ドラクエの職業みたいなもので、いきなり LLMエンジニアにはなれない。 データ側、エンジニア側 から登って、LLMエンジニア（魔法剣士的な）になる = 分析やソフトウェアエンジニアリングのスキルある人が "LLMも" 使いこなしてる状態 データアナリスト/データサイエンティスト側から @IVRy Inc. All rights reserved. ソフトウェアエンジニア側から 自分はDS側から登ったのでこの発表では主にその視点から話してみる。 7
※ロールやキャリアチェンジの現実はもうちょっと⼊り乱れていそう。 シンプルな⼀本道ではない。 引用: IVRy のデータ組織のこれまでとこれから- note @IVRy Inc. All rights reserved. 8
データ⼈材は２つの観点からソフトウェアエンジニアリングのスキルが必要になる ①データ活用の価値を大きくするため ● ● ● データ活用/機械学習モデル作成などの成果を最大化するには、データ品質を担保する必 要がある。garbage in, garbage out. データ品質を担保するには、自動で動き続ける仕組み（システム）を作る必要がある ○ データ基盤、データエンジニアリング等 これらのスキルはソフトウェアエンジニアリングが関わってくる @IVRy Inc. All rights reserved. 9
データ⼈材は２つの観点からソフトウェアエンジニアリングのスキルが必要になる ②ビジネスインパクトを大きくするため ● ● ● データはプロダクトとして売れることがわかってきた。 Data as a Product というビジ ネスモデル。 データプロダクトにはさまざまな提供方法がある ○ 人間は根本的にどんどん楽な方に流れていく。そうするとアプリケーション化 / 自動化の流れに乗っていく。 Data Product と AIプロダクトはおそらくほとんど同義になっていく ○ Data Productからデータ供給を受けて AIプロダクトが駆動する ⇒ データ分野の人はソフトウェアエンジニアリングの領域に立ち入る圧を受けがち @IVRy Inc. All rights reserved. 10
@IVRy Inc. All rights reserved. 引用: データプロダクトとは何か- SpeackerDeck 11
@IVRy Inc. All rights reserved. 引用: データプロダクトとは何か- SpeackerDeck 12
基礎集計、網羅集計的な分析はエージェントがやる時代に 分析の価値の消費期限の短さ ● データ分析は（プロダクト開発に比べ）再現性はそれほどシビアではなかった。なぜか。 ○ データ分析の成果物は、分析レポートのように 作った瞬間に価値が最大となりその後急 速に価値が減る もの。寿命の短い成果物。 ○ ビジネスの現場では特に、インサイトを得られたらすぐに使い捨てることが多い。さらにコ ストをかけて正確さや再現性を求めることはしない。 ■ 使い捨てコードが生まれる理由でもある。 ● ● 提供コストの割に一瞬で消費されるのでアナリストの苦労が報われにくい。 その割にニーズは多いのでアナリストが需要スピードに答えられない。 ● これらの問題に対し、かつては データの民主化 = 非エンジニアも SQLを学習する で対応しよう としたが、今は「 AIエージェントに分析させる」がアンサーとなりそう。 参考: メルカリにおけるデータアナリティクスAI エージェント「Socrates」と ADK 活用事例 - SpeakerDeck @IVRy Inc. All rights reserved. 13
「意思決定のサポート」のサポートへ これまで ● データ分析・データ抽出による意思決定のサポート これから ● 分析・抽出の実行主体は現場のメンバーに移譲 ● 「分析・抽出で意思決定をサポートする人」をサポート ↓ AIエージェントを駆動させる AI Readyなデータ基盤作成 , データエンジニアリングがアナリスト職 にも求められ、より深いエンジニアリングスキルが求められるかもしれない 参考: データ職の今後の役割について考えてみた- note @IVRy Inc. All rights reserved. 14
データ分析の⼈がプロダクト開発の現場に移って難しかったこと ● ● ● データ分析とプロダクト開発（ソフトウェアエンジニアリングの世界）の違い 使うツールやスキルが変わるよりも、言語や考え方、価値観、求められている状況 が大きく変わる。 データアナリスト /データサイエンティスト の考え方をアンラーニングできるかが大 事。 @IVRy Inc. All rights reserved. 15
分析は分解、プロダクト開発は構築 分析脳のまま開発現場に入ると、『だいたい動く』で満足してしまう 思考の方向性 ● 分析：複雑なものを単純な要素に分ける。「なぜ？」を繰り返す。因果を辿る ● 開発：単純な部品を組み合わせて複雑なものを作る。「どうやって？」を繰り返す 扱う例外の考え方 ● 分析：外れ値は除外して傾向を見る。 2:8で切り捨てることも。 ● 開発：外れ値も含めて動かす。 N=1でもクラッシュしたらバグ 抽象化の方向 ● 分析：具体から抽象へ（ 100件のデータ → 1つのインサイト） ● 開発：抽象から具体へ（ 1つの設計 → 100画面で動くシステム） @IVRy Inc. All rights reserved. 16
属⼈性の許容度の違い 分析チームにスクラムやコードレビューを導入しても、いまいち馴染まなかった経験がある。 なぜ属人性の許容度が違うのか？ 分析側が（相対的に）属人性を許容する理由 ● 成果物の寿命が短いゆえに 引継ぎコスト > 成果物の価値 になりがち ● 再現できなくても「インサイトが得られたら OK」で終わる場面が少なくない ● 「この人の分析だから信頼できる」が価値になる（属人性がプラスに働く） ● Kaggleのように「一番精度出した人が偉い」文化の影響もあるかも プロダクト開発側が属人性を排除する理由 ● 成果物（システム）が長期間動き続ける → 作った人が辞めても動かないと困る ● 障害対応は「誰でもできる」状態じゃないとリスク（特定の人しか直せない は事業継続上のリス ク） ● コードレビュー、ペアプロ、ドキュメント化などの「属人性を下げる投資」が あたり前の世界 @IVRy Inc. All rights reserved. 17
違いは他にもたくさん 「正しさ」の定義 分析：統計的に正しい、論理的に正しい 開発：ユーザーにとって正しい、ビジネスとして正しい（正確さより速さが勝つことも） 失敗のコスト感覚 分析：間違っても「次の分析で修正」で済むことが多い 開発：本番障害は顧客影響。深夜対応。ポストモーテム。二度と起こさない仕組み作り フィードバックループの長さ・もしくは完成の定義 分析：納品したら終わり 開発：リリースしてからが本番。運用・保守・改善が続く。 ステークホルダーの数 分析：依頼者とのやりとりが中心 開発：PM、デザイナー、他チームのエンジニア、 CS、セールス...。調整コストが高い etc… @IVRy Inc. All rights reserved. 18
書籍で知識を得て、現場で⾎⾁にすることがとても多い分野 @IVRy Inc. All rights reserved. 19
学びが⼤きかった経験（⾃分の場合） dbtのような ETLツールでデータパイプラインを作る経験はすごく役にたった おすすめする理由 1. SQLを書くのでデータの人も参入しやすい 2. 中長期での安定運用を期待するものであり、ソフトウェアエンジニアリングの知識 が必要になる（ので頑張って学ぶ理由になる） 3. Data Productとしてビジネス化もありえるのでプロダクト開発にも発展しうる 4. チームで開発するものになるのでスクラム開発などを学ぶきっかけにもなる 5. 作成したデータはシステムだけではなく AIエージェントにも提供するようになる。コ ンテクストエンジニアリングの文脈でもまだ伸びしろのある分野。 6. データパイプラインは組織フェーズや保持するデータによって大きくあり方が変わ る。ベストプラクティスがすべてではない。人間の意思込めが大切にもなる（ AIにリ プレイスされにくいかも） @IVRy Inc. All rights reserved. 20
AI/LLMはどこで学ぶのか？ ● ● ● 従来の技術と違うのは、とにかくお金がかかること ○ 深層学習は学習にはお金がかかっていたが、使用（推論）にはお金がかからないみたいな 感じだったが。 ○ Claude Code, 都度のLLM処理 等 大量に処理をしてわかることもある ○ しかし個人でやるにはやや負担が大きい ○ 会社でガンガン使えるのが一番 しかしAI使用の予算取り方法は会社で大きくやり方が異なる ○ ガンガン行こうぜタイプ、 ROIを説明せよタイプ、人数を絞って検証しようタイプ、他社がどう やっているか調べてから稟議出してねタイプ 等... @IVRy Inc. All rights reserved. 21
宣伝）AIやるならIVRyはとても良い環境 :) ● ● ● プロダクトの価値の中心に AIがあるので常に積極利用推奨 Claude Code, Devin, Cursor, GitHub Copilot... などをガンガン使える ○ GeminiやDatabricksのLLM APIも LLM/AIエージェントサービス開発メンバーも積極採用中 で、吉田が実際に何を作っているか は来月のイベントで話すので また聞きに来てください！ @IVRy Inc. All rights reserved. IVRy社のconnpassで近日公開予定 22
まとめ ● 分析と開発は思考ベクトルが逆 ○ 分解 vs 構築 ○ LLMエンジニアは両方を統合、もしくは適切なアンラーニングが必要になる ● AI時代は、LLMを使えることではなく、 LLMが動き続ける構造を設計できる方が重要 ○ 「だいたい動く」から「動き続ける」へ ● データの人こそ構造設計を学べばプロダクトの中心になれる @IVRy Inc. All rights reserved. 23
we are hiring @IVRy Inc. All rights reserved. 24
@IVRy Inc. All rights reserved.