Merpay & Mercoin Tech Fest 2023 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2023年8月22日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
記事は、「発行枚数100万枚を支えたメルカードGrowth施策の裏側」の書き起こしです。
@kazuya：「発行枚数100万枚を支えたメルカードGrowth施策の裏側」のセッションを開始します。セッションは3名の異なる職種のメンバーでお送りします。よろしくお願いいたします。
@kazuya：私はKawashimaと言いまして、メルペイでPMをしています。
@ksoichiro：メルペイバックエンドエンジニアのKashimaと申します。2019年にメルペイに入社し、Growth Platformチームでプロダクト開発を担当しています。よろしくお願いします。
@mikael：iOS Tech LeadのMikaelです。2019年に入社しました。今までメルカリアプリの支払いタブなどを開発しました。よろしくお願いします。
@kazuya：私がメルカードプロジェクトのPM、@ksoichiroさんがバックエンド、@mikaelさんがiOSエンジニアです。今回は3名でお送りします。
@kazuya：セッションのタイトルにもあった「メルカード」について、私から説明します。
メルカリアプリに「メルペイ」というスマホ決済サービスが追加され、メルペイの中には、メルペイスマート払いという、あと払いのスマホ決済サービスを展開していました。
2022年11月に、「メルカード」というメルカリが発行するクレジットカードをリリースしました。メルカードはメルペイスマート払いと同じ与信を使っているので、すでにあったメルペイあと払いを拡張したサービスとなります。
メルカードは、2022年発行で、比較的後発であるからこそ、メルカリとしてどういったクレジットカードがいいのかを、いろいろなメンバーと議論してサービスを設計しました。その中での大きな特徴として、「メルカリでのお買い物においてお得」ということは非常に重要です。
メルカリ内でアクションをとると、お買い物がお得になっていき、最大4%還元までレベルが上がっていく設計です。
続いて、メルカードの特徴について説明します。
Point1として、本人確認をすでに終えている方が1000万人以上いらっしゃいます。彼らはとても簡単にアプリ上で申し込みが完了します。
Point2としては、アプリ前提のクレジットカード体験を、ゼロから設計しています。例えば、スマホ決済と同じく、決済後すぐに通知が飛ぶ設計になっています。
クレジットカードの場合、アプリはあるけど、明細に反映されるのが数日後になり、利用状況がタイムリーにわからないこともあると思います。その点、メルカードはクレジットカード・iD決済・コード決済のあらゆる決済ですぐに通知が来て確認できるというシームレスな体験を実現しています。
Point3は、使った金額をいつでも清算できることです。例えば3800円のお買い物をしたときに、翌月末まで待つのではなく、今の時点で支払いたいときは支払いを済ませて管理をしやすくすることが可能です。
Point4は、AI与信です。クレジットカードを日本で作ろうとすると、年齢、職業、会社の勤続年数、年収などの情報が必要だと思うんですけれどもメルカリやメルペイの利用実績に基づいてAI与信をすることで、そういった属性情報の入力が大幅に省略できます。
11月の発表後、約半年で100万発行を達成しました。これは国内のクレジットカードとしても、トップに入る規模発行数になっておりますので、その点に関してはうまくいっているかなと思います。
参考記事：「メルカード」、提供開始から約半年で発行枚数100万枚突破
ここで、メルカリ/メルペイのカルチャーについて紹介します。メルカリでは、社内外の方に対して多様性を大事にしたいと思っており、メルカードという言葉にもその意味を込めています。
また、リサイクルPVCというエコな素材を用いていたり、色が変化するメルカリのHologram logoを載せたりと、ダイバーシティ&インクルージョンという考え方でデザインされています。
ここで、本題である「グロースをどのようにエンジニア含めて実現したか」という話に入ります。
一番大事なのは、メルカリが発行したクレジットカードなので、メルカリを使う中で自然と「メルカードを作ろう」と思っていただける体験です。
例えばホーム画面やチェックアウトのフロー、商品詳細で訴求をすると言ったように、メルカリの機能に対してもインテグレーションしました。キャンペーンも実施し、マーケティングとプロダクトが連携しながら進めてきました。
参照
メルペイ、「メルカリ」や「メルカード」などの利用でおトクな特典を受けられる「メルカリご利用特典」を提供
メルペイ、「メルカード」の新規入会で「メルカリ」でのお買い物が最大半額になるご利用特典と新TVCMが6月1日より開始
@ksoichiro：私からはグロース施策における体制について説明します。
まず一つ目に、必要に応じてメルカリとメルペイを横断して体制を組んでいます。
続いて、プログラム体制です。メルペイ内部の開発体制は、プログラム体制というバーチャルな組織体制が採用されています。一つ一つの箱がプログラムと呼ばれており、主要なカスタマージャーニーの単位で分けられたJourneyの他に、Foundation、Enablingなどの組織に分けられています。これとは別に通常の組織図に基づいたレポートラインもありますが、そもそもPM組織・エンジニアリング組織とわかれているので、実際の開発はこれらが一緒になって、チームやプロジェクト体制が組まれていきます。
プログラム体制におけるプログラムには複数のチームが含まれ、開発スケジュールが競合するとリソースの調整が発生してしまいますが、プログラム体制においてはまず、プログラムの中で調整するのが基本的な手法です。
メルカードのグロース施策に特に関わりが深いのは、Loyality Program / Payment journeyとGrowth Platform。この場にいる3名においても、2人はLoyality Program / Payment journeyに属していて、私はGrowth Platform所属です。
Loyality Program / Payment journeyには、メルカードそのものや各種決済における体験後は使っており、Growth Platformはグロース施策に必要となるポイント還元やキャンペーン訴求のための仕組み、メルカードにおける還元率の管理などを扱っています。
マーケティングの施策では、OKRをもとにそれぞれ締め切りが設定されてきます。基本的にはそれに基づいて開発スケジュールを計画・進行します。プロダクト開発のメンバーが複数の施策に関わっていくこともありますので、スケジュールが競合し、技術リソースの調整が必要になることもありますね。
これらに関わるメンバーは、特定の職種だけでなく、PMやマーケター、デザイナーなど、総動員で関わってきます。以上が推進体制の基本的な説明です。
@kazuya：メルカリ/メルペイと会社をまたいだり、メルペイの中でもいろいろなプログラム体制があったり、マーケットも協業してしていたりするという説明でした。
@mikael：メルカード関連でよく使ったツールを紹介します。JIRAとBrazeです。
JIRAは、私たちの会社で使用しているプロジェクト管理ツールです。私たちのチームでは、全員が全ての機能を見られるように使用しています。
もし、プロジェクトマネージャーが新しい機能を開始したい場合は、EPICを作成します。さらに、新しい機能における各メンバーごとのタスクを作成します。これにより、バックエンドエンジニア、モバイルクライアントエンジニア、そしてデザイナーも、現在の機能の状態を追跡することが可能になります。
JIRAのようなツールでは、多くの自由があります。私たちがこれらのツールを使用する際のアプローチは、使いやすく読みやすいようにシンプルに保つことです。
例えば、サブタスクの作成は避けます。また、EPICが大き過ぎるか、時間がかかる場合は機能を複数のEPICに分割して、誰にとっても管理しやすくします。
Brazeは、お客さまに表示する内容を変更できるようにするためのツールです。私たちの場合、Brazeはマーケティングをキャンペーンのエディタとして活用しています。マーケティング担当者やプロジェクトマネージャーがWebポータルを通じて、複雑なキャンペーンを簡単に作成・編集できます。
AndroidやiOSでこのようなキャンペーンを実施するためには、バックエンドエンジニア、デザイナー、PMと協力して、私たちのニーズに答えるものを作成する必要があります。最新のキャンペーンでは、商品価格をベースにしてクーポンなどの特別のオファーをお客さまに提案することができます。
SwiftUIで作成されたUIのセットアップ等をカスタムBraze枠によって、マーケティング担当者は情報の提示方法や計算方法を選択できます。例えば500円引きという固定された割引だけでなく、ある限度額までの商品価格に対するパーセンテージを提示することもできます。
@kazuya：マーケターが、キャンペーン中であっても、訴求をA/B Testできたり、様々な運用しやすくするためにもこういったツールを活用しています。
ツールを活用していくわけなんですけれども、Kashimaさんからは、バックエンドチームとして、さまざまなタスクがありながらキャンペーンなど、グロースを支えるための機能を作っていくというところの話をしていただこうかなと思います。
@ksoichiro：ここからは、バックエンド開発について説明します。グロースに関わる開発は、いろいろなものが並行して動いています。私はGrowth Platform チームの一部でTech Leadを務めていますが、それでも全部に関われている訳ではありません。そのため、この場では私が関わったものについて、具体的な事例をいくつかお伝えします。
一つ目はキャンペーンのための開発で、特定のキャンペーンスキームに合わせて対応するときの開発です。二つ目はプラットフォームの開発で、これは私が所属するGrowth Platformのメインの領域です。ポイント還元やキャンペーン訴求などのグロース施策を実行する上で必須になるような仕組みを作るというところです。
一つ目のキャンペーンのための開発も、何度も使うことが想定されているものであれば仕組み化が求められます。
最後はプロダクトのコア体験を作る開発です。例えば還元率がどのように上下するのかを決める仕組みは、細かい仕様が広い範囲の体験に影響しますし、キャンペーンなどの施策がなくても、日々改善して提供していく基本的な部分なので、別の枠として整理しました。
その上で自分が担当してきたことについて、関係するPMの方とどう関わってきたかにも触れつつ振り返ります。
スライドに載せているのは、私が関わった開発の事例の一部です。
一つ目のお得枠は、メルカリアプリの支払いタブの中にあるキャンペーン訴求を表示するエリアのことです。この部分にマーケターや、PMが運用できるような仕組みというのを用意しています。この前身となる類似の仕組みを数年にわたって運用してきてたので、私も担当のPMも知見を持っていて、その上で今後の利用予定をある程度見据えながら設計して準備しました。
二つ目は、入会特典の1000ポイントの付与です。メルカードを作ると1000ポイントもらえるという施策がリリースの当初からあります。
「ポイント付与精度の向上」は当たり前じゃないかと思われるかもしれません。ですが、このタイミングで新しい仕組みを使うという取り組みがあって、そのためにエンジニアリング的な努力が必要になりました。これはその後の大型キャンペーンの運用にも生きる取り組みだったのかなと思っています。
三つ目の特典ページはメルカードのために作られた還元率や特典を確認できるページのことです。私はその開発の初期から関わっていて、ここに関わるPMは1人ではなく、それぞれの施策担当する方と仕様検討しながら進めてきました。初期から数えるとおそらく7、8人は関わっています。
最後の還元率の管理についてですが、メルカードのリリースに向けて開発した新しい取り組みなので、トラブルもありました。メルカードを使い始めたお客さまにおいては、還元率がサクサク上がる体験をおそらくしていただけているんじゃないかなと思います。しかし、逆に意図せず還元率が落ちてしまう悪い体験も起きていて、それを防ぐための対策をとってきました。
こういうときに実際のデータを見ながら、発生しているパターンや件数を細かく分析するのですが、中には判断が難しいものもあり、そのときはPMと相談してステークホルダに説明することが必要になりました。
以上が私が関わった開発の一部です。振り返ってみると、リリース前から仕込んできたものの役割が大きいなと思います。計画的に積み重ねてきた土台があるからこそ、低コストで運用ができて、結果として新しい施策にも手を出せるという状況になっているのかなと思います。これはGrowth Platformチームの成果とも言えるのかなと思っています。
それからPMとの連携というところに関しては、バックエンドエンジニアは基本的には担当するマイクロサービスに対し長く関わっているので、該当の機能についてPMと同じかそれよりも詳しいこともよくあります。
それを踏まえてなるべくPMの目線を理解しつつ、一緒に自分事として関わっていくのか大事だと思います。
それから、体制の説明でも触れましたが、結構な数の施策が並行して進んだり、期間が短くても仕様を変えなければならなかったりします。
その中で変更のサイクルを早く回すには、エンジニアが技術面だけでなく体験面にも関心を持って仕様に口を出したり、インシデントが起きないようにエッジケースも注意しながらコミュニケーションを取ったり、ボールが落ちないようにプロジェクトマネジメントにも積極的に関わったりするのも重要だったんじゃないかなと思っています。
@kazuya：最後に、質問しつつ3人で話していきたいなと思います。
まず、グロース施策を行うときは、数字を達成するために急ぎのタスクが発生することもあります。そのときに、エンジニアとしては他のことをしていることもあると思うんですけれども、どのように受け止めていますか。
@mikael：そうですね。クライアントエンジニアから見ると、バグのfixやリファクタリングをしたいです。一方で、OKRを考えなければならないので、OKR関係のタスクを高いプライオリティにしなければならないと思います。バグのfixやリファクタリングのタスクがあれば、別のOKRを作って対応します。
@kazuya：会社全体の目標（カンパニーOKR）を掲げて皆さんが日々コミュニケーションを取っていることが一つの要因になっているのかなと思いました。
@ksoichiro：エンジニアリングの目標も並列にありますが、ビジネス目標は優先しなければならないので、エンジニアリングの目標は後回しにしなきゃいけないこともありますね。
エンジニアリングのOKRを一緒に立てて並べて、どっちを優先するみたいなのをクォーターごとに決めることで、うまく成り立っています。
@kazuya：続いて、自分たちがやりたいことがある中でもビジネス目標があるという状況で、どのようにモチベーションを維持していますか？
@mikael：開発者として開発をする際にテクニカルチャレンジがあるときに、楽しい気持ちになるので、それを大切にしています。
例えばメルカード関係のフィーチャーを作るときに、お客さまを考えながら作りますね。PMが全て決めることでなく、エンジニアも考えないといけないことがたくさんあるので、そこでモチベーションが上がります。
@ksoichiro：一つ目の話にも関係しますが、クォーターの最初で、計画が全部決まっていることはなくて、途中で変わることもあるので、やりたいことができないときもあります。でも、私自身いろいろな施策に関わり、プロダクトの成長に直接的に貢献できているということ自体がモチベーションにはなっています。
@kazuya：以上、こちらのセッションは、3人でお送りいたしました。皆さん、ご清聴ありがとうございました。
