0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

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

0
Last updated at Posted at 2026-05-11

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

はじめに

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


登壇資料・参考文献

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?