STORES のプロダクトマネジメントの裏側について話すイベントを実施しました。

hey（現：STORES）が創業し、丸6年。創業時からマルチプロダクトの会社を作っていくために経営統合やプロダクト統合を行ってきました。現在、さらに深い顧客課題を解決していくために新規プロダクトの開発を続々と進めており、まさに第二創業期といえるフェーズです。

今回は、CPOとプロダクトマネージャー（以下、PdM）2名が登壇し、マルチプロダクトをどのようにつくっていくのか、新規プロダクトを生み出すためにどのような取り組みを進めているのかを話してもらいました。

本記事はイベントの書きおこしになります。

STORES の紹介

井出： STORES の紹介を僕の方からできればと思います。
STORES という名前から、「ネットショップの会社だ」と思われていることがすごく多いなと感じています。
それも間違ってはいないのですが、実は今プロダクトが7つ（イベント当時）あります。
「ネットショップのサービスだけが利用者が多い」という訳ではなくて、キャッシュレス決済やネット予約とかを含めて、それぞれ同じぐらいの利用者がいます。

元々2018年に「STORES.jp」と「Coiney」が合併してできており、お店と顧客を直接つなぐ「フロントオフィス」業務をデジタル化するプロダクトを提供する会社になっています。

複数プロダクトが提供できるようになり、そのプロダクトを繋げて利用できるようになったり、繋げる為の仕組み・基盤を作りながら、その上に更に新しいプロダクトをどんどん増やしていくということを足元やっています。

西岡さんから今年リリースしたレジと予約を連携したプロダクトについての話も後ほどさせていただきますが、今年はあと3つ新しいプロダクトを出して、更に来年には、より多くのプロダクトをプラットフォームの上で利用できるようにしていきます。
単体のプロダクトだけだと小さくて狭い課題しか解決できないこと、お客さんや従業員の活動のデータとかをちゃんと集めながら課題解決にアプローチするには、プロダクト数を増やしていく必要があるからです。フロントオフィスはバックオフィスと比べてかなり自由度が高く、商売を提供する際のオペレーションとか、提供サービスが確立的ではない方がブランドとして価値が高い領域になってくるので、やることが多様になっていきます。

多様なことができつつ、データを統合し、経営や事業運営に活かしていくことができるような仕組みが求められ、足元はマルチプロダクトにしてデータをきちんと集めることをやっているんですけど、最近はAIとか、LMMみたいなものがすごい進化しているので、本当にデータを入れてAIが認識して利用できるようにすると、すごい効率が上がったりとか、便利に使える世界ができあがりつつあります。
我々はこういった店舗や店員さん、お客さんのデータをきちんと統合し、お店がやりたいことを実現しながらきちんと経営支援をしていくという段階に数年かけて登っていきたいなと思っているところで、その基礎的な部分としてプラットフォームとか、その上に乗っていく新しいプロダクトをどんどん増やしているフェーズとなっています。

STORES のプラットフォーム開発の裏側

淺田：さきほど、井出さんから話があったように、今 STORES では、お店のフロントオフィス業務として7つのプロダクトを提供しています。
私が担当している STORES プラットフォームは、それぞれのプロダクトを使っていただいてる事業者の方たちに、いかに複数のプロダクトを使ってもらえるか、をミッションにしている領域のPdMとなっています。 
私が入社した時は、クロスユースしてもらいたいと思ってはいるものの、元々 STORES という会社が色々な会社と統合してできた会社ということもあり、ブランド名は STORES という形で全部統一はしてたのですが、ログインするIDもバラバラになっていて、複数のプロダクトを使ってもらいやすい環境ができていない状況でした。そのプラットフォームという領域において、複数のプロダクトを使いやすい状態にしていくというところを進めています。

ようやく昨年、バラバラだったログインIDを全部のプロダクトで共通の STORES アカウントというもので、ログインできるような状態になりました。 
新規の事業者の方たちは、STORES アカウントだけでログインできる状態なのですが、まだ以前のID使ってる人たちもいらっしゃるので、今はその人たちにのせ替えみたいなところも引き続きやっています。 

OMO（※）領域では顧客情報が統合されているということが価値になっていきます。例えば、お店に新しく従業員が入った時に権限を追加する場合、それぞれのプロダクトで権限設定をしなければいけなかったり、新しく店舗を作る場合に各プロダクトでオンボーディングしなければいけなかったりするので、店舗、従業員というところを全部のプロダクトで共通にし、一括でできるようになるものを作れるよう、取り組んでいます。

（※）Online Merges with Offline／オンラインとオフラインの統合

さらに今年新たな挑戦でいうと、請求書も今までバラバラで事業者の方たちに発行していたので、請求についても統合する動きをしています。

では、なぜここまで統合していきたいのかで言うと、先ほど軽く触れましたが、オンラインとオフラインを統合したフロントオフィス業務の部分が STORES の今後の価値になっていくのではないかと考えているからです。
事業者の方たちがクロスユースしやすくなるようログインIDを同じにしたり、何度も同じ設定しなくていいようしたり、請求や支払いがすぐ分かるようにするというところは、どちらかといえばオペレーションが楽になるというところだとは思っていて、今私たちのプロダクトを複数使ってくださってる事業者の方たちが、いちばん「価値」だと感じてくださっているところはどこなのか、を考えると、やはりオンラインとオフラインで顧客情報が統合されてるところが1番大きいかなと思っています。

ネットショップも実店舗も持っているお店でいちばんお店に貢献してくれてるお客さんは、オンライン・オフラインの両方で来てくれる人です。
私達のプロダクトを使ってもらえば、すぐに顧客情報が可視化されますし、ネットショップも実店舗も両方利用してくれているお客さんの割合を増やすためにどういう施策をしていけばいいか考えることにお役立ていただいたりとか、私達のプロダクトを使って施策を打っていただくことが出来るかなと思っています。

顧客情報だけじゃなくて売上をまとめて見ることができ、分析もできるというところも価値になっていくと思いますし、細かいところで言うと、在庫も共通化されていることで、効率良く在庫を回すことができたりするので、統合することで、STORES を使う価値をより感じていただけるんじゃないかなと思ってます。

STORES プラットフォーム構築の際に意識をしていること

淺田：とはいえ、さきほどあげたようなプラットフォームを色々作っていかなければいけない中で、どういう順番で作っていっていいのか？や、どうやって作ってるの？と思う方もいらっしゃるかと思うので、今日はそのあたりもお話します。
今、私たちは、現場から求められたものからというところと、小さく導入していくというところを心がけてやっています。先回りして基盤を作っていくことも、もちろんできるんですが、各プロダクトに利用してもらえないと何も意味を成さない形になるからです。

現場から求められたものから、でいうと私の過去の経験がありまして。以前勤めてた会社でも、プラットフォームを作ったことがあるのですが、その際、前もって先回りして色々作ってはいたんですが、それを使ってくれる人が増えていかないと、なんとなくプラットフォームという箱を作っているだけになってしまう、という経験があったので、ちゃんと利用してもらえるような基盤を作っていかなきゃなという反省をもとに STORES では利用してもらえる人がいるものから作っていくということを心がけています。 
やっぱり利用してもらえる人がいるところのメリットはあって、困っているからこそ、きちんとしたユースケースが分かって、実のあるものが作れるなというところは、このやり方にしたことで感じています。 事前に先回りして作るというのは想像だけでやっぱり作ってしまう部分があるので、結局使い物にならず、作り直しになることが結構頻発するのですが、「このプロダクトでまず使ってみましょう。 こういうユースケースで使いますよ。」というのが分かっていれば、作り直すことがないので、前進するのが早いなと思っています。

あとは、これからもプロダクトを増やそうと考えると、なにか新しい基盤を作ろうとする時に、理想を考えていたら要件がどんどんどんどん膨れ上がり、議論してるだけでコードが一行も取り掛かれない状態になってしまい、全然前進していかないので、まずは、小さいスコープで考える。最初に使いたいプロダクトが本当に必要な要望だけで、作っていくというところを心がけています。
とはいえ、「そのプロダクトがすごくニッチなケースだったらどうするんだ」というところは、気を付けなければいけないところで、明らかにそのプロダクトだけしか使わないような機能やユースケースは作らず、それはプロダクトでやってもらうようにしていたりしています。

とはいえ、拡張性がない作りにしてしまうと、また1から作り直さなければいけないことになってしまうので、スケールできるような作りにはしておきます。しかし、そのために仕様を最初から複雑にしてしまうとスケールしづらくなるので、シンプルな作りにしておくというところも心がけているところです。

STORES の プロダクトマネージャーに求められる役割と機会

向原：ありがとうございます。プラットフォームの視点で、PdMに求められる役割と機会はどういったものになるのでしょうか。

粘り強く、着実に統合を進めていく

淺田：プラットフォームで言うと、粘り強く、着実に統合を進めていく推進者みたいな役割が求められます。 表側に出て事業者の方たちに喜んでもらえる機能を作っていくというよりは地味な作業が多いですし、色々なプロダクトの事を考えなければいけないので、考えることは多いというところはあります。なので、全てのプロダクトの仕様を把握する必要はもちろんありますし、一言に「統合」と言っても、やはり本当に地味なんですね。

例えば、ID統合する時に、IDにその使う人の名前みたいなのがあったりするわけですが、名前統合すると言っても、プロダクトによっては姓と名が分かれてるものもあれば、一緒になってるものもあるので、それをどうやって統合するんだっけ？みたいなことを考えていかなければいけなかったりしますし、プロダクトの数が増えれば増えるだけ条件が増えていくので、複雑なパズルができていくみたいなところがあったりします。
あとは、ただ仕組み作るだけで終わりではなくて、この仕組みに全てのプロダクトがのっていくようにサポートしなければいけなかったりもしますし、それを作ってるうちにまた新しいプロダクトが生まれるみたいなこともあったりするので、短期で結果は出ないですが、諦めずに登り続けていくことが求められるなと思ってます。

答えがどこにもないので自分で決めていく

淺田：答えがどこにもないというところが、1つの難しさでもあり魅力なところでもあるかなと思っています。プラットフォームの統合をしている会社はたくさんありますし、ブログとかにも色々書かれていたりとかしてると思うのですが、どうやって統合し、どうして統合しなければいけないかというところは、やはり企業によって事情が異なるので正解がないということだと思っているので、正解を自分で決めて進んでいくしかないというところは、難しさでもありますし、自分で決めていくという楽しさでもあるかなと思ってます。

「地味で複雑で何が楽しいの？」と思うかもしれないのですが、1つのプロダクトを作っている時では、経験できないような経験や成長を積むことができるところは、このプラットフォームという領域のいいところじゃないかなと思ってますし、当然、複数のプロダクトがプラットフォームを使うとなると、複数のチームが混成したメンバーでプロジェクトチームを作ってそれをビルドしてリードしていくという経験が積めるのも楽しいんじゃないかなと思っています。

短期的な成果を求められるもの作りではなくなってくるところではあるのですが、私が STORES に入社した理由もそこで、やはり短期的に成果を求められると、どうしても目の前の小さい施策を優先しがちなのですが、この会社入社した時に、CEOの佐藤さんから「5年後10年後ナンバーワンなれるように腰を据えてプロダクトを作ってほしい」と言われ、そういう環境で仕事できたら楽しいだろうなと思って私は STORES に入ったので、そういう長期的な目線でプロダクト作りをしていきたいという方いたら、ぜひ一緒に働きたいなと思ってます。

（後編へ続く）

＼ STORES では一緒にはたらく仲間を募集中です！／