「御社のプロダクト開発、どうやってますか?」dely×メルカリが疑問を投げかけあった社内勉強会レポート

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

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

前編では、クラシル開発組織が取り入れた「Squad(課題ごとにチームを作る開発スタイル)」、メルカリ開発組織の「Camp System(プロダクトを複数の領域に分解した状態した開発スタイル)」をそれぞれ取り入れた経緯や現状を紹介しました。前編最後では「メルカリ木下さんに聞きたいことがある」という話していたdely坪田さんですが、その内容とは?

この記事に登場する人


  • 坪田朋(Tomo Tsubota)

    livedoor、DeNAなどで多くの新規事業立ち上げやUIUXデザイン領域を専門とするデザイン組織の立ち上げを手掛ける。デザインファーム「Basecamp」を立ち上げてスタートアップの事業創出を支援。2019年7月からdely株式会社のCXOに就任。

  • 木下慶(Kei Kinoshita)

    筑波大学大学院コンピュータサイエンス専攻修了。NTTデータでのSE職、ランサーズでのエンジニア・プロダクトマネージャー職を経て、2016年6月株式会社メルカリに入社。メルカリのUS版、UK版のプロダクトマネージャーを務め、2019年7月よりJP版メルカリのHead of Productに就任。

  • 宮坂雅輝 (Masateru Miyasaka)

    マイクロソフト、株式会社楽天、株式会社ファーストリテイリングでさまざまな国内及び、グローバル向けの製品のプロダクトマネージメント行うのとともに、開発組織強化のためにAgile開発の導入、オフショア開発拠点の立ち上げなどに従事。2018年9月、株式会社メルカリに参画。現在はProduct Management OfficeのDirectorを務める。


メルカリのプロダクト開発で重要な2つの指標

宮坂:(「2社それぞれが紹介する開発体制の歴史」を語るなかで)坪田さんから質問があると言われていましたよね?

坪田:時間がおしているので、1つに絞りますね。木下さんに聞きたいと思っていたのは「プロジェクトマネジメントのアサインについて」です。

先ほどお話ししたように、サービスや考え方は複雑化しています。そうすると、機械学習を伴ったユーザー体験を実現するプロジェクトの場合、「どこまで技術サイドに寄せるか」によって、メンバーのアサインに悩むことがあります。「レシピのレコメンドアルゴリズムを頑張りたい」場合、機械学習に特化して解決すべき課題、ユーザーに入力を促進してルールベースで解決すべき課題など技術の使い所の判断や適切なメンバーのアサインに難しさを感じています。メルカリさんでは、どう解決していますか?

木下:ありがとうございます。メルカリではパーソナライズに特化したCampがあり、そこではホーム画面や検索に機械学習を取り入れようとしています。機械学習エンジニアはもちろん、デザイナーもいるので、UIを一緒に考えたりしているんです。また、プロダクトマネージャー(PdM ※メルカリではPMとしていますが、このイベント記事ではPdMとしています)とは別に、機械学習のアルゴリズム検索のロジックも話せるテックプロダクトマネージャー(TPM)もいる。そういったメンバーを同じCampに集めて、プロジェクトに取り組んでもらっていますね。

木下慶(メルカリHead of Product)

坪田:そこでは、最終的なユーザー体験の担保は誰がしているんですか?非エンジニアにとっては「機械学習でどんなコンテンツをつくるのか」がわかりにくいときもあるように思います。

木下:最終的には、定量的な評価をしていますね。そのためにまずABテストを設計し、どの指標を「成功」とするかを決めています。同時に、落としてはいけない指標「ガードレールメトリクス」も定義。ABテストでこの2つをクリアしたものを、全てのお客さまへリリースしています。細かく見ると、レコメンドされたコンテンツで「これは違うんじゃないか?」となる定性的なものもあるかもしれませんが、そこも含めて、数字で最終判断しています。

坪田:PdMがCamp内で指標を設計しているってことですか?

木下:メルカリには、分析業務を行うAnalyticsチームがあります。各Campにアナリストもアサインされているので、PdMと一緒に指標定義や分析設計書をつくっています。

坪田:なるほど、それは手厚くていいですね(笑)。細かいツッコミになるんですが、例えば自分のCampにとって優位な数字が、他のCampにとってマイナスになったとき、アナリストメンバーはどうカバーしますか?

木下:そこは、ガードレールメトリクスを見て判断します。もちろん主要KPIとベーシックなKPIは全社的にモニタリングしていて、数字が下がると検知されるようにしていますね。

「ピサの斜塔をまっすぐに維持する」ため、クラシルで培われた嗅覚

木下:先ほど坪田さんが話していた「ピサの斜塔」が面白いなと思っていて。事業環境や会社の優先度によって「お客さまに良くないことをやらざるを得ないとき」が発生する可能性はある気がしています。それはどう対応していますか?

坪田:クラシルでは1年前、そんな事態がありましたね。やはり足元の数字を維持しないと経営的にも厳しくなる。だからと言って、短期的な施策を打ち続けていては、本質的な価値をつくれずサービスの限界がきてしまう。これは、社長の堀江(dely代表取締役/CEO、堀江裕介氏)を含め、社内で感じる瞬間がありました。そこで大きく変更することにしたんです。

坪田朋(dely、CXO)

坪田:現在は、サービスの価値をつくるときには「ピサの斜塔をまっすぐに維持する」ことに意識を向けています。クラシルの売上は広告とユーザー課金ですが、iOSのIDFA問題によっていずれはアドネットワークの単価の下落が起こりうる可能性も考慮しています。市場全体で広告売上の不確実性もあるため、お客様がこのサービスにはお金を払ってでも使いたいという価値創出に振り切る意思から生まれた表現です。予算の達成度のジレンマは正直あり、まだ答えが出ていないので、悩みながら斜塔をまっすぐにする方向に抜けようと努力していますね。

宮坂:私からも質問していいですか?坪田さんの「ピサの斜塔」の話には、技術負債についても触れていましたよね?技術負債は、比較的見つけやすいものだと思っているのですが、クラシルではどう発見し、管理しているんでしょうか?

宮坂雅輝(メルカリProduct Management Office、Director)

坪田:数字で発見できたらいいのですが、そこまでシステマティックに管理できていません。属人的に、嗅覚みたいな感覚値で判断しているところがありますね。

弊社のメンバーはみんなすごくエゴサーチしているので、Twitter上でのつぶやきもキャッチしています。そこで歪みの発生ポイントを目で追いながら、ユーザーの意見やCSの反応を見て、自分の中の感覚値を持ち始める。社内チャットには開発について話し合うチャンネルもあり、エゴサーチしたTwitterの投稿をシェアすると議論が発生し、「これはやばいね」となることもあります。ユーザーの問い合わせを受け、経営会議やUX改善定例で「やめよう」と意思決定したこともありました。

会社を横断した判断は誰がやるのか?

宮坂:最後に、Q&Aです。寄せられた質問に「メルカリのCamp Systemでは、色や名前をつけないとありました。しかし、テーマのスコープによっては、結果的に色や名前がついていることになるのでは?」があります。どうですか?

木下:色や名前をつけずとも、向き合うテーマに意識が寄っていくことはあると思っています。今は「Camp1」「Camp2」「Camp3」としていますが、このほうが「リスティング」とつけるよりも広く考えられるのではないかと期待を込めています。

また、2021年1月からスタートした最新のCamp Systemでは、お客さまの登録からオンボーディング、取引完了まで一体感を持って体験設計しやすいように数を減らしています。ここが一番のアップデートですね。

坪田:クラシルでは、広告チームから「この枠を広告に使いたい」と言われることがあります。このような会社を横断した判断の可否は、メルカリさんではどうやって決めているんですか?

木下:今のところ、都度話し合ったり、意思決定したりしていますね。メルカリだと、どのチームもホーム画面部分で露出・開発したいと思っている。そこで「この範囲しかやりません」とせず、ホーム画面に手を加えたい時のガイドラインみたいなものをつくり、メルペイも含めて全社で共有。何かリクエストしたいときは「この情報をください」「この軸で優先度を決めます」とルール化し、広めていこうとしています。

坪田:では、担当するCampがある程度ルールを決め、他Campからオーダーがあったら話し合うスタイルなんですね?

木下:そうです。判断が難しいときは、メルカリ・メルペイお互いのプロダクトヘッドがいるところで話し合ったりしていますね。

坪田:なるほど、ありがとうございます。

「まだまだ完成形じゃない」

宮坂:ちょうど終了の時間になりました。最後に、ひと言ずついただいて終わりにしようと思います。まずは坪田さん、いかがでしょうか?

坪田:今日はいろいろ勉強になりました。delyもガードレールメトリクスのようなものを採用し、Squad間で統括するフレームワークをつくっていい規模になってきました。しかし、メルカリさんのCampは、弊社全部で1Campくらいの規模感なので、今後アップデートされるものを参考に追随できればと思いました。ありがとうございました!

木下:僕らも、非常に勉強になりました。Campはまだバージョン2であり、それも完成形とは言えません。まだまだ課題は出てくると思っています。数字で判断しているとお話ししましたが、「このUXいいよね」という定性的な感覚も数字で図ろうと今まさに取り組んでいるところです。そのあたりもぜひ、またどこかで情報共有できたらいいですよね。ありがとうございました。

関連記事 サクッと読める!✨

自社で基幹システム開発する背景・技術を知ってほしい!CS/CRE Tech Talkイベントレポート #メルカリな日々

“Technologies to support Trust and Safety” Mercari CS/CRE Tech Talk #2 Engineering for Trust and Safety イベントレポート #メルカリな日々

#MercariHackWeek のPre Event Hack Week Hints!!にてメルカリグループのエンジニアが公開議論! #メルカリな日々

関連記事 読み応えアリ✨