Mercari Tech Conf 2017基調講演のまとめ

概要

Mercari Tech Conf 2017に行ってきました。 とても素晴らしい基調講演だったので、無我夢中でメモを取りながら聞き入りました。せっかくなのでまとめを公開します。

本編のスライドが全て公開されていますので、正しくはそちらを御覧ください。

感想

メルカリがなぜココまでの急成長を遂げられたのか、 国内にとどまらずグローバルで拡大し続けられるのか、 その理由がよく分かるような発表でした。

自分たちの実現したい事業コンセプトを徹底するために大胆に判断し、必要なところに最大限のリソースを投入する。
既存コードの作り直しを厭わず、冗長な作業を自動化することで本当に必要なことにフォーカスできる環境を作りあげること。
ミスをしても再発を防止する仕組みを作ることで、失敗を恐れない文化が作られたのだと感じました。

基調講演のまとめ

概要

• メルカリの創業期の様子
• US/UKへのグローバル進出
• souzouã‚„kauruなど新しいプラットフォームの展開
• 急成長を遂げるためにどのような戦略を取ってきたのか。
• スケーラビリティを実現するためメルカリエンジニアの行動指針について
• そして今後の展望について

mercari創業時代の話

スピーカーは鶴岡 達也(Head of Engineering, Souzoh)さん

mercariのスタートは地味だった

• 今の六本木ヒルズの華々しいオフィスではなく、取り壊し予定ビル。
• テーブルには会社支給のお茶のペットボトルが置かれているが、なくなってからの交換のため忘れられて酸っぱいお茶を飲むこともあった。
• 企画とエンジニアとが同じテーブルに座って開発する文化は当時からあった。

初期の会議の様子

• MTGは定例のみ
• 会議室も無かった
• 時間は1hour/1weekぐらい

mercariの核となる事業コンセプト

• コンセプト
  • スマホでものを売るような時代が来る
• 競合他社との違い
  • 最初からスマホに完全特化したユーザ体験
  • サービス展開を世界規模で考えていたこと
• コンセプトの実現のために重視した2つの柱
  • ユーザ体験
  • スピード感

出品体験の最大化と競合他社を圧倒するスピード感

事業コンセプトを実現するために取った戦略。
ユーザ体験と開発速度の最大化を実現するために必要ないことはやらない。

初期のインフラ構築の例

一般的には、冗長化を考えた構成にするが、mercariはそうしなかった。
冗長化の例としてはLBや複数インスタンスのサーバ、DBのmaster/slave構成、キャッシュ層の導入などがある。

時代背景としては4年前。EC2はあったがGCEはなかったような時代。

当時の議事録

議題：インフラ ★決定 ハイエンドな1サーバに全部集約。

3ヶ月持てば良いという思想の元、最初から捨てることを決めて構築を行い、作業はわずか1日で完了した。

初期のインフラ構成

• 構成
  • サーバ：シンプルすぎるLAMP環境
  • クライアント: ios/android + webview
• 選定理由
  • メンバ全員が開発経験があった
  • 必ずリリースできる見込みがあった
  • メンバにはphp界隈では有名人も多く、コネクションもあり、後の人材採用の容易さも見込んでいた

初期のメルカリに無い、あって当たり前のはず機能

初期のメルカリには、検索機能が無かった。　

初期のメルカリにとって、検索機能はユーザにとっても開発者にとってもメリットがない不要なものだった。

「 手抜きではなくアイデア」と鶴岡さんは語った。

一方で、出品体験の最大化のために時間をかけた事例。

商品画像の改善

一見全く同じように見える2枚の画像だが、サイズと容量が全く異なる。
3G回線でも快適にアップロード出来るようにJPEGを軽量化するため、長い時間をかけてチューニングを行った。

タイムライン機能

初期はネイティブエンジニアがいなかったのでタイムライン機能はWebView(HTML5)による実装だった。
これは、開発者の都合でしかなく、ユーザにとっては重くて使いにくいものだった。
ユーザ体験を最大化するために時間をかけ、タイムライン機能はネイティブに作り変え、API側も数10msになるようにチューニングした。
その結果、スクロールしても一切引っかかることがなく、他社を圧倒する体験が実現できた。

テレビCM対応

メルカリはリリース後、早期からTVCMを撃った。
その対応は2ヶ月で行われて、本格的な負荷テストを実施し、キャッシュが導入された。

創業期の開発チームが上手く行った理由

• 事業コンセプトへの理解
• どんな課題を解決するか見極める
• 大胆に意思決定をする

必要なことを必要なときにやる、創業期はプロダクトのことだけを考えればよい時期だった。
チームより強力な個人のスキルに依存していたフェーズだった。

社員数が20人を超えてから、チームを意識するようになった。

mercariの拡大期とこれから

スピーカーは柄沢 聡太郎(VP of Engineering)さん

メルカリのプラットフォーム拡大、グローバル展開、開発組織、VALUEの話。

メルカリの拡大

サービスについて

• US/UK : 戦略的地域拡大
• JP : プラットフォーム拡張
• 共通 : 断続的なUX改善

souzouから生まれる新規事業はmercari idでログインすることが出来、mercariにも出品される。新しいチャネルを作っている。

エンジニアの規模について

• エンジニアの増加
  • 2015å¹´25人→2016å¹´ 50人→ 2017å¹´110人（約）と年々で倍になっている。
• 職種を超えた多様性
  • 数学部が出来た。証明問題を説いて喜んでいる人たち。
• グローバルでの開発
  • 全世界に拠点があるので時差があるため、24時間稼働している。
  • マージ = deploy なので常にリリースされている。

新規事業をどうやって作ったか（souzou)

新規事業を始めたいが、既存事業も重要。どうするか。

リソース（人的、物質的）を完全に分離して、新規事業に専念出来る環境を作った。
souzouにはインフラメンバもおらず、全てAppEngineで作った。

USの立ち上げ

USの立ち上げに踏み切ったとき、現地にはオフィスもなかった。
日本を開発拠点に、海外向けにフォーカスし、殆どのリソースをつぎ込んだ。 日本から全力で作った。
その時日本向けを作ってたのは1人だけ。クロネコヤマトとの連携機能なども一人で作っていた。（今では日本向けも少しずつ増えている。）

Nativeアプリの扱い

リリース当時は1バイナリを共有していた。（日本版のノウハウを横展開したかったため） しかし、ローカライズの要求が高まり、共有できる部分が減ったので完全に分離した。

• ローカル差分の例
  • USでは、日本でマイナーなpaypalでの決済が多い
  • 返品が当たり前な文化

顧客要望を敏感に嗅ぎ取るため、組織の現地化を行っている。

mercariの開発組織

• プロジェクトチーム
• 横断的チーム
  • SRE
    • インフラチームから実態に即した名前に変更
    • インフラそのものではなく、ユーザへの信頼性にフォーカスする。
  • QA/SET
    • 手作業によるQAをやっていたチームが自動化、環境構築に責任を持つようになった。
  • EngineeringOperations
    • 組織開発・採用を主導。自分たちの仲間は自分たちで連れてくるという思想
    • 一部社内システム構築も行う
    • 今回のTechConfも主導した。

メルカリのVALUE

• GO BOLD
• All for One
• Be Professional

valueを体現している例

Wifiの設定変更による障害 設定変更は環境を良くするために行った作業は、 GO BOLD リアクションに失敗を咎めない文化が現れている。
今回、失敗した事例を公開してスライドへ掲載する許可をくれたのは ALL FOR ONE と言える。

メルカリエンジニアの開発組織が掲げる理念 Scalable and Elastic

Scalable and Elastic

Scalable And Elasticをどのように実現するか。

スピーカー：名村卓（CTO）さん

メルカリの今

• 日本
  • 新機能開発
  • 複雑化への対応（シンプルに）
  • DBのスケールアウト
  • 検索精度向上
    • メルカリのCPUコア数はAPIより検索サーバの方が多い。
  • トラフィック最適化
• US
  • 国土の大きさ、州ごとにライセンスが必要、返品率高いへ対応するオペレーション
  • アプリを1から作り直したため、サーバのアーキテクチャも変わって独自進化を始めている。
  • USならではの独自機能
    • 価格交渉が出来るオファー機能
    • 不正利用を機械学習で検知
• UK
  • 立ち上げフェーズ
  • UK独自機能の追加
  • EU全体から多様性あるメンバーが集っている。

メルカリエンジニアの行動指針

1. Ornership
2. Automation, Karakuri
3. Progressive

1.Ownereship

Micro Service Architectureの導入

• 一つのマイクロサービスを担当するのは小さなチームになる。
• 独立チームになるので、裁量が与えられる。
• プラットフォーム、ミドルウェアの選定も全て任される。
• テストがシンプルになる。　テストが高速になる。　デプロイも軽量になる。
• オンボーディングコストが小さくなる。

どうやってマイクロサービスに転向するか。

USではすでに3つのMSが稼働している。今後もどんどん転換していく方針。

• 導入の背景
  • 既存をこれ以上大きくしたくない。
  • ローカル採用されたエンジニアが歴史的経緯を理解せず開発出来るようにしたい
  • US展開でクライアントのバイナリを分ける話があった
• 設計
  • API GW: go+ protocol buffer
  • grpcでマイクロサービス化
  • kubernatesでochestration。デプロイも簡単。

モノリスから

徐々にマイクロサービスを切り出し 発展させる

2. Automation, Karakuri

小さい頃では気合でなんとかなっていたものが、大きくなっては無理になる。 組織も大きくなってくると、個人の頭のなかだけにあるノウハウは足かせにしかならない。

二度以上やったことは自動化の対象。全て自動化していく

気合ではなく、仕組みで解決する方法がKarakuri

からくり : 仕組みによる問題解決

• 障害を起こした原因がテスト不足だったらUTを増やす。
• レビューを2回に増やすという運用を追加しても意味がない。

botによる自動化

• Go Bold Bot
  • 月400回の メルカリのdeployを支える
• とんこつbot
  • アプリのストア反映をキャッチして通知するBot（手でポーリングしなくて良い）
• AccountBot
  • 手動でやっていたアカウント作成を自動化した。（DBã‚„VPNのアカウント) Slackで承認ボタンを押すだけで済むようになった。

アプリの e2eテストも自動化：（SETチーム）

Karakuriを大事にする風土

mercariでは、犯人探しはしない。 問題が起きない仕組みが出来たら、解決したとなる。

責任を取るのではなく、仕組みを作ることで問題を解決する。

3 Progressive

常に足を止めずに良い手法、技術を探求し続ける。 メルカリでは様々な最新技術を試している。

• ApacheAirflowはOSS化されてすぐにUSのデータアナリストが稼働させた。
• deployにはspinnakerを検討している。

新しい技術分野

• AI&machine learning
  • 機械学習をプロダクトに取り入れるため、Project横断組織のチームAIがある。
• C2C marketing * Blockchain
  • まだ語れないことが多い

MachineLearningPlatform：Continuous Training

チームには多様性があるため、モデル作成に集中しやすい基盤を整備している。 データの整備やモデル評価などの共通部分を基盤化しており、来年あたりOSS化する目標を持っている。

以上。基調講演のまとめでした。

余談

こちらは戦利品のノベルティーです。 中はどら焼きでした。六本木の名店です。

運営について

素晴らしい運営体制だと感心しました。　　 Wifiも快適につながり、時間通りに進行して一切トラブルが無く、気持ちよく一日が過ごせました。

特にすごかった点

1. 時間が完璧。殆どの発表が時間ぴったりに収まっていたこと。
2. 気配りがすごい。メイン会場での発表のほか、サブ会場では展示会とカフェが併設されていました。サブ会場ではスピーカーへ質問できる場所が設けられていたり、困ることがありませんでした。
3. お金がかかっている。英語への同時通訳、懇親会の料理、社員エンジニアのスタッフ参加。

初めての大型カンファレンスをこのクオリティでやれるメルカリは改めてすごいと感心しました。