本記事では、2025年5月14日に開催されたオンラインイベント「【技術選定を突き詰める】Online Conference 2025」内のセッション「使えるデータ基盤を作る技術選定の秘訣」の内容をお届けします。同セッションでは、CARTA HOLDINGS / 事業部 VP of Dataのpeiさんに事業におけるデータ基盤の価値からツール導入のポイント、そして導入後の活用についてお話しいただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
pei：CARTA MARKETING FIRMのpei（@pei0804）です。 本日は「使えるデータ基盤を作る 技術選定の秘訣」というタイトルでお話しします。
現在、CARTA HOLDINGS傘下のCARTA MARKETING FIRMという会社でVP of Dataを務め、データ戦略からエンジニアリング、組織づくりまで幅広く担当しています。Snowflakeを得意としており、2024年、2025年と2年連続でData Superheroesに選出されています。
「便利そう」で選ぶ技術選定は、なぜ失敗するのか
データ界隈は日々無数の技術が登場しますが、個別ツールの紹介はすぐに陳腐化してしまいます。そこで本日は、その中から本当に必要なものを見つけ出すために、私が普段考えていることを共有します。というのも、「データ基盤やツールを導入したのに、なかなか活用されない」という相談を本当によく受けるからです。こうした失敗には共通点があり、本日はそのアンサーとなるお話です。
話を聞くと、導入理由が「便利そうだったから」というケースが非常に多いのですが、これは大抵の場合、失敗します。よくありがちな罠として、管理者目線での「便利そう」は、現場では基本的に流行らないと私は思っています。
例えばモダンなツールを入れても、利用者からすれば「このデータがない、このグラフがない」という課題が挙がり、結局「じゃあスプレッドシートでやろう」となる。管理者は「またスプレッドシートでやってるよ、みんな勉強してよ」と嘆くことになります。高度な技術を導入しただけでは、ラストワンマイルを解決してくれる表計算ソフトに負け続けるんです。
解決策はシンプルで、「本当の痛み」を解けば人は動きます。実際にデータを使って価値を出す利用者が本当に欲しいものを選定し、提供すること。これが今日いちばん伝えたいことです。
事業におけるデータ基盤の価値とは
技術選定に入る前に、まず事業におけるデータ基盤の価値について目線合わせをさせてください。もしデータ基盤が1日止まったら、どれくらい困るでしょうか？すぐに問い合わせが殺到するか、あるいは翌日になっても誰も気づかないか。それだけでも、価値の大きさはある程度測れます。
データ基盤がなくても事業が回ることは、実は少なくありません。これは、データ基盤が事業のスケールに伴って後から付加価値として生まれるものだからです。100行のデータなら人間が見ればいいですが、1億行は無理ですよね。特に歴史ある事業はデータ基盤なしで成功してきたため、「本当に必要なのか？」と思われがちです。
だからこそ、事業に不可欠な存在になるには戦略的な活用が必須です。場当たり的な施策ではコストばかりかかっていると思われ、私の感覚では2〜3年で「価値が出ていない」と判断され、頓挫してしまいます。この「なくても事業が回る」という構造的な課題こそが、技術選定の出発点です。
では、価値ある状態とは何でしょうか。「データ基盤の利用者に日々使われていること」、これが何よりも重要だと思います。データ基盤が使われている状態は、人の営み自体に影響していく動きを意味します。そのため、「便利そう」という理由だけでツールを導入しても誰も使いません。「これなら明確に使える」というストーリーが非常に大事です。そのストーリーを作れる技術なのかをベースに技術選定をします。
大局を知る：無数のツールとどう向き合うか
技術選定をする前に、我々が置かれている大局を捉えましょう。ご存知の通り、モダンデータスタックの登場でデータ基盤の構築はかなり民主化が進んでいます。無数のツールの中から選べば“それっぽいもの”は作れます。今日の話は、まさにこのツール群とどう向き合うかです。
結論から言うと、これらのツールを使わない手はありません。多くの技術的課題はツールで解決できます。かつて数ヶ月かかった作業が、今や数クリックで終わる時代です。データを使いたい人にとって重要なのはアクセスできるまでの時間で、すぐに使えることが価値になります。
ツールを使うもう一つの大きなメリットが、集合知にアクセスできる点です。例えばdbtは、裏側のデータウェアハウスを抽象化して「共通言語」となるため、「こういう場合はどうする？」といった業界全体の知見を活かした議論が格段にしやすくなります。一方でフルスクラッチだと独自事情が多くなり、集合知へのアクセスが難しくなります。
また、一定の評価を得ているツールには洗練されたプラクティスが備わっています。そのツールにある程度業務を合わせた方が、良い管理手法を採用できます。これは、集合知の活用や、長期的にはツールの置き換えさえ容易になるため、戦略的にそうした方がよいと考えています。逆に自社要件でカスタマイズしすぎるとベンダーロックインのリスクがあります。業界のプラクティスに自社のデータを寄せていく方が、結果的にツールを選べるようになり、管理も楽になる。良いことずくめです。
ツールで「データを試す速度」を最大化する
「ベンダーロックインが怖い」という声も聞きますが、時間をかけすぎてビジネスの“旬”を逃す方がずっと怖いです。データを試したいという熱量があるうちにすぐ試せる環境が何より大事で、ロックインを議論している間にプロジェクト自体が頓挫しかねません。
データ活用プロジェクトは、基本的に失敗の連続です。優秀な人材や高度な技術を投入したとしても、試行錯誤のサイクルが速くなる可能性はあっても、成功「率」そのものは、なかなか上がりません。ビジネス的には何も変わらない、という失敗を何度も乗り越える。これがデータ活用なんです。
仕組みを議論している間に、他社はどんどん試して成長していきます。とにかく試すこと、たくさん失敗することが成功への近道です。「試す前から大変」と言っていたら、もっと大変な「試した後」には永遠にたどり着けません。
ですから、ツールに乗っかれる部分は乗っかり、とにかく価値を出すことに集中しましょう。たくさん試せば、「使える」ストーリーは自然と生まれます。すぐ試せる状況を作るために、ツールを絶対に使った方がいいです。
ツール選定の勘所
では、具体的にどうツール選定を進めるかの話です。モダンデータスタックはツールが多すぎて、何から手をつければいいか分からないですよね。
私のおすすめは、ツール選定の前に「今、何に困っているのか」を把握することです。データ基盤が必要な時点で、何かしらの課題があるはずです。課題が把握できたら、それが「データの取り込み」なのか、「変換」なのか、「可視化」なのかといったカテゴリーを特定し、自分たちのニーズがカオスマップ上のどの領域にあるかを見定めます。
よく「課題がどこにあるか分からない」と聞かれますが、それは現場を見ていなさすぎです。データ基盤チーム以外にも、データを使って仕事をしている人は身の回りにいます。議事録もレポートも、すべてがデータです。
現場を深掘りすれば、「なぜこんなことを手作業で？」というような、テクノロジーで解決できる課題が山ほど見つかります。例えば、重要なのに置き場がスプレッドシートしかないデータや、あちこちに散らばってサイロ化したデータなどです。こうした身近な課題を解決することが、「使えるストーリー」の第一歩になります。
とはいえ、課題のカテゴリーを特定しても、まだツールは非常に多いです。
そこでおすすめなのが、まずは何でもいいので1つツールを試してみることです。ほとんどのツールにトライアル期間があり、すぐに試せます。実際に触れば「これは課題を解決できる」「課題はそこじゃなかった」といった手触り感が得られ、自社に必要な機能も見えてきます。
さらに踏み込むなら、同じカテゴリーで3つほど試すのが理想です。すると、各ツールが持つ共通機能、つまりそのカテゴリーが解くべき本質的な課題が見えてきます。同時に、ツールごとの微妙な差も明確になり、自社の文化にどれがマッチするのか、より適切な選択ができるようになります。
導入判断する前に見る8つのポイント
では、最終的に導入するツールをどう決めるか。私が重視している基準をお話しします。
1. 圧倒的に仕事を変える力があるか
いちばん見ているのは「圧倒的に仕事を変えられるかどうか」です。「少し便利になる」程度のツールは、覚えるコストや運用コストに見合わず、誰も使いません。「これを使わないともったいない」、そう思えるほどインパクトのあるツールだけを導入すべきです。
2. 学習コスト
高機能でも学習コストが高いツールを大勢に学習してもらうことは非現実的です。「見たら分かる」が一番です。もちろん、学習コストが高くても事業に必要なツールはありますが、その学習は基盤チームが担えばよいと考えます。基盤チームだけが使うならシンプルで小回りが利くもの、基盤利用者がメインで使うものは、とにかく簡単にすぐ使えることが重要です。
3. 公式ドキュメントの充実度
「ツール自体は良いから」とドキュメントが不十分なサービスを導入すると、結局問い合わせがすべて基盤チームに集中し、業務負担が増大します。ドキュメントが私たちの代わりに説明できる状態になっていることは、自分たちの負荷を軽減する意味でも非常に重要です。
4. サポート体制の良し悪し
SaaSの場合はサポート体制の良し悪しも重要なポイントです。トライアル中に担当者と話し、「この人は本当に分かっているな」と感じるアドバイスをくれるか注視します。もし少しでも違和感を覚えたら、導入後にも同様に発生するので無視せず考慮したほうが良いです。周囲に先行ユーザーがいれば、評判を聞いてみるのも良いと思います。
5. コミュニティの活発度
必須ではありませんが、コミュニティの活発度は大きなレバレッジになります。公式サポートではカバーしきれない、導入後の運用や活用といった生々しい課題は、コミュニティの方が議論しやすいです。データに関する悩みは業界が違えど驚くほど似ているので、他業界の成功事例が自社に応用できることも多く、その点でコミュニティは重要です。
6. 課金モデルと組織体制の相性
ここまで検討できたら、導入判断を悩み始めますが、その際に非常に大事なのが課金モデルと組織体制の相性です。SaaSの場合は必ずプライシングがあると思いますが、課金に影響する変数がどこにあるかをしっかり見た方がいいです。 例えば利用者数課金モデルの場合、将来的な拡大を見越さないと、「これ以上人数が増えたら無理だ」と、課金形態が活用の足枷になってしまいます。理想は、活用することがペナルティにならない課金形態です。
7. ロードマップへの共感度
課金形態も分かり、使えそうと考えている段階で大事なのが、ロードマップへの共感度です。自社とツール提供元が目指す方向が、中長期的に一致しているかを見ます。今良くても、向かう先が違えばだんだん離れていき、いずれ“お別れ”することになってしまいます。今までどうやってロードマップを決定し、過去のロードマップが実際に達成できているかといった点も見た方がいいです。現状だけで判断すると翌年には不要なツールになってしまう場合もあります。
8. セキュリティ体制
候補となるツールが2、3個に絞られ、まだ1つに決められないという時に判断基準となるのがセキュリティ体制です。特に機密データを入れるとなると、この観点はかなり大事です。SOCやISMSといった認証を取得済みなら社内調整も非常に楽ですが、一切取得していないとヒアリングが面倒になります。そういう時にセキュリティの点で足切りにして「認証がなければ無理」と絞り込むことも多く、定量的に判断できるラインです。将来的に認証を取得するという場合や、認証がなくてもヒアリングで通過させて使うと覚悟を決めるなら、それでも良いと思います。
「撤退シナリオ」を導入前から考える
そして、ここまでの基準をクリアし、いざ導入を決めるその前に必ずやってほしいのが、「撤退シナリオを考える」ことです。
特に多くの利用者が関わるツールは業務に密接に紐づくため、切り替えの負担がとても大きく大変です。だからこそ、どうすれば撤退できるかを最初に考えておくべきです。そのSaaSの将来性や収益モデル、この課題解決自体が事業にとってどれくらい重要なのか、などを総合的に見て判断していきます。
撤退の方法を決めていくと、責任範囲が自動的に決まります。「このツールにはここまで任せる」「ここは任せない」という線引きが重要です。ツールが成長して機能を拡張してきても、安易にすべてを任せない。そうすれば、数年後にトレンドが変わった時でもツールを剥がしやすくなります。こうして事業の独立性を保ち、将来の技術選択の自由度を確保するためにも、撤退シナリオは最初に考えるべきなんです。
良いツールを見つけ、導入してからが本番です。「サービスを入れたのに誰も使わない」という事態を避けるため、オンボーディングが極めて重要になります。
当初利用を想定していた人は、おそらくすぐに触ってくれて便利だと感じてくれると思います。ですが、本当に活用を広げたいのは、まだその価値に気づいていない潜在的なユーザーです。彼らにただ「便利ですよ」とツールを渡しても、「何に使うか分からない」と感じるんです。
人生で一度もフォークを見たことがない、スプーンでスパゲティを食べていた人に「フォークはすごく便利です」と渡しても、「何に使うんだ？」となります。「こう使うと食べやすいですよ」と一度一緒にやってみせる。そうすれば、その便利さを理解し、使ってくれるようになります。そして、その人がまた別の人に便利さを伝えてくれます。この道具が何を解決するのかを教え、一緒に使ってみる。これは泥臭くやるしかないので頑張りましょう。
事業をデータエンジニアリングする
参考までに、私たちCARTA MARKETING FIRMのツール選定をお話しします。
データソースの取り込みはFivetran、ログ系はSnowflakeのデフォルト機能に任せ、dbtで変換し、AWS Step Functionsでオーケストレーション。メトリクスやコストの可視化はSELECT、データオブザーバビリティはElementary Cloudに任せています。こうして整備したデータを、最終的に活用レイヤーの人たちが自由に利用しています。詳細な構成はFindy Toolsの記事にも書いているので、よろしければご覧ください。
このアーキテクチャは2年ほど変化がなく、正直なところ、技術的な課題はもうほとんどありません。
今取り組んでいるのは、テクノロジーで解決すべきデータ関連業務のデジタル最適化です。例えば、隣の人に聞けば分かるようなことは、データ基盤が頑張る必要はありません。その人に聞けば大体事業のことが分かります。ただ、私たちの会社は4社統合したり、今後も統合があったりすると知識がサイロ化してしまいます。そうなった時に、全体を説明できるのがデータだけになったり、多様な広告プラットフォームから手作業でレポートを集めていては日が暮れてしまう、といった課題が出てきます。
こうした手作業のETL処理を自動化し、「朝出社したらレポートが揃っている」状態を作る。これはデータ基盤の構築というより、今までデータになっていなかったものをデータ化する営みです。私はこれを、「事業をデータエンジニアリングしている」と呼んでいます。
人・組織・文化こそがツール導入後の真の課題
ツールが活用され始め、「あとは寝て待てばいい」と思ったら大間違いです。dbtのレポートによると、データ分析で大変なことの上位は、データ品質、ステークホルダーのリテラシー、データオーナーシップの曖昧さといった組織的な課題ばかりです。
つまり、皆が困っているのは技術ではなく、人・組織・文化。これこそがツール導入後の真の課題です。
データ基盤を入れているということは、おそらくデータドリブン経営を目指していると思います。データドリブン経営は、行動変容を伴って初めて意味をなします。ツール導入はその第一歩にすぎず、その先には組織文化の醸成や人材育成といった、より広い範囲の仕事が待っています。
組織のデータ活用成熟度には、大きく4つの段階があります。
- Data-Exploring：データ収集はしているが活用できておらず、意思決定は直感に頼る段階
- Data-Informed：データの価値を認識し始め、分析ツールやデータスタックへの投資が始まる段階
- Data-Driven：データが意思決定の中心となり、組織全体でデータ活用が浸透する段階
- Data-Transformed：データが組織のDNAとなり、すべての活動がデータに基づいて最適化される段階
データ基盤を入れようとしている人たちは、Data-Exploringからスタートして、最終的にはData-Transformedを目指していきます。このうち、「Data-Informed」の段階までは、ツールの力で到達できます。「使えるストーリー」を積み重ねていけばいいからです。
しかし、その先の「Data-Driven」への壁はとても高いです。ここからは人や組織が重要になるからです。課題の本質が技術から「人の行動変容」へとシフトします。ツールを使ってもらうのではなく、データに基づいた意思決定という行動そのものが当たり前になる必要があります。だから大変なんです。
では、どうやってこの壁を越えるのか。私がData-Drivenへ向かうために実践していることは、RevOps（Revenue Operations）です。これは、データを使ってチームの壁を越え、組織全体の利益を最大化する取り組みです。この鍵こそがデータ。データは組織の「共通言語」になり得ます。各チームが同じデータ、同じレポートを見ていれば、そこには共通言語が生まれ、「あのチームとコラボしよう」といった共通認識が育ちます。
RevOpsは共通言語を作る動きだと思っています。組織の能力を上げ、共通言語にすることで意思決定のレベルが底上げされるので、どちらにも効果があります。最終的には、人や組織といった課題に向き合いましょうという話です。詳細は以下の資料も参照してください。
Data-Drivenへの道は「技術と組織」の両輪で進む
まとめです。まず「Data-Informed」まではさっさと行きましょう。ここに3年もかけている場合ではありません。これは技術選定を上手くやれば行けます。
これまで話してきたように、データ基盤は構造的に「使われる」だけでも簡単ではありません。しかし真の価値は、その先の行動変容にあります。幸い、ツールの力を借りれば「Data-Informed」へは昔より比較的早く到達できます。
そして、その先の「Data-Driven」を目指すには、最終的に技術と組織という両輪で、人と向き合う必要があります。私たちは今まさに、そのData-Drivenな世界の実現を目指しています。
Q&A
Q. 部署ごとに利用ツールが違うと、管理が難しくなりませんか？
A. ツールの役割次第では、バラバラでも問題ありません。最終的なデータの合流地点さえしっかり設計すれば、各チームのツールは違っていても大丈夫です。
特に、データの可視化や分析といった「活用」部分のツールは、各チームに選択を任せています。なぜなら、元となるデータウェアハウスは全社で共通化されており、そこからどうデータを活用したいかはチームによって異なるからです。例えばBIツール一つとっても、単純な表で見たいチームもあれば、複雑な分析をしたいチームもいます。ここで基盤チームがツールを一つに縛ると、かえって活用されなくなってしまいます。
「データはここにすべて集約します。どう活用するかは自由です」というスタンスで、様々なツールからデータが集まるように導線を設計するのが、私たちの腕の見せ所です。
Q. 「圧倒的に仕事を変える力」を定量化する指標はありますか？
A. 結論から言うと、指標は使いません。例えば、これまで8時間かかっていたレポート作成が3秒で終わるなら、もはや指標は不要ですよね。圧倒的すぎるからです。
私は、8時間が4時間になるような「少しの改善」にはツールを入れません。誰が見ても分かるくらい、劇的に仕事が変わる所にだけ投資します。その方が変化が圧倒的で、楽すぎるので、人は自然とついてきます。スプーンでパスタを食べていた人がフォークの便利さを知ったら、もう戻れないのと同じです。作業そのものを無くすくらいの改善を狙っています。
ただし、経営層への説明ではROIを算出します。削減できる作業時間を人件費に換算し、何ヶ月で回収できるかといった説明をします。説明する相手によって情報の見せ方を工夫しています。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
「『使える』データ基盤を作る技術選定の秘訣」
※動画の視聴にはFindyへのログインが必要です。