2021年11月11日に、「プロダクト開発体制を一挙公開〜メルカリ・エンジニア組織の大解剖〜 」 というイベントを開催しました。
この記事では当日いただいた質問の中で時間の関係上お答えすることができなかったものに対して、登壇者のkwakasa、mmiy、vkgtaroからの回答を記載します。
なお、本イベントはYouTube上にある配信アーカイブ動画からご視聴いただけます。
質問への回答
メルカリのプロダクト開発体制
— Q: チームとしての学び、の具体的な例を教えていただきたいです！
チームで振り返り(Retrospective)を行い、そこで何が良かったのか、何か改善できるのかといったことを特定して、解決策を考えて取り組みます。これを繰り返し行うことでチームとしての学びを行っています。
あるチームでは、コードレビューのタイミングやサイズを定義して効率を上げたり、あるチームはテストのケース管理の方法を工夫したりなど、日々の開発の中でよりよくできることを行っています。
— Q: AgileのPracticeを具体的にどのように広げたか教えていただきたいです。
Agile(Scrum)を導入するために、ステージを定義し、それぞれのステージのなかにPracticeを定義しました。これにより何からスタートしたらよいのか、次に何をすればよいのかということが分かり、チームで徐々にPracticeを広げていくことができます。
さらに、Agile Coach、Scrum Masterにより各チームへのコーチングや実際にScrumをトライしてみるということを行ないました。これらにより徐々にPracticeを広げて、Scrumでの開発を展開しました。
— Q: AgileコーチとScrum Masterの人数比率と、CampごとにAgileのマインドをどのように整え広げているのか教えていただきたいです。
メルカリでは各チーム全員がScrumを理解することを期待しており、Certified Scrum Master(CSM), Certified Scrum Product Owner(CSPO)の取得を推奨しており、合計で50名程度がこれらの資格を取得しました。その人達が各Campやチーム内でScrum導入を推進していきました。
また、実際にAgile(Scrum)を展開するプログラムチームが用意したAgileコーチは最大で6名程度、Scrum Masterは数名です。その方達は主に各チームでScrum Masterを行う人のコーチングを行なったり、Scrum導入で問題に直面しているチームにサポートで入ったりしていました。
全員ソフトウェアエンジニアとは？
— Q: 外国籍エンジニアの積極採用は、よりレベルの高いエンジニアを集めるために母数を広げるためということでしょうか？
それも理由としてありますが、もっと重要なポイントとして、メルカリのミッション、 "新たな価値を生みだす世界的なマーケットプレイスを創る” を実現するためという観点があります。グローバルな視点でプロダクト開発を進めるための重要なステップの1つとして外国籍エンジニアを積極採用しています。
— Q: ソフトウェアエンジニアの評価はどのように取り組まれているのか気になります。 職制は限定しないが役割みたいな考え方で評価するのでしょうか？
もちろん専門領域の技術的貢献はメインになりますが、専門領域を超えた活躍については、お客さまへの価値提供や事業におけるポジティブな貢献も考慮しています。
また、エンジニアの成長段階ごとに期待される行動を明文化した、Engineering Ladderも利用しています。
— Q: サイロ化とのバランスの取り方で具体的に取り組んでいる事があれば知りたいです
Campの役割や責任範囲を明確にすることはアカウンタビリティの観点から大切です。しかし、縄張り意識に陥らないよう、あえてCampの役割と責任範囲を厳密に定義せず柔軟性を持たせています。また、状況に応じて躊躇せずCamp構成を見直しています。
Cross-functional team in Mercari
— Q: 開発と運用（障害発生時の原因追及、修正）をどのように両立させているか教えていただきたいです
まず初めに、メルカリでは新規開発と運用をチームで分けてはいません。そのため、障害が起きた際などにはその機能を担当したチームが率先して障害の対応を行うようにしています。
障害対応はまずは通常の状況に戻すまでの一次対応、その後、原因究明とともにポストモ
ーテムと呼ばれる障害報告書を記載の上、恒久対応を行います。
一次対応と原因究明に関しては Sprint を中断して行うことにはなりますが、それで現在の Sprint に遅れが生じて計画通りにいかないことは許容するしかないと考えています。
また、恒久対応に関しては何かアクションが必要であればタスクを Backlog に積んでもらい、その他のタスクと合わせ優先順位を決めた上で、通常の Sprint と一緒に対応するようにしています。
— Q: 手段の話は視座が関係している事が多い気がします。その人から見ると最善手なので提示しているが、受けとる側は一歩上の視点から見ているのでズレが生じるというのはありそうだと思いました。
ご指摘の通り、その人のポジションによって見えているものに違いはあると思います。
実際、 人によっては cross-functional teamであることが目的になっているケースもあり、 チーム内になぜこの専門の人がいないのか、という質問を受けることもあります。できる限り、メンバーへの説明、Whyの共有を行うようにはしています。
また類似の話としては、Scrumも手段であり、あまり「正しいScrum」を行うことに執着はして欲しくはないと考えています。やはりメルカリというプロダクトをお客さまへ提供することが共通の目的であり、 All for OneのOneとは何か、ということをメルカリのエンジニアには考えて欲しいと思っています。
パネルディスカッション & Q&A time
— Q: みなさん業務では英語で対話まで行わなければならないですか？
プロダクト開発チームとしてはかなりの会議が英語で行われるようになりました。よって対話も英語で行っています。 CS チームなど日本語をメインとしている部署と協力しているチームでは日本語がメインということもあります。
— Q: 海外のエンジニアが増えてきて、社内の変化を知りたいです。
目に見えて最も変わったのはやはり英語だと思います。非日本語話者が増えて、仕様の記載は英語が必須、日本語はオプションとなったことのほか、さまざまな全社向けメッセージが英語と日本語併記になりました。日常的な業務範囲だと Slack はほぼ英語です。
また、全体的にローコンテクストになってきていると感じていて、以前よりは前提や文脈についての説明が詳細になってきているように思います。
それから、「海外」と一言でいっても各々のバックグラウンドからくる考え方の違いがあり、「海外」のエンジニア同士でも時折発見があるようです。こういった違いをお互いに許容する上でお互いをリスペクトするようなコミュニケーションがあるように感じています。
— Q: 仕様策定する際にどのようにPO側と開発者側とで協力されてますでしょうか。プロダクトが大きくなると、一発で確定して、そのまま実装・リリースということは少ないかと思います。手戻りなく仕様を受ける開発者が拘っている（そもそも仕様の検討にも非協力）場合、メルカリさんではどのように対処されますでしょうか。
チームによるところが大きいですが、基本的には仕様策定の段階から、エンジニアも関わるように促進しています。 PO/PM が問題提起から仕様策定まで行うのを待つのではなく、その間も関わって、実際の開発の上でのブロッカーの共有や、他の良い実装方法の提案を行うことはエンジニアの仕事であると伝えています。
チームによっては、エンジニアがユーザインタビューへ参加しているケースも確認しています。ありがたいことに英語を話せるお客さまが英語でのユーザインタビューを受けてくれているケースもあります。
— Q: エンジニアとUXUIデザイナーは、普段どのように協業していますか？
現在、社内的にデザイナーの数が少ないため、各チームではなく各Campに数人という形で配置しています。日々の仕事の中ではチームの中にはいないものの、 Slack のデザイナーチャンネルに「この画面のこれはどういう意図か」といった質問をエンジニアから気軽に投げていたり、 Camp の EM、PM が集まって課題を共有しあう会議にデザイナーも参加して議論したりといった形で協業しています。
— Q: 一緒に働く中で、信頼できる・働きやすいPMは、どのような人か教えていただきたいです
リリースの後、お客さまの反応をまとめて共有してくれたり、関わっているプロジェクトの障害やお問い合わせについて真摯に対応できる方は信頼できると感じます。
また、プロジェクト進行に関して、周辺のステークホルダーとしっかりコンセンサスを取りながら、チームと並走してくれている方は働きやすいです。
— Q: 年間計画に対するCampでのディスカッションをまとめるのかなり難しいと思うのですが、取り入れいるMTG手法や図の表現方法などあれば教えていただきたいです。
年間計画は基本的に Google Docs に記載して共有しています。 Google Docs だと、該当箇所に対してコメントを載せることができるので、トピックごとの議論がしやすいです。
また、必要に応じて図が載せられることも多いですが、載せている図に関してはイメージ図であったり、グラフであったりとケースバイケースです。文字だけだと伝わりづらいことに関しては、特に図が使われていると思います。
— Q: リリースサイクルの短いAgile開発において、セキュリティはどのように担保しているのでしょうか？（専任のセキュリティチームがいる、自動化されたセキュリティテストツールを使っているなど）
専任のセキュリティチームはあります。最近だと、Security Champion という役割の方が各Campに1名いて、その人がセキュリティにまつわることをCamp内で促進しています。
また、仕様策定の段階でセキュリティチームにレビューをしてもらうようにしています。
ツールに関しては Whitesource などを採用しており、セキュリティチームが主にモニタリングを行っています。
— Q: エンジニアのキャリアパスとしてEM以外のロールはありますか？
キャリアパスという意味では「マネジメント」と「Individual contributor（スペシャリスト）」とで分かれています。
また、メルカリではロールはあくまで役割であり、キャリアパスはグレード定義を参照して話すことが多いです。会社のグレード制度と対応して作成された Engineering Ladder を用いて、エンジニアだとこのグレードの人はこのくらいの期待値があるという会話がなされています。
EM だからグレードが高いということはなく、実際にはロールを持たないエンジニアの方がグレードが高いといったケースもあります。
詳細についてはこちらの記事を読んでいただくと理解が深まると思います。
— Q: チームの責任範囲の間に落ちるようなタスクを拾う仕組みやチームは存在しますか? エンジニア個人の振る舞いに依存していますか?
エンジニア個人の振る舞いに依存しているといえばそうですが、 Engineering Ladder での定義で、グレードが上がるごとにチーム間やCamp間など、サポート範囲が広がっていくような項目があります。そのため、評価対象になっているという意味で仕組みはあります。
また、今回のイベントで紹介させてもらいましたが、 Backend Guild のようなチーム横断的な取り組みもこういったタスクを拾い上げる仕組み化の一種です。
ただ、全てのケースに対してのフォローはできておらず、ある程度は前述の個人の振る舞いを評価などで強化していく必要があるとは思います。
— Q: ドメインの分け方はあくまでユーザー体験ベースなのでしょうか、見えない部分のドメイン分割などで困った体験があれば知りたいです。
Microservices のドメインやチームの責任境界は、当初機能ごとで切っていました。そのため現在のお客さま体験ベースや提供したい価値ベースの Camp systemとの相性があまり良くなく、今もチームやナレッジごとCamp間で移動が行われることがあります。
この辺りの議論になった時に議論がうまくまとまらないことも正直に言うとあったりするので、ドメインの分け方にはあまりこらない方が良さそうです。
— Q: 組織のスケールに付随しますが、ソフトウェアエンジニアの方が直接メルカリのサービスを一緒に考えたりすることはあるのでしょうか？ もしある場合、どのように巻き込んでいますか？
新規事業に関してはエンジニアも一緒にアイデアを考えることはあります。また、四半期の最後に次の四半期にやることをチームやCampで集まって Ideation しているケースもあります。
ただし、多くの人数での議論は結論が出なかったりするので、ある程度方向性をまとめた上でチームに分けて discussion したりなどの工夫もされています。
— Q: Camp体制で評価はスケールできるのでしょうか? 他職能のEMからの評価(Backend の EM が Androidエンジニアの評価など)にメンバーは納得するのでしょうか。技術に専門性が出てくるほど評価が難しくなるのかなと思いました。
メルカリでの評価は、各 EM が自分のメンバーの評価の記載はしますが、その後、キャリブレーションミーティングという、 EM 間でお互いの評価が妥当かどうかを議論するミーティングが開かれ、そこで、他の EM からのレビューを受けており、この辺りについてはうまく担保できていると思います。
ただ、確かにこの方式はスケールするかという観点では一定の限界はあると思うので、新たな取り組みを考える必要があるかもしれません。
また、お客さま体験を作ることに近いCampとは異なり、プラットフォーム寄りのCampやML のチームではより近い専門性を持つEM から評価されているようには思うので、Campによっても状況は異なっていると思います。
— Q: コミュニケーションは主に何で取ってますか？今、在宅が増えた中でどうしてるのか教えていただきたいです。
コミュニケーションは主にSlackでとっています。また、チケットや仕様はJira, Confluenceを利用、他にもGoogle Workspaceの各サービス、Figma、Miroなどのオンラインツールを利用してコミュニケーションのストレスを減らすようにしています。Google Meetでのオンラインミーティングも頻繁に行われています。
— Q: Foundationへの投資と事業計画に必要な施策の優先度付はどのように行っていますか?
どちらかを優先するために優先順位を付けるのではなく、どちらも重要なので、投資割合を調整するという考え方で進めています。特にFoundationへの投資は中長期的な継続性が求められるため、投資を極端に抑制したり停止することがないよう、計画遂行のためのメンバーが常にアサインされている状態を維持しています。
— Q: 組織を保つための時間は週や月でどの程度確保しているのでしょうか？
インターナルコミュニケーションのための時間についてのお尋ねだという前提で回答します。定量的な回答は難しいですが、Division全体に向けた粒度の大きなメッセージの発信、マネージャーやステークホルダー間の調整、1on1での粒度の小さい具体的なディスカッションなど含めると、エンジニアリング組織全体としては、惜しみなく、かなり多くの時間を割いています。
最後に
当日はたくさんの質問をいただきありがとうございました。これらの回答が少しでも皆様のお役に立てたら嬉しいです。
メルカリではメンバーを募集中です。少しでもご興味のある方は、ぜひともMercari Careersの募集要項をご覧下さい。
また、今後もエンジニアリング組織に関係するイベントを随時開催していきます。connpassでメルカリ/Mercariのグループメンバーになることで最新情報を受け取れます。
