2019年２月のサービス開始から63日で累計登録者数が100万人を突破し、その後６月には200万人を突破するなど、上々の滑り出しを見せているスマホ決済サービス『メルペイ』。リリース以来、コード決済、クーポン機能、後払いサービス、ネット決裁など、矢継ぎ早に新機能をリリースしている。

そんなメルペイのスピーディーな機能開発を支える影に、近年注目されている職種でもあるプロダクトマネジャー（以下、PdM）の活躍がある。定義や役割は企業によって異なるものの、一般的にPdMの役割は「何をなぜ作るのか」にあり、PMの役割は「いつまでにどのように作るのか」にある。

まだまだ日本企業に浸透しているポジションとは言えないが、役割や志向性は違えど「プロダクトに責任を持つ」という意味では、プロジェクトマネジャー（以下、PM）と通じるものがあるだろう。

そこで今回は、メルペイのエンジニアリング責任者である２人、CTO（Chief Technology Officer）の曾川景介さんと、VPoE（Vice President of Engineering）の木村秀夫さんにお話を伺った。メルペイのこれまでの振り返りとともに、優れたPdMの条件を紐解いていく。メルペイのPdM像から見る、プロダクトをグロースする役割を担うPMが学ぶべき視点とは？

メルペイはメルカリのアーキテクチャの転換が生んだ大きな成果

CTOの曾川さんは、メルペイをリリースした手応えを「想定以上だった」と振り返る。好調の理由を次のように分析。

「これまでメルカリで得た売上金は、メルカリ内で使うか、銀行口座に移して引き出すしかありませんでした。しかしメルペイの登場によって、実店舗での利用に加え、後払いも可能になり、手元に現金という“財”がなくても、何かを得て、活用することが可能になりました。お客様には、こうした点を高く評価していただいているのではないかと思っています」（曾川さん）

実際、モバイルに特化した調査研究機関・MMD研究所が発表した「2019年7月QRコード決済利用動向調査」にて、メルペイは総合満足度1位にランクインしている。

一方、エンジニアチームを束ねるVPoEの木村さんは、２月のリリースから６月までに「ユーザーがメルペイに価値を感じていただける機能を、一旦は一通り出せたと思う」と話す。機能リリースの順序やタイミングは、メルカリ利用者の動向や属性データなども参考にしたと言う。

「追加機能の仕様やリリースのタイミングにおいて大切にしたのは、価値ある機能から提供すること、そしてメルカリを利用していただいているお客さまにも安心してお使いいただくことの２点でした。これからも新機能のリリースは続きますが、滑り出しの第一フェーズとしては、とてもうまくいったと思います」（木村さん）

一方、曾川さんは、長年ペイメントサービスの開発に携わってきた経験から「当初から、これほどスケーラビリティを考慮に入れて設計された決済サービスは無いのではないか」とメルペイを評する。

「多くの決済サービスは、キャパシティプランニングが困難なことから、初期段階からスケーラビリティを備えていることは稀です。しかしメルペイは、月間利用者が1300万人ものメルカリの決裁基盤という側面を持つ決済サービスであるため、最初から膨大なトラフィックに耐えられるよう設計されました。そういう意味では、数ある決済サービスの中でも稀有な存在といえるかもしれません」（曾川さん）

曾川さんは、こうした設計を可能にした背景に、2017年から始まったメルカリのサービス基盤の構造的転換があったと話す。メルカリはサービスの改善頻度とスピードを高めるため、マイクロサービス化に取り組んできたのだ。曾川さんは、そのひとつの成果がメルペイと位置付けている。

「開発スピードの速さなど、モノリシックなアーキテクチャにもメリットはあります。しかし、サービスが成長しシステムが大きくなりすぎると、課題の解決に時間が掛かってしまうといった、さまざまな欠点が露わになってきます。この問題を温存していては、メルカリを世界的なマーケットプレイスにすることはできません。

だからこそメルカリは、サービス基盤の効率的な運用や改善を目指し、２年ほど前からマイクロサービス化に積極的に取り組んできました。こうした経緯を踏まえると、メルペイはメルカリのアーキテクチャの転換が生んだ、一つの大きな成果といえるのではないでしょうか」（曾川さん）

PdMとエンジニアが同じ方向を見て仕事をするのは、海外のテックカンパニーでは当たり前

続々と新機能をリリースし、利用者の裾野を広げるメルペイ。では、エンジニアとPdMは、どのような開発体制で働いているのだろうか。

木村さんは「メルペイでは、その時々の必要性に応じてメンバーをアサインするマトリクス型組織を採用している」と言う。

「エンジニアは、フロントエンドやバックエンドなど、担当領域ごとに組織化され、PdMは、CPO（Chief Product Officer）のもと、機能やプロジェクトごとにアサインされるのが通例です」（木村さん）

つまり、機能やプロジェクトの目的ごとに、目的達成に必要なスキルを持つエンジニアがPdMのもとに集まるようになっている。木村さんは、他社の開発体制と比較して、メルペイには次のような特徴があると感じている。

「一般的にビジネス側の要求を代表するPdMと、テクノロジーによってその要求を実現していくエンジニアは、立場も専門性も話す言葉も異なります。そのため、コミュニケーションに問題が生じがちなのですが、メルペイの場合は互いの専門性や立場についての理解が進んでおり、常に同じ方向を見て仕事をする印象が強い。GAFAをはじめ海外のテックカンパニーなどでは既に当たり前の光景ですが、日本の会社ではまだ珍しいと思います」(木村さん)

だからといって、PdMとエンジニアが馴れ合っているというわけではない。プロダクトに対するミッションが明確に定義された上での協調なのはいうまでもない。

しかし木村さんは、両者の所属組織を分け、プロジェクトへのアサイン権限も明確に分離しているのは、プロダクトに対する貢献のためだけではないと話す。「エンジニアのリソースを社内の技術基盤のアップデートにも適切に配分するためでもある」からだ。

「金融サービスはステークホルダーが多く、プロダクトに対する要求レベルも非常に高いため、どうしてもエンジニアのリソースをプロダクト開発に振り分けようとする力学が働きがちです。一方、社内の開発基盤も一度作ってしまえば終わりというわけにはいかず、常に新しい技術を取り入れ、技術的負債が溜まったら返済していかなければなりません。マトリクス型組織を採用しているのは、両者のバランスを保つためでもあるのです」(木村さん)

「何のためにこの機能を開発しているのか」を問い続ける

PdMは、エンドユーザーが求めるサービスを生み出すために「何を作るか（What）」、「なぜ作るか（Why）」を徹底的に考える役割を担う。一方、PMは「いつまでにどのように作るのか」を追求する立場であり、一般的に役割は異なる。

CTOの曾川さんは、メルペイの開発に加わった複数のPdMたちに対して、常に「未解決の課題を解決しているという自覚」と「社会に対する責任感と思慮深さ」を求め続けたと言う。

「メルペイの開発に取り組んでいる間、常にPdMたちには『何のためにこの機能を開発しているのか』という問いを投げかけ続けました。社会のために役に立つサービス、機能とはどのようなものかを見つけることが、PdMにとって最も重要な使命だからです。一方で、この２つの問いはPdMだけに当てはまるものではなく、エンジニアを率いるPMにも求められるものだと考えています」（曾川さん）

「PdMとPMの両者は、プロダクトをグロースさせるという目的においてはあくまで同じ立場にいる」と曾川さんは続ける。

「『未解決の課題を解決しているという自覚』と『社会に対する責任感や思慮深さ』は、PMにも求められる素養です。PdMとPMでは、確かに専門性と役割は異なります。だからといって、テクノロジーを駆使して『How』を追求するエンジニアが、社会との関わりの中でサービスを開発しているという意識を持たなくていいわけではありません。優れたプロダクトを提供するためには、PMも社会との関わりを通じて、『Why』や『What』を考えるべきだと思います」（曾川さん）

その上で、「エンジニア出身のPdMが希少なように、『Why』や『What』を念頭に『How』を考え抜けるPMは市場価値が高い」とVPoEの木村さんは話す。

「PdMとPMは、サービス開発における役割や立場、専門性、課題に立ち向かうアプローチが違うだけで、求められる素養については、実は共通する部分が多い。優れたプロダクト開発の影には、こうした思考ができる人たちが数多く集まっているように感じます。そしてその中で一番執念を持ち、最後まで成し遂げる力を持つことが、プロダクト開発を牽引するリーダーに求められる素養です」（木村さん）

PdMもPMも、固有のスキルや資質、志向性を除けば、両者の間に明確な線引きがあるわけではない。テックカンパニーとして抜きん出た存在になるためには、「Why」や「What」を念頭に「How」を考え抜けるエンジニアを育成する役割を背負うPMの果たすべき責務は大きい。他社の事例を参考に自覚を持って取り組むべきだろう。

取材・文／武田敏則（グレタケ）　撮影／桑原美樹