【SmartHR・VPoP】急成長SaaSのプロダクト組織課題四天王とSmartHRが実践する撃退法

スタートアップにおけるプロダクト開発でボトルネックとなりやすい組織づくり。組織に関して抱える課題は企業によって異なり、絶対的な正解は存在しない。それでも、他社事例を知ることで見えてくる解決策はあるはず。

本記事は、SmartHRでVP of Productを務める安達隆氏から、急成長を遂げるSaaSプロダクトが直面する「組織課題四天王」と、いまでも施行錯誤を繰り返しながら実践する対処法を教えていただきました。
※本記事は、10月27日に開催されたイベント「SELECK LIVE! for Startup#2」のレポート記事になります。

• keyboard_arrow_down レイターステージのSaaSにおける2つの問題／3つのニーズ
• keyboard_arrow_down そして浮上する「プロダクト課題四天王」
• keyboard_arrow_down 四天王を倒すべく、SmartHRが行った「実験」
• keyboard_arrow_down 色々取り組んでいても試行錯誤の日々

プロダクト組織のあり方は、事業環境というコンテキストに大きく左右される。安達氏は他社のPMと話す中で、レイターステージのSaaSは同じような悩みを抱えていることに気づいたという。

では、レイターステージはどのような事業環境に置かれがちなのか？それに対して、プロダクト組織にはどのような要件や課題が存在しているのか？そして、そういった要件や課題に対して、SmartHRはどのようなアプローチを取っているのか？

SmartHRのようなレイターステージのSaaSは「競争の激化」・「TAM（Total Addressable Market）の限界」という2つの問題に直面すると安達氏は語る。

まず、「競争の激化」とは、スタートアップがニッチでブルーオーシャンな領域で事業を展開していたはずなのに、他社が「あのジャンルは儲かるんだ」と気づいて参入してくるという問題。そこから価格競争も始まり、思うようにビジネスが展開できなくなってしまう。

もう1つの「TAMの限界」は、「市場の限界」とも言い換えられる。たとえば「日本国内」「SMB（Small and Medium Business）向け」「人事労務のクラウドサービス」というようにターゲット市場を設定すると、最大でどのくらいのユーザー・売上を獲得できるのかというのは事前に予測できてしまう。そんなとき、市場が求める成長曲線を描くためには、新たな打ち手が必要になるのだ。

これらを踏まえ、レイターステージのSaaSに求められるものが3つある。

1つ目がエンタープライズ対応。より単価の大きな顧客を取りに行き、売上を伸ばす方向に舵を切る戦略を取ることだ。しかしこれには、プロダクト自体が高機能で柔軟なカスタマイズができることが求められる。なぜなら、取引相手が大企業になれば、複雑な業務フローへの対応や基幹システムとの連携などが必要になってくるためだ。

2つ目がマルチプロダクト化。TAMの限界突破を目指し、隣接する市場を取りに行くために、別ジャンルのプロダクトをつくる戦略だ。また利用者側の観点でも複数のプロダクトを使い分けることは運用負荷が大きく、複数領域がオールインワンで利用できるプロダクトが求められる。

3つ目がプラットフォーム化。自分たちのプラットフォーム上に、サードパーティのサービスを巻き込んでいく戦略だ。これを実現するためには、他社のSaaSと連携しやすくすることが求められる。

これら3つのニーズを実現するためには、それに応えられる開発組織が必要になってくる。実現に向かって組織体制の変更・整備を実施していくなかで、4つの大きな課題（これを安達氏は「プロダクト課題四天王」と表現）が浮上したという。

第1に、意思決定の複雑化。プロダクトの規模が小さい頃は、プロダクト側とビジネス側の距離が近く、扱う問題の範囲も狭いのでスピーディーな意思決定がしやすい。しかし規模が大きくなってくると、開発の優先順位付けの難易度が上がり、エンタープライズ対応で要件定義のプロセスが複雑になってくる。

第2に、アジリティの維持。ビジネスが順調であればあるほど、組織は拡大し、開発メンバーもステークホルダーもどんどん増えていく。そんな中で、スケールとスピードをどう両立するかは大きな課題だ。

第3に、広域戦になること。成長のためには同時並行で複数のプロダクトを立ち上げる必要があり、領域・フェーズが異なるプロダクト間の連携も求められる。

そして第4に、技術的負債が溜まること。レイターステージに入ると、初期につくられたアーキテクチャに限界がやってくる。機能開発を止めずにどうやって技術的負債を解消するのか、というのが難しいポイントだという。

では、これらの課題に対して、SmartHRではどのように対処しているのか。

まず重要になるのが、意思決定プロセスの高速化なのだ。SmartHRでは、ボトムアップとトップダウンを組み合わせることで、スピードと全体最適の両立を図っているという。

ボトムアップのアプローチとしては、まずスクラム開発を全社的に採用。これにより、複雑な状況に対して、現場のメンバーが柔軟に対応できるようになる。また、ユーザーリサーチを行うことで、顧客課題の解像度を上げることにも努めている。

一方でトップダウンのアプローチとしては、経営陣を中心に、中長期の全体戦略とビジョンを策定し、部署間・プロジェクト間での優先順位にコンフリクトが起きた場合も、迅速な解決を図るためにトップダウンで意思決定を行っている。

他にもSmartHRでは、より機動的な開発体制が組めるように、アーキテクチャと組織構成にも気を配っている。SmartHRのプロダクト群は10個ほどのプロダクトから構成されており、リポジトリ単位でそれぞれ分割され、それぞれスクラムで開発を行っている。開発規模の大きい基本機能を除くほかのオプション機能は、少人数スクラムチームで機動的に動ける体制を構築している。

ただし基本機能の部分に関しては大きめのモノリスになっており、6チームの大規模スクラムで開発を行っている。ここは特に運営が難しく、今も試行錯誤を続けているという。

また、チームとマネジメントラインを「縦」と「横」で区切るマトリクス形式の組織図にも特徴がある。横軸は、職能横断のプロダクトチームで、チームの中で企画からリリースまで一貫して完遂することで開発スピードを担保している。一方で縦軸は職能で切り分けられており、必ず同じ職能を持った人が評価を行うという仕組みになっている。

例えば事業責任者が他の職能も評価する形を取っていると、短期的な売上に意識が向きがちになるとのことだ。縦軸にマネジメントラインをつくることで、短期的な利益のためにプロダクトの価値を毀損するようなことが起きにくい仕組みをつくっているという。

最近のSmartHRでは、開発効率の向上と今後のプラットフォーム化を見据えて、リファクタリングとリアーキテクティングの重要度が高まっているという。現行の体制では推進しにくい技術的負債の解消や、複数プロダクトが共通で利用する機能の開発などを加速させるため、開発体制をアップデートしていく議論を進めているそうだ。

外からはスマートで完成された組織に見えるSmartHRですが、安達氏によると「実際の開発現場はカオスで、色々実験しています」という。「これらの改善を手伝っていただける方の採用も強化しています」とセッションを締めくくった。

文：伊藤 祥太