最新情報をお届けします！
ホームページ作成サービスやWeb広告の入札最適化サービスなどを提供するFLUX。従業員数が約100名となり、急成長フェーズへ。ロードマップを引くべきか。そして実際にどう運用しているか。FLUXでPdMを務めるGoto Hideakiさんが語った。
※2022年2月8日に開催された【開発PM勉強会〜SaaSの開発ロードマップ、マイルストーンどう決める？〜】 より、株式会社FLUX Goto Hideaki さんによる【急成長なフェーズでの成長戦略 】を書き起こし形式でお届けします。
＞＞＞「開発PM勉強会」の記事一覧はこちら
FLUXの後藤と申します。本日はよろしくお願いします。「急成長のフェーズにおける成長戦略」と題してやらせていただきます。
改めて自己紹介ですが、Twitterを@hidexirという名前でやっています。キャリアとしてはエンジニアをやっていて、以前の職場ではPMをやり、今はがっつり本腰を入れてPdMをやっています。一応、会社としては「テクニカルPdM」というジョブで、テックリード業務とPdMが混ざった感じです。
会社の紹介を軽くさせてください。
「テクノロジーを、カンタンに。企業と人の可能性を最大化する」というミッションを掲げてやっています。設立が2018年で今年で4年目。従業員数は95名ほどになり、2020年末ぐらいにオフィスを大きくする大イベントがありました。
事業としては大きく2つやっていて「AutoStream」と「Siteflow」があります。
「Siteflow」は中小企業様向けに提供していて、「名刺代わりにWebがほしい」というニーズに応えるため、比較的軽量な意味でのメディアが作れます。サイトフローエンジニアみたいな方がいて、ノーコードでぽちぽちで作り、お客様にWebを提供する事業です。
もう一方の「AutoStream」が売上としてはメインで、広告をメディアさんに入れているケースが非常に多いんですけど、入札の最適化って実は全然できてなくて、そこをお手伝いする事業です。その他にブランドセーフティと呼ばれる不適切なアドを排除するツールの導入だったり、あとアナリティクスの導入、ちょっと右側にイメージを載せてるんですけど、こういったツールを導入したりしています。
ここは近日リリース予定ですけど、サードパーティーCookieが使えなくなるので、ここら辺の新しいソリューションの導入支援など、特許なども取りつつ、今やっている感じです。
本日「話さないこと」は、具体的なツールの使い方とか、どう作ってるのかなど。時間も限られているので、ちょっと具体的な部分は割愛させていただければなと思っています。
ここから本題ですが、改めて「ロードマップについて」というところでロードマップに3つ大きく大項目として用意しています。
・コンテキストによって変わるところ
・FLUXにどうロードマップ文化が定着したかの背景
・それに伴う失敗
などを話せればと思います。
最後に、実際に運用してみて共通的によかった施策など、少しでもみなさまに持ち帰っていただければと思います。
まずそもそもロードマップとは何か？ここは特別、どこかから定義を持ってきたわけじゃないですが、僕がいた会社はどこの会社も大体ロードマップは引いていました。その上で“文脈によって意味が変わる”っていうのが自分の中での答えになります。
たとえば、投資家様に対する資料や、セールスにおける売上予想は、未来予想的な文脈で使われるケースもあります。SaaSプロダクトに携わる皆さんであれば、プロダクトの新規機能をいつまでに作るとかリリースか、エンジニアのリソースが今どれぐらいあるか、そういったものの工数管理、可視化の文脈で使われるケースも多いのではないでしょうか。
FLUXにおいては「科学的にプロダクトを成功し続けられる仕組みを作る」を実現するための考え方の一つだと僕らは定義しています。
もう少し紐解くと、やっぱりメンバーに多少属人化しますが、こういうふうにロードマップを作ることで「7～8割の精度でだいたいこれぐらいの着地するだろう」といった再現性を持ってトライできるようにする。ここを一つ目標にしています。
また、「計画を立てずに失う機会損失を減らす」とも言っています。ロードマップを立てるって正直面倒くさいな…と僕自身も思います。じゃあ、何で作るのか、弊社でも立てなかった時と、立てた時、どっちのフェーズもあったのですが、仮に目標達成ができなかったとしても、「ロードマップを引いて失う機会損失」は、ロードマップを引かなかった頃に比べて、結果的に少なかったと。その事実があったから…という風になっています。
急激に成長した結果、ロードマップが必要になったわけですが、創業当初は本当に5～6人、創業メンバーとエンジニア2人ぐらいで、いろんなプロダクトを作っては、PMFを探していました。
当時はコミュニケーションコストが比較的かからなかったのですが、やっぱり人の増加に伴い、だんだん誰が何をしているのか、分からなくなってきました。そこから2年後ぐらいで売上が本当に何十倍にもなってきて。人も採用できるようになり、開発エンジニアも増えるにつれて、特にステークホルダーと各チームの連携において歯車が少しずつ狂い始めました。
従業員数の伸び方も下のグラフを見てもらってわかるんですけど、2021年だけで外部とかも含めてですが、100人を超えてきて。1年でおよそ倍になっており、急激な成長が定量的にもわかるかなと思います。
コミュニケーションコストでいくと、関わる人が「2人」から「6人」になっただけでも指数関数的に増えてくるんですね。
こういうこともあり、やっぱりみんなが何をやっているのか把握する意味でもロードマップが非常に重要になります。
コミュニケーションコストが増大した結果、たとえば、「セールスチームのAさん、開発のBさんは同じものを作っているはずなのに、どうも違う話をしている」といったことが起こりました。
同じ組織内でも今、誰が何のプロジェクト、プロダクトをやっているのかがよくわからない。チーム間で連携したアウトプットが上手く出せない。セールスチームが本来売ろうとしていたものが作れていない。本来、開発は「つながっていくもの」だと思うんですけど、それがうまく連携できてないケースが実際に起きました。
まとめると「作りたいもの」と「売りたいもの」が乖離しており、会社の成長ファクターが一部の人間に集中してしまいました。
もう少し詳細に説明をすると、会社って問題がたくさんありますが、「問題意識に対し、解決したい一部の人たちだけが、どんどんその事業成長ボールを拾う」みたいな事が起きがちになっていました。
そういったものは、すごくありがたい。ですが、やっぱみんなで複数の課題を解決していく仕組みづくりが非常に重要だと思っていて。個人のモチベーションに属人化しない、そういった組織を目指す上でロードマップが必要だと逆説的になっていきました。
実際に開発において、ロードマップに何を乗せるのか、どの会社さんもかなり悩んでいるのかなと思います。FLUXの場合、ポートフォリオをまず用意します。
・新規プロダクト
・既存プロダクトの継続的開発
・負債解消的な文脈のもの
と、大きく3つあります。一般的にはどこの会社さんもやっていると思っていて。FLUXの事業ドメインの特性上、比較的この開発スケジュールがシビアになります。お客様の方である程度リリース時期が決まっており、やっぱり遅れてしまってはいけない。「こういう機能はいつ頃にリリースされます」とか「導入します」というところが比較的シビアになるので、ロードマップの精度の重要性が比較的高いのかなと思っています。
ポートフォリオとして先ほどの3つをもう少し詳細に説明します。
1つ目が売上が比較的小さくても高い確率で売り上げに繋げられるようなもの。僕らは「ヒット」と呼んでるんですけれども、いわゆるヒット的なプロジェクト。
2つ目がTAMは大きいけれど、ちょっと不確実性が高く、開発や期間、もちろん人も含めてコストがかかるもの。マーケティング広告もそうですね。
3つ目が継続的開発です。僕はもともと技術者なのでよくわかるのですが、基本的なものを作り続けます。そこから生まれる改善、負債の解消といったところがあります。これら3つをポートフォリオとして組んでいます。
FLUXの場合、事業が比較的安定してきているので、2:6:2の割合で。売上を倍にしている施策を打つためにホームランを狙い、他は維持する形になっています。
FLUXにはロードマップの策定の流れがあります。基本的にトップのリサーチチーム、経営メンバーからある程度「こういう時期にこういうものがやりたい」と降りてきます。僕の考え方として、何をやっていくか、そこは社長の仕事だったり、リサーチチームが組織としてやるほうがいいと思っています。
実際にじゃあ何を作るのかとなった時、まず小さい課題に分解します。大きい課題だと工数の見積もりが非常に大変なので、OKRをやっているところであればKey Result（結果）、KPIであればチームKPIを決めていく、あとは今日のテーマでもあるマイルストーンを決めるみたいな感じです。
次はそれぞれのコストの計算ですが、最初は「ポイント」でいいかなと思っていて。実際に「1ポイント1時間」とか各会社さんであると思うんですけど、そういう形で粒度の細かいところで切っていきます。そこで最終的にステークホルダーとコミュニケーションを取ります。
全体スケジュールの流れとしては、非常にこれが良かったのですが、FLUXでは基本的に各Qが始まる前までに何をするか、確定させます。
たとえば、2022年の1Qであれば、2021年の4Qにロードマップを作る必要があります。もちろん年間ロードマップも作るのですが、まだまだ会社としては若いので基本的には半期先までを具体的に予想している形です。また、1Qはリソースとして基本的には余白を20%持っておくということを心がけています。ここは後ほど詳しく説明します。これらをずっとひたすらぐるぐる回し、会社が成長していく感じです。
続いて、FLUXにおけるロードマップの決まり方です。組織的要因があるのですが、僕は【PM PdMチーム】と一部【開発チーム】みたいなところにいて。基本的には【経営層】【セールスチーム】【開発チーム】【採用（人事）チーム】が重要になるので、話し合いながら何を作っていくか、決めていきます。
実際作ってみてどうだったのか。結論としてはたくさん失敗をしました。公表できていない具体的な問題ケースを話してみたいと思います。
まずロードマップを引いたが、差し込みが入って進まない。めちゃくちゃよくある話ですよね。
バグだったり、障害だったり。あとはセールスが勝手に無いサービスをお客様に伝えてしまったり。どこの会社でも似たような話は聞きますが、これもやっぱりロードマップに組み込めないところが問題ですが、大きく2つに分解できるかなと思っています。
そもそも「予想ができるもの」と「予想ができないもの」があります。「予想ができるもの」に関しては、ロードマップ工数に盛り込む感じにして、前もってロードマップを時間かけてつくりましょう、という話です。そうすることで、抜け漏れは比較的減らせると思います。一方で「予想できないもの」に関してですが、今後「予想できるようにしていく」が必要だと思います。簡単でいいのでドキュメントにまとめておくとか、やっぱりバッファを持たせることが非常に重要です。
僕もいろいろな開発者と話しますが、共通的に「バッファを持たせてよかった」という話になります。あとは「想定していない案件が落ちてくる」といったところも「予想できないもの」の一つかなと思っています。
問題ケース2はマイルストーンやスケジュール設定ができないということです。そもそもこの問題は、精度があまり出ないところに起因していると思います。FLUXも最初はそうでした。
見積もりに対して基本的に係数をかけていて、今現在だと「1.5」です。たとえば「◯◯さんにやってもらって広げていったところ、1.5か月分に算出する」といった感じです。そうすることで「ここはカバーしてざっくり余裕を持ったスケジュール」を設定します。
これはもう繰り返しですが、とにかくサイクルを回し、続けていく。運用することの方が重要なので、その中で精度を上げるところを心がけています。
ロードマップを引くにあたって良かったことは「ロードマップを決める人間を決める」です。少しややこしいですが、会社組織として50人くらいに増えた時、やっぱりいろんな意味でのステークホルダーが増えるので「誰が何を決めるか」ある程度決めることでスピーディー、且つより正確に作れるようになったと思います。
PM PdMレイヤーの人達って、ドメインエキスパートになることで非常にワークしたと思っていて。根深い問題、潜在的リスクの洗い出しに関しては、今やっているビジネス領域に対し、興味と知識は一定必要だと感じます。
まとめになりますが、20%バッファを持たせることで余裕が生まれました。余裕が生まれることで、仮に何も差し込みがない場合も新しい投資ができます。なので、技術的な新規の挑戦など、どんどんプラスに働けたかなと思っています。SaaSのPdMとして立場上、本当に幅広い能力が必要だと感じます。だからこそやっぱ日々のインプットっていうところも、20%のバッファを作って、そこで学ぶっていうのは非常に大事かなと思っています。
自分は元々エンジニアリングっていうところを中心にやってきたので、特に技術系の工数見積もりは非常に精度高くできています。こういったところってやっぱりなんか誰もが気持ちよく働けるファクターになるんじゃないかなとは考えています。
最終的にポートフォリオを組んで「じゃあ何をするか」は、PdMが中心に決めると思います。ヒットやホームランを狙うか、再投資なのか。会社として限られたリソースで全てはできないと思うので、何に力を入れたいのか、明確にする必要があると思います。
その上でもやはり自分の会社の領域、どういう事業をやっているか、理解を深めることが大事だと思います。
改めてまとめですが、「ロードマップは作ってもうまくいかない」はお話してきた通り、サイクルを回すことで、だんだん良くなっていくと思います。あとはファクターがたくさんあるので「洗練する（減らす）」「誰が何を決めるかを決める」という話につながってきます。
PM PdMとして定期的なインプットは非常に大事。ロードマップを作るところに関して、時間とコストがかかるのは前提だと思います。PM PdMの仕事の一環でもあるので「ロードマップを作ること自体、比較的大変なんだ」と近い距離のメンバーやステークホルダーに理解してもらうことも大事かなと思います。
FLUXも急成長し、たくさん負債がたまりやすい状態ですが、良くもあり、悪くもあるかなと思っていて。そこをどれだけ味方にできるかと僕は考えています。
だからこその科学的な成長ができるように、いいロードマップを作りましょう。そういった形で締めさせてください。ありがとうございました！
＞＞＞「開発PM勉強会」の記事一覧はこちら
編集 ＝ CAREER HACK
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください！
経営者たちの「現在に至るまでの困難＝ハードシングス」をテーマにした連載特集。HARD THINGS STORY（リーダーたちの迷いと決断）と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない！そんなNotionを愛する人々、チームのケースをお届け。
