こんにちは、Startup Tech Live事務局です。「エンジニア組織のグロースに必要な知見の流通」をテーマに様々なイベントを開催しております。

こちらは2023年6月29日に開催したIVS2023でのセッション「PMF達成後に描く、開発組織のスケーリング戦略」のイベントレポートになります。
今回はモデレータにグロービス・キャピタル・パートナーズの堀江、グロービスVPoE末永氏とナレッジワークCTO川中氏、マネーフォワードVPoEの高井氏に登壇いただきました。（記事内では敬称略とさせていただいております。）

内容が非常に盛りだくさんだった本セッション。1記事には収まりきらず、Vol.1/Vol.2で掲載させていただきます。（こちらはVol.1の記事になります）
Vol.2はこちら

スピーカー

モデレータ

堀江）「開発組織のスケーリング」が本日のテーマですが、スタートアップはシード、アーリ、ミドル、レイターのように階段を上がっていくように変化します。
それぞれのフェーズにおいて求められる会社の重要なテーマや社員の規模、それこそ開発のチームのあり方が変わります。本日は特にこのPMF後の3つのフェーズについて段階を追って議論していきたいと思います。

お三方にあらかじめ各フェーズにおける課題感をヒアリングして簡単にキーワードをプロットしてみました。これをベースにしながら議論を深掘りしていきたいなと思っています。

まず1つ目、人や組織の悩みが大きくある中で、CTOの負荷が大きくなってくる、リーダー不在による問題をよく拝見するのですがその点いかがでしょうか？

末永）皆さん近いようなこと書いてるなと思いましたね。
私はグロービスにエンジニア1人目として入社しましたが、その後だいたい1年ぐらいで20人ほどの組織になりました。
その当時は私がリードしながら全メンバーを見るという形だったので1週間で20人と1on1していました。自分の時間が溶ける状況を体験しましたね。

1年ぐらいでこのスケールをすると次の人に任せることもなかなかできなく、もどかしい状態でした。
小さいプロジェクトあたりは少しづつ任せていくことができましたが、自分の時間をどう作るかというところが非常に難しい状況でした。

高井）1on1はどういった内容でしたか？

末永）当時はそこまで詳細に決めていませんでした。今は1on1はメンバーのための時間ということにこだわっています。

毎週30分をセットしていましたが、本当に時間がないときは15分でお願いしますと言っていましたね。当時のフェーズだと会話（コミュニケーション）が特に大事だったので時間を作っていましたが、本当に忙しかったなという記憶です。
ようやくいい方が入社し、成長してきたこともあり段々と任せることができてきました。

堀江）川中さんにも似たような経験はありましたか？

川中）ありますね。1週間30分の1on1をやっていましたが、組織が10人くらいになったタイミングで辛くなってきて1on1を隔週に変更することにしました。

このアーリーフェーズのタイミングは、組織課題もあるんですが、最初は技術設計をしっかり考え込まないとだめだとずっと思っていたので、そこに時間を使いたいと思っていました。人・組織は良いメンバーがいる、マネジメントした人もみんな頑張ってくれて乗り越えたという感じです。

この時は全社で30人のうち26人ぐらいがリファラルで入社してくれたメンバーでした。
私もそうですが、何名かリファラルをすごく頑張ってくれて1人で10人連れてきてくれた人もいました。

高井）リファラルはインセンティブをつけていますか？

 川中）インセンティブはつけていません。みんな、自分が頑張らなかったらこの会社は崩壊するみたいな強い責任感の上で、仕事に取り組んでくれるので良いチームもつくれたと思います。

 堀江）なるほど、ありがとうございます。このアーリー期って会社がすごく変化するタイミングだと思います。

プロダクトが売れるようになり、ユーザー（お客さん）からの要望も増える。とはいえプロダクト開発も頑張らなきゃいけない。
その中でメンバーマネジメントにどの程度マインドシェアを割くべきなのか。先を見据えて時間として投資すべきなのか、プロダクト・技術にフォーカスすべきなのか。皆さんはいかがでしょうか？

高井）この時期は3倍頑張るという感じですかね。

川中）3倍頑張る正しい（笑）CTO、VPoEが3倍頑張る。これが正解ですね。

末永）そうですね。振り返るとプロダクトと人は両方見ていましたね。ただプロダクト周りは任せていきたいという思いはあったので、PdMの採用にはすごく力を入れていました。

川中）意思決定することにあまり時間を使いたくないと思っているので、なるべくルール化をし、このルールでやってくれたら問題ないという前提のもとルールをいくつか作っていました。
マネージャーである程度判断できる状態にしました。
振り返ってもこういったルール化はやっておいてよかったと思います。

このルールを作りました、このルールに沿ってくれたら問題ない。このルールに沿って考えてほしい。そのルールもみんなで作ろうという雰囲気になり、意思決定における負荷がだいぶ減ったと思ってます。

堀江）ナレッジワーク社はすでにアーリー期を脱しつつあるのかもしれないですね。ちなみにルールは具体的にどういうルールですか。

川中）例えばスプリントの回し方、プロダクトの設計とアーキテクチャ、コードレビューのプロセス、1on1のアジェンダ等細かいこともドキュメント化していました。
このフェーズでちゃんと言語化してシステムとして落とすということは、割とちゃんとやってる方だと思います。

高井）ルール化ができて運用できているのがすごいですね。誤解を生むことはないですか？

川中）誤解はあまりないですね。ルールの前にスタイルというものがあります。いわゆるミッション・ビジョン・バリューのバリューに相当することを僕らはスタイルと呼んでいます。
エンジニア組織だけじゃなくて会社全体でかなりのコストをかけてつくりました。
「陰口や悪口を言わない」などの日常的な行動レベルの規範も含みますが、その結果、連携や協調志向を組織で育めたと思います。

末永）私も一番初期にやったのはドキュメント化でした。人によって考え方が違うのでドキュメントツールを入れて、そこに情報を全部残していく、共通理解できる状態にしようということにはこだわって導入しました。
その辺は初期のタイミングでやっておいたほうがいいなと思いますね。
作るのも結構大変なんですが、メンテナンスが辛いですね。

みんなにどう使ってもらうかも重要で、最初は日報ツールみたいな使い方にして、全員の日報に私が毎日リアクション・コメントをするようにして、毎日みんなに使ってもらうことを工夫していました。

高井）ハードルを下げること、あとはフィードバックをするというのは使ってもらう人を増やす上ですごく重要ですよね。

川中）確かに。あと一番最初にある程度ちゃんとものを作ることは結構重要かなと思っています。
あるのが当たり前になると、ないことが不安になってくるっていう文化を作れたら大きいと思ってます。

高井）メンバーに書いてほしいとお願いするのも大事ですよね。一周回るまではお願いし続けたり、自分で書いたりしていくことでスタンダードになっていきますね。

堀江）ありがとうございます。
いわゆる会社組織となる最初のフェーズがアーリーだとしたときに、今の話のように人・組織が動くためのドキュメント化をつくっていくのが最初のステップだという話と、中長期的に組織を作っていく上で人に対する時間のアテンションやマインドシェアを取りに行くことは当たり前に重要（忙殺される中でどう適切に時間を生み出すのかが重要）だと思いました。

技術・プロダクトの課題にも触れていきます。
作るフェーズから、運用していくフェーズに変化する中で会社としてどう向き合うか。メンバーの増加や、顧客からの要望にばらつきがでると、質の面が気になってくると思います。

運用と開発のバランスみたいな話についていかがでしょうか？

 末永）グロービスは特殊例かもしれませんが、既存顧客の規模が大きいのが、グロービスの1つの特徴としてあると思います。
ありがたいことに一番最初にプロダクトを出した後にすごくたくさんのユーザーさんがついてくれました。

初期で一気に顧客が入ってきたこともありリリース直後にいろんな問題が起きました。
日々の運用や不具合の修正、いろんなところから来る要望。これらに向き合うために相当な時間を費やしました。もっと新しい機能をどんどん追加していきたいのに、それができないというのが当時私たちのチームが思っていた状況ですね。

川中）ナレッジワークは逆で、一気にユーザーがつくわけではないのでバグがいっぱい出るみたいなことはあんまりなくプロダクト開発を粛々と続けていきました。
開発品質自体がそんなに悪くなかったんで運用負荷はあんまりなかったかなと記憶しています。リファクタリングをやりたいんだけどプロダクト開発を優先しちゃうっていうのは当然ありましたね。

堀江）開発品質で凌げたっていうのがすごい重要だと思ってて、初期から先を見据えた設計・プロダクトのロードマップ策定があったからこそ、ピボットする際でも最小の工数で走れたのではないかと思っています。

代表の麻野さんのプロダクトの設計力と川中さんのアーキテクチャの設計力があったから実現できたのではないかと勝手に思っていますがどうですかね。

川中）それは結構あると思います。前述でもお話しましたが設計にはかなりの時間を使いましたし、私としても自信のある領域でした。

堀江）このアーリーの時って当然プロダクトの変化も発生すると思います。その中でちょっとした軌道修正があったり、右行こうと思っていたらいきなり左だよ！みたいな。
それを繰り返せば繰り返すほど品質の問題や負債の話になると思っていますがいかがですかね？

川中）ナレッジワークにもピボットはありました。ただ私はピボットの予兆を感じとるのであらかじめリファクタリングしておくというのを勝手にやっていましたね。

末永）予兆非常にいいですね！そこを感じ取れないと難しいですよね。

川中）そうですね。未来を予測して、これを作ったということは次はこれ作るに違いないとか、ちょっと前から言ってることが変わってきたなきっとこういうことやりたいんだろうなって想像して少しずつ変えていくというのをやってました。

末永）個人的には戦略が変われば、いくらいいコードを書いてても負債になると思っているので、その予兆があったときにやっぱりリファクタリングしないといけないですよね。
すごいいいバランスでやられてるんだなと思いました。

高井）みんなのウェディングはDeNAさんからのスピンオフでPerlを使っていたんですよね。新規開発も難しい、新しい人も採用しにくいということもありRailsに切り替えながら開発をしていきましょうと判断しました。

初期の設計がいいからそういうの困らなかったという話を聞くとやっぱり開発組織の価値というか、ビジネスサイドからみたらわかりにくいかもしれませんが、判断の重要さはあると思いますね。

 川中）これなかなか伝わらないんですよね。開発者と仲良くなりたいという方は、こういうのができている開発組織であればぜひ褒めてあげてください。（笑）

高井）アーリーフェーズでのコツは頑張るしかないと思うんですよね。
もうちょっと経つと技術ポートフォリオを考えて新規事業は今までやったことのないやつで開発してみようとかできるようになると思うんですけど、この頃はどうするのがいいですかね。

川中）この頃はそもそも人がいないんでポートフォリオもない。分散投資できませんという感じだと思うんで、一点投資でいいやつに張るしかなかったと思います。

堀江）私の仮説ですが、事業側でプロダクトを作っている責任者はこのフェーズだとおそらくCEOだと思うんですけど、そのCEOとCTOの間のコミュニケーションの密度が重要だと思っています。
CEOがどういう戦略でどういう価値をプロダクトに落とし込みたいのかを同じレベルで理解をして、高頻度で議論してるからこそ予見できるみたいなことではないかと思います。

川中）そこはその通りですね。弊社の場合コミュニケーションはすごく密にやっています。
毎日、その当時は1時間ぐらいはプロダクトについて話す時間を設けていましたね。
僕とCEOだけじゃなくて当時10人-15人ぐらいいる全員出席でプロダクトについて話す時間も作っていました。

堀江）川中さんがCTOとしてその事業課題を技術課題に翻訳することをやっていたんだなと感じました。
CEOの言葉を噛み砕いて技術的なアクションレベルまで翻訳する。
こういう事業課題があるから技術課題はこうとか、こういう事業戦略があるから技術戦略はこうだという翻訳家的存在だったのではないかなと。

Vol.1はここまで。
Vol.2ではミドルフェーズ、レイターフェーズでのお話に切り込んでいきたいと思います。ご覧ください。