【Product Engineer Night #4】 物流のデータモデルを探求する 深遠な旅の軌跡 リードプロダクトエンジニア 宮津 

2 自己紹介 2 1991年生まれ 北海道出身 2016年 新卒でSIer NSSOLに入社 EC・小売の分野で 大規模システム開発に従事 2022年 物流 x データの世界に惹かれ アセンド株式会社に入社 物流向け運送管理SaaSを開発 宮津　研士郎 Miyatsu Kenshiro リードプロダクトエンジニア 

物流業界の価値最大化 トラック運送会社向けに All-in-One SaaS ロジックスを開発 シリーズA 社員 20名、エンジニア 7名 

物流は日本で 最もデジタル化の遅れた産業 ※ 総務省「情報通信白書令和3年版」産業別 クラウドサービス利用状況 

物流のあらゆる業務を 迅速にデジタル化する挑戦 

6 6 運送業のコアデータ “配送案件” を中心としてあらゆる業務を繋ぐ 運送業特化 All-in-One SaaS を開発 

個別のプロダクトを提供するのではなく 複数のプロダクトをコアデータ中心にリバンドルし スムーズな連携という顧客価値を提供する。 一方でコアデータのモデリングは難しく、 詳細さと柔らかさのバランスが求められる 7 コアデータとは？ 〜コンパウンドスタートアップ〜 7 データ連携・データ活用のためには正確さと詳細さが必要 ユーザーが入力し切れるユーザビリティ・柔らかさも必要 

8 どうドメインをキャッチアップして どうコアデータをモデリングしたか お話します。 

9 9 データモデリングのための ドメインキャッチアップ データモデリングのための ドメインキャッチアップ 

データモデリングとは、現実世界を抽出し、 システムで扱える概念に簡素化するプロセス です。 システムに新しい要求が生まれた時や、何か 課題が見つかって、エンジニア自身が新しい ドメインの姿に触れた時、データモデリング は行われます。 ドメインのキャッチアップとデータモデリング 10 

誤ったドメイン認知がデータ観点で引き起こす問題 11 業務を受け止められない ユーザーの思ったデータ構造と違う。データ構造が想像でき ない。データ構造より業務がはるかに複雑。 データの空箱 ユーザーが入力したくなくなる、想像通りに入力できない ストレージの肥やし 誰も活用してない、活用できない 

● 顧客の行動を適切に記録できる構造か？ユースケースを満たすか？ ● データのライフサイクルが言語化できるか？ ○ データは”具体的に”どうやって生まれる？ ■ 事務担当の職員がキーボード入力で打ち込む。 一日⚪件、一度に１０文字程度... など。 ■ そんな大変な入力だったらそのうち入力されなくなるかも？ 簡素化する仕組みが必要...! といった論点になる。 ○ データは”具体的に”どうやって活用される？ ■ 入力同様。誰が、どのように？ ■ 入力と活用が適切なループを生むか？ インセンティブがなければそのうち入力もされなくなる可能性がある。 キャッチアップの際のポイント 12 

例えばこんなキャッチアップ & 工夫 13 ・荷物を運ぶ際の”発着時間” ・ドライバーさんの稼働時間把握 や、案件の時間単価を知るため重要 ・データを覗いてみると、時間まで は入れてくれないお客さんがいた デフォルト値 

・担当CSに深掘ってもらい、以下のような事情がわかってきた。 例えばこんなキャッチアップ & 工夫 14 1日を24時間で捉えずに、 AM・PMのように業務しやすい 形で時間帯を区切って業務して いるから 　→24時間制だとどう入力して いいのかわからなかった 1日のうちであれば、 いつ届けてもいいような荷物の 依頼がある。 　　→時間の入力が不要 

例えばこんなキャッチアップ & 工夫 15 ・”時間帯”というラベルを埋め込め るようにし、お客さんの認知に寄 り添う →これだけでは活用ができない ・内部的に時間の定義を併せ持つ 構造とし、価値を生むデータも同 時に生成 内部的には 06:00 扱い 内部的には 12:00 扱い 

データモデリングにおける、キャッチアップのポイント ◼お客さんがどう入力して、どう出力を活用しているかのイメージアッ プをする。 　　　それが全て！！！ 16 まとめ 

17 そう甘い話でもなく.... 

18 18 アセンドにおける 物流データモデリングの歩み アセンドにおける 物流データモデリングの歩み 

CPOが初めてお客さんにプロダクトを当てた時の一言 「こんなの入れたら、業務が絶対回らなくなる。こんな 製品、私は絶っ対に入れませんからね！」と顔を真っ 赤にしていきなり大きな声で怒鳴られました。 CPOインタビューより https://note.ascendlogi.co.jp/n/n8941d4d9cad6 「こんな製品、私は絶っ対に入れませんからね」事件 19 

CPO「物流業界の変革のために、現場で取得すべき物流データから逆算 してプロダクトの理想像を作ってしまった。 … 理想と現実のバランスを保った目線が不可欠だった。」 なぜ事件は起こったのか？ 20 

通称 案件V1 (2021 ~ 2024) ◼配送案件を１台のトラックで実行するデータモデル ◼UXを1から見直し、UIを刷新 ◼スキーマレスDBの柔軟性を生かして、顧客要望の都度、データ モデルを更新しつつ対応 ◼導入社数は2年で5倍に ◼コアデータを守りながら柔軟性を実現する「項目制御機能」 ”現場が使いやすい”プロダクトに作り直し 21 

◼項目制御機能 コアデータを守りながら、入出力を柔軟 にする機能。顧客の見たい情報だけ見れ るようにしたり、入力したい形式を業務 実態に合わせて変えられる。 ・各社ごと・項目ごとにラベルを設定 ・荷物重量を入力する際の単位(kg/t) ・一覧で表示する情報を取捨選択 …など ”現場が使いやすい”プロダクトに作り直し 22 

…1年後　課題が見えてきた ◼導入社数が増え、運送業についての見識が広がった。 ◼多様な荷物・運送形態を抱える業務を受け止めきれなさそうだ。 ◼幅広く業務を受け止められるデータモデルを模索する激闘が始まる。 運送業の像の広がり、データモデル刷新の意思決定 23 

ひたすら言語化、認知のすり合わせ、作って、議論の繰り返し。 ９ヶ月の激闘 24 

見えてきたコアデータの姿。配送案件と運行 25 トラック1で運ぶ 魚1箱 トラック1で運ぶ 魚1箱 肉1箱 トラック1で運ぶ 鉄10t トラック2で運ぶ 

通称 案件V2（2023 〜 ） ◼配送案件と運行をN:Nで表現できるモデル ◼運送管理アプリの中でも、唯一無二の柔軟性を誇る ◼導入社数は1年弱で更に5倍に ◼プロパティは増えても、リレーションの見直しなどは発生せず。モデル としての正確性を保ち続けている。 ◼受け止められる業務の幅を広げるほど、入力してもらう工夫は必要 激闘を経て、モデルを刷新 26 

そして、現在 27 ◼顧客が”ちゃんと”データを入れ、活用するようになった。 ◼N:Nまで受け止められるデータモデルの中で、 限られた業務パターンまでしか実現できていない。 ◼より多くのお客さんに価値を届けたい！ 

We are hiring !! 28 𝕏 (@kenshiro382) お気軽にフォローください。 28 

No content