＜STOREPAD開発ストーリー＞第二部 初期プロダクトの開発ストーリー
こんにちは、イクシアス株式会社COOの戸田です。
今回はSTOREPAD開発ストーリーの第二部です。
STOREPADの誕生秘話に関しては第一部を参照ください。
さて、今回はそんなこんなで誕生したSTOREPADの初期開発ストーリーです。
ここでは創業から1~2年くらいの試行錯誤を、下記の構成でお伝えしていきます。
3つのMVP開発と検証
初期の仮説検証は、創業者の知り合いの店舗を中心に進めました。
・対象業界は飲食、美容、クリニック、リラクなどが中心
・規模は個人経営から100店舗以上のチェーンまで
「複数媒体を運用する上での手間・課題があるか」、「一気通貫管理による工数削減や最適運用が可能か」、「そもそもどのような業務フローなのか」を中心に、いくつかの仮説はあったものの、どの業界・規模の顧客にニーズがあるか読み切れていない段階だったこともあり、特定の業界や規模に絞り切らずに幅広いニーズを探りました。
初期に開発を進めたMVPは、以下の3つのプロダクトを中心としています。
【集客】GoogleビジネスやSNS情報を一括管理する集客システム
Googleビジネス、SNSの情報を一括管理、運用できる現在の注力商材となるプロダクト【予約】ネット予約、即時予約サービス（一部業界向け）
GoogleやSNSで集客したユーザーに予約をしてもらうためのプロダクト【追客】LINEを活用したリピーター化支援システム
来店後の顧客との接点を維持し、リピート利用を促進するためのリピーター管理プロダクト
3つのプロダクトの裏側で共通のCRMを持ち一気通貫で管理できる統合型のソリューションとして開発を行いました。
開発力に自信を持っていたので、初期に集客・予約・追客システムで三社分くらいの領域で検証をしたのではないかと思います。
またMVPといってもしっかり販売し価値提供ができるレベルまで各プロダクトを開発しており、1~2ヶ月くらいで企画から開発までを行い各プロダクトの販売開始できるレベルまでスタートすることができました。
スピーディーに開発を進められた背景
なぜ開発スピードが早いのかと聞かれることもありますが、まずMVPの段階ではCTOの開発スピードに大きく依存していました。
ただ開発が早いというだけでなく、ビジネス解像度を持ち口頭での会話でもイメージのすり合わせができていたため、初期開発において要件定義の工程を大きく減らすことができスピーディーな開発を進めることができました。
現在も開発チームはただ言われた内容を開発するのではなく、背景やビジネス要件も汲み取り自走できる強いメンバーが揃っており、開発の文化として根付いています。
また、私もCSを兼任し、減らした要件定義の時間をできるだけたくさんのお客様と会う時間にあてました。
直接対面で訪問する時間をつくり、ただお客様から意見や課題を教えてもらうだけでなく、特に業務フローを伺ってどこに見えない課題があるのかを把握・観察する時間を意識的につくりました。
そこでの発見を週3回実施していた開発MTGでフィードバックし、即実装を進めるサイクルで高速開発を実現しました。
MVP検証を進めた中で見えた課題
開発自体高速で進められましたが、一方で複数のプロダクトを同時に開発することのリソース的な厳しさも痛感しました。
特に、開発後のオンボード・サポート業務が負担となりました。SaaSプロダクトなので当然すぎるのですが、開発して終わりではなくむしろ継続して使っていただく上でのオンボードやサポートが重要です。
そういった中で複数プロダクトの各仕様を細かく把握しつつお客様にあわせ運用までをサポートしていく作業は属人性が高まりやすく、大規模化をしていく中でのチーム編成を含めての課題も見えました。
私自身、SaaSプロダクトの開発は初めてだったので、オンボード・サポートの大変さを正直甘く見ていました。この初期の経験が弊社がカスタマーサクセスの重要性を再認識し、今も力を入れてCS体制を構築しているキッカケになっており、また、システムでのサービス提供だけでなく弊社CSが運用を代行することでお客様のDXを実現する運用代行サービスが中小企業を含めた業界のDX挑戦の鍵となるという考えにもつながっています。
プロダクトの反響とMVPからの進化
さて、プロダクトに関してですが業界にもよりますが初期から想定より前向きな声を多数いただきました。
特に集客プロダクトに関しては「業務の手間が大幅に減った」「集客が増えた」など多くの反響をいただき、現在も土台となるサービスとして注力しています。
検証を進めての気付きとしては下記のようなものがありました。
１．一括管理サービスにおいて、業界特化機能が必要
STOREPADはGoogleビジネスとSNSの一括管理サービスとしてスタートしましたが、各業界の主要媒体にも対応していくことが必要だと痛感しました。
例えば飲食業界を例にすると、営業時間を更新する際にGoogleやSNSをまとめて更新できるだけでも価値がありますが、食べログのような業界主要媒体もあるわけで結局そこまで更新できないと真の一括管理にはなりません。
STOREPADでは業界ごとの機能装着を重要視しており、例えば飲食業界向けには食べログやホットペッパーといった業界主要媒体を含めた「口コミ」「メニュー」「営業時間」などの一括管理・更新サービスを提供するようになりました。
※参考：STOREPADの飲食業界向けの強化機能
２．複数店舗、個店向けの機能分けの必要性
STOREPADはどちらかというと本部のマーケティング担当者様向けにスタートしましたが、本質的にさまざまなお客様のDXのご支援をするには、各店舗や個店で活用いただくお客様に最適な機能/UI提供の必要性も感じました。
なので本部の方に使える機能をベースにはしつつ、
・Instagramの投稿を自動でGoogleビジネスや各種業界媒体を含め反映できる機能
・スマートフォンで口コミを簡単に確認、返信できる機能
・簡単にホームページが作成できる機能
など個店の方が使いやすい機能拡充も行いました。
３．一気通貫ニーズ有るも、まずは当社のみの価値提供機能中心のご案内から
多媒体で集客を行い、予約を獲得しCRM構築からのリピーター化をする、全てが1サービスで出来るのが理想でありニーズもあります。
ただし、予約管理などのソリューションは既に存在しており業務ごとにツールを分けて使っていたり、たくさんの人が関わっているなかで、運用を一気に変えるハードルは高く、スタートアップとして、また、お客様の負荷を考え、まずは当社ならではの価値提供が強い多媒体での情報発信&口コミ管理・分析領域を中心に価値提供させていただいてDXを進化していただき、本質的なDXのご支援に向けて徐々に他の領域でもご支援をさせていただく流れでの現場装着、伴走が最適、つまり選択と集中→広範囲支援の流れを意識した展開をするにいたりました。
次回
今回は、簡単にSTOREPADの初期開発ストーリーをまとめましたが、1~2年で他社が実現できていないレベルまで開発を進めサービス構築ができたと自負しています。
ここに書ききれないたくさんの気づきがありましたが、その気付きから今も開発を進めており、次回のnoteでは、STOREPADが国内媒体連動数No1になるまでをお伝えできればと思います！