2004年に創業、世界初のモバイルゲームを開発し一大ムーブメントを起こしたグリーと、2013年に創業し日本に二次流通市場を拡げたメルカリ。

サービスの性質や歴史は異なるが、短期間で会社規模が大きくなり、それとともにエンジニア組織も急速に拡大した点は共通する。

ゼロからの組織・サービスを立ち上げ、「スタートアップ」「ベンチャー」と呼ばれた時代を超えて、巨大テックカンパニーになろうとしている両社が、開発組織を数百名規模まで大きくさせる上で突き当たった壁とはどのようなものだったのか。

グリーで2005年から16年にわたってエンジニアリング組織の拡大を支えている藤本真樹さんと、2020年7月からVPoEを務め、2021年7月にCTOに就任した若狭建さんに、組織の拡大期における学びや気付きを語ってもらった。

マルチプロダクトなグリー、シングルプロダクトで結合度の高いメルカリ

若狭：グループ全体に関していうと、メルカリでは2017年から2019年ごろまでかなり採用を強化していて、年間の社員増加率が20～30%になることもありました。エンジニア組織についても同じような動きで、2017年からの1年間で一気に3倍ほどの規模に拡大しましたね。

ただ、2020年ごろからはコロナ禍に伴い採用もセーフモードに入ったため、そこから従業員数も横ばいです。

藤本：グリーでは上場3～5年目にあたる2011年～2013年は年間数百名単位で社員が増えていました。2014年以降は大体1500～1600人ほどで安定しています。全社員数のうち、大体3～4割がエンジニア職ですかねー。

藤本：一方で最近感じているのは、「従業員数＝会社の大きさ」とは一概に言えなくなってきているということです。

コロナ禍に突入してからは、副業や業務委託で関わっていただく方も増えていますし、チームのつくり方や働き方もさらに多様になってきています。

「社員数は5人だけど業務委託や副業の方が1万人いる」みたいな会社もあるかもしれないですし。

若狭：たしかにそれは言えますね。

藤本：そもそもメルカリさんとグリーでは、組織の性質も違うので従業員数で比較するのは難しい面もありますよね。

グリーの場合はゲームや広告、最近だとメタバースと多様な事業を展開していて、ゲームタイトルだけでいっても20タイトル以上運営しています。一方メルカリさんは、極論シングルプロダクトといっても過言ではないわけですから。

若狭：そうですね。スマホ決済サービスの『メルペイ』やEコマースプラットフォームの『メルカリShops』などはあるものの、基本的には『メルカリ』に全て連携させていますし、一つの大きなプロダクトを担っていると言えます。

藤本：グリーの場合は共通基盤みたいなものはあれど、ゲームタイトルごとに違うチームを組んで開発しているんです。40～50人くらいのチームで作っているプロダクトがたくさんある状態。

だから、メルカリさんと比べると、ある意味グリーの方がだいぶ楽なところがあるんですよね。例えば、言語選択一つとってもチームごとに適した言語を使う、といった臨機応変な対応ができますから。

若狭：おっしゃる通り、プロダクトが分かれていればそれぞれが必然的に疎結合になるので、動きやすさはありますよね。

シングルプロダクトの場合、残念ながらモジュールが密結合になることを止める手立てがデフォルトでは存在しません。

組織、特にエンジニアリング組織を拡大するにあたって、作るものもどんどん大きくなっていくし、それに比例して人もモジュールも増える。いや、比例どころの話ではなくて、依存関係は指数関数的に増えていきます。

すると、何かしらリリースしようとしても変更の影響範囲が大きくなって、「ここを変更したいんですけどいいですか？」と関係各所に許可を取らなければいけないし、その関係者もどんどんと増えていく。調整コストが膨れ上がっていくわけです。

藤本：グリーもかつて、一つのプラットフォームを数百人単位で作っていた時は大変でしたよ。今は「個別タイトルがそれぞれ」という側面が強いから、プロダクト間の連携があまり取れていなくても何とかなるので、そのあたりの負担はかなりなくなりましたが。

若狭：開発を持続可能なものにするため、メルカリはAPIで連携された疎結合なシステムにしていく必要があります。今後はチーム間で密に協業し、それを実現していく方針です。

「ソフトウエア」と「人」は同じようにはいかない

若狭：先ほどの話にもつながりますが、メルカリには「変更が容易なソフトウエアを作る」という大きなチャレンジがありました。

そこで2018年の8月にマイクロサービスに舵を切ったんですよ。それで、「じゃあマイクロサービスを実現するための組織とは」という話をして、各モジュールが自律的に機能するのと同様に、組織もそれと同じ構造にしようとしていたんです。「逆コンウェイの法則（※）」というやつですね。

※コンウェイの法則：組織構造や組織の生産性がソフトウエアやアーキテクチャに反映されるという法則。逆コンウェイの法則はこれを逆手に取り、目指すソフトウエアやアーキテクチャに合う組織を設計するというもの

若狭：でも、これは上手くいったかどうかは抜きにして、個人的にはかなり野心的な挑戦だったなと思います。やっぱりソフトウエアとエンジニア（人）は違うんですよ。同じように扱うのは難しい。前職のGoogleを振り返ってみると、誰もマイクロサービスとか言ってなかったんですよ。

藤本：だってGoogleってモノレポって話ですよね。かなり巨大な（笑）

若狭：そう。でも、思い起こせばエンジニア一人一人はかなりマクロなサービスを触ってたんです。つまり「組織の話と作っているものの話って、そこまでリンクしてないんじゃない？」と思ったりするわけです。

で、モノリスからマイクロサービスに切り出そうとしたときに、どう切ればいいかなんて誰も分からないじゃないですか。

この切り方で良いのかなんて分かんないけど、とりあえず切る。マイクロサービスと組織は相似形でやりたいから組織も同じように切る。でも、後で「この切り方は間違いだったね」なんて話もあるわけです。

すると、ソフトウエアは100歩譲って直せばいいですけど、組織は簡単には直せないじゃないですか。「チームAの一部をチームBに合流させよう」と言ったって、そこにはいろいろな調整が発生して、数週間、ときには数カ月を要することもあります。

藤本：人には感情がありますからね。揉めたりとかもあるだろうし、不満も出てくるだろうし。

若狭：切り方を間違えること、失敗をすること自体は後で直せばいいので全然いいんですけどね。でも組織は簡単には直せない。それがつらいんですよ。

つまり、個人的にはマイクロサービスは銀の弾丸ではなく、一つの手段でしかないなと。モノリシックが悪いわけでもマイクロサービスが万能というわけでもありません。

藤本：Shopifyとか、マイクロサービス化からモノリシックに切り戻しているケースもありますしね。

メルカリさんの「マイクロサービスでどうやって組織をつくっていくか」という課題に近い話でいうならば、グリーはシングルプロダクトでわーっとすさまじい勢いで採用をして、組織をスケールさせてきました。

でも、結局その勢いが続かなくて、スローダウンすることになった。僕らの成熟度が至らなかったんですよね。結局、スケールさせた組織を生かしきれなくて、新しいチャレンジや事業成長を思ったほど実現できませんでした。

そこで一度立ち止まって成熟度を上げて、もう一回チャレンジしようというところまできたのがこの5～6年かなと。

だから、グリーとメルカリさんで創業時期やこれまでの道筋に違いはあれど、それぞれ苦労をして結果的に今同じラインに立っている感じがしますね。

若狭：でも、グリーさんの方が歴史が断然長いので、その分超えてきた山の数は多いんじゃないかとは思います。

藤本：事業の戦略・戦術自体が上手に描けていなかった面もあるし、組織のカルチャーがバラバラになってしまい、みんなが違う方向を向いてしまった面もありました。

組織については特に、急激に人が増えた時に生まれる典型的な問題がたくさん起きていたように思います。

若狭：質問なんですが、人が増えると当然オンボーディングが必要になってくるじゃないですか。グリーさんはその辺はどうしていたんですか？

藤本：エンジニアリングチームにコンスタントに一定の人数が入ってきていた時は、「ブートキャンプチーム」というものを作っていました。

入社したら一定期間そのチームに入って、課題をやったりグリーならではのローカルな開発方法を学んだりするんです。求める基準をクリアできたら卒業。そこで同期のような仲間もできるわけです。

若狭：ローカルなドメイン知識って大切ですよね。自分の持っているテックスタックと違う場合もありますし。

藤本：めちゃくちゃ優秀な人でもgitを使ったことがない人もいますしね。独自のツールチェインを発展させまくってる会社もありますし。

組織が大きくなるほど、ローカルルールや会社固有のシステム知識も必要になってくるじゃないですか。それらを知ってもらったり、リレーションを作ったりする機会を提供するのは、エンジニア採用を強化するフェーズでは特に大事なことだと思います。

若狭：メルカリは新卒向けには似たような仕組みをつくっていますが、中途採用では、オリエンテーションや、一部のローカルルールの浸透、技術領域ごとのオンボーディングの作成などは始めているものの、まだまだ不十分な点が多く、コンテンツの拡充は引き続き課題となっています。

オンボーディングの仕組みがないと、各チームで「メンター」となっているメンバーの負荷が上がってしまうので。

これはジュニア・シニア問題にもつながるんですが、メルカリでは組織をスケールさせるときにジュニア層とシニア層の比率を是正することに苦労したんですよ。

実は一時期、エンジニアのジュニア層の割合が多くなってしまったことがありました。

いくらポテンシャルのある若手を集めたとしても、実務経験のない人には社会人エンジニアとしての振る舞い方なども含めて教えなければいけないことがたくさんある。

当時は、シニア層から「若手育成に時間をとられて、仕事が全然進まない」という声が上がることも……。

そこで、一定の経験値を持った方をより多く採用する方向へ舵を切りました。

藤本：それはグリーも同じですね。開発組織を一気にスケールさせた時（2011年ごろ）、とにかく人数を採用しようという状況でうまくいかなかったことがあります。

「採用基準を満たす人を採用する」ことよりも、「採用人数を決められた期間内に達成すること」に意識が向いた結果、カルチャーにマッチしない人や求める経験・スキルが足りない人が社内に増えてきてしまった。

本来は「迷ったら採用しない」が鉄則中の鉄則なんですけど、それとは逆のことをやってしまっていました。

若狭：「迷ったら採用しない」。そうなんですよね。昔読んだ『Joel on Software（ジョエル・オン・ソフトウェア）』（オーム社）にも書いてありましたよ。 ……守るのは大変ですけどね。

メルカリが目指すのは、一人一人が意思決定できる自律性

若狭：ええ。だから僕らがCTOとしてやらなければいけないのは、組織が大きくなっても、変わったとしても、エンジニアが開発に集中できる環境づくりをし続けること。

エンジニアが社内調整や書類作りなど開発以外のことに時間を使っていると、組織の開発力は上がっていきません。どれだけ開発以外のことにリソースを取られないようにするか。これからは、そこにさらに注力していきたいですね。

特に直近では、エンジニアリングとは別の組織の中にTechPM（テクニカルプログラムマネジャー）というチームを置いて、EM（エンジニアリングマネジャー）の負荷を下げようとしています。

藤本：EMは大変ですよね。エンジニアリングもするし、チームマネジメントもするし、プロジェクトマネジメントもやるし。グリーでも今後は、プロジェクトの部分はPM（プロジェクトマネージャー）にもっと任せていくとかできるといいなーとは思っていますけどね。

若狭：メルカリがこれから目指したいのは、誤解を恐れずに言うと「マネジャーのいらないエンジニア組織」なんですよ。メルカリのエンジニアには、一人一人がもっと自律的であってほしい。

前CTOの名村もよく「マイクロディシジョン」の重要性を説いていました。要は、エンジニア一人一人が”大人”になって、自分で意思決定を下し、自分で責任を持って仕事を進めてほしいということですね。

藤本：メルカリさんはすでにそこをうまくやっている印象でした。でも、ざっくりとでも方向性を決めるリーダーの存在は必要ですよね？

若狭：そうかもしれません。もう少しEMの負荷を減らしても開発がしっかり回っている状態にしたい。EMはチームのハイレベルな方向性の決定、チーム全体としての生産性向上や成果の最大化、メンバーの成長のサポートなど、本来やるべきことにもっと時間を割けるようにしたいところです。

若狭：そうですね。事業の変化に従ってどういう組織が最適か模索し続けることが大切だと思います。

藤本：正解はないけど、組織は「変わること」を止めた瞬間にだめになりますからね。そういう意味で、メルカリさんは常に変化し続けていてすごい。

若狭：結構大変ですけどね。「変わり過ぎだろ」という説もあるし（笑）

藤本：うちは逆に「変わんな過ぎだろ」という説があります。特にCTOが。

若狭：1社で16年以上もCTOを続けているのは、本当にすごいことですよね。藤本さんにしかできないかもしれない（笑）

「複雑でデカい課題」が、大企業には待っている

若狭：技術基盤にはしっかり投資していきたいです。特にC2Cマーケットプレイスでいうと、トランザクションと呼ばれる取引のところや、出品アイテム、アカウント管理、ペイメント、ロジスティックスと呼ばれる配送の部分。

藤本：うちで言えばIDや課金、ペイメントの部分ですね。

若狭：ここをもっとモジュールごとにしっかり切り出したいんですよ。それで直近「RFS（Robust Foundation for Speed）」という技術基盤強化のプロジェクトを立ち上げました。

藤本：会社として基盤への投資に踏み出したわけですか。気になりますね。

若狭：この表現は個人的にはあまり好きではないですが、これまでもいわゆる「技術的負債の返済」に取り組んではきていたものの、どうしてもビジネスサイドの方々にその重要性があまり理解されず、新機能のリリースに比べたらプライオリティーは下げられてしまっていました。

でもその状態が積み重なって、多様に入り組んだ部分が影響し合い、リリースに時間が掛かるようになってしまったんです。

そこで経営層に、「負債の返済」という表現は避け「基盤強化するために基盤を強化しているわけじゃなくて、機能のデリバリーのスピードを速めてビジネスに貢献するためにやろうとしている」という趣旨の説明をし理解を得て、何とか始まった状態です。

藤本：それこそ若狭さんの前職、前々職のGoogleもLINEも、巨大な一つのプロダクトを大人数で作っているじゃないですか。そこで積んだ経験は、そのまま生かせそうですよね。

若狭：ええ。ただ、技術基盤の強化に本気で取り組む場合は、テクニックとかノウハウを知っていることよりも、「覚悟」が何より大切だと思うんですよ。

例えばGoogleには、特定のモジュールをずっと書き換えているエンジニアがたくさんいるんです。「サーチのこの部分を完全に置き換えました」とか、あとは「データベースの基盤にSpannerを導入しました」とか、そういうことに数十人規模で取り組んでいる。

ユーザーから見ると何も変わってないけど、内側ではものすごくシステムが最適化され開発コストが削減されているわけです。

これはやっぱり投資判断の問題で、「ここを置き換えるのが正しいからやるんだ！」という精神論だけではなかなか解決しない。

で、そこに覚悟を持って人とお金をたっぷり投資できるのが、いわゆる「ビッグ・テック」なのかなと。メルカリもそうやって「世界基準のテックカンパニー」になることを目指していきたいんですよ。

藤本：なるほど。メルカリがそういう姿勢であり続けたらめっちゃカッコいいですよね。そういう意味では、プロダクトが大きければ大きいほどリターンが得やすいだろうし。

若狭：そのためには、投資のリターンも見える化はしていきたいですよね。やっぱり基盤の投資効果って分かりにくいですから。でも、GoogleやAmazonのような会社はそこを見てるんだと思います。

若狭：スマホのOSを気にしているユーザーは少ないと思いますが、例えばiOSそのものを作っている人って、基盤を作っているわけじゃないですか。それがなければいろんなアプリは動かないし、社会は成り立たない。だから彼らはそこに誇りを持っているんだと思うんですよね。

藤本：僕はゼロから何かを作るより、既にあるものを上手に良くしていくっていう方が単純に難しいと思うんですよ。「より難しい問題を解けた方がうれしくない？」っていうのは、個人的には感じますね。

ちょっとしたアプリを作るって話なら究極一人でもできるけど、10年動いているソフトウエアをさらに10年動かすためにはどうしたらいいかを考えるのって、エンジニアとしては大事なことだし、すごく難しいことだと思う。

若狭：それこそ、本当のエンジニアリングですよね。

藤本：それに、最近はそういう「みんなで協力して大きなものを作る」ことの重要度が増しているように感じます。

というのも、ソフトウエア業界も成熟してきて、20年前みたいに一人でなんでも作れるやんちゃなエンジニアが価値を発揮できる場所は減ってきていると思うんですよ。

若狭：分かります。一人がワンアイデアで市場を席巻できる時代ではもうないんですよね。

藤本：いろいろなプロダクトが世に溢れている中で、作るべきプロダクトの規模はどんどん大きくなるし、求められるクオリティーも高くなっていますからね。

しんどいこともそれなりにあるとは思いますが、スケールが大きくて複雑な課題に取り組めるのは、大企業ならではですね。

若狭：特に「ビッグ・テック」と呼ばれるほどの企業になると、一見お金にならない複雑な課題や技術にも大胆な投資ができる。なぜなら、それができるぐらい本業で稼いでるから。Amazonだって、もともとは大きなビジネスにしようと思ってAWSを始めたわけではないと思いますしね。

そしてメルカリは今まさにそのフェーズに向かうための投資をし始めている段階。今後は組織規模をさらに拡大していきながら、これまでにないチャレンジをしていけたらと思っています。

取材・文／石川香苗子　撮影／赤松洋太　編集／河西ことみ（編集部）