to B SaaSのつくりかた
今月からマネーフォワードビジネスカンパニーでMid Market 領域のCPO（Chief Product Officer）を担当することになりましたヒロハラです。
突然ですが、ここ数年で日本でも一気にto B SaaSが増えてきたなーと思います。スタートアップなどで、PdMとしてゼロからサービスの立ち上げを経験される方も増えてきているのではないでしょうか？
私自身も、PdMとして、今年6月にリリースしたマネーフォワードクラウド固定資産というサービスの立ち上げを担当しました。
そこで今回は、地味ながらも難易度が高い、to B SaaSの立ち上げにフォーカスして、特にサービスの企画開始から開発開始するまでの初期段階でPdMがこだわるべきポイントについて書いてみたいと思います。
なお、今回の内容は教科書的なものではなく、あくまで私個人がこのようなことに気をつけながら取り組んできたという内容になります。かなり長文になってしまったのですが、そんな考え方もあるんだなー程度に読んで頂けたらうれしいです！
はじめに
サービスの企画開始からのStepを改めて振り返り、ざっくりまとめると以下のような感じになります。
・徹底的にリサーチする
・できるだけ解像度高く理想の完成形を描く
・描いた完成形が本当に理想的なのかを広く深く検証する
・大胆に優先順位をつけながら広げた完成形を畳む
・ゆずれないポイントは自らfeasibility studyする
・最低でも１回は作り直しが可能な開発スケジュールを引く
ポイントとして、それぞれのStepで使うアタマが変わるので、いまは何にこだわるべきフェーズなのか、どのアタマを使うフェーズなのかを強く意識することが重要だと思っています。
それでは、それぞれのStepでこだわるべきポイントを中心に書いていきたいと思います。
[Step.1] 徹底的にリサーチする
まず、最初のStepは、リサーチです。
個人的には、このStep.1で、これから作るプロダクトの成否の8割くらいが決まると思っています。
このStepのポイントは以下のとおりです。
・狭い範囲でリサーチして満足しない
・浅い理解のまま次のステップに進まない
・ヒアリングしない
新しいサービスの企画を開始すると、PdMが「どんなサービスがあるとうれしいですか？」「どんなペインがありますか？」などといきなりユーザーヒアリングを始める、というパターンを見ますが、これは完全にNGです。
そもそも、PdMには、そのサービスを通して解決したい課題、実現したい未来があるはずです。それをいつでもどんなときも、まず語ることが重要だと思っています。
最初は、「経理部の決算業務を楽にしてあげたい」といったおぼろげなイメージでもよいので、たくさんの人に自分が考える世界観を語ることがスタートです。そして、その内容にユーザーや社内のメンバーがどのように反応したか、ココロに響いているのかイマイチなのか、聞き手の表情やニュアンス含め、細かくキャッチしていきます。
もし反応がイマイチならば、なぜ響かないのか、相手のバックグラウンドはどんな人なのか、必死に考えて原因を探っていきます。これを繰り返すことで、ペルソナやマーケットに対する解像度があがり、プロダクトを通して実現したいビジョンの語り口もどんどんブラッシュアップされていきます。
ここを妥協せず、できる限り多くの人たちに対して行うことが重要だと思います。身近な数人にだけ話して満足してしまう人も多いですが、それではたくさんの人に愛されるサービスにはなりません。
リサーチというと、ユーザーに聞く、専門家に教えてもらう、といったことをイメージする人が多いと思いますが、ここで必要なのは、「自分がサービスを通して解決したい課題と実現したい未来のビジョンに対して、マーケットがどのような反応を示すのかを徹底的にリサーチすること」です。
自分がイメージするプロダクトビジョンを聞いて多くの人がわくわくしている、という結果が得られるなら、あとはそのプロダクトが作れさえすれば、確実に成功します。もちろん、作れさえすれば、がそんなに簡単ではないので、次のステップ以降に進むことになります（笑）
[Step.2] できる限り解像度高い完成形を描く
次のStepとしては、とにかくサービスのイメージをできる限り広げて、解像度高い最終完成形を描くことです。
アジャイル開発が浸透し、ムダなものを作らない、できるだけ小さくスタートする、といったことが強調されるあまり、広げることが軽視されることがありますが、個人的にこのStep.2が非常に重要だと思っています。
このStepのポイントは以下のとおりです。
・限界まで広げる
・サービスの目的とメリットを明確化する
・実現可能性を意識しない
ここで重要なのは、とにかく限界まで広げることです。
意外とよく見かけるのが、実現可能性や工数を最初から意識して、広げることにブレーキをかけながら、結果的に小ぢんまりした世界を描いてしまうというケースですが、これはNGです。
いまは、とにかく広げることに集中するんだと自分に言い聞かせながら、発想を膨らませることだけにアタマを使います。実現可能性は意識せず、どんな世界が理想なのか、最終的なゴールはどんな姿なのかを描いていきます。
ユーザーストーリーマッピングを取り入れているようでしたら、USMの左右、上下を可能な限り広げて、ストーリーを可能な限り書き出していくイメージです。
広げる際に軸となるのは、そのサービスをなぜ作るのかという「目的」と、誰にどんな価値を届けるのかという「メリット」です。
その目的を達成するためにはこんな機能も必要だな、とか、このメリットを提供するにはこういったUXが欲しいな、などと、次々発想を広げていきます。必要な要素を漏れなく洗い出すというのがここでは重要です。
そして、このStepでの理想的なアウトプットは、サービスの最終完成形のデモを完成させることです。さすがにそれは厳しいにしても、最低でもサービスのLPが完成している状態は目指したいです。
マネーフォワードクラウド固定資産では、このタイミングでデモ前のプレゼンが行えるアウトプットを作成しました。初めて社内で発表したときには、たくさんの人からポジティブなフィードバックや応援の言葉を頂いて、とても嬉しかったのを今でも覚えています。
[Step.3] 描いた完成形を広く深く検証する
Step.3では、前のStepで考えた最終完成形の検証を行います。
ポイントは以下の通りです。
・できるだけ多くのユーザーからのフィードバックを同時に集める
・アンケート等を活用して分析可能な定量データを集める
・ユーザーインタビューではヒアリングをせずデモをする
このStepは、最近のITの進化によって本当に進めやすくなりました。
マネーフォワードクラウド固定資産の立ち上げ時には、Google Formを使ったアンケートと、Zoomを使ったユーザーインタビューを行いました。（ご協力頂いたみなさま、本当にありがとうございます！）
まず、アンケートで得たかったのは、マーケット全体の傾向や偏り、業務やシステムの規模感（広さと深さ）と、例外的な業務が発生する確率です。
例えば、固定資産の件数が何件あるか程度の情報であればある程度想像がつきますが、年間に発生する除却の件数は？とか、減損が発生する頻度は？などになると、正確にイメージするのは難しいです。また、圧縮記帳はありますか？増加償却はありますか？といった例外的な業務は、不特定多数にアンケートを取ることで、おおよその発生確率やどのようなタイプのユーザーで発生する可能性が高いかなどの傾向を知ることができます。
SaaSは、全てのユーザーが同じシステムを利用することになります。このアンケート結果によって、より多くのユーザーにとって心地よい汎用性の高いシステムとはどんなイメージなのかの解像度をあげていきます。
次に、ユーザーインタビューですが、こちらはStep.1と同じマインドで行います。
ヒアリングするのではなくStep.2で作成した理想的な完成形についてデモを行いその反応を得るのが重要です。デモを行うことで、ユーザーからは「こんなことはできる想定ですか？」とか「あんなこともできるといいですねー」と言った、具体的なフィードバックを得ることができます。そんなフィードバックや反応から、マーケットの深さを理解し、より詳細にデモをブラッシュアップしていきます。そして、ここでは1社の意見に引っ張られないように、できるだけ短期間でたくさんのユーザーにデモすることも重要になります。
このStepでの理想的な成果は、まるでリリース後のサービスに対しての要望かのような、リアルで具体的な要望リストを得ることです。
一般的にはリリースしてはじめて得ることができるリアルな要望を、プロダクトの開発前に得ることができれば、開発開始前からリアルなプロダクトバックログを積むことが可能です。そのためにも、できるだけ精度の高いデモを行い、リアルな要望リストを得ることに一番こだわることが重要です。
そして何より、このタイミングで何としても得ておきたいのは、「このサービスがリリースされたらぜひうちの会社でも使いたいです！」という声です。
もし、そのような声が思ったように得られなかった場合、私はStep .1や2に戻ってやり直すようにしています。
[Step.4] 大胆に優先順位をつけながら広げた企画を畳む
Step.3までで、かなり解像度高い最終形のイメージが完成しました。
このStepでは、広げきった最終形イメージを大胆に畳んで1stリリース時点のイメージを固めていきます。
優先順位順に整理され、MVP（Minimum Viable Product）、もしくはMSP（Minimum Sellable Product) のラインが引かれることで、ユーザーストーリーマッピングが完成するイメージです。
ここでのポイントは以下の通りです。
・絶対に売れるにピンを留めた上で、可能な限り機能を削ぎ落とす
・開発の都合も考慮して決める
・１人（最大でも２人）で決める
SaaS開発において、MVP、MSPというワードはかなり意識すると思います。
私の場合は、1stリリース時には必ず複数社の受注を達成すというところにピンを留めているので、MVPではなく、確実に売れる最小限のサービス（MSP）を強く意識しながら、大胆に畳むようにしています。
このタイミングでは、Step.2の広げるとは全く別のアタマを使います。いまはとにかく切り落として必要最小限にすることに集中するのだと自分に言い聞かせて、大胆且つ繊細に進めていきます。
もう1点、開発の都合も考慮して決めるというのは意外に思われるかもしれません。ユーザー価値で決めるべき、という声が一般的だと思います。ただ私は、このタイミングでは開発の都合も考慮するようにしています。
例えばビル建設に例えると、50階建てのビルを建てたくて3階までできたタイミングでオープンしたい（1stリリース）というケースがあったとき、最初に、将来50階建てでも耐えられるだけの基礎を作る必要があります。ここを、基礎は後回しでとりあえず3階建てを作ってオープンしてから50階にするのはその後考えれば良いや、と進めたら、結局ビルの建て直しになってしまうのはイメージできると思います。また、例えば、オープン時は7階だけしかいらないんだよなーと言われても、そんなビルは建てられません。必ず1階から作る必要があります。
システム開発でも同じように最終的なゴールにたどり着くために、最初に工数をかけて開発しておかなければいけない基礎、というのがあります。これは完全に開発の都合ですが、なるべく将来に負債を生まないよう意識して優先順位を決めるようにしています。
そしてもう1点、ここは賛否両論ありそうですが、私は１人で（最大でも２人）決めるというのも重要視しています。
３人以上が集まって決める場合、どうしても多数決で決めると保守的な結論になることが多く、結果、無難でつまらないサービスになりがちです。
後発の新サービスが、確実に売れる最小限のサービス（MSP）を実現するためには、かなりエッジの効いた差別化要素を含んだ構成になっている必要があるので、保守的な結論に向かわないようにするためにもMSPは１人で決めるようにしています。
チームの合意で決めるべきなのではという意見もあると思うのですが、そもそも、これから一緒に開発をするエンジニアやビジネスメンバーの想像を超え、みんながわくわくして共感してくれるMSPが描けないようでは、そのサービスの成功はありません。
１人で決めるというのは、決して独りよがりで決めるという意味ではなく、MSPを描くことはPdM自身の最大のミッションであるということを強く意識して進めています。
[Step.5] ゆずれないポイントは自らFeasibility Studyする
Step.4で、ついに1stリリースのイメージが固まりました。
あとは作るだけ、となりそうですが、もうちょっとだけStepがあります。
Step.5では、それが本当に作れるのか自ら前もって検証します。
ここのポイントは以下の通りです。
・いざ作り始めたら、「無理です」と言われることは結構あることをあらかじめ意識しておく
・PdMも自ら設計〜実装のシミュレーションを行い、開発中にぶつかる技術的課題と解決策をイメージしておく
・特に重要なポイントの実装方法案は複数パターン考えておく
ここは、エンジニアやテックリードの仕事じゃないの？という声も聞こえてきそうです。それはその通りです。
ただ、エンジニアやテックリードから「やっぱりこれは作れないですね」と言われたとき、PdMはどうすればよいのでしょうか？ただ諦めるのでしょうか？
Step.4までで、全力で理想の最終形を描き絶対に売れるMSPを描きました。このMSPは必要最小限まで削ぎ落としていますから、どこか１箇所でも開発できなかったらそのサービスはリリースしても売れないことになります。
そうならないよう、絶対にゆずれないポイント、壁にぶつかる可能性があるポイントについては、PdM自身があらかじめ想定し実現可能性の検証を行っておくのが望ましいと思います。もちろん、エンジニア経験や知見が無いとできないことではあるのですが、逆に言えば、ある程度のエンジニア知見はPdMには必須だと思います。
私自身は、マネーフォワードクラウド固定資産の開発においては、このサービスで最もコアとなる、減価償却計算のプログラムと、資産の異動履歴を管理するデータ構造の部分については、開発開始前に自分自身で全て設計や実装を検証しました。これを事前に行うことで自分自身の不安も減り、プロダクトの成功確率があがったのは事実だと思います。
なお、ここで検証した実装案は、最初からエンジニアに伝える必要はないと思います。もし開発が進む中でエンジニアが迷ったり、うまく開発できないという雰囲気を見せ始めたときに、はじめて伝えてあげて、諦めず一緒に前に進められるようにサポートするのが良いのではと思っています。
[Step.6] 最低でも１回は作り直しが可能な開発スケジュールを引く
いよいよ開発開始まであと少し、最後のStepです。
Step.6は、最低でも1回は作り直しが可能な開発スケジュールを引く、です。
ここでのポイントは以下の通りです。
・MVPは、リリースまでのスケジュールの30〜40%くらいまでに完成させるスケジュールとする
・MVP完成後ユーザーテストを行い、戻りに対応できるスケジュールをあらかじめ確保しておく
・ユーザーフィードバックを受けての改善を、本当に実施する
MSPも決まり、いざ開発開始となると、大体ざっくり1stリリースの日に向けてスケジュールを立てるのではと思います。
例えば、リリースまで丸1年あるとした場合、ざっくり10ヶ月くらい開発して最後の2ヶ月はテストとバグの修正、でも少し開発が遅れてしまってちょっとテスト不十分でリリースになるかも、みたいなスケジュールを引くことが多いんじゃないでしょうか？
ここでは、このスケジュールこそがNGパターンです。
マネーフォワードクラウド固定資産の開発時には、リリースまで10ヶ月の開発期間を、4ヶ月、3ヶ月、3ヶ月にフェーズ分けして、最初の4ヶ月でMVP（ここはMSPではありません）を作りきる計画を立てました。実際、4ヶ月で開発したサービスは、本当に最小限の業務を完遂できるようになっているので、これをマネーフォワードの経理部のみなさんに協力頂いてユーザーテストしました。実はそのテストで、ある重要な機能が誰も使いこなせないくらいわかりずらいという事実が発覚したのですが、あらかじめ予定していた戻り対応用のスケジュールに従ってもう一度深く考えてゼロベースで作り直すことで、最終的には全員が便利に使いこなせる形でリリースできたどころか、なんとこの機能が特許を取得するに至りました。
もし予めこのようなスケジュールを引いていなかったら、この機能は生まれなかったですし、当然特許も取得できませんでした。
業務システムの場合、業務の一連の流れを確認できる状態になってはじめて気付く想定漏れがどうしても発生してしまいます。であるならば、その大きな単位のシステムを、最低でも１回は作り直すことができるスケジュールを予め引いておくことが必要と思います。
もし、何事もなく開発することができたなら、その時はリリースを前倒すなり、MVPやMSPを大きく広げるなりすればいいのです。
ここもとても重要なポイントだなと思い、最後のStepとして書いてみました。
さいごに
ここまで読んで頂いたみなさんはお気付きかと思いますが、ここで書いた内容は、はっきりいって理想論です。私自身も、これら全てを完璧に実践できたことは正直一度もないのですが、毎回、次こそは前よりも一歩でも理想に近づきたいという思いを胸に、ゼロからのサービス作りに挑んでいます。
最後まで読んで頂いてありがとうございました！
マネーフォワードでは、一緒にto B SaaSを作っていって頂ける PdM、デザイナー、エンジニアを募集しています。
また、カジュアルに話してみたい、情報交換したい、なども大歓迎です。
ご応募、ご連絡お待ちしています！
