@六本木アカデミーヒルズ
全部Aパートの方を見ました。半分仕事しながら書いたので抜け漏れ誤植もあり
http://day.mercari.com/2017/

Mercari - Moving Beyond Borders(柄沢 聡太郎)

• 日本/SanFransisco/Londonと3拠点ある
• 60人/8人/4人
• ローカライズは文化や習慣にも合わせてやっている
• チームごとにOKRを設定して進める
• インフラ/テストチームを分けている
• 横断して目指しているのはプロダクトファーストであるというところ
• 技術的負債に関しては進みながら直している
• 技術に関してはスペシャリスト性を重んじつつ、適材適所を意識してマネジメントしている
• ミッション（Go Bold, All for One, Be Professional）
• 採用
  • コード見ずに採用しない
  • 設計力・発想力・応用力を見る
  • エンジニア経験のある人、第一線のエンジニアを採用にフルコミットさせる
  • 候補者に取っても理解してもらいやすい
• 育成
  • メンターをつける
  • 毎日1on1する
  • 困ったこと、見直してほしいことをつける
  • 全員CS研修をする、新卒は一ヶ月まるまるSREをさせる
• 技術評価
  • 四半期ごとの貢献＋技術貢献
  • リファクタリングやドキュメンテーション、新しい技術への評価など
  • 技術的な課題菅とそれへの取り組み
  • キャリア
  • プロンシパルエンジニア
    • 技術力＋事業貢献
  • エンジニアリングマネージャー
  • どっちも経営陣と同等の評価を受けるようにしている
  • 自発的な行動を支援する仕組み
  • カンファレンスへの参加や発表を明確にサポートする
  • 月一の何をしてもいい日もある、プロジェクト以外の技術へのトライやアウトプット
  • 日を決めておくことで周りの協力や行動を起こしやすい
  • 事業の拡大と多角化

考察

• マルチリージョンでのエンジニア獲得戦略も同じなんだろうか
• 「好きことをしていい日」があるのはいい、挑戦への理解を作りやすそうだ
• 第一線のエンジニアを人事にフルコミットさせるのは、考えても実施できないと思うからすごい
• 自分がもしそれにアサインされたらすごく面白そうだけど、その時のポジションや目標をどのように持たせてもらえるかがきになる

This is mercari, This is a SRE(佐々木 健一)

• kenichi sasaki
• 関連エントリ：http://tech.mercari.com/entry/2015/11/18/153421
• インフラについて
• そもそもSREとはGoolgeの提唱した様々なプロダクトを横断してサイトの信頼性を向上させる
• エラーや不具合を予算と考えて、障害などでこれを消化したらデプロイを控えるなど
• 採用状況はIndeedでは3.6k人の募集がある
• 日本ではまだ採用が少ない
• インフラ
  • 日本はさくら石狩DC
  • 構成はシンプル（資料参照）
• 名前変更した理由
  • 海外でも通用するため
  • インフラとしてでなくサービス横断のプロダクト改善のため
• メルカリにおけるSREの業務
  • ミドルウェア開発、分析基盤整備、DevOps
  • Gaurunなど
• chatops
  • ChatBotをカスタマイズしまくり
  • １日10回とかデプロイ増えていったため

考察

• 開発・試験・本番環境を社内で専任で改善してくれる人がいるのはとてもいい
• SREの考え方である予算の発想は面白い

品質向上の取り組み(鈴木 祥真)

• 4人
• 関連資料：http://sssslide.com/speakerdeck.com/shomas/merukariniokeru-software-engineer-in-test
• SET (SoftEngineer in Test)
• 開発環境の整備
  • Dockerベースで本番環境を模倣したものを作る
  • 入社した日から動けるようにする
  • 探索的テストなど
• それぞれの環境で差異をなるべくなくしている
• ユニットテストだけじゃなくて、それぞれのレイヤーで早く安定的に動くようにする
• テストとリリース、ビルドを短くしていきたい

考察

• Dockerですぐローカルでサービス再現でくるのをあの規模でやっているのはすごい
• ユニットテストでカバーしない・もしくは信頼しきらない体制をとっているのはとてもクレバー、 レイヤでちゃんとテストの役割を分けているのもいい
• ビルドとデプロイサイクルを短くする取り組みがすごい

グローバル展開を支える量子的なサービス設計(中野 拓)

• 観測する人によってバックエンドは理解が変わる
• 実験したほうが早く正解にたどり着ける
• モバイルのバックエンドに求められること
  • リリースのコストが低い
  • 非公開にできる
  • そのために施策を数打つ土台にならなければいけない
  • アドホックな障害対応など
  • データの最終防壁
• メルカリのバックエンド
  • 汎用性とかにはこだわってない
  • RESTなども守っていない
  • 公式クライアントにだけ合わせている
  • データは一貫性にしているが、コードは朝令暮改
  • 一貫性のない修正に耐えられるようにコストを支払うべき
• 使っているフレームワークはDietCake
  • 薄いフレームワーク、ほとんどなにもしてくれない
  • 開発の速さが優先されている
  • 1週間でリリースしてから全削除みたいなことをよくやる
  • ガード節が結構使われる
• エンジニアリングだけでこれを解決しない
  • 自動テストが作り的に辛いのでQAやテストでカバー
  • 品質が心配ならSREにすぐ戻せる環境を作ってもらう

考察

• これまでの開発のルールへのアンチテーゼのような話に思えつつ、現場感のあるいい話
• もちろんこれができればDeveloperとして理想的かもしれない、ただそれを支えるCS/SRE/QAなどがいなければ実現できない
• エンジニアとしての理想でなく事業理想が開発に反映されていていい

アプリファーストの影で頑張るWebの話(坂本 結衣)

• UniversalLinks/AppLinksに対応している
• Amp 商品ページがすでに数万ページがインデックスされている
• Web側の取り組み
  • アプリ誘導
  • 商品やユーザー情報のシェア
  • 日スマホユーザーへの認知・SEO
  • 新たなユーザー層にリーチできている
  • 1年で3倍、メディア露出など
  • PVは10倍増
  • Webのパフォーマンス改善はSREチームと一緒に改善している
  • システム構成
  • jQuery/Redux React
  • アプリと共通のAPIを利用
  • 1ソースで複数リージョン
  • １日に5-6回はリリース
  • 専任はいない
• 課題
  • マルチリージョン対応
  • SEO課題
  • デザインフィットと実装工数

考察

• アプリファーストな会社でWebの役割はリファラルと広いユーザー層の獲得
• 専任がいないのが意外だけど裁量があるからプロジェクト単位での動きでもなんとかなっているのかな
• 数値の伸びがアプリにも左右されるので負荷の見積もりなどが見にくそう

メルカリiOSアプリ開発の現状とこれから(石川 直樹)

• 現状とこれから
• 体制はエンジニアがそれぞれPJ所属、定例で共有
• 開発は自由なMac
• 開発現状
  • 最初は3年半前にリリース
  • 8:2 ObjC:Swift
  • ReactiveCocoa/APIKit/Result/ObjectMapper/Snapkit
  • MVVM
  • 1画面1Storyboard
  • ABテストを考慮して実装、ロールアウトもしやすい実装
  • 社内でアップデートテスト・QA・CI
  • SlackBotでBeta版配布やitunesへのアップデートができる
• 開発今後
  • リリースサイクルをadhoc -> 2weekごとに
  • masterブランチでそれぞれリージョンごとにビルドする
  • マルチソース、マルチライブラリで動かせるようにする

考察

• 思ったほどモダンなことはしてない気がした
• 3年もやっている＋ABテストが走っているとなるとやはりSwift化などは難しいんだろう
• 配布やアップロードまでSlackBotでまとめているのはすごい

high意識Android(高山 征大)

• JP4, US 2, UK 1
• PJごとに1,2人
• 時差の課題
  • 6:30 早朝にMTG
  • 効率は上がったけおど、起きれないこともある
  • ScreenHero
  • 同期的にレビューするサービス
  • 帯域も広い
  • 思いレビューじに役立つ
• リファクタリング
  • 案件のスケジュールに入れる
  • ファクトを残しやる理由を作る
  • テストでカバーしてQA負荷を下げる
• ID基盤
  • SngleSignOnを実現する
  • iOS/Androidチャレンジ、kotlinやgRPCを試す
  • アメリカだとgRPCで不具合

考察

• ライブラリに最新の技術を試すのは保守性大丈夫なんだろうか、枯れたもの使うのがベストエフォートなきがする
• テストから導入するのは良さそう
• 規模の割にエンジニア少ない、採用が厳密なんだろうか
• 時差の問題は結局ルールと仕組みで解決するしかないのか・・・

エンジニアの組織と採用

• メルカリの採用の全体感
  • エンジニア70名、1年で2倍くらい
  • 各ポジションも2倍
  • メインはリファラル採用
  • ドリンクミートアップやカンファレンス経由
• ソウゾウの採用
  • 2人から1年で20人
• どんな人が来るか？
  • メルカリのエンジニアのブランディングができていて、技術アピールができている
  • そういった環境に身を置きたい人が来ている
  • ソウゾウは採用方針を意図的にメルカリと変えている
• 面接で見ること
  • 技術課題はプルリクを出す
  • プロダクトをどう改善したいかを聞く
• 採用時の技術課題の選び方
  • ポジションごとに異なる、オフラインでやってもらって1週間後くらいにプルリクで見る
  • ホワイトボードみたいのもやっている
• 言語ごとにカルチャーが異なるのでどういい部分を見つけるか？
  • SIの上の方の人もとっている
  • PSRのような一般的なものは知っているので差が出ないと考えている
• 不便への慣れ
  • 新しい人の「ここおかしい」は重要、違和感を見つけ解消できる仕組みづくりをする
• 評価について
  • Qごとに人事評価
  • 昨日開発への貢献を全社の目標に対してブレイクダウンしたものを聞いている
  • エンジニアは技術評価もしている
  • 20人くらいまでは特に評価の仕組みはなかった

全体所感

• 評価や制度はあまり変わったことをしていない印象
• ただそもそものエンジニア組織の体制がスピードを重視したものになっているし、それで技術的負債を作っても 解消したり、解消を評価する制度があるのだと感じた
• メルカリはソウゾウと比べて硬い仕組みを使っているとのことなのだが、QAやSREでとてつもない技術力があるのを感じた
• エンジニアが事業理由に下手に邪魔されずに開発に集中できているからこそ今の体制があるんだと感じた
• 全体的に面白かった

このあとTechShopに3DCADのワークショップに行くので帰ります