データプロダクト開発の歩み

by 10xinc

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

©10X, Inc. All Rights Reserved. 6 お客様アプリ AIによる推薦や高精度の検索により数万点の SKUからスムーズに買い物ができる UX 主な機能 • 数万SKUから商品からスムーズにカゴを作成 • キーワード・カテゴリ検索・お気に入り・注文変更・購入履歴といった基本機能 • 商品の受け取り方法を選択 • 注文状況・配達状況の確認や通知 • Web(オプションにて提供)

Slide 7

Slide 7 text

Slide 8

Slide 8 text

©2024 10X, Inc. 提供サービス商品・在庫ロジック構築マスタの半自動生成店舗でのお買い物に限りなく近い品揃えを実現半自動の商品在庫マスタ生成プロセスを提供し欠品と運用コストを削減データソース特定データI/F開発アルゴリズム開発日別店別在庫マスタ生成発注データ販売データ廃棄データ販促データ店舗A 店舗B 店舗C 店舗D Stailerとつなぐ I/Fの開発アルゴリズムの開発販促情報発注周期品揃除外 etc. 8

Slide 9

Slide 9 text

Slide 10

Slide 10 text

©2024 10X, Inc. （余談）ネットスーパーについてよく聞かれること 10 >お店で買うより高いんでしょ？ ○ そんなことないよ！昨今の物価価格人件費高騰を受けて値上げしてるところもあるけど、ほとんどは同じ値段だよ >配送料高いんでしょ？ ○ 2024年11月現在、そんなに高くないよ大体300円とか ■ （炎天下、子供連れ、重い荷物を運ぶ苦労と比べると…） >使えるエリア狭いんでしょ？ ○ まだどこでもとはいえないけど意外に使えるよ。特に都心部

Slide 11

Slide 11 text

Slide 12

Slide 12 text

©2024 10X, Inc. 10XはBtoBtoCビジネス 12 10X 小売企業（10Xでは、契約先の小売企業様をパートナーと呼んでいます）ユーザー関連記事: プロダクトビジョンとプロダクト方針の作成 - 10X Product Blog 「1人の難題を巨大な市場から解く。」直接の顧客ネットスーパーやドラッグストア事業を継続的に運営できる手段を提供間接的な顧客日常の買い物負担を減らし、買い物を便利にする使いやすいアプリを作る（toC）だけではなく、直接の顧客である小売企業の複雑な問題を解く（toB） B C B ネットスーパー・ネットドラッグストアの立ち上げと成長を支援便利な買い物手段の提供

Slide 13

Slide 13 text

©2024 10X, Inc. プロダクトチームとその業務領域 13 パートナーデータ Stailer App 売場画面検索・推薦売場チームお客様体験チーム商品データチーム商品データ分析用データ基盤データ基盤チーム決済お会計チーム配送ピックパックお届けチームリライアビリティ＆セキュリティチーム QA チーム品質保証 9チーム約40名のエンジニアで開発店舗関連情報サービス信頼性・セキュリティー店舗チームユーザー店舗所属しているところ。今回はここの話が中心

Slide 14

Slide 14 text

©2024 10X, Inc. （補足）ネットスーパービジネスは何が難しい？1 14 業界的難しさ ● 小売業は薄利多売の業界 ○ 粗利益率が低く投資余力が限られる ○ 特にIT, DX, AIへの投資。先行事例も少ないため意思決定が難しい ● エネルギー価格高騰・円安進行による原価高騰のプレッシャー ● 労働集約的な現場 ○ パートタイムワーカーの依存度が高く、人材力不足が深刻化 ■ 労働生産性改善が急務 ● 一方で、電子決済やセルフレジ等、時代に合わせた対応への圧力も高い ● 日本人の食へのこだわり。サービスへの要求レベルが高い。

Slide 15

Slide 15 text

©2024 10X, Inc. （補足）ネットスーパービジネスは何が難しい？2 15 技術的難しさ ● 基幹システム・データが各社バラバラ ○ そもそもネットスーパーをやる用のデータではない。必要なデータがあったりなかったり。 ■ 場合によってマニュアルデータで補完する必要もある ■ データの種類も量もバラバラ ● 現場判断で売価が常に変化する ○ 臨機応変に売価を柔軟に変更する仕組みが必要。かつそれをどのようにデータマネージするか ● 上記の理由により複雑なデータ変換を行うにもかかわらず、原則、1レコードの間違いも発生させてはいけないというデータ品質への厳しさ ○ ex. 金額を間違って安く販売してしまうと赤字が出る ○ ex. 金額を間違って高く販売するとユーザーから指摘がくる、対応コストがかかる ○ ex. 在庫がないのに販売してしまうとユーザーへ代替え品などの電話連絡をするオペレーションコストが発生する ○ そのような厳密なデータ変換をどのような技術構成で行うか、どのようにデータ品質をモニタリングしたり改善したら良いかのノウハウが少ない

Slide 16

Slide 16 text

©2024 10X, Inc. （補足）ネットスーパービジネスは何が難しい？3 16 現場の複雑さ、それをデジタルへ写像（DX）する難しさ ● ネットスーパーのオペレーションは（愚直にやると）現場への負担が高い ○ 注文された商品のピッキング・パッキング作業コスト、配送コストが必要。ペイできるか？ ● 在庫管理がそもそも難しい。 ○ じゃがいもは箱買いする。そこに何個入っているかはわからない。 ○ 期限が迫った生鮮のいくつかが組み合わさって惣菜に変化したり ○ 不定貫商品の在庫管理をどうするか ○ 電子機器（amazon等）やアパレル（ユニクロやzozo等）は管理コストを払っても採算が取れる。一方で、「白菜一個」の管理を電子タグ等で追跡したいかというと…？ ● 在庫管理の重要さに濃淡がある ○ 日配や缶詰などの賞味期限が違う話 ■ 日配（牛乳・卵などの毎日売れるもの。賞味期限が短いもの）管理する前にさっさと並べてさっさと売る圧力が強い ● 毎日売れて毎日発注するなら厳密な在庫数はわからなくても困らない ■ 缶詰は売れなくても長く棚に並べておく。過剰に在庫は持ちたくないので在庫管理しておきたい

Slide 17

Slide 17 text

©2024 10X, Inc. （補足）不定貫商品 17 ● 重量や数量が変化し、それによって価格も変わる商品のこと ○ 量り売りの肉や魚など ● 単価（gあたり金額） x 量目（内容量）で金額が決定される ● 量目は現場で臨機応変に決まる ○ 肉は決まった重さで切れても、魚は”1匹単位”で売る等 ● 量目によって販売価格が変わるため、在庫管理が複雑になる ○ 520gの鶏肉が1つ、310gの鶏肉が1つ、... と在庫管理する意味はあるか？

Slide 18

Slide 18 text

Slide 19

Slide 19 text

©2024 10X, Inc. データプロダクトとは 19 19 ● Data as a Product / データを製品（プロダクト）のように開発するという考え方 ● その考えで作られた成果物（ソリューション・アプリケーション）がデータプロダクト ● 「製品のように」とは ○ 単なるデータの管理や提供を超え、製品開発に準じた視点やプロセスをデータ管理に適用する ■ 品質保証 ● ex. データに対するテストやモニタリングの実施 ■ 保守性改善 ● ex. データパイプラインの継続アップデート、保守運用 ■ etc…

Slide 20

Slide 20 text

©2024 10X, Inc. データプロダクトの5つのタイプ 20 20 データプロダクトはデータを元にしたソリューション、アプリケーション。昨今はデータの価値発揮先が増えており、故に様々な形態が存在。考えるコスト小大データプロダクト例データを使って最終的な目標を達成することを第一の目的とする製品人間とのインターフェース生データ派生データアルゴリズム意思決定の支援意思決定の自動化データウェアハウスビジネスの主要 KPIを視覚化する企業ダッシュボード自動運転 SQL 可視化 Visualization 車「Data as a Product vs data products. What are the differences?」の内容を図示 , 発表者が一部加筆

Slide 21

Slide 21 text

©2024 10X, Inc. データプロダクトのポジションマップ例 21 21 「Designing Data Products」の内容を図示 , 発表者が一部加筆生データ派生データアルゴリズム意思決定の支援意思決定の自動化 API・コーディングダッシュボード・可視化 webアプリなどデバイス・ハードウェアインターフェースのフレンドリーさ易難考えるコスト小大オープンデータデータウェアハウス経営ダッシュボードレコメンドカーナビなどレコメンド・カーナビなど DeepL翻訳 ML駆動検品システム ML駆動検品システム ML駆動癌検知画像システム ML駆動癌検知画像システム自動運転・石油プラントの最適運転システム

Slide 22

Slide 22 text

©2024 10X, Inc. （余談）プロダクトの方向性生データ派生データアルゴリズム意思決定の支援意思決定の自動化 API・コーディングダッシュボード・可視化 webアプリなどデバイス・ハードウェアインターフェースのフレンドリーさ易難考えるコスト小大オープンデータデータウェアハウス企業ダッシュボードレコメンドカーナビなどレコメンドカーナビなど DeepL翻訳 ML駆動検品システム ML駆動検品システム ML駆動癌検知画像システム ML駆動癌検知画像システム自動運転石油プラントの最適運転システムソフトウェアビジネス化 AIビジネス化 22 「Designing Data Products」の内容を図示 , 発表者が一部加筆「何も考えなくても簡単に扱える」方向へ。これはデータプロダクトでも変わらない

Slide 23

Slide 23 text

Slide 24

Slide 24 text

©2024 10X, Inc. 商品データチームがつくっているデータプロダクト（の生成物） 24 商品カテゴリーセールス種類商品画像商品名金額（税率）当該店舗の在庫数量商品説明文「商品データ」と呼ばれるどの商品が、いつ、どの店舗に、いくらで、何個あるかを　全パートナー、全店舗、全商品で、毎日生成🛒 1店舗だけで数万種類の商品！関連記事: ネットスーパーの要!?あなたの知らない「商品マスタ」の世界 - 10X Blog

Slide 25

Slide 25 text

Slide 26

Slide 26 text

©2024 10X, Inc. （補足）dbt; data build tool とは 26 ● データエンジニアリングやデータ分析のプロセスを効率化するために設計されたOSS ● 主にデータウェアハウス上でのETL（Extract, Transform, Load）プロセスの中で、特に「T（Transform）」の部分を担う ● 同じチームの @takimoさんが日本コミュニティーの立ち上げと運営を行っている with hoge as (...), fuga as (...), …. 以後50個くらいのCTE句 1000行くらいの.sql🤮🤮🤮 source_1 source_2 source_3 logical_a logical_b mart_x dbtならデータソースの処理層クレンジングやロジックの処理層完成品のデータマート層 - モデルとして関係性を表現（データモデリング）でき、かつモデル感の依存関係も自動で可視化 - モデルごとにテストを実施し、データやロジックの妥当性の検証も可能 - gitで管理できる例えば、関連記事: dbt日本コミュニティの立ち上げと10Xでdbtの実践を行った2022 - SpeakerDeck dbtを使ったELTデータパイプライン構築と運用事例 - SpeakerDeck

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

©2023 10X, Inc. データ処理 by パートナー個社データ（input）商品データ（output）ユーザー Stailer App （Dart）アプリに載せる・・・ A社基幹データ X社基幹データ A社商品データ X社商品データ Data Product （BigQuery with dbt） X社のネットスーパーアプリ ① 商品・在庫数等のデータを受領して ② dbtで整理・変形・計算 ③ 整理された商品データを出力商品データチームのデータプロダクト超概要

Slide 30

Slide 30 text

©2023 10X, Inc. データ処理 by パートナー個社データ（input）商品データ（output）ユーザー Stailer App （Dart）アプリに載せる・・・ A社基幹データ X社基幹データ A社商品データ X社商品データ Data Product （BigQuery with dbt） X社のネットスーパーアプリ ① 商品・在庫数等のデータを受領して ② dbtで整理・変形・計算 ③ 整理された商品データを出力 ④ データをアプリに載せる商品データチームのデータプロダクト超概要

Slide 31

Slide 31 text

©2024 10X, Inc. dbt部分をもう少し詳しく 31 10X BQ （source data）基幹データマニュアルデータ gateway doman service application DataYard（と呼んでいる） DataExpress（と呼んでいる） input Data Product output 各パートナー独自の要件を吸収するレイヤーネットスーパー構築に必要なドメインデータをここで作るどんなデータをどんな粒度で作るかがポイントドメイン層以降は全パートナーで共通の処理を行い商品データを完成させる dbtで４つのレイヤー構造を作り、開発の効率化を行っている。アプリで表示するためにFirestoreに格納

Slide 32

Slide 32 text

Slide 33

Slide 33 text

©2023 10X, Inc. 生データ派生データアルゴリズム意思決定の支援意思決定の自動化 API・コーディングダッシュボード・可視化 webアプリなどデバイス・ハードウェアインターフェースのフレンドリーさ易難人間の考えるコスト小大オープンデータデータウェアハウス企業ダッシュボードレコメンドカーナビなどレコメンド・カーナビ DeepL翻訳 ML駆動検品システム ML駆動検品システム ML駆動癌検知画像システム ML駆動癌検知画像システム自動運転・石油プラントの最適運転システム dbtによるスケーラブルなデータ処理パイプライン推薦アルゴリズム等「Designing Data Products」の内容を図示 , 発表者が一部加筆（余談）10X商品データプロダクトのポジション

Slide 34

Slide 34 text

©2023 10X, Inc. データ処理 by パートナー個社データ（input）商品データ（output）ユーザー Stailer App （Dart）アプリに載せる・・・ A社基幹データ X社基幹データ A社商品データ X社商品データ Data Product （BigQuery with dbt） X社のネットスーパーアプリ ① 商品・在庫数等のデータを受領して ② dbtで整理・変形・計算 ③ 整理された商品データを出力 ④ データをアプリに載せる 10X商品データプロダクトの特徴作成したデータがほぼそのままユーザーに提示されるところ（プロダクションに直結している！！） 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

©2024 10X, Inc. この章のまとめ 36 36 ● データプロダクトと呼ばれる新しい開発領域について概要説明 ● 10Xではデータプロダクトとして「商品データ」を作成している ● 商品データのデータプロダクトでは、dbtでレイヤ構造化させたデータモデリングを行っている ● このパイプラインで作成したデータはプロダクションに直結している ● 商品データは直接ユーザーが触るものであり、間違いがあるとパートナー（小売企業）にも損害がでるため非常にシビアである

Slide 37

Slide 37 text

Slide 38

Slide 38 text

©2024 10X, Inc. パートナーローンチの歴史 38 2020 2022 サイトコントローラーによる操作アプリケーションコードの中でSQL 実行データモデリングでの実装 dbtで実装 DataExpress世代 38 Stailer native 第4世代サイトコントローラー時代 Stailer native 第1世代 Stailer native 第2世代 Stailer native 第3世代 DataExpressの誕生 ※ドラッグストアは紫枠 2021 2023 アプリのリリース時期でマッピング

Slide 39

Slide 39 text

©2024 10X, Inc. 最初はサイトコントローラーから始まった 39 39 2020 2023 2021 2022 データ受領は行っておらず、サイトコントローラーによって先方サービスを操作。商品データは作成していなかった。 ● 10X社の最初のサービス”タベリー”（現在はサービス終了）では、献立の提案をし、その食材を小売流通企業のネットスーパーでシームレスに注文できた ● 当時、ネットスーパーへの注文はサイトコントローラーで行われており、10Xが直接データをもっていたわけではない ● アプリリリースの了承を取るために小売流通企業に訪問。タベリーのシステムを評価され、公式のネットスーパーアプリ作成を正式に受注 ○ これが現在のStailerへ繋がるサイトコントローラー時代 https://x.com/tabelyapp 関連記事: タベリーからStailerへ - 10X Blog

Slide 40

Slide 40 text

©2024 10X, Inc. （補足）サイトコントローラーとは 40 40 ● Stailerアプリで操作すると、裏側で公式のweb画面を操作して買い物を完了させる仕組み ● スクレイピングは情報収集、サイトコントローラーは操作・管理が目的 ○ スクレイピングと違って、直接決済まで行うところなどが大きな違い ● 代表的なものは宿泊予約まとめサイト、飛行機価格比較サイトなど ● 操作先のサイト構造が変わると動かなくなるので大変 https://everyday-fresta.jp/ パートナー公式のwebサイトに対し、 10Xがサイトコントローラーで決済まで操作するという仕組みだった

Slide 41

Slide 41 text

©2024 10X, Inc. 基幹データを受領し、Stailer nativeで駆動 41 41 2020 2023 2021 2022 当時はDartコードの中でSQLを実行し商品データを操作していた（の仮サンプル） ● 初めてのstailer nativeへ ○ サイトコントローラーではなく、パートナー（のベンダー）から基幹データを10X GCPへデータ連携してもらい、そのデータを処理してStailerを動かす ○ 100店舗分を超えるデータ量を捌く必要があった ● スーパーだけではなくドラッグストアでもStailerを展開 ○ 医薬品のネットでの販売ルールなど、新たな専門知識が必要になる Stailer native 第1世代

Slide 42

Slide 42 text

©2024 10X, Inc. （補足）StailerはFlutter（Dart）で動いている 42 42 ● StailerはFlutterというモバイルアプリ用のフレームワークで開発されており、FlutterはDartで書く ● Flutterは iOS/Androidの両方にコンパイルできるメリットがある ○ OS毎に開発チームを作らなくて良い。開発者が少ない組織にはメリット関連記事: 「なぜDartなのか」CTO石川が技術選定に込めた想いとその背景 - 10X Blog

Slide 43

Slide 43 text

©2024 10X, Inc. dbtを採用し商品データ作成ロジックを分離する 43 43 2020 2023 2021 2022 ● 通常、データ変換をそれほど行わない場合はアプリケーションコード（10Xではdart）の中でSQLを書いてデータを呼ぶことはそれほど珍しいことではない（らしい） ● 商品データ作成に複雑なデータ変換が必要となることを当時は予期していなかった ● SQLでのデータ変換に加え、Dartでも一部データ変換のロジックを作っていたので至る所でデータ変換ロジックが散らばり、この後、変更・保守が難しくなっていった ● これを改善するため、商品データ作成部分の実装を Dart + SQL から dbt に変更 ○ 商品データに関するデータ変換は dbt にロジックを寄せる ○ dbtが作成したデータマートを Dart は呼ぶだけにした（Dartでのデータ変換は行わない） ● dbtが生成したデータがサービスプロダクションに直結している（直接ユーザーが触るデータになる）はまだ事例が少ない Stailer native 第2世代これまでの実装の知見を生かしつつ開発を進めるが、まだ各パートナー毎にスクラッチで作っていた

Slide 44

Slide 44 text

©2024 10X, Inc. データモデリングの導入 44 44 2020 2023 2021 2022 Stailer native 第3世代 gateway, domainなどのレイヤー構造の採用開発者を増やすのではなくモデリングを洗練させる方針へ ● パートナー実装を繰り返すことで、ネットスーパーで求められる共通機能がわかってきた（ドメイン知識が溜まってきた） ● それを生かしてパートナー共通のドメインを定義し、データモデリングを始める ○ gateway層やdomain層ができ始める ● ドメインが定まることでパートナーに請求すべき受領データも定まってきた ○ 無秩序に基幹データを受領するのではなく、実現したいロジックを元に事前にパートナー側（のベンダー）にデータを作成してもらいそれを10Xが受領することで下流での複雑な変換を減らす ○ 体感で従来の1/10くらいの労力でローンチできるパートナーが出始める

Slide 45

Slide 45 text

©2024 10X, Inc. dbt部分をもう少し詳しく 45 10X BQ （source data）基幹データマニュアルデータ gateway doman service application DataYard（と呼んでいる） DataExpress（と呼んでいる） input Data Product output 各パートナー独自の要件を吸収するレイヤーネットスーパー構築に必要なドメインデータをここで作るどんなデータをどんな粒度で作るかがポイントドメイン層以降は全パートナーで共通の処理を行い商品データを完成させる dbtで４つのレイヤー構造を作り、開発の効率化を行っている。アプリで表示するためにFirestoreに格納ここができた再掲

Slide 46

Slide 46 text

©2024 10X, Inc. DataExpressの誕生とローンチの高速化 46 46 2020 2023 2021 2022 ● ドメインの理解が深まってきた。処理を更に抽象化し、パートナー共有処理部分は社内パッケージ化した（”DataExpress”と命名） ○ ドメイン層ができれば後はDataExpressに流すだけになるまで実装が効率化。 ○ DataExpressをパッケージバージョン管理し、プラットフォームとしての機能はここに入るようにする ● 受領データフォーマットを作成し、データ受領工程の圧縮 ● ここまでの改善の成果として、半年ほどで一気に6パートナーをリリースできるまでに Stailer native 第4世代 DataExpressの誕生

Slide 47

Slide 47 text

©2024 10X, Inc. パートナーローンチの歴史 47 2020 2022 サイトコントローラーによる操作アプリケーションコードの中でSQL 実行データモデリングでの実装 dbtで実装 DataExpress世代 47 Stailer native 第4世代サイトコントローラー時代 Stailer native 第1世代 Stailer native 第2世代 Stailer native 第3世代 DataExpressの誕生 ※ドラッグストアは紫枠 2021 2023 再掲

Slide 48

Slide 48 text

©2024 10X, Inc. この章のまとめ 48 48 ● 最初期はサイトコントローラーによって商品購入を実現していた ● データが受領できるようになり、Dart + SQL で商品データを作成していた ● ロジックが複雑化したため、dbtを導入し、商品データロジックとアプリケーションコードを分離した ● 複数パートナーのローンチを繰り返すことで、必須の機能/個別のニーズがあぶり出されていき、ドメイン知識が蓄積された。 ● それを元にデータモデリングが進み、処理が抽象化されることで開発効率が上がった ○ DataExpressという共通処理パッケージも作成 ● 現在は13パートナー様の商品データパイプラインを運用・改善していっている

Slide 49

Slide 49 text

Slide 50

Slide 50 text

©2024 10X, Inc. パートナーローンチの歴史 50 2020 2022 サイトコントローラーによる操作アプリケーションコードの中でSQL 実行データモデリングでの実装 dbtで実装 DataExpress世代 50 Stailer native 第4世代サイトコントローラー時代 Stailer native 第1世代 Stailer native 第2世代 Stailer native 第3世代 DataExpressの誕生 ※ドラッグストアは紫枠 2021 2023 2024年以降は？再掲

Slide 51

Slide 51 text

©2024 10X, Inc. 必ずぶち当たる”品質”問題 51 51 ● ローンチラッシュを超える ● それにより10を超えるパートナーの運用と保守が始まる ● 各パートナーからの問い合わせが開発チームに寄せられる ○ 商品データの価格 / 在庫数が期待と違う ○ 売場に出てほしい商品がない / 期待外の商品が出ている ○ マニュアルデータを入稿したら意図しない状態になった etc ● バグ修正も、業務委託メンバーからのPRレビューも追いつかない ● 直しても他のところが壊れる...直してもデグレ直してもデグレ直しても...

Slide 52

Slide 52 text

©2024 10X, Inc. なぜそんなことになったのか 52 52 ● スタートアップでは「リリースすること」が至上命題になりがち ○ リリースしないことには何も始まらないから ○ サービスを動かしてキャッシュインを早めないとキャッシュがなくなるから ○ パートナーからの期待とプレッシャー。「動くものを早く見たい」「可能な限り早くリリースしたい」 ○ サービスを動かすことで改善のPDCAを回す思想 ● 故に、「チームで」というより「各個撃破」スタイルで仕事を最短で完了させるスタイルになる

Slide 53

Slide 53 text

Slide 54

Slide 54 text

©2024 10X, Inc. （余談）スタートアップと一人一殺開発の引力 54 54 ● スタートアップが行うプロダクト開発では、世の中にまだ「だいたいこれが正解」というプロダクトがない ● その場合、「何を作るべきか」「どう作るか」を作りながら理解する側面が強い ● 「早く探索する」「動くものを作る」ことが最優先の現場と ”一人一殺開発” は相性が良い ○ いい意味でプロフェッショナルなシニア人材の自律性をフルに使う

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

©2024 10X, Inc. 57 全員が別々のことをやっているので、お互いが順調なのか遅れているのか分からない進捗確認は、「間に合いそうか」「依頼されたバグは直ったか」のみ振り返りも「お互い大変だね」とねぎらう場になり共通の学びが得られづらい朝会も振り返りも欠席者が増えるスクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines - Speaker Deck 一人一殺の先に待っていたチームの状態

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

©2024 10X, Inc. プロダクト品質を改善するには？ 64 64 - 属人的な解決方法ではプロダクトはスケールしない。チームで問題を認識し、継続的な改善アクションを中長期のスパンで積み重ねないとスケールしない - 我々のチームにおいては、 - 「実装者しか知らない知識」を如何にして「チームの知識」にするか - 「実装した人がそのパートナーの担当」という「実装者の持ち物化してしまったもの」を如何に「チームの持ち物」にするか - ソフトウェア開発の文脈では「スクラム開発」という便利な方法論がすでに存在している - どのようにチームのタスクを決定するか - どのようにチームの進捗を管理するか - どのようにチームとして知見を得てoutcomeに繋げるか - チームにユビキタス言語の浸透、開発のコンテクストの浸透をどのように行うのか - どのようにチームで反省し、次に活かすサイクルを作るか - etc… - スプリントを減る事に改善のサイクルを回し、継続的に良い開発チームになっていく方法論やメンタリティーのプラクティスが転がっている

Slide 65

Slide 65 text

Slide 66

Slide 66 text

©2024 10X, Inc. ● データ活用の下流側のタスクが主領域 ● プロジェクト型の仕事（短期~中期）が多い ● データから導き出されるインサイトが成果物 ○ 集計可視化、レポーティングなどでデータ活用を推進し現場を動かす系タスクも多い ○ 特定期間内、特定用途向けのデータを対象とすることが多い ■ 一旦既存システムとは独立した状態を仮定することが多い ○ （PJ型の性質上）中長期先まで同じ利用できることはフォーカス外とすることが多い ■ 故にテスト実施、品質保証もフォーカス外となることが多い ● プロダクト開発/スクラム開発とは対象とする開発期間も、目指すものも、関心事も大きく異なる。 ○ 別の文化圏の仕事の進め方を経験してきたメンバーたち ● 輪読会をして知識をつけたり、意見交換して考え方をアップデートしたり頑張るデータアナリスト/サイエンティスト職種の仕事範囲 66

Slide 67

Slide 67 text

©2024 10X, Inc. チームの課題 ● チームの状況をうまく同期する仕組みをもっていない ○ 朝会はいちおう集まりはするが... ● タスクの優先順位が（チームに）ない ○ 問い合わせが来た順、声の大きい順に対応 ● 属人的に実装したため、実装の詳細を互いに知らない ○ ドキュメントも乏しい ● 実装の複雑化 ○ （一定のルールはありつつも）各パートナー毎に個別に実装したためパートナーごとの特別なロジックが存在 ● プロダクト開発を行う能力がチームに足りていない ○ メンバー間にスキルギャップがある

Slide 68

Slide 68 text

Slide 69

Slide 69 text

©2024 10X, Inc. スクラムのイベントを週次で実施しチームを同期させる ● スプリントプランニング（1週間のタスク決定）:1h30min ○ 次の一週間でチームでどのタスクをやるかを決定 ○ 着手可能な粒度まである程度タスク分解する ● デイリースクラム（朝会）:毎日20min ○ 昨日なにをしたか、今日誰が何をするかの宣言 ○ なにか困り事がないかの確認 ● スプリントレビュー（一週間の成果報告会）:1h ○ どんな成果物ができたかをチームに共有 ● スプリントレトロスペクティブ（一週間の反省会）: 45min ○ 今週を振り返り、チームで次の一週間に活かせる反省がないかを対話 ● リファインメント:（チームのtodoリストの整理） 1h ○ チームのタスク一覧（プロダクトバックログアイテム）を見直し、優先度を並べ直す ○ 直近で取り掛かるタスクについてどれくらい工数が必要かを見積もる ■ 不確実性が高く見積もれない場合、巨大な工数が必要な場合は原因を取り除くアクションを洗い出す

Slide 70

Slide 70 text

Slide 71

Slide 71 text

©2024 10X, Inc. プロダクトバックログアイテムを作る ● チームが持っているタスク一覧を優先度順（取り組む順）に並べたもの（=プロダクトバックログ）を作成 ● チームにPO（プロダクトオーナー）を立て、POが主に優先度を決定する ○ 故に、POはチーム外の関係者とも密にコミュニケーションをとり、チームが受けるべきタスクを決定し、バックログアイテムに順位付きで追加する ○ そのために、チームの状態（稼働状況や抱えている課題）をチーム外に適切に共有する必要もある ● チームメンバーはバックログを見て上から順にタスクを解決する ● プロダクトバックログができることで、問い合わせされた順に対応することなく、今チームがやるべきことに集中して対応することができる ● プロダクトバックログベースでチーム外とタスク調整の会話をすることができる（XXを今やる選択をするなら、代わりにYYができなくなるけどいいか？等） ○ これにより、「いまチームには保守性向上が必須である」ことを全社に訴え、優先タスクとして保守性向上に関するタスクをチームが取り組める段取りができた（=保守性以外のタスクが後ろ倒しになることを合意できた）

Slide 72

Slide 72 text

Slide 73

Slide 73 text

©2024 10X, Inc. 銀の弾丸はない。愚直に毎日コツコツ改善 ● 属人的に実装したため、実装の詳細を互いに知らない ○ → ドキュメントの補強, データソースのSSOT化 ○ → ペアプロ・ペア作業などで実装の解説、理解深堀り ● 実装の複雑化 ○ → 全パートナーのロジックを洗い出し。共通の処理, 課題を網羅 ■ → 処理をパターン化しリファクタリングしていく ■ → モデリングを見直してリファクタリングしていく ○ → testの導入。小さくテストし、”安心できる部品”を積み上げる ○ 自動チェックの仕組みを増やし、安心できる開発体制を整えていく ● プロダクト開発を行う能力がチームに足りていない ○ → スクラムイベントを通じて作業や知識の同期 ■ 有識者の考えていることを聞いて「無知の知」を知る, 反省会を通して仕組みを改善させる ○ → ペアプロ・モブプロなどで同期作業。知識移転 ■ → 「コードを読む会」の実施, 輪読会の実施 ○ →チーム出社日を増やし、密度をあげる

Slide 74

Slide 74 text

©2024 10X, Inc. 74 ● 我々のチームにおいては、「プロダクトバックログの作成」が大きかった気がしている ○ チームがやるべきことを明確になり同じ方向を向けるようになった、集中できるようになった ○ チーム外と会話できるようになり、組織横断で課題感を共有できるようになった ■ （経営層とも課題認識を揃えることができたが、これはCTOが組織にいる影響もあるかも） ○ 一人一殺の断片的なインクリメント（成果）ではなく、開発/改善がチームとしての「積み上がる成果」になった ○ 重要度の高い属人的なタスクが可視化され、それを解消するために議論されるようになった ■ 議論する中で、「データプロダクトは “ソフトウェア開発だったんだ”」と発見した（何を今更と思うじゃろ？: 続く）スクラムを導入し、特に価値を感じていること

Slide 75

Slide 75 text

Slide 76

Slide 76 text

©2024 10X, Inc. なぜこの開発が”ソフトウェア開発”であると気づくのに遅れたのか？ 76 76 （ここまでの振り返り） ● dbtの開発ではSQLをゴリゴリ書きまくる↓ ○ SQLを書くのが得意なデータアナリスト系の人がチームに集まる↓ ○ 実際に触っているのはBQとSQLのみなので、データアナリティクスの領分と思える↓ ● 実際に動くdbtパイプラインは作れるので、リリースまでは到達できる↓ ● リリースすると次は品質が問題になる ○ 品質改善のためには多くのソフトウェアエンジニアリングのスキルが必要であると気づく ■ スクラム、テスト、CI/CD, 障害対応 etc ● 扱う対象は「データ」であるものの、使うスキルの大部分はソフトウェア開発の方法論と被ることに気づく ○ 「あっ、データプロダクト開発は”ソフトウェア開発”だわ」 ○ 実際はそれに加えて、効果的なdbtパイプライン設計のために「データモデリング」の知識も必要になる

Slide 77

Slide 77 text

©2024 10X, Inc. （余談）間抜けだったのか？ 77 77 「SQLを書くからデータアナリストが必要」は誤算だったのか？そうは思えない。 ● まだ「正解」がないものを手探りで作っていくフェーズだった ○ 最初は開発の設計図もないところからBizDevと相談しながら手探りでパートナーが欲する機能を作っていった。型化・共通化・抽象化よりも、まずは動くコードを作って提供することが至上命題。道を切り開いた。 ■ データの活用（実装）がまずあって、その後に問題に気づくことができる。 ■ 他のデータ職種ができないとはいわないが、データアナリスト趣向の人のほうが燃えるシチュエーションぽい。アドホックに立ち回る役目として一定は状況にﬁtしていた

Slide 78

Slide 78 text

©2024 10X, Inc. dbtというゲームチェンジャー 78 78 ● dbtという新しい道具がソフトウェア開発文化をデータ領域に持ち込んだのも大きい ○ 「データ処理文脈でSQLを書いていたら、気づけばソフトウェア開発に足を突っ込んでいた」状態 ● SQLはデータ分析の道具の色が濃かった。しかしdbtの登場によってSQLでもプロダクト開発ができるようになりソフトウェア開発の色を濃くした。 ○ そのときにより重要になるのはアドホックでクイックな黒魔術的な高度なSQL技術ではなく、「ソフトウェア開発」を強く意識したコーディング技術だった ■ 保守運用しやすいコード ● 第三者にも意図が透けて伝わる関数命名、CTE句単位 ■ テスト実施単位での疎結合化 ■ ユビキタス言語やコンテクストマップの意識。ドメイン駆動開発 ■ etc…

Slide 79

Slide 79 text

©2024 10X, Inc. 現在の開発体制 79 79 現在は、データエンジニア・ソフトウェアエンジニアを中心にソフトウェア開発のお作法でデータプロダクト開発をおこなっている ● データプロダクト開発として、次のステージに来ている感 ● これまで獲得した知識を使った「保守性改善」と「プラットフォーム機能強化」に注力 ○ データプロダクト領域とつながる部分のインターフェース定義（Data Contract） ■ データプロダクトへのinputデータの再定義 ■ データプロダクトからのアウトプットデータの再定義 ○ DataExpressの開発を通じたプラットフォーム機能追加 ■ 「プラットフォームとして提供すべき機能」「プラットフォームの外で作る個別機能」の考え方をブラッシュアップ ○ 保守性改善のための開発体験の向上、ドメインの再考、レイヤリングの再考関連記事: 【Stailerの現在地】保守性改善からプラットフォームの道へ - 10X Blog

Slide 80

Slide 80 text

©2024 10X, Inc. ここまでの振り返り 80 80 ● ベストプラクティスがなかった、ローンチすることが至上命題だったフェースではゴリゴリと目の前の要望を叶えていくデータアナリストが道を切り開いていった ● そこを超えると、今度はプロダクト品質が問題になった ○ スピードとのトレードオフで起こる問題 ○ 解決できないとパートナー解約にも繋がるため死活問題 ● しかし問題は明確だった。スクラムでその問題を少しつづ改善していく ○ 中長期を目指したチーム構築を目指して開発体制、やり方論を一新する必要がある。ここで分解せずにうまくピボットできるか。 ■ データアナリスト的文化から、ソフトウェア開発文化へのシフト ● （可能不可能以前に、そのキャリアを目指したいかという個々人の問題もある） ● ゼロから「データプロダクト開発」をするなら、似た道を辿るかもしれない

Slide 81

Slide 81 text

©2024 10X, Inc. データプロダクト開発に必要なスキル？ 81 81 データ生成から活用までのプロセスにおいて、5つのデータ職種が主戦場としてそうなところ（主観含む）データ収集・整備基盤構築分析モデル構築モデル運用・改善 ①データエンジニア ②アナリティクスエンジニア ③データアナリスト ④データサイエンティスト ⑤MLエンジニアそして、データプロダクト開発に必要となるスキルは①と②の間の子、もしくは両方くらい？（現実の業務では前後に染み出ることが多いし実際に重なるところが多いので区別にあまり意味はなさそうだが。）上流下流

Slide 82

Slide 82 text

Slide 83

Slide 83 text

©2024 10X, Inc. 10Xの２つのデータチームの違いってなんだろう？ 83 83 ● ところで、10Xにはデータ活用・BI提供を行う「データ基盤チーム」と、これまで紹介してきた商品データのデータプロダクトを開発する「商品データチーム」がある ● 2チームの必要なスキルセットはほとんど同じ ○ SQL、データモデリング、ETLツール、クラウドプラットフォーム ● 根本的に何かが違ったりしているのだろうか？（とふと思ったので考えてみた）データプロダクトダッシュボードデータ基盤 hoge “データ基盤”と”データプロダクト”の関係は世の中的には何となくこんなイメージ？ “データ基盤”の中にいろいろ入っている感じ？「データ基盤チーム」については以下を参照関係記事: 10Xでのデータ基盤の変遷とこれから - speakerdeck

Slide 84

Slide 84 text

©2024 10X, Inc. 84 84 10Xにおけるデータプロダクトとデータ基盤の立ち位置基幹データデータプロダクト商品データ app データ（売上データ・行動ログ等）データ基盤 Stailer App 分析レポート BI 参考: データガバナンスチームの結成で得た学び - speakerdeck データプロダクト（商品データチーム）データ基盤（チーム）価値の提供先プロダクト（Stailer） - 各パートナー担当者 - 10Xのグロース担当者提供する価値売場構築に必要な商品データを、より厳密に、安定的に供給する売上状況データを可視化・分析し、より正確に、より早く意思決定できる環境アウトカムプロダクトの正常稼働インサイトを得ることによるビジネスの駆動確かにいろいろ違いそう

Slide 85

Slide 85 text

©2024 10X, Inc. データプロダクトのポジションマップ例 85 85 「Designing Data Products」の内容を図示 , 発表者が一部加筆生データ派生データアルゴリズム意思決定の支援意思決定の自動化 API・コーディングダッシュボード・可視化 webアプリなどデバイス・ハードウェアインターフェースのフレンドリーさ易難考えるコスト小大オープンデータデータウェアハウス経営ダッシュボードレコメンドカーナビなどレコメンド・カーナビなど DeepL翻訳 ML駆動検品システム ML駆動検品システム ML駆動癌検知画像システム ML駆動癌検知画像システム自動運転・石油プラントの最適運転システム再掲

Slide 86

Slide 86 text

©2024 10X, Inc. 86 86 アウトプット観点でのデータプロダクトポジションマップデータ品質要求が厳しい比較的厳しくない価値の提供先がシステム価値の提供先が人 - 経営ダッシュボード - 癌検知システム - 機械翻訳 - レコメンドエンジン - カーナビ - アドホックな分析ダッシュボード - 自動運転 - 食品検品システム - （プロダクションに乗るデータ）（品質が良くない初期のシステム向けデータプロダクト）人命や企業赤字に繋がるもの ① ② ③ ④ 関係 ● ①と②の関係 ○ ”インサイト”を人に与えることが価値 ○ コストが見合うなら①へ移動 ● ③と④の関係 ○ プロダクトの稼働が価値 ○ 開発初期は④から始まり③へ進む圧力が生まれる ● ③の特徴 ○ バージョンアップによる性能向上が競争力になるためソフトウェア開発の色が濃い ○ データ品質、プロダクト品質ともにシビア ● ①②③に優劣関係はなく、目的に応じて必要な手段を選ぶ「誰に提供するか」、「どのくらいのデータ品質を求められるか」で分けると、

Slide 87

Slide 87 text

©2024 10X, Inc. 87 87 データ品質要求が厳しい比較的厳しくない価値の提供先がシステム価値の提供先が人 - 機械翻訳 - レコメンドエンジン - カーナビ - アドホックな分析ダッシュボード - 自動運転 - 食品検品システム - （プロダクションに乗るデータ）（品質が良くない初期のシステム向けデータプロダクト） ① ② ③ ④ ● 商品データチームは③の領域を、データ基盤チームでは①②の領域を扱っている　という棲み分け ○ （この2軸で分けた場合はそういう違いになる） ● このため、スキルセットは近いものの、扱うデータの種類も、開発手法も異なる。 ● それぞれが重い仕事なので別チームになっている人命や企業赤字に繋がるもの - 経営ダッシュボード - 癌検知システム 10Xでは③チームと、①②チームに分かれている

Slide 88

Slide 88 text

Slide 89

Slide 89 text

©2024 10X, Inc. 89 1. 10Xのビジネスについて ○ ネットスーパー立ち上げのBtoBtoCモデル。売上連動のビジネスモデル 2. データプロダクトとは ○ Data as a Product / データを製品のように開発するという考え方のプロダクト開発領域 3. 10Xのデータプロダクトとは ○ 「商品データ」を作るデータプロダクト開発。プロダクションに直結しているためシビア 4. データプロダクト開発の歩み ○ データパイプラインのアーキテクチャとモデリング進化の歴史 5. データプロダクトと品質 ○ プロダクト品質問題への発生。一人一殺開発の功罪。 6. プロダクト開発とスクラム ○ データチームにおけるスクラムの導入。品質改善への取り組み、 7. データプロダクトとスキルセット ○ データ分析文化からソフトウェア開発文化への体制変更 8. データプロダクトとデータ基盤 ○ 10Xにおける２つのデータチームの違いこのスライドの一行まとめ