「不確実性の解消と同時に、チームの文化が醸成されていったんです」

そう話すのは、メルペイの信用事業を担当するCredit DesignチームのBackendエンジニアである小川雄大（@fivestar）とQuality Assurance（品質保証、以下QA）エンジニアの櫻井みづき（@miisan）でした。

2019年2月にリリースしたiD決済機能を皮切りに、コード決済やメルペイスマート払いなど続々と世の中に送り出してきたメルペイ。その裏側には、開発メンバーの強い連携があります。

しかしながら、最初からすべてスムーズだったわけではありません。そこには、いろいろな紆余曲折があったようで…？

※撮影時のみマスクを外しています

メルペイ開発のボトルネックだった「プロジェクトの不確実性」

@miisan：いきなり私から質問をしてしまうのですが、そもそもBackendエンジニアがメルペイのプロジェクトにどう関わっているのかを聞いてみたいです！

@fivestar：サービスの成長にあわせて変化してきた歴史がありますね。

前提として、私は以前までメルカリCorporate Engineeringチームで社内向けプロダクトを開発していました。そして2019年にメルペイへ異動。当時のCredit Design（以下CD）チームは今よりも少人数でした。それこそ、チームとしての文化を確立しようとしていたところだったんですよね。そこへ「メルペイスマート払いの定額払い機能を開発する」という、チームの規模に比べて大型すぎるプロジェクトが立ち上がりました。

定額払いを無事にリリースするため、採用や社内から協力してくれるメンバーを募りながら開発していくことになります。そうすると、初期から関わっていたメンバーと新メンバーの間で「解像度のギャップ」が発生。進め方にもズレが出始めていました。

小川雄大（@fivestar）

@miisan：その問題はどうやって解決を？

@fivestar：問題意識はみんなが持っていたので、チームの振り返りや反省会を細かく実施しました。そのなかで感じたのは、プロジェクトの不確実性。開発が後半になるにつれ、仕様の不整合が多く見つかる傾向があったんです。

そのため、PMを巻き込んでプロジェクトの前半でいかに不確実性を潰せるかを検討し始めました。最近では、要件を整理するフェーズからエンジニアとPMが密に連携を取り、両者が仕様を確定することに最大限責任を持つ体制を確立。サービスとしての振る舞いが正しいかどうか、技術的な実現性があるかどうかを確認しながら設計・開発するようになっています。

同時に、PMやエンジニアだけでなく、QAエンジニアやビジネスサイドのメンバーも早い段階で巻き込み、不確実性をなくすための動きも徹底しました。おかげで、多くのメンバーと協力しながらサービス運用をする姿勢が「CDチームの文化」として根付きました。

不確実性の解消と同時に醸成された、チームの文化

@miisan：私は、定額払い機能を期日までにリリースさせるためにCDチームへ異動してきました。当時のQAチームはプロジェクトのスピード感やスケールに追いつけていない状態で、QAとしてのバリューを最大限発揮できていなかった印象でしたね。チーム規模も今より小さく、目の前のタスクに追われてしまい、常に逼迫していました。

不確実性をゼロにすることは難しいですが、QAフェーズで見つかってしまう新たな問題はリリースに大きな影響をもたらします。だからこそ、QAチームからもその不確実性を減らせるような関わり方や発信ができるように、チームビルディングしていきました。最近は、チームみんなで意見を出し合い、考える時間を持つことで、新たな大型プロジェクトが舞い込んできても「まずは不確実性を潰す」ための議論を当然のようにできています。お互いの動きをフィードバックし合えるのは、とても大事な文化ですね。

@fivestar：そして、お互いをリスペクトする文化もあります。私は、チームにおいてQAエンジニアは重要な位置を占めると思っています。メルペイではQAチームがしっかりしてくれているから、クオリティの高いサービスを出せている。

先ほど話したプロジェクトの不確実性は、QAエンジニアのみんなにしわ寄せが行きがちでもありました。定額払いも、@miisanさんをはじめとしたQAエンジニアのみんなが苦労している姿を見ていたので…。CDチームみんなで不確実性に向き合おうとしたとき、@miisanさんがQAチームをリードする立場として改善アイデアを出してくれたことはとても心強かったです。

@miisan：常に不確実性とプロジェクトの進行がトレードオフみたいで…気になっていたんですよね（笑）。例えば「こんな問題が起きそうだが、リリース日はズラさずに進行してほしい」といった相談事が何度も起きていました。しかし、決済サービスとして品質を下げることはできません。それぞれの事象に対して妥協点や解決策をチームに提示し、リスクマネジメントしながら進めることでそのトレードオフを成立させていた感じです。

櫻井みづき（@miisan）

@miisan：QAは「テストすること」が本筋と思われがちですが、できることはもっと広く、多岐に渡ると思っています。PMによる仕様書に対して「こうしたほうがいい」など話し合えたほうが手戻りも少ないですし、何よりお客さまに一番近い立場にいるQAからのフィードバックはプロダクトの精度を高めると思っています。QAエンジニアはサービスや機能全体の仕様を把握できているので、メルペイとしての優先度をつけながら話し合いをしていた記憶です。

先ほど@fivestarさんは「不確実性のしわ寄せがQAに集まっていた」と話していましたが、当時はもうやりきるしかない感じだったので常にいろんなチームのメンバーと連携しながら爆速で対応していました。でも、このときからみんな協力的だったので、QAエンジニアとして力を発揮できていました。感謝しています。

@fivestar：みんな、ちゃんと進行するためにいい意味で戦友になっていましたよね。一緒に乗り越えた経験を持つところは、スタートアップらしいというかなんというか（笑）。

QAエンジニアの仕事は、証明するのが難しい

@miisan：メルペイで開発していくなかで、一番難しいと感じたことはありましたか？

@fivestar：メルペイへ異動したときに掲げた目標に「チームをリードするエンジニアになる」があります。そのためには、メンバーから信頼されることが大事だと思っていました。異動したばかりのころのメルペイには面識がある人はほとんどいなかったので、誠実な仕事を積み重ねて、信頼を得るためにいろいろチャレンジしましたね。自分とは異なる役割を持つ人たちと丁寧にコミュニケーションしたし、チームの課題も一つずつ取り除いていきました。

メルペイの人たちって、一人ひとりがとても優秀でポテンシャルが高いんですよね。難しかったところを挙げるなら「優秀なメンバーに囲まれながら、自分のパフォーマンスを発揮するにはどうすればいいか？」と考えたことでしょうか。発言にはいつも以上に気をつけましたし、一人ひとりのモチベーションを上げながら文化をつくることに試行錯誤した日々でした。とはいえ、苦労はあれど総じて楽しく仕事ができているので「辛かった」とはあまり感じていないですね。単に、感覚が麻痺しているだけかもですけど（笑）。

@miisan：それはちょっとありそうですね（笑）。

@fivestar：@miisanさんはどうですか？

@miisan：QAエンジニアの仕事って、証明するのが難しいんです。なぜなら、不具合がないと証明することは最後までできないから。そのため、リリースの判断もQAメンバーやチームの信頼度がすべてだったりします。話に出ていたプロジェクトでの不確実性に関しても、QAチームとしてリリースできると判断したら出せるし、無理だと言ったら中止になる。その狭間で悩むことは多かったですね。

@fivestar：メルペイにおいて、CDチームが開発するプロダクトの重要性はどんどん大きくなってきています。@miisanさんが言うように、それを支えるメンバーやチームの責任も増えていっているわけです。お金に関する機能だから法律の規制もあり、そのなかでいかにお客さまの利益を守りながら価値ある体験を作り出すか…ここはとてもプレッシャーがかかります。私としては、プロフェッショナルの冥利に尽きる環境だなぁとポジティブに受け止めている状況ではありますが。

@miisan：そうですね。大変なことに変わりはないのですが、それを乗り越えたあとは「あんなこともあったね」といい思い出になっている感じはありますね（笑）。

信用領域は重要度が増す、だからエキサイティングになる！

@miisan：最後に、CDチームとして目指したいものを教えてください。

@fivestar：信用領域はとてもおもしろくて、もっと発展させられる。メルペイのなかでも重要度も、エキサイティングなプロジェクトも増えていくと思っています。いい事業領域なので、CDチームを通じてその楽しさを発信していきたいですね。

チームは、私自身の立ち位置はもちろん、常に拡大しているメルペイ事業の流れに身を任せながら変化していくと思っています。まだまだやりたいことはたくさんあるので、いろいろアウトプットしていきたいです。

@miisan：ありがとうございます！QAチームは信用と技術的な観点、そしてお客さまにとって使いやすいUI/UXなのかさまざまな視点を持ちながら、引き続き品質を向上させていきます。品質を守りつつ「育む」観点がないと信用領域でのQAエンジニアは務まりません。まだまだ伸びしろのあるチームなので、より高いパフォーマンスを出せるようにしたいですね。

@fivestar：いい話だ、頑張りましょう！