プライシングにもっと注力すべきーーfreee宮田氏
freeeの宮田氏は、SaaSのプライシング、つまり料金づけをテーマに話をした。新プロダクト「プロジェクト管理freee」の提供にあたってプライシングに悪戦苦闘しながら取り組んだ体験を踏まえて語った。
宮田氏はまず、プライシングが重要な理由として、「プライシングを1％改善することで12.7％売り上げが変化する例もある。マーケティングの最適化としてユーザー獲得コストを1％増やすより、プライシングを1％上げると利益貢献は4倍になる」（出典元：ホワイトペーパー「The Anatomy of SaaS PRICING STRATEGY」by Price Intelligently）と説明する。これだけ重要なのにもかかわらず、プライシングについてあまり議論されない理由として、SaaSではプロダクトをユーザーに届けるまでにさまざまな人が介在し「プライシングのオーナーが誰なのかが明瞭ではないからでは」と分析した。freeeでは、PMを務めていた宮田氏とUXリサーチャーが手を組み、関係者を巻き込んで最終的に設定したという。
SaaSのプライシングの考え方は「SaaSプロダクトの提供価値と、ユーザーがいくらなら払う意思があるのか（WTF：Willingness to Pay）のバランス」と宮田氏。方法論として宮田氏は、競合調査、それに基づいた定性調査と定量調査を紹介した。
調査の対象は、「対象業務プロセス」「MVP（Minimum Viable Product）」「チャージモデル」「価格感」の4つ。
「競合のプロダクトがどのような業務プロセスに対してのものなのか、それがどのようなソリューションとして提供されているのかをしっかり把握し、自社が提供する対象となる業務プロセスと差分があるのか、ソリューションに違いがあるのかを精査していく」という。差分が明確になったら次は定量調査のフェーズで、ユーザーの母数の確認などを行う。
この中で今回は、定性調査について深掘りする。宮田氏は定性調査で調査する内容は「たった3つ」と以下を挙げた。
- ユーザーが現在どのように業務設計して運用しているか
- 価格がいくらまでなら導入を検討するか
- その価格をどのように算定したのか
この3つをしっかり聞くことで「ユーザーの思考回路を理解し、どこに価値を感じてもらえそうかユーザー目線で考える糸口になる」と宮田氏。
「ヒアリングを数回した上で、インタビューの状況、ヒアリング結果、アンカリング対象を整理し、これをさまざまな観点で見つめ直す。クリエイティブな時間になるが、この作業をしっかり行うことで、ユーザーセグメントやユーザーが持っている特徴の導出につなげる」と述べた。
定性調査における注意点として宮田氏は「ヒアリングと実際の商談は違う」と指摘。商談ではユーザーも競合の仕様やプライシングを綿密に調査した後に提案を受けるため、ヒアリングの方が料金がやや高めに出るという。
また「日本以外の国の競合調査をしっかりやるべき」とも助言した。「日本はSaaS後進国。海外で「イケている」サービスの情報を早めに拾うことでどこに収束するのかが先にわかる」という。
このほかにも「バイヤーを正確に捉える」「さまざまな観点で整理する」などのポイントも明かした。特に後者については、freeeでは「自信を持ったプライシングのために、30社程度にインタビューした」という。
最後に宮田氏は「SaaSによるプライシングはとても重要。手を抜かずにしっかりやるべき」と再度強調した。
エンタープライズのプロダクトマネジメント、陥りやすい罠とは？
ラクスル 執行役員 CPOの水島壮太氏は、BtoBプロダクトの開発投資の考え方、BtoBプロダクト開発で陥りやすい罠について話した。
ラクスルは印刷、そして物流のハコベル、TVCMのノバセルと3つの事業を展開している。同社のプロダクト開発の考え方として水島氏は「まずマーケットプレイスを創造して取引を始め、取引前後の業務や顧客課題を特定、それを解決するソフトウェアをSaaSとして有償または無償で提供し、業界を変革していく」と説明する。
経営陣はエンジニアとデザイナーを最も貴重な投資と位置づけているため「PMの究極のミッションは、貴重なエンジニアとデザイナーの開発投資へのROIを最大化することになる」と水島氏。社内では月に一度、数百万円以上の開発投資規模を持つプロジェクトに対して、プロダクトについてのドキュメントを提出し、それがもたらす粗利ベースの5年間のROIを示すことになっているという。「恐ろしい会」と水島氏は苦笑しながらも、「結果を毎年チェックしており、非常によい場になっていると思う」と続けた。
続いて水島氏は本題の「BtoBプロダクト開発で陥りやすい罠」を紹介。まず、BtoBとBtoCでは顧客特性が大きく異なる、と解説する。
一口に「toB」といっても、個人事業主やSMBとエンタープライズでは大きく異なる。ラクスルの場合、規模の小さい企業からだんだんエンタープライズに拡大していったが、利用者と決裁者が異なる、社内フローに従いバックオフィスの連携が必要になる、カスタマイズ要求が出てくるなど、それまでにはなかった特性に向き合った。
その際の「罠」として、水島氏が挙げたのは次の3つ。どうマインドを変えていくべきかについても、経験を踏まえて解説した。
（1）ARPUが高いので、LPとオペレーションだけで利益が出せてしまう
「これで事業が立ち上がってしまい、結構利益が出る。そうなると、プロダクトの検討をせずに人を増やすことがドライバーになり、オペレーションも高度化して幅を広げてしまうと必ず行き詰まるというケースがある」と水島氏。大切なこととして、「ARPUが高い状態でも人手による利益創出ではなく、プロダクトを見据えたMVPであると捉えて出口を考えておくことが重要」とアドバイスした。
（2）toCのようなアジャイル開発をやりすぎる
顧客特性が異なるので「toCのように利用者だけを意識してミニマムなスコープで開発した結果、その後ろにいる決裁者やチャネルフローに沿わないといった致命的なケースになったことがある」と水島氏。そこで、「決裁者やバックオフィス向けの要件をおろそかにしない」「保守的なユーザーを意識して丁寧な改善活動を」と助言した。
（3）大口顧客のカスタマイズ要求に屈しやすい
エンタープライズ顧客は専用API、シングルサインオンなどの個別の対応要求を出すことが多いが、ここでも「戦略なしに個別対応を続けていくと、結果的に使われずにROIが低い状況やエンジニアがつらい状況が起こる」という。同じ状況に陥ったラクスルでは、2年前にシステムの刷新とアーキテクチャの見直しを行い、個別対応をせずに複数の大口顧客を獲得するというプロダクト設計マインドに変更したという。
「"if else"で考えず、戦略的なアーキテクチャをシミュレーションしながら常に意識するといい。難易度が高いので、CTOやリードエンジニアと相談しながら進めるとよいのでは」と水島氏は述べた。
※後編へ続く
