IVRy Data Jam '26

2026/07/30(木)に実施した「IVRy Data Jam '26」の資料です。
https://ivry.connpass.com/event/398000/

1. 26 2026.07.30 @ IVRy 東京オフィス
2. IVRy Data Jam ʻ26 とは IVRy データチームの今を知ってもらおう、の会です！！！ どんな⼈がいるのか、どんな仕事をしているのか あなたもメンバーの⼀員になりませんか！🎸🥁🎺 WE WANT YOU！
3. CDOから15min メンバー13名 x 3min LT 駆け抜けます⚡⚡🏃
4. 株式会社IVRy（アイブリー） 〒108-0073東京都港区三⽥三丁⽬5-19 住友不動産東京三⽥ガーデンタワー10F 設⽴ 2019年3⽉ 代表取締役 奥⻄ 亮賀 (Ryoga Okunishi) 事業内容 対話AIプラットフォーム「アイブリー」の運営 従業員数 250名以上 (2026年4⽉末時点）
5. 累計発着信数 累計アカウント数 60,000 件 1億 件 2026年6月末時点 2026年4月末時点 導⼊数 98/99 業界 顧客満⾜度 ※⽇本標準産業分類(令和5年)の中分類 99業界 ※2022年1⽉(⾃社調査)時点 2021 2022 2023 2024 2025 2026 ※出典：デロイト トーマツ ミック経済研究所「⾃動対話システム市場の現状と展望 2026年版（2024年度実績）」 デロイト トーマツ ミック経済研究所「⾃動対話システム市場の現状と展望 2025年版（2023年度実績）」
6. Keynote データ組織が プロダクトになる未来 ~ Making "Work is Fun" a reality ~ Keisuke OSONE
7. 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
8. IVRy Data Hub について
9. 2025.11 にリリース！ IVRy Data Hubとは 企業が保有するコミュニケーションデータ（通話、メールなど）を⼀元的に統合‧分析し、AIの⼒で経営課題の解決を ⽀援します。従来活⽤が難しかった⾮構造なコミュニケーションデータを、AIの⼒で「リスクの予防的検知」「業務プロ セスの抜本的な⾃動化」「顧客価値の戦略的な最⼤化」という3つの領域で活⽤可能なデータに変換します。 @IVRy Inc. All rights reserved.
10. IVRy Data Hubとは「検索」 IVRy Data Hubに集約されたデータに対して、⾃然⾔語で検索をかけることができます。 網羅的に全てのデータを確認し、対象のコミュニケーションデータに絞って抽出や傾向分析ができます。 ⾃然⾔語で分析内容や分析軸を ⾃由に指定可能 実際の対話内容を元に 傾向分析や⽰唆出し 実際の対話履歴から⽂字起こしの確認が可能 アイブリーの通話データは⾳声確認も可能 @IVRy Inc. All rights reserved.
11. IVRy Data Hubとは「通知」 レポート通知 あらかじめ登録したプロンプトの回答を、 定期的に通知するように設定をしておくことができます。 電話解約が発⽣した件数と原因の傾向をまとめたレポート通知 @IVRy Inc. All rights reserved. アラート通知 AIがコミュニケーションを監視し、アクション漏れや、 リスク事象（ハラスメント等）を検知して通知します。 「後ほど担当者から連絡します」と約束したものについて 対応漏れを検知して通知
12. IVRy Data Hub の主な活⽤⽬的 ①オペレーションコストの削減 レポーティングの負荷軽減と質向上 ②顧客体験の改善 顧客の⽣の声を可視化‧経営/企画へ伝達 これまで⼈が時間をかけていた集計‧分析‧報告を ⾃動化し、⽂脈も踏まえた「客観的事実」として リアルタイムでレポートします。 お客様が不満に感じている⽣の声を可視化し、 適切な部⾨へ届け改善サイクルを加速させます。 ③収益機会の最⼤化（LTV向上） ④リスク管理 お客様数の拡⼤‧⽣産性の向上へ ブランド毀損や離職リスクの発⾒と軽減へ コンバージョンにいたるコミュニケーションの特徴 を顧客属性ごとに可視化し、CVRを改善します。 クレーム∕カスハラの検知や、法令遵守モニタ リング、対応漏れの防⽌などに寄与します。 @IVRy Inc. All rights reserved.
13. このプレゼンで伝えたいこと データ組織の成果物は、分析でも AI でも BI でもない 未来へ価値を届け続ける「プロダクト」になる そして、そのプロダクトを⽣み続ける 組織そのものが、プロダクトになる
14. プロダクトとは何か
15. プロダクトとは何か プロダクトとは価値交換システムである プロダクトや サービス 顧客 ビジネス $$$ 顧客のために 実現した価値 ビジネスのために 実現した価値 プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届けるより引用
16. "Earn with your mind, not your time." - Naval Ravikant 価値は時間ではなくレバレッジから産まれる
17. プロダクトとは何か 英語 特徴 作品 Work ⼀度作る 商品 Goods / Merchandise 売れる 製品 Product 継続して価値を届ける 本講演では、継続的に価値を届けるものを『Product（製品）』と呼びます。
18. プロダクトとは何か プロダクトとは、⼀度作れば、何度でも価値を届け続けるもの あるいは⾃分が働いていない間も働いてくれるもの 特徴 • 複製できる • 継続的に価値を⽣む • 改善され続ける • Permissionless Leverage（誰の許可もいらないレバレッジ）
19. プロダクト?
20. 仕事を「資産」へ変えるもの。それがプロダクト Project Product ⼀回だけ価値を届ける 何度でも価値を届ける Project が終われば、終わる 作った後も、24/7 働き続ける Work → Asset → Product
21. データ組織の歴史
22. データ組織の 15 年 BI Platform ML LLM 次 レポート 分析基盤 モデル Agent ? Data Analyst Data Engineer Data Scientist AI Engineer ? データ組織は、その時代で価値ある成果物を作ってきた
23. Reporting Era 依頼を受けて、分析して、返す Business → Request → Data Analyst → SQL → PowerPoint 価値の源泉は「分析すること」そのもの ⼈の⼿が⼊ることが前提。依頼の数がそのまま組織の上限になるため複製不可能
24. Platform Era Modern Data Stack が、分析の限界費⽤を下げた Modern Data Stack Build an experimentation platform BigQuery Snowflake that lowers the marginal cost of dbt Airflow experiments close to zero. Fivetran Analysis — Ron Kohavi (Microsoft) → 分析を「プロダクト化」 Experiment → Experimentation Platform
25. AI Era LLM が、これまで⼈の⼿を必要とした作業を引き受けた SQL Python 分析 レポート コーディング 分析能⼒そのものが、⺠主化される 「分析できること」は、もう組織の差別化要因ではなくなる
26. データ組織がプロダクトになる
27. 分析が AI になると、データ組織は何を作るのか？ 問い 答え Data Product 分析がコモディティに なった世界で、 Search Semantic Layer Evaluation Knowledge Workflow Agent 組織は何を残せるのか
28. データ組織そのものが、プロダクトになる 今までは Organization ↓ Product これからは Organization = Product よい組織は、よいプロダクトと同じ性質を持つ 継続的に価値を届ける アクションに繋げる 改善され続ける レバレッジを⽣む
29. 社内も社外も同じ Product に Internal / External はない。あるのは Users だけ Employees Customers Partners AI Agents Users 優れたプロダクトは、届け先で品質を変えない
30. Conway's Law よい Data Product を作るには、組織そのものを設計しなければならない Organizations design systems that mirror their communication structures. だからこそ、これからの役割はこう変わるかもしれない Data Product Evaluation Knowledge Data Product Builder Engineer Architect Orchestrator
31. ⼈間は何をするの ?
32. ⼈は何をするのか？ AI Agent Human 問いを⽴てる 分析する 実装する 価値を設計する 没頭する "Find work that feels like play to you." — Naval Ravikant
33. Work is Fun とは、 仕事を楽しくすることではない ⼈が最も価値を発揮できる仕事に 集中すること
34. 闇にいるなら光を探せ！ 光がないなら、⾃分が輝け！ FUJI ROCK FESTIVAL'26, Hi-STANDARD
36. 闇にいるなら光を探せ！光がないなら、⾃分が輝け！ 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.
37. Making "Work is Fun" a reality
38. LT 1/13 クライアントの声を聞け Hiroyuki Moriya
39. 2020年以前: ⾊々やってました 2020年 ~ 2022年: DMM データサイエンス組織２⼈⽬にジョイン 2022年 ~ 2024年: Microsoft development MSN / Bingのソフトウェアエンジニアリング 森⾕ 浩幸 AI Engineer 2024年: 株式会社IVRy AIエンジニアとして、新規プロダクト⽴ち上げなど
40. プロダクトを作っても、使ってもらうのは難しい コーディングエージェントによって、 実装‧リリースの速度は改善された。 でも、買ってもらえる‧使ってもらえる‧喜んでもらえる プロダクトを作るのは難しい。
41. IVRyは、プロダクトを⼤きく外すことは少ない 電話‧FAX‧データエージェントなど、⼿広く開発に取り組んでき た。 どのプロダクトも、市場に受け⼊れてもらっている。 スタートアップにおけるプロダクト失敗率と⽐べると、 ⽐較的うまくいっている。
42. 「イシュー‧解決したい課題」が曖昧だと、 良いプロダクトを作れない
43. イシュー解像度が低いと、 曖昧なプロダクトを量産してしまう 新規プロダクト開発の難しさは、 「コーディング」ではなく、「ユーザーに刺さるか？」 イシューが曖昧だと、「ユーザーに刺さる」確率が低いままであ る。 打率が低いまま、打席に⽴ち続けても意味はない
44. クライアントの声を聞け
45. IVRyは、クライアントの声を聞きながら成⻑してきた たまたま作った電話プロダクトの反応が良かったのが始まり 有識者の 「電話なんて時代遅れでしょ」「すでに⼤企業が参⼊している」 という声ではなく 「クライアントが喜んでいる」「クライアントが継続して使ってい る」 という事実を⼤事にしてきた
46. 商談同席しろ
47. 商談同席すると、良いことがたくさんある クライアントの⼀次情報が⼿に⼊って、イシュー解像度が上がる プロダクトに対する期待値調整ができる 「これはできないんですよ」を直接喋れる セールスとの共通⾔語が⽣まれる セールスの⼈たちとの⼀体感が出て、飲み会で盛り上がれる
48. まとめ
49. エンジニアは商談に出て、イシュー解像度を上げろ 「エンジニアだから、商談に出ません」は⽢え。 コーディングはAIがやってくれるので、 エンジニアは別の形で付加価値を出すべき。
50. LT 2/13 AIエージェントとデータ基盤 〜分析基盤から⾏動基盤へ〜 Kazuki Inamura
51. 2017年: 株式会社サイバーエージェント エンタープライズ向けチャットボットエンジンの開発 2017年-2020年: 株式会社PKSHA Technology ⾃然⾔語処理を活⽤したエンタープライズ向け受託開発 2020-2024年: MNTSQ株式会社 契約業務⽀援のエンタープライズ特化AI SaaS開発 稲村 和樹 AI Engineer 2024年: 株式会社IVRy 通話履歴データの設定や分析への利活⽤機能を開発
52. 誰のためのデータ基盤？ - 従来：⼈間がデータ分析して意思決定する基盤 - ダッシュボードを⾒て、SQLを書いて、Notebook で分析して… - 今後：AI Agent が業務実⾏するための基盤 - Wiki を読む / SQLを書く / APIを呼ぶ / チケット起票する / 契約を更新する … => 業務のAI化にあたっては、業務⽂脈‧業務環境の整備が急務 - Context / Ontology Layer を各プラットフォーマーが統合 - どのようなテーブルがあるか（カタログ） Customerとは何か（業務上の意味/メタデータ） Contract と Customer はどう結び付くか（関係性） このAgentは何を実⾏してよいか（認可） 更新するならどのAPIを呼ぶか（Action）
53. https://www.palantir.com/explore/platforms/foundry/ontology/
54. https://openai.com/ja-JP/business/frontier/
55. https://www.aboutamazon.com/news/aws/aws-summit-nyc-2026-ai-agents
56. データプロダクトに関わる⼈の今後 - 従来：⼈間のデータ活⽤者の⽀援 - ETL / DWH 設計 / Dashboard 提供 … - 今後：AI Agent が安全に働ける職場環境の設計とその活⽤⽀援 - 業務要件の整理 / Business Ontologyを設計 / Metadata整備 / 認可設計 / Action API 提供 … - 基盤に対する Read から Write の⽐重が⾼まっていく - shared role から embedded role の⽐重が⾼まっていく データ基盤は 分析基盤 から ⾏動基盤 へと進化している流れにある
57. LT 3/13 IVRy Data Hub Agentの パフォーマンスを評価する Yuya Taguchi
58. 2017年: 株式会社朝⽇新聞社 ⾃然⾔語処理の研究開発に従事し、⽂章要約の研究や ⽂章校正SaaS「Typoless」の開発をリード 2026年: 株式会社IVRy IVRy Data Hubの評価基盤構築、要約ツールの開発を担当 ⽥⼝ 雄哉 AI Engineer
59. 評価は⼤事、でも難しい… • VOCの分析や応対品質の評価など、 そもそも"正解が存在しない"ユースケースが多い • そして出⼒の内容はユーザーのコミュニケーション データに⼤きく左右される
60. ではどうやるのか？ • 正解があるケースとないケースで分ける ◦ 正解がある：今週の問い合わせ件数は？ ◦ 正解がない：応対の改善施策を考えて • 正解があるケース：それをもとに正答率を確認する • 正解がないケース：LLM-as-a-Judgeを利⽤しつつ、 ⼈⼿のチェックも⾏う
61. 点ではなく線で評価する • ナイーブに「ユーザーの問い合わせ」と「出⼒結果」 だけでは評価ができない • Agentが呼び出したツールなどのTrajectory（軌跡） まで⾒ないと、最終結果の良し悪しを判定できない
62. LLM-as-a-Judgeをどこまで信⽤するか • 「⼊⼒‧Trajectory‧出⼒」をもとにJudgeをさせても結 果が⼀致しない ◦ 1回⽬：🤖「忠実性がいいが網羅性に問題あり」 ◦ 2回⽬：🤖「網羅性はあるが⼀部忠実ではない表現が…」 ◦ 3回⽬：以下略 • Agentの挙動もそもそも実⾏毎に微妙に異なるのに加え、 LLM-as-a-Judgeもブレがあり、Agent/Evalどちらも 出⼒を安定させるのが難しい
63. 評価はムズカシイ、だからこそやっていく • 「成功指標を定め、評価データを作成し、⼈⼿評価も しつつ改善」という流れはいつの時代も変わらず
64. LT 4/13 ソフトウェアエンジニアが 最低限すべきこと Yuki Gumizawa
65. 2019年: 株式会社Gunosy 広告CVR推定システム周りの開発や、ニュースアプリ のロジック開発に従事 2021年: ピクシブ株式会社 イラスト共有SNSのおすすめロジックの改善を担当 パーソナライズの導⼊などに従事 桾澤 優希 AI Engineer 2026年: 株式会社IVRy IVRy Data Hub の開発に従事
66. データチームには⾊々な⼈がいる
67. データチームには⾊々な⼈がいる 職種 (Role) 主な役割と業務 Data Engineer データ分析基盤の構築‧運⽤、データパイプラインの設計‧開発、 データの品質管理および最適化 Analytics Engineer 意思決定を⽀えるデータの集計‧分析、各種KPIの可視化ダッシュ ボード作成、ビジネス課題の抽出 AI Engineer LLMやAI Agent等を⽤いたプロダクト機能の設計‧開発、技術検証 （PoC）の推進および精度‧実⽤性の評価 Data Product Orchestrator 顧客業務の構造化とPoC設計を起点に、データ連携‧活⽤環境の実 装を推進し、成果と知⾒をテンプレ化してプロダクトに還元‧ス ケール Software Engineer プロダクトへのデータ機能の組み込み、データ活⽤を推進するアプ リケーションや機能の設計‧開発‧運⽤ 所属してる⼈の例
68. データチームには⾊々な⼈がいる 職種 (Role) 主な役割と業務 Data Engineer データ分析基盤の構築‧運⽤、データパイプラインの設計‧開発、 データの品質管理および最適化 Analytics Engineer 意思決定を⽀えるデータの集計‧分析、各種KPIの可視化ダッシュ ボード作成、ビジネス課題の抽出 AI Engineer LLMやAI Agent等を⽤いたプロダクト機能の設計‧開発、技術検証 （PoC）の推進および精度‧実⽤性の評価 Data Product Orchestrator 顧客業務の構造化とPoC設計を起点に、データ連携‧活⽤環境の実 装を推進し、成果と知⾒をテンプレ化してプロダクトに還元‧ス ケール Software Engineer プロダクトへのデータ機能の組み込み、データ活⽤を推進するアプ リケーションや機能の設計‧開発‧運⽤ 所属してる⼈の例
69. ⾃分しかいねぇ!
70. AIエンジニア (⼤嘘)
71. データチーム唯⼀のSWEがやっていること • IVRy Data Hub のバックエンドの開発 • IVRy Data Hub のフロントエンドの開発 • IVRy Data Hub ⽤エージェントハーネスの開発 etc...
72. 全部AIによってとって変わられそう
73. そうならないためにやりたいこと
74. コードリーディング
75. 雰囲気で書いたコードの中⾝を理解しないと • その後もずっと雰囲気でコードを書くしかなくなる • 負債が貯まる • ある時点でどうしようもないゴミが出来上がる • ⼿がつけられなくなる
76. ソフトウェアエンジニアとして • まだAI書いたコードについて⼈間が責任を持つ必要 がある • そうである以上Vibeで書かせたコードも全部⽬を通 そう
77. 責任持つ必要なくなったら仕事辞めます
78. LT 5/13 売上データを整備すると どうなる？ 知らんのか Yusuke Wada
79. 2013 年: ヤフー株式会社 2019 年: 株式会社メルカリ 2022 年: 株式会社estie 2024 年: 株式会社IVRy 和⽥ 悠佑 Analytics Engineer Engineering Manager データアナリストとして⼊社したけど、 アナリティクスエンジニアと 名前を変えて働いてます。
80. 結果的に古参（とはいえ来⽉で 3 年⽬）
81. 外向けには綺麗なこと⾔ってんだけど セマンティックレイヤーだの…… AI Ready だの…… ※ やってないわけではない
82. 「また売上データ（周り）の整備が始まる」 ⼊社してからずっと売上関連指標をメインに整備 （⼊社してすぐ） この沼から出れねぇ • 定義の標準化 • データ処理のパイプライン化‧⾃動化 範囲を拡⼤し続ける…… • 売上に対するコストのデータ整備 • ⼊⾦‧返⾦など会計的な観点の追加
83. データ職は組織の過去と向き合いがち……ツライ 当時の例外、みたいなものの調整が常に発⽣ AI によって過去の⾮構造データも価値を持ち始めている データの価値が⾼まるのは良いことである⼀⽅で ⼀⼈で抱え続けるには⾟いところもある ※ これすらも AI が解決してくれるのか……？
84. 皆でやっていきましょう！！ ありがたいことに IVRy はデータが組織として 拡⼤する⽅針がとれている 今⽇の なんだかわからない イベントに集まってくれる 同業の⽅も沢⼭いる 同業種としてツラミをいい感じに対処していきましょう！ 今⽇は楽しみましょう！
85. LT 6/13 セールスチームの⽣産性を 10xするために AI Opsチームがやっていること Yuta Yoshida
86. 2015年: 株式会社ブレインパッド データサイエンティストとして様々なドメインのデー タ分析‧機械学習システム構築PJに参画 2023年: 株式会社10X ネットスーパーのデータプロダクト開発に従事 吉⽥ 勇太 Analytics Engineer 2025年: 株式会社IVRy 営業活動⽣産性向上のためのAIツール/プロダクト開発
87. AI Opsチームとは • セールスチームの⽣産性向上を⽬指すチーム • セールスオペレーション改善を担当するBizメンバーとエンジニアがタッグを組む • 現場のペインをよく知るBizメンバーと、実装できるエンジニアが直接組んで、効 率化のアプリや仕組みを作って試して現場定着を⽬指す • 活動の軸は⼤きく ①社内ツール開発 と ②AI活⽤の社内浸透 の2つ エンジニアメンバー 合流 Sales Opsメンバー AI Opsチーム
88. 現代の業務効率改善、ムズすぎ問題。 • • • • DX今昔 ◦ 昔: 現実を機械に合わせる ◦ 今: ⼈間都合のニッチなワークフローにAIが柔軟に合わせてくれる ◦ どこまでを⾃動化して、どこからを運⽤でカバー（⼈間が責任をもつ）にする？ AIエージェント時代。⼈間を業務から外す？ ◦ ⼈間がボトルネックになるので業務フローに関与させないようにするという⽅向性 ◦ ⼈間を排除しすぎると別の問題がでてくる バイブコーディングの登場。どの抽象度で問題を解く？ ◦ 内製する？買ってくる？ ◦ SaaS的‧データプロダクト的な汎⽤ツールで解く？個別実装する？ 出来る現場の⼈は俺々業務効率アプリを作る。別チームが全体最適アプリを作る必要ある？
89. 結果: 作ったアプリは使われない • 理由 ◦ そもそも現場業務が忙しすぎて新しいアプリを使う余裕‧学ぶ余裕がない ▪ ◦ Gemレベルの単純なツールはよく使う 臨機応変な現場作業に対して、常に痒いところに⼿が届かない ▪ 型化した瞬間から、常に現実に劣後する感覚 ▪ ⾃分がやったほうが早い、に負ける ▪ AI Opsチームがつくった物より、俺々アプリの⽅が使える など
90. 今の境地（今後変わるかもだけど） • ⼈間が操作するアプリケーションを作らない ◦ 「業務に溶かす」状態 ◦ 例: SalesForceへの商談内容⾃動記⼊ ▪ 原則、⼈間の操作はなし。LLMが裏で全部記⼊。⼈間は商談するの み。 • インターフェースは馴染みのアプリだけで ◦ 例: 情報はSlackに通知 ◦ 例: データへの問い合わせはClaudeから ▪ Databricksにデータセットを作成し、MCPで呼び出す
91. もしかして「データを⽤意する」だけが仕事に？ • 実は「データ参照範囲が広いAIエージェント」で⼤体解決できるかも？ • セマンティックなデータテーブルを完備する • ◦ このときにドメイン知識もたくさん必要になる ◦ それをClaudeが読みに来る体制を整える ◦ いつか、AIエージェントがデータをエンリッチメントするようにもなりそう やることは、データエンジニア的な領域になるかなぁ ◦ データの拡充 ◦ 権限管理（誰が、どのデータにアクセスしていいか‧ダメか） ▪ 社⻑が⾒れるデータと、⼀般社員が⾒れるデータは違う ◦ AI挙動のモニタリング‧コスト管理 ◦ 利⽤者（⼈間）とAIの橋渡しをする役⽬
92. LT 7/13 僕たちは失職するために仕事している Ryosuke Noaki
93. 2020年: 株式会社エウレカ BIエンジニアとして、pairsのプロダクト改善を⽬的としたデー タ分析業務、A/Bテスト設計、KPI設計、ダッシュボード構築、 などを担当。 2025年: 株式会社IVRy 野秋 良介 Analytics Engineer 分析基盤の整備や、データ活⽤を⽀えるテーブル設計‧運⽤と いったデータイネーブルメントを担当。
94.  Data Product データプロダクトを作って稼ぐ  Data Enablement 事業の状況を把握‧分析  AI Ops AIで社内業務の効率化   Data Infra データを集めて、利⽤可能に
95. イネーブルメント活動のゴールは ⾃分の消滅
96. チームトポロジーが⽰す「イネーブルメント」 チームトポロジーによると イネーブルメントチームとは、 他チームが”⾃⼒でできる”ようにする存在 恒久的な依存先になった時点で、それは失敗である。 ⽀援先が⾃⽴する = ⾃分の必要がなくなる
97. わたしのおしごと ビジネス指標の 定義を すり合わせる 共通データソー ス基盤を整える データ⼊⼒‧品 質を標準化する ドキュメント化 して脱属⼈化 する
98. おしごとが完了すると...？ ビジネス指標の 定義を すり合わせる データ⼊⼒‧品 質を標準化する ドキュメント化 して脱属⼈化 する ▶ もう聞かなくていい ▶ 経由しなくていい ▶ 直さなくていい ▶ いなくても回る 共通データソー ス基盤を整える
99. おしごとが完了すると...？ “⾃分への依存を消す”作業 ビジネス指標の 定義を すり合わせる データ⼊⼒‧品 質を標準化する ドキュメント化 して脱属⼈化 する ▶ もう聞かなくていい ▶ 経由しなくていい ▶ 直さなくていい ▶ いなくても回る 共通データソー ス基盤を整える
100. やり切った瞬間、この4つの仕事は消える 「的確な意思決定を最速で⾏える環境を作る」のが⽣存価値 (くそでかコストセンターであり、会社の中でProfitを⽣み続ける意味づけをし続けければレイオフされる) ＝ 失職するために仕事している
101. 失職を恐れて環境整備の⼿を抜けば、じわじわ⽴場を失う。 ⾃ら失職しにいく奴だけが、次の椅⼦に座り直せる。
102. 泥臭い仕事や⽣存戦略を考え続けるツラみについて 共感してくださる⽅はぜひ、お話しましょう！
103. LT 8/13 ⼊社1ヶ⽉からみたIVRyの組織⾵⼟： 期待値と実体験の統合的分析 Kazuya Ozawa
104. 免責事項 権利および⾒解の帰属 • 本発表におけるすべての発⾔‧記述は発表者個⼈の⾒解であり、所属企業の公式解 釈を⽰すものではありません。 ⾮保証事項 • 内容の正確性‧完全性‧有⽤性について⼀切保証いたしません。本情報の利⽤によ り⽣じた損害について発表者は責任を負いかねます。 演出に関する謝罪 • 本発表における過度に厳格な演出は、「前後のカジュアルなLTとの⽐較が、⾯⽩い のではないか」という当社内の定例協議（いわゆる「内輪ノリ」）に基づき企画‧ 実施されたものです。 • ご聴講の皆様におかれましては、甚だ⾒苦しい演出となりましたことを切にお詫び 申し上げます。
105. 2015年: 株式会社データフォーシーズ 分析コンサルタントとして、 ⼤⼿通信会社の多数の分析プロジェクトに従事。 2023年: 株式会社AbemaTV データアナリスト/エンジニアとして、データ分析、 データ基盤運⽤、セルフ分析環境の構築‧推進。 ⼩澤 和也 Analytics Engineer 2026年: 株式会社IVRy 7⽉にアナリティクスエンジニアとして⼊社。 IVRy Data Hubの成⻑のためのデータ活⽤を担当。
106. 本発表の構成 本発表は、発表者のIVRy⼊社前の事前イメージによる期待値から、 ⼊社後の実体験‧実態調査に基づく印象の変化を整理し、 当社を認知していない層へ忖度のない実態を開⽰することを⽬的とする。 1. ⼊社前における期待値 2. ⼊社後における実態調査結果 3. 総括
107. ⼊社前における期待値 組織⾵⼟： ⼊社障壁に対する警戒感 • 公開情報より、過度に洗練された排他的⽂化 ◦ 独⾃のVision 「Making "Work is Fun" a reality. 」 ◦ オフィスのボルダリング壁および⼊社後のレゴ配布のような特徴的な雰囲気 組織状態：急成⻑に伴う構造的混乱 • 急激な事業拡⼤フェーズ特有の「⾮効率的かつキャッチアップ困 難な混沌状態」への懸念
108. ⼊社後における実態調査結果 組織⾵⼟：Vision主導の合理的カルチャー • Visionは、「顧客の仕事を良くする」「熱中して成果を出す」と いった姿勢を内包 • 特徴的な演出は、Vision体現に合理的であることを確認 組織状態：⾃律統制機能を持つ「健全な混沌」 • 事業‧組織拡⼤に伴う過渡的混沌は認められる • 徹底された情報公開性（Notion/Slack等）と各社員の⾃発的な 改善的⾏動により、⾃律統制機能が作動
109. 総括 ⼊社前のIVRyへの印象は誤認であり、実際には極めて⽣産的かつ先進的な環境であるこ とが実証された。 入社前における 期待値 入社後における 実態調査結果 組織⾵⼟ 過度に洗練された 入社障壁の高い新興企業 深い企業ミッションと それを支える合理的な施策 組織状態 急速な事業成長に伴う、 非効率的・追従困難な混沌 一定の混沌を伴いつつ、 自律統制機能を有する
110. 本発表に関する公表⽂献 本発表で取り扱った題材につきまして、以下の公表⽂献(note)でも取り扱って おります。 • 【⼊社エントリ】「Work is Fun」を語る敷居が⾼そうな会社につい勢 いで⼊社した結果
111. LT 9/13 経理も採⽤もプロダクトも 全データ突っ込んで 権限整理したるでー George - Yuji Yamamoto
112. 4社⾊々 セールス LINE 事業企画、マーケティング 楽天 データエンジニア アンドパッド 経営企画 ⼭本 雄⼠ Data Engineer IVRy データエンジニア
113. まず、全部突っ込みました 経理‧財務 • 会計ソフトの仕訳 • 経費精算 採⽤‧⼈事 プロダクト • ATS（選考データ） • サービスDB • 組織マスター • ⾏動ログ • エンゲージメントサーベイ • 決済 ただ、「⾒えてはいけないもの」も 1 か所に集まりました。
114. 「⼈事データ」は、⼀枚岩じゃない 社内オープン 秘匿 組織マスター 採⽤結果 誰がどの部署にいるかは、 採⽤システムの選考評価。 全社に公開されている 個⼈情報の観点から採⽤関係者のみに絞る 「⼈事データを⾒られる⼈」では定義できない
115. 異動は、ヤバい ⼊社 付ける ✓ — 退職 — 剥がす ✓ 異動 付ける ✓ 剥がす ？ ⾜すのはみんなやる。剥がすのは、忘れる。
116. やってること 最⼩権限で切る 職能や役職ではなく、データの属性で縛る 申請と付与を、記録に残す Slackとterraform。誰が‧いつ‧何に対して、が後から追える 定期的に棚卸す ⾃動化は道半ば。⼿も動かしています 「記録の残らない権限付与はしない」ここだけは死守
117. で、いちばん権限を持ってるのは僕なんですけど 基盤を作った⼈間は、構造上ぜんぶ⾒えてしまう ⾃分で⾃分を縛るのは、正直むずかしい Databricks で、ロールの assume ができるようになった 常時フルアクセスをやめて、必要なときだけ切り替える
118. きつくすれば、じゃま。 ゆるくすれば、こわい。 その間を、ずっと調整していく仕事。 ⼈に残された仕事、権限付与。
119. LT 10/13 え、データエンジニアが 商談に出るんですって！？ Kenji Matsuda
120. 2014年: ヤフー株式会社 新卒⼊社し、広告配信システムのDMP開発に従事 2016年: 株式会社カケハシ 薬局向けSaaSのスタートアップに6⼈⽬として参画 松⽥ 健司 Data Engineer 2025年: 株式会社IVRy データ基盤の構築やIVRy Data Hubの開発に従事
121. 社内のデータ基盤を作りつつ、商談にも出ます。
122. お客様の声を、直接聞ける。 だから、意味のある開発ができる。
123. 温度感がわかる
124. でも、⾔われたまま作らない。 御⽤聞きでもない。 押し付けでもない。
125. リアルタイムなんていらなかった
126. カスタマイズして、売らない。 その場限りの開発はやらない。
127. 会社の資産にならない
128. 要望を蒸留して、 プロダクトに還元する。
129. 1社の声が積み重なり、プロダクトが複利で育つ
130. 声を直接聞き、蒸留し、還元する。 それが、商談に出るデータエンジニアの⾯⽩さ。
131. ぜひデータエンジニア あるある話しましょう！
132. LT 11/13 それで、Agentic Search って 何なのよ Kazuaki Hiraga
133. Infoseek Japan (楽天) / FAST (Microsoft) / Basis Technology など Web 検索、ニュースアグリゲーション‧検索、NLP関連など ソフトウェア‧エンジニア∕シニア‧ソフトウェア‧エンジニア 2012年: 楽天株式会社 新検索基盤開発のシニア‧ソフトウェア‧エンジニア 2019年: 株式会社メルカリ 新検索基盤開発のシニア‧ソフトウェア‧エンジニア その後、検索チームのTL/EM 平賀 ⼀昭 Principal Search Engineer 2023年: クーガー株式会社 AI（NLP/CV）チームのTL/EM 2026年: 株式会社IVRy 検索基盤開発に従事
134. Agentic Search って何なのよ RAG と何が違うの？ AI 検索と何が違うの？
135. なぜ検索が必要なのか？ 最新情報‧社内情報‧正確な根拠 を得るために検索が必要 なぜなら Knowledge Cutoff 最新情報は知らない Grounding 根拠‧社内情報‧⼀次情報が必要 ↓ Hallucination
136. RAG とは違うの？ RAG 検索して答える Agentic Search RAG Agentic Search 質問 ↓ 検索 ↓ 回答 ゴール ↓ 計画 ↓ 検索 / Tool Use ↕ Reflection ↓ 回答 ⽬的を達成するために検索を使う ※ ※広く共有された明確な定義がまだないため、ここではこのように定義しています
137. 検索は？ 20年前は⼈が検索ボックスにキーワードを⼊⼒して いました RAG では LLM が検索するようになりました Agentic Search では、AI が⽬的を理解し必要に応 じて検索を⾏うようになります
138. つまり検索は？ Knowledge Cutoff がある限り Grounding が必要な限り 必須 ただし 検索の主役は⼈からAIへ
139. Agentic Search とは？ 良い検索ができなければ良い Grounding はできない 良い Grounding ができなければ良い Agent も作れない Agentic Search は検索を置き換える技術ではなく 検索の価値をさらに⾼める技術
140. LT 12/13 AI時代の “オーケストレーター” という役割 Sorami Shiromizu
141. 1989年⽣まれ 2012: 奈良先端科学技術⼤学院⼤学（NAIST） ⾃然⾔語処理の基礎研究 2014: ブレインパッド データサイエンティスト 2017: ワークス徳島⼈⼯知能NLP研究所 研究開発, 形態素解析器Sudachi 2020/2026: Legalscape 法律領域でのデータ整備‧RAG開発 ⽩⽔ 空海 Data Product Orchestrator 2022: MIERUNE 位置情報‧地図‧データ可視化 2026: IVRy Data Product Orchestrator
142. Hello World !
143. 🍼
145. 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
147. 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
149. 出典: ⼈事院ホームページ, ウィキメディア‧コモンズ / CC BY 4.0 https://commons.wikimedia.org/wiki/File:Keizo_Obuchi_cropped_Keizo_Obuchi_19890107.jpg
150. 出典: 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
151. 36 年 1989 → 2026
152. パソコン パソコン パソコン パソコン パソコン パソコン パ インターネット インターネット インターネット インター モバイル モバイル モバイル モバイル モバイル モバイル モ パソコン パソコン パソコン パソコン パソコン パソコン パ インターネット インターネット インターネット インター モバイル モバイル モバイル モバイル モバイル モバイル モ パソコン パソコン パソコン パソコン パソコン パソコン パ インターネット インターネット インターネット インター モバイル モバイル モバイル モバイル モバイル モバイル モ パソコン パソコン パソコン パソコン パソコン パソコン パ インターネット インターネット インターネット インター モバイル モバイル モバイル モバイル モバイル モバイル モ
154. スパコン性能の進歩 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年は前⾝版
155. スパコン性能の進歩 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年は前⾝版
157. 6倍 20.2兆ドル → 121.6兆ドル
158. 🏦
159. 出典：Wikimedia Commons, Nordean historia-arkisto, ELKA, パブリックドメイン https://en.wikipedia.org/wiki/File:Pohjoismaiden_Osakepankin_Helsingin_sivukonttori.jpg
161. 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
162. … しかし 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
163. 技術、 だけでは ⾜りない
164. 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
165. ❌ いまの業務をAIで効率化する ✅ AI前提で業務を作り直す
166. そのためには ... 技術と業務を深く理解した上で、 全体を俯瞰して構成する
167. オーケストレーターとは ... エンジニア、セールス、経営、 そしてお客さんといった、 ⽴場も専⾨も違う⼈たちのあいだに⽴ち、 業務のつくり直しから、プロダクト開発、 そして世の中へ広く届けるところまでをつなぐ役割
168. 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
169. ⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕⽕ ⽂字 ⽂字 ⽂字 ⽂字 ⽂字 ⽂字 ⽂字 ⽂字 活版印刷 活版印刷 活版印刷 活版印刷 活 科学 科学 科学 科学 科学 科学 科学 科学 鉄道 鉄道 鉄道 鉄道 鉄道 鉄道 鉄道 鉄道 コンピューター コンピューター コンピ インターネット インターネット インタ
172. 、 前まで 年 0 20 どもが ほんの ⼦ の た 1⼈ んでい 2⼈に 死 に の前 思春期 それが 19 50年に は 27%、 2020年 には4. 3%まで 低下し た
173. 🍼
174. https://ivry.jp/company/vmv/
175. LT 13/13 社⻑⾯談で号泣して ⼊社を決めました Rio Kurihara
176. 2016年: 株式会社ブレインパッド 様々なドメインのデータ分析‧機械学習 PJ に従事 クライアントワークと開発の両輪 2023年: 株式会社メルカリ メルペイ与信モデルの開発‧保守運⽤ Tech Lead / PjM 栗原 理央 Data Product Orchestrator 2026年: 株式会社IVRy Data Product Orchestrator
177. ⼊社の経緯から⼊社後までを 3分で駆け抜けます
178. 社会⼈10年⽬を⽬前にしたアラサーの苦悩 がむしゃらだった10年 「⾃分はこれまでに何かを成し得てきただろうか」 「このままでいいのか」 という漠然とした不安に駆られる⽇々
179. アルムナイでの出会い 吉⽥ 勇太 Analytics Engineer
180. 爆速の選考 ⼀次⾯接からオファーまで5営業⽇
181. 決め⼿となった会⾷ ⼤曽根さん 吉⽥さん 稲村さん 花⽊さん Chief Data Officer Analytics Engineer AI Engineer Principal AI Engineer
182. 決め⼿となった会⾷ ⼤曽根さん 吉⽥さん 稲村さん 花⽊さん
183. 環境を変えることが怖かった 背中を押してほしかった
184. 奥⻄さん（代表取締役/CEO）と15分の⾯談 漠然とした不安をそのままぶちまけた
185. 奥⻄さんと15分の⾯談 漠然とした不安をそのままぶちまけた 成功体験がない。 どこにいってもうまくいかないのでは ... 自分の課題は何か？ どこにどう向かえばいいのかわからない 二人育児とスタートアップは 両立できるのか ...
186. 奥⻄さんと15分の⾯談 成功してきた人は自分の勝ちパターンを 知っているから、最初の半年はそれを使って成 果を出せる 代表取締役 / CEO 奥⻄さん
187. 奥⻄さんと15分の⾯談 成功してきた人は自分の勝ちパターンを 知っているから、最初の半年はそれを使って成 果を出せる 代表取締役 / CEO 奥⻄さん でも、そのあとは 頭打ちすることが多い
188. 奥⻄さんと15分の⾯談 一方、成功体験が少ない人は 成功するためにたくさん試行錯誤をして、 いろんな引き出しを開けてきているはず。 代表取締役 / CEO 奥⻄さん
189. 奥⻄さんと15分の⾯談 一方、成功体験が少ない人は 成功するためにたくさん試行錯誤をして、 いろんな引き出しを開けてきているはず。 代表取締役 / CEO 奥⻄さん そうしてきたでしょ？
190. https://note.com/kai_yon/n/nd8ad8f4fff89
191. ⼊社理由‧⼊社してみてどうか （真⾯⽬ ver.） @懇親会
192. Closing Keisuke Osone
193. データチーム 積極採⽤中です！ 募集中のデータ系ポジション、 カジュ⾯リンク、 参考情報等は すべてこちらのページに あります！ https://ivry.jp/lp-article/data-team/