2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
t-iwamoto氏(以下、t-iwamoto):今からはパネルディスカッションのかたちで、事前に受けている質問や、こちらで想定している質問を紹介しながら、みんなでワイワイしていこうかなと思います。
初めに、参加者の方から事前に質問を受けているので、そちらからやっていこうかなと思っています。続々とTwitterやコメントから質問がきているので、それも紹介しながらやっていこうかなと思います。
参加者からの質問で「PMのミッションと具体的(な)仕事内容ってどんなことをやっていますか」とあるのですが、そちら(の回答者)はmanaminさんですかね(笑)?
manamin氏(以下、manamin):あはははは、すごい直球ですね(笑)。PMのミッション。そうですね。これはメルカリ・メルペイグループ(の中)で特にメルペイについて話しますが。
メルカリ・メルペイグループのプロダクトマネージャーは、「プロダクトマネージャーだからこれをしなくてはいけない」みたいなのはあまりなくて、けっこういろいろなところに出没して、いろいろな人と話してみたいなことをやっています。
ミッションは、私のミッション(が何か)ということなんですかね。まず、(私の場合は)メインプロダクトマネージャーが私ともう1人マネージャーしかいなくて、主に2人でやっていたので守備範囲が広過ぎたんですけど(笑)。本当に本当に広かったんです。
私がやっていたことは先ほど話しましたが、プロセッサや、それこそJCBのブランドさん、あとはカードを発行する会社さんなど、いろいろな会社のパートナーの方とお話ししなければいけませんでした。
そのためには、「メルペイはこういうクレジットカードを作りたいんです」ということを説明していって、それに合わせてカスタマイズしてもらったり、業務を推進していかなければいけないところが主なミッションだったかなと思っています。
私としては外のパートナー側との折衝だけじゃなくて、メルカリ・メルペイ内にも同じような動きをしなくてはいけなくて。単純に言えば、要件整理と仕様を作らなければいけなかったんです。既存のサービスがあるので、そこに対してどういう変更を加えるのかを我々で要件定義をして、そこで「お願いします」と頼んで回るところをやっていましたね。
先ほど話しましたが、それだけだとプロジェクトが回らないので、プロジェクト管理みたいな(こともやっていました)。私は本当にざっくりしかしていないのですが、マイルストーンやQAの調整など、そういう他のチームとの調整やスケジュール管理も最後のほうはしていました。
具体的な仕事内容もこれで答えられたんじゃないかなと思いますが、本当に“ゆりかごから墓場まで”じゃないですが……。墓場ではないですね(笑)。“種から花まで”みたいな。(種を)育てるまで。農園経営みたいな感じですが、もはや大きくなり過ぎて、いろいろなことをやっています。
t-iwamoto:実を言うと、この規模感のプロジェクトに対して2人のPMで回すのは、なかなか見たことないなと私も思っていたんですよね(笑)。そこらへんは何か。
manamin:そうですよね。私も見たことがなかったです(笑)。
t-iwamoto:何か工夫したり、効率的なことを考えたり。進め方の上で過負荷になったときどうやって(進められていたのか)。しかもmanaminさんは(そんな中でも)けっこう家族も大切にしていて、(そばで)見ていてすごいなと思っていたんですが(笑)。そのあたり、何かコツがあるんですかね?
manamin:そうですね、コツはないです。もうたぶん、(その時は)回っていなかったと思います(笑)。私のモットーとしては「退勤したらもう働かない」というのがあるので、だいたい6時半ぐらいに上がって、土日も働かないという生活をしていました。
それでもオンスケ(オンスケジュール)で進められたのは、ここにいるメンバーの方が自立していろいろ進んで考えてくれたり、やってくれたりしたからで、私1人の力ではなかったかなというのはすごくあります。
t-iwamoto:はい。ありがとうございます。
t-iwamoto:次にBackendに対しての質問がきていますね。「これまでで一番大変だった開発経験をお聞きしたいです」という質問です。「これまでで」と言うと広いので、メルカードの開発に対して大変だったことを、Backendエンジニアが3名いるので、みなさん一言ずつお話を聞きたいなと思います。では初めにebeさんからいきますか。
hiroebe氏(以下、hiroebe):そうですね。僕がメルカードの開発に関わって大変だったのは、クレカ特有の決済パターンの多さです。
自分はもともとネット決済の開発をやっていたので、仮売上・実売上みたいな概念はもともと知っていたんですが、決済処理をやっていると、それに増してクレカ特有の決済パターンでかなり複雑なものがあって。「これがこの順番できたらどうなるんだ?」とか、「くるはずのものがこなかったらどうなんだ」とか、いろいろ考慮すべきことがあって、個人的にはそのあたりが一番大変だったかなと思いますね。
t-iwamoto:ありがとうございます。では次にshiwakuさん、よろしくお願いします。
yuichi.shiwaku(以下、yuichi.shiwaku):はい。(質問でいただいている)開発と言っていいのかどうなのかというところはあるのですが、今回メルカードの開発に携わって一番大変だったのは、実はコロナ禍に入って完全新規のプロジェクトを立ち上げるというのが、自分はこれが初めてだったので、そこのところ(が一番大変だったところ)です。
しかも、関係するメンバーがPMのmanaminのボスであるマネージャーしか知っている人がいなくて、それ以外のメンバーは全員初めて一緒に仕事する感じだし、今回参加してもらったuechocoさんは、自分が関わり始めてから「誰が一緒に働いてくれるんですか?」という質問をした時に「新しく入ってくる方をアサインします」と言われて。いったいどうなるんだろうと思いました。
しかも直接会うことがなかなか難しい、まだワクチンの接種も始まっていなかったタイミングだったので、そういった中での立ち上げというところで、お互い知らないところからどうコミュニケーションをとっていこうかと模索していくのは、最初は特に大変だったかなというのが強く印象に残っていますね。
結果的にというかたまたま運が良かった部分は、メンバー全員がかなり自立的に立ち回ってくれる感じだったので、回らなくなっていたりするとサポートに入ってくれるというところが、リモートでもうまく機能した、かなり助かったというか、良かった部分です。
これをもう1回やれと言われたらうまくいくかどうか……。「(うまくいくかどうかは)運かな?」というところなので、参考にはならない気がしています。というところがちょっと大変でした。
t-iwamoto:ありがとうございます。最後にuechocoさんお願いします。
uechoco氏(以下、uechoco):そうですね。似たような答えになってしまいそうな感じがします。もしかしたらその質問をしてくれた方は、技術的な大変なことを聞きたかったのかなと思いました。
メルペイ事業は長く実はもう何年かやっていて、社内のいろいろなマイクロサービスなどでノウハウが蓄積されています。例えばiD決済と今回のクレジットカードは、決済の内容としてはけっこう似ていて、かなり近いものを実装するところでいうと技術的には知見があったので、新規の大変さは技術的にはありませんでした。
(大変だったのは)やはり仕様理解ですよね。先ほどebeちゃんの話にもありましたが、仕様理解が一番大変で。クレジットカードならではの用語や仕様、商習慣などといったものがすごく古くからずーっと行われて存在していて、後から読み込んでもやはりなかなか理解するのが難しいものを1個1個紐解きながらやっていくのが大変でしたね。
みんなが素人だったらちょっと危ないプロダクトになってしまうので、先ほどshiwakuから説明があったように、間にプロセッサというクレジットカードの知識が豊富な会社さんを挟んでやり取りをしているので、決して危ないプロダクトを作っているわけではぜんぜんないんですが、それでもやっぱり理解の難しさはずっとありましたね。
manamin:めちゃくちゃムズかったですね(笑)。どんどん次から次へカードの仕様が出てきて。いやぁ、30年の歴史があるサービスは違うなぁと思いました(笑)。
uechoco:仕様書の量をあまり細かく言うことはできないのですが、とんでもない量の仕様書があって、それをみんなで読まなきゃいけないというのは、けっこう大変な思い出でしたね。
yuichi.shiwaku:そうですね。
t-iwamoto:それが最新化されているかどうかもまた別の点があるので(笑)。
uechoco:そうですよ。でも最新の仕様書がよく届いたりはするんですよね。なので、意外と日々アップデートはされてはいるみたいですね。
t-iwamoto:はい、了解です。わかりました。
t-iwamoto:あっという間に時間が過ぎていっちゃうんですけれど(笑)。何点かTwitter上からもコメントがきているので、こちらが用意した質問より、そちらを優先していこうかなと思っています。
初めに質問よりの感想みたいなところで、「決済基盤をどうやって管理しているのか気になる」ということです。「大きくなり過ぎて変更が入りづらいよね」みたいな質問もきていますが、決済基盤(の担当)がこちらのチームではないので、しゃべれる範囲で話していきましょうか。こちらは誰が詳しいですかね。shiwakuさん?
yuichi.shiwaku:そうですね。「今の決済基盤どうなってるの?」みたいなところは、たぶん(メルペイに)要望を出してイベントを企画してもらえばより詳しい話が聞ける(ようになる)んですけど。
今回、メルカードのチームが関わるに当たって、どういう状況になっているのかを軽く説明させてもらいます。先ほどもあったとおり、ebeちゃんはネット決済をやっていて、我々のチームはペイメント、決済基盤とけっこう長く付き合っています。
決済基盤の基本的な設計は、カード決済などのほとんど共通の振る舞いをAPIとして提供してくれていれば、カード決済やコード決済でもカバーできるようになっています。
そのAPIの設計はすごくよくできていて、もともと作っ(てあっ)た、最初のメルペイをリリースした時の設計がよかったという一言に尽きるのかなと思うんですが、iD決済なども最初から提供できていた部分で考慮されていたところですかね。
なので、メルカードやコード決済、ネット決済からすると、そういったもともとあった決済が利用しているAPIを、例えば「リアルカードの決済ですよ」と示すフラグなどのちょっとしたものを拡張することで、今回は実現できました。
今の決済基盤はそういったかたちです。なので、実はリリース当初からの管理でうまくなんとか実現できています。
t-iwamoto:はい。ありがとうございます。実は決済基盤回りだけでイベントができるぐらい、もっともっと大きな話ができるとは思います。
我々のチームは決済基盤を使っているマイクロサービスなので、深くまで話し始めると止まらないかなと思うので、(決済基盤の話は)これぐらいにしようかなと思っています。
ちなみに、決済基盤も1つのマイクロサービスではなくて、そこに枝分かれしたようなたくさんのマイクロサービスがついています。個々のマイクロサービスで開発を進めていくので、1つの大きい開発基盤みたいなかたちではないイメージです。
t-iwamoto:では次の質問で、「こういうのはGMOなりStripeなりのpayment gatewayみたいなとかを使うんですかね?」というものです。あとは「銀行のAPIとかを使っていますか」みたいな質問がきています。こちらは誰が一番詳しいかな?
uechoco:一応私が(担当していたので)一番詳しいですかね。payment gatewayという言葉の指し示す意味を共通用語として捉えていいのかわからないんですが、恐らく決済代行会社みたいな意味なのかなと思っています。
先ほどから何度かキーワードがありましたが、プロセッサ企業を間に挟んで(いるので、)他の会社が関わっている、協力会社があることは間違いないのですが、payment gatewayというかたちで代行してもらっているわけではありません。
カードの発行やカードの番号の取り扱い、それからカードのネットワークの接続、内容のメッセージの解釈をプロセッサの企業にやってもらって、それをメルペイにとって扱いやすいかたちのAPIに変換してやり取りをしているかたちになってます。
なので、なんて言ったらいいんでしょう……。イシュイングシステムみたいなものを提供している会社さんを使っているという回答になるかなと思います。
t-iwamoto:はい。ありがとうございます。
manamin:だいぶカスタマイズしていますけどね(笑)。
yuichi.shiwaku:そうですよね。
manamin:本当にだいぶカスタマイズして作っています。
t-iwamoto:そのやり取り系(の話)もまたお話できればいいですね。きっといっぱい苦労話があるのではないかと思っているので。
t-iwamoto:ちょっとPM寄りな質問がきているので、こちらも紹介させてください。「やりたいことが今の法律的にできないなどの問題はなかったのでしょうか」みたいなところで、「そういった調整はどのように進めましたか」という質問がきています。こちらmanaminさんですかね?
manamin:ありましたねぇ(笑)。メルカードのチームでコンセプトを作るんですが、それに対してこういうリーガル的な懸念がある。先ほどのシステムの話でいえば、セキュリティ的な懸念があるようなことは、1個ずつ担当部署と話していきます。
リーガルに関しては外部弁護士事務所まで巻き込んだり、クレジットカード協会などにアドバイスを貰ったり、そこまで広げて「本当にやりたいことができるか」という確認をしていった感じです。
t-iwamoto:はい。ありがとうございます。
t-iwamoto:時間的にあと1個ぐらいかな。あっという間ですね、ほんとに(笑)。最後にQAに関してですかね。「初めてのクレカ発行で、クレカ特有のシナリオをどうテストしたのかを知りたいです」みたいな質問がきています。
実はこの2日後、3月17日に実はQAでの裏話みたいなものがあるので、もし興味があるのであれば、そちらのイベントも聞いてもらえればなと思います。
uechoco:簡単に質問に答えると、今回メルカードはJCBさんと協業して一緒にやっているので、JCBさんのサポートを受けてクレカ特有のシナリオもいろいろと網羅性も確認してもらいました。
また、先ほど言っていたプロセッサの企業さんもクレジッドカードの豊富な知識があるので、そこのノウハウも加えていろいろなシナリオをチェックしたというのが簡単な回答になります。詳しくはQAのパートでお話しできるかもしれません。
t-iwamoto:はーい、了解です。わかりました。質問は一段落したかな。というわけであと10分くらい(余裕が)あるので、随時(質問は)いただければなと思います。
(次回に続く)
2024.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05