スタートアップやベンチャーが成長していく際に、必ず突き当たるのが「チームづくり」や「組織構築」にまつわる課題。

人数が増えれば当然のように仕組み化が求められ、かつ創業時のカルチャーを維持するためには「チームで何を重視するのか」を明示化しなければならない。

エンジニアを採用をしていく上でも、どんな開発組織なのかを応募者に伝えなければならないし、一定の時間が経てば技術的負債との戦いも必要になる。CTOや開発リーダークラスのエンジニアは、人事評価も含めてどのようにチーム運営をしていくか、常に考え続けることが求められるのだ。

11月24日、東京・渋谷にあるイベント＆コミュニティスペース dots.にて、このテーマについて真正面から語り合うイベント『TECH TALKS -ソウゾウ×グノシー×エウレカ 技術トップが語るこれからのエンジニア組織-』が行われた。パネラーとして登壇した3人は全員、自社サービスの立ち上げ期から開発に携わり、開発チームが拡大していく中で要職に就いている人物だ。

株式会社ソウゾウで執行役員を務める鶴岡達也氏は、現在担当する地域コミュニティアプリ『メルカリ アッテ』を手掛ける前は、日米5500万ダウンロード超という一大サービスとなったフリマアプリ『メルカリ』をリリース前から開発してきた。

株式会社Gunosyの執行役員である松本勇気氏も、創業陣である3名が会社を法人化してすぐのタイミングでジョインし、その後インフラ構築、組織づくりの両面で手腕を発揮。現在は、同社の新規事業開発室でKDDI・沖縄セルラーとの共同開発であるニュース配信アプリ『ニュースパス』の開発もリードしている。

そして今年10月に執行役員CTOになった株式会社エウレカの金子慎太郎氏は、2012年に同社に転職後、主力サービスである恋愛・婚活マッチングサービス『pairs』およびカップル専用アプリ『Couples』の立ち上げメンバーとして開発に従事してきた。

ゼロイチから拡大期まで、一連の流れを経験してきた3人が語る組織論は、非常にシンプルな結論から始まった。特にサービスローンチ後の一定期間は、「組織づくりよりプロダクトづくりが大事」という話だ。

ならば、いつぐらいから組織づくりを意識し始め、どのようにチーム運営をしているのか。当日のパネルディスカッションをダイジェストで紹介しよう。

プロダクト初期段階のリーダーは「率先垂範」で開発に没頭せよ

まず、サービスの初期段階では「組織づくりよりプロダクトづくりが大事」である理由について説明していこう。

理由は各社で微妙に異なるが、共通していたのは「チームづくりよりもプロダクトを磨き上げるスピードの方が重要だから」という答えだ。

メルカリの鶴岡氏によると、同社は創業期のメンバーがほぼ全員エンジニア経験のある人ばかりだったこともあり、マネジメントだけをする人は皆無で、皆が開発かサービス企画に従事していたという。

そこからエンジニアチームが25名くらいになるまで、チームづくりは意図的にやらずにいたそう。メルカリの創業前にもいくつかのプロダクトで立ち上げを行っていた鶴岡氏の経験上、「プロダクトが一定以上に成長するまではリーダーも現場もなく開発に集中した方が効果的だから」だ。

このスタンスは、Gunosyもエウレカも同様である。エウレカの場合は「開発チームが7～8名くらいになった時に初めて、例えば『プロジェクト管理にはJIRAを使おう』といったルールを固めていった」と金子氏は振り返る。それまでの期間は、メルカリと同様に「1秒でも速くプロダクトを改善し、リリースすることを優先していた」そうだ。

開発チームがどの程度の規模になるまで突っ走るかはそれぞれだとしても、最初は組織づくりに時間を割くことより、100％プロダクト開発に集中してスピード重視で改善することが大事ということだろう。このフェーズにおけるリーダーの役割は、「率先垂範（自ら進んで手本を示す）」であると金子氏は強調する。

ただし、鶴岡氏やGunosy松本氏によると、社内で「2つ目のプロダクト」を開発する際は少々やり方が違ったという。

『メルカリ アッテ』を開発・運用するソウゾウでは、開発をリードできるエンジニアを据えてからすぐ組織づくりに着手したと鶴岡氏は言う。Gunosyとしての2つ目のプロダクトになる『ニュースパス』の開発時も、「必要なアーキテクチャを逆算してチームづくりも並行して行った」（松本氏）そうだ。

スタートアップしてゼロからプロダクトを立ち上げる場合と、そこで学んだことを土台にして社内の新規事業を立ち上げる場合は、少々毛色が異なるということだろう。

人員が増えたら「スモールチーム」、「適材適所」を意識するも、過度な分業には否定的

では、リーダーも現場も関係なくプロダクト開発に集中するフェーズから、徐々にチームづくりや評価制度などの仕組みづくりを始めるのはいつごろが妥当なのか。

前述したように、メルカリではチームの規模が25名程度、エウレカでは10名弱の規模になった段階で徐々に諸々の仕組み化を始めたという。Gunosyの場合は、30名くらいの規模になるまではチーム全員が数字を見ながら判断するようにしていたそうで、この文化は人数が増えた今も開発陣に根付いているという。

そのような中でも、鶴岡氏は「人数の規模で仕組み化を考えるというより、『そろそろチーム化した方がいいかも』という予兆にいつ気付くかが大事」と言う。例えば、コミュニケーション量が減って来たので1on1を仕組み化する、といったように、気付いたらすぐやるようにしてきた。

他方のエウレカ金子氏は、Amazonのジェフ・ベゾスCEOが推奨しているといわれる「2枚のピザ理論（2枚のピザで食欲を満たせる人数くらいが1チームの最適人数という考え）」を参考に、それ以上の人数になったらチーム運営のスタイルを変えるようにしてきたと話す。そのため、現在の『pairs』では事業部制（各事業ごとにディレクターやエンジニアを配するやり方）を採っており、人員拡大を続ける中で近く改めて組織を見直す予定だそうだ。

Gunosy松本氏もこれに近い考えを持っており、同社では「1人で5人以上のマネジメントはしない」という不文律で組織運営を行っているという。

とはいえ、3社ともにスモールチームで開発を進めることを念頭に置きつつも、過度な分業制や役割分担には否定的だ。

Gunosyの松本氏は「全体の意思決定はプロダクトオーナーが行うが、その他の細かな施策は現場発で考えてやれるようにしている。全員が『課題解決のできるエンジニア』であるという気持ちを持ってほしいということは、朝会とかで常々強調している」と話す。

ソウゾウの鶴岡氏も、「ある程度人数が増えると適材適所が大事になるが、本当に優秀なエンジニアとはすごく抽象度の高いリクエストをされた時にも適した答えを返せる人のはず。そういう人が活躍できるようにするには、細かく役割分担をし過ぎないことも大切だ」と続ける。

ベンチャーの場合は特に、どの規模になっても「課題解決し続ける人」こそが尊重されるということだろう。課題解決のできるエンジニアとはすなわち、「問題発見のための仮説構築からやれる人」（松本氏）なのだ。

取材・文・撮影／伊藤健吾（編集部）