「なぜ、ソウゾウへの異動を希望したの？」
「ソウゾウ“らしい”と感じるところは？」

2021年1月に産声をあげ、同年7月には「メルカリShops」をプレオープン（試験提供開始）したソウゾウ。そこには、メルカリ・メルペイから異動したメンバーも多く所属しています。

今回のメルカンでは、ともにメルペイからソウゾウへ異動したプロダクトマネージャーの田中俊貴（@toshiki）とエンジニアの田中宏明（@napoli）が登場。同じメルカリグループで働いていたからこそわかる「ソウゾウの独特さ」をインタビューしました。聞き手は、ソウゾウ採用担当の増田 悠（@massuu）です。

インタビューから見えてきたのは、ソウゾウをお客さまファーストに突き動かす“ある善意”──。

※撮影時のみマスクを外しています

「ソウゾウ設立からもう8ヶ月経つのか…」

@massuu：まず、@toshikiさんと@napoliさんがソウゾウへの異動を希望した理由を知りたいです。@toshikiさんは、当初はメルペイだったんですよね？

@toshiki：私は2019年11月にメルペイへ入社しました。前職ではおもに銀行の基幹系システム開発を担当していました。なので、メルペイ入社をきっかけに、WEB業界へ入った感じです。メルペイではKYCやAMLなど、どちらかというと守りの領域をプロダクトマネージャー（PM）として担当していました。そして2021年1月にソウゾウへ異動したんです。

田中俊貴（@toshiki）

@massuu：異動のきっかけは何だったんですか？

@toshiki：2020年11〜12月に育休をとっていました。復帰するときに「どうしますか？」と話し合っているなかでソウゾウへ異動できるチャンスがありまして、@unryu-inさん（メルカリShopsのプロダクトオーナー）と一緒に働けるってところも大きなポイントとなって、それならばぜひチャレンジしてみたいということでジョインしました。そうか、もう8ヶ月ほど経つんですね…。2〜3ヶ月くらい前の感覚でした（笑）。

@massuu：しっかり8ヶ月ほど経っています（笑）。そして、@napoliさんは？

@napoli：僕は2017年3月に初代ソウゾウへ入社。そのときから、現在のソウゾウ代表である@mazeさん（ソウゾウ代表取締役CEO、石川佑樹） と一緒に働いていました。初代ソウゾウの解散後は2代目ソウゾウを経て、メルペイへ異動。@mazeさんとはプライベートでもよく話したりしていて、そのなかで「一緒にやりませんか？」と声をかけてもらったんです。そのときは何をやるのかも決まっていない状態だったんですが「@mazeさんと一緒なら絶対におもしろいはず」と思ったんですよね。ちなみに、歴代ソウゾウはすべてコンプリートしたことになります！

田中宏明（@napoli）

@massuu：すごい！前提として、ソウゾウは「メルカリグループの次の柱となる事業」として誕生したグループ会社でもあります。@napoliさんは新規事業が好きだったとかですか？

@napoli：僕は起業経験もあります。なので、昔から「わちゃわちゃした感じ」が好きだったんです。それを味わいたくて、ソウゾウを選んでいるところはあるかもしれません。

メルカリとのシステムを「あえて」切り分けた理由

@massuu：現在、ソウゾウは「メルカリShops」を展開しています。このサービス開発の特徴はどんなところにあるんですか？

@toshiki：ソウゾウにはプロダクト開発チームAとBがあります。チームAはBuyer（買い手）向け、チームBはSeller（売り手）向けのUXや開発をそれぞれ担当しています。私と@napoliさんはチームBとして、Seller向けの機能開発を担当しているんです。

@napoli：今我々がつくっているメルカリShopsは、いわゆるメルカリグループが使うシステムの外側にあります。お客さまから見るとメルカリの一部機能に見えますが、システムは切り離されているイメージです。

メルカリグループでは、マイクロサービスという開発手法を取り入れています。この手法は一つひとつの機能を独立させられる利点がありつつ、分散してしまうために管理が難しいところもありました。そこで、ソウゾウでは「モノレポ」という管理方法を取り入れ、1つのソースコードにメルカリShopsで使うリポジトリを全部管理できるスタイルにしました。そのため、現在はモノレポとマイクロサービスの両方を扱っています。

@massuu：最初からシステムを切り離したのは、今後もスケールしていくことを考えてですか？

@napoli：そうです。ここは意見が分かれるところですが、個人的には切り離したほうがやんちゃができるかなぁと思っていたりします。メルカリ内のシステムを使うと、メルカリShopsに万が一のことが起こったときに全体へ影響を及ぼしてしまいます。でも、僕らはメルカリ以上のスピードで開発したかった。だから、メルカリShopsに何かあってもメルカリは安全、という状況にしたんです。システムの切り出しは、けっこう強く主張しましたね。

@massuu：では、同じシステムで開発したほうがいいという意見もあったんですね？

増田 悠（@massuu）

@napoli：ありました。そちらのほうが連携もスムーズですしね。もちろん一長一短なのでどちらにもそれなりの難しさはあります。最終的には、ソウゾウはよりGo Boldに、そしてMove Fastにサービスを拡大させていくために切り出す決断になったんです。

@toshiki：ソウゾウは新しいサービスをつくっているのですが、お客さまからすると「メルカリでのサービス体験」なんですよね。スタートアップ的に開発・改善するなかで「まずは出してみよう」と出したものが、メルカリの評判を毀損してしまう可能性だってある。早くつくって出したい気持ちと、メルカリ内でサービス展開することでの「守り」のバランスを保つところはソウゾウならではの難しさですね。同時に、工夫しがいのあるところだと思っています。

メルカリShopsを「お客さまファースト」に動かす、善意のエピック

@napoli：ソウゾウでの開発でもうちょっと特徴をあげると「おさわりかい」「善意のエピック」あたりですかね。

@massuu：どちらも印象強いワードですね。

@toshiki：おさわりかいとはその名のとおり、チームのみんなで機能を触ってみて「こうしたほうがいい」「この動きがないとまずいね」など話し合う会です。Bチームの場合、そこで出たアイデアをPMの私がとりまとめて優先度をつけて改善していく流れです。

@massuu：ちなみに、おさわりかいで出たフィードバックをどんな気持ちで受け取っているんですか？

@toshiki：ほかのPMはわかりませんが、私は毎回けっこう凹んでいますね！

（一同笑）

@toshiki：メルカリShopsは短期で開発を進めてきたこともあり、優先順位的に諦めていた部分もあったんです。削れるところは削って仕上げてきたところはあったので…そこを指摘されると言い訳しちゃうんですけれど（笑）。でも、冷静に考えればどれも当たり前の指摘なんですよね。結果的におさわりかいで出てくるのは、事業目標以前のレベルで「つくっている側がダサいと感じるサービスを出すわけにはいかない」の観点が多い。優先順位では確かに上位じゃない、さらにいうと見方によっては「やらなくていいもの」かもしれない。でも、「四の五の言わずにこれはやるべきなんや！」という気持ちで改善を進めていました。

@napoli：そうとは気づかず、ばんばんと言ってしまってごめんなさい！

@toshiki：いやいやいや（笑）。むしろありがたいので、引き続きばんばんと言ってほしいです。落ち込みますしダメな仕事をした気持ちになるけど、おかげで見違えるくらいにぐっと良くなるのがわかるので！

@massuu：そして「善意のエピック」とは？

@napoli：善意のエピックとは、優先順位に関わらず「お客さまにとって必要だと思ったこと」にとりかかる動きを指しています。ちなみに、命名したのはプロダクトオーナーである@unryu-inさん。

@toshikiさんの話のなかで「優先度をつけて開発している」とありました。それももちろん大事なのですが、一方で「お客さま目線で見たときにやったほうがいいこと」が漏れてしまうことがあるんです。そういった「漏れてしまったけれどお客さまにとって大事なこと」を善意のエピックとして拾い、対応しています。

@massuu：善意のエピックは、自然発生的なものだったんですか？

@toshiki：うーん、どうだったんだろう…。ただ、メンバーの間では「優先順位は低いけどやったほうがいい」「のちのちブロッカーになる可能性があるものをどうしよう」と感じるものはあったはずなんですよね。それを相互で話していると、善意のエピックという認識が出てきたと言いますか（笑）。

@napoli：これがあるおかげでメンバーのモチベーションは保てていると思うんです。どうしても「やらなければならないこと」だけでは心が疲弊してしまいます。忙しくても「これをやれば確実に喜んでもらえる」と思えるものは別腹。むしろやる気が出る（笑）。そして善意のエピックという言葉があることで、みんなが「優先順位は低いけどやりたい」と言い出しやすい環境になっています。

我々の仕事はコードを書くことではなく、ちゃんとしたサービスをつくること

@massuu：「おさわりかい」「善意のエピック」など、現場メンバーが自ら声をあげやすいポイントがあるのはいいですね。

@toshiki：ですね。PMとエンジニアって、ともすれば「発注者と受注者」みたいな関係性になってしまうこともあると思います。そうすると「ただ言った通り・言われた通りにつくる」だけの関係性になってしまい、より良いプロダクトにするための建設的なコミュニケーションが発生しづらくもなり得る。ソウゾウに関しては、おさわりかいや善意のエピックのエピソードがあるように、仕様をアウトプットする前後に関わらず「こうしたほうがいい・すべき」とフィードバックがばんばん飛び交うんです。それこそPM・エンジニアに留まらず、LegalやBizDevなども含めたあらゆる職種からも容赦なく。このあたり、すごく健全にプロダクトを開発・改善している感じがありますね。なかには鋭いフィードバックもあるので凹むこともあるわけなんですが、めちゃくちゃありがたいと感じています。

@napoli：みんな、自分の愛情を込めているようなところがありますよね。それはお客さまへ絶対に伝わります。逆に、愛情がないこともわかってしまう。それに、PMとエンジニアが「発注者と受注者」の関係性になってしまっては、熱量高いコミュニケーションができなくなります。

@suguruさん（ソウゾウCTO、名村卓）自身も、そういった考えなんです。ある日、週次定例で「僕らの仕事はコードを書くことではなく、ちゃんとしたサービスをつくること」「その気持ちがないと、仕事をしているうちに入らない」と言っていました。もう、本当にそのとおりだなと思っていて。「自分なら、どうすればサービスを良くできるか」と考えることをやめたら、仕事を放棄したことにつながると思っちゃうんですよね。

@toshiki：@unryu-inさんも、そういうところを大切にしたいと強く意識してくれています。だから、我々PMもやりやすい。善意のエピックなどには、ともすれば優先順位をとにかく下げ続けざるをえないものもある。それを、バランス良く取りかかれる環境があるのはいいなと日々感じています。

@massuu：メルカリShopsはお客さまのためのサービスだから、そのためにコードを書いている。

@napoli：そうです。僕らはお客さまが使うサービスをより良くするために仕事をしています。その気持ちは、忘れたくないですね。