ネットスーパーにおける商品在庫データのアプリケーション構築事例

by 10xinc

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

Slide 7

Slide 7 text

©10X, Inc. All Rights Reserved. なぜ商品在庫データを作る必要があるのか？  7   通常EC  店舗型ネットスーパー   品揃え  数十〜数百  数万点  在庫数の管理  倉庫の入庫数と販売数で管理が可能  基本的に日次での残在庫数等は数値管理していない場合が多い（生鮮系や賞味期限が短いものは売り切りが基本）   金額  あまり変わることはない   チラシ価格や特売等、日単位で同一商品で変化する  ● 日々変化する「金額」と取り扱う「商品数の多さ」から厳密な在庫数確認が困難で、人的な対応も限界がある  ● Stailerでは店頭在庫数を自動で推定し、ネットスーパーの在庫データとして提供している  

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

©10X, Inc. All Rights Reserved. 2021年前半　爆誕期  ● 社内ではDWHの構築のためにdbtの導入が進んでおり、 dbtを使える人が増加  ● 外部パートナーから提供されるデータから商品在庫データを生成する必要性が出る   ● データ内容の理解の難しさや変換処理の設計難易度、プロダクトエンジニアのリソース的な観点もあり、「データ変換処理」をdbtで実装するためのチームが組成された  ● ファーストリリースがされる🎉  10 商品在庫データの歴史

Slide 11

Slide 11 text

©10X, Inc. All Rights Reserved. 2021年後半　拡大期  ● 嬉しいことに様々なパートナーにお声をかけて頂き、 dbtを使った商品在庫データの生成パイプラインは増えた  ● パートナーごとに保有しているデータ仕様が異なりがあったが、開発ガイドライン（初期）を策定し、一定の変換対応ができればサービスを提供できるようになっていた   ● dbtを採用した事により開発に携われる人の採用職種の幅を出すことができ、機動的に開発チームを増員していくことが出来た   11 商品在庫データの歴史

Slide 12

Slide 12 text

©10X, Inc. All Rights Reserved. 2022年前半　戦乱期  ● 個社毎に作ったパイプラインにも問題がで始める 🔥  ● 複雑に入り組むリネージ  ● 同じような処理ロジックが様々なところに＆下流に様々なロジックが混在しやすくなってしまっていた  ● また属人的に開発をする必要が高く、キャッチアップコストも高い状態に   ● 修正をしたりする開発難易度や品質確認のためのQA工数も高くなってしまった   ○ リネージが複雑でデータの流れを追うのが大変だったり、抽象度が荒いので様々なテーブルの確認が必要等  12 商品在庫データの歴史

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

©10X, Inc. All Rights Reserved. どういうモデリング、アーキテクチャにすべきか検討  ● DRY（SSOT）を実現し、計算ロジックをテスト出来る状態にすることが必要命題   ● 様々な開発手法のアプローチやモデリングを検討した   ○ dbtのベスプラ（staging, mart）  ○ ディメンジョンモデリング（fact, dimension）  ○ 他の開発手法であるMVCやDDD（ドメイン駆動設計）等  ● 最終的にドメイン駆動設計の思考に近いアプローチが良さそうだと判断   19 アーキテクチャの共通化

Slide 20

Slide 20 text

©10X, Inc. All Rights Reserved. ドメイン駆動設計とは？  ● このスライドだけではぱっと説明するのは自分には無理だなと感じつつ。。   ● 以下のようなアプローチで解決をしようとするものです   ○ 解決したい関心事（ビジネスや業務）を「ドメイン」という粒度で捉える  ○ ただし「ドメイン」を整理するためにはドメインの深い知識と理解が必要  ○ 「ドメイン」同士の複雑性をオブジェクト指向や制約でコントロールする  ● 詳しく勉強したい人は書籍を！  20 アーキテクチャの共通化

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

©10X, Inc. All Rights Reserved. なぜドメイン駆動設計が良いと思ったのか  ● 大まかな設計方針として「データを一定の粒度に一度まとめる（SSOT）」、その後利用するといった考えは持っていた  ● DDDの中でドメイン（モデル）をまたぐ複雑な処理（今回の実装でいうと計算処理）はドメインサービスとして切り出すような思想になっている   ● 実際のパイプラインでもこの計算処理の部分が複雑になりやすく、この処理を切り出し、テストできるようにしたかったのでやりたいことと思想がマッチした   23 アーキテクチャの共通化

Slide 24

Slide 24 text

©10X, Inc. All Rights Reserved. 5つのレイヤリングに役割を区分しテストで品質を保証  24 アーキテクチャの共通化ソースデータ    ・このデータを様々なところから利用しない   ゲートウェイ    ・ソースデータをクレンジングする処理層   ・データレイクとの入り口を意識した名前       ドメインモデル    ・ビジネスドメインを一定の粒度で集約する   ・ドメインモデル同士は依存させない       ドメインサービス     ・ドメインモデル同士を利用して複雑な処理をするための処理層  ・必ず実装する必要はない      アプリケーション     ・最終的なユースケースに沿った結合処理等を行う     

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

©10X, Inc. All Rights Reserved. まだまだ道半ばです  ● ネットスーパーを運営するためにはまだまだ様々なことが必要です   ● 今日はその難しさの中の一部分を紹介させてもらいました   ● 本日は技術方面の話が中心でしたが、実際は先方と仕様を調整したり、データプロダクトの企画や仕様策定といった業務をリードするデータプロダクトマネージャーと一緒に仕事をしています  ● 是非ご興味ある方はカジュアル面談等お気軽にお尋ねください   32 まとめ

Slide 33

Slide 33 text

No content