CodeZine(コードジン)

特集ページ一覧

プロダクトとエンジニアリングの理想の関係とは? 「メルペイ」リリースまでの組織変革に学ぶ

前編

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2020/06/01 11:00

 日本最大フリマアプリ「メルカリ」の決済基盤として、2019年2月にリリースされたスマホ決済サービス「メルペイ」。メルカリの売り上げを電子マネーとして支払いに使用できるなど、他サービスとの差別化を図り、順調に業績を上げている。リリース以降も、コード決済やクーポン機能、後払いサービスといった新機能を次々と追加するなど、サービス価値を高めてきた。スピーディで柔軟な開発を支えるエンジニアリングの戦略やマネジメント組織のあり方などについて、開発チームを束ねる同社執行役員 VPoEの木村秀夫氏に伺った。

目次
株式会社メルペイ 執行役員 VP of Engineering 木村秀夫
株式会社メルペイ 執行役員 VP of Engineering 木村秀夫

ISPでエンジニアとしてのキャリアをスタートさせ、独立起業や通信キャリア等での開発業務を経て、2009年株式会社ディー・エヌ・エーに入社。Mobageオープンプラットフォームの立ち上げ、グローバル展開、Mobage全体のマネジメントに従事。2013年に執行役員に就任。その後もオートモーティブ新規事業立ち上げ、システム&デザイン本部長を経て、2018年5月、株式会社メルペイ執行役員 VP of Engineering に就任。

リリースから1年、快進撃を続けるメルペイ、成功の鍵を握る「VP of Engineering」とは

――さまざまな電子決済アプリが登場する中で、「メルペイ」はひときわ好調と聞きます。その理由について、どのように捉えていらっしゃいますか。

木村:「メルペイ」は2019年2月にリリースされた、スマホの決済アプリです。日本最大フリマアプリを展開する「メルカリ」のグループ会社として事業を開始し、リリースより1年程度で600万人以上の利用者を獲得しています。これはメルカリのユーザーの大部分をスライドできたこと、そしてメルカリの売上金をコンビニなど実店舗の決済で使えるという、他の決済サービスにはない独自性が大きな差別化になっていると考えています。

 メルカリの売上金がなくても手数料無料で銀行口座からチャージでき、決済方法としては、非接触型のiD決済、バーコード払い(CPM方式)、店舗側のQRコードを読み取るMPM払いの3種類を提供しています。中でもiD決済は決済アプリとしてはめずらしく、特徴の1つと言えるでしょう。また、ネット決済にも対応し、アパレルECを中心にオンラインでも使えるほか、「メルペイスマート払い」ではクレジットカードのように与信枠を設け、チャージせずとも後からまとめて支払える機能も提供しています。ユニークなのがその与信枠を、従来の属性や年収などではなく、メルカリの取引実績などを加味して算出していることでしょうか。

 メルペイでは「新しい『信用』を生み出す」というミッションステートメントを掲げているように、フリマアプリ「メルカリ」との連携もあって、ほかにはない決済の体験を提供しようとしています。それが期待感をもって受け入れられているのでしょう。

――メルペイのプロダクト開発に、木村さんはどのような立場で関わられているのでしょうか。メルペイの開発組織におけるポジションや役割についてお聞かせください。

木村:メルペイ全体の技術部門を束ねるCTO(Chief Technology Officer)である曾川景介と、VPoE(Vice President of Engineering)として、メルカリのエンジニアリングのマネジメント責任を担っています。CTOが組織全体の技術的な方向性やビジョンを示す立場だとすれば、VPoEはチームビルディングやプロジェクトマネジメントなど、より現実的にプロダクト実現に向けた指針を決定し、リードする立場と言えるでしょう。

 組織としては、「What:何を、Why:なぜ作るのか」にコミットし、企画とプロジェクトマネジメントを担う「プロダクトチーム」と、「What:何を、How:どうやって作るのか」を考え、テクノロジーを駆使して開発および運用を行う「エンジニアチーム」とに分かれており、私はエンジニアチームのマネージャーになります。

 基本的には、プロダクトマネージャーがユーザーニーズや市場の動向などを見ながら、プロダクトの方針やその機能として何を盛り込むかを考え、企画します。それを実際にどのようにアプリケーションとして設計、実装するのかが、エンジニアの役割になります。

プロダクトマネージャーと密に連携し、プロジェクトの完遂にコミットする

――プロダクトマネージャーとエンジニアリングマネージャーはお互いに連携し、補完し合う関係に見えますが、エンジニアリング側から見たプロダクトマネージャーとの関係についてお聞かせください。

木村:プロダクトのリーダーとしての仕事で最も重要なものは、「あらゆるステークホルダーと合意形成を行うこと」だと思います。なぜそれを作ろうと考えたのか、どのように企業として社会にインパクトを与えようとしているのか。それを考えて構想する仕事も大切ですが、組織やチームで実現させるためには、構想を誰もが理解し、共有することが欠かせません。

 例えば具体的な手法としては、プロダクトの立ち上げ時にすべてのステークホルダーを集めて「なぜこのプロダクトを開発するのか」をしっかりと伝えるキックオフミーティングなどが挙げられます。口頭でイメージ的に語るだけでなく、より具体的に求めるスペックや機能などを文書化して読み合わせることが大切です。こうしたことは些細なことのように見えますが、できないまま進行すると当初の合意形成に支障が出るだけでなく、時間が経つにつれてプロジェクトの目的を見失い、はては頓挫する可能性が高いのです。プロジェクトの開始後も随時、文書で残して評価を行い、目的などを振り返りつつ進行することが重要です。

――そうしたプロダクトマネージャーの役割に対して、エンジニアリングマネージャーとしてはどのように関わっているのですか。

木村:こうしたあらゆるステークホルダーとの合意形成は、本質的にはプロダクトマネージャーの役割ですが、エンジニアリング側から見て、意見やアドバイスをすることもあります。プロジェクト開始後も、時にはエンジニアとの間に齟齬が生じる時があるので、その際には調整役を担います。

 私が入社する前、メルペイのプロジェクトが開始されてしばらくの間、メンバーが50人に満たず、エンジニアの評価や採用まであらゆることをプロダクトマネージャーが1人で行っていた時期がありました。リリース前のスピードが求められるフェーズだったため、そうした形態が望ましかったのでしょう。また組織も小さく、プロジェクトの目的共有も比較的行いやすかったのだと思います。

 しかし、私が入社した2018年5月頃には、急速に人数が増え、行うべきタスクも増えており、かなりカオスな状態でした。プロダクトマネージャーの負担も爆発的に増し、本来の仕事である、プロダクトの目的や構想を考える時間すら十分に取れない状況にありました。時間もリソースが限られ、要件が大きく、難易度も高いという過酷な状況下で、誰もが鬱々とした雰囲気が生じていたのです。

 エンジニア側は「なかなかリリースの判断が降りない」「求められる優先順位に違和感を覚える」などの不満をため、プロダクトマネージャー側は「なぜこの機能の実装にこんなに時間がかかるのか」「進捗状況が見えない」と不安に思い、双方のすれ違いが明らかでした。また以前より、エンジニアの方から自分の仕事やスキル、成長などを、エンジニアである人に評価されたいという要望も上がっていたとも聞いています。

 混沌とした状況を整理し、エンジニアとの橋渡し役となる役割が必要でした。それがエンジニアリングマネージャーというポジションだったわけです。さらに、組織全体についても再編成を行うことになりました。私が入社して約2か月後、2018年7月のことでした。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 伊藤 真美(イトウ マミ)

    エディター&ライター。児童書、雑誌や書籍、企業出版物、PRやプロモーションツールの制作などを経て独立。ライティング、コンテンツディレクションの他、広報PR・マーケティングのプランニングも行なう。

  • 岡田 果子(編集部)(オカダ カコ)

    2017年7月よりCodeZine編集部所属。慶応義塾大学文学部英米文学専攻卒。前職は書籍編集で、趣味・実用書を中心にスポーツや医療関連の書籍を多く担当した。JavaScript勉強中。

バックナンバー

連載:プロダクト開発の先進事例に学ぶ、キーパーソンインタビュー
All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5