【イベントレポート】TECH TALKS 〜ソウゾウ×グノシー×エウレカ 技術トップが語るこれからのエンジニア組織〜 #dotstechtalks

メルカリは、インテリジェンスが運営するイベント&コミュニティスペースdots.にて、エンジニアやエンジニアに関わる方向けに、「TECH TALKS 〜ソウゾウ×グノシー×エウレカ 技術トップが語るこれからのエンジニア組織〜」と題してイベントを開催。イベント今回、Pedia Newsでは、セッション&質疑応答の中から「立ち上げ時における “開発” と “チーム作り” の力配分」に関する各者の回答をご紹介する。

メルカリは、11月24日、インテリジェンスが運営するイベント&コミュニティスペースdots.にて、エンジニアやエンジニアに関わる方向けに、「TECH TALKS 〜ソウゾウ×グノシー×エウレカ 技術トップが語るこれからのエンジニア組織〜」と題してイベントを開催。

イベントは以下のような構成だった。

1. セッション&質疑応答
* パネラー:ソウゾウ 執行役員 鶴岡 達也氏、Gunosy 執行役員 松本 勇気氏、エウレカ 執行役員CTO 金子 慎太郎氏
* モデレーター :メルカリ 執行役員CTO 柄沢 聡太郎氏
2. Meet up time

今回、Pedia Newsでは、セッション&質疑応答の中から「立ち上げ時における “開発” と “チーム作り” の力配分」に関する各者の回答をご紹介する。このセッションには、パネラーに、ソウゾウ 執行役員 鶴岡 達也氏、Gunosy 執行役員 松本 勇気氏、エウレカ 執行役員CTO 金子 慎太郎氏、モデレーターに、メルカリ 執行役員CTO 柄沢 聡太郎氏が登壇し、Q&A形式で行われた。

### 立ち上げ時における “開発” と “チーム作り” の力配分

立ち上げ時における “開発” と “チーム作り” の力配分について、柄沢氏のモデレートのもと、パネラーの3者は以下のように答えた。

#### ○ ソウゾウの場合は?

**ソウゾウ 鶴岡氏**:まず、**メルカリの創業時は、経営陣も含めてみんなエンジニア経験がありました。**全員コードも書けて開発もできる状況で、マネージメントだけしている人はいませんでした。**「全員が開発あるいは企画してひたすら手を動かし続ける」**

メルカリでは、チームを作ることに関して、相当後ろまで意図的に遅らせていました。聡太郎さん(今回のモデレーターでもある、メルカリ 執行役員CTO 柄沢 聡太郎氏)が入社してから開発のチーム体制を作り始めました。**タイミングとしては、エンジニアチームが当時の会議室1部屋に入りきる人数でもあった25人を超える頃でしたね。**それまでは、僕ともう1人でエンジニアチームを見ていましたが、チームマネジメントは極力考えないようにしていました。その後、マネジメント専門の人が入るようになってから、スケールのことを考えるようになりました。そのため、**メルカリでは、「組織を作るフェーズ」「開発するフェーズ」をくっきり分けていました。**

**ソウゾウも、メルカリと近くて、リリースまでは少人数でみんな手を動かすことをしていましたが、バックオフィスのリソースなどはメルカリの力を借りれる状況だったので、早めにチームマネジメントのことを考えていました。**リリース後、リードエンジニアを採用できたらそのタイミングで、僕は手を動かさなくなってマネジメントに注力するという形で進めています。

**メルカリもソウゾウも両方とも、タイミングはずれていますが、「ガッツリ開発するフェーズ」と「マネジメントフェーズ」で分けていますね。**

チームマネジメントのタイミングについて、僕は、こういう条件が揃ったら行うというものではないと思っています。それよりも**「組織化した方がいいかも」ということに、いかにはやく気づけるか**だと思います。「どのくらいの頻度で1on1のコミュニケーションをするか」物理的に1個のテーブルにチームメンバーが収まらなくなると、必然的にコミュニケーション量も減っていくのですが、そういうことにどのタイミングで気づき、どう対処していくか、だと思います。

#### ○ Gunosyの場合は?

**Gunosy 松本氏**:僕らもメルカリやソウゾウと同じで、「基本的に誰もが何でもやる」スタンスです。僕は、**「スケールする速度が予測しやすいケース」「何も見えないカオスのケース」の2つがある**と思っています。

今回は先日KDDIと提供開始した『ニュースパス』というニュースアプリを中心に話しますね。**『ニュースアプリ』の場合は、前者で将来が見えていたので、アーキテクチャーをチームの考える将来に合わせた形で行うことを気をつけていました。**「明らかに異常な速度で成長する」、簡単に言えば「今のGunosyと同じ規模を作らないといけない」というのが見えている場合には、それには「どのくらいのチームが必要なのか」「どのようなチーム分けになるか」「それならシステムはどう分けていくか」といった、チームとアーキテクチャーを沿わせることに取り組んでいました。

**また我々の会社は今、スクラム開発を非常に重視しています。**スクラムのツールでインセプションデッキというものがありますが、**マネジメントのいらないチーム作りのためには「ゴール設定の明確化」「意思決定基準を明確化」が非常に重要だと考えており、まず一番最初にインセプションデッキを作るようにしています。**『Gunosy』の時は、どのようなニュースサービスが当たるのか未知だったので、その時は作らずに、数字を見て、どうすれば定量的に成長していくのかをみていましたね。

インセプションデッキを作るのに、2〜3日かけていますね。**インセプションデッキの良いところは、チームの中に判断軸をインストールできることです。**「意思決定基準の明確化」そうすることで、チームがスケールする時も、「俺たちはこの軸でどのような判断をしてサービスを運用していくか」がわかりやすくなります。だからこそ、スケールしやすくなったとも感じています。

**チームマネジメントのタイミングとしては、**個人的に、Gunosyは正直遅かった**と思っています。**「チームが大きな目標を達成するタイミングは、その先が見えなくなるタイミングでもある」**その時に、評価制度や福利厚生、チーム体制、責務などが表面化していくのを感じています。大きなリリース、例えば、サービスの売上の一定目標の達成、上場・M&Aなどのタイミングが見えてきたら、**その半年前から手当てしないと、ケアできない人が出てくるというのが、僕の正直な感想です。**チーム内で誰が誰を評価するのか、など自覚をちゃんと持ってもらうにはそれくらいの期間が必要だと思います。**やはり30人以上、かつ大きな目標を達成し始めると、組織が崩れ始めると思うので、その辺りから組織化するといいと思います。*

そのほか**Gunosyでは、1人で5人以上マネジメントしない**と決めています。5人以上でやるべきような開発はなかなかないとも思っているので、それでチームを分けてマネージャーをつけていくことを定量的にやっています。

#### ○ エウレカの場合は?

**エウレカ 金子氏**:僕らもほとんど同じですが、**初めはチームをきちんと作るよりも、それなら、サービスが売れなかったりすることもあるので、しっかりサービスを改善して成長させていく**方がいいですよね。それが**結果として組織全体のためになります。**

**エウレカの場合も、最初はチーム組織を作るよりも、サービスを開発するために、トップの人たちがしっかり手を動かしていきました。**ここでポイントなのは、**トップの人たちが率先的に開発していくことが重要**だと思っています。トップの人たちが手を動かさずに考えて数字を見て改善するだけでは、成長できない部分もあると思っています。**「ゼロイチのフェーズでは、絶対効果あるというものは1週間スパンでやっていかないと、サービスが成長しない」「すぐ手を動かして、すぐ改善して、すぐリリースする」**それが一番良いと思っています。『pairs』立ち上げ時もフルスクラッチの時もそれと同じような形でした。

フルスクラッチの時は「今あるPHPで書かれたものをGo言語にする」という明確な目的があったので、最初からできるメンバーを選んでチームを整えましたが、組織力を上げるよりもとにかく開発して少しでも早くリリースすることにコミットしました。台湾版と日本版で開発を進めて、合計で台湾版は11ヶ月、日本版は14ヶ月くらいかかりました。また、メンバーは、最初はミニマムの4名で始めて、ベースを作り、それが整ったタイミングの半年後くらいから人を増やして、9ヶ月後には7名、最終的にはアプリケーションエンジニアだけで10名くらいまで増えました。4名から7名に増えたタイミングで、QAも進めていたので、密にコミュニケーションをとったり、JIRAを使ったりしていましたね。

**チームマネジメントのタイミングについては、Amazonのジェフ・ベゾスが提唱する「2枚のピザ理論」が僕の中では一つあると思っています。**