下町柚子黄昏記 by @yuzutas0

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

GCPUGでデータ基盤の話をしました #gcpug

社内GCPUG1でデータ基盤の話をしました。 Cloud Dataflowのプロダクトマネージャーを招いた豪華イベントでした。 実施は半年前ですが、ずっとブログに書き忘れていたので、自分の記録用に投稿しておきます。

※本稿は個人の見解であり、所属する組織を代表するものではありません。

スライド

「BigQuery for DDDD」

内容としては「Jupyter+BigQueryによるデータ分析基盤のDev&Ops」から一部を抜粋・英訳したものがメインとなります。 元資料との明示的な違いとして「1.サービスレベル」「2. データのリボン」「3. コストセンター」の3点について言及しています。

データ基盤におけるサービスレベル定義

f:id:yuzutas0:20180620233001p:plain

f:id:yuzutas0:20180620233316p:plain

分析用途のデータ基盤では個人を特定できないようにデータを加工しています。 個人情報をマスキングしたDBビューと、そのビューにしかアクセスできないDBユーザーを用意して、そのユーザー経由でデータをBigQueryに疎通しています。

サービスレベルについては以下のエントリーを参照ください。 yuzutas0.hatenablog.com

データ基盤におけるサービスレベルの設計・運用の全体像については以下のエントリーを参照ください。 yuzutas0.hatenablog.com

データ基盤とはリボンである

データ基盤とは何か?という問いに対する私なりの定義を明記しています。 「n個のデータソースとn人の利用者をリボンのように結びつけるもの」をデータ基盤として解釈しています。

f:id:yuzutas0:20180620233907p:plain

@ITの連載記事でもこの定義について言及しました。

データ基盤とは「データソースと利用者をリボンのように結び付けるもの」だと筆者は解釈しています。 データソースや利用者がお互い1つのときは、直接参照するだけで要求は実現できるでしょう。 しかしプロダクト成長や体制拡大によって、リボンの両側は多様になっていきます。そうなると、結び付ける役割のデータ基盤が必要になるのです。

開発現場に“データ文化”を浸透させる「データ基盤」大解剖 - @IT

ちなみに世界最古のデータ基盤は、船乗りが水の残量をモニタリングするために樽に横線を引いたやつだと(勝手に)思っています。 この例は示唆に富んでいて、水のリアルタイム状況とは別にスナップショットの履歴を記録するので費消傾向を分析できたり、水の残量というデータを踏まえた上で節約や調達などの意思決定・アクションに繋げることができたりと、データマネジメントに必要な観点が揃っています。 歴史考証をしていない適当な例ですが。

データ基盤はコストセンターである

データ基盤は単体で売上を出せるわけではないので、ビジネス観点においてはラクをすべき(=過剰実装に力を注ぐべきではない)場面が多々あるのではないか、という旨を述べています。

f:id:yuzutas0:20180620233954p:plain

多くの組織において、データ基盤自体はコストセンターであり、それゆえに組織の予算構造や他のプロフィットセンターの業績に依存しがちです。 この点は、データ基盤の構築・運用・活用において、極めて強い影響力を持つ制約となるはずです。 その制約を踏まえた(あるいは制約自体を乗り越えた)上で、最適なデータ基盤のあり方を設計することになります。

コストセンターのトピックは前提に過ぎず、その上でまずは簡易的なデータ基盤を構築しましたよ、という話に繋がります。 具体的な内容は過去エントリーの通りです。

yuzutas0.hatenablog.com

データ基盤をビジネスのキードライバーに

コストセンターに関して。この手の話は一概に何が正しいとは言えません。 ラクしろとは言うものの、システム設計において中途半端に手を抜くと、あとあとの保守・運用が余計に面倒臭くなります。 データの量・種類・SLAがレベルアップするに従って、一見本質的ではないように見えるシステム設計・運用に、いっそうの工夫が求められるようになります。

もしかしたらコンテキストや組織戦略、解釈の仕方によっては、データ基盤はコストセンターではないのかもしれません。 データ基盤こそが利益の源泉だとステークホルダー全員が断言できるような組織も、世の中を探せばどこかにあるのかもしれません。 だとしたらそれは素晴らしいことです。

そもそもの理想を言うなら、データ基盤に限らず、コストセンターと呼ばれる機能は(というか営利組織におけるあらゆる機能は)「利益の源泉」であってしかるべきです。 直接的には売上を生み出さなくても、間接的には利益創出に寄与しているはずです。 なので、やっぱりその先でどういう価値を創造するかが一番大事なんだろうなぁと思います。 そして、いかにその価値創造を支えるようなデータ基盤を開発・運用するかがキードライバーになりうるのだろうと思います。

まとめ

データ基盤自体はコストセンターに位置付けられるということを認識した上で、担当技術者の1人よがりな過剰実装をするのではなく、ビジネスのキードライバーとなるようにハックしていきたいよね、という話でした。

宣伝

ということで、一緒にやっていくチームメイトを絶賛募集中です。

  • データ基盤の開発・運用におけるベストプラクティスを追求したいSREエンジニア
  • データ活用による業務改善(RPA)で利益創出を目指したいアプリケーションエンジニア・機械学習エンジニア・UXデザイナー
  • データ分析による意思決定でプロダクト開発を支えたいアナリスト・データサイエンティスト
  • データ案件推進やデータ駆動文化の醸成を担いたいディレクター・プロデューサー

我こそはという方がいらっしゃいましたら、ぜひお気軽に@yuzutas0にお声掛けください。

Dama-dmbok: Data Management Body of Knowledge

Dama-dmbok: Data Management Body of Knowledge

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems


  1. 某キーワードで検索すれば出てきますが、あえてリンクは貼らないでおきます。