「データプロダクト」とは何かを自分なりに考えてみた

数年前に訪れたモンゴルにて。
残忍なイメージを植え付けるプロパガンダを使いこなし、結果として血を流さずに領地拡大する情報戦に長けていたという噂の、皆さんご存知チンギス・ハン。
背景の草原・ゲルと、勇ましい形相のコントラストがすごい。
例によって、記事との関連は全く無い。
数年前に訪れたモンゴルにて。 残忍なイメージを植え付けるプロパガンダを使いこなし、結果として血を流さずに領地拡大する情報戦に長けていたという噂の、皆さんご存知チンギス・ハン。 背景の草原・ゲルと、勇ましい形相のコントラストがすごい。 例によって、記事との関連は全く無い。
📔
この記事は、10X創業6周年アドベントカレンダーの5日目の記事です! 昨日の記事は、サクセスオペレーション部の菊池さんによる、「10Xで10xな働き方を模索したい30代のリアルな今」でした! 素敵な内容でしたね、僕も10xな働き方=単なるハードワークではない、という認識を新たにしました!
こんにちは、@tenjinです。
僕は10Xという会社で働いており、グロース本部という組織に所属しています。
グロース、という言葉が力強いかつ具体をイメージしづらいですが、データアナリスト・アナリティクスエンジニア・マーケターなど、社内でも珍しいほど多様な専門性を持ったスペシャリストが集まる組織です。
言うならば、事業を立ち上げる・状況を把握する・数字を伸ばすなど、各フェーズの様々なイシューを解決するため、あらゆる機能を提供する集団になります。
 
また、グロース本部の中には「データプロダクト部」という珍しいチームが存在し、僕はそこに所属しています。
僕自身、ふとした瞬間に「データプロダクト」について考えを巡らせては、何かが浮かんで消え、眼の前の仕事に忙殺され・・・を繰り返す日々です。
そのため、本稿では自分なりに「データプロダクト」とは何か、を改めて思考し、その言語化を試みます。
 

何故グロース本部にデータプロダクト部があるのか?

データプロダクト部の主な仕事は、小売事業者が商いをする・エンドユーザーが買い物をするための売り場を品質高く作るために、様々な情報が集約されたマスタデータを作ることである。
例えば「いつ・どの店舗で・どの商品が・何個・いくらの金額で売っているか」のようなデータだ。
 
こういったデータは、一見存在して当たり前のように感じられるが、決してそんなことはない。
店舗型のネットスーパー・ドラッグストアといった業態では、商品数が数万にも及ぶだけでなく、その在庫数や売価も変動するためだ。
実店舗でお客様が買えば在庫は減るし、値下げも様々なタイミングや期間で行われる。
(むしろこれを意識する必要の無い環境は、どこかで誰かが貢献してくれている、という裏返しだ)
 
僕たちはそれを考慮してマスタデータを作り、Stailerにおける各所に引用され、ECの売り場が構築されていく。
自分のハンドリングしたデータがプロダクトや事業へ直接影響を及ぼすため、非常にやり甲斐と責任感のある仕事である。
言い換えると、マスタデータが無ければ、10Xと各ステークホルダーを繋ぐものは何も無くなってしまう。
つい先日公開されたStailerのLPにも、お客様アプリ・スタッフアプリ・管理画面の機能と並ぶ形で、商品マスタが紹介されている。
グロース本部には、様々なチーム・職種があることは事実だ。
  • 日々の業務や打ち手をなるべく再現性高く・型に昇華させることで、事業の立ち上げや成長に伴走できる知見を貯めること
  • その遂行のため、共通言語としてデータやファクトを武器にできるような環境や文化を整備していくこと
この2つの観点から、それぞれのチームが同じ本部に所属し、お互いにシナジーを生んでいく構造は、個人的にとても納得感があるものとなっている。
 
事実として、マスタデータ作成のような業務も、元々は社内分析用のデータマート整備に専門性が由来している。
StailerがWhole Productとして成長する中で、最初はエンジニアの方々が実装していたマスタデータ生成プロセスにつき、事業機会拡大に伴う工数増加を解決するため、データ人材である僕たちがこのイシューを受け持ったのだ。
 
10XのStailerにおけるデータの流れ、下記ブログより転記
10XのStailerにおけるデータの流れ、下記ブログより転記
 
Stailerにおけるマスタデータ生成の一番の難しさは、売り場への考え方・元となるデータの形や量が、企業によって異なることである。
もちろん、これらを初めから格好良く捌けたことはなく、繁忙期には人海戦術に頼らざるを得なかったり、各社の生成プロセスも個別最適あるいは属人的なものになってしまっていた。
あえて分けて表現すると、最初はエンジニアリング側とデータ側の境界線も試行錯誤で、徐々に役割分担や抽象化を進めながら、なんとかデリバリーまで漕ぎ着けていった。
その点、振り返るとデータ側だけでも、随分遠くまで来たものだ、という感想を抱く。
(まあ、最初はとにかく必死だったのである)
 
ある程度独立して業務ができるようになったということは、その境界線・コントラクトが整備されたと同義であり、最終的には決まった形・制約でデータを作成する必要がある。
そこで課題認識を新たにした僕たちは、プロセスを何周かした上での汎用アーキテクチャの設計や実装、組織体制の再構築や開発プロセス自体の刷新など、様々な取り組みを並行して進めていった。
結果、以前とは比べ物にならないほどのスピードで、かつ漏れなくダブりない論点を潰した状態で、スムーズにマスタデータ作成や売り場形成ができるようになった。
 
これに付随して、各社ごとに異なるデータも横断的に扱いやすく、知見を得るデータ抽出も行いやすく、プラットフォームの機能追加や状況変化も対応しやすくなった。
データハンドリング自体もさることながら、抽象化された粒度・階層・定義へ落とし込むための設計、ローンチ後の運用まで見据えた品質担保、売り場生成に限らない利活用方法といった、幅広いナレッジ蓄積も進めていった。
 
以下は、この構想や推進を第一線で進めてくださった@takimoさんが外部登壇した資料であり、事の経緯がわかりやすく解説されている。
 
そして昨年の組織変更のタイミングに伴い、正式にグロース本部・データプロダクト部が誕生した。
ここに至るまでの僕個人の経験については、以下の過去記事にも書いていたりする。
 

データプロダクト部がやっていることは何か?

このような経緯から生まれたグロース本部のデータプロダクト部だが、いま何に注力しているのか、についても述べる。
現在熱量が高まっているのは、以下の3つである。
 
1. データ品質とアーキテクチャへの投資
Stailerへ正確なデータを届けること、売り場を保つことは、データプロダクト部の最重要ミッションだ。
この達成のため、データを作る仕組みを構築してデリバリーするのみならず、中身の品質を保ち続けること・土台のアーキテクチャへ投資を続けることは、全てを差し置いて優先順位が高い。
例えば、データ連携における異常検知、バックアップやリカバリー手段の確立、不具合の事前防止に向けたモニタリングなど、やるべきことは何重にも渡る。
 
特に掲載SKUやセレクション・欠品といった指標は、品質観点だけではなくビジネス観点からも、示唆を出す営みに繋がるだろう。
これらの実現のため、マスタデータ生成パイプライン各所のデータを効率的・安定的に取り扱い、スケール可能なオペレーションとデータガバナンスを確立するべく、日々研究を続けている。
 
2. データプロダクトを介した事業開発
データそのものは価値を産まないが、10Xにおけるデータプロダクト部が各所へ価値提供していることも事実だ。
新規パートナーのローンチのみならず、プラットフォームの機能追加など、Stailer内部だけを切り取っても、様々な箇所でデータが必要とされる。
一方で現実は、全ての要望に答えるほどのリソース的余裕は無く、ビジネスインパクト観点からその配分を判断せざるを得ない。
 
当然ながら、言われたことをやる・求められる役割をこなすのみならず、未来に向けた事業開発やR&Dを行うことも大切だ。
そのため、あくまで本業ありきの前提を置きながら、
  • 会社全体として健全な売上を立てられていること
  • そのために適切な投資がなされていること
  • 加えて新しい芽を探索できている(その余裕がある)こと
の三点を適切に抑えつつ、チームを推進するように努力している。
 
3. 組織内外のマネジメント・コラボレート
データプロダクト部はグロース本部の中でも大所帯で、その運営を日々ブラッシュアップし続ける必要がある。 具体的には、スクラム開発のエッセンスを取り入れつつもカスタマイズし、適切なチームアップに目を光らせている。
加えて、僕たちは業務委託の方々の協力がなければ、日々のタスク遂行は極めて限定的になってしまう。
そのため、バックグラウンドや雇用形態・勤務時間などが異なるメンバー間において、適切にコラボレートするための仕組み構築や、ドキュメント・開発フローの改善も続けている。
 
また、データプロダクト部が連携する部署・職種は多岐に渡ることから、関係者間のレポートライン整備も不可欠である。
これについては、部内の業務改善のみならず、他職種であるBizDev・SWE・PdMとも頻繁にやり取りをして、お互いの課題感をsync、解決するアウトプットを共に作ったりしている。
本当に色々な人達と話しながら仕事ができるので、いつも新鮮で楽しい日々を過ごしている。
 
パートナー小売企業の新規ローンチにおける、マスタデータ生成が関わる業務フロー・関係者・課題・解決策案の全体像。
職種をまたいだコラボレーションによる賜物であり、人によって見ている景色が異なることが改めて明らかになった。
パートナー小売企業の新規ローンチにおける、マスタデータ生成が関わる業務フロー・関係者・課題・解決策案の全体像。 職種をまたいだコラボレーションによる賜物であり、人によって見ている景色が異なることが改めて明らかになった。

そもそもデータプロダクトとは何か?

話は変わって、「データプロダクト」という定義について。
あまり聞き慣れない言葉だが、調べるとその名の通り「データ自体が主となったプロダクト」を指すものらしい。
たしかに既存のプロダクトでは、あくまで主役はプロダクトそのもので、データはそれを影で支えたり、副産物だったりするケースが多かったように思う。
それに対してデータプロダクトは、データそのものが主体となる存在で、これによりステークホルダーへ多大な影響を与えてしまう。
 
加えて、僕が過去記事で調べた内容をそのまま引用すると、個人的な解釈も含むが”Data Product Manager”という職種は、以下のような役割が定義されているらしい。
  • プロダクトのデータ収集・整理・保存・共有・管理について、組織における責任を持つこと
  • プロダクトのライフサイクル全体を通じて、信頼できるデータフローを整備し、機能を構築・完成させること
  • 大規模なデータ取り扱いの要件につき、実行可能なサイズに分解して、それに適切なリソースを割り当てること
  • ビジョンを伝え、要件を特定・翻訳し、利害関係者の調整・プロジェクトの優先順位付けをすること
  • 組織内のデータ民主化に加え、データおよびそれらの組み合わせによる新たな価値実現に向けて探索をすること
  • 時にはデータサイエンス・機械学習などを目的ではなくツールとして用いながら、プロダクトに組み込んで収益化すること
  • 内外のデータを用いて仮説検証を行い、プロダクトマネジメントにフィードバックさせること
 
 
先述の通り、10Xにおけるデータプロダクトは売り場形成の根幹であり、かつ一定の独立した業務遂行や、日常的な品質担保が求められる。
そのため、僕たちデータプロダクト部にて定義している職種には、データプロダクトの企画・推進について注力する”Data Product Manager”だけでなく、データプロダクトを構築するアーキテクチャや仕組み・専門性のデリバリーについて責務を持つ”Data Product Engineer”が存在する。
 
振り返ると、かつて社内では僕たち自身のことを、商品マスタ部(仮)のように呼称していた時期もあった。
そして組織組成のタイミングにおいて、改めてチームで話し合い、責任や提供価値を棚卸しするのに伴って、正規にデータプロダクト部、と名乗り始めたのであった。
また、僕の個人的な結論としても、日々作成するマスタデータ群は「データプロダクト」であり、それを利用して売り場を生成するStailerは「プロダクト」なのである、という整理にも至った。
 
2022年の夏頃、チームが正式に部として組成されることに従って、新しい部の名前を何にしたら良いか、悩んだり助けを求めている様子。
2022年の夏頃、チームが正式に部として組成されることに従って、新しい部の名前を何にしたら良いか、悩んだり助けを求めている様子。

データプロダクトの提供価値は何か?

では改めて、僕たちがデータプロダクトを通じて提供している価値とは何なのだろうか。
以下では、僕が実際に業務を行う過程であったり、商談で小売から直接お話を伺ったり、BizDevからもらったフィードバックなどを元に、個人的見解を3つほど述べてみたいと思う。
 
1. 買う側・売る側双方に快適なEC体験を提供する
実店舗においては、在庫がない商品を購入してしまうことはありえない、何故ならば物理的に存在しないためだ。
しかし、ECではデータの不整合により、購入したはずの商品が実は欠品していて届かない、という事象は起こり得る。
 
小売の立場からしても、「未成年がお酒を買おうとしていないか?」「お一人様いくつまで限定商品か?」「冷蔵品ならばドライアイスが必要か?」といった考慮事項につき、POSレジやスタッフが都度判断をしているが、これを数万SKUを販売するECにて代替するには、自動化が不可欠であろう。
加えて、実店舗では陳列の入れ替えやセール反映も頻繁に行われているが、ECはずっと品揃え・売価も変わり映えのないまま放置されたり、実態と乖離が大きくなる結果、現場にも負担が掛かってしまう。
 
こういった買り手側・売り手側双方の悪い体験を最小限に食い止めるため、データプロダクトは小売のシステムにおける基幹データ・一部人間の意志入れをするためのマニュアルデータを掛け合わせ、ロジックを組み上げてモダンな技術スタックを使って捌くことで、快適なEC体験の一翼を担っている。
 
2. EC販売の業務負荷を省力化する
1.で述べたような売り手側の事情について、当然ながら価格・在庫・品揃えなどは店舗ごとに状況が異なる。
店舗型のネットスーパー・ドラッグストアにおいて、店舗が増える毎にオペレーションも線形に増える状況は避けるべく、これらのデータを効率良く取り扱う思想が不可欠となる。
 
また、小売によっては限られた店舗でデリバリーサービスのプラットフォームなどを活用し、試験運用と位置付けてEC販売を実施するケースも存在する。
しかし、試験運用が故に異なるデータソースからコピペする作業が強いられたり、ひたすらExcelでデータ加工する人員が必要だったりと、データ生成に課題を抱えていることがある。
 
この点、10Xにおけるデータプロダクトは、店舗・商品を含めたデータを一元的に取り扱うことができるため、初期のデータパイプライン・ロジック構築さえしてしまえば、その後の店舗開設などのハードルは極めて低い。
日々の運用業務負荷も最小限のままに、データ鮮度も保ちつつ、新店舗や新プラットフォーム活用といった戦略的領域に注力することができる。
 
3. デジタル化に向けたデータ整備への先行投資とスモールスタートをする
新しくECを始めようとした時に、既存データの商品名が半角カタカナだったり、カテゴリのような構造的概念が存在しなかったり、というのはあり得る話かもしれない。
これらのデータは、買い手側にとっても商品の検索・推薦といった体験に必要不可欠でもあり、実店舗ではスタッフに尋ねれば済むものの、ECではそうはいかない。
 
また、世間には様々な分析手法やMAツール・デジタル化事例が存在するが、これはあくまで綺麗に前処理・整理・構造化されたデータが前提となることも多い。
(仮に高額なSaaSを入れたとしても、商品やユーザーに紐づく元データが使い物にならなければ、宝の持ち腐れである)
 
10Xのデータプロダクトでは、これまでStailer事業を推進してきた知見から、ネットスーパー・ドラッグストアにて必要なデータを網羅的に洗い出せている自負があり、 伴走させていただくことで必然的にあるべきデータ整備への力学を働かせることができる。
それは来たる未来に向けた、小売のデジタル化への先行投資とスモールスタートに他ならない。
 
データプロダクトにおける商品名・売価・在庫数の生成に向けた概念図
データプロダクトにおける商品名・売価・在庫数の生成に向けた概念図
先に述べた内容について、ECで最も複雑かつシビアな項目である商品名・売価・在庫数の三要素につき、データパイプラインや優先順位付けを概念化したものが、上の図である。
例えば売価は、販売初期の定価・店頭での売価・セール価格など、複数の値を持っていることがあり、さらに期間によってこれらが頻繁に変更される。
これに加えて、プロモーション目的でEC限定の売価設定をしたり、そもそも基幹システム側で保持していない生鮮食品や惣菜の売価設定をしたりと、一部については人間の意志入れが必要となる。
そのような要件に対して、中央あるいは店舗別の基幹データと、Excelなど手で作成するマニュアルデータをハイブリッドで組み合わせ、優先順位や参照方法などのロジックを構築することで、半自動的な売価変動の反映や意思入れをすることが可能となっている。
 
以上、10Xにおけるデータプロダクトは、EC立ち上げプラットフォームであるStailerの一機能としていわば必要に駆られ、現在に至っている。
そして、述べたような価値提供についても、当然データプロダクトのみで実現できるものではなく、10X・Stailerにおける他のモジュールや職種や部署といった連携が不可欠である。
しかしながら、データプロダクト自体が一定の切り分けられた領域において、幾分かの価値提供ができているということも、これまた事実であろう。

結びに

あくまで個人的に最近思っていることを、結びに書き残しておく。
10X・Stailerにおける役割分担が明確になるにつれ、データプロダクトそのものへの引合や非連続な期待をいただく機会が、どんどんと増えている。
事実、多店舗におけるオペレーション改善なども含めたEC周辺の全面刷新=Stailerの本格導入ではなく、既存の仕組みを拡張することで、小さく需要を探っていきたい、という小売も存在する。
 
その点、データプロダクト単独は比較的小回りがききやすく、現状組まれたワークフローの一部を請け負って改善するなど、大きな意思決定の手前から伴走することができる。
実際に僕個人も、元々はBizDevやSWEといったインターナルの関わりが多かったが、徐々に外部との商談にも同席するようになっている。
これは非常に有り難いことであり、嬉しい誤算でもあった。
しかしながら、これは同時にデータプロダクトに対する考え方を改めなければいけない、ということと同義でもある。
 
いままでのデータプロダクトはStailerの一部であり、Stailerの売り場を介して、Stailerを導入したパートナー小売企業とエンドユーザーを結ぶために存在していた。
もしも今後、データプロダクト単独での価値提供が望まれるとすると、事業・プロダクト・組織など、様々な箇所で一皮剥ける必要が出てくる。
そうだとしても、親元であるStailerへ向けたマスタデータ生成は、当面継続しなければならないであろう。
なぜならば、この役割を担えるのは現状で僕たち以外に存在しないからである。
 
一方で、データプロダクトも一つのプロダクトを作る・育てるといった意識を持たなければ、拡大する事業機会や積み上がる機能要望に対応することができない。
この時には、各々の事情を汲んで実現する考え方と、汎用的な資産の開発・運用・保守を継続する考え方という、縦横双方のバランスを見た優先順位付けが求められる。
それはまるで、10Xにおけるマトリクス組織の関心事に近い。
 
この複雑な事業あるいはプロダクトを推進していくために、誰か超人を据えるのではなく、何か仕組みで境界線を整備できるのか、あるいは各所との連携や説明責任をどう果たしていくのか、非常に頭を悩ませている。
こうなるともはや、データプロダクト部自体は10Xには存在するかもしれないが、データプロダクトから見るとStailerも一つの得意先のように、お互いの関係性が変化していくのではないか、とすら思えてくる。
小売とStailerはデータプロダクトを介してデータ授受を行っているが、今後はデータプロダクトがStailerとは異なるプラットフォームを介して異なるエンドユーザーに価値を届けたり、はたまた異なるステークホルダーが存在するようになっていったとしても、全く不思議ではない。
 
あるいは、Stailerのプラットフォームで生まれたデータを適切な粒度で受領し、これ自体を分析や可視化・自動化に活かすことで、各所へ価値提供する仕組み自体も、一種のデータプロダクトと呼べるのかもしれない。
データプロダクトとは決して無機質な基幹システムではなく、データ自体を資産としてステークホルダーへの価値提供を行う存在であるとすれば、必ずしもデータフローは一方通行である必要もなく、その利用方法がステークホルダーによって異なる事・EC以外の目的に用いられる事も、大いに歓迎すべきである。
少なくとも、僕個人は現在そのように考えている。
 
今後も小売のため、エンドユーザーのため、あるいはこれから出会う方々のため、データプロダクトを介してどんな価値提供ができるのか、色々と試行錯誤していきたい。
 
データプロダクト部オフサイトの様子
データプロダクト部オフサイトの様子
🌞
10Xではメンバーを募集しています、採用ページもぜひご覧ください! 明日は、BizDevの土性さんが記事を公開する予定です! 予報によると、猛烈な熱量と熱射が想定されますので、日焼け止めと麦わら帽子のご準備をお忘れなく!