増大したコミュニケーションコストはロードマップで解消　成長企業におけるチーム連携と課題解決のための施策

自己紹介と株式会社FLUXの事業について

Goto Hideaki氏：FLUXのGotoです。本日はよろしくお願いします。タイトルは「急成長なフェーズにおける成長戦略」です。

自己紹介です。Twitterはhidexirという名前でやっています。キャリアはずっとエンジニアをやっています。現在はPdMとソフトウェアエンジニアの両立しています。テクニカルPdMというジョブなのですが、テックリード業務とPdMが混ざっている感じになっています。

軽く会社の紹介をさせてください。「テクノロジーを、カンタンに。企業と人の可能性を最大化する。」というミッションバリューを掲げてやっています。2018年設立で、今4年目です。今は従業員数が95名ほどになっています。

事業は大きく2つやっています。AutoStreamと呼ばれる事業と、Siteflowと呼ばれる事業があります。簡単に説明させてください。

（スライドを示して）Siteflowが中小企業向けです。「名刺代わりにWebを持ちたい」というニーズに応えた、比較的軽量な意味でのメディアを作る時に、弊社のSiteflowエンジニアたちがノーコードでポチポチで作っていって、お客さんにWebを提供する事業です。

（スライドを示して）AutoStreamと呼ばれる事業です。簡単に言うと、メディアは広告を入れているケースが非常に多いですが、実は最適化がぜんぜんできていないので、そこを弊社がお手伝いしています。その他に、ブランドセーフティと呼ばれる不適切なアドを排除するツールや、アナリティクスなどのツールを導入しています。

そもそもロードマップとは？

ここから本題です。ロードマップについて、大項目を3つ用意しています。まずコンテキストによって変わるところ。次に、FLUXでどうやってロードマップ文化が定着したかという背景と、それに伴う失敗。最後に、実際に運用して共通的に見つかった「こういう施策がよかった」という点をみなさんに持ち帰ってもらえればと思います。

「そもそもロードマップとは」というところです。特別にどこからか定義を持ってきたわけではありませんが、僕がいた3社とも（ロードマップを）引いていて今に至り、文脈によってけっこう意味が変わる、というのが自分の中での答えです。

例えば、投資家に対する資料や、実際のセールスでの売上予想は、未来予想的な文脈で使われるケースもあります。

（スライドを示して）SaaSプロダクトのみなさんだと、たぶんこちらの文脈がより強いと思います。プロダクトの新規機能をいつまでに作るとか、リリースするとか、今エンジニアのリソースがどれぐらいあるとか。そういったものの工数管理・可視化の文脈で使われるケースも多いのではないかと思っています。

FLUXにおいて、僕らは「科学的にプロダクトを成功し続けられる仕組みを作るのを実現するための考え方の1つ」と定義しています。もう少しひもといて話すと、多少メンバーに属人化してしまうのですが、このようにロードマップを作ることで、誰でも7、8割の精度で、「だいたいこれぐらいの着地になる」ということを、再現性をもってトライできるところを1つ目標にしています。

FLUXでロードマップを作成した理由

なぜ作るのかというと、弊社で言えば（ロードマップを）立てなかった時と立てた時でどちらのフェーズも実際にあったのですが、結果的にロードマップを引いた時は、立てなかった頃と比べると、仮に目標達成ができなかったとしても、機会損失が少なくなった事実があったからです。

急激に成長した結果、ロードマップが必要になったというところです。創業当初に、創業メンバーとエンジニア2人の5、6人のメンバーで、いろいろなプロダクトを作ってPMF（Product Market Fit）を探していました。

当時はコミュニケーションコストは比較的かからなかったのですが、人の増加にともなって、やはりだんだん誰が何をしているのかがわからなくなってきました。

それが（起き始めたのが創業から）だいたい2年後ぐらいで、売上が何十倍にもなってきて、人も採用できるようになって、開発のエンジニアも増えて。会社の事業、特にステークホルダーと呼ばれる人たちと各チームの連携がとりにくくなり、スピードが鈍化したと感じました。

（スライドを示して）このグラフを見てもらうとわかるのですが、人の伸び方も、外部なども含めますが、2021年だけで100人を超えておおよそ倍になりました。急激な成長が行われているのは、定量的に見てもわかるかと思います。

コミュニケーションコストの増大で起きたこと

あらためてコミュニケーションコストの話をします。（スライドを示して）人が2人から6人になった時に、間に発生する線は指数関数的に増えていきます。こういうこともあり、みんなが今何をやっているのかを把握する意味でも、ロードマップは非常に重要です。

コミュニケーションコストが増大した結果、例えばセールスチームの〇〇さんと開発の△△さんが、同じものを作っているはずなのに人によって違う話をしていたり。同じ組織内でも、今誰がなんのプロジェクト、プロダクトをやっているのかがよくわからない、透明性がないみたいな状態になったり。チーム間での連携したアウトプットがうまく取れなくなったりしました。

例えば、本当は開発とつながっていくものだと思うのですが、セールスチームが本来売ろうとしていたものが作れていなくて、うまく連携できていないようなケースが実際に起きました。

（スライドを示して）まとめると、作りたいもの、売りたいものが乖離していました。会社の成長ファクターが、一部の人間に集中していました。これをもう少し詳細に説明をします。会社には問題がたくさんあると思いますが、問題意識に対して、解決したい一部の人たちだけが、事業成長のボールをドンドン拾うみたいなことが起きがちになっていました。

そういったことはすごくありがたいのですが、みんなで複数の課題を解決していく仕組み作りが非常に重要かなと思っています。個人のモチベーションに属人化しない組織を目指したいというところで、逆説的にロードマップが必要だというところはありました。

FLUXがロードマップに載せる開発ポートフォリオ

実際に開発において、どの会社も「じゃあ何を作るの？」「ロードマップに何を載せるの？」と悩んでいるかと思っています。FLUXの場合は、大きくポートフォリオを用意しています。

FLUXの場合は、新規プロダクト、既存プロダクトの継続的開発、負債解消的な文脈のものと、大きく3つあります。一般的には、どこの会社もやっているかなと思っています。FLUXの事業ドメインの特性上、比較的この開発スケジュールはシビアになります。

理由は、お客さんのほうである程度リリース時期が決まっているので、「遅れてしまってはいけない」「こういう機能がいつ頃にリリースされます」「導入します」ということが、比較的シビアになります。弊社はロードマップの精度の重要性が、比較的高いかと思っています。

（スライドを示して）ポートフォリオとして、先ほどの3つのもう少し詳細な説明です。まずTAM（Total Addressable Market）が小さい、売上が小さくても比較的高い確率で売上につなげられるもので、僕らはヒット的なプロジェクトと呼んでいます。

次に、TAMは大きいのですが不確実性が高く、開発に要するコストが高いものです。期間や人、マーケティング・広告といったコストという文脈です。

そして、僕はもともと技術者なので、継続的開発という言葉をよく使いますが、基本的にものは作り続けるもので、過去の提供製品から生まれてくる副産物の解消があります。

これら3つを、弊社はポートフォリオとして組んでいます。FLUXの場合は、今は大きく2：6：2の割合です。事業は比較的安定してきているので、より売上を倍にしていく施策を打つために、今はホームランを狙って、他は維持するかたちになっています。

FLUXにおけるロードマップの策定の流れ

FLUXにおけるロードマップの策定の流れがあります。弊社は基本的に、トップのリサーチチームや経営メンバーから、ある程度「こういう時期にこういうものがやりたい」ということが下りてくる会社なので、アンケートで来た「そもそも何を作っていいかわからない」というところは、今日は割愛させてください。

というのも、僕の中での考え方の一部として、何をやっていくかというところは、社長の仕事だったり、弊社ではリサーチチームが組織としてしっかりやるということになっています。

実際に「じゃあ何を作るか」となった時に、小さい課題に分解します。なぜかというと、大きい課題だと工数見積が非常に大変だからです。OKRではキーリザルト、KPIであればチームKPI、あとは今日のタイトルにもあるマイルストーンを決める感じです。

次は、それぞれのコストの計算です。最初はポイントでいいかなと思っています。実際に1ポイント1時間とか、1日とか。各会社であると思いますが、粒度の細かいところで切っていきます。最終的にステークホルダー、弊社で言えばチームリーダーや経営メンバー、外注先の担当とコミュニケーションを取ります。

（スライドを示して）次に、全体のスケジュールの流れとして非常によかったところです。弊社はクオーターが始まる、1クオーター前までに何をするかを基本的に確定させます。

例えば、2022年の1クオーターであれば、2021年の4クオーターにロードマップを開始して、終える必要があります。もちろん年間ロードマップも作りますが、まだまだ会社として若いので、基本的には半期先までを具体的に予想しています。

こちらも後ほど詳しく説明しますが、基本的には常に余白20パーセントを持っておくことを心がけています。これをひたすらグルグル回して、会社が成長していく感じです。

FLUXにおけるロードマップの決め方で組織的要因があります。僕はPM、PdMチームと一部開発みたいな感じではあるものの基本的には経営、各セールスチーム、開発チーム。当然採用も重要になってくるので、（それらチームと）話し合いながら何を作っていくかを決めていきます。

ロードマップを作って起きた2つの問題

実際に作ってみてどうだったのかは、結論としてたくさん失敗をしました。考慮できていない点を、具体的な問題ケースとして話してみたいと思います。

問題ケース1で、ロードマップを引いたが差し込みが入って進まないということはメチャクチャよくある話です。バグや障害だったり、実は無いものをセールスが勝手に売ってきてしまったりすることはどこの会社でもよくあって、似たような話は聞きます。これもやはりロードマップに組み込めていないのは問題なのですが、大きく2つに分解できるかと思っています。そもそも予想ができるものと予想ができないものとなってくると思います。

「予想ができるものに関しては、ロードマップや工数に盛り込む」とありますが、これは何をすればいいかというと、前もってロードマップをしっかり時間かけて作りましょうという話です。そうすることで、比較的抜け漏れは減らせるかと思います。

予想できないものに関しては、今後予想できるようにしていく必要があります。簡単でいいので、ドキュメントなどになるべくまとめておくのと、やはりバッファを持たせるのが非常に重要です。僕もいろいろな開発書を読みますが、共通的にバッファを持たせていて、実際にバッファを持たせてよかったといったところです。想定していない案件が落ちてくるところも、予想できないものの1つになるかと思っています。

問題ケース2は、マイルストーンやスケジュール設定ができないことです。この問題は、たぶん精度があまり出ないところに起因してくるかと思っています。

弊社も最初はそうでした。見積に対して基本的に係数を掛けていて、現在だと1.5です。例えば、〇〇さんにやってもらう1人月のところを、1.5ヶ月分で算出します。係数を掛けることでカバーして、余裕をもったスケジュールを設定しています。

これは繰り返しになりますが、とにかくサイクルを回すことを続けていきます。運用することのほうが重要なので、運用していく中で精度を上げていくことを心がけています。

ロードマップを引くにあたってよかったこと

ロードマップを引くにあたってよかったことです。僕がよかったと思うのは、ちょっとややこしいですが、ロードマップを決める人間を決めることです。会社組織が50人ぐらいに増えてきた時に、いろいろな意味でのステークホルダーが増えるので、誰が何を決めるかをある程度決めることで、スピーディに、より正確に作れるようになったと思います。

PM、PdMレイヤーの人たちは、ドメインエキスパートになることで非常にワークしたと思っています。根深い問題や潜在的リスクという洗い出しは、自分が今やっているビジネス領域に対して、どうしても興味と知識は一定必要だと感じます。

まとめになってきますが、先ほど話したとおり、20パーセントのバッファを持たせることで余裕が生まれました。仮に何も差し込みが無い場合は新しい投資ができるので、技術的な新規の挑戦などがプラスのワークに働きかけたかなと今は思っています。

（スライドを示して）SaaSのPdMとして、僕もPM、PdMという立場上、本当に幅広い能力が必要だと感じます。だからこそ、日々のインプットも20パーセントのバッファを作って、そこで学ぶのは非常に大事かなと思っています。

自分はもともとエンジニアリングを中心にやってきたので、特に技術系の工数見積は非常に高い精度でできます。こういったところは、誰もが気持ちよく働けるファクターになるのではないかと考えています。

最終的にポートフォリオを組んで、「では何をするか」は、たぶんPdMが中心に決めると思います。まずはヒットを狙うのか、ホームランを狙うのか、負債投資なのか。会社として全部をやるのはリソースをかけてもできないと思うので、何に力を入れたいのかを明確にしていく必要があると思います。

そして自分の会社の領域。（スライドには）ドメインと書いていますが、そもそも自分のプロダクトを回す（こと）、どういう事業をやっているかということに対して、しっかり理解を深めることが大事かなと思います。

ロードマップはサイクルを回すことで改善される

まとめです。ロードマップは作ってもうまくいかないというところで、先ほどから話しているとおり、サイクルを回すことでだんだんよくなるということです。ファクターがたくさんあるので、洗練する、減らす、誰が何を決めるかを決めるという話につながってきますが、しっかりここは決めておく必要があるかなと考えています。

そして、PM、PdMとしては定期的なインプットは大事で、ロードマップを作るところに関しては、時間とコストがかかるのはやはり前提として必要かと思います。

さらに、これがPM、PdMの仕事の一環でもあると思うのですが、ロードマップを作ること自体が比較的大変だということを、特に近いメンバーとステークホルダーに理解してもらうことが大事かなと思います。

弊社も急成長中で負債がたくさん溜まりやすい状態ですが、（この現状は）よくもあり悪くもあると思っています。そこをどれだけ味方にできるかというところかと僕は考えています。

だからこそ、科学的な成長ができるように、いいロードマップを作りましょうということで締めさせてください。宣伝になりますが、興味を持ってもらえたら、ぜひMeetyでお話しできればと考えています。よろしくお願いします。