見出し画像

開発組織がサービス導入を担う!?データ準備チームの取り組みをご紹介

本記事はGoalsアドベントカレンダー2023の12/18の記事です。

こんにちは、株式会社Goals 開発部門の宍戸です。
今回は、開発組織内にありながら、プロダクトの開発・サポートではなく顧客導入作業の一部を担う、変わった立ち位置のチームの取り組みについてご紹介します。

弊社プロダクトHANZOと導入体制

弊社ではHANZOシリーズという飲食店向けの需要予測型AIサービスを展開しています。

HANZOシリーズのうちの一つ、HANZO 自動発注ではAIによる需要予測および理論在庫により最適な発注数量を提案することができ、日々の発注業務の負担を軽減していくことができるサービスとなっています。

HANZO 自動発注が最適な予測を出すためには、売上データや受発注データ、それから店舗で提供しているメニューのレシピデータなど、さまざまなデータをHANZOに連携させ、学習させる必要があります。
弊社では、このような必要なデータの収集、およびデータの成形、HANZOへのデータの登録など、サービス導入時に必要となるデータ準備をサポートする体制を整えています。

基本的な顧客ごとのHANZO導入推進はカスタマーサクセスチーム(以下CS)が担っています。そのCSの導入作業の工程の中で、HANZOへ登録するデータの収集、成形(および必要に応じて分析)を行う工程を実際に実行していくチームを、弊社では現在、開発組織内に置いています。


開発組織内に構えるデータ準備チーム

開発組織内に顧客データ準備のチームを置くことの狙いは、以下の通りいくつかあります。

①adoptionフェーズのスタートダッシュを決めるための準備を最速に

こちらの記事adoptionのお仕事でご紹介しました通り、自動発注を成功させる要はadoptionであり、この工程でさまざまなチューニングを施すことで自動発注が実現していきます。
そのadoptionを始めるためには、いくつかのデータ上の条件があり、自動発注に関連する多くのデータに対して満遍なくその条件を揃えるよう、確認作業と調整作業を行う必要があります。
この作業をデータリテラシーの面で強みがあるエンジニアが行うことで、スピード感とデータ品質を保ちながらデータ準備を行うことができ、サービスの稼働開始までのリードタイムを短くすることが期待できます。

②ノウハウの集約とプロセスの抜本的な改善を回す

以前はCS内でサービス導入に向けたデータ準備を行っていましたが、個々のCSにデータ作成のノウハウが散らばっており、また、自動発注を成功させるためのデータ作成のノウハウやチェックポイントの体系化も顧客ごとの導入タスクが他にもたくさんある中でなかなか進めづらい、という課題がありました。
このような課題の発見と解消をデータ準備チームの責務とすることで、ほぼ全てのお客様の自動発注のデータ準備を行いながらチーム内にノウハウを集約し、自動発注に最適なマスタデータ群の構成の検討や、データ分析の手法・コツの検証のサイクルを回しながら、作業プロセスを高めています。
また、データ準備作業を行う中で、作成するデータの均一性や非効率、属人性、エンジニアにしかできない処理などの課題を洗い出し、開発面からのアプローチで改善していくサイクルも同時に回していくことで、抜本的な改善を図っています。

ノウハウが整理されて、適切なツール化や作業プロセスが統一されていけば、求められるデータリテラシーも下がっていくことにつながり、エンジニアじゃなくても一定の品質を担保してデータ準備ができるようになっていくはずなので、組織のスケールも目指していけるってわけですね。

チームに入る経緯とキャリアについて

社内のお仕事紹介の記事なので、一応簡単に私のあれこれを話しておきます。
本記事を執筆している宍戸はGoalsにジョインして2年ほど経つアプリケーションエンジニアですが、現在はデータ準備チームで顧客データ準備の作業を担当しています。おかげさまでHANZOを導入したいお客様が増えており、このチームが立ち上がって半年ほどですが私は10業態ほどのデータ準備を担当させていただきました。

データ準備チームは厳密に言えば機能開発を実行していくチームではありません。いまあるHANZO機能をフル活用して、お客様の導入を最速で遂行するチームです。開発をしないということに対してエンジニアのキャリアとして不安がないわけではありません。ですが、それ以上に未開拓の土地を開拓していく面白さの方が今は勝っています。

日々導入作業を行いながら、新しいデータ分析方法を検証してみたり、既存機能の改善を行ったり、組織をスケールしていくためのチーム育成をしてみたり、基準となる作業プロセスをドキュメント化してみたり・・・。課題解決の手段が開発だけじゃないということを、日々学んでいます。

面白そうだなと思ってチーム立ち上げ時に手をあげて、飛び込んでよかったと思っています。

最新の取り組みをご紹介

さて、本記事の残りは、ほんの触りだけですが、約半年間の活動で見えてきたHANZO 自動発注のデータ準備に関するノウハウを一つだけご紹介しようと思います。ここから飲食店向けサービスっぽい話になりますよ。

HANZO 自動発注では、お客様が運営する飲食店のレシピデータをベースに、マスタデータを準備していきます。レシピデータは、飲食店で提供されるメニューの1人前の材料と分量で構成され、飲食店で提供するほぼ全てのメニューのレシピデータを整えることが、自動発注を実現する基礎を整えることにつながります。

一口に1人前のメニューといっても、以下のようにさまざまな形式のメニューがあり、レシピデータのデータ構造は実はかなり複雑となっています(HANZO 自動発注を導入されると、このようなレシピデータを登録・閲覧できるメニュー管理機能をHANZOの通常機能としてご利用いただけます)。

  • お膳や定食など、複数の料理で構成されるメニュー

  • そばやうどん、ラーメン、丼ものなど、麺やトッピングに多くの組み合わせが構成できるメニュー

  • ドリンクやお酒など、サイズ違いや割り方に多くの組み合わせが構成できるメニュー

上記のような複雑なレシピデータは、マスタを作成する人やその他の環境要因によって、構成方法にばらつきが発生します。例えば、定食などの複数の料理で構成されるメニューを、「全て一つのレシピとして作成」するのか、「ご飯、味噌汁、小鉢、メインそれぞれのレシピを作成し、その組み合わせで構成」するのか、といったいくつかの構成手段をとることができます。

こういった構成上のとりうるパターンを洗い出し、メリット・デメリットを整理しながら優劣を吟味していきます。これを繰り返しながら、自動発注のマスタデータとして相応しい構成とは何かという議論をチーム内で積み重ねています。

上記の例だと、後者の構成が自動発注的には「良し」と判断しています。自動発注を進めていくと、レシピデータの内容を修正したいタイミングが頻繁に発生します。その時に前者の構成だと「全ての定食のご飯の分量を変更したいのに、大量のレシピ修正しないといけない!」となりますが、後者であれば「ご飯という一つのレシピを修正すればOK!」となります。まぁ、データベースの正規化の基本と同じですね。

弊社のHANZOシリーズは飲食店のDXを助けるプロダクトです。自動発注を目指す過程でレシピデータをこういった活用可能なマスタデータ群として整理して活用していくことが、お客様のデジタル化の第一歩につながると私は信じています。

最後に

少々長くなってしまいましたが、今回は飲食店のデータ活用とその準備について、弊社の取り組みを紹介させていただきました。
弊社では常に面白い取り組みに挑み続けていて、全く飽きることがありません!
現在のチーム内の議論では、データ準備からもう少し話が進んでいて、データ分析でできることがもう少し見え始めています。
データの活用の可能性が感じられてとても面白い!

明日は12/19、鵜飼さんの入社エントリー記事です。乞うご期待!

Goalsでは一緒に働く仲間を募集しています!
カジュアル面談ご希望の方は↓こちらから。

この記事が気に入ったらサポートをしてみませんか?