Slide 1

Slide 1 text

使えるデータ基盤を作る 技術選定の秘訣 【技術選定を突き詰める】Online Conferenc e 2025 近森 淳平(チカモリ ジュンペイ) @pei0804

Slide 2

Slide 2 text

データ界隈、 どんどん新しい技術(ツール)出てくる。

Slide 3

Slide 3 text

その中から、本当に必要だったものを 見つけ出す考えを共有します。

Slide 4

Slide 4 text

「データ基盤がなかなか活用されない。 どうしたらいいいですか?」

Slide 5

Slide 5 text

「ツール導入したんですが、使われません。 どうしたらいいですか?」

Slide 6

Slide 6 text

この質問、本当に何回も聞きました。

Slide 7

Slide 7 text

話を聞いていると、 「便利そう」で導入している。 これは失敗する。

Slide 8

Slide 8 text

よくありがちな罠として、 管理者視点で便利そうは流行らない。

Slide 9

Slide 9 text

課題を解決してないツール導入 ①モダンなBI入れました! みんな使ってね!! ③また、スプシでやってる!! BI使ってよ!!  ②このグラフ、データないのか スプシでやろ・・・ 管理者 利用者

Slide 10

Slide 10 text

高度な技術を導入するだけでは、 ラストワンマイルを解決している 表計算ソフトに負ける。

Slide 11

Slide 11 text

本当の痛みを解決すれば、人は動く ①このレポート、数時間かけてると 思いますが、3秒で出来ます。 管理者 利用者 ②それは、すごすぎ!!! どうやってやるの教えて!! ③こういうツールがありまして・・・ ④これはすごい! これから、これでやろ。

Slide 12

Slide 12 text

実際にデータを使って価値を出す人たちが 欲しいものを技術選定をしよう。

Slide 13

Slide 13 text

アジェンダ ● 自己紹介 ● データ基盤の価値 ● 大局を知る ● ツール選定の勘所 ● CARTA MARKETING FIRMのツール選定 ● 事業をデータエンジニアリングする

Slide 14

Slide 14 text

アジェンダ ● 自己紹介 ● データ基盤の価値 ● 大局を知る ● ツール選定の勘所 ● CARTA MARKETING FIRMのツール選定 ● 事業をデータエンジニアリングする

Slide 15

Slide 15 text

自己紹介 ぺい @pei0804 近森淳平(チカモリ ジュンペイ) VP of Data @ CARTA MARKETING FIRM / CARTA HOLDINGS 2024, 2025 Snowflake Data Superheroes

Slide 16

Slide 16 text

アジェンダ ● 自己紹介 ● データ基盤の価値 ● 大局を知る ● ツール選定の勘所 ● CARTA MARKETING FIRMのツール選定 ● 事業をデータエンジニアリングする

Slide 17

Slide 17 text

今回の技術選定の対象である データ基盤の価値とは何か。

Slide 18

Slide 18 text

事業にとってデータ基盤は何か。

Slide 19

Slide 19 text

1日止まると、どれくらい困る? 翌日に復旧していれば問題ない?

Slide 20

Slide 20 text

実はデータ基盤がなくても、 事業は継続できたりしませんか? (悪いことではない)

Slide 21

Slide 21 text

データ基盤は事業の必須条件ではなく付加価値 データ基盤は事業の必須条件ではなく付加価値なケースが多いです。 特に歴史ある事業は、データ基盤がない、手軽ではない時代から データ基盤なしでも成功を収めてきました。 そのためデータ基盤はなくても事業が回る存在と認識されやすいのです。 実際に収益を生む業務システムと比較すると、 「本当に必要なのか?」という疑念を持たれやすい性質があります。

Slide 22

Slide 22 text

事業に不可欠な存在へと変えるには、 戦略的な活用が必須となります。

Slide 23

Slide 23 text

場当たり的に取り組むだけでは、 「本当に必要なのか?」と疑問視されやすい。 それがデータ基盤。 ここを出発点に、技術選定を考えていきます。

Slide 24

Slide 24 text

では、どのような状態であれば データ基盤に価値があるのでしょうか?

Slide 25

Slide 25 text

日々使われていること。 これが何よりも重要です。

Slide 26

Slide 26 text

もちろんデータ基盤管理者ではなく、 データ基盤の利用者にです。

Slide 27

Slide 27 text

「データ基盤がなかなか活用されない。 どうしたらいいいですか?」

Slide 28

Slide 28 text

これまで事業に存在していなかったものを 新たに活用してもらうことは 容易ではありません。

Slide 29

Slide 29 text

データ基盤が使われている状態を作るとは、 人の営みを変えるということ。

Slide 30

Slide 30 text

「便利そう」だと弱い。 明確に「使える」ストーリーが必要。

Slide 31

Slide 31 text

「使える」ストーリーを作れる技術を 選定し導入する。

Slide 32

Slide 32 text

アジェンダ ● 自己紹介 ● データ基盤の価値 ● 大局を知る ● ツール選定の勘所 ● CARTA MARKETING FIRMのツール選定 ● 事業をデータエンジニアリングする

Slide 33

Slide 33 text

技術選定をする前に、大局を知る。

Slide 34

Slide 34 text

データ基盤を取り巻く環境

Slide 35

Slide 35 text

モダンデータスタックの登場により、 データ基盤構築の民主化が進み 専門知識がなくても構築可能に

Slide 36

Slide 36 text

https://notion.castordoc.com/modern-data-stack-guide

Slide 37

Slide 37 text

今日の技術選定の対象は、 このツールたちです。 もはや、これらを使わない手はない。

Slide 38

Slide 38 text

多くの技術問題は、ツールで解決できる。

Slide 39

Slide 39 text

以前は数ヶ月かかっていたことが、 現在では1日で完了する。

Slide 40

Slide 40 text

ツールが使えるなら、 絶対に使った方が良い。

Slide 41

Slide 41 text

なぜツールを使った方がいいか。

Slide 42

Slide 42 text

すぐに使えることは価値 1からフルスクラッチで作った仕組みで取り込んだデータも、 ツールを使って取り込んだデータも、得られる結果に違いはないです。 異なるのはデータにアクセスできるまでの時間です。 データ使いたい人にとっては、早く使える方が良いのです。 データ閲覧に時間がかかるようでは、誰も使わなくなってしまいます。

Slide 43

Slide 43 text

ツールを通して、集合知へアクセスできる ツールという共通言語を通じて集合知にアクセスできます。 例えば、dbtを使うことで、これまでデータウェアハウスごとに 分断されていた知識が集合知とになっています。 逆にフルスクラッチでデータパイプラインを作ると、 独自事情が多くなり、集合知へのアクセスが難しくなります。

Slide 44

Slide 44 text

ツールに合わせる利点 一定の評価を得ているツールには、 洗練されたプラクティスが備わっています。 ツールに業務を合わせることで、より良い管理手法を採用できます。 このアプローチは業界の集合知を活用する戦略的選択であり、 長期的な保守性向上と将来の選択肢確保につながります。 反対に事業の特殊要件にこだわりすぎると、 カスタマイズ機能に縛られてベンダーロックインのリスクがあります。

Slide 45

Slide 45 text

再掲 ツールが使えるなら、 絶対に使った方が良い。

Slide 46

Slide 46 text

ロックイン怖くない?

Slide 47

Slide 47 text

時間をかけすぎて、 旬が過ぎる方が怖い。

Slide 48

Slide 48 text

「試したい!」熱がある時に、 すぐ試せる方がいい。

Slide 49

Slide 49 text

なぜか?

Slide 50

Slide 50 text

高度な技術や優秀な人材を集めただけでは、 データ活用の成功確率は必ずしも上がりません。

Slide 51

Slide 51 text

基本的に失敗する。 本当に。

Slide 52

Slide 52 text

たくさん失敗して、たまに成功する。 それがデータ活用。

Slide 53

Slide 53 text

なら、たくさん試して、 たくさん失敗した方が良い。

Slide 54

Slide 54 text

試す前の段階で大変だったら、 絶対にうまくいかない。

Slide 55

Slide 55 text

ツールに乗っかれるとこは乗っかって、 さっさと試せるようにする。

Slide 56

Slide 56 text

たくさん試せされると、 「使える」ストーリーは自ずと増える。

Slide 57

Slide 57 text

これが「使える」ストーリーを作る 最速の方法

Slide 58

Slide 58 text

再掲 ツールが使えるなら、 絶対に使った方が良い。

Slide 59

Slide 59 text

アジェンダ ● 自己紹介 ● データ基盤の価値 ● 大局を知る ● ツール選定の勘所 ● CARTA MARKETING FIRMのツール選定 ● 事業をデータエンジニアリングする

Slide 60

Slide 60 text

https://notion.castordoc.com/modern-data-stack-guide

Slide 61

Slide 61 text

ツール選定は、どこから始めるか

Slide 62

Slide 62 text

解く課題を明確にする ツール選定を始める前にやるべきは、解決すべき課題の明確化です。 課題がないところにツールを導入しても使われないです。 誰のどのような課題を解決するのか、 これをはっきりさせることが大切です。

Slide 63

Slide 63 text

課題がどこにあるか分からない? 身の回りの人たちのスプレッドシート(以下スプシ)を見れば、 データに関する課題、ニーズは可視化されています。 ● ビジネス上重要だけど、スプシしか置き場のないデータ。 ● サイロ発生している箇所を、繋げるガムテープスプシ。 いきなりAI活用とかしなくても、身近なところにニーズはあります。

Slide 64

Slide 64 text

課題のカテゴリを特定する 課題がどのカテゴリのものかを特定しましょう。 ● データ取り込み ● データウェアハウス ● データ変換 ● データ可視化・分析 ● オーケストレーション ● データガバナンス ● データオブザーバビリティ ● etc…

Slide 65

Slide 65 text

カテゴリを絞り込んでも、 たくさん候補がある...。

Slide 66

Slide 66 text

まず、1つのツールを一旦試す ツールの多くは簡単に試すことができます。 SaaSなら一般的にトライアル期間が用意されていますし、 OSSであればすぐに試すことが可能です。 具体的な課題解決方法が見えなくても、 長時間の調査よりもまず実際に試してみる方が効果的です。 実際に使うことで課題がより明確になり、 必要な機能も見えてくることが少なくありません。

Slide 67

Slide 67 text

同じカテゴリで、3つ試す 可能であれば、同一カテゴリのツールを3つ試すことをお勧めします。 3つほど検証すると、カテゴリ内の共通の機能と 各ツール固有の強みが見えてきます。 それぞれの特色を自組織の課題と照らし合わせることで、 より適切な選択ができ、失敗を避けられます。

Slide 68

Slide 68 text

導入判断する前に見るポイント 1. 圧倒的に仕事を変える力があるか 2. 学習コスト 3. 公式ドキュメントの充実度 4. サポート体制の良し悪し 5. コミュニティの活発度 6. 課金モデルと組織体制の相性 7. ロードマップへの共感度 8. セキュリティ体制 9. 撤退シナリオ

Slide 69

Slide 69 text

圧倒的に仕事を変える力があるか ツール選定で最重要なのは、圧倒的に仕事を変えられるかどうかです。 「ちょっと便利」程度のツールは、導入・運用コストが便利を上回り、 組織の生産性を低下させます。 特に多くの利用者を想定する場合、前の方法が馬鹿らしくなるほどの 圧倒的な価値提供が不可欠です。 価値あるツールとは、「使わないと損」と実感できるものです。 この基準を満たさないツールは、導入しない方がマシです。

Slide 70

Slide 70 text

学習コスト すごく高機能だが、学習コストが高いツールを、 基盤利用者に学習してもらうことは非現実的。 「勉強すれば分かる」が通用するのは、 基盤チームだけが利用するケースに限ると捉えた方が良い。 基盤チームだけが使うものなら、Simpleな小回りが効くもの。 基盤利用者がメインで使うものなら、Eazyに扱えるもの。

Slide 71

Slide 71 text

公式ドキュメントの充実度 公式ドキュメントの充実度は、 基盤利用者の体験と運用負荷に直結します。 ドキュメントが基盤チームの代わりに説明をできる状態に なっていれば、サポート負荷は大幅に軽減されます。 逆にドキュメントが不十分だと、 基盤利用者からの問い合わせが増え、業務負担が増大します。

Slide 72

Slide 72 text

サポート体制の良し悪し SaaSを使う場合、これは絶対に確認すべきポイント。 事前のトライアルでコミュニケーションを重ねて見極めます。 個人的には「分かってる」と感じる回数が重要な判断材料になります。 トライアル中に感じた違和感は、導入後も同様に発生しますので、 無視せずに考慮すべきです。 周りに先行ユーザーがいれば、 サポートの質について聞いておくことも有益です。

Slide 73

Slide 73 text

コミュニティの活発度 コミュニティは公式サポートとは質的に異なる価値を提供します。 具体的には、導入後の運用・活用の話は、 コミュニティだからこそカバーされる領域です。 私はSnowflakeのSnowVillageに参加しています。 ここには多様な業界や役割のメンバーが集まっています。 自組織だけで気づかなかった視点や創造的な解決策に 出会える貴重な機会となっています。 https://usergroups.snowflake.com/snowvillage/

Slide 74

Slide 74 text

課金モデルと組織体制の相性 SaaSなら、料金体系が業務や組織構造と合致するかを確認しましょう。 例えば、課金に影響する変数が利用者数の場合、 現在と潜在的な利用者も見積もりに含めることが重要です。 ツールの活用が進んでいくと高くてやってられないとかだと、 活用レベルにアッパーができてしまうからです。 活用が罰則的な費用増加につながらないのが理想的です。

Slide 75

Slide 75 text

ロードマップへの共感度 将来的な方向性と自組織の戦略的ニーズの一致度を評価します。 短期間の一致よりも、中長期的な方向性の合致が重要です。 また、ロードマップがどのように決定されているか、 過去のロードマップと現在の達成度を確認することも有効です。 現状のみで評価しすぎると、 翌年には不要なツールになってしまう可能性があります。

Slide 76

Slide 76 text

セキュリティ体制 SaaSで機密データを扱う場合、重要な観点です。 SOCやISMSなどのセキュリティ認証があれば理想的です。 認証取得がない場合は、社内基準への適合性も確認が必要になります。 セキュリティ要件は選定の足切りとして使いやすい要素です。 選定が難しい場合は、セキュリティ要件から決めるのがおすすめです。

Slide 77

Slide 77 text

撤退シナリオ ツールからの撤退については、導入前から考えておくべきです。 特にデータ基盤利用者が主に使用するツールは、 様々な業務と紐づいて切替えの負担が大きいため、 どうすれば撤退可能になるかは検討すべきです。 撤退が現実的でない場合は、将来性、解決課題の重要性。 SaaSの場合は収益性などを、総合的に評価しましょう。

Slide 78

Slide 78 text

撤退可能な責任範囲を定義する 撤退可能にする過程で、ツールの責任範囲が自然と明確にできます。 広範囲な業務を任せすぎると撤退が困難になります。 「このツールにはここを任せる」「ここは任せない」線引きが重要です。 ツールの役割と責任範囲を明確にすることで、 過度な依存を避け、事業の独立性を保ちます。 この適切な責任境界設定こそが、 将来の技術選択の自由度を確保する重要な戦略になります。

Slide 79

Slide 79 text

いい感じのツール見つけたら、 あとはいい感じに・・・。

Slide 80

Slide 80 text

ならない!

Slide 81

Slide 81 text

導入してからが本番

Slide 82

Slide 82 text

「XXXっていうサービス導入しました!」

Slide 83

Slide 83 text

数カ月後、誰も利用してない。

Slide 84

Slide 84 text

ツールを置くだけでは、誰も使わない。

Slide 85

Slide 85 text

オンボーディングしよう。

Slide 86

Slide 86 text

ツールのオンボーディング 利用を想定していた人たちは、恐らくすぐに使ってくれるでしょう。 潜在的な利用者はこちらからアプローチが必須になります。 ● 社内向けのドキュメントの整備(必要に応じて) ● 具体の課題を解決する支援 これは泥臭くやってくしかない部分なので頑張りましょう。

Slide 87

Slide 87 text

アジェンダ ● 自己紹介 ● データ基盤の価値 ● 大局を知る ● ツール選定の勘所 ● CARTA MARKETING FIRMのツール選定 ● 事業をデータエンジニアリングする

Slide 88

Slide 88 text

CARTA MARKETING FIRMの ツール選定

Slide 89

Slide 89 text

https://findy-tools.io/companies/cartamarketingfirm/145/36

Slide 90

Slide 90 text

https://findy-tools.io/companies/cartamarketingfirm/145/36

Slide 91

Slide 91 text

2年くらい大きく変化がない。

Slide 92

Slide 92 text

じゃあ、何してるの?

Slide 93

Slide 93 text

https://findy-tools.io/companies/cartamarketingfirm/145/36

Slide 94

Slide 94 text

事業をデータエンジニアリングしている。

Slide 95

Slide 95 text

アジェンダ ● 自己紹介 ● データ基盤の価値 ● 大局を知る ● ツール選定の勘所 ● CARTA MARKETING FIRMのツール選定 ● 事業をデータエンジニアリングする

Slide 96

Slide 96 text

ツールを使われ始めても、 別の課題が出てくる。

Slide 97

Slide 97 text

https://www.getdbt.com/resources/reports/state-of-analytics-engineering-2024

Slide 98

Slide 98 text

https://www.getdbt.com/resources/reports/state-of-analytics-engineering-2024

Slide 99

Slide 99 text

https://speakerdeck.com/pei0804/data-engineering-for-business?slide=44

Slide 100

Slide 100 text

データ基盤を事業に活用したいという取り組みは、 多くの場合「データドリブン経営」を目指す動きです。 しかし、この実現はツール導入だけでは達成できない課題です。 データドリブン経営は理念として語るのは容易ですが、 実現にはツールだけでは解けない課題解決が必要となります。 ツール導入はあくまでも第一歩に過ぎず、組織文化の変革や人材育成、 データリテラシーの向上など、より広範な取り組みを必要とします ツール導入後の真の課題

Slide 101

Slide 101 text

https://www.heap.io/blog/the-four-stages-of-data-maturity

Slide 102

Slide 102 text

https://www.heap.io/blog/the-four-stages-of-data-maturity す ご い 高 い 壁

Slide 103

Slide 103 text

データ成熟度の4段階 ● Data-exploring ○ データ収集はしているが活用できておらず、意思決定は直感に頼る段階。 ● Data-informed ○ データの価値を認識し始め、分析ツールやデータスタックへの投資が始まる段階。 ● Data-driven ○ データが意思決定の中心となり、組織全体でデータ活用が浸透する段階。 ● Data-transformed ○ データが組織のDNAとなり、すべての活動がデータに基づいて最適化される段階。

Slide 104

Slide 104 text

データ成熟度の4段階 ● Data-exploring ○ データ収集はしているが活用できておらず、意思決定は直感に頼る段階。 ● Data-informed ○ データの価値を認識し始め、分析ツールやデータスタックへの投資が始まる段階。 ● Data-driven ○ データが意思決定の中心となり、組織全体でデータ活用が浸透する段階。 ● Data-transformed ○ データが組織のDNAとなり、すべての活動がデータに基づいて最適化される段階。 ツールの力でいけるのはここまで

Slide 105

Slide 105 text

データ成熟度の4段階 ● Data-exploring ○ データ収集はしているが活用できておらず、意思決定は直感に頼る段階。 ● Data-informed ○ データの価値を認識し始め、分析ツールやデータスタックへの投資が始まる段階。 ● Data-driven ○ データが意思決定の中心となり、組織全体でデータ活用が浸透する段階。 ● Data-transformed ○ データが組織のDNAとなり、すべての活動がデータに基づいて最適化される段階。 ここからは人や組織が重要

Slide 106

Slide 106 text

Data-drivenへの壁:技術から人へのシフト Data-informedまではエンジニアのマンパワーとツールの力で達成可能ですが、 Data-drivenへの移行は全く異なる性質の課題です。 この段階では技術より「人」が中心課題となり、 組織文化や意思決定プロセス、個々の行動様式を変える必要があります。 最新のデータ基盤を導入しても組織の行動が 変わらなければ真のData-drivenは実現しません。 ここからの道のりは、技術的課題から組織変革へと本質が変わるのです。

Slide 107

Slide 107 text

実際にData-drivenへ 向かうためにやっていること

Slide 108

Slide 108 text

RevOpsの導入 RevOpsの考え方を経営に導入し、 部門間の壁を越えて収益最大化を 目指しています。 短期的な課題解決と 長期的なビジョンを両立させながら、 データを経営資本として活用することを 目標にデータ活用を推進中。 https://speakerdeck.com/pei0804/path-to-revops

Slide 109

Slide 109 text

最後は人や組織の課題に向きあう。

Slide 110

Slide 110 text

https://speakerdeck.com/pei0804/data-engineering-for-business

Slide 111

Slide 111 text

まとめ

Slide 112

Slide 112 text

Data-informedまでさっさと行こう。 そこには技術選定が効く。

Slide 113

Slide 113 text

まとめ データ基盤は事業にとって必須ではないことが多いです。 なので、使われるだけでも簡単な道のりではないです。 また真に価値あるデータ基盤を構築するには、 最終的には組織設計まで視野に入れる必要があります。 ツールの力を借りれば、「Data-informed」の段階には 比較的早く到達できますが、真の「Data-driven」組織を目指すには、 技術と組織の両輪で「人」と向き合う継続的な取り組みが不可欠です。

Slide 114

Slide 114 text

データ成熟度の4段階 ● Data-exploring ○ データ収集はしているが活用できておらず、意思決定は直感に頼る段階。 ● Data-informed ○ データの価値を認識し始め、分析ツールやデータスタックへの投資が始まる段階。 ● Data-driven ○ データが意思決定の中心となり、組織全体でデータ活用が浸透する段階。 ● Data-transformed ○ データが組織のDNAとなり、すべての活動がデータに基づいて最適化される段階。 これが実現できてる世界見たくないですか?

Slide 115

Slide 115 text

【PR】We're hiring 【アナリティクスエンジニア】データ活用の可能性を引き出し、新たな価値創造に挑戦 https://hrmos.co/pages/cartaholdings/jobs/cmf-e04 【データエンジニア】データの源泉から価値創造までエンジニアリングする https://hrmos.co/pages/cartaholdings/jobs/cmf-e05 【リード機械学習エンジニア】低レイテンシーな機械学習システムでデータ駆動の意思決定を推進 https://hrmos.co/pages/cartaholdings/jobs/cmf-e03 【データサイエンティスト】20の事業を生成AIで支援するデータサイエンティスト https://hrmos.co/pages/cartaholdings/jobs/carta-e08 【データエンジニア】運用型テレビCMサービスを支えるデータ分析基盤の構築・運用! https://hrmos.co/pages/cartaholdings/jobs/telecy-e15