
2025年、メルペイの「おくる・もらう」に、QRコード送金機能の追加・受け取りフローの改善など、約5年ぶりとなるアップデートが行われました。日常的なコミュニケーションのなかで、より手軽に、そしてスムーズにお金のやりとりができるようになった今回の改善。
しかし、この5年間、改善への要望はありながらも送金のニーズが顕在化せず、社内でプロジェクト化し実装に向けて動かすことに苦戦し続けたという歴史がありました
このプロジェクトを突き動かしたのは、一人の新卒メンバーの「どうせ誰もやらないなら、自分たちでやろう」という熱意。その思いは開発合宿をきっかけに多くのメンバーを巻き込み、ついには経営層をも動かしていきます。
ボトムアップで生まれたこのプロジェクトは、どのようにして数々の壁を乗り越え、リリースまでたどり着いたのか。プロジェクトの中心となったメンバーたちに、その軌跡と未来の展望を聞きました。
この記事に登場する人
-
和田拓弥 | @phi / ML Engineer
2021年にメルカリグループが開催している、トレーニングとインターンシップのオンラインプログラム「Build@Mercari」のインターン生として参加。北海道大学大学院工学院を卒業後、2023年にメルペイに新卒入社。現在はCredit Modelingチームに所属。
-
@kubomi / iOS Engineer
Build@Mercariプログラムのインターンを経て2024年にメルペイにiOSエンジニアとして入社。Payment Mobileチームで、メルカードやおくる・もらうのモバイル開発を担当。
-
小林亮太 | @kobaryo / Backend Engineer
2024年にメルペイに新卒入社。Balance Team (Payment Platform) のBackend Engineerとして残高管理基盤の開発を担当。
-
@yag / Product Manager
2023年からメルペイに入社。Growth PlatformでCRMサービスのプロダクトマネージャーを経験後、2025年からCredit Payment チームでメルカードのグロースを担当。
「なぜ改善しない?」新卒メンバーの素朴な疑問から開発がリスタート
ーまず、メルペイの「おくる・もらう」機能は、なぜ開発されたのでしょうか?また、5年もの間、大きなアップデートがなかったのか、その背景から教えていただけますか?
@phi:私は2023年の入社なので、当時の担当PMに聞いた話になりますが、2020年のリリース当初、この機能が生まれた背景は2つあったと聞いています。
1つは、メルカリのエコシステム強化です。メルカリでの売上金など、サービス内で生まれたお金の使い道の選択肢を増やしていただく狙いもありました。もう1つは、当時メルペイが注力していた本人確認(eKYC)済みのお客さまを増やすための手段としても期待されていました。個人間で送金をするには本人確認が必要になるため、個人間送金は、その促進策としても開発が進んでいたそうです。
ーなるほど。お客さま向けの機能という側面に加え、事業戦略上の目的も大きかったのですね。ではその後、なぜアップデートが止まってしまったのでしょうか。
@phi:正直なところ、「メルペイにおける送金機能のニーズが顕在化していなかった」という点が大きかったようです。個人間送金はインフラ的な側面も強く、機能自体が直接的なメリットを生むわけではありません。事業としてどう絡んでいるかの整理が十分に出来ておらず、お客さまのニーズも明確になっていなかったことから、改善の優先度がどうしても上がりづらくなっていました。
社内のメンバーからも「使いづらい」という声は常に上がっていて、メンバー同士の送金などでは他社サービスが使われることもあるのが実情でした。
@kubomi:その「ニーズの顕在化」という点は、今回のプロジェクトが実現フェーズに移る際の大きなハードルにもなりましたね。「どの程度お客さまに使われるのか?」「これをやって、どんなインパクトがあるのか?」と問われたときに、「使いやすくなります」「やりたいんです」という情熱だけでは、会社を動かすのは難しいという現実がありました。
ー優先度が上がらない状況の中で、皆さんが「動かそう」と決意したきっかけは何だったのでしょうか。
@phi:直接のきっかけは、私を含めた23卒の新卒メンバーの「どうせ誰もやらないなら、自分たちでやろう」という思いでした。私自身、社内の部活動に参加する中で、精算などで不便さを感じていましたし、@kobaryoさんも「メルペイ単体をもっと強くしたいのに、送金がしづらいのは致命的だ」という強い問題意識を持っていました。
そこで、私が発起人となり、同期に声をかけて有志での活動を始めたのが最初です。幸い、QAや開発、運用担当のメンバーまで23卒に揃っていたので、「これならできるはずだ」と。ただ、当時は私も旗振り役としての経験が浅く、皆それぞれ本業がある中での調整はうまくいきませんでした。それでも諦めきれず、いつか経営層に提案できる日に向けて、課題の整理などの準備を水面下で進めていました。
きっかけは開発合宿。有志の熱意がプロトタイプを作り上げた
ー有志での活動から、どのようにして現在のチームが形成されていったのですか?
@kobaryo:大きな転機は、2025年1月に開催された開発合宿です。ちょうど良いタイミングで、普段の業務から離れてフルコミットできる機会が訪れました。@phiさんも機能改善への思いを発信していたので、「では、合宿で形にしよう」と。
@kubomi:そこからメンバーが続々と集まり、チームが固まっていきました。私も参加を決めたのは合宿当日の朝、合宿に向かう道で @kobaryo さんから話を聞いてチームへの参加を決めたんです(笑)。
ーすごい熱量ですね。合宿では、どのような形で開発を進めたのでしょうか。
@kobaryo:2日間という限られた時間でしたが、とにかく集中しました。バックエンドのメンバーがその場で初めてiOS開発に挑戦したり、皆で夜遅くまで作業したり…。プレゼンが始まってからも、裏ではまだ開発を続けているような状態でしたね。
@phi:ビンゴ大会の最中もひたすら開発していて、僕らのチームだけ異様な空気を放っていたと思います(笑)。
@kobaryo:でも、その甲斐あって、プロトタイプを動画で見せる形で発表することができました。2日間でそこまで仕上げたチームは他になく、かなり注目してもらえたと感じています。ただ、これが実現できたのは、実は徹底した事前準備があったからです。
@phi:そこでは、私の過去の失敗経験が活きましたね。先ほどお話しした通り、思いのあるメンバーを集めても、何を作るべきかという要件定義が曖昧で、結局自然消滅させてしまった苦い経験があるんです。その反省から、今回は事前に課題や実現したいスコープをかなり具体的に詰めておきました。合宿当日は「ただ手を動かすだけ」の状態にできたことが、短期間でプロトタイプを完成させられた大きな要因だと思います。
「このままでは終われない」プロジェクト化の壁と経営層との対話
ー開発合宿での成功と、経営層からの後押しでプロジェクト化へ向けて動き出したのですね。
@kubomi:はい。「案は良いので開発合宿での成果を前に進めてほしい」という後押しもあり「では、やらせてください!」と。…しかし、ここからがまた長い道のりでした。
@phi:いざプロジェクト化しようとすると、大きな壁にぶつかりました。メンバーは有志の若手が中心で、皆それぞれの本業のチームとの兼務です。プロジェクトオーナーをどう立てるのか、QAや予算のリソースをどこから確保するのか、誰も正式な進め方がわかりませんでした。
@kobaryo:週次でミーティングを開催していたのですが「もっとこうしたい」というアイデアばかりが膨らんでスコープが拡散してしまい、一時は「もう、やめようか」という話にもなりかけました。また、リリース後の運用体制も大きな課題でした。僕らが勝手に作ったものを、既存のチームに「はい、お願いします」と渡すわけにはいかないですし。
ーボトムアップで進めることの難しさに直面したわけですね。その状況をどうやって乗り越えたのでしょうか。
@phi:そこにPMとして参画してくれたのが@yagさんです。彼がプロジェクトに加わった瞬間から、止まっていた歯車が一気に動き始めたような感覚がありました。
@yag:私が参加したとき、メンバーのみんなの熱意はすごいけれど、進むべき道が定まっていない状態だと感じました。そこで私がやるべきは、この「作りたい」という熱量を、どうすればお客さまに届けられるか、その道筋を整理することだと考えました。
具体的には、ボトムアップでの活動に限界があるなら、トップダウンの承認を得ようと、メルペイの経営会議に持ち込むことを提案しました。会社として正式なプロジェクトになれば、リソースやオーナーシップの問題も解決に向けて動き出します。
@kobaryo:この提案は、まさにブレークスルーでした。トップダウンで会社としての目標になれば、各方面のブロッカーが外れていきます。それまでは完全にボランティア活動で、上長から「本業もおろそかにしないようにね」と釘を刺されながらやっていたのが(笑)、正式に会社のロードマップに乗った。これは本当に大きな変化でした。
視座を引き上げた経営層からの問いかけ「10倍の価値を生み出すには?」
ー経営会議での提案は、スムーズに進んだのでしょうか?
@phi:役員の一人が、僕らの想像以上にこの機能改善に強い思いを持ってくれていたのが大きかったですね。「すぐに改善に着手してもらえますか」と、むしろ僕らが背中を押されるような雰囲気でした。
@yag:そこで忘れられないフィードバックをもらいました。僕らが持ち込んだのは、あくまで開発合宿で作ったプロトタイプレベルの改善案でした。それに対して、「その改修の先に何があるのか。お客さまにとっての価値を10倍にすることを考えてきてほしい」と言われたんです。
正直、頭をガツンと殴られたような衝撃でした。僕たちは目の前の「使いにくさ」を解消することしか見ていませんでしたが、もっと高い視座で、このプロダクトの未来を考えることを求められたのです。
@kubomi:さらに、「メルペイらしくやること」、つまり「私たちがやる意味」も問われました。単に他社の便利なアプリに近づけるのではなく、メルカリが持つアセットを活かして、我々だからこそ提供できる価値は何か。その問いのおかげで、議論は一気に深まりました。
普段の業務ではなかなかできない、プロダクトの根源的な価値や会社のミッションにまで立ち返って考える、非常に貴重な機会になりましたね。この経験を通じて、チーム全体の視座が格段に上がったと感じています。
メルペイだからできる価値交換の未来へ
ー多くの壁を乗り越え、ついにリリースに至ったわけですが、開発の最終段階でも苦労はありましたか?
@kubomi:はい。例えば、クライアント側では、最短でお客さまに届けるため、予定していたマイグレーション完了を待たずに旧アーキテクチャ上で実装する判断をしました。普段触らないコードの理解や影響範囲の検証に時間がかかり苦労しました。
@kobaryo:バックエンド側では、バージョンの異なるアプリ間での挙動の整合性を取るのに苦労しました。アップデート済みの人とそうでない人、送る側と受け取る側、その組み合わせで4パターンの複雑なケースを考慮する必要がありました。
@yag:リリース直前には法的な課題も見つかりました。改善後の仕様において、改善前の法的整理を維持できるかについての懸念が上がったのです。そのため、一時はリリースが危ぶまれましたが、リーガルチームが全力を尽くして改めて法的整理を行い解決策を見出してくれました。改めてメルカリのチームワークの強さを感じた瞬間でしたね。
ーそしてまず、QRコード送金機能、次に承認フローの改善がリリースされました。今後の展望について教えてください。
@kobaryo:短期的には、UI/UXのさらなる改善が必要です。デザインシステムを最新のものに揃え、誰にとっても直感的に使える状態を作っていきます。まずは、まだ十分に知られていない「メルペイでお金を送り合える」という価値を、しっかりとお客さまに届けることが目標です。
@kubomi:中長期的には、もっと広い意味での「価値交換」を実現したいと考えています。メルカリグループには、お金だけでなく、ポイント、暗号資産、NFT、さらには通信量(ギガ)など、多様なアセットがあります。これらを個人間で滑らかに「おくる・もらう」ができるようになれば、全く新しい体験が生まれるはずです。
@phi:僕は「使いやすさ」に加えて「楽しさ」も追求したいです。例えば、NFCでデバイスをタッチするだけで送金できたり、決済時のエフェクトに振動(ハプティクス)を加えて触覚でも楽しめるようにしたり。単なるお金のやりとりではなく、コミュニケーションがもっと楽しくなるような仕掛けを考えていきたいですね。
そして、事業としての成長も重要です。将来的には、この機能がメルペイの収益の柱の一つになるような展開も模索していきたいと考えています。
ー最後に、このボトムアップのプロジェクトを進める中で、皆さんが感じていることをお聞かせください。
@kobaryo:普段のトップダウンの業務とは違い、自分たちの「こうしたい」という気持ちを起点に、オーナーシップを持ってプロダクトを作れたことが何よりの経験です。そして、「10倍の価値」を問われたことで、会社のビジョンにまで立ち返って物事を考える面白さを知りました。
@yag:エンジニアの熱意を経営層がしっかりと受け止めてくれる、メルカリの懐の深さを改めて感じました。普段担当している金融領域とはまた違う、お客さまの体験に直接触れるプロダクトに関われたことも、大きな喜びです。
@phi:旗振り役として一度は失敗した経験があったからこそ、今回の学びは大きかったです。プロダクトへの思いは誰にも負けない自信があるので、この経験を糧に、また新しい挑戦をしていきたいです。
@kubomi:自分たちが「欲しい」と心から思えるものを、最高の仲間たちと主体的に考え、形にできた。本当に良い経験でした。このプロジェクトを通して、お客さまに価値を届けることの難しさと、それを乗り越えたときの喜びを、身をもって学ぶことができました。
この記事に関連する求人情報
募集中の求人の一部をご紹介します
-
Software Engineer, Web – US App
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
AI/Data Product Engineer – Mercari
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
Software Engineer, Cloud Networking – Mercari (Japanese Speaker)
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
Anti-Fraud Specialist / 不正対策スペシャリスト – Merpay
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
-
Senior IT Risk & Security Specialist – Merpay/Mercoin
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
-
Security Engineer, Threat Detection and Response – Mercari
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
Software Engineer, Backend – Mercari Mobile (モバイル領域新規事業)
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
Creative Director – Merpay
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
-
UX Designer – Merpay
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
-
Credit Control Specialist / 債権管理スペシャリスト – Merpay
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
別サイトに移動します
この記事に関連する求人情報
募集中の求人の一部をご紹介します
-
Software Engineer, Web – US App
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
AI/Data Product Engineer – Mercari
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
Software Engineer, Cloud Networking – Mercari (Japanese Speaker)
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
Anti-Fraud Specialist / 不正対策スペシャリスト – Merpay
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
-
Senior IT Risk & Security Specialist – Merpay/Mercoin
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
-
Security Engineer, Threat Detection and Response – Mercari
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
Software Engineer, Backend – Mercari Mobile (モバイル領域新規事業)
オフィス: 東京・六本木オフィス
会社・事業: メルカリ
-
Creative Director – Merpay
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
-
UX Designer – Merpay
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
-
Credit Control Specialist / 債権管理スペシャリスト – Merpay
オフィス: 東京・六本木オフィス
会社・事業: メルペイ
別サイトに移動します