Databricks登壇資料_aws_startup

Copyright © KAKEHASHI Inc. All Rights Reserved.
カケハシがDatabricksを採用した背景
〜薬局DXを支えるデータ基盤が目指す姿〜
株式会社カケハシ松田健司
2023/02/15 Databricks on AWS Start-Up Day

View Slide

自己紹介

View Slide

松田健司 @ken_3ba
経歴
2014年、新卒でヤフー株式会社に入社。広告配信のための
DMP開発に従事。
2016年、株式会社カケハシに
6人目のメンバーとして入社。薬歴システム
「Musubi」の開発をした後に、開発ディレクターとしてチーム改善に従事。
2019年、薬局経営ダッシュボード「
Musubi Insight」のチームを立ち上げる。
2022年、全社横断のデータ基盤チームを立ち上げ、
7月にDatabricksの導入。

View Slide

アジェンダ

View Slide

アジェンダ
● カケハシについて
● カケハシデータ基盤の歩み、Databricks導入の背景
● Databricks採用の決め手、期待したこと
● Databricks導入により得られた効果
● 今後のカケハシデータ基盤の目指す姿

View Slide

カケハシについて

View Slide


View Slide

テクノロジーで、
薬局をあるべき形に。
全国に、コンビニエンスストアより多い約 6万店が存在する調剤薬
局。その経営や薬剤師の業務、患者さんとの関係性など、薬局の
あり方そのものをアップデートし、薬局 DX（デジタルトランスフォー
メーション）を推進する、独自のプロダクトを展開しています。

View Slide

2016年 2017年 2018年 2019年 2020年
Musubi
正式リリース
シード資金調達
創業
プレSeries A調達
Series A調達
Series B調達
9 億
0.7 億
1.6 億
26 億
2 
6  6  8 
12 
15 
19 
28 
36 
44 
65 
79 
84 
88 
18 億
Extension 調達
9
96 
105 
✔ 創業6年
✔ 累計131億円の資金調達
✔ 社員数314人（2023年1月時点）
2021年
114 
126  126 
130 
153 
314
180 
192 
2022年
214 
* 2022年10月時点
241 
264 
これまでのカケハシの歩み

View Slide

カケハシデータ基盤の歩み、
Databricks導入の背景

View Slide

カケハシデータ基盤の歩み
● 2019年頃、データに基づいた意思決定で各プロダクトの改善を行い、ユーザーによ
り高い価値を届けるために社内のデータ基盤が構築される
2019~2021のデータ基盤アーキテクチャイメージ

View Slide

2019~2021 社内でのデータ活用は順調に進んだ
● 社内データ分析、可視化のケース
○ プロジェクト管理、KPI、NSMの計測
○ ヘルススコアの導出
○ システムのSLA、SLO監視
○ 人事採用進捗、実績の可視化
● プロダクトでの利用ケース
○ 機械学習
○ 事業の実証結果分析
○ BIレポーティング

View Slide

活用が進むにつれて徐々に課題も顕在化

View Slide

顕在化した課題
● 解消し切れていないデータサイロ
○ Redash上でのデータソースを横断したデータのJOINが困難
○ SQLの複雑化、クエリ性能の限界
● データ基盤チームの開発速度と利用側の期待値の乖離
○ エンジニア不足による開発速度低下、溜まり続ける開発依頼チケット
○ 基盤チーム側のドメイン知識の不足
○ 開発時のコミュニケーションコストの増大

View Slide

● 解消し切れていないデータサイロ
○ Redash上でのデータソースを横断したデータのJOINが困難
○ SQLの複雑化、クエリ性能の限界
● データ基盤チームの開発速度と利用側の期待値の乖離
○ エンジニア不足による開発速度低下、溜まり続ける開発依頼チケット
○ 基盤チーム側のドメイン知識の不足
○ 開発時のコミュニケーションコストの増大
顕在化した課題
技術課題：データサイロ
運用組織課題：中央集権的組織構造の限界

View Slide

技術課題：データサイロ
課題解消に向けたアプローチ

View Slide

データサイロ解消へのアプローチ
● 大規模データの分析等に適したクエリエンジンとデータストレージへのデータ統
合が必要
● 専用のデータウェアハウス製品の導入で解決が見込める

View Slide

運用組織課題：中央集権的組織構造の限界

View Slide

● 中央集権的組織構造になる原因
○ データパイプラインの開発オーナーシップを決める上で、技術的な専門性やシステムアーキテク
チャを境界にしている
中央集権的組織構造の改善のためのアプローチ

View Slide

● 初期のデータ基盤立ち上げフェーズで中央集権的組織構造になるのは自然な流れ
ではある
● 一方で急速に進む会社事業の拡大に合わせて増加するデータ活用ニーズに合わせ
て社内のデータ基盤運用組織の拡張性も確保する必要がある
データメッシュの原則を参考にし、ビジネスドメインを境界とした分散オーナーシップ
型データ基盤運用組織を目指す

View Slide

● データメッシュとは
○ データ基盤における中央集権的組織構造の拡張性等の課題解消のために近年登場した概念
● データメッシュの4つの原則
○ Domain Ownership
■ データに対して最も専門性を持つドメインチームが、データの開発オーナーシップを持つ
○ Data as a product
■ データもプロダクトとして管理し、ドメインの内外にいるデータ利用者に高品質のデータを提供
できるようにする
○ Self-serve data platform
■ 各ドメインのデータプロダクトの開発に集中するためのデータインフラが必要
○ Federated computational governance
■ ドメインと中央組織の間で責任範囲を分担したガバナンスの仕組みが必要

View Slide

● カケハシで目指す分散オーナーシップ型データ基盤組織の具体像
○ 各ドメインチームはデータ領域のオーナーシップも持つ
○ データ基盤チームはドメインチームの支援、横断的なマネジメント、ガバナンスに注力

View Slide

● 分散オーナーシップ型の組織で期待すること
○ データ基盤の運用組織としての拡張性を確保
○ 最も専門性を有するドメインチームが開発を担うことで、利用者に向けてより質の高いソリューショ
ンを提供
○ DataOpsの加速
■ データ関連の開発がドメインチームで完結するため、データの収集〜分析〜得られた洞察を
ビジネスに活かすまでの一連のサイクルを高速に回すためのシステムと組織の構造を実現

View Slide

● システムアーキテクチャを最適化する上でも有効
○ ドメインを境界にすることでコンウェイの法則がシステムアーキテクチャに対して良い方向に作用す
る
○ データ品質の本質的な向上施策はデータの最上流からの改善が必要
■ Garbage In, Garbage Out
■ データパイプライン上でオーナーシップが分断されている場合、チーム間のコミュニケーショ
ンコスト、パワーバランス、開発優先度調整等が絡んでくる

View Slide

● カケハシの組織構造とも相性良い
○ 事業ドメイン毎にサービス開発のチームが分割され自走する構造
○ 各チーム内にエンジニア、データサイエンティスト、 PdM、PMM、ドメインエキスパート等、サービスを
開発、運用する上で必要なロールのメンバーが所属
○ データ活用も開発チームに閉じたユースケースが多く、一部では既に実質的にオーナーシップを渡
している部分もある

View Slide

技術面、運用組織面の課題の解決のためには、データ基盤の技術的な刷新、組織構造
の漸進的な変革が必要
分散オーナーシップ組織を前提とした運用が可能かつ、技術課題も解決できるデータ基
盤プラットフォームの導入が必要と判断

View Slide

Databricks採用の決め手、期待したこと

View Slide

Databricks採用の決め手、期待したこと
要約するとDatabricksのアーキテクチャコンセプトがカケハシの要件に合致していた
決め手となった点は：
● データレイクハウスアーキテクチャのメリット
● 強固なデータエンジニアリング組織の実現
● 横断的なデータマネジメントを技術面でサポート
● 分散オーナーシップ型組織の実現をサポート

View Slide

● データレイク〜ウェアハウスまで共通したデータストア・クエリエンジン
● ファイルベースの基盤でSpark Read, Writeを繋げるシンプルなデータフロー
● 未連携のRawデータへのアクセスが容易
データレイクハウスアーキテクチャのメリット
データ基盤のアーキテクチャが非常にシンプルになり、開発コストや運用コストが削減可
能

View Slide

● Databricksの標準機能でデータ基盤を構築可能
○ ETL処理, ワークフローエンジン , BI, 機械学習に至るまでの要素をオールインワンで提供している
ため、基本的に標準機能でデータ基盤を構築可能
○ 自前で各種サービスを組み合わせるケースも減らせる
データレイクハウスアーキテクチャのメリット
データ基盤構築例）

View Slide

● 組織内のスキルを標準化
○ Apache Spark, Delta Lake, MLflow等のOSSベースの機能を会社のデータエンジニアリング、機械
学習における標準技術に
強固なデータエンジニアリング組織の実現
● データエンジニアリングの知見の蓄積・共有による生産性の向上に繋がる
○ 概念レベルでのデータエンジニアリングの知見を全社横断的に共有可能
○ チームを越境したデータエンジニアリソースの流動性を確保
○ 既存人材のデータ領域への進出のための教育コストを削減

View Slide

● オープンな仕様
○ 個人のスキルセットのベンダロックイン回避
○ 組織の開発資産、データのベンダロックイン回避
○ Python、Scalaを操るエンジニアも広くデータエンジニアリングへ招待
○ 採用市場の人材への訴求効果
● 豊富な言語選択肢
○ Notebookの言語をPython, Scala, R, SQLから選択可能
○ 多様なバックグラウンドを持つメンバーが得意な言語で実装可能

View Slide

職種やチームを問わず、データを利用する全員で知見を共有し、強固なデータエンジニ
アリング組織の実現が目指せる！

View Slide

横断的なデータマネジメントをサポート
● 横断的なデータマネジメントの施策が実施可能
○ データ基盤がDatabricks上でほぼ完結でき、メタデータ情報の捕捉範囲の網羅性が高くなる
○ メタデータの情報は網羅性が重要になってくるが、捕捉対象が限定的であったり収集先の対象
が増えるとその分ガバナンスコストが膨れ上がる
各種マネジメント、監視が必要
これらの全てのデータ、処
理、操作がマネジメント対象
になり得る

View Slide

横断的なデータマネジメントをサポート
● 標準機能の充実
○ データカタログ機能や、 Unity Catalogによるデータリネージュの自動収集、統合的なデータアク
セス権限管理の機能は基盤チームの負荷を軽減
○ 開発リソースが潤沢であれば自作したり OSSツールを別途導入するという選択肢もありだが、状
況的に厳しい
データリネージュ例

View Slide

分散オーナーシップ型の組織をサポート
● Workspace環境の分離
○ 個別の開発ドメインチーム単位で環境を分離可能
○ ETL環境を各自のAWSアカウント上にホストし、責任分界点を明確にして自走する環境を提供可能
○ Domain Ownership, Data as a product, Self-serve data platformの面を支援
● Unity Catalogでのデータ共有、アクセス権限の管理
○ 分散したWorkspace間のデータを統合したデータストアとして会社全体で共有できる
○ 個別に環境は分離しているが、データストアに対しては横串でのアカウントの権限の管理が可能
○ データ基盤チームによるガバナンスコストを削減
○ Federated computational governanceの面を支援

View Slide

分散オーナーシップ型のシステムアーキテクチャイメージ図

View Slide

分散オーナーシップ型のシステムアーキテクチャイメージ図
データメッシュ原則
- Domain Ownership
- Data as a product
- Self-serve data platform
-
データメッシュ原則
- Federated computational
governance

View Slide

Databricks導入により得られた効果

View Slide

● データエンジニアの開発効率向上
○ データパイプラインの開発体験向上
○ アカウント発行~権限付与のDevOpsの自動化
○ データアクセス権限の一元管理
● データ・AIの民主化の加速
○ データサイエンティストによる探索的データ分析作業の効率向上
○ データアナリストによる ETL処理の実装
● ガバナンスの強化
○ データオブジェクトの権限管理
● 組織内での知見共有
○ コードベースのモノレポ化の実現
○ 既存設計パターンを他チームでも活用
Databricks導入により得られた効果

View Slide

今後のカケハシデータ基盤の目指す姿

View Slide

● 分散オーナーシップ組織化を漸進的に進める
○ チーム間の責任分界点を明確化
○ 各チーム内で必要なロールの明確化、ロールチェンジ、採用計画への反映等
○ Workspace環境を適切な範囲に分離
■ ※当面はモノリシックな環境で運用予定
● データ基盤チームは横断的なデータマネジメントに注力
○ データ基盤全体向けのガイドラインやポリシーの制定、ドメインチームの開発支援活動に徐々にシ
フト
○ 法務、SRE、情シス等の横断的チームとも協力する体制を構築しガバナンスを強化
○ データ利用者向けのデータ活用の手助け、文化の醸成の活動にも注力
今後のアーキテクチャ、組織設計の構想

View Slide

最後に

View Slide

● Databricksを活用したデータ基盤開発に興味がある方
● ヘルスケア領域のサービス開発に興味がある方
● データエンジニアリングに興味がある方
● カケハシに興味を持っていただいた方
エンジニア絶賛募集中
カケハシ採用サイト

View Slide

Databricks登壇資料_aws_startup

Databricks登壇資料_aws_startup

kakehashi

More Decks by kakehashi

Other Decks in Business

Featured

Transcript