こんにちは、SmartHRのプロダクト基盤領域で、テクニカルプロダクトマネージャーをしている hikita です。
この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿します。ぜひご覧ください！
SmartHRでは2023年にプロダクト基盤チームを組成し、マルチプロダクトの共通基盤づくりに力を入れて取り組んできました。私からは、その中で学びながら整理できてきた「マルチプロダクトにおける共通基盤をどう作り、育てていくのが良いか」について紹介します。
マルチプロダクトの会社で共通機能を作ることになったけどどう進めるか悩む。時間をかけて作った共通機能があまり使われなかった。そして、これからSmartHRで共通基盤を作っていくチームメンバー。そんな方々にとって少しでも参考になることがあれば幸いです。
プロダクト基盤チームについての参考記事：
前提
共通基盤の作り方や育て方は、組織やプロダクト、なぜ作るかといったコンテキストによって変わると思うので、まずはその前提を紹介します。
共通基盤とは？
SmartHRにおける共通基盤とは、複数のプロダクトが共通して利用する機能群を指していて、具体的には権限基盤や従業員データ基盤、課金基盤などがあります。
共通基盤では
- プロダクト同士のデータや機能を統合し、ユーザー価値を高めること
- 各プロダクトが共通して使う機能を一箇所で提供することで、開発生産性を高め、全体にレバレッジを効かせること
の2つを目的としています。
最初から共通基盤として作っていたわけではない
SmartHRは創業当初から、連携するマルチプロダクト展開を考えて作られた、いわゆるRipplingのようなコンパウンドスタートアップではありません。
そのため、規模が拡大したタイミングから作りはじめた共通基盤もあり、すでに多くのユーザーに利用されているプロダクトにも導入していく必要がありました。
領域や利用ユーザーが異なるプロダクトが数多くある
SmartHRは、労務領域からタレントマネジメント領域まで、幅広く機能を提供しており、プロダクト数はSmartHR社が提供しているものだけでも20を超え、開発パートナー企業に提供していただいているプロダクトを含めると40を超えています。
複数領域でマルチプロダクトを展開する場合、様々な種類のユーザーが、様々なユースケースでプロダクトを利用することになり、共通基盤への要求も複雑化、肥大化していきます。 SmartHRでも、労務領域からタレントマネジメント領域に進出したことで、共通基盤に多くの課題を抱えることになりました。
プロダクト基盤チームが共通基盤を作る役割をもつ
SmartHRでは、プロダクト基盤チームという専任チームが共通基盤を作り、プロダクトに導入していくことに対して責任を持ちます。
2023年までは必要に応じてプロジェクト化したり、課題感を感じたチームがコミットする形で進めていたのですが、本格的にマルチプロダクト戦略を推進していくタイミングで明確に責任を持つチームを作りました。
SmartHRでは、以上のような前提のもと、マルチプロダクトの共通基盤づくりにチャレンジしています。
共通基盤は大きく作りがち
共通基盤について考えると、どうやって全プロダクトに導入できるようにするか、どうすればすべての要求やユースケースを満たす基盤を作れるかと、大きく考えてしまいがちです。
風呂敷を広げて考えることは、全体の解像度を高め、方向性の認識を揃えるためにも、最初に取り組んだほうが良い重要なことだと思います。ですが、最初から大きいものを作ろうとしてしまうと、多くの時間がかかってしまい、リリースの頃には状況が変わってしまうかもしれません。そしてなにより、大きなコストを掛けて「（間違っているかもしれない）価値があると思っている共通基盤」を作り、広げてしまうリスクがあります。
最初に完璧だと思っている共通基盤はあくまで仮説であり、間違っている可能性を含んでいます。共通基盤においても通常のプロダクト同様に、小さく価値検証し、価値あるものに育ててから、スケールさせていくアプローチをとることが有効だと思います。
共通基盤はマルチプロダクトを良くもするし、悪くもする
マルチプロダクトを提供する会社で共通基盤を作っていく際、常に意識しておきたいことがいくつかあります。
- 共通基盤は、多くのプロダクトに依存される性質を持ち、一度活用が広がると変更コストがとても高い
- 共通基盤の質によっては、すべてのプロダクトを良くもできるし、悪くもできる。レバレッジも効かせられるし、ボトルネックにもなりうる。
- プロダクトに導入されるまでに考えた価値はすべて仮説。導入する過程や導入して使われることで初めて価値が検証できる
- スケールさせるのは、共通基盤チームだけではできない。プロダクトチームをどう巻き込んでいくかの設計、仕組み化が鍵
共通基盤は、マルチプロダクト全体を良くもできるし、悪くもできてしまいます。また、組織全体にレバレッジを効かせることもできる一方で、ボトルネックにもなり得ます。さらに一度広げると変更コストが非常に高いといった特徴を持っています。
間違った共通基盤を広げないためには、価値をだせることを検証してから広げるというプロセスが非常に重要になります。
価値ある共通基盤を広げるために意識したい3つのフェーズ
価値ある共通基盤を作り、広げていくためには、大きく３つのフェーズに分けて進んでいくのが有効なのではと思っており、それを紹介します。
- 価値ある共通基盤に小さく育てる
- 導入プロダクトを絞り、小さく検証、改善しながら、価値ある共通基盤に育てるフェーズです
- 目指す状態：共通基盤の価値を検証できていて、導入プロダクトを広げていける判断ができる状態
- スケールできる状態を作り、広げる
- 共通基盤の価値を広げ、レバレッジの効く状態をつくるために、スケールに耐えうる状態に育て、導入の仕組みを作る、拡大フェーズです
- 目指す状態：各プロダクトのユースケースを満たし、各プロダクトチームが効率的、かつ安全に導入できる状態
- 当たり前に組み込まれる仕組みを作る
- 新規プロダクトづくりのオペレーションに組み込み、今後作られるプロダクトには当たり前に導入されている状態にするフェーズです
- 目指す状態：新規プロダクトを作るときには、当たり前に組み込まれるように仕組み化されている状態
（なお、ここでは初期の課題やソリューションのディスカバリーフェーズは割愛しています）
それぞれのフェーズについて説明していきます。
フェーズ1. 最初から大きく作らない。ターゲットを絞り、スケールしないことをして、検証と改善をする
フェーズ1では、その共通基盤を広げることがマルチプロダクト全体としての価値に繋がることが検証されている状態を目指します。
そのため、いきなり多くのプロダクトを対象とせず、プロダクトを絞って導入し、検証・改善を繰り返すことで、共通基盤の価値がユーザー、ビジネス、プロダクトにとって高いものになるよう育てていきます。 共通基盤は、プロダクトからの依存が増えるほど変更難易度が上がってしまうため、プロダクトを絞り、変更しやすい状態を保ったうえで、検証と改善を繰り返します。
このフェーズでは、スケールのためにコストは使いません。むしろ、スケールしないことを積極的に行い、学習していくことが重要です。
活動例
- 導入するプロダクトチームとコミュニケーションをとり、ユースケースや要求、課題を深く理解する
- 最初の価値検証ができるレベルでスコープを絞り込んだMVPを作り、目的としていたユーザーの課題を解決できるか、ビジネス価値を発揮できるか、ユースケース網羅性はあるかなどを検証し、改善する
- プロダクトへの導入をプロダクトチームに任せきらず、自分たちでも手を動かして体験し、何に工数がかかりそうか、何が導入障壁になりそうかを学習する
- プロダクトチームの設計や実装方針をサポートし、どこに迷いそうか、どういった事を気にするか、どういったユースケースだと対応が難しそうかを学習する
また、より多くの不確実性を潰すために、導入プロダクトの選定も重要になります。 不確実性があまりなく、導入が容易なプロダクトで検証してしまうと、十分な検証ができずスケールフェーズになってから困る場合がでてきてしまいます。 そのため、初期の導入プロダクトを選ぶ基準としては、以下のような観点を意識しておくのが良いのではと考えています。
- 課題が大きい
- ユースケースや業務、要求が複雑である
- すでに様々なユーザーに使われている
- その他、不確実性が高いことがある
複雑で、不確実性が高く、ユーザーに使われていて、課題解決インパクトの大きいプロダクトを選ぶことで、より多くのことを学習、検証でき、不確実性を早めに潰すことができます。
ただ、これはあくまで参考で、観点は色々あると思いますし、検証すべきプロダクトは１つとも限りません。事前に何を検証できればスケールの判断ができそうかを設計し、検証内容に合わせてプロダクトを選ぶことが必要になります。
また、このようなプロダクトを絞って導入していくアプローチを取る場合、共通基盤の機能や構造が、最初の導入プロダクトに引っ張られて、特化したものにならないよう注意することも重要になってきます。個別ケースに引っ張られると、他のプロダクトにとっては良くない、導入が難しい基盤になってしまうことがあり、個別のケースと全体最適は常に分けて考え、設計していくことが必要です。そのためにも、最初に風呂敷を広げ、広い解像度や全体最適な設計を持っておくことが重要になってきます。
フェーズ2. スケールできる状態を作り、活用プロダクトを広げていく
フェーズ1でスケールさせていく判断ができたら、フェーズ2では共通基盤を活用するプロダクトを広げていき、ユーザー価値、ビジネス価値、開発生産性にレバレッジを効かせていきます。
このフェーズでは、各プロダクトのユースケースを満たし、開発チームが簡単、安全に導入できるように共通基盤を育て、そのための仕組みを整えていきます。
活動例
- スケールに耐えうる状態にするため、MVPから共通機能を磨き込む
- 初期に落としていたユースケースの対応、エラー時の原因切り分けのための対応など
- 開発チームが簡単、安全に導入できるように仕組みを整える
- 導入を簡単にする共通ライブラリの作成
- 開発ドキュメントの充実 など
- 開発者コミュニティを作り、知識共有しながら課題を解決していける、共通基盤へのフィードバックをもらえるエコシステムを構築していく
- 各プロダクトチームとコミュニケーションを取り、必要に応じてサポートしながら適用を推進していく
今後も増え続けるマルチプロダクト展開を考慮すると、共通基盤チームがボトルネックにならないように、各チームが自律的に導入していける仕組みや、コミュニケーション設計をしていくことは非常に重要です。
私たちが実際に取り組んだ例として、社内で開発者コミュニティを作り、週に一度各プロダクトチームの開発者が集まって知識や課題の共有を行い、課題解決の促進、共通基盤へのフィードバックができるエコシステムを作ったことは、機能した取り組みの一つだったと感じています。
この取り組みを通して、導入プロダクト同士が悩んだ部分や工夫したこと、実際にどんなコードを書いたかを共有し合うことが出来たため、導入がスムーズになりましたし、共通基盤チームとしても実際の開発者の声を聞きながら学習し、改善していくことができました。
フェーズ3. オペレーションに組み込み、プロダクトづくりの当たり前にする
最後は、今後作られる新規プロダクトに対して、共通基盤が当たり前に導入されていくようにオペレーションに組み込んでいくフェーズです。
このフェーズでは、今後作られるプロダクトはほぼ工数をかけることなく、当たり前に、その共通基盤を導入でき、爆速で新規プロダクトを立ち上げていけるような状態を作っていきます。
活動例
- 新規プロダクト立ち上げの際のガイドラインやテンプレートへの追加
- 困ったときの導入サポート窓口の設置と周知
正直、ここはまだあまりできていない部分で、今後の課題として捉えています。（進めていくうえで学びができたらまた発信できればと思います）
まとめ
まだまだ道半ばで出来ていないこともたくさんありますが、プロダクト基盤チームを立ち上げて1年ほど活動し、学んできたことから、どう育てていくのが良いかについての考えを紹介しました。
この記事で特に伝えたかったことは、価値の検証されていない基盤を広げないことです。あくまで検討段階のものは仮説であり、それに本当に価値があるかどうかは検証しないとわかりません。
共通基盤であっても、しっかりと学習と検証のサイクルを回し、価値ある基盤を広げていくことが、マルチプロダクトの価値を高めることにつながります。もし価値が出せないと判断したら、広げるのをぐっとこらえる勇気や忍耐も、プロダクトマネージャーにとっては重要だと思います。
共通基盤は全プロダクトの価値を高めることもできますが、逆に下げてしまうこともある、とても重要な役割です。
実際には、小さく検証することが難しかったり、検証の切り分けがうまくできないこともあり難しい面もありますが、ユーザーに価値あるマルチプロダクトを届けていくために、今後もチャレンジしていきたいです。
私たちはプロダクトマネージャーを募集しています！
SmartHRでは引き続きPMの採用に注力しています。PM職に関する情報をまとめた記事がありますので、ぜひご一読ください。カジュアル面談のリンクなどもこちらに掲載しております。
