Sansan CPO大津氏直伝「SaaSにおけるプロダクトとCPOの役割」 by SaaS部 2021 Spring

みなさん、こんにちは。今回は、2021年3月に開催したイベント「SaaS部 2021 Spring」のレポート記事をお届けします。弊社の投資先およびSaaS領域で起業した起業家を対象にDNXが主催となって開催しているイベントですが、緊急事態宣言開け直後、久しぶりのリアルイベントに、経営者たちの集中と熱量溢れる学びの詰まった会でした。

３つのセッションから、今回はSansan CPOの大津裕史さんのセッションの内容をレポート。「SaaSにおけるプロダクトとCPOの役割」と題して、SaaSにおけるプロダクトとは、CPOとCTOの違い、プロダクトの意思決定や人材育成・採用についてまで深掘りいただきました。

プロダクトが目指すべくは、低コストで高価格

SansanでCPOを務めています、大津です。本日はSaaSのプロダクトとCPOの役割についてお話をさせていただきたいと思います。

まずは私の自己紹介から。私がSansanにジョインしたのは2018年。それまでは自分で会社を8年やっていました。最近上場したWACULという会社です。

本日は、プロダクトについて3つお話をします。

ひとつは、SaaSにおいてプロダクトは「ソリューション」であり、ソリューションとしてのプロダクトは「コスト」である、というお話です。最終的には低コストで高価格を目指すことになります。

ここからお話することはあくまで私の考えなので、合っているか間違っているかはわかりません。
私の考えでは、SaaSプロダクトは二つの種類があります。ひとつは、「ソリューション」を目指すこと。もうひとつは「消費」されるもの。たとえばTwitterやInstagramなどは、何かの課題解決をするというよりは、消費するためにプロダクトが存在しているという種のものです。一方ソリューションというのは、解決すべき「状況」がある。ソリューションは何かを解決するためのソリューションなので、開発・運用コストやユーザー側のコストが安ければ安いほど喜ばれます。

「導入すればコストが下がる」が必須条件

本日はB2B SaaSについてなので、「ソリューション」としてのプロダクトを語ることになります。

「ソリューション」としてのプロダクトは、「コスト」であるということを肝に銘じる必要があります。
例えば、Sansanが提供する請求書の一括管理サービス「billone」は、このプロダクトを導入するまでは、顧客は紙で届いた請求書を別のプロダクトや手作業で管理してきたわけですね。つまり、払っているコストや時間があった。この「billone」を導入するかどうかは、このプロダクトを使用することで金銭/ストレス/時間のコストがどれだけ下がるかにかかっています。
実際SaaSツールを使えば、PCやスマホでどこでも操作でき、スピードも処理速度もあがり、コストが下がる。基本的にどのSaaSも、コストが下げられるSaaSプロダクトを目指すわけです。

カスタマーサクセスやデリバリーも、ある意味コストを下げる行為です。
導入時期にカスタマーサクセス側でオンボードを丁寧にやることも、使いやすい環境を整えコストを下げています。たとえば先ほどの「Billone」も、社員みんなが使い方を理解しない限り使ってもらえませんし、使い方を調べながら使うとなると時間的にも労力てきにもコストが高い。そこでSansanのカスタマーサクセスチームが、セミナーなどを通じて使い方を教えると、導入コストは低いし便利だね、となる。導入時期に使い方のイメージをきちんと掴んでもらえていれば、使う段階でコストが下がるわけです。
このように、プロダクトだけでなくカスタマーサクセスもコストの低い環境を作る行為だとみています。

プロダクトで単価をあげるには、高価値ソリューションかつコスト削減

ビジネスですので、コストを下げて高単価で提案することを目指すわけです。このとき、ソリューションの価値は、そのプロダクトを求めているユーザーの状態で決まります。もともと同じ課題を解決している別プロダクトやマーケットがあるのであれば、コストをかけるだけのバリューがあると見なされているものです。もっと低コストで提案できれば、ビジネスになるわけです。

一方で、こういうことがあったらいいなという機能については、その時点で払っているコストがなければ、ただの妄想、ただのアイデアです。今コストがかかっていない「あったらいいな」というプロダクトや機能については、追加費用を払ってまで導入しないと考えるべきでしょう。
たとえば、営業のプロセスに30分間のロスが生じている場合、30分を1分にできたらユーザーは利用してくれるでしょう。ユーザーにとっては、新しいソリューションを使うこと自体が、覚えるために学習コストがかかり、アプリを立ち上げる時間、操作コストも含めて「コスト」がかかります。したがって、既存のコストと比べてどれだけコスト削減になるかを見ます。

加えて、ソリューションの提供バリューも重要です。高いバリューをもたらすソリューションであれば、高いコストでも通用する。ユーザーが払うコストができるだけ小さくすむからといって、ソリューションのバリュエーションあまりに低かったらビジネスにならないですよね。このギャップ自体、つまりバリューが大きいのに払うコストが低いと、高単価で売れるというわけです。ユーザー側のコストを下げられた時やより高価値のソリューションになったときに単価をあげるということになる。プロダクトで価値をあげるというのは、そういった意識なんです。

プロダクトを作ること自体だってコスト。つくることすら渋る。

前半についてまとめますと、私の考えるプロダクト、特にB2B SaaSのプロダクトとは、「ソリューション」です。そのうえで、ソリューションとしてのプロダクトは「コスト」です。作る上でもプロダクトは「コスト」になります。開発コストもかかりますし、運用やその後のCS・営業が説明することもコストです。
プロダクトと向き合っている責任者で、「プロダクトを作りたい」という方はプロダクトに向き合っているとは言えません。プロダクトをつくることを渋るような人間じゃないとダメです。これを開発するんだ、運用するんだ、ということに本当に向き合い、問えるような人が、プロダクトに向き合う役割を負える人です。
CPOがいない会社はCEOがプロダクトに向き合っているかと思います。私の知っている多くの日本の経営者は、何でもかんでも作りたがります。作ることが自己表現であり、自分の成果だと考えがちなんですが、作ること自体はコストなので、価値はありません。だってプロダクトを作ることがコストなんですから。そのコストで何を得るかが本来目指すものだと思います。

「機能」「テクノロジー」「使いやすさ」プロダクトの三権分立

続いて、CPOの役割の話に移っていきたいと思います。CPOの役割を話しますが、その周辺の役割についても話していけたらと思います。

「プロダクトの三権分立」という考え方があります。salesforceから学んだもので、「機能」「エンジニアリング」「使いやすさ」の３つの要素です。

プロダクトはWhyと向き合う行為、エンジニアはHowを向き合う行為です。エンジニアリングとプロダクトの差、役割分担を意識してすると良いと思います。CPOはCEOとプロダクトに関する中期の目線を合わせること、そして現場とクオリティ目線を合わせることが、メインの仕事かと思います。採用登用面では、GM、PdM、UXという役割にコミットをしています。

三権分立とは、プロダクトと向き合ううえで尊重すべき「機能」「テクノロジー」「使いやすさ」の3つそれぞれを、プロダクトマネージャー・エンジニア・UXが向き合うということ。プロダクトに向き合う人は、リテラシーを持っていることはもちろんのこと、この３つについて議論や意思決定ができる人材でないといけません。

プロダクトマネージャーは「Why」と向き合い、エンジニアは「How」と向き合います。
プロダクトを作る上で、なぜそのプロダクトを開発するのかという企画はPMやUXデザイナーなどプロダクトサイドの仕事です。どう作ればオペレーションとして美しいか、スムーズかに向き合います。一方、エンジニアはどういうソースコードを書くか、どんなテクノロジーを採用するかなど「How」を決めて行くわけです。

チーム統制とレポートライン、各々の役割分担

こちらの画像は、それぞれが何に対するオーナーか示した図です。プロダクトのオーナーがPdM、体験のオーナーはUX、エンジニアはプロセスのオーナーです。何を作るかはプロダクトが決めますが、その後どうやって作るかという「How」の部分はエンジニアに任せるのが良いと思います。プロダクトのオーナーがプロセスについてあまり口を出すべきものではありません。どうやってやるかは彼らに任せる。

ではCPOは何をしてるかというと、CEOの数多くの権限・役割のうち、プロダクト監修の部分を担います。CEOがプロダクトに向き合うのを、横から手伝う存在ですね。よくCPOがCEOとレポートラインを持って、CPOがGMとCEOのレポートラインを邪魔するような組織図を描く方もいますが、CEOはGMと話した方がいいが、CPOは横から支える方がいいと思いますね。

続いてGM（ジェネラルマネージャー）は、特定のプロダクトドメインのトップ、事業責任者です。うちでいうならばSansanというプロダクトにはSansanのGMがいて、BillOneにはBillOneのGMがいます。GMは、プロダクトでどれだけ売り上げるかということにコミットするので、ビジネスも向き合うことになります。

顧客や社内から様々なフィードバックと合わせて数多くのバックログが上がってきますが、顧客のリクエストに基づいたバックログもあれば、顧客が想像していないイノベーティブなバックログもあります。Sansanではこれらを分けて管理していますが、それらの優先度を、中期の戦略や競合の動きを踏まえてCEO-CPOで決めています。ここで8〜9割決まったものを、次はGMとすりあわせて目線合わせをします。GMとの目線合わせのときには、場合によって予めプロトタイプを用意して具体的に見せることもありますね。さらにGMが解像度高く理解して、現場に落としていくんです。

チームの統制・採用などについては、プロダクトマネージャーとUXデザイナーに任せています。PdMに関しては、バックログづくりのクオリティに関する目線合わせや、リリースされた内容についてPdMと毎週話しています。一方、UXデザイナーとはプロダクトの体験面について話をしています。CDOやCXOがいる場合は、おそらくその方に統制を任せればいいということになります。

みんなからのフィードバックを取り入れ、意思決定はオープンに

最後に、Sansanがプロダクトに向き合うためにどんなことをやっているか軽く紹介します。社内のコミュニケーションはSlackを使っているのですが、そのなかにプロダクトごとに「フィードバックチャネル」を設置し、立場を気にせずプロダクトのフィードバックを書きこめるようになっています。ルールは、重複も気にせず、全員が気づいたことを自由に書く。営業からも開発からも、自分の声も顧客の声も集まり、例えばSansanプロダクトでは月間300ほどのフィードバックが寄せられます。PdMは、フラットな目で企画のタネとして目を通し、提案材料に使ったりする。

また、月に1回社内のみなさんに対して、1時間CEO/CPOのプロダクトレビューを行う機会を設けています。私が全プロダクトのことを現場から取りまとめてCEOに報告する様子を、全社員に公開しているんです。全プロダクトのリリース情報とそのレポートをまとめると100ページ以上に。この会話をみんなが聞くことで、どんな目線でプロダクトをどう考えているか、生の声を聞くことができる。効果的な施策だなと思っています。

Sansanで月に一回開催されているプロダクトレビューの配信

（文・上野なつみ / 監修・倉林陽 / 制作サポート・平松映人）