hikoharu's blog

エンジニアリング、プロダクトについて考えていること。twitter: @hikoharu06

SaaSのプロダクトマネジメント、縦から見るか?横から見るか?

f:id:hikoharu06:20220225175616j:plain

はじめに

SaaSプロダクトマネジメントはとても大変です

日々、多種多様な顧客要望を捌きつつ、中長期でのビジネスインパクトを出すための施策や技術的負債に対する難しい舵取りを求められます。

この記事では そもそもSaaSプロダクトマネジメントで大事にするべき原則的な考え方をまとめることで、少しでもその助けになればと思います。

SaaSの種類

まずはSaaSには大きく分けると

  • Vertical SaaS(縦)
  • Horizontal SaaS(横)

の2種類があります。

この2つにはそれぞれ考え方に違いがあるため、概要を説明しつつ、大事にするべきプロダクトマネジメントの考え方についてまとめていきます。

※ここからは業務改善、効率化型のtoB SaaSをイメージして書いています

縦で見るVertical SaaS

特定の業界に特化したSaaSのことです。

日本ではアンドパッド(建築業界)やコドモン(保育業界)などが有名かと思います。

Verticalの由来は、下記のように業界と業務をマトリクスで表現した時に、プロダクトのカバー範囲が垂直(Vertical)なものになるからではないかと思っています。

f:id:hikoharu06:20220222183732p:plain

Verticalなプロダクトマネジメントで重要なのは

  • ソリューションの深さ
  • プロダクトとしてカバーする業務の網羅性

です。 そもそもVertical SaaSが必要とされるのは、

  • 業界特有の業務
  • 構造的な特異性
  • その他リテラシーなど

などがあり、汎用的なプロダクトを導入しても効果が出づらい、そもそも導入ができないという背景があるからです。

なのでVertial SaaSでは

  • ソリューションの深さ、機能、表現などプロダクトのあらゆる部分において対象業界に合わせて最適化されたもの
  • 特殊な業務群についてもそのプロダクトを入れれば全て対応できるという網羅性。いわゆる All in one。

が大切になってきています。

業界の特殊性への理解度がそのままプロダクトの品質に直結することが多いと思います。他業界では?と思われるような機能、表現こそが業界特有の課題を解決でき、価値が出てきます。

ちなみに網羅性についてはあくまで現在の話で、個人的な考えとしては1つのシステムで全てを網羅するのではなく、1つ1つが局所最適されたシステムを組み合わせて使うという方向にゆるやかに向かっていくと思っています。

複数のシステムを組み合わせて活用するための下記のような条件がありますが、徐々に整ってきていると感じています。

  • 特定の特化した問題を解決する高品質なSaaSが増えてきた
  • API連携などにより、組み合わせて使う際の利便性向上
  • 組み合わせて使う側のリテラシーの向上

エンジニアでいうモノリスからマイクロサービスへという流れに少し似ていますね。 自律したチームがオーナーシップを持って判断することで、それが結果として速度、変化への対応につながるという訳です。

すでに、DX化が進んでいる業界、業種ではこの流れが徐々に始まってきており、基幹業務についてはポストモダンERPという概念も生まれています。

biz.moneyforward.com

Vertical SaaSが必要とされる業界は基本的にやや遅れていることが多く、この流れがしばらく遅れて来るのではと予想しています。

  • まずはAll in oneのものを導入して、業務の標準化、システム化がされる
  • それを使う中で、細かい業務単位で個別にやりたいことが出てきて、他システムとの組み合わせの検討が始まる

というVertical SaaSをコアとしつつも、その周りに複数のシステムを組み合わせるような形になっていくのではないかと思っています。

横で見るHorizontal SaaS

特定の業務に特化したSaaSのことです。

SmartHR、freeeなどが有名どころかと思います。

Horizontalの由来は、プロダクトのカバー範囲が水平(Horizontal)なものになるからではないかと考えています。

f:id:hikoharu06:20220222183748p:plain

業務としてメジャーなのは一定規模の会社には確実に存在するバックオフィス系(人事、会計)だと思います。一言で人事領域といっても、入社手続き、年末調整のようなどの企業でも必須の業務から、いわゆる組織活性化、採用支援など企業によってはmust haveでないものまで様々です。

Horizontalなプロダクトマネジメントで重要なのは

  • 課題の抽象化
  • 解決する課題、プロダクトのスコープの明確化

です。

性質上、複数の業界の共通業務を切り取るようなプロダクトマネジメントになります。

避けなければならないのはHorizontalといいつつ、特定業界でしか使わないような機能を生み出してしまうことです。

最初これだけは、、、と思っても、一度やってしまうと高確率で二度目も起こるので下記のような構造に近づいています。

f:id:hikoharu06:20220222183800p:plain

本来SaaSのメリットは、個社ごとで開発していたカスタマイズが必要なシステムを、まとめることで低価格で使えるというもののはずなのに、構造的な厳しさを抱えることになります。 一度プロダクトの中で枝葉が生えてしまうと、切り落としたり、まとめるのは中々に困難です。

あとは自分たちのプロダクトが何を解決するのかというスコープの明確化も重要です。 多くの場合、自分たちのプロダクトだけで業務は完結せず、前後に別の業務があり、他のシステムもユーザーは使っています。

ユーザーが困っている、ビジネス上のメリットがありそうだとしても、「このプロダクトで扱うものではないから」という判断が重要です。

縦と横の勘所

ここまでVertical,Horizontalそれぞれの場合を見てみましたが、これらのベースが合った上で実際には下記のようになっていることが多いです。

最初このように見えているが、、、

f:id:hikoharu06:20220222183810p:plain

実際はこう

f:id:hikoharu06:20220222183818p:plain

いわゆるユーザー、マーケットに対する解像度が上がるというやつです。

お客様の規模、業界の特異性など分けるための軸は様々ですが、実際には思っているよりはるかに細かいセグメントに分けて考えられます。

そしてそれぞれのセグメントで課題やTAM、ビジネス上のポテンシャルなどが大きく違っています。

その中で

  • 各セグメントの具体的な状況
  • 各セグメント間の関係、抽象化して共通しているグループとしてまとめて考える

という具体と抽象の間を行き来しながら、解決すべき問題、自社のプロダクトのスコープ、ポジショニングを決めていくことが重要です。

つまりは

  • Verticalであっても対象としない業務はあり、優先度の検討が必要
  • Horizontalであっても対象としない業界はあり、優先度の検討が必要

ということで、縦*横でプロダクトのスコープを意識して考えることで 大抵の場合は下記のようにプロダクトのカバーする領域がまだらな状況になります

f:id:hikoharu06:20220222183825p:plain

解像度が上がって突き詰めていくと、結局はVertical,Horizontal両方の思考を組み合わせることが多くなるなと感じています。

最初から解像度が高い状態はなかなか難しいと思いますが、リリースしてユーザーと接する中でファクトが見つかっていきます。中長期でこのような形になっていくと意識しながらプロダクトマネジメントするとチームの目線合わせ、いくつかの構造的な大失敗を防げるかもしれません

場合によってはプロダクトのスコープを変更すること、外から見ているとピボットに見える判断をすることもあります。 ピボットというとマイナスなイメージですが、解像度が上がった結果プロダクトのスコープが変わるのはある種当然で、健全なことだと思っています。

おわりに

SaaSの縦と横のプロダクトマネジメントについてまとめてみました。結局は解決すべき課題、プロダクトのスコープが何より重要ということです。

CTOとしては、プロダクトのスコープが変わっていく中でしっかり追従していく、時には先を読み、コードベース、機能をデザインしていくことに非常に面白みを感じています。

定番になりますがエンペイは積極採用中です! SaaS * Fintechという非常にアツい領域で、既存プロダクトを伸ばすことはもちろん、新規プロダクトの開発も水面下で進めています。

少しでも興味持っていただけた方は、ぜひぜひカジュアルにお話しましょう〜

www.wantedly.com

meety.net