コンパウンド戦略の壁──なぜビジョンが抽象的になるのか
「複数のプロダクトを展開していると、サービス全体のビジョンが抽象的になりすぎて、何を目指して開発すべきか分からなくなる」。これは、コンパウンド戦略（※1）を取るSaaS企業が共通して直面する課題です。
さまざまな領域でマルチプロダクトへの展開やコンパウンド戦略への転換を目指すSaaSが当たり前になった時代、一部では「コンパウンド戦略すら時代遅れ」と言われることもあります。一方で、時代遅れと言われつつも、コンパウンド戦略を突き詰めたSaaSは少ないとも感じています。マルチプロダクトでGTM（Go-to-Market）（※2）できていない、あるいは難易度が高いという壁を感じる企業が多いのが実情でしょう。
本稿では、複数のプロダクトを開発するjinjer社が取り組んだ「プロダクトビジョンの階層化」について、その背景・運用方法・得られた効果を紹介します。
特にプロダクトが多角化・成長フェーズに入った開発組織にとって、筋の通ったプロダクト指針をどのように再設計するかのヒントになれば幸いです。
（※1）コンパウンド戦略とは：複数のプロダクトを同時に提供し、顧客課題を横断的に解決することで、市場を広げる戦略のこと。参考：EXPACT「SaaSスタートアップの新しい競争戦略！コンパウンドスタートアップとは？」。
（※2）GTM（Go-to-Market）とは：自社の製品・サービスを市場に投入する際に、顧客にどのように提供すべきかの流れをまとめた戦略のこと。BeMARKE「GTM（Go to Market）戦略とは？市場進出を成功させる策定手順と指標を解説」より引用。
ジンジャーにとってのプロダクトビジョンの「重要性」
プロダクトビジョンはコミュニケーションを円滑にする共通指針
ジンジャーは2016年にリリースされたHR SaaSです。サービス名称「ジンジャー」に込めているように、「人事のためのサービス」を目指し、リリース当初より「統合型人事システム」（いわゆるコンパウンドSaaS）の構想を掲げてきました。この構想を中心としたプロダクトビジョンのもと、これまで多くの企業様にご導入いただいています。
この「統合型人事システム」の構想は、HR SaaSの各企業が掲げる提供形態として、今でこそ当たり前となりましたが、約10年前からその構想を掲げサービスを提供してきたことは、ジンジャーの大きな強みとなっています。マーケティング、セールス、カスタマーサクセスチーム、プロダクト開発チームまで一貫して「1つの人事データベースを軸にした統合体験を強みにしている」という共通認識を持ってきたからこそ、同じ方向を向いてサービス提供をすることができています。
このような背景があるジンジャーにとってのプロダクトビジョンは、お客さまへのサービス説明に留まらず、社内のコミュニケーションを円滑にする共通認識として、不可欠な存在と位置付けています。
なぜ今、「ビジョンの階層化」が必要だったのか？
人事労務・勤怠管理・給与管理といった人事の定型業務から、直近1〜2年は人事データ分析・人事評価などのタレントマネジメント領域をジンジャーは展開してきました。その一方で、複数のプロダクトを展開する中で、以下3つの課題に直面していました。
1．各プロダクトのビジョンが定まらない
「統合型人事データベースを軸に人事の顧客体験を追求する」というサービス全体のビジョンは描けていました。一方で、各プロダクトのリリース・機能の拡充を進める中で、最上位のプロダクトビジョンへの紐付きを意識しすぎた結果、個々のプロダクトビジョンの抽象度が高くなってしまうという課題が生じました。
プロダクト数が少ない時期は、ユーザー像のバラつきも少なく、「ジンジャー全体」のビジョンに紐づいた機能拡充でユーザーへ便益を伝えることができていました。しかし、サービスが多様化すると、お客さまのニーズも多様化します。
具体例として、新プロダクトでは「既存プロダクトとの親和性を意識して、既存ユーザー向けのサービスを重視するのか」と「新プロダクトが立ち向かう新規市場を意識して、新しいユーザー像に向けたサービスを重視するのか」という点でビジョンの設計があいまいになりました。結果的に、中立的なビジョンを作ってしまうことで、プロダクト別のビジョンの抽象度が高くなってしまいました。
これは直接お客さまと対峙するセールスやカスタマーサクセス側へ、プロダクトの説明をする際にも、抽象的な説明になってしまうことにもつながってしまいます。そのため、新しい機能をリリースしても「このプロダクト／機能はお客さまへの提案に活かすことができないな……」と受け取られてしまい、新プロダクト／新機能の内容を適切に顧客へ届けられないという課題が生じていました。
2．新機能開発の優先順位が定まらない
プロダクトビジョンが抽象化してしまうと、プロダクトマネージャーが描いたロードマップに沿った開発を推進することも難しくなります。
具体的には、セールスや顧客からの要望を重視するあまり、事業側の優先順位が高い機能を優先してしまうケースがありました。これは、本来策定した開発全体のビジョンやロードマップに沿えない形で機能開発がなされてしまうため、開発の軸が不明確になってしまうという問題が発生してしまいました。
次々と寄せられるアイデアや要望に対して「イエス」と答え続け、セールスチームが「この機能を実装すれば顧客が喜ぶ」といった目の前の要望を優先することで、結果的に機能としては網羅性はあるものの、描いたビジョンを反映できず、指針のないプロダクト設計に陥ってしまうという状況に陥っていました。
3．開発部門と事業部門の共通認識が不足
プロダクトの多様化は、開発難易度自体にも影響を与えます。
特に、複数のプロダクトを跨いだ機能開発や、親和性の高いプロダクトと連携して大きな価値を生み出す機能のリリースを検討することが増え、コンパウンド戦略では重要な機能であるにもかかわらず、その意味について部門間で共通認識を持つことが難しい場面がありました。
「なぜこの設計でこの機能を作る必要があるのか」「さまざまな理由を度外視してこの要件や優先順位で進める理由は何か」などを説明する際、プロダクト別のビジョンの抽象度が高いことが原因で共通認識を醸成しきれず、プロダクトマネージャーとしてはビジョンや方向性に合った説明をしているつもりでも、重要性を伝えきれないこともありました。結果として、顧客への付加価値向上や業界内での優位性を確立できるようなプロダクト開発ができていないと感じていました。
プロダクトの成熟度もバラバラで、数も多い。それぞれ描くべき戦略が異なるにもかかわらず、設計したプロダクトロードマップに対してビジョンを用いた共通認識が不足したと言えます。
結果的に、社内のあちこちで納得感を得にくくなり、「そもそもこのプロダクトビジョンは本当に必要なのか？」という疑念すら生まれ始めていました。
解決策はプロダクトビジョンの「階層化」：プロダクトビジョンを「4階層」に構造化する
これらの背景から、会社やサービス全体のビジョンには紐付きながらも、各プロダクトが目指す世界を具体的に描く「プロダクト個別のビジョンを確立すべきだ」という声がプロダクトマネージャーの間で強まりました。私たちは以下のようにプロダクトビジョンを分解し、企業全体から各プロダクトまでを連動する仕組みを設計しました。
- jinjer社のステートメント（ビジョン／ミッション）
- ジンジャープロダクト全体のビジョン
- プロダクト領域別のビジョン（例：CoreHR、TalentHR）
- プロダクトサービス個別のビジョン（例：ジンジャー勤怠、ジンジャー人事評価など）
ここで重要なのが「3．プロダクト領域別のビジョン」です。「1、2、4」を接続してビジョンを設計するSaaSは少なくないと思いますが、間に「領域ごとのビジョン」という階層を挟むことで、よりプロダクトを届けたい顧客像とその課題や理想を階層別に明確に描くことができ、社内でプロダクトビジョンに対する共通認識を作ることができました。
特に、このプロダクトビジョンの階層化は、ジンジャーがタレントマネジメント領域に参入したタイミングで検討を始めたものです。それまでジンジャーは労務領域を中心にサービスを展開してきましたが、事業の幅を広げる中でも、「統合型人事データベースを軸にした一貫した体験」という強みは守り続けたいと考えていました。
そこで、これまでの労務領域を「CoreHR」、新たに踏み出したタレントマネジメント領域を「TalentHR」と定義しました。そして、この2つをつなぐ形で、ジンジャー全体のビジョンを再設計しました。
