タイトルにした「開発情報を共有しない」というのは、情報を隠蔽しているということではない。もちろん、意地悪でそうしているわけでもない。

現在、メルカリから同社の100％子会社ソウゾウに出向し、地域コミュニティアプリ『メルカリ アッテ』の開発マネジャーを務めている鶴岡達也氏は、「メルカリの開発情報がソウゾウに共有されることはあっても、その逆はあえてしていない。史上最強の社内ベンチャーを目指すためにやっている試行錯誤の一つだ」と理由を明かす。

2013年2月に創業、同年7月に最初のサービスとなるフリマアプリ『メルカリ』をリリースした親会社のメルカリは、約3年で売上高を42億円超に（同社の第3期決算公告より）、資金調達額では計126億円と過去に例を見ないペースで急成長してきた。

その成長過程で彼らが得てきた知見も、当然前例のないもの。子会社となるソウゾウが『メルカリ アッテ』を開発・運用していく上で、そのノウハウやリソースを活かさない手はないように思える。

実際、『メルカリ アッテ』のようなクラシファイド・サービス（ユーザーのいる地域や目的ごとに分類されたさまざまな募集広告を一覧掲載するサービス）で懸念される出会い系まがいの悪用に対しては、100名以上の体制を築いているメルカリのカスタマーサポートチームが分担して監視・対応しているそうだ（参照記事）。

しかし、冒頭で述べたような情報共有の非対称さのみならず、こういったリソースの共有についても、「今は必要最小限にとどめている」と鶴岡氏。

現在約20名ほどいる人員に関しても、同氏や『メルカリ アッテ』プロデューサーの田辺めぐみさんなどメルカリからソウゾウに出向してきた社員はほんの数名だ。メンバーはほとんど中途採用やインターン学生で賄っている。

なぜ、「史上最強の社内ベンチャー」を目指す上で、このような自前主義を貫いているのか。その試行錯誤の理由を紐解いていくと、多くの社内ベンチャーや新規事業が頓挫してしまう原因が浮かび上がった。

ゼロイチができるチームを作るために重視した2つの条件

「新規事業を手掛けるチームで一番大事なのは、仕組みが整っていない状態でも自分でマイルストーンを置いて動ける人の存在だと思います」（田辺さん）

ソウゾウからメルカリへ開発情報の共有を義務化していない理由の一つは、まさにここにある。情報共有をすることで出てくるであろうメルカリ側からの意見やアドバイスが、『メルカリ アッテ』の開発スピードを遅くするなどの弊害も考えられるからだ。

その逆に、成長軌道に乗るメルカリ側の経験知やリソースに、ソウゾウのチームメンバーが過度に頼ってしまうこともあり得るだろう。「親会社とのシナジー」と書けば聞こえは良いが、それがある種の甘えにつながることも考えられる。

こうしたリスクを断ち切り、新規サービスである『メルカリ アッテ』をゼロから育てていくためにも、ソウゾウは情報共有の仕方をはじめチームづくりのやり方に細心の注意を払ってきた。

（※ちなみに情報共有の良しあしについては、近年の新規事業の成功例と言えるLINEの元CEOで、現C Channel代表の森川亮氏も以下の記事で似たような指摘をしている）

>> 社内の「情報共有」が、仕事をダメにする!? – ダイヤモンド社書籍オンライン

その試行錯誤の中で重視しているキーワードは、鶴岡氏によると主に2つある。

【1】スピード重視でトライ＆エラーを繰り返すこと
【2】メルカリではできない技術的挑戦を行うこと

だ。【1】のスピード重視のトライ＆エラーについては、気持ちだけでなく仕組みづくりが肝心だと鶴岡氏は続ける。

「サービスの初期段階では、いろんなことを試しながら『メルカリ アッテ』なりの成功法則を見つけるしかない。リーン・スタートアップで重要と言われるMVP（Minimum Viable Product）でプロダクトを磨き込み、検証を繰り返すしか道はないと思うんですね」（鶴岡氏）

そのためにも、現在の『メルカリ アッテ』では、ソウゾウ代表の松本龍祐氏が承認すればすべての決裁が降りるようにしているそう。加えて、松本氏や開発リーダーの鶴岡氏、プロデューサーの田辺さんらがトップダウンで物事を決めるのではなく、チーム全員が企画や仕様決めに携わるような雰囲気づくりを重視しているという。

「仕様決めはプロデューサーだけに任せずエンジニアも一緒になって行い、逆にプロデューサーである私も直接SQLを触ってログの収集・分析をしたり。デザイナーでも企画段階から入るようにしていたり。良い意味で『役職』と『分担』が一致していない状態を作るようにしています」（田辺さん）

また、日常的にこういった状況を作り出すために、ソウゾウ社内の情報共有ではSlackのほか、チケット管理ツールの『Backlog』やプロジェクト管理ツールの『Asana』などを駆使して全員が横断的に開発進ちょくを把握できるように工夫している。

メルカリがLAMP環境なのに対し、ソウゾウがGo&Swiftを採用した理由

2016年2月に中途入社してきたiOSエンジニアの石川洋資氏は、こういった環境面に惹かれて入社を決めた1人だ。

「前職では非常に大規模なサービスを開発していたので、エンジニアは仕様書ありきで開発をせざるを得ない面がありました。でも、個人的にエンジニアはコードを書くこと以外の仕事にも顔を突っ込むべきだと考えていたので、ソウゾウのような意思決定のスタイルで仕事をするのはとても面白そうだと感じました」（石川氏）

そしてもう一つ、石川氏を惹き付けたのは、【2】の技術的挑戦を重視する風土だ。

メルカリは、創業後いち早く商売として立ち上げねばならないという事情もあってLAMP環境をベースに“枯れた技術”を選択してきたが（参照記事）、ソウゾウでは一転GolangとGoogle App Engine、SwiftとRxSwiftを採用している（詳しい開発環境情報は以下参照）。

>> アッテの開発技術をお伝えする atte FeS【Go・Swift開発編】を開催しました – Mercari Engineering Blog

SwiftやRxSwiftに関するGitリポジトリを自作するなど、これまで積極的に情報発信をしてきた石川氏にとっては、新規事業開発ならではのスピード感を体験しながら業務でSwiftを使える場として、ソウゾウはぴったりだった。

「ソウゾウが比較的新しい技術を使った開発に乗り出した理由の一つには、石川のように技術的挑戦が好きでプロダクト思考のエンジニアを採用したいという狙いもありました。幸いなことに、親会社のあるソウゾウは、初期のメルカリとは違ってすぐにマネタイズしないと生きていけないという状態ではありません。ですから、3～4年後に主流になっているかもしれない技術を先取りするようなチャレンジもできるんです」（鶴岡氏）

この判断は、親会社のメルカリとは異なる強みを持つチームを持っておくことで、グループ全体の多様性につながるという点でもメリットがあるはずだと鶴岡氏は付け加える。

「LAMP環境での開発に比べて、GolangやSwiftを軸にした開発では中途採用で即戦力になり得る方の総数は減ります。ただ、僕自身Golangの初心者だったのに2カ月くらい学習して使えるようになったので、何かしらの開発言語をマスターしているエンジニアであれば対応できるはず。ですから採用時のデメリットより、質の高いエンジニアを獲得できるかもしれないというメリットの方が上だと判断しました」（鶴岡氏）

一般的なスタートアップなら二の足を踏んでしまうような新しい挑戦もできるという点は、（好調を維持する）親会社を持つ子会社ならではの特権かもしれない。

最後に、メルカリのようなメガヒットサービスの「次」を担うサービスづくりはプレッシャーにならないのか？と尋ねると、鶴岡氏は「それ以上にこの環境で新規サービスを作れるのが楽しいし、むしろメルカリ側に申し訳ないくらいだ」と返答した。

海外に目を向ければ『Craigslist（クレイグズリスト）』のように世界規模で展開するクラシファイドサービスが存在しているものの、日本で『メルカリ アッテ』のようなサービスが一大マーケットに成長する保証はまだない。

マーケットそのものの開拓し、ユーザーリテラシーの向上を含めて時間を掛けてサービスを育てていく必要があるジャンルを手掛ける場合、ソウゾウの採っている社内ベンチャー的なアプローチは悪くない選択肢だろう。

その過程で、ソウゾウ自身が理想とするようなチームづくりが堅調に進むかどうか。『メルカリ アッテ』の成功は、「ヒト・モノ・カネ」でいうところの「ヒト」集めにかかっている。

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