2年間のVertical SaaS立ち上げフェーズ、開発者目線で意識的に取り組んだこと4つ
スタディスト開発ブログ Advent Calendar 2021 の 24日目の記事です。Hansoku Cloud 開発グループのマネージャーをしている zuckey が担当します。私は2020年の頭に Hansoku Cloud という新規事業のリードエンジニアとして入社し、今では Engineering Managerとしてチームビルディングしつつ、Hansoku Cloud プロダクト側の責任者をしています。
本エントリでは小売企業向けのVertical SaaS である Hansoku Cloud のこれまでの立ち上げフェーズを開発の立場から振り返り、ここに工夫していたな、思い切ってやって良かったな、という取り組みを紹介しようと思います。
1. プロトタイプでガッツリ価値検証
いきなり製品版の開発から始まるサービスはいまやほとんどありません。コアの価値を確かめるためにプロトタイプの作成からはじめました。
小売企業の本部が企画した商品の店頭での陳列状態を写真でつぶさに把握できるようにし、今後の企画などに活かすことができたり、指示の最適化により売上を最大化できたりする、というのが Hansoku Cloud の初期のアイデアです。
そこでFirebaseの各ツールとGoogle SpreadSheet とを連携して、写真を収集し、データを集計して簡単なグラフを出力できる仕組みを作りました。
実際に数社のパイロット顧客を獲得して実際の店舗で利用された結果を見ることができました。店舗群を分けたA/Bテストなども利用し、これは考えていたような価値を提供できそうだぞ、と自信を持つことができました。
また、結果を見た顧客から私達が考えていなかった良さもフィードバックをいただくことができ、夢をふくらませることもできました。動くものを用意でき、現場で使われるというのはすごく幸運な状況です。
弊社のコア事業であるTeachme BizはHorizontal な SaaS であり、小売企業の顧客にもお使いいただいています。その既存の顧客にアプローチすることでこのプロトタイプによる価値検証が実現しました。この動きはシンプルに会社の強みだなと思いますし、新規事業の担当者からすると本当にありがたい限りです。
2. チームメンバーのサービスへの解像度を高める
プロトタイプによって価値に自信を持てたら次は製品としてリリースできるものを作ります。
まずは、登場人物の業務を時系列に並べ、プロダクトとのタッチポイントを洗い出しました。いわゆるサービスブループリントと呼ばれるものを作る活動ですが、目的はユーザー体験の向上というよりは、サービス全体についてチームメンバーの共通認識を作ることでした。
小売企業出身の事業部長に質問をぶつけながら、下のようなものを作りました。製品版リリースの後もことあるごとに立ち返っています。
現在では更に理解を深めて、時系列を大きな1つのプロセスとして見るのではなく、PDCA（Plan / Do / Check / Action）の4つのプロセスに分けて捉えています。
これによって、開発予定の機能がどのプロセスのどの問題を解消するものなのか共有しやすくなり、要件の検討がスムーズになりました。また、「顧客にPDCAを回してもらうにはどうアプローチすべきだろうか」という会話が頻繁にあわられるようになっており、チームの前提が揃ったよい試みだったと思います。
3. 可能な限り作りすぎない
Vertical SaaS は特定の業種に特化したプロダクトであり、顧客の業務フローにガッツリと寄り添うように作ります。そのため、導入となると業務を変えうるモノが多い印象があります。ハマると効果は大きいものの導入には慎重になるでしょう。
また、業務に寄り添うがために顧客からの機能への要望も増えます。できる限り既存の業務を変えたくないはずです。既存の基幹システムとスムーズに連携できたり、今運用している組織構造を元にリソースの管理をしたくなります。
一方でコアではない機能を早めに作ってしまうのは少数の企業への過剰な最適化となる怖さがあります。リリースした機能のUIを大きく変更したり、取り下げたりするのは大きなハレーションを生みかねません。そのため、可能な限り作りすぎない、というのをベースに社内外でコミュニケーションしてきました。
とはいえすべての機能開発を却下するわけではありません。CSVなどを介してマスターデータを取り込んだり、DBのデータをCSVとしてエクスポートして手で集計する仕組みを用意したりするなど、できる限り「やりたいことは概ねできる」と感じてもらえるよう意識しました。
ほんとに作る必要あるんですか？誰が使うんですか？どのくらい使うんですか？と毎回ネチネチと聞いていると、開発とそれ以外での対立構造を生みかねません。なので、やろう！と決めた機能についてはスケジュールの期待を裏切らないように慎重に調整するなどして信頼を得ていくなどしていきました。
一方で、勇気を出してつくる決断をしたものもあります。先日AdventCalendar の8日目 に書いたネイティブアプリ開発は、一部の顧客の強い要望がきっかけで検討し開発しました。バランスを取るのは難しいですが、要望は山程出てくるので、基本的に作りすぎない姿勢を取り続けるのが重要だと思います。
4. 顧客企業の組織図を作ってみて開発すべき機能を見極める
事業を前にすすめるには製品をリリースするだけではなく、売上を上げていくことも重要です。そのためには、顧客に予算を獲得してもらう必要があります。決済者は誰で、その方が日々追いかけている数字は何なのかを把握できると効率よくサービスの価値を訴求できますし、チーム内で機能開発の優先順位を話しやすくなります。
そのため、顧客の会社の組織図を書き出しました。企業内の各部門の関係を洗い出し、今繋がることができている人をマッピングし、導入に反対している人、導入に肯定的な人、フラットだけどキーマンになりそうな人などを可視化していきました。
私自身商談に同席させていただいたり、議事録も日々すべて共有いただいていますが、この活動を通して日々の定例での営業の方の「〇〇の△△さんがこんなことを言っていて〜」という発言がイメージしやすくなりました。
また、作った組織図をお客様に見せてみて反応を伺うなどもしました。導入に肯定的な担当者の方から、別の部署を説得するためにこういう機能がほしい！といった具体的な要望もいただけるようになりました。結果、顧客とともにプロダクトを共創している感覚が強くなり、自信を持って開発に着手できるので、このフェーズでは良い試みだったと思います。
まとめ
2年間、思いつくことをやってみました。そして振り返ったときにやってよかったことを紹介しました。並べてみるとよく言われるようなことばかりかなとも思います。「Vertical SaaS」と題名には大きく打ち出していますが、関係なくSaaS全般の初期フェーズの開発で効果があるものなのかなと思いました。
さいごに
スタディストでは “伝えることを、もっと簡単に” していけるメンバーを広く募集しております！少しでも気になる方は気軽にご連絡ください！
明日はCTOである佐橘が Advent Calendarの最後を締めくくってくれます！また、来年以降も開発ブログを更新していきますので、よければTwitterアカウントのフォローをお願いします！
