メルカリでエンジニアとPMのキャリアを行き来する中で見えたこととは

メルカリAIチームの古澤智裕（@furufuru）は、入社後の3年間で、一貫してメルカリのディスカバリー体験の改善に携わってきたそう。前編では、メルカリのレコメンデーションチームの立ち上げから現在に至るまでの歩み、そして今後取り組みたいことまでを教えてもらいました。

後編では、PM・エンジニア・スクラムマスター……とさまざまなポジションを経験した彼が、メルカリで働く中で大事にしてきたこと、またメルカリ特有の組織カルチャーについて教えてもらいました。

プロフィール

古澤智裕（@furufuru）| Product Manager
データサイエンスとソフトウェアエンジニアリングの楽しさに出会い、いつの間にかITの世界へ。大学院卒業後は図書館情報学をバックグランドとして情報検索や情報推薦のプロダクト開発に従事。2019年より株式会社メルカリに入社し、データサイエンスチームにて検索評価に取り組む。その後レコメンデーションチームの立ち上げを経て、現在はProduct Managerとしてプロダクト改善を推進している。

PMとエンジニアの経験によってスムーズな開発を進めることができた理由

──古澤さんは、メルカリ入社後の3年間で、PM・エンジニア・スクラムマスター……とさまざまなポジションを経験されてきましたが、そうした経験があるからこそ、メルカリで価値発揮が出来ていると感じる瞬間はありますか?

ひとつは、技術的な負債に対しても機能改善と同じようにアプローチができる点です。プロダクトを作っていると「直接お客様の価値に影響しないが、開発体験ひいては長期的な改善スピードに影響してしまう」といった技術的負債が生じることがありますが、こうした事象に対しても気を配れるようになりました。また、エンジニアのバックグラウンドがあるため、この機能開発にはどれくらいの工数がかかるか、どの要素に注力して取り組めばいいのか、なども判断しやすいですね。エンジニアメンバーともスピード感を持ってコミュニケーションできている実感があります。

もうひとつは、エンジニアとしても働く際にもPM的な立ち回りができるということでしょうか。レコメンデーションチームの立ち上げの時は、まだ社内の組織や開発環境も今ほど整っていませんでした。新たにレコメンデーションの機能を立ち上げるぞ、となった時もシステムとして変えていかなくてはいけない場所が多かったのですが、機能開発を進めるにあたって必要なメンバーを想定しながらコミュニケーションを進めていくことができました。

もう少し細かい話をすると、当時は ①クライアントのコード ②バックエンドのマイクロサービスのコード ③周辺の複数のマイクロサービスのコード、この3点をバランスよく変えていかないといけない状況でした。そのため各チームのエンジニアとコミュニケーションをし、デザイナーやCSチームとも話す必要がある。1つの機能を出すために、社内のさまざまな人とコミュニケーションを行った記憶があります。

こうした取り組みにより、レコメンデーションの機能開発を進めることができました。

TechPMとして大事にしていることは、データを扱う能力

──メルカリのTech PMとして求められる能力があれば教えてもらえますか？

メルカリのTechPMとして必要だと考えているのは、まずはデータを扱う力です。今あるデータを見て、何が起こっているか解釈する。データからみえるお客さまの行動をもとに、成功と失敗を定義する。失敗しているのであれば原因を突き止め次の手を考える…といった、判断のためのデータ分析能力が求められます。

施策を打つ際は、事前に「成功をどう測るか」ということを決めてリリースしています。一番簡単なのは、その機能を通じて売上が上がったかどうか、という測り方ですね。しかし、単一の機能でバーン！と数字が跳ねることは少なく、その手前のお客様の行動変化があるかどうか、というところを追いかけることも多いです。仮説通りに数字が動くこともあれば、変わらないことも。時には数字が悪くなることもあります。モニタリングしていた売上に繋がる手前の数値が良くなったとしても、売上自体が下がって、ということもありました。その場合、そもそもの仮説が間違っていたことになるので、仮説から作り直します。常にデータを見て、判断して、ということを繰り返す職種なので、データ分析能力は必要だと思います。

あとTechPMに限らず、PMとして重要なのは、ROIを常に考える力でしょうか。いかに効果的な施策を、より低コストに打てるか、勘所を持って戦略を立てることは大事な能力ですね。

「メルカリのエンジニアは、PMが考えたものを作る人たちではない」ことが衝撃だった

──メルカリの組織で特に得られた能力や、成長実感を得ていることがあれば教えてください

分かりやすく伝える能力、でしょうか。メルカリは、様々なバックグラウンドを持つメンバーがいる、ダイバーシティな組織です。入社当初、自分としては分かりやすく話しているつもりなのに、メンバーとうまく意思疎通できないことが多かったんですよね。「こういうことをやります」とチームに伝えても「この施策に取り組む価値がわかない」とコメントが返ってくることも。「どうやら価値が伝わっていないぞ？」と、改めて原因を振り返ってみると、すべてを丁寧に伝えようとしすぎて、かえって難しく伝えていたことに気付きました。異なるバックグラウンドをもつメンバーに対して分かりやすい情報伝達をするために「最も伝えるべきことは何で、この施策の価値はどこにあるのか」ということを考え、情報をできるだけ削ぎ落とし、重要な点のみを抽出して伝えるように努めました。また、メンバーのバックグラウンドに合わせて、伝える情報を取捨選択する視点を持ったことで、PMとして、一緒に働くメンバーと働きやすくなりました。

あと、ピラミッド型の組織だと、上から伝達された情報をさらに下に伝えていく流れですよね。メルカリは横に情報伝達をし、メンバー同士のコミュニケーションを経てトップレベルに合意を取りにいく、ボトムアップの流れも存在しています。このボトムアップの流れを作るためのメルカリ特有な情報伝達の仕方も学びになりました。

──その他、メルカリ特有のカルチャーなどがあれば教えてください

メルカリに入って衝撃を受けたことの一つは、エンジニアから発信されるものがすごく多いということです。メルカリのエンジニアは「PMが考えたものを作る人たち」ではないことはすごく衝撃でした。彼らは「作る意義がわからないもの・作りたくないものは作らない」というスタンスを持っているので、私も作る意義はいつでも説明できるように心がけています。

逆にエンジニアの立場としても、PMから「これ作って」と言われたときにそのまま「OK！」と請け負うことは良しとされていないんです。システム的には問題がないか、実装のコストはどうか、作る意義はなんなのか、チーム全体として腹落ちしてないといけない。

PMとして、会社として作らないといけないことが決まっている実装だとしても、その機能の価値やコンテクストをエンジニアに伝え、そして納得してもらう必要があります。「これを作って！」という一方的なコミュニケーションだと、いいものが生まれなくなるんですよね。

エンジニア・PMの両方を経験し、双方の気持ちが分かるようになりました。PMであれば、エンジニアに背景となる情報や意味を正しく伝えて動いてもらう必要性を学びましたし、エンジニアとしてはPMに対して主体的に意見を持つことが必要だと感じました。

メルカリのディスカバリー体験は、まだまだ改善できる余地がある

──古澤さんが入社当初、メルカリでやりたかったことは達成できたのでしょうか

入社から一貫して、メルカリの検索やディスカバリー体験の改善に取り組んできました。実際、お客さま体験は改善してきたと思いますが、まだまだ改善の余地があります。メルカリは、エンジニアだからここまでというボーダーはなく「アプリをよくしたい」という思いがあれば、挑戦を後押ししてくれ、私の体験としては実際にPMとしてレコメンデーションチームを軌道に乗せることができました。会社の方向性と合ってさえいれば、個人の意志を大事にしてくれると思います。

振り返ってみると、メルカリにはデータサイエンティストとして入社しましたが、PMとして働く機会にも恵まれました。今後も自分としてのやりたい方向に合っていれば挑戦していきたいです。

• Photo : Shun Nakayama (Web/Twitter)
• Text : Ayumi Iga (Twitter)