見出し画像

Goalsのプロダクトが立ち上がるまで〜 HANZO自動発注の場合〜

あけましておめでとうございます。
株式会社Goals CTOの多田です。

GoalsのHPやnoteで公開しているインタビューでは何度か顔を出させていただいていますが自筆の記事を公開するのは初めまして、になります。拙いところが多々あるとは思いますがよろしくお願いします。

今回記事を書くにあたってなにを書くか非常に迷ったのですが、、今のところ私自身の特性としてプロダクトの0→1の立ち上げが一番の得意領域かなと考えているのでその周辺についてお話しさせていただければと思います。

具体的には、Goalsの主力サービスであるHANZO 自動発注の創世期の話をさせていただこうと思います。時期としてはコンセプトがやっと固まったあとぐらい。ヒアリングや調査を経て、自動発注の引きが強く、これでいこう、というのが8割ぐらい決まったあとでのお話しです。

この時期は代々木にオフィスを間借りしており、もはや記憶はあやふやですがおそらく社員数7人の時期です(2023/1現在で正社員56名)。



社員数7人で手一杯の代々木オフィス


コンセプト段階での決定プロセスなどは以下の対談記事で語っているので、未読の方はぜひ読んでいただけると嬉しいです。


この時点で数十社にはヒアリングを実施しており、手元には超ざっくり書くと以下イメージのような情報があります。

発注業務の課題 230点
 L 発注に時間がかかって大変 80点
 L 店長しか発注できる人がおらず属人化 80点
 L 店長が休みの日どうする問題 80点
~~~以下略~~~

ユーザー(この場合は飲食店)のペインがリストアップされており、点数付けが完了している段階です。基本的に顧客へのヒアリングをもとに、自分の主観をできるだけ排して重要度を決めていきます。

これと対になる要素として、これらの課題を解決するソリューションの案のリストがあり、期待効果・実現可能性などで点数づけしています。この時点で「自動発注」というソリューション案が最有力だったのでそれを実際の業務に適用し、ユーザーの課題を解決できるかを検証する、というのが次のステップでした。

お作法的に、検証の手法はいくつかありますが、HANZO 自動発注の場合は実プロダクトに近いMVPを作って、それを実際にユーザーに利用してもらう形で検証を実施しました。理由はいくつかあるのですが、検証したい項目のひとつに業務効率化という重要トピックがあり、たとえばエクセルなどのプロダクトの代替では検証が難しかったこと、などです。

この時点で協力してもらえそうなユーザーは何社か確保できていました。そもそもユーザーが確保できない場合はペインかソリューションの設定が間違っているのでその先のステップには基本進みません。

具体的にはあるファストフードチェーンのお店1店舗にてテスト導入いただけることになりました。

この段階でのプロダクトの完成度は、、ひいき目に見て30点ぐらいでしょうか。HANZO 自動発注は人間に代わってAIが日々の食材発注の数量を算出するのですが、この時点で算出される数字に自信などなく、バグも多々ありました。

とはいえこの段階で妄想のままゴリゴリ実装を進めても、実証されていない機能に工数と時間を使うことになるので、なるべく「後出しジャンケン」できるように工夫をします。

具体的には、店舗のタブレットに30点のプロダクトをインストールしていただいた上で、以下のように人力とのハイブリッドで検証しました。

  1. HANZOが自動で発注書を作る

  2. HANZOの発注書の数値を確認し、おかしそうなら人間が数値を直す

  3. ユーザーがプロダクトを操作し発注を行う

  4. 店舗に行ってユーザーに数値の妥当性やUIの不満点などをヒアリング

  5. フィードバックをもとにHANZOのアルゴリズムやUIを修正

これを2〜3ヶ月ほどの期間、毎日実施しました(土日は休みました)
最初の頃はHANZOが1億円の発注書を作ったりしたのを慌てて直したり・・・みたいなことも当たり前のようにありました(汗)

ヒアリング担当は私で基本毎日、夕方ごろ店舗に伺いました。1品なにかしらのメニューを頼んで時間を潰し、ピークタイムが過ぎたら店長を捕まえてヒアリング。最終的にその店舗のメニューは全て網羅しました。

普通に考えると店長も毎日ヒアリングに付き合うのは軽くない負担なので、お付き合いいただけたのが本当にありがたかったです。事前に我々が目指す効果や世界感の説明をきちんとすることには注意をくばりましたが、とはいえ前向きに協力いただき、本当に感謝しかないです。

毎日機能をユーザーに相談し、毎日フィードバックをいただき、毎日プロダクトに反映させる。

発注業務は基本毎日行われる業務なので振り返るとフィードバックサイクルもめちゃくちゃ速かったです。

「作る前に検証する」
「効率的な検証サイクルを設計する」

あとは日々の検証の中で改善や軌道修正をしたりしながら、うまくいっていれば手応えを掴んでいくことになるのですが個人的にターニングポイントとなったエピソードが一つあります。

検証を始めてから1ヶ月ほど、HANZOが作る発注書と実際のズレがなくなってきていいタイミングだと感じたので「アルバイトの方にも使ってもらいませんか?」と提案し、実施していただきました。普通発注を1人前にできるようになるには教育に1ヶ月くらいかかるのですが、この時やったことはHANZOの操作方法を10分ほどレクチャーしただけ。

翌日のヒアリング。「HANZOの作った発注書の通りに発注してもらって、トラブルはありませんでした。なんか・・・久々にちゃんと休めた気がします」とのコメント。

よくよく聞くと、これまではなんだかんだ休みの日も店舗に電話したり、アルバイトがシステムに入力した発注内容を確認したりしており、休みでも気が休まらなかったそうです。

まさにユーザーのペインをプロダクトが解消した瞬間でした。私にとってはこれはいける、と手応えを感じた瞬間でもあります。

ある程度フェーズが進んだ際は操作ログやアンケートなどのほうが効率的に情報収集できますが、初期はこれぐらい狭く・深くフィードバックをもらえる状態を作ったほうがユーザー業務の解像度が上がり結果的にプロダクトの改善サイクルとしては速くなるように思います。

実はこの店舗で半ばたまたま、うまく行き過ぎてこのあとの実プロダクトへの落とし込みで苦労することにもなるのですが・・・

それはまたのお話しということで。現時点で十分長くなってしまっていると思うので、一旦このあたりで終わりにさせていただこうと思います。

思い出話も多くなり恐縮ですが、プロダクト作りの現場のリアルを感じていただけたら幸いです。

最後に、基本的にはリーンスタートアップの思想や手法が大好きなのでそれを大いに取り入れているつもりです。

超有名な著書ではあるのでわざわざ紹介するのも気は引けますがプロダクト作りに関わる方で、まだ未読であればぜひ一読することをオススメします。

リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす


ただし、toBの業務システムでやろうとすると色々難しいポイントもあるのでそのあたりは私もまだまだ試行錯誤しながら、という感じです。

長くなりましたが、今回は以上となります。
ご拝読ありがとうございました!

もし、もっと聞いてみたい!Goalsに興味が湧いた!などありましたらMeetyでの面談ウェルカムですので、お気軽にお申し込みください。


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