CLOSE

パネルディスカッション(全2記事)

メルペイの立ち上げ時点でメルカードの構想はあった チーム立ち上げや開発の苦労、リリースまでの舞台裏

メルカードの開発舞台裏について、PJに関わっていたPMとBackendエンジニアとのパネルディスカッション形式で対話する「Merpay Tech Talk~PM、Backendエンジニアによるメルカードの開発舞台裏大公開~」。ここでPMのmanamin氏、ソフトウェアエンジニアのhiroebe氏、yuichi.shiwaku氏、uechoco氏が登壇。続いて、メルカードの開発・リリースの舞台裏について話します。前回はこちらから。

メルペイの立ち上げ時点でメルカードの構想はあった

t-iwamoto氏(以下、t-iwamoto):「2年間のプロジェクトを振り返ってみて」みたい(な話)になっていましたが、今回の開発を振り返ってPM観点で……。メルペイの新規ビジネスみたいなものとしてメルカードを出したと思うのですが、そのあたりの裏話的なことをちょっと聞いていきたいなと思っています。

初めに、なぜこのタイミングとか、なぜクレジットカードにメルペイは参入したのかみたいなところが、先ほどの説明資料だと抜け落ちていたかなと思っているので、何か話ができる方……。(この)話をしても大丈夫なのかな(笑)?

(一同笑)

manamin氏(以下、manamin):もういいんじゃないですか。

t-iwamoto:大丈夫ですよね。

manamin:舞台裏なので(笑)。

t-iwamoto:そんなところで、じゃあPMのmanaminさんからよろしくお願いします。

manamin:そうですね。私はメルペイの立ち上げの時からずっとジョインしてやっているんですが、2018年ぐらいの最初のメルペイの立ち上げの時からメルカードの構想はあって。今ちゃんとそのシナリオどおりに進んでるという感じですね。

なので突然やりたくなったわけじゃなくて、メルペイを作るに当たって、ロードマップの1つに、よりたくさんの人に使っていただくサービスとして(メルカードが)あったと理解しています。

t-iwamoto:はい。もともとロードマップ上あって、ようやくリリースできたねって。けっこう長い期間開発していたので、初めからもちろんロードマップ上にあって出してきたようなかたちですね。

PMとしてはメルカードの開発にすごくワクワクしていた

t-iwamoto:次です。またPMに対して(の質問で)、新しいクレジットカードを作れと言われて、しかも2名ぐらいで(進めないといけない)となった時の気持ちみたいな(笑)。どうでした? 「これやんの?」みたいな(感想とかありましたか)(笑)。

manamin:正直、私はすっごくワクワクしていました。自分で手を挙げて「やりたいです」と言ってアサインしてもらいました。なので、自分はすっごく作りたかった感じです。

それは(なぜかというと)、私はキャッシュレス(サービスの中)でメルペイの考え方がすごく好きでしたし、なかなか人生でクレジットカードを(仕事で)作ることはないと思うので(笑)。なのですごくいい経験だし、私はどうしてもやりたくて、すごくアピールしました(笑)。

t-iwamoto:確かに。クレジットカードを新規で出すようなことは、なかなかないですからね。

manamin:いや、ないですよ。人生で何人に出会えるのかという感じだと思います。

t-iwamoto:確かに。聞いたことがあんまりない。そうですね。はい、了解です。わかりました。

オンラインでの新規チーム立ち上げで気をつけたこと

t-iwamoto:では今度はBackend観点です。

shiwakuさんの初めの説明で、コロナ禍で完全オンラインでチームを立ち上げました、チームビルディングを行いましたよ、みたいな話があったと思うのですが、そこでメンバーがたまたまよかったところプラス、TL(Tech Lead)として気をつけたことが、きっとけっこういっぱいあるんじゃないかと思っています。

そのあたりの裏話的なところを聞ければおもしろそうだなと思っているのですが、どうですかね、shiwakuさん?

yuichi.shiwaku(以下、yuichi.shiwaku):そうですね。これについては自分もまったくの未知の経験でした。試行錯誤だったのですが、チームを立ち上げるまでのメルペイの他のチームの開発をやっていたり、関わってたりした中で、自分が完全リモートで働く時にストレスだったポイントを潰すことにはかなり意識を割いてましたね。

1つは、みなさんやっていると思うのですがメルカードのチームに関しては、毎日朝に声を出して会話をするタイミングを作るためのデイリースタンドアップを作るとか、ウィークリーや隔週……、まぁウィークリーかな。ウィークリーでPMも全員交えて進捗のタスクの棚卸しをしたりとか。そういった機会をできるだけオンラインで作ることは意識していました。

毎日雑談も含めて会話していないと、距離が読めない状態が生まれてしまうのはどうしても避けられないので、そういったところを意識していましたね。

メルペイやメルカリのエンジニアやPMはけっこう自走力がある人たちが多過ぎて、本当に安定したチームだと、朝会はSlackのスレッドに今日やることを書いて終わりみたいなチームもあったりするんですよ。

もともとお互いよく知っていて顔を合わせて働いていたチームが、オンラインの開発に移行するに当たってそういうふうに移行したというのは別に問題ないし、より効率がよくなるのだったらいいのかなと思うんですが、今回は新しいプロダクトだったので、直接コミュニケーションを取るきっかけ作りを意識していましたね。

t-iwamoto:はい、ありがとうございます。

声によるコミュニケーションは大事

t-iwamoto:せっかくメンバーのebeさんとuechocoさんもいるので、メンバー観点でどうでしたか?

uechoco:そうですね。確かに、途中からデイリーのスタンドアップを用意してもらって、(そこからは)けっこうコミュニケーションをよく取れたかなと思っているので、すごくありがたかったかなと思います。

わりとリモートだとテキストの会話が多くなりがちで、弊社だとSlack、チャットのツールでやり取りしたり、エンジニアだとGitHubのコメントでやり取りしたりするのが多いんですが、議論をずーっとテキストでやっても伝わらないこともあって。そこはビデオチャットを使うなど工夫したりすることはやはりあったので、声によるコミュニケーションは大事だったなとはと思いましたね。ebeちゃんはどうですか。

hiroebe氏(以下、hiroebe):そうですね。僕も同じようなことを思っています。例えばプルリクエストのレビューをしたりされたりというコミュニケーションは定常的に発生するのですが、そういうところで話したほうが早いことはけっこうあると思います。

uechoco:うんうん。ありますね。

hiroebe:実際によくあって、そういうところではちょろっとつないで「今話せます?」みたいな感じで話しながら進められたのは、進め方としてはうまくいったポイントなのかなぁと思いましたね。

t-iwamoto:はい、ありがとうございます。

マイクロサービスの開発で「えらい大変だった」こと

t-iwamoto:時間的にあともう1つぐらいかなといったところです。せっかくなので、技術的なところ・トピックみたいなところも1つ設けたいなと思っています。

クレジットカードのマイクロサービスを今回作ったというところで、メルペイの中で、他のマイクロサービスと違うことや、気をつけたことは何かありましたか?

yuichi.shiwaku:ここまでにも話があったのですが、メルペイだとiD決済というもともとあった仕組みが大いに参考になったというのが、Backendの設計上はすごくありがたかったです。

なので、最初の「こういうふうにしたらいいよね」というDesign Docとかアーキテクチャの設計は、それほど課題感はなかったんですよね。

ただ、やってみて「えらい大変だったなぁ」みたいなところで言うと、申し込みしてお客さまにカードを配送するという、これまで我々が提供してこなかったものを新しく開発するところが結果的にものすごく大変でした。

それを実現するためにアプリ側にも大きく変更(を加えること)や追加開発をしなきゃいけないし、メルペイ・メルカリはeKYCや本人確認の仕組みもすでに提供していて、そこを拡張したり使い回して今回実装する(ことになりました)。そういったところが当初想定していたのと違う、両方から外れて「あれ? ここはこんなに大変になるんだ」みたいなところが生じたなというのが実感としてはありますね。

t-iwamoto:了解です。やはり申し込みの部分ですね。説明の中でも出てこなかったのが申し込みの部分で、たぶんまだイマイチみなさんわかっていないかもしれないので、もう少し深掘りして話せますかね? どこまで話せるのか、話していいのかがちょっと微妙かもしれないですけど。

例えば、今回物理的なカードを配送するようなところがあったと思うのですが、そこも全部アプリの中で完結しているわけじゃないですか。

そういうのも含めてけっこう大変だったんじゃないかなと思っています。そのあたりで工夫した点、工夫というか大変だった点、ハマった点みたいなのがあれば。

yuichi.shiwaku:そうですね。今回は新しいマイクロサービスだったので、クレジットカード専用の、メルカード専用のマイクロサービスにしたことで、例えばiD決済などの既存のものを拡張して実現していった場合、そういった配送通知(を画面から)どう飛ばすのかとか。アプリ上での見え方で、既存のAPIを拡張していたりすると、そういった申し込みや配送状態や再発行といったコミュニケーションを取るAPIのデザインがこんがらがっちゃったりすることが発生しちゃうんじゃないかなと思います。

しかし、結果的には分けていたので、メルカードの要件がどんどんアプデ(アップデート)されていくのに追従して開発を切り離して、他のサービスへの影響を出さずにメルカードの開発のみに注力できたところはあるかなと思いますね。

t-iwamoto:はい、ありがとうございます。こちらで時間になりましたので、一応パネルディスカッションはこれで終了とさせていただきます。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!