下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

DataOpsとは何か #dataops

  • 本稿は、コンテンツの保存を目的として、2018年8月10日にR-Techブログに寄稿した記事を転記し、一部表現を修正したものです。 https://blog.recruit.co.jp/rtc/2018/08/10/developers_summit_summer2018/

  • 本稿の筆者は DataKitchen の記事でも紹介されており、事実上「日本におけるDataOpsの第一人者」だと自認しています。 https://medium.com/data-ops/dataops-goes-global-9d6e67dcaf30

  • 本稿の内容は筆者の個人的な見解であり、当時の所属を代表するものではありません。 また、DataOpsという用語についてグローバルスタンダードの定義を説明したものでもありません。 本稿の内容を参考にして「DataOpsとは何か」を業務で説明する場合、一般論ではなく「この記事の筆者の解釈である」ことを明記してください。 2018年以降、引用元を明記せずにDataOpsを解説した記事・資料が増えていますが、トラブルの温床ですのでご注意ください。

前書き

「いかにDataとOpsを繋げるか」というテーマで Developers Summit 2018 Summer に登壇しました。

多岐に渡るトピックを網羅しているので、以下のような内容に興味のある方はぜひスライドを参照ください。

  • Webマーケティングにおけるデータ活用事例
  • 「自然に」「無理なく」データを活用できるようなユーザー体験のデザイン
  • データ基盤のアーキテクチャやインフラ設計
  • データチームへのスクラム開発手法の適用
  • 非エンジニア・サイエンティストがデータ分析を実施するための文化醸成

なにはともあれ無事に終えることが出来てほっとしています。 ご関係者の皆様、誠にありがとうございました。

関連記事

yuzutas0.hatenablog.com

DataOpsとは何か

本稿では裏話として、タイトルにある「DataOps」の意味についてご説明します。

DataOpsという言葉ですが「DevOps」のコンセプトをデータ活用に当てはめたものだと言われることが多いです。以下のWebサイトや記事が代表例となります。

このように一部界隈で注目されているDataOpsですが、DataOpsを取り巻くプラクティスはまだ荒削りのようです。あくまでも「こういう方向を目指しましょう」というコンセプト提唱のフェーズなのだと私自身は解釈しています。そのためDataOps自体の表面的な解説をするのではなくDevOpsの文脈上で意味を捉えるほうが適切でしょう。

DevOpsとは何か

ではそもそも「DevOps」とは何かと言われると、主に2つの方向で解釈が分かれているように見受けられます。

1つ目は「Infrastructure as Code」などに代表されるもので、Ops(システム運用業務)にDev(システム開発手法)を適用するという考え方です。 よりITシステムに注目した視点と言えるでしょう。 形式ばったシステム運用を改善しようという取り組みです。

R-Techの場合ですと、書籍 『DevOps導入指南 – Infrastructure as Codeでチーム開発・サービス運用を効率化する』 で解説を行っています。 国内のデータ界隈だと「MLOps」という言葉を耳にする機会が増えてきましたが、主にこちらの意味合いのDevOpsに近い意味で使われることが多いようです。

2つ目はDev(システム開発者)とOps(システム運用者)による協働を指す考え方です。 よりIT組織に注目した視点と言えるでしょう。 凝り固まったサイロ化組織を改善しようという取り組みです。

R-Techの場合ですと、デブサミ夏(2015)登壇資料『経営のアジリティを支えるDevOpsと組織』 で解説を行っています。 この資料では「開発チームはスクラムを通してシステム課題を可視化し、短期解消可能であればチーム内で改善する」「システム運用チームはITILの枠組みで長期的負債を管理・解消する」「スクラム開発のレトロスペクティブとITIL運用の課題管理がチケットによって繋がる」という例を挙げています。

xOpsとは何か

これら2つは注目する視点こそ違いますが、大元の目的は同じです。 どちらも(チーム開発手法などを含めた広義の)ソフトウェアエンジニアリングの知見を最大限に活用し、開発・運用の業務におけるボトルネック(ムダ・ムラ・ムリ)を取り除くことで、ビジネス価値を最大化する取り組みと言えます。

このDevOpsの延長として、DesignOps、CustomerOps、BizOps、RevOps、SalesOps、MarketingOpsといった言葉(いわばxOps)が台頭しています。 Takaaki Umada氏の『xOps: エンジニアがスタートアップの成長の原動力となる日』 という資料では「xOps」台頭の背景として「あらゆる業務でITシステムがボトルネックになりつつあるから」(=ソフトウェアエンジニアリングによって大幅改善を期待できるから)だと解説しています。 MLOpsやDataOpsもまた同じです。

DataOpsとは何か(解)

今回の登壇のタイトルに「DataOps」という言葉を入れたのは上記の経緯を踏まえたからです。

  • ビジネス価値を生み出すデータ活用案件とは何か
  • 効率的なプロセスとはどのようなものか
  • 信頼できるデータ基盤をどう構築&運用するか
  • 安定したデータチームをどう運営するか
  • 1人1人がデータを活用できる文化(データの民主化)をどう実現するか

こうした命題に対して、ソフトウェアエンジニアリングの知見を最大限に活用し、業務上のボトルネック(ムダ・ムラ・ムリ)を取り除くことで、ビジネス価値を最大化することこそが「DataOps」なのだと解釈しました。

まぁそれを言ったら大抵の取り組みがxOpsだと言えてしまうので、ただの言葉遊びだと指摘されてしまうとその通りです。 ただ「データ活用のあらゆる側面に対してエンジニアリング・マネジメントが必要ですよ」(華やかに見える他社事例やAIという言葉に振り回されている場合ではありませんよ)ということを明確にメッセージしたかったので、あえてDataOpsという言葉を選びました。

以上です。 めでたしめでたし。

追記(2022年1月)

上記で説明しているように「ITシステム構築や自動化がDataOpsである」は正確な解釈ではないと筆者は考えています。 しかし、誠に残念なことに、筆者の過去のアウトプットでは、データモデリングや技術要素などの個々のキーワードばかりが注目されてしまいました。 DataOpsの話をしても、返ってくるのは「要するに3層で管理すればいいんですね」「要するにBigQueryを使えばいいんですね」といったコメントです。

「データ基盤の3分類と進化的データモデリング」 という記事では「進化的データモデリング」という設計思想(Why/What)を提案しました。 DevOpsではCI(継続的インテグレーション)やCD(継続的デリバリー)が重要な役割を果たします。 同様にDataOpsでは「進化的データモデリング」が重要な役割を果たせるはずです。

しかし、実際には「進化的データモデリング」ではなく「3層構造」という設計手法(What/How)だけが独り歩きしました。 引用元を明記せずに「うちは3層構造で作りました」とWhat/Howだけをアウトプットした者たち、 引用元を調査せずに「うちも3層構造で作ろう」とWhat/Howだけをインプットした者たちが、大勢いました。 その結果「3層構造はここの役割分担で迷うから良くない」といったコメントまで出てしまいました。

stand.fm

stand.fm

拙著 『データマネジメントが30分でわかる本』(2020年)『実践的データ基盤への処方箋』(2021年) も、当初はDataOpsの説明を目指していましたが、上記を踏まえて「xOpsを大多数の読者に説明するのは現実的ではない」と考え、現在の形に方向転換しました。 多くの人間に影響を与えて、現実の行動を促すのは、具体的で一貫性のある「How」の体系なのだと思います。 ポリシー(Why/What)は、アーキテクトが具体的で一貫性のある「How」の体系を提供する際に、常に根底にあるものです。 逆に言うと、それ以上の役割を担うべきではないのかもしれません。

「DataOps」というキーワードが出てくる度に、つい「そういうことじゃないんだよ」と言いたくなる自分がいます。 そのような自分に対して「いちいち相手にするなよ」「2018年に言いたいことは全て言っただろ」と言い聞かせるために、本稿を改めて残しておきます。 私自身もDXとかプロダクトマネジメントとか、キーワードの提唱者が不本意に思うであろう使い方をしているので、気にしたら負けだなと思います。