ALL for SaaS SaaS立ち上げのすべて

宮田善孝

SaaSの立ち上げに携わるすべての人に捧ぐ！SaaSの検討開始からリリースまでの羅針盤！

【本書の内容】
プロダクトマネージャとしてfreeeで新規SaaSを立ち上げた軌跡を丁寧に体系化した必読書！著者が戦略コンサルティングファーム2社で培った経営戦略の視点や、スタートアップ/ベンチャー3社でのプロダクトマネージャとしての経験を元に企画検討から最終的にプロダクトとしてリリースするまでを網羅的に解説。

freee株式会社 CEO 佐々木大輔氏推薦！「SaaSを立ち上げるすべての人の心の拠り所！」

【本書の特徴】
すでに国内でもSaaSという言葉をよく目にするようになった。その波に乗ろうと、SaaSの立ち上げに取り組む企業も多い。しかし、その立ち上げ方は各社が独自の手法で手探りで推進しているのが実情である。

このような現状を打破すべく、著者がSaaSの本質に立ち返り、大きく変容したソフトウェアビジネスを前提に、SaaSの立ち上げ方を体系化している。昨今、SaaSと並んで取り上げられるサブスクリプションに焦点を当てるのではなく、SaaSの文言通り、サービスとしてソフトウェアを提供することに主眼を置き、その立ち上げ方を整理している。

本書ではSaaSの立ち上げを、大きく4つのフェーズ（事前／深掘り調査とプロトタイプ、開発、ゴー・トゥ・マーケット戦略、リリース）に分けて、非常に多岐に渡る検討内容や注意点を丁寧に説明し尽くしている。また、プロダクトマネージャの視点から整理を試みているが、エンジニア、デザイナーがオーナーとなるべき検討事項はもちろん、ビジネスサイドが中心になって進めるべきプライシング、事業計画、販売戦略などのゴー・トゥ・マーケット戦略についても、できる限り網羅性を担保した構成となっている。

※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。

• カテゴリ: ビジネス・実用
• ジャンル: ビジネス・経済 / 経営・企業
• 出版社: 翔泳社
• ページ数: 384ページ
• 電子版発売日: 2021年08月13日
• コンテンツ形式: EPUB
• サイズ(目安): 15MB

[ブクログ · ★★★☆☆]

■Part 1｜SaaSを取り巻く環境
Chapter 1｜SaaSの概要
Chapter 2｜SaaSの優位性
Chapter 3｜SaaSの評価方法
Chapter 4｜まとめ
　経営者という立場からは売り切りでパッケージソフトウェアとして売れるものを、わざわざ短期的な売上の規模を落としてまで、サブスクリプションを前提としたSaaSによる提供を採用するという判断はしにくかっただろう。しかし、ここまで順を追ってみてきた通り、国内においても、昨今SaaSの評価方法は確立し、浸透するフェーズを迎えている。つまり、SaaSを評価するユニットエコノミクスを中心とした概念がベンチャーキャピタルや経営者に浸透し、今後プロダクトを通して事業を立ち上げていく1つのオプションとしてSaaSを認知し、採用しやすい環境が整ったのである。そのため、SaaSが急激な伸びを見せていることはすでに言及した通りである。
ここからは、プロダクトマネジメントの視点からSaaSの立ち上げに関する方法論を再構築していく。
■Part 2｜SaaS構築の全体像
Chapter 1｜SaaSを立ち上げるためのフェーズと体制
・組織体制
　SaaSの企画検討を進めるに当たって、2つの組織設計の考え方がある。それは事業型とファンクション型である。前者の事業型は各事業に必要なファンクションを備える体制を指す。この場合、事業責任者がSaaSの企画検討に対して責任を負い、異なるファンクションのメンバーを巻き込むだけでなく、ピープルマネジメントもその職務として担うことが多い。
　後者のファンクション型はプロダクトマネジメントや開発など、ファンクションごとの組織を組むが、ファンクション横断のバーチャルチームを組成し、プロダクトや事業を運営するスタイルを指す。各ファンクションが結果責任を負い、CEOを中心とした企業の中枢にレポーティングを行うことになる。具体的には、プロダクトの責任者としてCPO(Chief Product Officer の略) やVPoP(Vice President of Productの略)を置くように、各ファンクションの責任者に据えて、その配下に組織が組まれることが多い。
　昨今のスタートアップの多くがファンクション型の組織を採用しており、SaaSを運営しているスタートアップでも同様の傾向が見られる。これは、SaaSの立ち上げに高い専門性を持った様々なファンクションの人が協働し、推進していく必要があるからである。逆に、事業型があまり採用されない理由は、事業責任者が事業の運営に必要なファンクションに関する知見を併せ持つ必要が出てくるが、SaaSの立ち上げに必要な知見が多様すぎて、適切な事業責任者を擁立しづらいからである。
　本書の目的はSaaSを立ち上げていく上での方法論を確立させることにあるため、多様でかつ専門性の高いファンクションの協働が可能なファンクション型の組織体制を前提に議論を進めていくことにする。
Chapter 2｜目標設定
Chapter 3｜プロダクトマネージャとは
　他方、BtoCではBtoBのプロダクトと同じく事前に潜在ユーザにテストを行うことは可能であるが、ユーザが享受する価値以上に流行やネットワーク効果などに依拠するところが多く、事前に検証することは難しい。そのため、事前の検証よりもリリース後が主戦場になる。具体的にはしっかりマーケティングを行い一定数のユーザを確保し、数多くのABテストを通してイテレーションを行うことが競争力の源泉となる。
　さらに、ゴー・トゥ・マーケット戦略の面から両者の違いを比較すると、BtoBでは事前/深掘り調査によってかなり精度高くユーザの反応を確認することができるため、プロダクトを起点にボトムアップで事業計画を策定することになる。来年度開発を予定している機能群を踏まえ、購入可能性が高い市場を見出して、プライシングや事業計画、販売戦略を策定していく。他方、BtoCでは事前/深掘り調査を比較的簡潔に行い、リリース後のマーケティング、イテレーションに重きがある。そのため、事業計画もプロダクト起点にボトムアップで策定するというよりも、どの規模感(売上やユーザ数など)を目指すのかから設計し、策定した事業計画を起点に、必要なマーケティング施策やプロダクトの改善を企画検討していくケースが多い。
Chapter 4｜まとめ
　SaaSの立ち上げは、事前/深掘り調査とプロトタイプ、開発、ゴー・トゥ・マーケット戦略、リリースと大きく4つのフェーズに分解ができる。フェーズを経るごとに関係者が多くなり、リリースを迎える頃には一大プロジェクトと化す。ただ関係者が多くなるだけではなく、多種多様なファンクションのメンバーが集まり、リリースに向けて協働していくことになる。そのため、クロスファンクションチームでOKRを立て、フェーズに合わせた運用が不可欠である。
　プロダクトマネージャは、そのチームが追うべきOKRを策定し、同じ目標を共有した上で、各ファンクションのメンバーの自主性を担保し、チームのパフォーマンスを最大化する触媒的な役割を持つ。そのため、プロダクト開発に関わる広いスキルセットが求められるのである。その中でもBtoBを前提とするSaaSでは事前/深掘り調査を行えば把握できることが多く、高い調査スキルが求められ、調査結果を踏まえて開発を進めるマーケットインのアプローチが主流なのである。
■Part 3｜事前/深掘り調査とプロトタイプ
Chapter 1｜事前/深掘り調査とプロトタイプの概要
Chapter 2｜事前調査
Chapter 3｜深掘り調査
Chapter 4｜プロトタイプ
Chapter 5｜開発投資判断
Chapter 6｜まとめ
　BtoB向けのプロダクトの場合、BtoCに比較し、調査を通じて事前に把握できることが多く、しっかりと業務理解を行うことから始めるべきだろう。特にSaaSはサービスとしてソフトウェアを提供するものであり、業務を理解せずに提供するのは難しい。
　調査と言っても、事前/深掘り調査として様々な手法がすでに確立しているので、知るべきことをきちんと洗い出して、必要な調査を設計し、実査を進めることになる。
　調査を行い、業務理解ができると、新たにプロダクトを立ち上げる上で最も根源的なプロダクトビジョンの策定に取り掛かる。プロダクトビジョン自体に正解があるものではなく、また策定する上で王道もないので、思い思いの進め方でプロダクトを通して実現したい世界観の言語化に挑戦していくことになる。
　プロダクトビジョンができると、デザインスプリントなどを通してソリューションアイデアを創出し、プロトタイピングを進めていく。この段階で初めて潜在ユーザに提案し、フィードバックを受け、プロトタイプの磨き込みを進める。この時期、ユーザテストのたびに新たな知見があり、仮説検証のサイクルが周り、プロトタイプの精度がどんどん上がっていく時期を迎える。
　そして、最後に事前/深堀り調査からプロトタイプまで総ざらいを行い、開発投資判断を仰ぐことになる。今やプロダクトを運営している企業にとって、開発リソースは最も重要な経営資源の1つである。ミッション/ビジョンとの整合性と事業性の2つの視点から確認されることになるので、入念に準備すべきだろう。
■Part 4｜開発
Chapter 1｜開発の概要
Chapter 2｜デザイン
Chapter 3｜機能要件の開発
Chapter 4｜非機能要件の開発や対応
Chapter 5｜QA
Chapter 6｜まとめ
　開発投資判断を受けて、まず行うべきはユーザストーリーマッピングである。SaaSが対象とする業務は複雑で、関係者も多いので、デザイン、開発、QAを進めていく上でユーザストーリーマッピングを起点に置くべきだからである。チームビルディングも兼ねて、開発に関係する全員で作成していくものだろう。
　このユーザストーリーマッピングを受けて、デザイナーはオブジェクトマッピングを作成し、具体的なユーザインターフェース/ユーザエクスペリエンスに落とし込んでいくことになる。
　SaaSは継続的にサービスとして提供するため、最初から完成を目指すのではなく、徐々に機能追加や改修を通して理想とするプロダクトに近づけていくことになる。そのため、ウォーターフォール開発ではなく、アジャイル開発を採用すべきだろう。QAも同じく開発に併せて、アジャイルをペースにし、開発が終わりQAを通して確認できた機能からリリースし、ユーザからのリアクションをタイムリーに受け取れるようにすべきである。SaaSの立ち上げを行うに当たっては、機能開発だけではなく、インフラ専の非機能要件の開発も漏れなく付いてくる。この分野は開発経験がないプロダクトマネージャにとって疎遠なテーマになりやすい。しかし、プロダクトマネージャとして着目すべきポイントであるリリース後の可用性、セキュリティ要件、キャパシティプランニングのための流入見込みの想定、バックアップの設定ぐらいは押さえておきたい。
■Part 5｜ゴー・トゥ・マーケット戦略
Chapter 1｜ゴー・トゥ・マーケット戦略の概要
Chapter 2｜プライシング
Chapter 3｜事業計画
Chapter 4｜販売戦略
Chapter 5｜販売戦略実現に向けた準備
Chapter 6｜リーガル対応
Chapter 7｜コミュニケーションのデザイン
Chapter 8｜まとめ
　ゴー・トゥ・マーケット戦略は、プライシング、事業計画、販売戦略の3つに分解できる。これらは相互に独立したものではなく、互いに連関し合うので、行ったり来たりしながら議論し、決めていくことになる。
　プロダクトマネージャは何のために誰にどんなプロダクトを作るのかに焦点を当てることが多い。もちろん、SaaSの場合でもこれらの観点を重視し、サービスとしてソフトウェアを提供し、ユーザに価値を届けていくことになる。さらに、プライシングを主導し、ユーザが享受する価値をベースにその対価を設定していくこともある。プライシングと聞くと、売り主の経験と勘によって決められるような印象があるかもしれないが、SaaSの場合、その設定手法はかなり体系化されており、かつ実践的である。
　各種調査を元に、プライシングの候補を洗い出し、それらを踏まえた上で事業計画を立てたり、逆に事業計画のシミュレーションありきで採用すべきプライシングを割り出したりすることになる。プライシングとの整合性を取るべき対象は事業計画だけでなく、実際販売していく上での方針や体制などをまとめた販売戦略とも相互に齟齬がないかを確認していくことになる。販売戦略は立てて終わりではなく、事業を成長させるべく、実践していくことになる。その実践の内容は非常に広く、潜在ユーザに訴求すべく、SaaSの名称やロゴの作成から最終的にユーザが継続的にSaaSを通して価値を感じられるように導入支援の実施やカスタマーサポートの立ち上げを行なっていくのである。
　ところで、ゴー・トゥ・マーケット戦略に直接挙げられることは少ないが、リリースまで対応すべきビジネスサイドの論点として、リーガルもここで合わせて確認しておきたい。SaaSの立ち上げに関して、検討初期に致命的なリーガルリスクがないか確認し、ある程度プロダクトの方針が決まった時には、さらに細かく確認することになる。具体的には、利用規約とプライバシーポリシー、特許、商標に関して、事前に対応を行うべきだろう。
　開発までは、そのほとんどがプロダクトサイドで完結していたが、ゴー・トゥ・マーケット戦略ではビジネスサイドと協働することになり、一気にSaaS立ち上げの関係者が多くなる。そのため、このタイミングを見越し、SaaS立ち上げメンバー内外でのコミュニケーションを確立させておきたい。
■Part 6｜リリース
Chapter 1｜リリースの概要
Chapter 2｜リリースの事前準備
Chapter 3｜ベータ版リリース
Chapter 4｜正式版リリース
Chapter 5｜プロジェクト全体の振り返り
Chapter 6｜まとめ
　リリースと言っても、その対象は大きくベータ版と正式版に分かれる。ベータ版については目的に応じて、公開範囲と課金の有無によりさらなる分類が可能であり、その中から選択して展開することになる。また、恣意的なリリースにならないように、事前にリリース判定基準を立てて、関係者ですり合わせておくことで、基準に即した客観的な判断が可能になる。
　ベータ版の展開を行い、ようやく辿り着く正式版のリリースは、事前/深掘り調査、プロトタイプを経て、開発、ゴー・トゥ・マーケット戦略を進めてきた集大成となる。最も大変な工程の1つであるが、リリースに向けたタスクリストなどを活用し、スムーズにリリースしてほしい。
　ここまでの過程をただプロダクトを立ち上げるだけの成果にしてしまうのは本当にもったいない。立ち上げたプロダクトによる成果や実績と共に、そのプロセスもしっかり振り返り、体系化することで、自分や自社にしかない新規プロダクトの立ち上げプロセスに昇華すべきだと思う。