「つくりおき.jp」において「予測」することがなぜ重要なのか
この記事はAntwayアドベントカレンダーの19日目の記事です。
サブスク×週替わり×冷蔵宅食というビジネスがなぜ難しいか
Antwayでは、週替わりで、11品という多品種メニューを自社で製造し、即座にお客様にお届けするという、比較的ユニークなサブスクリプションビジネスを展開しています。
サービス開始から4年以上が経過し、26都府県に配送エリアを広げることができ、幸いなことに、現在では数多くのお客様にご登録いただいています。
3年前にデータ組織を立ち上げて以降、データサイエンスを用いて、この複雑なビジネスをいかに成立させるかを考え、苦心してきたので、今回は改めてこの辺りの話を深ぼってみたいなーと思います。
Web業界にいたときは「食品製造業→なんとなくアナログっぽい?データサイエンスとは無縁そう」という壮大な勘違いをしていたわけですが、当事者になって「めちゃくちゃデータサイエンス大事じゃん!」と気づいたよという話です。
前提
この話をするにあたって、理解しておくべき事項としていくつかあります。
まず、第一に重要なのは、「在庫を持たない(持てない)」 ということです。消費期限がある冷蔵というビジネスでは、基本的にはその日作ったものをその日に送り、完成品を貯蔵しておくことはできません。
また、週替わり→毎週違うものを製造するということなので、仮に食材が余っても、それを次に使う日がいつ来るか分からないので、安易に貯蔵しておくこともできません(倉庫がすぐパンパンになってしまう)。
ここが、冷凍宅食ビジネスとは大きく違うポイントの一つかなー、と考えています。冷凍の場合は日持ちがするので、完成品・あるいは中間仕掛品を大量に作って貯蔵しておき、発注が来たら詰め合わせて配送するということができそうです。(実際にそうしているかは知らない、、)
第二に、「お客様は毎週の注文をスキップできる」 ということです。
現在は毎週水曜締切という仕様になっており、お客様は前週水曜までであれば翌週の注文をスキップすることができます。これは、お客様の利便性の観点で、どうしても来週は旅行で受け取れない、ちょっと注文を一休みしたい、などといったように、ニーズに合わせて柔軟に選択できるようにしたいという目的で設定されています。
課題
上記のようなUXを前提とした場合に、オペレーション側ではいくつか課題が発生します。
①最適な集客数が分からない
各キッチンで製造できるキャパシティはある程度決まっているので、ビジネスとしてはできるだけキャパシティを最大限充足できるように注文数を集めたいです。
つまり、「生産キャパシティ-既存会員注文数=新規集客数」として、毎週の集客計画を立てる必要があります。一方で、上述のように注文スキップがあるため、「既存会員注文数」はかなり不確実性が高いです。
そのため、既存会員注文数を見誤ると、多く人を集めすぎてキャパオーバーしてしまったり、逆に少なく人を集めすぎてしまって機会損失となってしまいます。
②最適な食材発注量が分からない
大量の食材を発注する場合、注文が決まってから用意しても間に合わないため、かなり事前に仕入れておく必要があります。上記と同じ理由で、需要が読みにくいため、食材の過不足が発生するリスクがあります。(基本的にはバッファを持って発注するので余れば原価が悪化する)
③最適なシフトが分からない
食材と同じで、生産する人的リソースも調達をする必要があります。②と同じ理由で、これも余れば人件費が悪化するので、できれば需要分だけ準備したいです。
上記の課題に対して、精度を高く未来の需要を予測することができれば、ビジネスの利益を上げていくことができそうです。
予測を支える技術
現在Antwayでは①の部分については、機械学習を取り入れることで一定解決できています。
予測パイプライン全体の流れとしては以下。
▼詳細フロー
①週次の注文が実行されると、トランザクションがBigQuery内にロードされる
②featureテーブルを作成
③featureテーブルを参照して予測を実行
④予測結果をBigQueryに出力
⑤予測結果を集計したレポートを作成し、Google Sheetsに出力
⑥集客担当がレポートを元に、集客計画をシミュレーション
全体のフロー制御はGithub Actionsで行っています。また、featureテーブル、reportテーブルなどの作成はdbtで管理し、データ品質に異常があればSlackに通知を出すことで、品質の担保を行っています。
加えて、予実差分をダッシュボードにしてモニタリングすることで、精度異常の監視をしています。
モデルの予測/学習については、現状BQMLを使っていますが、 アルゴリズムの制約や拡張性を踏まえ、1月目処にVertex AI Pipelineをベースにしたシステムに移行する予定です。
日々思っていること
モデル精度がビジネス成果と直接的に連動するのでやりがいがあると同時に痺れる
良くも悪くもモデル精度がわかりやすく事業利益に直結します。そのため、自分の作ったプロダクトが利益を産むやりがいは大きく感じられる一方で、障害や精度低下などにすごく敏感になります。
特にビジネスの変化が激しいスタートアップにおいては、新機能のリリースやユーザー傾向の変化などで、データドリフトが頻繁に発生する可能性があるので、ビジネスのスピードに追随しながらモデルの精度を高く保つことが非常に難しいです。
ようやくMLを業務活用できるようになったばかりですが、今後複数のMLシステムが稼働すると、こうしたメンテナンスをいかに効率よくできるかが重要になってくる気がします。MLOpsの勉強をもっとせねば。
良い予測は良いデータから
当たり前ですが、モデル精度を常に保ち続けるためには、データ品質を良い状態で担保し続ける必要があります。基盤整備・データ品質整備が事業利益に貢献しやすく、今後ソリューションが増えていくに従って加速度的にその重要性は増していくので、かなり面白い領域だと思います。
弊社では初期からdbtですべてのSQLロジックを管理し、随時品質チェックを行うことで、このフェーズのスタートアップにしてはそれなりのレベルでデータ基盤の管理ができていると思います(たぶん)。一方で、データマネジメントという意味ではまだまだやれることは大きく、DMBOKなど読みながら体系的にアプローチしていく必要があると思います。(が、リソースがない、、)
今後の展望という名の願望
お客様のUXをもっと上げていくためには、より多くの選択肢を提供していく必要があります。例えば、メニューをカスタマイズできるようにしたり、アップセル/クロスセル/ダウンセルの商品プランを作ったりなどが考えられそうです。
ここまで書いてきたように、Antwayのビジネスモデルでは、UXとオペレーションは根本的にトレードオフ関係にあるので、普通にやれば到底スケールすることができません。そのため、ソフトウェアとデータサイエンスが両者のクッションとなって負荷を吸収・軽減していくことで、ビジネス全体のアジャイル・スケーラビリティを獲得していければいいなー!と考えています。
まとめ
MLエンジニアもデータエンジニアも大募集中!
Discussion