【デブサミ2020レポート】メルペイリリースとその後一年間の裏側と学び #devsumiD

はじめに

2020年2月14日に開催されたDevelopers Summit2020に参加してきました。

event.shoeisha.jp

テーマ

【14-D-6】メルペイリリースとその後一年間の裏側と学び

カテゴリ

エンジニア組織

登壇者

• 木村 秀夫さん[メルペイ]
  • @hidek
  • ISPでキャリアをスタート
  • 2009年、DeNA入社
  • 2018年より、株式会社メルペイVP of Engineering

発表資料

講演メモ

メルペイとは

• 19年2月13日リリース
  • リリース1周年！！
• メルカリとは会社が別
  • メルカリの売上金がすぐに使える
• 決済方法
  • iD
  • コード支払い
    • なんちゃらpayがたくさんあるやつ
  • MPM形式
    • 店舗にあるQRコード読み取り
• オフラインでも利用できる
  • アパレルECなど
• メルペイスマート払い開始
  • 信用取引
  • メルカリのユニークなデータを活用
  • メルカリの取引実績をもとに信用スコアを算出
• キャンペーン
  • いろいろやってます

アーキテクチャ

• マイクロサービス
  • 50以上
• 2020 ２Qで1544億円扱うメルカリの決済基盤
• 600万人以上の利用者
• メルカリはオンプレからクラウドに移行中
• メルペイはGCPを利用
  • K8s
• バックエンド
  • マイクロサービス
  • Go
  • gRPC
• Android
  • Kotlin
• iOS
  • Swift
• Frontend
  • Vue.js/Nuxt

組織

• エンジニア数
  • 18年から2年で約2倍
• PM-EM組織
  • 横軸がプロダクト
  • 縦軸がエンジニアリング

振り返り(2019年1月~3月)

• 最初のリリース
• リリースまで14ヶ月かかっている
  • 会社設立は2017年11月
  • 最初は2018年8月リリース予定だった・・・。
• なぜ6ヶ月遅延したのか？
  • 不確実性による見積もり失敗
  • 作るものが大きいため、最初の見積もりがとても難しい
• 主な要因
  • 肥大化する要件による不確実性
    • なんちゃらPayとしては後発
    • 経営として、最初から全部盛りでリリースしたい！！
    • エンジニアとして、良いものを作りたい！
      • 気持ちはわかるが・・・
  • 複雑な依存関係による不確実性
    • 決済はステークホルダーが多い
      • Gateway
      • 銀行システム
      • 既存のメルカリ
    • 大規模なマイクロサービスの開発経験がなかった
      • GCPの知見も十分でなかった
• 結果、見積もりが意味をなさなかった
• やったこと
  • 肥大化への対応
    • フェーズの整理
  • 複雑な依存関係
    • スコープの整理（段階的リリース）
      • 最初はiD決済、iOSのみ
      • 経営としては最初のリリースに力を入れたかったが・・・
• 大きな初期リリースはウォーターフォールなプロジェクトマネジメントが効く
  • やりすぎはダメ
  • あくまで緊急措置

振り返り(2019年4月~6月)

• キャンペーン・クーポンやった
  • 現場は火事場
• 一時的にメルカリ本体から30人ほどエンジニアを借りた
  • 経営トップの判断
  • All for One連携
• 事業的には成功した、が、
  • メルカリ本体側の、マイクロサービス化のためのコードフリーズの延期
    • 技術的負債
  • 開発中のプロジェクトフリーズ
    • 組織的負債
      • エンジニアのモチベーションダウン
      • 事業は大事だが、もうちょっと丁寧にできたのではないか・・・
• 戦時は、民族大移動も必要
  • やりすぎはダメ

振り返り(2019年7月~9月）

• 技術的負債の返済
  • 負債そのものは悪ではない
  • 借りすぎは悪
• プロダクトアウト vs 将来の開発スピード
  • バランスを取るのが難しい
• 一時的に大きく借りたので、一定返す期間が必要だった
• 課題の洗い出しと優先順位の整理
  • スプレッドシートで管理
    • セキュリティリスクが高いもの
      • 比較的古いマイクロサービスのストレージ移行
      • メルカリモノリスに実装した機能のマイクロサービス化
    • 部署横断で意思決定が必要なもの
• やったこと
  • OKR(目標設定手法)
  • 全社目標で技術的負債の返済を入れた
    • この時期は工数を使うことを、経営層に言い続けた
    • 会社全体でコミットした
    • エンジニア以外の人にも理解が進んだ

振り返り(2019年10月~12月)

• インシデントレスポンスの改善
• 理想
  • 24365完璧に動く
• 現実
  • 何かしら障害が起こる
  • 障害が起こることを見越した運用が必要
• 安心安全なサービスを実現するために
  • 正しい状態の定義
    • SLOの定義
      • 縦軸：お客様の体験
      • 横軸：SLO,信頼性（＆コスト）
  • 正しい状態出ないことに早く気づく
    • 監視
• SLOの定義
  • 殆ど待たずに決済できる
    • QRコード決済Requestの99%がGatewayで計測して100ms以内に成功する
  • QRコード決済したが、20秒待っても完了しない
    • きちんと数値化して言語化する
    • 監視の標にもなる
• やったこと
  • OKR
  • 運用するものは増えたが、インシデントは増えていない
  • インシデントから1週間以内で対応している

振り返り(2020年1月～これから)

• プロダクティビティの向上
• 安定運用できてきた
• 今の体制でできることをN倍にしたい
  • プロダクティビティの向上へ
• What
  • 運用生産性
  • 開発生産性
• How3つの軸
  • 省力化
    • 自動化
  • 可視化
    • 情報の検索性
  • 汎化
    • プラットフォーム化
    • 車輪の再発明はしない
• どうやるか
  • OKR
  • 全社で向き合う

まとめ

• 色々あったが、全て全社のOKRに組み込んだ
  • 全社で向き合った
  • 採用もOKRに組み込んだ
• 言い続けることが大事
  • 無意識の合意
  • コミュニケーションコストが上がる
• 半歩先を意識する
  • 先すぎても事業案鏡に振り回される
• バランス大事
  • 技術も組織も無理をするときと、順序立ててやるときの見極めをする
  • 短期・中期両方の成長機会を失う

宣伝

• 3.17
  • メルペイ Tech Fest2020やります
  • 虎ノ門ヒルズフォーラムにて

感想とまとめ

メルペイはメルカリの売上金を引き出す際に使うくらいですが、 VPoEの立場から見た振り返りは大変勉強になりました。技術者の立場を経営層が理解してくれることは、エンジニアリングを行う上で非常に大事な要素だと思います。1エンジニアがOKRが大事だと吠えたところで、全社レベルで意思統一させるのは難しいと思います。技術も組織も理解するVPoEの存在は羨ましいなと素直に思いました。

プロダクティビティ向上のためのHOWは自分のプロダクトにも取り入れてみたいと思います！