DevOpsエンジニアは、なぜ『データ』で越境したのか?:サイロの摩擦を溶かし、組織を繋ぐデータマネジメント立ち上げのすすめ

DevOpsエンジニアは、なぜ『データ』で越境したのか?:サイロの摩擦を溶かし、組織を繋ぐデータマネジメント立ち上げのすすめ

この記事は、2026年4月14日に開催された「DevOpsDays Tokyo 2026」での登壇内容を、Qiita用に記事としてまとめたものです。

DevOpsエンジニアは、なぜ『データ』で越境したのか?:サイロの摩擦を溶かし、組織を繋ぐデータマネジメント立ち上げのすすめ / Why a DevOps Engineer Crossed the Border with 'Data': Melting Silos and Connecting Organizations Through Data Management

はじめに

みなさん、DevOpsしていますか?

DevOpsの提唱者の一人であるPatrick Debois氏は、DevOpsを 「サイロによって生まれる摩擦を克服するためにすること全て」 と定義しています。

私は株式会社カオナビでDevOpsエンジニアとして活動してきましたが、組織の壁(サイロ)を壊し、全体最適を加速させるための最強の武器として選んだのが 『データ』 でした。

本記事では、2026年4月14日に開催された「DevOpsDays Tokyo 2026」での登壇内容をもとに、一人のDevOpsエンジニアがなぜデータマネジメントの世界へ越境し、どのように組織を繋いでいったのか、その軌跡と知見を共有します。


1. カオナビにおけるデータ基盤の歩み(2023-2026)

私が2023年に入社してから現在に至るまで、カオナビのデータ基盤は以下のようなステップで進化してきました。

  • 2023年:導入期(種まき)
    • SnowflakeのPoCを開始。まずは「データが集まる場所」を定義。
  • 2024年:拡大期(活用提案)
    • プロダクトの利用実績データを収集。社内の各部署へ「データがあればこんなことができる」という提案を回る。
  • 2025年:再構築期(基盤刷新)
    • 本格的な活用に応えるため、より堅牢でスケーラブルなデータ基盤へ再構築。
  • 2026年:高度化期(AIとの融合)
    • AI(LLM)がデータを解釈し、誰もがインサイトを得られる環境へ。

この数年で、Salesforce、GitLab、Redmine、GA4、Marketoといった、社内に点在していた「サイロ化されたデータ」をSnowflakeへと統合してきました。

2. なぜ「データ」が必要だったのか:組織を蝕む「見れない」問題

越境のきっかけは、組織内のあちこちで起きていた**「見れないことによる摩擦」**でした。

開発(プロダクト企画・開発)側の課題

新機能をリリースしても、それが「本当に使われているのか」「顧客の価値に繋がっているのか」を評価する術がありませんでした。権限やインフラの制約で、エンジニア自身が本番DBのデータに触るハードルが高すぎたのです。

ビジネス(CS・販促)側の課題

カスタマーサクセス(CS)は、顧客がプロダクトを使いこなせているか分からず、一歩踏み込んだ提案ができませんでした。「何に困っているか」を把握するために、毎回顧客にヒアリングする必要があったのです。

「データが繋がっていない = 組織が分断されている」 という状態でした。

3. データは組織を繋ぐ「共通資産」

私は、データを特定の部署の持ち物ではなく、**「組織を跨いで活用される共通資産」**と定義し直しました。

Snowflakeを中央に据え、情報の非対称性を解消することで、サイロは自然と溶け始めました。

  • 開発チームは、自らSQLを叩き、機能改善の効果を数値で測るようになる。
  • CSチームは、顧客の利用状況をダッシュボードで確認し、解約予兆の察知やアップセル提案に活かす。

データという共通言語を持つことで、「推測」ではなく「事実」に基づいた対話が組織間で生まれました。

4. DevOpsエンジニアがデータマネジメントを担う「必然性」

なぜ、データエンジニアではなく「DevOpsエンジニア」がこの役割を担ったのか。そこには、DevOpsエンジニア特有の 「パイプライン意識」 があります。

ビジネスプロセスも一つの「パイプライン」

DevOpsエンジニアは、コードが本番にデプロイされるまでの「開発パイプライン」を最適化するのが仕事です。 実は、 ビジネスプロセス(Lead → Inside → Field → Customer → Churned)も、全く同じ構造のパイプライン として捉えることができます。

視点 開発パイプライン ビジネスパイプライン
主な指標 リードタイム、デプロイ頻度 成約までの期間、CVR
現場の課題 フェーズごとの在庫(仕掛品) 案件の滞留、リードの放置
思考法 TOC(制約理論)、フロー効率 全体最適、歩留まり改善

DevOpsエンジニアが持つ「パイプラインを整え、流れを良くする」という思考は、データの流れを整えてビジネスのボトルネックを見つけ出すデータマネジメントと、非常に親和性が高いのです。

5. AI時代のデータ基盤:インターフェースの変革

2026年現在、データ活用の現場はさらに進化しています。人間がSQLを書くだけでなく、AIがデータ基盤の「スキル」として機能しています。

カオナビでは、Claude Desktopのskills機能などを活用し、AIが直接Snowflakeのデータを確認しにいく仕組みを構築しています。

AIへの依頼例: 「〇〇社の過去3ヶ月のログイン頻度と、新機能Aの利用状況をグラフにして、チャーンリスクがあるか分析して」

このように、AIというインターフェースを通じてデータが民主化されることで、非エンジニアでも高度なデータ分析が可能になり、サイロの解消はさらに加速しています。

結びに:越境する勇気を

DevOpsの本質が「サイロの摩擦を克服すること」であるならば、データマネジメントはまさにDevOpsそのものです。

DevOpsエンジニアのみなさん。今持っているその「パイプラインを整える技術」を、ぜひデータの世界に向けてみてください。組織の壁を溶かし、ビジネスを繋ぐ新しい景色が見えるはずです。


登壇資料・参考文献