CTOとエンジニアが赤裸々に語る 変化と挑戦

第一部 CTO

名村さん メルカリのエンジニア組織 今とこれから

  • メルカリのイメージが中と外で大きく違う

    • サービスが完成されていてチャレンジすることがなさそう、自分がやれることはなさそう
    • 優秀な人が集まっていそう
    • 最先端な技術を使用していそう

    • 従業員数は3年で3倍

      • エンジニアもここ3年で3倍増えた
    • 頑張って人を増やした結果、組織の空気が変わってきた。

      • 育成する文化が熟成されていなかった。新入社員が良くも悪くもほっぽり出されることが多かった。
        • カルチャー、マインドの育成の弱さを感じた。
      • 開発プロセスが属人化され、変化に弱い組織になっていた。
    • 短期的な意思決定によって、技術的負債も

    • 急速なグローバル化により、言語や文化の壁に直面

      • 半分くらいが外国籍の方
  • 過去うまく言っていたものを捨てて、新しい方向へ踏み出すタイミング

  • 「お客様に最高の体験を届ける」

    • エンジニアが成長できる組織
      • エンジニアが心の底からプロダクト開発を楽しむことができる組織
  • 統率のとれた有機的な組織 の要件

    • 目指す方向性…Mission vision OKR,
      • 裁量 アーキテクチャの刷新 Feature flag, Design System,
        • カルチャー・仕組み Engineer principles, Career ladder, グローバル人材を育成するためのプロジェクト発足
  • メルカリCTO名村が目指す「統率のとれた有機的な組織」とは?

曽川さん メルペイのこれまでとこれから

立ち上げて半年経ったくらいであったり、事業のステージが違う。 挑戦について

  • Cash In… 5,300億円
  • MAU … 1,357万人
  • 決済対応箇所 1,700,000箇所
    • iD, ApplePay のステッカーがあるところは使用できる
  • 後払い機能

  • メルペイが解決したい世の中の課題

    • お金が理由で諦めることを無くしたい (お金の問題を解決したい)
    • お金はやりたいことを実現するツール
    • スコアリング
  • メルペイのMission

    • 信用を創造して、滑らかな社会を作る
      • お金の問題を解決して一人一人がやりたいことを実現できるようにする
      • お金の循環のあるMercariでやる意義
        • お金の流動性と物の流動性を相互に高めていく
      • メルカリとメルペイの親和性の高さ
        • メルカリを利用することで、不要なものをお金に戻すことができる
          • 時計の針を戻す機能 と言える。
        • お金と時間の関係、メルカリとメルペイの関係
    • メルペイが目指す社会
      • 滑らかな社会… 一人一人の好きなこと・やりたいことが実現できる
        • これは市場の役割でもある
          • そのためにも多様な社会・組織が良い
    • こんな未来が創りたい
      • 信用によって、今までできなかったことをできるようにしたい
        • うることを前提とした社会
        • 二次流通でなく一時流通でやるべきことが見えてくるなど、色々なメリットがあるだろう
        • 持続的な社会への貢献となる
  • まだスタート初日の気持ち。課題が多い。ここからが勝負

    • 価値の創造(交換)は、すごく面白いテーマ
      • 労働も

社内で言われていること: テクノロジーの力で価値交換のあり方を変えていく

第二部 Engineer

Taichi Nakashima さん @deet

  • MIcroservices の基盤チームを立ち上げてきた

    • その経験からの学びについて
  • これまで関わったプロジェクト

    • US MicroServices 2017
      • 初期のサポート
      • Search serviceの開発(抜き出し)
    • JP MicroServices 2017

      • 基盤チームの作成
        • k8s
        • DevOps ToolChain
        • Common Framework Best practice & documentation
      • AI出品の機能

        • 出品写真から自動でカテゴリ付与

          • モノリスのサブシステムとして開発してあるが、抜き出していきたい
        • 問題解決のために APIGagtewayの開発

          • Api gateway を差し込み、モノリスのサービスを抜き出しやすい環境を作った
          • Api gateway
            • Goでフルスクラッチ
            • UKでも使えるように作った。⇨メルペイでも使えるようになった
            • 実装からリリースまで半年。
              • 全てのメルカリのリクエストを受ける。60,000 ピーク次で。
          • マイクロサービスを作るためのMicroServices starter-kit
            • Terraformで共通インフラをBootstrapする
            • オファーサービスをこのきっとで作った
          • MerpayのMicroserviceも同じMercari MicroservicePlatform に乗せた
        • マイクロサービス化を進めるために、 Monolith code freezeを採用

          • Monolith code freeze
            • 新規機能の追加
        • 40以上のサービスが Platformで動いている

    • まだSakuraにサービスが載っているので、現在は切り出しを引き続き行なっている

  • 学び

    • “Why” が一番重要
      • 新しい組織図 がマイクロサービスのやる意味
      • 組織が大きくなっても、アウトプットを落とさず、むしろ上げること
    • “How”は無限にある。”Why”でしか最適な答えは導き出せない
      • 設定のデリゲーションができない実装になってしまったことがある
    • Top-down decision isrequired
      • 現場 Bottom-up だけでは解決できない問題はたくさんある
      • code-freeze
        • 反発はあったが、やらなかったらやばかった
    • Clomplete freedom is not true
      • Microservicesでは技術や言語を自由に選択できるという神話
        • Noじゃないか?
        • 初めは小さく、徐々に増やしていくのが正解では?
          • 独立した意思決定が可能となって、初めて自由な選択ができるようになるのでは
  • The microservice architecture is a means to an end: enabling continuous delivery/deployment

    主森理さん Merpay Engineering Manager

  • @osamingo

    • Sozoでメルカリカウルを立ち上げた
  • 今の開発体験が構築されるまで

    • 201711 メルペイ設立
    • メルカリの社内公募でメルペイに異動
    • Sozoからとメルカリからの異動者がいるが、メルカリのスタイルを継承

    • オンライン決済の設計を担当した

    • VPoE の@hidek が入社

      • 改革

        • CTOをBusinessとtechに集中させた
        • PM-TL-EM体制を構築した(Googleと同じ)

          • マトリクス 縦軸がPM、横軸がEM
        • TL TechLead

          • 技術選定、コードレビュー、メンバーサポート
          • 何を作るのか、どのように作るのか
        • EM

          • 強いエンジニアチームを作る
          • 技術選定、技術ディレクション
          • 誰が働くのか、どうやってパフォーマンスを出すか
      • 問題解決

        • 会議体の設置、開発ポリシーを設定
      • PM-TL-EM体制では Project Managementの責任者が明確ではない

        • PJOを設置(PMはProductManager)
  • EMのやってること

    • 色々な経緯でEMになる
    • 自チームのマネジメント(bacend3 チーム)(1on1, 評価、目標設定)
    • 登壇、採用、チーム編成
    • プログラムはかける?
      • TLを兼務している人は書くことが多い
      • osamingoさんは書かない
        • ただし感を持ち続けるために
          • Software Designへの寄稿
          • 個人開発
    • 醍醐味
      • チャレンジの楽しさ、チームでの達成、情報量が多くなる。
      • All For One
  • TPM(Technical Product Manager)とは

    • 職位ではなく、役割
    • プロジェクトの進捗管理
    • VPoE へ集まりすぎて Scaleしない
    • 定期的にネガティブチェックを行う。本当にこの役割は必要なのか?

高山征大さん(@mootoh) メルカリEM

  • ManagerとEngineerを行き来している
  • 2018前半からAndroidチームに外国籍の方がかなり増加
  • 行き来できる環境はかなりレア、
  • 大事なのは、振り子を振っていく中で、ボールを大きくしていくこと
  • 一度マネージャーを辞めたエンジニアが、メルカリで求める「楽しさ」の正体
  • THE ENGINEER/MANAGER PENDULUM

    高木潤一郎(@tjun)メルペイEM

  • 信頼性へのチャレンジ

    • 信頼性とは
      • 金融サービスとしての信頼性
    • Reliability <==> Velocity
    • SLO (Service Level Objective)
      • サービスの実現すべき数値 を決める. 目標を決める
        • 次のチャレンジへのチャンスを作る基準
    • 誰が実現するか
      • SRE? だけではない。組織全体で作る
    • メルペイのリリース
      • メルカリユーザーのリクエストが一気にメルペイにくる。
        • 一般的なサービスのような漸進的な調整が難しい
    • SREがマイクロサービスの信頼性のためにやったこと
      • 共通インフラの構築
      • ルールや仕組みづくり
      • リリースのためのサポート
    • 何も信頼できない
      • 障害は起きるという前提で考える
      • 信頼性については、リリース後に高めていくもの、これからChallange
  • エンジニアと立ち話。Vol.20 @tjun(メルペイSRE)ちょっとお話いいですか?

第三部 対談

  • ミスマッチ防止のために赤裸々に話している 
    • 内と外でイメージのギャップが 大きい
    • 外から見るとキラキラしているようにみられがちだが、実際大変
    • 大変そうな方が好きな人、ネガティブなことを恐れない気持ちが大事
  • 社内の不満は少なくない。
    • それだけPayの戦いは厳しい
  • メルカリに向いている人、メルペイに向いている人
    • 現在は直接的に解を持っている人が欲しい
      • ゼロイチより、ピンポイントで問題解決できる人があっているかも
      • なかなかいないので、仮説を持ってい行動できる人、こうしたいという世界を持っている人
    • 英語喋れる人は必要
    • 価値観は当初と変わっていないが、2,3日でわーっとプロダクトを作るような形ではない
      • 以前と雰囲気が変わっていることは確かにある。スタートアップの立ち上がりの空気は今は落ち着いている。
  • 評価制度

    • 外国籍の方や外国企業で働いてきた人が増えてきて、しっかりとやっていくことが必要になってきた
      • ladderをしっかり作る
    • 導入時の難しさ
      • 導入後の不満を防ぐため、反論のチャンスを設けた
  • 1on1について

    • 組織の話、ブロッカーは何かある?それを取り外すのが上司の仕事
  • Microservices

    • 未経験の人はやってみないとわからないところではある
    • DesignDoc は社内で全員が書き込める
      • gRPCのProtocolbuffersのサービスの定義がコミュニケーションに一役買っている
  • VPoEが事業をしっかりみている

  • キャッシュレスに対してコミットしていきたい