「もしよろしければ一緒に勉強会か、お互いの開発体制、プロセスと課題の共有会とかやりませんか？」

そんなひと言から始まったのが、レシピ動画サービス「クラシル」や女性向けメディア「TRILL」を運営するdelyを迎えた合同社内勉強会「Mercari×dely session」。当日は、クラシル・メルカリそれぞれでプロダクト開発をリードするメンバーが登壇し、開発体制の歴史を紐解きながらお互いの知見を共有し合いました。

今回のメルカンでは「各社の開発体制の歴史」にフォーカスし、2社それぞれが紹介する開発体制の歴史とパネルディスカッションの2本立てで勉強会の内容を記事化。前編では、delyのCXOである坪田朋さん、メルカリのHead of Productを務める木下慶が紹介する「Mercari×dely開発体制の歴史」をお届けします。

現在、メルカリではCamp System（キャンプシステム）、delyではSquad（スクワッド）が開発組織に取り入れられています。両社とも課題となっていたのが「意思決定の複雑化」「他職種との連携」。近しい課題感はあれど、なぜ現在のスタイルを取り入れることになったのでしょうか？

「バックエンドをお客さま視点やUXに近づけたい」から始まったメルカリのCamp System

ー現在、メルカリのMAUは約1,700万。リリースしたころは20名程度だった開発組織も、現在は500名以上になりました。当初は現メルカリ代表取締役CEOである山田進太郎がプロダクトオーナー（PO）を務めていましたが、事業規模の拡大とともにメンバーも職種も増え、PO + 複数名のプロジェクトのオーナー（PJO）を設置し、プロダクトマネージャー（PdM ※メルカリではPMとしていますが、このイベント記事ではPdMとしています）がPJOを担うようになったのです。

木下：僕がメルカリへ入社したのは2016年6月。このときはプロダクトを複数チームに分解し、各チームのオーナーの役割をPdMが担っていました（PJO制）。特徴的だったのは、デザイナーやエンジニアなどのレポートラインもPJO（PdM）に紐付いていたこと。つまり、プロジェクトとメンバーのレポートラインが一致した体制だったのです。

ーここまで話を聞くと、開発組織としては理にかなったようにも聞こえますが、同時に「エンジニアの評価はエンジニアが行うべき、という意見も出ていました」と木下は言います。そして2018年4月に導入したのが、エンジニアリングマネージャー（EM）でした。こうして、iOSエンジニアの評価はiOSチームのEM、PJO（PdM）はPdMの評価をするといった横串で職種ごとにマネジメントを実施（PMM/EM体制）。

木下：2019年1月からは、四半期ごとのプロジェクトベースに変えてきたチームを体験ベースで固定化。メルカリ内で進められていたマイクロサービスへの移行を推し進めるため、フロントエンドとバックエンドを分けた「Front-Back体制」にし、Backendチームを体験設計するチームから分離させたこともありました。

ーそして2019年2月に決済サービス「メルペイ」をリリース。同年4月にはスクラムを導入するほか、海外から来たメンバーの増加に伴い、スペックやドキュメントの英語化も進められました。

木下：メルカリでは2020年1月から「Camp System」を始めています。Camp Systemとは、プロダクトを複数の領域に分解し、各領域を「Camp」として、さらにその中には複数のスクラムチームが存在。各Campが担当する体験に直接関わるバックエンドもCamp内にあることがFront-Back体制との違いです。

木下：以前まではフロントエンドとバックエンドを分けた「Front-Back体制」だったのですが、バックエンドが離れたことで、体験設計をするチーム内で開発が完了しないといった課題がありました。そのため、バックエンドも含んだCamp Systemを導入したのです。各CampにはPdMヘッドとエンジニアヘッドをアサイン。コミュニケーションや意思決定もCamp内で行い、スピード感を持って開発を進められるようにしました。

課題になったのは「体験設計が局所化」「優先順位の不整合」「メルペイとのコラボ」

ーでは今、メルカリのCamp Systemはどうなっているのでしょうか？

木下：Camp Systemは「Product Camp」「Platform Camp」の2つに分けられます。Product Campは、いわゆるお客さま向けUX改善に取り組むことがミッション。そのため、会員登録やホーム画面、検索、購入など、お客さまの利用シーンごとに分かれた8つのCampがあります。Platform Campでは、データやアーキテクチャ、機械学習、DPEの4つにCampを分けています。

ー課題になったのは「Campごとで体験設計が局所化」「優先順位の不整合」「メルペイとのコラボレーション」。

木下：「Campごとで体験設計が局所化」は、それぞれのCamp内でクロスファンクショナルに意思決定できたのはよかったのですが、“閉じた発想”になる傾向がありました。そこで「出品体験」など大きなテーマ設定にし、それぞれのテーマにCampをアサイン。Campの数も減らしあらゆる場面でメンバーがオーナーシップを持って開発できるような体制にし、解決しょうとしています。「優先順位の不整合」では、プロダクト全体・Campごとの優先順位が異なる事態も起きていました。これについては、プロダクト全体で優先度調整ができる仕組みを導入予定です。

最後に「メルペイとのコラボレーション」。メルカリとメルペイは同じアプリ内のサービスです。ですが、組織は分かれていますしサービスフェーズも違います。そうすると、双方ともに「あちらはどこにフォーカスしようとしているのか」「開発プロセスはどうなっているのか」がわからない。そのため、各社の全社定例でトップから共通の取り組みを説明したり、中長期的なお客さま体験にフォーカスするKPIをお互いに設定。コミッティのようなものも運営し、意思決定でのコンフリクトがあったときには各社の経営陣や担当者で話し合えるようにしました。

木下慶（メルカリHead of Product）

ーそして、「2021年からはCamp体制をアップデートします」と木下。

木下：2021年1月からは、さらにアップデートしたCamp体制がスタートします。まずは一つひとつのCampをお客さまの体験に合わせて大きくし、お客さま視点に近づける。最終的には、どのCampでもどの画面・バックエンドでも開発できるようにしてさらに体験設計の柔軟性を上げることを目標にしています。

Squad体制の導入は「自走したい人が自走できない状態になりつつあったから」

ー続いて登壇したのは、クラシルのCXOである坪田さん。前提として、クラシルの開発組織はエンジニアとデザイナーが所属しています。求められているのは「経営ビジョンとの接着」「プロダクトマネジメント」「ピープルマネジメント」「技術マネジメント」の4つ。そんなクラシルの開発組織が2020年4月からSquad体制を導入した理由とは？

坪田：Squad体制にしたのは、クラシルのサービスステージが変わり、属人的な意思決定では開発スピードを遅らせてしまうと感じたから。ようするに、以前までのクラシルでは、自走したい人が自走できない状態になりつつありました。そのため、課題ごとにチームをつくるSquadを採用。現在は、1Squadに5〜6名いるイメージですね。

ークラシルの開発組織をSquadにした手応えは？坪田さんは「職種と組織の壁をなくせたこと」と話を続けます。

坪田：Squadのなかには、アプリのパフォーマンスや起動速度を上げる「速度改善Squad」があり、エンジニアがPdM（Product Manager）を担当します。そしてもう1つが「新機能Squad」。ここでは不確実性の高いものに向き合うことを目的に、プロトタイプを触りながら話し合うため、仮説を可視化するデザインドリブンです。このようにSquadを使い分けられるおかげで、横断コンテンツによるサイロ化を避け、イシュー解決に必要なメンバーを集め、ユーザー価値を実現できるようになりました。

ーしかし、Squad導入は一筋縄ではいかなかったと言います。

坪田：Squad導入時は「いきなりGo」とはできず、最初は開発チームのみでスモールスタートさせました。そこから徐々に検索やコンテンツといった関連職種を巻き込み、マーケティング側にも横断できるように変えていったのです。

以前の開発組織では、各職種のマネージャーがプロジェクトを管理していました。Squad開発ではそれを切り離し、開発スタイルや達成KPIはSquad単位でルールをつくっています。職種のキャリアや横断した技術選定は職種マネージャーに相談するという、縦と横軸の組織のバランスを整えたイメージです。

「ピサの斜塔現象」を避けるための長期的視点

ー坪田さんいわく「Squad体制はまだまだ試行錯誤の途中」であり、しっかりとルール化できていないところもあるそうです。そこで、四半期ごとに出た課題にあわせてルールをつくる「みんなで作るSquadルール」も実施。最近では、リモートワークの導入とオフィス移転を機に、Squadごとに座席替えもしています。

坪田：検索やパフォーマンス改善などの価値実現のために必要な人をSquad内にアサインしながら実現していきたい。そのため、会議体で決めるより、リアルタイムで実行し、成果を出せるために、席で話せるようにしたんです。

ただ、現場に裁量を与えすぎるとプロセスが複雑化し、連携が難しくなります。クラシルでは、アウトプットに3週間以上かかるタスクは開発定例で起案し、議論するなどプロセスを透明化。全員で解像度を上げることで、SquadとSquadの価値が掛け算的に上がるようにしました。そのため、週次定例でも経営メンバーが入り、方向性を議論。そうすることで、意思決定のほか、普段サービス関連の話ができていないメンバーと連携できるようにしました。そのほか、サービス関連のMTGが長引いた場合、上司との1on1をスキップしていいという「ユーザーファースト」な文化も形成しています。

ーここで飛び出したのが「ピサの斜塔現象」。これは、短期的目標で小さな歪みが積み重なり、崩れていく状態を表した言葉です。Squadでも、掛け算で価値を発揮していくなかで「自分さえ成果を出せばいい」となると、小さな技術負債を残してしまうことを懸念していました。

坪田：技術負債に関しては、長期的なものにこそじわじわとダメージを与えるところがあります。長期で持続するサービスづくりをする上で、短期的に数字を稼ぐために小さなダメージを蓄積させるのではなく、「長期的に持続できるサービスにするためには？」の視点を全社で持てるように意識しています。

まとめのようになるのですが、考え方としてはサービス・プロダクト優先であり、組織改善を優先することはありません。Squadは四半期ごとに体制を見直していますが、あわせてPdMも編成も変えていきます。最終的には、誰もがサービスのことを考えられる状況にできればと思っているんです。

坪田朋（dely、CXO）

担当PdMによって領域が偏るアンバランスさを整えるには？

ー最後に「これは木下さんに相談しようと思っていたんですけれど」と坪田さん。

坪田：最近、サービスも考え方も複雑化しています。例えば、機械学習エンジニアをPdMにしたとき、技術サイドに寄りすぎてしまい、UIとの連携が薄くなったり。逆に、デザイナーをPdMにすると、アルゴリズムまで考えきれなかったり。そのあたりのバランスをどうとるべきか悩んでいます。

また、Squad以外のボールが拾えなくなると、CSの要望を見落とすようなことも起こると危惧しています。Camp SystemはSquadに近しいところがあるので、メルカリさんではどうやって解決しているのかを聞きたいと思いました。ここはぜひ、次のパネルディスカッションで質問させてください。