先日からお伝えしていた通り、9/30 （土） にベルサール六本木にて第1回 Mercari Tech Conf 2017 が開催されました。
テーマに Next を掲げ、過去から現在にいたるまでに実現してきたこと、そしてこれから実現する未来について発表しました。
それでは、簡単に各発表を振り返っていきます。
基調講演
鶴岡 達也 (Head of Engineering, Souzoh) / 柄沢 聡太郎 (VP of Engineering) / 名村 卓 (CTO) 3名による基調講演でした。
- メルカリ初期の話 – 鶴岡
- この頃はとにかく素早くものを作る必要があった
- シンプルな LAMP 構成を採用した。LAMP なのは初期のエンジニアが一番触りやすい構成、言語だから。人のスケールをさせやすいから
- インフラはハイエンドな1つのサーバに集約
- アーキテクチャを切り替えられるようになっていればそれでよくて、それよりも高速でインフラなどを準備することが大事だった。3ヶ月持てば良いとの判断で、どこかのタイミングで捨てることを前提にした構成にした
- なぜ検索機能がないのか？
- 手抜きではなくアイデア。取捨選択の線引きが初期の段階では重要。初期は高速でリリースする事が一番大事だった
- サービスを開始してから10ヶ月目でテレビ CM を打った
- このころからスケールアウトを意識
- 事業コンセプトの理解 -> どんな課題を解決するか見極める -> 大胆な意識決定をする
- チーム開発というより強い個に依存していた時期、プロダクトのことだけを考えて実装する時期
- メルカリ拡大期 – 柄沢
- 機械学習、テスト (SET) 専任のエンジニアが増えてきている
- エンジニアの多様化（組織の拡大化もあいまって、プロダクト以外の面でも。数学部などが発足する)
- 24時間開発体制 (世界各地に3拠点があるがゆえ)
- Souzoh
- 既存事業にリソースを取られ、新規事業にフォーカスできないのを防ぐ
- US 立ち上げ期、JP のリソースを9割以上を US に向ける
- 立ち上げたあとは、徐々にローカライズ、開発メンバも日本人から現地人に移行しつつある
- クライアントのfork
- 今まで1ソースで開発していた。しかし拡大とともに国ごとに共有できるコードについて減ってきた
- それぞれの国に合う UI の最適化をおこなったためフォークした
- Value
- メルカリに根付く3つの Value。すべての社員の行動規範になっている
- 今後の拡大などについて – 名村
- JP では、
- いかにシンプルにするか、急増するトラフィックをさばく、DB のスケールアウトなどが目下の課題、トラフィック最適化、検索精度の向上化
- US では、
- サービスの「定着化」、配送が時間掛かるなどの国土特有の問題、州制度によるライセンスの問題など
- あるタイミングでコードベース書き換えた。それに伴うサーバアーキテクチャの刷新など、日本と違う独自の進化を遂げている。たとえばOffer 機能など
- UK では、
- ローンチから6ヶ月
- タイムラインを UK 独自のアルゴリズムで実装した (→マイクロサービス化)
- EU各地から優秀なエンジニアが集まっていて、ダイバーシティに富んでいる
- メルカリエンジニアの行動指針、Scalable かつ Elastic な組織づくりをする
- オーナーシップ
- マイクロサービス化。Uber、Lyft など急成長業でも採用しているサービスアーキテクチャ
- マイクロサービス化することにより、オーナーシップを分散する
- 役割を明確化する。テストが簡潔になり、品質の向上、デプロイの軽量化を行うことができる。また、学習コストも減る
- マイクロサービスは組織が持つ問題点を解決する技術的な手法の一つ
- どうやってマイクロサービスへ転向しているか
- SRE では、すでにこの指針を打ち出す前から動いていたが、プロダクト面では US で大きく舵を切った
- US ではすでに3つ。これがうまくいったのでこれからもどんどん増えていくだろう
- 現地採用されたメンバーに昔の巨大な API を触らせるのは大変なこと。マイクロサービス化することによりそれを減らす
- Automation / Karakuri
- Automation: 自動化できるものは自動化する
- Karakuri: 物事の問題を仕組みを持って解決する
- 人が増えると気合で解決できるものではないので、ある程度の仕組み化が必要になる
- 障害を起こした原因がロジックであれば、「テストを追加する」という行動は正しいが、2重レビューをしましょうというのは、Karakuri の指針に反する
- 「ミスをしてはいけない」ではなく、「ミスをしてもいい」という環境のほうがエンジニアにとってクリエイティブと捉えている
- Slack での bot による自動化など、メルカリでは Karakuri を大事にする風土を取り入れていく
- 責任を取る風土ではなく、仕組みで問題を解決する風土を目指している
- JP では、
Mercariサーバサイドデプロイ:現在と未来
- SRE とは Google が提唱した概念
- 最初はインフラチームだったが、メルカリでは「いつでも快適、安全に利用できる信頼性の高いサービスの実現」をするため、実態に則した名前に変更した
- 現在のメンバーは10名
- サーバサイドデプロイ
- マスターからマージしたタイミングでデプロイ
- プルリクエストからのデプロイ。インフラの設定・マネージャの承認等の事前確認があればマージされデプロイされる
- 昔は Redmine を使っていたが今は JIRA を使っている
- 2017~
- マイクロサービス化 + 人が増えてきた
- bot の役割がおおきくなってきた
- レビューとデプロイの bot を切り分ける
- GitHub の bot はAWS Lambdaで動いている
- デプロイbotの話
- Node.jsで書かかれている
- 内部コードの説明 (Promise がメイン)
- GitHub のステータスに書いていたが、社内的に評判が悪かったので、comment に書くようにした
- なので、ステータスをラベルを自動的に付与するようにした
review pleaseとコメントすると細かい結果を出すようにする- ユーザ体験 (開発エンジニア) を意識する
- 開発者の邪魔をしないようにする
- 情報は最小限に
- 課題: 稼働しているか開発者が不安になる
- Kubernetes
- 今後のプラットフォームとして k8s を基盤に選定
- Spinnaker の採用
- 開発者によりデプロイ周りのオーナーシップを与える
- 課題
- 設定GUIベース
- コミュニティが始まったばかりでトラブルシューティングの情報が足りない
Web アプリケーションにおける Go 言語のパッケージ構成 〜メルカリ カウル編〜
- golang.tokyo のアンケートでパッケージ構成について興味のある人が多かった (第2位) (1位はテストだが Mitchell Hashimoto 氏の Advanced testing in Go を参考にされたい)
- One package
- 一番シンプル、パッケージ切らない方式。カバレッジ測りやすい
- Flat package
- Go の標準パッケージなどに近しい
- Multiple pakcage
- モノリシックな Web サービスなど (GAE/Go 構成)、MVC アーキテクチャ
- 縦でパッケージ切るか、横でパッケージ切るか、というイメージ
- Souzoh ではインフラエンジニアはおらず、GAE 任せ
- src ディレクトリを切ってるのは、パッケージ管理システムの gb の関係
- うまく共通化できたライブラリはプロジェクトのリポジトリから切り出されて、private リポジトリとしてパッケージされたりする
- 意識せずにパッケージを切ると、cycle import が頻繁するので、疎結合であることを死守する (とくにドメインロジックは)
- インターフェース
- Is-go-object-oriented いいエントリ
- Interface は単なるメソッドリストである
- インターフェースパターンの実例
- 振る舞いの定義より、「Java 的な Interface 定義」
- DI 前提の Interface は Go チーム自体も話していない (ので価値があるかも)
- ただ、gRPC でジェネレートした関数群はこのような定義がされている
- DDD が悪いことではない (早く出したいとか、つい App Layer に書くとか)
- 正しく定期的、意識的に分離することが大事
- 先行サービスが次のサービスの立ち上げに役立つような基盤だったりレールを敷いておくことが Souzoh では重要かもしれない
US版Mercari iOSアプリのアーキテクチャーとDependency Injection
- US アプリを刷新した。何が新しいか？
- 見た目が新しい
- コードベース
- アーキテクチャ
- 流行っているアーキテクチャよりも、メルカリではシンプルなものを
- MVVM＋Repository の採用に至る
- DI の話になると、ライブラリ選定などの話になる→面倒だから
- (DI Container の DEMO)
High 意識 Android – US App : Re-born
- US アプリを6月に刷新した
- 2016年以来の歴史
- 日本とアメリカのメンバーで開発していた
- 時差が問題
- 公安9課モデルを採用
- 縦を個人プレーのパフォーマンス、横をチーム間のパフォーマンスとする、それを最大化することが大事
- 早朝 6:30のデイリーシンクMTG、Screenhero でスクリーンを共有するなど
- 2017年
- 9人に増えた
- リージョンに UK が追加→1リポジトリでの開発がつらくなる
- リポジトリを各リージョンごとの3つに分けた
- この時点で3年半かけてつくってきたためコードベースが古い
- より早く動かしたい→全部作り変える (Re:born)
- 誰でも同じコードが書ける
- すべての問題を適切なサイズに落としておく
- 大きな問題を小さなサイズへ分割したい
- → DI
- 高品質なコミュニケーション
- 最新技術へのチャレンジを積極的に行う
- 気付きがスピードアップするヒント
- 各週で東京、サンフランシスコ間で情報を共有する
- サンフランシスコの採用状況
- やはり太平洋横断開発は難しい
- 将来100人にしたい
- 大体65人分ぐらいのパフォーマンスしかでないが、100人以上のパフォーマンスを出せるチームにしたい
画像認識技術は人間を超えたのか？
- 2015年くらいに人間のエラーレートをマシンがすでに越している
- メルカリと ImageNet のコンペティション
- カテゴリ数同じくらい
- データ数も同じくらいにできる
- 最近のアルゴリズムを使うだけで同じ精度を期待できるのではという仮定をした
- 結果エラーレート 30%。1000 以上の選択肢 (カテゴリ) がある中でこのエラーレートは実は凄いこと
- 「その他」カテゴリは定義がない（何者でもないものの集まり)
- 「その他」とわかったところでなんの意味もない
- これを切り捨てると 30 -> 25
- お客さまが選択したものが正解、水玉のピンクのコートを男の子のカテゴリに入れても問題のないこと（ここに機械学習の難しさがある、エラーレートを引き上げてしまう原因である)
- 幼児は 200ms でまばたきをするので3歳くらいまでに数億ものイメージを学習している。機械学習も同じで、優秀なアルゴリズムも重要であるが、大量のデータを学習させることも重要である
- 現状カテゴリ認識において、人間を超えたという実感はない。その原因は学習力にもある
イギリスでの開発チームの作り方
- 2017 春ローンチした
- ヨーロッパチーム、日本人3、4割ほど、プロダクト全体では 19 人
- メルカリUKの歴史
- 2016
- 9月: 開発スタート
- 11月: UKへ移動
- 2017
- 2月: 初期バージョンの作成完了
- 3月: 初期リリース
- 2016
- 3人の技術者を日本から出した
- iOS, Android, API
- 英語力よりも技術力を重視した
- ロンドンの求人市場は流動性が高い
- Hiring 結果
- CV (履歴書)
- 最初はピンと来る人がなかなかいなかった
- 各分野ごと最初の一人目が大事。そうしないと全体も苦しくなるし、二人目の採用も難しくなる
- ロンドンにおけるメルカリは知名度がない。ロンドンに日本のインターネット企業は殆ど無い
- 日本の企業に対するネガティブイメージがある (残業など)
- エージェント経由での Hiring をするが Fee が高いという問題点がある
- エージェントがLinkedInからサーチして、闇雲にメールを送る
- 受け身の感覚で来られるのでモチベーションが低い人が来ることが多い
- やはり社員紹介がいい、自分たちの仲間は自分たちで集める
- 現地紹介をして半年
- 一人目がいい人を採用できると二人目が楽
- 採用で大切なのはスピード
- 業界標準のツールセットを使う
- JIRAの普及率が高い
- タイトルに拘る人が多い（転職のため）
- シニアエンジニア、リードエンジニア等
- 転職の流動性が高い（大体2〜3年）
- サービスを流行らせブランドをあげる
- スポンサーを出して、知名度をあげる
まとめ
第1回目の Mercari Tech Conf (MTC) が終了しました。たくさんのエンジニアの方々にご来場いただき、大盛況のうちに終わることができました。ありがとうございました。
来年も開催します！また第2回MTCでお会いしましょう！
