IVRy Data Jam '26 - Speaker Deck

IVRy Data Jam '26

by IVRy（アイブリー）のSpeaker Deck

Embed

Start on current slide

Slide 1

Slide 1 text

26 2026.07.30 @ IVRy 東京オフィス

Slide 2

Slide 2 text

IVRy Data Jam ʻ26 とは IVRy データチームの今を知ってもらおう、の会です！！！どんな⼈がいるのか、どんな仕事をしているのかあなたもメンバーの⼀員になりませんか！🎸🥁🎺 WE WANT YOU！

Slide 3

Slide 3 text

CDOから15min メンバー13名 x 3min LT 駆け抜けます⚡⚡🏃

Slide 4

Slide 4 text

株式会社IVRy（アイブリー）〒108-0073東京都港区三⽥三丁⽬5-19 住友不動産東京三⽥ガーデンタワー10F 設⽴ 2019年3⽉代表取締役奥⻄亮賀 (Ryoga Okunishi) 事業内容対話AIプラットフォーム「アイブリー」の運営従業員数 250名以上 (2026年4⽉末時点）

Slide 5

Slide 5 text

累計発着信数累計アカウント数 60,000 件 1億件 2026年6月末時点 2026年4月末時点導⼊数 98/99 業界顧客満⾜度 ※⽇本標準産業分類(令和5年)の中分類 99業界 ※2022年1⽉(⾃社調査)時点 2021 2022 2023 2024 2025 2026 ※出典：デロイトトーマツミック経済研究所「⾃動対話システム市場の現状と展望 2026年版（2024年度実績）」デロイトトーマツミック経済研究所「⾃動対話システム市場の現状と展望 2025年版（2023年度実績）」

Slide 6

Slide 6 text

Keynote データ組織がプロダクトになる未来 ~ Making "Work is Fun" a reality ~ Keisuke OSONE

Slide 7

Slide 7 text

2012年: 株式会社サイバード占いサイトの構築やモバイルアプリ開発の後、ビッグデータブームに伴いデータ分析部⾨⽴ち上げ等を担当 2016年: 株式会社Gunosy ニュース記事配信アルゴリムの改善およびグノシー事業責任者‧取締役 Chief Data Officer 2022年: 株式会社アダコテック Chief Development Officer として製造業における異常検知プロダクトの開発などに従事⼤曽根圭輔 Chief Data Officer Ph.D in Engineering 2024年: 株式会社IVRy データプロダクト IVRy Data Hub の事業開発とデータ組織の構築を担当。2026年7⽉より Chief Data Officer

Slide 8

Slide 8 text

IVRy Data Hub について

Slide 9

Slide 9 text

2025.11 にリリース！ IVRy Data Hubとは企業が保有するコミュニケーションデータ（通話、メールなど）を⼀元的に統合‧分析し、AIの⼒で経営課題の解決を⽀援します。従来活⽤が難しかった⾮構造なコミュニケーションデータを、AIの⼒で「リスクの予防的検知」「業務プロセスの抜本的な⾃動化」「顧客価値の戦略的な最⼤化」という3つの領域で活⽤可能なデータに変換します。 @IVRy Inc. All rights reserved.

Slide 10

Slide 10 text

IVRy Data Hubとは「検索」 IVRy Data Hubに集約されたデータに対して、⾃然⾔語で検索をかけることができます。網羅的に全てのデータを確認し、対象のコミュニケーションデータに絞って抽出や傾向分析ができます。⾃然⾔語で分析内容や分析軸を⾃由に指定可能実際の対話内容を元に傾向分析や⽰唆出し実際の対話履歴から⽂字起こしの確認が可能アイブリーの通話データは⾳声確認も可能 @IVRy Inc. All rights reserved.

Slide 11

Slide 11 text

IVRy Data Hubとは「通知」レポート通知あらかじめ登録したプロンプトの回答を、定期的に通知するように設定をしておくことができます。電話解約が発⽣した件数と原因の傾向をまとめたレポート通知 @IVRy Inc. All rights reserved. アラート通知 AIがコミュニケーションを監視し、アクション漏れや、リスク事象（ハラスメント等）を検知して通知します。「後ほど担当者から連絡します」と約束したものについて対応漏れを検知して通知

Slide 12

Slide 12 text

IVRy Data Hub の主な活⽤⽬的 ①オペレーションコストの削減レポーティングの負荷軽減と質向上 ②顧客体験の改善顧客の⽣の声を可視化‧経営/企画へ伝達これまで⼈が時間をかけていた集計‧分析‧報告を⾃動化し、⽂脈も踏まえた「客観的事実」としてリアルタイムでレポートします。お客様が不満に感じている⽣の声を可視化し、適切な部⾨へ届け改善サイクルを加速させます。 ③収益機会の最⼤化（LTV向上） ④リスク管理お客様数の拡⼤‧⽣産性の向上へブランド毀損や離職リスクの発⾒と軽減へコンバージョンにいたるコミュニケーションの特徴を顧客属性ごとに可視化し、CVRを改善します。クレーム∕カスハラの検知や、法令遵守モニタリング、対応漏れの防⽌などに寄与します。 @IVRy Inc. All rights reserved.

Slide 13

Slide 13 text

このプレゼンで伝えたいことデータ組織の成果物は、分析でも AI でも BI でもない未来へ価値を届け続ける「プロダクト」になるそして、そのプロダクトを⽣み続ける組織そのものが、プロダクトになる

Slide 14

Slide 14 text

プロダクトとは何か

Slide 15

Slide 15 text

プロダクトとは何かプロダクトとは価値交換システムであるプロダクトやサービス顧客ビジネス $$$ 顧客のために実現した価値ビジネスのために実現した価値プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届けるより引用

Slide 16

Slide 16 text

"Earn with your mind, not your time." - Naval Ravikant 価値は時間ではなくレバレッジから産まれる

Slide 17

Slide 17 text

プロダクトとは何か英語特徴作品 Work ⼀度作る商品 Goods / Merchandise 売れる製品 Product 継続して価値を届ける本講演では、継続的に価値を届けるものを『Product（製品）』と呼びます。

Slide 18

Slide 18 text

プロダクトとは何かプロダクトとは、⼀度作れば、何度でも価値を届け続けるものあるいは⾃分が働いていない間も働いてくれるもの特徴 ● 複製できる ● 継続的に価値を⽣む ● 改善され続ける ● Permissionless Leverage（誰の許可もいらないレバレッジ）

Slide 19

Slide 19 text

プロダクト?

Slide 20

Slide 20 text

仕事を「資産」へ変えるもの。それがプロダクト Project Product ⼀回だけ価値を届ける何度でも価値を届ける Project が終われば、終わる作った後も、24/7 働き続ける Work → Asset → Product

Slide 21

Slide 21 text

データ組織の歴史

Slide 22

Slide 22 text

データ組織の 15 年 BI Platform ML LLM 次レポート分析基盤モデル Agent ? Data Analyst Data Engineer Data Scientist AI Engineer ? データ組織は、その時代で価値ある成果物を作ってきた

Slide 23

Slide 23 text

Reporting Era 依頼を受けて、分析して、返す Business → Request → Data Analyst → SQL → PowerPoint 価値の源泉は「分析すること」そのもの⼈の⼿が⼊ることが前提。依頼の数がそのまま組織の上限になるため複製不可能

Slide 24

Slide 24 text

Platform Era Modern Data Stack が、分析の限界費⽤を下げた Modern Data Stack Build an experimentation platform BigQuery Snowﬂake that lowers the marginal cost of dbt Airﬂow experiments close to zero. Fivetran Analysis — Ron Kohavi (Microsoft) → 分析を「プロダクト化」 Experiment → Experimentation Platform

Slide 25

Slide 25 text

AI Era LLM が、これまで⼈の⼿を必要とした作業を引き受けた SQL Python 分析レポートコーディング分析能⼒そのものが、⺠主化される「分析できること」は、もう組織の差別化要因ではなくなる

Slide 26

Slide 26 text

データ組織がプロダクトになる

Slide 27

Slide 27 text

分析が AI になると、データ組織は何を作るのか？問い答え Data Product 分析がコモディティになった世界で、 Search Semantic Layer Evaluation Knowledge Workﬂow Agent 組織は何を残せるのか

Slide 28

Slide 28 text

データ組織そのものが、プロダクトになる今までは Organization ↓ Product これからは Organization = Product よい組織は、よいプロダクトと同じ性質を持つ継続的に価値を届けるアクションに繋げる改善され続けるレバレッジを⽣む

Slide 29

Slide 29 text

社内も社外も同じ Product に Internal / External はない。あるのは Users だけ Employees Customers Partners AI Agents Users 優れたプロダクトは、届け先で品質を変えない

Slide 30

Slide 30 text

Conway's Law よい Data Product を作るには、組織そのものを設計しなければならない Organizations design systems that mirror their communication structures. だからこそ、これからの役割はこう変わるかもしれない Data Product Evaluation Knowledge Data Product Builder Engineer Architect Orchestrator

Slide 31

Slide 31 text

⼈間は何をするの ?

Slide 32

Slide 32 text

⼈は何をするのか？ AI Agent Human 問いを⽴てる分析する実装する価値を設計する没頭する "Find work that feels like play to you." — Naval Ravikant

Slide 33

Slide 33 text

Work is Fun とは、仕事を楽しくすることではない⼈が最も価値を発揮できる仕事に集中すること

Slide 34

Slide 34 text

闇にいるなら光を探せ！光がないなら、⾃分が輝け！ FUJI ROCK FESTIVAL'26, Hi-STANDARD

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

闇にいるなら光を探せ！光がないなら、⾃分が輝け！ My life is a normal life working day to day - Hi-STANDARD, STAY GOLD Today's work becomes tomorrow's product. Tomorrow's product becomes everyone's work. その先に Making "Work is Fun" a reality.

Slide 37

Slide 37 text

Making "Work is Fun" a reality

Slide 38

Slide 38 text

LT 1/13 クライアントの声を聞け Hiroyuki Moriya

Slide 39

Slide 39 text

2020年以前: ⾊々やってました 2020年 ~ 2022年: DMM データサイエンス組織２⼈⽬にジョイン 2022年 ~ 2024年: Microsoft development MSN / Bingのソフトウェアエンジニアリング森⾕浩幸 AI Engineer 2024年: 株式会社IVRy AIエンジニアとして、新規プロダクト⽴ち上げなど

Slide 40

Slide 40 text

プロダクトを作っても、使ってもらうのは難しいコーディングエージェントによって、実装‧リリースの速度は改善された。でも、買ってもらえる‧使ってもらえる‧喜んでもらえるプロダクトを作るのは難しい。

Slide 41

Slide 41 text

IVRyは、プロダクトを⼤きく外すことは少ない電話‧FAX‧データエージェントなど、⼿広く開発に取り組んできた。どのプロダクトも、市場に受け⼊れてもらっている。スタートアップにおけるプロダクト失敗率と⽐べると、⽐較的うまくいっている。

Slide 42

Slide 42 text

「イシュー‧解決したい課題」が曖昧だと、良いプロダクトを作れない

Slide 43

Slide 43 text

イシュー解像度が低いと、曖昧なプロダクトを量産してしまう新規プロダクト開発の難しさは、「コーディング」ではなく、「ユーザーに刺さるか？」イシューが曖昧だと、「ユーザーに刺さる」確率が低いままである。打率が低いまま、打席に⽴ち続けても意味はない

Slide 44

Slide 44 text

クライアントの声を聞け

Slide 45

Slide 45 text

IVRyは、クライアントの声を聞きながら成⻑してきたたまたま作った電話プロダクトの反応が良かったのが始まり有識者の「電話なんて時代遅れでしょ」「すでに⼤企業が参⼊している」という声ではなく「クライアントが喜んでいる」「クライアントが継続して使っている」という事実を⼤事にしてきた

Slide 46

Slide 46 text

商談同席しろ

Slide 47

Slide 47 text

商談同席すると、良いことがたくさんあるクライアントの⼀次情報が⼿に⼊って、イシュー解像度が上がるプロダクトに対する期待値調整ができる「これはできないんですよ」を直接喋れるセールスとの共通⾔語が⽣まれるセールスの⼈たちとの⼀体感が出て、飲み会で盛り上がれる

Slide 48

Slide 48 text

まとめ

Slide 49

Slide 49 text

エンジニアは商談に出て、イシュー解像度を上げろ「エンジニアだから、商談に出ません」は⽢え。コーディングはAIがやってくれるので、エンジニアは別の形で付加価値を出すべき。

Slide 50

Slide 50 text

LT 2/13 AIエージェントとデータ基盤〜分析基盤から⾏動基盤へ〜 Kazuki Inamura

Slide 51

Slide 51 text

2017年: 株式会社サイバーエージェントエンタープライズ向けチャットボットエンジンの開発 2017年-2020年: 株式会社PKSHA Technology ⾃然⾔語処理を活⽤したエンタープライズ向け受託開発 2020-2024年: MNTSQ株式会社契約業務⽀援のエンタープライズ特化AI SaaS開発稲村和樹 AI Engineer 2024年: 株式会社IVRy 通話履歴データの設定や分析への利活⽤機能を開発

Slide 52

Slide 52 text

誰のためのデータ基盤？ - 従来：⼈間がデータ分析して意思決定する基盤 - ダッシュボードを⾒て、SQLを書いて、Notebook で分析して… - 今後：AI Agent が業務実⾏するための基盤 - Wiki を読む / SQLを書く / APIを呼ぶ / チケット起票する / 契約を更新する … => 業務のAI化にあたっては、業務⽂脈‧業務環境の整備が急務 - Context / Ontology Layer を各プラットフォーマーが統合 - どのようなテーブルがあるか（カタログ） Customerとは何か（業務上の意味/メタデータ） Contract と Customer はどう結び付くか（関係性）このAgentは何を実⾏してよいか（認可）更新するならどのAPIを呼ぶか（Action）

Slide 53

Slide 53 text

https://www.palantir.com/explore/platforms/foundry/ontology/

Slide 54

Slide 54 text

https://openai.com/ja-JP/business/frontier/

Slide 55

Slide 55 text

https://www.aboutamazon.com/news/aws/aws-summit-nyc-2026-ai-agents

Slide 56

Slide 56 text

データプロダクトに関わる⼈の今後 - 従来：⼈間のデータ活⽤者の⽀援 - ETL / DWH 設計 / Dashboard 提供 … - 今後：AI Agent が安全に働ける職場環境の設計とその活⽤⽀援 - 業務要件の整理 / Business Ontologyを設計 / Metadata整備 / 認可設計 / Action API 提供 … - 基盤に対する Read から Write の⽐重が⾼まっていく - shared role から embedded role の⽐重が⾼まっていくデータ基盤は分析基盤から⾏動基盤へと進化している流れにある

Slide 57

Slide 57 text

LT 3/13 IVRy Data Hub Agentのパフォーマンスを評価する Yuya Taguchi

Slide 58

Slide 58 text

2017年: 株式会社朝⽇新聞社⾃然⾔語処理の研究開発に従事し、⽂章要約の研究や⽂章校正SaaS「Typoless」の開発をリード 2026年: 株式会社IVRy IVRy Data Hubの評価基盤構築、要約ツールの開発を担当⽥⼝雄哉 AI Engineer

Slide 59

Slide 59 text

評価は⼤事、でも難しい… ● VOCの分析や応対品質の評価など、そもそも"正解が存在しない"ユースケースが多い ● そして出⼒の内容はユーザーのコミュニケーションデータに⼤きく左右される

Slide 60

Slide 60 text

ではどうやるのか？ ● 正解があるケースとないケースで分ける ○ 正解がある：今週の問い合わせ件数は？ ○ 正解がない：応対の改善施策を考えて ● 正解があるケース：それをもとに正答率を確認する ● 正解がないケース：LLM-as-a-Judgeを利⽤しつつ、⼈⼿のチェックも⾏う

Slide 61

Slide 61 text

点ではなく線で評価する ● ナイーブに「ユーザーの問い合わせ」と「出⼒結果」だけでは評価ができない ● Agentが呼び出したツールなどのTrajectory（軌跡）まで⾒ないと、最終結果の良し悪しを判定できない

Slide 62

Slide 62 text

LLM-as-a-Judgeをどこまで信⽤するか ● 「⼊⼒‧Trajectory‧出⼒」をもとにJudgeをさせても結果が⼀致しない ○ 1回⽬：🤖「忠実性がいいが網羅性に問題あり」 ○ 2回⽬：🤖「網羅性はあるが⼀部忠実ではない表現が…」 ○ 3回⽬：以下略 ● Agentの挙動もそもそも実⾏毎に微妙に異なるのに加え、 LLM-as-a-Judgeもブレがあり、Agent/Evalどちらも出⼒を安定させるのが難しい

Slide 63

Slide 63 text

評価はムズカシイ、だからこそやっていく ● 「成功指標を定め、評価データを作成し、⼈⼿評価もしつつ改善」という流れはいつの時代も変わらず

Slide 64

Slide 64 text

LT 4/13 ソフトウェアエンジニアが最低限すべきこと Yuki Gumizawa

Slide 65

Slide 65 text

2019年: 株式会社Gunosy 広告CVR推定システム周りの開発や、ニュースアプリのロジック開発に従事 2021年: ピクシブ株式会社イラスト共有SNSのおすすめロジックの改善を担当パーソナライズの導⼊などに従事桾澤優希 AI Engineer 2026年: 株式会社IVRy IVRy Data Hub の開発に従事

Slide 66

Slide 66 text

データチームには⾊々な⼈がいる

Slide 67

Slide 67 text

データチームには⾊々な⼈がいる職種 (Role) 主な役割と業務 Data Engineer データ分析基盤の構築‧運⽤、データパイプラインの設計‧開発、データの品質管理および最適化 Analytics Engineer 意思決定を⽀えるデータの集計‧分析、各種KPIの可視化ダッシュボード作成、ビジネス課題の抽出 AI Engineer LLMやAI Agent等を⽤いたプロダクト機能の設計‧開発、技術検証（PoC）の推進および精度‧実⽤性の評価 Data Product Orchestrator 顧客業務の構造化とPoC設計を起点に、データ連携‧活⽤環境の実装を推進し、成果と知⾒をテンプレ化してプロダクトに還元‧スケール Software Engineer プロダクトへのデータ機能の組み込み、データ活⽤を推進するアプリケーションや機能の設計‧開発‧運⽤所属してる⼈の例

Slide 68

Slide 68 text

Slide 69

Slide 69 text

⾃分しかいねぇ!

Slide 70

Slide 70 text

AIエンジニア (⼤嘘)

Slide 71

Slide 71 text

データチーム唯⼀のSWEがやっていること ● IVRy Data Hub のバックエンドの開発 ● IVRy Data Hub のフロントエンドの開発 ● IVRy Data Hub ⽤エージェントハーネスの開発 etc...

Slide 72

Slide 72 text

全部AIによってとって変わられそう

Slide 73

Slide 73 text

そうならないためにやりたいこと

Slide 74

Slide 74 text

コードリーディング

Slide 75

Slide 75 text

雰囲気で書いたコードの中⾝を理解しないと ● その後もずっと雰囲気でコードを書くしかなくなる ● 負債が貯まる ● ある時点でどうしようもないゴミが出来上がる ● ⼿がつけられなくなる

Slide 76

Slide 76 text

ソフトウェアエンジニアとして ● まだAI書いたコードについて⼈間が責任を持つ必要がある ● そうである以上Vibeで書かせたコードも全部⽬を通そう

Slide 77

Slide 77 text

責任持つ必要なくなったら仕事辞めます

Slide 78

Slide 78 text

LT 5/13 売上データを整備するとどうなる？知らんのか Yusuke Wada

Slide 79

Slide 79 text

2013 年: ヤフー株式会社 2019 年: 株式会社メルカリ 2022 年: 株式会社estie 2024 年: 株式会社IVRy 和⽥悠佑 Analytics Engineer Engineering Manager データアナリストとして⼊社したけど、アナリティクスエンジニアと名前を変えて働いてます。

Slide 80

Slide 80 text

結果的に古参（とはいえ来⽉で 3 年⽬）

Slide 81

Slide 81 text

外向けには綺麗なこと⾔ってんだけどセマンティックレイヤーだの…… AI Ready だの…… ※ やってないわけではない

Slide 82

Slide 82 text

「また売上データ（周り）の整備が始まる」⼊社してからずっと売上関連指標をメインに整備（⼊社してすぐ）この沼から出れねぇ ● 定義の標準化 ● データ処理のパイプライン化‧⾃動化範囲を拡⼤し続ける…… ● 売上に対するコストのデータ整備 ● ⼊⾦‧返⾦など会計的な観点の追加

Slide 83

Slide 83 text

データ職は組織の過去と向き合いがち……ツライ当時の例外、みたいなものの調整が常に発⽣ AI によって過去の⾮構造データも価値を持ち始めているデータの価値が⾼まるのは良いことである⼀⽅で⼀⼈で抱え続けるには⾟いところもある ※ これすらも AI が解決してくれるのか……？

Slide 84

Slide 84 text

皆でやっていきましょう！！ありがたいことに IVRy はデータが組織として拡⼤する⽅針がとれている今⽇のなんだかわからないイベントに集まってくれる同業の⽅も沢⼭いる同業種としてツラミをいい感じに対処していきましょう！今⽇は楽しみましょう！

Slide 85

Slide 85 text

LT 6/13 セールスチームの⽣産性を 10xするために AI Opsチームがやっていること Yuta Yoshida

Slide 86

Slide 86 text

2015年: 株式会社ブレインパッドデータサイエンティストとして様々なドメインのデータ分析‧機械学習システム構築PJに参画 2023年: 株式会社10X ネットスーパーのデータプロダクト開発に従事吉⽥勇太 Analytics Engineer 2025年: 株式会社IVRy 営業活動⽣産性向上のためのAIツール/プロダクト開発

Slide 87

Slide 87 text

AI Opsチームとは ● セールスチームの⽣産性向上を⽬指すチーム ● セールスオペレーション改善を担当するBizメンバーとエンジニアがタッグを組む ● 現場のペインをよく知るBizメンバーと、実装できるエンジニアが直接組んで、効率化のアプリや仕組みを作って試して現場定着を⽬指す ● 活動の軸は⼤きく ①社内ツール開発と ②AI活⽤の社内浸透の2つエンジニアメンバー合流 Sales Opsメンバー AI Opsチーム

Slide 88

Slide 88 text

現代の業務効率改善、ムズすぎ問題。 ● ● ● ● DX今昔 ○ 昔: 現実を機械に合わせる ○ 今: ⼈間都合のニッチなワークフローにAIが柔軟に合わせてくれる ○ どこまでを⾃動化して、どこからを運⽤でカバー（⼈間が責任をもつ）にする？ AIエージェント時代。⼈間を業務から外す？ ○ ⼈間がボトルネックになるので業務フローに関与させないようにするという⽅向性 ○ ⼈間を排除しすぎると別の問題がでてくるバイブコーディングの登場。どの抽象度で問題を解く？ ○ 内製する？買ってくる？ ○ SaaS的‧データプロダクト的な汎⽤ツールで解く？個別実装する？出来る現場の⼈は俺々業務効率アプリを作る。別チームが全体最適アプリを作る必要ある？

Slide 89

Slide 89 text

結果: 作ったアプリは使われない ● 理由 ○ そもそも現場業務が忙しすぎて新しいアプリを使う余裕‧学ぶ余裕がない ■ ○ Gemレベルの単純なツールはよく使う臨機応変な現場作業に対して、常に痒いところに⼿が届かない ■ 型化した瞬間から、常に現実に劣後する感覚 ■ ⾃分がやったほうが早い、に負ける ■ AI Opsチームがつくった物より、俺々アプリの⽅が使えるなど

Slide 90

Slide 90 text

今の境地（今後変わるかもだけど） ● ⼈間が操作するアプリケーションを作らない ○ 「業務に溶かす」状態 ○ 例: SalesForceへの商談内容⾃動記⼊ ■ 原則、⼈間の操作はなし。LLMが裏で全部記⼊。⼈間は商談するのみ。 ● インターフェースは馴染みのアプリだけで ○ 例: 情報はSlackに通知 ○ 例: データへの問い合わせはClaudeから ■ Databricksにデータセットを作成し、MCPで呼び出す

Slide 91

Slide 91 text

もしかして「データを⽤意する」だけが仕事に？ ● 実は「データ参照範囲が広いAIエージェント」で⼤体解決できるかも？ ● セマンティックなデータテーブルを完備する ● ○ このときにドメイン知識もたくさん必要になる ○ それをClaudeが読みに来る体制を整える ○ いつか、AIエージェントがデータをエンリッチメントするようにもなりそうやることは、データエンジニア的な領域になるかなぁ ○ データの拡充 ○ 権限管理（誰が、どのデータにアクセスしていいか‧ダメか） ■ 社⻑が⾒れるデータと、⼀般社員が⾒れるデータは違う ○ AI挙動のモニタリング‧コスト管理 ○ 利⽤者（⼈間）とAIの橋渡しをする役⽬

Slide 92

Slide 92 text

LT 7/13 僕たちは失職するために仕事している Ryosuke Noaki

Slide 93

Slide 93 text

2020年: 株式会社エウレカ BIエンジニアとして、pairsのプロダクト改善を⽬的としたデータ分析業務、A/Bテスト設計、KPI設計、ダッシュボード構築、などを担当。 2025年: 株式会社IVRy 野秋良介 Analytics Engineer 分析基盤の整備や、データ活⽤を⽀えるテーブル設計‧運⽤といったデータイネーブルメントを担当。

Slide 94

Slide 94 text

 Data Product データプロダクトを作って稼ぐ  Data Enablement 事業の状況を把握‧分析  AI Ops AIで社内業務の効率化   Data Infra データを集めて、利⽤可能に

Slide 95

Slide 95 text

イネーブルメント活動のゴールは⾃分の消滅

Slide 96

Slide 96 text

チームトポロジーが⽰す「イネーブルメント」チームトポロジーによるとイネーブルメントチームとは、他チームが”⾃⼒でできる”ようにする存在恒久的な依存先になった時点で、それは失敗である。⽀援先が⾃⽴する = ⾃分の必要がなくなる

Slide 97

Slide 97 text

わたしのおしごとビジネス指標の定義をすり合わせる共通データソース基盤を整えるデータ⼊⼒‧品質を標準化するドキュメント化して脱属⼈化する

Slide 98

Slide 98 text

おしごとが完了すると...？ビジネス指標の定義をすり合わせるデータ⼊⼒‧品質を標準化するドキュメント化して脱属⼈化する ▶ もう聞かなくていい ▶ 経由しなくていい ▶ 直さなくていい ▶ いなくても回る共通データソース基盤を整える

Slide 99

Slide 99 text

おしごとが完了すると...？ “⾃分への依存を消す”作業ビジネス指標の定義をすり合わせるデータ⼊⼒‧品質を標準化するドキュメント化して脱属⼈化する ▶ もう聞かなくていい ▶ 経由しなくていい ▶ 直さなくていい ▶ いなくても回る共通データソース基盤を整える

Slide 100

Slide 100 text

やり切った瞬間、この4つの仕事は消える「的確な意思決定を最速で⾏える環境を作る」のが⽣存価値 (くそでかコストセンターであり、会社の中でProﬁtを⽣み続ける意味づけをし続けければレイオフされる) ＝失職するために仕事している

Slide 101

Slide 101 text

失職を恐れて環境整備の⼿を抜けば、じわじわ⽴場を失う。⾃ら失職しにいく奴だけが、次の椅⼦に座り直せる。

Slide 102

Slide 102 text

泥臭い仕事や⽣存戦略を考え続けるツラみについて共感してくださる⽅はぜひ、お話しましょう！

Slide 103

Slide 103 text

LT 8/13 ⼊社1ヶ⽉からみたIVRyの組織⾵⼟：期待値と実体験の統合的分析 Kazuya Ozawa

Slide 104

Slide 104 text

免責事項権利および⾒解の帰属 ● 本発表におけるすべての発⾔‧記述は発表者個⼈の⾒解であり、所属企業の公式解釈を⽰すものではありません。⾮保証事項 ● 内容の正確性‧完全性‧有⽤性について⼀切保証いたしません。本情報の利⽤により⽣じた損害について発表者は責任を負いかねます。演出に関する謝罪 ● 本発表における過度に厳格な演出は、「前後のカジュアルなLTとの⽐較が、⾯⽩いのではないか」という当社内の定例協議（いわゆる「内輪ノリ」）に基づき企画‧ 実施されたものです。 ● ご聴講の皆様におかれましては、甚だ⾒苦しい演出となりましたことを切にお詫び申し上げます。

Slide 105

Slide 105 text

2015年: 株式会社データフォーシーズ分析コンサルタントとして、⼤⼿通信会社の多数の分析プロジェクトに従事。 2023年: 株式会社AbemaTV データアナリスト/エンジニアとして、データ分析、データ基盤運⽤、セルフ分析環境の構築‧推進。⼩澤和也 Analytics Engineer 2026年: 株式会社IVRy 7⽉にアナリティクスエンジニアとして⼊社。 IVRy Data Hubの成⻑のためのデータ活⽤を担当。

Slide 106

Slide 106 text

本発表の構成本発表は、発表者のIVRy⼊社前の事前イメージによる期待値から、⼊社後の実体験‧実態調査に基づく印象の変化を整理し、当社を認知していない層へ忖度のない実態を開⽰することを⽬的とする。 1. ⼊社前における期待値 2. ⼊社後における実態調査結果 3. 総括

Slide 107

Slide 107 text

⼊社前における期待値組織⾵⼟：⼊社障壁に対する警戒感 ● 公開情報より、過度に洗練された排他的⽂化 ○ 独⾃のVision 「Making "Work is Fun" a reality. 」 ○ オフィスのボルダリング壁および⼊社後のレゴ配布のような特徴的な雰囲気組織状態：急成⻑に伴う構造的混乱 ● 急激な事業拡⼤フェーズ特有の「⾮効率的かつキャッチアップ困難な混沌状態」への懸念

Slide 108

Slide 108 text

⼊社後における実態調査結果組織⾵⼟：Vision主導の合理的カルチャー ● Visionは、「顧客の仕事を良くする」「熱中して成果を出す」といった姿勢を内包 ● 特徴的な演出は、Vision体現に合理的であることを確認組織状態：⾃律統制機能を持つ「健全な混沌」 ● 事業‧組織拡⼤に伴う過渡的混沌は認められる ● 徹底された情報公開性（Notion/Slack等）と各社員の⾃発的な改善的⾏動により、⾃律統制機能が作動

Slide 109

Slide 109 text

総括⼊社前のIVRyへの印象は誤認であり、実際には極めて⽣産的かつ先進的な環境であることが実証された。入社前における期待値入社後における実態調査結果組織⾵⼟過度に洗練された入社障壁の高い新興企業深い企業ミッションとそれを支える合理的な施策組織状態急速な事業成長に伴う、非効率的・追従困難な混沌一定の混沌を伴いつつ、自律統制機能を有する

Slide 110

Slide 110 text

本発表に関する公表⽂献本発表で取り扱った題材につきまして、以下の公表⽂献(note)でも取り扱っております。 ● 【⼊社エントリ】「Work is Fun」を語る敷居が⾼そうな会社につい勢いで⼊社した結果

Slide 111

Slide 111 text

LT 9/13 経理も採⽤もプロダクトも全データ突っ込んで権限整理したるでー George - Yuji Yamamoto

Slide 112

Slide 112 text

4社⾊々セールス LINE 事業企画、マーケティング楽天データエンジニアアンドパッド経営企画⼭本雄⼠ Data Engineer IVRy データエンジニア

Slide 113

Slide 113 text

まず、全部突っ込みました経理‧財務 • 会計ソフトの仕訳 • 経費精算採⽤‧⼈事プロダクト • ATS（選考データ） • サービスDB • 組織マスター • ⾏動ログ • エンゲージメントサーベイ • 決済ただ、「⾒えてはいけないもの」も 1 か所に集まりました。

Slide 114

Slide 114 text

「⼈事データ」は、⼀枚岩じゃない社内オープン秘匿組織マスター採⽤結果誰がどの部署にいるかは、採⽤システムの選考評価。全社に公開されている個⼈情報の観点から採⽤関係者のみに絞る「⼈事データを⾒られる⼈」では定義できない

Slide 115

Slide 115 text

異動は、ヤバい⼊社付ける ✓ — 退職 — 剥がす ✓ 異動付ける ✓ 剥がす？⾜すのはみんなやる。剥がすのは、忘れる。

Slide 116

Slide 116 text

やってること最⼩権限で切る職能や役職ではなく、データの属性で縛る申請と付与を、記録に残す Slackとterraform。誰が‧いつ‧何に対して、が後から追える定期的に棚卸す⾃動化は道半ば。⼿も動かしています「記録の残らない権限付与はしない」ここだけは死守

Slide 117

Slide 117 text

で、いちばん権限を持ってるのは僕なんですけど基盤を作った⼈間は、構造上ぜんぶ⾒えてしまう⾃分で⾃分を縛るのは、正直むずかしい Databricks で、ロールの assume ができるようになった常時フルアクセスをやめて、必要なときだけ切り替える

Slide 118

Slide 118 text

きつくすれば、じゃま。ゆるくすれば、こわい。その間を、ずっと調整していく仕事。⼈に残された仕事、権限付与。

Slide 119

Slide 119 text

LT 10/13 え、データエンジニアが商談に出るんですって！？ Kenji Matsuda

Slide 120

Slide 120 text

2014年: ヤフー株式会社新卒⼊社し、広告配信システムのDMP開発に従事 2016年: 株式会社カケハシ薬局向けSaaSのスタートアップに6⼈⽬として参画松⽥健司 Data Engineer 2025年: 株式会社IVRy データ基盤の構築やIVRy Data Hubの開発に従事

Slide 121

Slide 121 text

社内のデータ基盤を作りつつ、商談にも出ます。

Slide 122

Slide 122 text

お客様の声を、直接聞ける。だから、意味のある開発ができる。

Slide 123

Slide 123 text

温度感がわかる

Slide 124

Slide 124 text

でも、⾔われたまま作らない。御⽤聞きでもない。押し付けでもない。

Slide 125

Slide 125 text

リアルタイムなんていらなかった

Slide 126

Slide 126 text

カスタマイズして、売らない。その場限りの開発はやらない。

Slide 127

Slide 127 text

会社の資産にならない

Slide 128

Slide 128 text

要望を蒸留して、プロダクトに還元する。

Slide 129

Slide 129 text

1社の声が積み重なり、プロダクトが複利で育つ

Slide 130

Slide 130 text

声を直接聞き、蒸留し、還元する。それが、商談に出るデータエンジニアの⾯⽩さ。

Slide 131

Slide 131 text

ぜひデータエンジニアあるある話しましょう！

Slide 132

Slide 132 text

LT 11/13 それで、Agentic Search って何なのよ Kazuaki Hiraga

Slide 133

Slide 133 text

Infoseek Japan (楽天) / FAST (Microsoft) / Basis Technology など Web 検索、ニュースアグリゲーション‧検索、NLP関連などソフトウェア‧エンジニア∕シニア‧ソフトウェア‧エンジニア 2012年: 楽天株式会社新検索基盤開発のシニア‧ソフトウェア‧エンジニア 2019年: 株式会社メルカリ新検索基盤開発のシニア‧ソフトウェア‧エンジニアその後、検索チームのTL/EM 平賀⼀昭 Principal Search Engineer 2023年: クーガー株式会社 AI（NLP/CV）チームのTL/EM 2026年: 株式会社IVRy 検索基盤開発に従事

Slide 134

Slide 134 text

Agentic Search って何なのよ RAG と何が違うの？ AI 検索と何が違うの？

Slide 135

Slide 135 text

なぜ検索が必要なのか？最新情報‧社内情報‧正確な根拠を得るために検索が必要なぜなら Knowledge Cutoﬀ 最新情報は知らない Grounding 根拠‧社内情報‧⼀次情報が必要 ↓ Hallucination

Slide 136

Slide 136 text

RAG とは違うの？ RAG 検索して答える Agentic Search RAG Agentic Search 質問 ↓ 検索 ↓ 回答ゴール ↓ 計画 ↓ 検索 / Tool Use ↕ Reflection ↓ 回答⽬的を達成するために検索を使う ※ ※広く共有された明確な定義がまだないため、ここではこのように定義しています

Slide 137

Slide 137 text

検索は？ 20年前は⼈が検索ボックスにキーワードを⼊⼒していました RAG では LLM が検索するようになりました Agentic Search では、AI が⽬的を理解し必要に応じて検索を⾏うようになります

Slide 138

Slide 138 text

つまり検索は？ Knowledge Cutoﬀ がある限り Grounding が必要な限り必須ただし検索の主役は⼈からAIへ

Slide 139

Slide 139 text

Agentic Search とは？良い検索ができなければ良い Grounding はできない良い Grounding ができなければ良い Agent も作れない Agentic Search は検索を置き換える技術ではなく検索の価値をさらに⾼める技術

Slide 140

Slide 140 text

LT 12/13 AI時代の “オーケストレーター” という役割 Sorami Shiromizu

Slide 141

Slide 141 text

1989年⽣まれ 2012: 奈良先端科学技術⼤学院⼤学（NAIST）⾃然⾔語処理の基礎研究 2014: ブレインパッドデータサイエンティスト 2017: ワークス徳島⼈⼯知能NLP研究所研究開発, 形態素解析器Sudachi 2020/2026: Legalscape 法律領域でのデータ整備‧RAG開発⽩⽔空海 Data Product Orchestrator 2022: MIERUNE 位置情報‧地図‧データ可視化 2026: IVRy Data Product Orchestrator

Slide 142

Slide 142 text

Hello World !

Slide 143

Slide 143 text

🍼

Slide 144

Slide 144 text

2026

Slide 145

Slide 145 text

AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI

Slide 146

Slide 146 text

No content

Slide 147

Slide 147 text

87年解けなかったヤコビアン予想を、AIが「SNSの1ポストに収まる短さ」であっさり反証 https://theconversation.com/hello-there-the-jacobian-conjecture-is-false-thanx-why-a-tiny-social-media-post-has-mathematicians-rethinking-ai-283883

Slide 148

Slide 148 text

1989

Slide 149

Slide 149 text

出典: ⼈事院ホームページ, ウィキメディア‧コモンズ / CC BY 4.0 https://commons.wikimedia.org/wiki/File:Keizo_Obuchi_cropped_Keizo_Obuchi_19890107.jpg

Slide 150

Slide 150 text

出典: Lear 21 (English Wikipedia) / CC BY-SA 3.0 https://commons.wikimedia.org/wiki/File:West_and_East_Germans_at_the_Brandenburg_Gate_in_1989.jpg

Slide 151

Slide 151 text

36 年 1989 → 2026

Slide 152

Slide 152 text

パソコンパソコンパソコンパソコンパソコンパソコンパインターネットインターネットインターネットインターモバイルモバイルモバイルモバイルモバイルモバイルモパソコンパソコンパソコンパソコンパソコンパソコンパインターネットインターネットインターネットインターモバイルモバイルモバイルモバイルモバイルモバイルモパソコンパソコンパソコンパソコンパソコンパソコンパインターネットインターネットインターネットインターモバイルモバイルモバイルモバイルモバイルモバイルモパソコンパソコンパソコンパソコンパソコンパソコンパインターネットインターネットインターネットインターモバイルモバイルモバイルモバイルモバイルモバイルモ

Slide 153

Slide 153 text

No content

Slide 154

Slide 154 text

スパコン性能の進歩 1989 2026 2.1 2,198,000,000 GFLOP/s → GFLOP/s 1989: Cray Y-MP/832 https://en.wikipedia.org/wiki/Cray_Y-MP 2026: LineShine https://top500.org/lists/top500/2026/06/ LINPACK系ベンチマークFP64実測値.ただし完全に同⼀のベンチマークではなく'89年は前⾝版

Slide 155

Slide 155 text

スパコン性能の進歩 1989 2.1 GFLOP/s 2026 10 億倍 → 2,198,000,000 GFLOP/s 当時32年かかった計算を、いま1秒で 1989: Cray Y-MP/832 https://en.wikipedia.org/wiki/Cray_Y-MP 2026: LineShine https://top500.org/lists/top500/2026/06/ LINPACK系ベンチマークFP64実測値.ただし完全に同⼀のベンチマークではなく'89年は前⾝版

Slide 156

Slide 156 text

No content

Slide 157

Slide 157 text

6倍 20.2兆ドル → 121.6兆ドル

Slide 158

Slide 158 text

🏦

Slide 159

Slide 159 text

出典：Wikimedia Commons, Nordean historia-arkisto, ELKA, パブリックドメイン https://en.wikipedia.org/wiki/File:Pohjoismaiden_Osakepankin_Helsingin_sivukonttori.jpg

Slide 160

Slide 160 text

No content

Slide 161

Slide 161 text

ATMでは、銀⾏業務は変わらなかった … 銀⾏窓⼝係と ATMの数 1970-2010 出典: James Bessen, Learning by Doing ( ) David Oks, "Why ATMs didn't kill bank teller jobs, but the iPhone did" https://davidoks.blog/p/why-the-atm-didnt-kill-bank-teller

Slide 162

Slide 162 text

… しかし iPhone が、銀⾏業務を終わらせた⽶国での銀⾏窓⼝係の数 2000-2025 David Oks, "Why ATMs didn't kill bank teller jobs, but the iPhone did" https://davidoks.blog/p/why-the-atm-didnt-kill-bank-teller

Slide 163

Slide 163 text

技術、だけでは⾜りない

Slide 164

Slide 164 text

AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI

Slide 165

Slide 165 text

❌ いまの業務をAIで効率化する ✅ AI前提で業務を作り直す

Slide 166

Slide 166 text

そのためには ... 技術と業務を深く理解した上で、全体を俯瞰して構成する

Slide 167

Slide 167 text

オーケストレーターとは ... エンジニア、セールス、経営、そしてお客さんといった、⽴場も専⾨も違う⼈たちのあいだに⽴ち、業務のつくり直しから、プロダクト開発、そして世の中へ広く届けるところまでをつなぐ役割

Slide 168

Slide 168 text

AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI

Slide 169

Slide 169 text

⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽂字⽂字⽂字⽂字⽂字⽂字⽂字⽂字活版印刷活版印刷活版印刷活版印刷活科学科学科学科学科学科学科学科学鉄道鉄道鉄道鉄道鉄道鉄道鉄道鉄道コンピューターコンピューターコンピインターネットインターネットインタ

Slide 170

Slide 170 text

No content

Slide 171

Slide 171 text

No content

Slide 172

Slide 172 text

、前まで年 0 20 どもがほんの⼦のた 1⼈んでい 2⼈に死にの前思春期それが 19 50年には 27%、 2020年には4. 3%まで低下した

Slide 173

Slide 173 text

🍼

Slide 174

Slide 174 text

https://ivry.jp/company/vmv/

Slide 175

Slide 175 text

LT 13/13 社⻑⾯談で号泣して⼊社を決めました Rio Kurihara

Slide 176

Slide 176 text

2016年: 株式会社ブレインパッド様々なドメインのデータ分析‧機械学習 PJ に従事クライアントワークと開発の両輪 2023年: 株式会社メルカリメルペイ与信モデルの開発‧保守運⽤ Tech Lead / PjM 栗原理央 Data Product Orchestrator 2026年: 株式会社IVRy Data Product Orchestrator

Slide 177

Slide 177 text

⼊社の経緯から⼊社後までを 3分で駆け抜けます

Slide 178

Slide 178 text

社会⼈10年⽬を⽬前にしたアラサーの苦悩がむしゃらだった10年「⾃分はこれまでに何かを成し得てきただろうか」「このままでいいのか」という漠然とした不安に駆られる⽇々

Slide 179

Slide 179 text

アルムナイでの出会い吉⽥勇太 Analytics Engineer

Slide 180

Slide 180 text

爆速の選考⼀次⾯接からオファーまで5営業⽇

Slide 181

Slide 181 text

決め⼿となった会⾷⼤曽根さん吉⽥さん稲村さん花⽊さん Chief Data Oﬃcer Analytics Engineer AI Engineer Principal AI Engineer

Slide 182

Slide 182 text

決め⼿となった会⾷⼤曽根さん吉⽥さん稲村さん花⽊さん

Slide 183

Slide 183 text

環境を変えることが怖かった背中を押してほしかった

Slide 184

Slide 184 text

奥⻄さん（代表取締役/CEO）と15分の⾯談漠然とした不安をそのままぶちまけた

Slide 185

Slide 185 text

奥⻄さんと15分の⾯談漠然とした不安をそのままぶちまけた成功体験がない。どこにいってもうまくいかないのでは ... 自分の課題は何か？どこにどう向かえばいいのかわからない二人育児とスタートアップは両立できるのか ...

Slide 186

Slide 186 text

奥⻄さんと15分の⾯談成功してきた人は自分の勝ちパターンを知っているから、最初の半年はそれを使って成果を出せる代表取締役 / CEO 奥⻄さん

Slide 187

Slide 187 text

奥⻄さんと15分の⾯談成功してきた人は自分の勝ちパターンを知っているから、最初の半年はそれを使って成果を出せる代表取締役 / CEO 奥⻄さんでも、そのあとは頭打ちすることが多い

Slide 188

Slide 188 text

奥⻄さんと15分の⾯談一方、成功体験が少ない人は成功するためにたくさん試行錯誤をして、いろんな引き出しを開けてきているはず。代表取締役 / CEO 奥⻄さん

Slide 189

Slide 189 text

奥⻄さんと15分の⾯談一方、成功体験が少ない人は成功するためにたくさん試行錯誤をして、いろんな引き出しを開けてきているはず。代表取締役 / CEO 奥⻄さんそうしてきたでしょ？

Slide 190

Slide 190 text

https://note.com/kai_yon/n/nd8ad8f4fff89

Slide 191

Slide 191 text

⼊社理由‧⼊社してみてどうか（真⾯⽬ ver.） @懇親会

Slide 192

Slide 192 text

Closing Keisuke Osone

Slide 193

Slide 193 text

データチーム積極採⽤中です！募集中のデータ系ポジション、カジュ⾯リンク、参考情報等はすべてこちらのページにあります！ https://ivry.jp/lp-article/data-team/