2021年11月11日に、プロダクト開発体制を一挙公開〜メルカリ・エンジニア組織の大解剖〜 というイベントを開催しました。 この記事はその中で行われたパネルディスカッション「メルカリプロダクト開発体制本音トーク」の書き起こしです。
詳しくはYouTube上にある配信アーカイブをご視聴下さい。
当日行われたその他セッションの書き起こしは以下でご覧いただけます。
- 【書き起こし】プロダクト開発体制を一挙公開 – メルカリのプロダクト開発体制
- 【書き起こし】プロダクト開発体制を一挙公開 – 全員ソフトウェアエンジニアとは？
- 【書き起こし】プロダクト開発体制を一挙公開 – Cross-functional team in Mercari
イントロダクション
メルカリプロダクト開発体制本音トークということでパネルディスカッションを行っていきたいと思います。
モデレーター並びにパネリストはこの4名となります。
- モデレーター
- @braitom (Engineering Office)
- パネリスト
- @kwakasa (CTO)
- @mmiy (Head of Products Foundation)
- @vkgtaro (Camp1 Eng Head)
参加者の皆様から事前にいただいた質問をベースにいくつかテーマを設けてディスカッションしていければと思います。よろしくお願いします。
メルカリのプロダクト開発体制の実態
– メルカリのプロダクト開発組織にはプロダクトマネージャー(以下PM)、テクニカルプロダクトマネージャー(TPM)、エンジニアリングマネージャー(以下EM)、エンジニアと様々なロールがあると思いますが、その役割分担はどのようになっていますか？
@mmiy:
役割分担ですが、それほど特別なものではなく、世の中でいう教科書的な形になっているかと思います。
PMとTPMは担当する領域がよりエンジニアリング知識が必要かどうかの違いだけでどちらもお客さまの課題を発見するのが一番大事で、それに対してどういうソリューションを探し出せるかが大きな役割になっていると思います。この探す段階でデザイナーやEMと一緒にコラボレーションがはじまって、その後エンジニアに作ってもらって、一緒にテストしてリリースする形になっています。Campによって取り組み方は違うと思いますが、PMが全部内容を決めてエンジニアに「後はよろしく」ということはありません。PMとCamp内のScrumチームとで協力してソリューションを考えて、作り上げる形になります。
@vkgtaro:
Camp1は特にVOC（Voice of Customerの略。お客さまの声）を吸い上げて課題発見するので、PMはもちろんエンジニアも課題を見つけています。ただ、どう対応すれば良いかは分からない場合もあるので、PMに手伝ってもらったりとお互いに協力しながら進めています。
@mmiy:
あとはPMやエンジニアだけでなく、BIやデータアナリスト含めて数字を見ています。検証して、やはりそうだったという確認をしたり。先ほど@vkgtaroのスライドにあった、中心にプロダクトがあって周りにメンバーがいる形になっていると感じますね。
@kwakasa:
PMはWhat（何を作るのか）とWhy（なぜ作るのか）、ソフトウェアエンジニアはHow（どうやって作るのか）とWhen（いつまでに作る）が役割分担というのが基本かと思います。ただソフトウェアエンジニアがWhatとWhyに意見を言ったり、一緒に考えるのを推奨していますし、PMがHowやWhenについて一緒に考えるのもクロスファンクショナルだと思います。
– ありがとうございます。1つ質問が来ているので取り上げます。Camp内の横断的な課題の発見と解決は、誰が具体的に取り組んでいるのでしょうか？
@kwakasa:
一言で言えば「みんな」なのですが、先ほど言ったPMとソフトウェアエンジニアの役割分担はあります。ただ、あなたは課題を発見する人、あなたは課題を解決する人みたいに明確に決めることはあえてしないようにしています。
@mmiy:
先ほどの私のセッションでCampの中にはScrumチームが複数あるとお伝えしたのですが、それぞれの課題発見について自分のところしか見ていない訳ではありません。自分の領域だけを見るのではなくCamp内全体を幅広く見る人が多いので、課題を発見したらそれが自分のチーム外だったというケースは良くあります。
そうした時に、では一緒にやりましょうとか、あるチームがリードして他のチームと協力し合いながら進めることも自発的に起きています。これはメルカリのカルチャーであるAll for Oneが活きている部分だと思うので、あえて役割分担を決めないことが強みになっているのかと思います。
@vkgtaro:
先ほど私のセッションでも説明したCamp1のBackend Guildについてもそうですね。最初は1人のバックエンドエンジニアが声をあげて、Camp内のバックエンド開発に関わるエンジニアを集めてアイディアソンを実施して、ギルドを作ろうという流れになりました。やはり課題発見する人は、そこにいる人や関わっている人だなと思います。
企画、要件定義への関わり
– メルカリではエンジニアはプロダクトの企画や要件定義にどれくらい関われるのでしょうか？
@mmiy:
関われるタイミングとして一番大きいのはAnnual Plan(年間計画)を策定するタイミングになると思います。各CampでAnnual Planを立てる際にはみんなでディスカッションしながら、これをやった方が良いとか、これを目指すべきだとか意見を出し合います。それはPMだけでなく、エンジニアやデザイナーも加わって行うので、これが1つのインプットタイミングです。
ただ、このAnnual Planはふんわりとした、柔らかいものです。こんなことをやろうね、くらいのものです。そして具体化するところでは様々な提案ができます。PMは課題は分かっていますが、そこに対して具体的なやり方はソフトウェアエンジニアの方が知っていますし、アイディアが採用されるケースは多いと思います。
あとはAnnual Planとは別で緊急対応すべき案件も来ます。当然、Annual Planで考えていたこと全てが必ずできる訳ではありません。バックログとも比較して優先順位を決めて、取り組む順番を決めるケースは多いです。
@kwakasa:
どれくらい関われるかというご質問なので、関わりたいという意思がある方からの質問だと思います。今日は赤裸々に語って良いということだったので言ってしまうと、マネジメントの課題感として、関わりたいと思って欲しいんですよね。
エンジニアの中には言われたことをやります、言われるまで待ちますと言った受け身のマインドセットの方も中にいます。みんながみんな、関わりたいと思っている訳ではないかもしれません。僕の課題意識としては、もっとみんなに関わって欲しい、関わってくれれば助かりますと考えています。もっとプロダクトやお客さま、サービス自体に興味を持つよう意識付けをしていこうとしています。
– ビジネスサイドとプロダクトサイドの対立はあったりしますか？
@kwakasa:
正直ないということはないですよね。僕はコミュニケーションの問題だと思っています。エンジニアの立場で言うと、プロダクトオーナー（以下PO）が要件が固まりきっていない、ふんわりとした状態で話を持ってくることがあります。そこで、エンジニアが一緒に考えましょうと話に入れば、自然と協力体制ができると思います。逆に、そんな状態では協力できないので、もっと要件を固めてから来てくださいと言ってしまうと、POは一生懸命考えて、さらにスケジュールまで決めてから持ってくるでしょう。そうなってから蓋を開けてみると、そんなスケジュールでは無理ですといった具合で対立が発生したりします。
こういう対立関係はお互い反省すべき点があると思うので、早い段階でコミュニケーションを拒絶しないように行っていくのが大事だと思っています。
@vkgtaro:
生々しい話でしたね。
@mmiy:
昔はプロダクトとエンジニアの対立が多かったのですが、最近ではプロダクトとエンジニアは距離感が近くなったので、これとは別にビジネスとプロダクト、ビジネスとエンジニアというコンフリクトが多くなってきているように感じます。
あとはグループ企業があって、それぞれ事業計画が異なるために優先順位がずれることもあります。メルカリの場合はプロダクトとエンジニアリングサイド、どちらか一方が作り出していくカルチャーではないので、たまにハードなネゴシエーションも発生しているようです。その中でも落とし所を見つけて、次は改善しようとする試みも見かけるようになりました。
@vkgtaro:
この2年くらいはビジネスサイドとエンジニアリングサイドの間で揉まれていたのですが、コミュニケーションの問題は大きかったですね。ビジネスサイドで決まった話が伝言ゲームで伝わってきたりするのは良くないケースです。今はPMとエンジニアは一緒に働いていますし、エンジニアの中でもビジネスに関わってくれるケースも増えてきていて、お互いに積極的に意見交換することで改善されています。メルカリには他社との協業を進めるBizDevがありますが、そこにも可能であればもっとエンジニアが関わっていくべきでしょうね。
組織編成の考え方
– Camp構成の考え方、ドメインの分け方、構成人数などはどう考えていますか？
@mmiy:
まず考えとして、我々のプロダクトやサービスをどう構成しますか、どう分けますかというのが一番最初のポイントになります。さまざまな分け方を過去に試しています。例えばお客さまの体験で分ける場合は出品するお客さま、購入するお客さま、そして売買に伴うトランザクションなどになりますが、それぞれの重さを考えて何人ずつ配置しましょうと考えます。そして出品に対する現状の課題を洗い出して、その課題に見合ったチーム構成にしましょうという考え方です。
つまり、サービスをどのように分けるかを最初に考え、次にその中の課題ごとのボリュームに合わせて人数構成を考えるということで。
これは@kwakasaの話にもあった通り、サイロ化しないように注意が必要です。このチーム構成自体はたまに変えてみることはありますが、少なくとも半年から1年くらいは同じドメインチームで取り組んでいます。ただ、これも理想論な部分はあって、現実問題としてエンジニアにはMLが得意な人、バックエンドが得意な人などがいて、思った通りにチーム構成ができないこともあります。
@kwakasa:
スタートアップで小さなプロダクトであれば、全員で何でもやっていくので、組織構成を考えなくとも大丈夫かと思います。そんな中で機能が増えてくると、まず機能で分けるって発想になるのかなと。メルカリで言うと出品とか、購入、トランザクション、アイテム詳細、マイページなどです。最近ではどちらかというと体験で切る形になっているかと思います。ただ、これも絶対的な正解はなくて、機能や体験のフロー、提供する価値で切るとか色々な方法を繰り返し試していくのかなと思っています。
– D&Iはいかがでしょうか？
@mmiy:
外国籍エンジニアも増えてきていますので、ナショナリティーという視点ではすでに十分にダイバーシティがあるので、この点ではD&Iを考えることは減ってきています。最近では、逆に日本人のことを考えなければいけないケースが出てきています。特に他の部署では英語を使っていないケースもあるので、そことのコミュニケーションをどう解決するか考えることが多くなっています。
– 開発組織のスケールについての注意点はありますか？
@mmiy:
プロダクトが小さいと、人を増やしても意味がありません。プロダクトのサイズと組織のスケールにはある程度相関性がありますので、組織だけをスケールさせるということはないです。プロダクトやサービスが大きくなっていくとか、サポートが増えていく中で組織をスケールさせるという点があります。
例えば我々が導入しているCampシステムですが、これは何か新しいものが増えたときにCampを1個作るみたいなイメージでスケールさせられるように設計しています。今のCampシステムは将来的なスケールであったり自律的に動けることも期待しています。組織をスケールさせるのと、プロダクトやサービスが増えていくのを両輪として行っていく予定です。
@kwakasa:
CampシステムがメルカリJPの基本単位ですが、それと平行する形でレポートラインがあります。いわゆるエンジニアリングマネージャーであったり、ディレクターといったレポートラインもスケールを考えないといけません。今一番課題に感じているのは、エンジニアリングマネージャーの負荷が高いことです。ここでいう負荷というのは技術的な問題はもちろんですが、コミュニケーションや人間関係も含まれています。このレポートラインのスケールも考えないといけません。
メルカリの開発体制の良いところ、改善したいところ
– 皆さんそれぞれからメルカリの開発体制の良いところ、改善したいところを教えて下さい
@mmiy:
私はPMとして開発体制を見ているのですが、良いところはオープンで、協力的なところですね。これはメルカリのカルチャー、ミッションやバリューに関係していると思います。何か提案をした時に、ちゃんと話を聞いてくれて、改善策やフィードバックをきちんと言ってくれるところが良いですね。
逆に改善したいところは、何でもオープンに話せるのでカオスになってしまうことがあるところでしょうか。個別に判断して進めてくれますが、広がりすぎてしまって収集つかなくなることもあります。ガバナンスではないですが、ある程度守るべきところも必要かなと。ただ、その上でも自由があるよねという環境を作っていけると、より働きやすくなるのでは思います。
@vkgtaro:
良いところはゴールに対して柔軟にチーム体制を変更して、向かっていけるマインドセットがあることですね。私が入社した頃は3ヶ月でチーム構成を変えていたのですが、今のように長く同じチームで仕事をして、ちょっと何か言うだけでも通じ合うような関係で仕事を進められるのも大事だと思っています。今のCampシステムはそれができるようになっているので良いなと。
逆に改善したいのは、長く継続しているチームは、そのチームを保つことに固執してしまう面があることでしょうか。エンジニアリングリソースを柔軟に調整できるのが良いところなのですが、そうなった際に、メンバーを手放したくない、引き続き一緒に仕事をしたいといったことが起きる場合があります。もう少し全体を見て仕事できると良いなと思っています。とは言え、Camp1では本当に柔軟にできています。
@kwakasa:
コミュニケーションがとても多いのが良いところだと思います。みんな何でも言って良いよという雰囲気があって、ここを変えた方が良いと思うといったコメントや改善案が随時寄せられています。心理的安全性はとても高いと思いますね。
建設的か否かに関わらずどんどん発言して、自分たちで自分たちのやり方を変えていくんだという意思を全員が持っているのだと感じます。
改善の余地があるとすれば、手段が目的化してしまうことがあるところでしょうか。ある技術を導入した際に、それを利用するのが目的になってしまうことがあります。でも技術は手段なので、我々のゴールを達成する上では別な手段もあるはずで、手段と目的を明確に分けて考えていけるように改善していきたいですね。
Q&A
– Q: 組織規模が大きくなるにつれて、マインドセットの浸透が重要になるかと思います。工夫されている取り組みがあれば教えてください
@kwakasa:
メルカリではインターナルコミュニケーションを重視しています。今、エンジニアもメルカリ内で数百人を超えるようになって、インターナルコミュニケーションがとても難しくなっています。みんなが互いを知っている組織であれば意識あわせをするのも簡単ですが、知らない人もいるし、どう同じ方向を向いてもらうかが課題です。今回のようなイベントもそうですし、色々な手法を駆使していますが、良い方法があったら逆に教わりたいですね。
@mmiy:
メルカリの場合、コミュニケーションのほぼ全てがSlackにて行われています。あとはAll Hands（部署全体で集まるミーティング）くらいです。そのためこの2つのコミュニケーション手段を駆使しながら浸透させようとしています。
あとは先にドキュメントにまとめることです。まずドキュメントにまとめて、Slackに投稿します。そしてさらにAll Handsで伝える。これを何回も何回も繰り返しています。
@kwakasa:
同じことを10回くらい言わないと伝わらないと感じますね。同じことを何度も言うのは、言っている側としては不安になってくるのですが…。同じことばっかり言っていると思われそうだなと。そういう考えは忘れて、同じことを何度も言うように心がけています。
@vkgtaro:
メルカリには社員同士の「共通の価値観」をまとめた社内向けのドキュメントCulture Docがあります。ここにはメルカリのメンバーとして、これを体現してくださいといった内容が書かれていて、何かあれば参照するようになっています。SlackでURLを共有したり、EMとの1on1の中で内容を確認したりしています。
– Q: Camp自体がScrumチームの単位にも見えますが、Campの下にあるScrumチームはどのような開発チームなのですか？
@mmiy:
Campによって若干の違いはあります。まずCampの中にあるScrumチームはいわゆるピザサイズ（5〜6人）、最大でも10名いかない程度で構成されています。それを複数束ねてCampになっているのですが、これはいわゆるLarge-Scale Scrum（以下LeSS）になります。
@vkgtaro:
Camp1はLeSSで行っています。Camp1で1つのバックログを持っていて、スプリントプランニングはCamp全体で行っています。そこから各チームがプロダクトバックログアイテムを持っていって、スプリントは各チームで走ります。そして成果物を各チームが持ち寄ってCamp単位でのスプリントレビューを行ってフィードバックを与え合う形になっています。
– Q: プロダクトロードマップで定められた中長期の機能開発と足元の課題解決はどのように優先順位を付け、どのようなリソース配分で対応していますか？
@mmiy:
これもCampによって異なります、が答えになります。ロードマップには、これはこのCampで対応するという内容があるので、各Campはその中長期のゴールに向かって自分たちでもタイムラインを引きながら対応しています。しかし、当然ながらセキュリティやプライバシー関連など、今すぐ対応しなければならないタスクも飛び込んできます。それもやはりScrumのリズムで、プロダクトバックログを見ながら対応しています。
なおAnnual Planやロードマップはあるのですが、これはコミットではありません。お客さまやパートナーとの協業であれば締め切りがあることもありますが、自分でここまでにやりますと定めたとしても、必ず達成しないと評価が下がるというものではありません。必要なタスクがあって正しくジャッジできていれば、その結果としてスケジュールがずれたとしてもネガティブに判断されることはありません。短期のタスクが入ってきたとしても、見直しサイクルがスプリントに入っていますので、その時の判断で優先順位を変えています。
– Q: 全員ソフトウェアエンジニアの考え方の背景として日本の雇用形態が関係していますか？
@kwakasa:
一言で言えば関係していません。恐らく日本でよく見られる雇用形態であるメンバーシップ型を想定されていると思うのですが、そこは特に考えていないです。
あくまでもエンジニアは課題解決する人であるという考え方をベースに、その手段を縛ったり、縛られた考え方をして欲しくないということです。なので無理矢理ジョブローテーションしたり、不得意なことをどんどんやってくださいって言う意味ではないです。
– 時間となりましたのでここで終了させていただきます。本日回答できなかった質問は後日ブログで公開させていただきます。ありがとうございました！
一同:
ありがとうございました！
当日お答えできなかったご質問への回答
質問への回答まとめはこちらで公開しています。
さいごに
メルカリではメンバーを募集中です。 少しでもご興味のある方は、ぜひともMercari Careersの募集要項をご覧下さい。
また、今後もエンジニアリング組織に関係するイベントを随時開催していきます。connpassでメルカリ/Mercariのグループメンバーになることで最新情報を受け取れます。
