ZOZO MLOps のチームリーディングとSRE (Engineering)

SRE Next 2020/01/25

株式会社ZOZOテクノロジーズ

開発部 MLOps リーダー、SRE スペシャリスト

瀬尾 直利

Copyright © ZOZO Technologies, Inc.

2

瀬尾 直利 (そのっつ)

株式会社ZOZOテクノロジーズ

SRE スペシャリスト

開発部 MLOps リーダー

CSIRT兼任

Google Cloud 担当

​

Twitter/GitHub: @sonots

CRuby、Fluentd、Chainer コミッタ

​

© ZOZO Technologies, Inc.

Disclaimer (免責事項)

ZOZO MLOps のチームリーディングと銘打っていますが、

筆者であるそのっつ流のチームリーディング術であり、�所属企業であるZOZOテクノロジーズの標準手法というわけではありません

4

https://zozo.jp/

• 日本最大級のファッション通販サイト
• 1,200以上のショップ、7,300以上のブランドの取り扱い（ともに2019年6月末時点）
• 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商品を掲載
• 即日配送サービス
• ギフトラッピングサービス
• ツケ払い など

© ZOZO Technologies, Inc.

5

https://wear.jp/

• 日本最大級のファッションコーディネートアプリ
• 1,300万ダウンロード突破、コーディネート投稿総数は900万件以上（ともに2019年9月末時点）
• 全世界（App Store / Google Playが利用可能な全ての国）でダウンロードが可能
• 200万人以上のフォロワーを持つユーザー（WEARISTA）も誕生

© ZOZO Technologies, Inc.

6

https://zozo.jp/multisize/

​

• 身長と体重を選択するだけで理想のサイズの商品が見つかる新しい洋服の買い方
• ZOZOSUITで得た100万件以上の体型データを活用し、20～50サイズのマルチサイズ（多サイズ）に展開
• 2019年秋冬アイテムから、人気ブランドのマルチサイズアイテムを販売開始

【参加企業】

　株式会社アーバンリサーチ、株式会社ストライプインターナショナル、

　株式会社デイトナ・インターナショナル、株式会社パル、株式会社ビームス、

　株式会社ベイクルーズ、MARK STYLER株式会社、リーバイ・ストラウス ジャパン株式会社　　など

© ZOZO Technologies, Inc.

ZOZO MLOpsチーム

2019年4月に発足

• 入社３ヶ月後　
• 発足時2名 → 現在4名
• ZOZO研究所があったが、本番にML機能を出せていない課題があった

MLOps チームのミッション

• MLプロダクトを世に出すために必要となるモデル作成以外の全てのエンジニアリングを担当し、MLエンジニアが優れたモデルを作ることに注力できるようにする
• 特にMLエンジニアが(一般的に)得意としていないプロトタイプからプロダクションレベルへの引き上げフェーズで成果を発揮することがミッション

MLOpsチームにおける私の役割

Engineering Manager (EM) 兼 Tech Lead

• 弊社では、チームによっては EM (いわゆるリーダー) と Tech Lead の二人がいる
• 私は事実上の兼務

EM としての仕事

• 他チームとの調整
• 人事評価、採用活動、キャリア相談

Tech Lead としての仕事

• 技術的なリード

チームが挑戦してきた課題

Phase1: ML機能を１つプロダクションに出す

• チーム自体のオンボーディング(立ち上げ)
• レベルの高い(技術選定が妥当である、安定している、十分に高速)インフラを構築できることを示す
• MLOpsチームへの社内からの信頼を得る → 次の仕事を得る
• 社外からの技術プレゼンスを得る → 優秀な人材の採用に繋げて仕事の幅を広げられる下地を作る
• １つ目なので社内外からの信頼度はまだ低い状態

Phase2: ML機能を複数プロダクションに出す

• ML機能をさらに出すことで、再現性があることを示す。
• それにより、社内外からの信頼度をさらに高める。
• 新メンバーを受け入れて、新メンバーのオンボーディング

Phase3: ML機能の量産体制を整える, e.g., ML基盤？

​

イマココ

チームリーディング術

チームリーディングで気にしていること

• チームとしての方向性を定義する
• スムーズなプロジェクト進行
• 心理的安全性
• リーダーがボトルネックにならないようにする
• メンバーがスキルアップできる環境であること
• ルールより文化

チームとしての方向性を定義する

なぜわざわざチームを作ったのか軸がブレないようミッション（目標）を定義

「 THE TEAM 5つの法則」より引用

チームリーディングで気にしていること

MLOps チームの目標

ミッション (意義目標)

• MLエンジニアが優れたモデルを作ることに注力できるようにする
• 特にプロトタイプからプロダクションレベルへの引き上げフェーズで成果を発揮

成果目標

• Phase1: ML機能を１つプロダクションに出す
• Phase2: ML機能を複数プロダクションに出す ← イマココ
• Phase3: ML機能の量産体制を整える, e.g., ML基盤？

行動目標

• キーワードは「プロ意識を持つ」
• 期ごとの目標は個人ごとに立ててもらう（もらいたい）

​

チームとしての方向性を定義する

プロ意識を持つ

そのっつの考えるプロとは

社内の期待を裏切らない

• 期日を守る
• 遅れそうな場合は、調整をするとか
• 一度引き受けたものを後になってやらないと言ったりしない

レベルの高いインフラを構築できる

• 技術選定が妥当である
• 安定している
• 十分に高速
• 負債の少ない

行動目標

技術的負債をなくすコツ

• コードだけを見て意図が通じることを意識する
• 設計結果だけではなく、調査過程も記録に残す
• やったほうが良いがまだやれてないだけなら TODO コメントを残す
• OSS の社内プライベート fork を作らない
• PRを送ってマージされるまでやり切る

チームリーディングで気にしていること

• チームとしての方向性を定義する
• スムーズなプロジェクト進行
• 心理的安全性
• リーダーがボトルネックにならないようにする
• メンバーがスキルアップできる環境であること
• ルールより文化

スムーズなプロジェクト進行

調整ごとは早めに

• 仮予約 - まだ本決まりしていないが、そんな依頼をするかもとジャブを打っておく

プロジェクト進行上のボトルネック(クリティカルパス)を潰す

• 依存があるタスクをなるべく作らない
• 作業を止めるよりは次善の策を捻り出して進める
• 後で修正するコストよりも、作業が止まるリスクの方がビジネス的に大きい
• 他のチームに依頼を出さずにすむような業務フローの設計
• こちらでPRを作ってレビューとマージをしてもらうだけにする, etc

チームリーディングで気にしていること

心理的安全性

思いついたら即相談

• 朝会や定例を待たずに、すぐ聞いてと言ってある

仕組み(orコード)を憎んで人を憎まず

• レビューの指摘は、あなたを非難しているわけではない
• ミスがあった時も、仕組みでカバーできないか考える

わからないことは聞ける雰囲気

• 新しい技術やツールをメンバーに先に調査してもらって、むしろリーダーが教わる
• リーダーでもわからんものはわからん → 皆わからんものは質問しやすい（はず？
• あとは、馬鹿な話をするなど(オヤジギャグなど

チームリーディングで気にしていること

リーダーがボトルネックにならないように

(特に) コードレビュー

• ミーティングが多くてレビューできない場合がある
• 最低一人の Approve は必須
• リーダーの Approve が必須なわけではないのがミソ
• (あとでマージされたPRにコメントすることは正直ある
• 急ぎでレビューして欲しい場合、Slackメンションを飛ばしてもらう
• 今は Pull Panda 導入 → GitHubでレビューワにアサインするとDMが飛ぶ

リーダーは必須な(実装)タスクを握らない

• ミーティングが多くて進まないことがある
• 自分がボトルネックにならないようにタスクに集中すると、今度はリーダー業が疎かになる
• 急な差し込みがあった場合の余裕も持てる

​

チームリーディングで気にしていること

チームリーディングで気にしていること

• チームとしての方向性を定義する
• スムーズなプロジェクト進行
• 心理的安全性
• リーダーがボトルネックにならないようにする
• メンバーがスキルアップできる環境であること
• ルールより文化

スキルアップできる環境であること

• モチベーションコントロール
• やりたい仕事とチームの仕事が一致しているか
• 目標 x 報酬
• 1 on 1 でのヒアリング
• コーチング
• 当たり前のレベルを引き上げる

1 on 1 でのヒアリング

原則: 1 on 1 はメンバーの時間

• リーダーがメンバーに物申す時間ではない
• メンバーが何を話したいか考えておく
• どこにモチベーションがあるのか、何にストレスを感じているのか

KPTとの違い

• 会議室を取ってやるのでオープンスペースでは話せないようなことを話せる
• 例) キャリア相談、給与の話、会社に対して物申したいこと

リーダーとしてやること

• Action Item の確認
• さらに上に投げる必要があれば投げる, etc

モチベーションコントロール

コーチング

基本的には「背中を見せる」スタイル

• 「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」
• by 山本五十六

サポートの仕方は人（とその人のフェーズ）によって変えている

• 指示型: 具体的な指示命令を与え、仕事の達成をきめ細かく監督する
• コーチ型: 引き続き指示命令を与え、仕事の達成をきめ細かく監督するが、決定されたことも説明し、提案を出させ、前進できるように援助する
• 援助型: 仕事の達成に向かって部下の努力を促し、援助し、意思決定に関する責任を部下と分かち合う
• 委任型: 意思決定と問題解決の責任を部下に任せる
• by 1分間リーダーシップ―能力とヤル気に即した4つの実践指導法

​

スキルアップできる環境であること

当たり前のレベルを引き上げる(1)

コードがあったら読むの当たり前

• OSSの動きが不可思議だったら、外から動作を推測するよりコードを読んだ方が確実
• 社内エンジニアが書いたアプリなら、それもコードを読んだ方が確実

strace でシステムコール追うのも当たり前

• strace コマンドの使い方をまとめてみた : sonots:blog
• 例) パーミッションエラーが出ているがファイル名がわからない？よし strace だ

ネットワークトラブル時は tcp パケット追うの当たり前

• tcpdump コマンドの使いかたをまとめてみた : sonots:blog
• 例) RSTが返されてるとか、応答自体が来ていないなどの切り分け

コーチング

当たり前のレベルを引き上げる(2)

技術ドキュメントを書くの当たり前

• 検討結果はもちろん、検討過程も記録に残す
• 色々なやり方があったら「〜をする５つの方法」のようなQiita記事を書くなど
• 例) digdag の rb オペレータで bundle exec を使う３つの方法

技術発表をするの当たり前

• 例) 類似アイテム検索機能についてGoogle Cloud Next '19 in Tokyoで技術発表をしました

OSSにバグがあったら報告するの当たり前

• なんならパッチを送るのも(ry
• 例) Fix examples to work #970 - treasure-data/digdag

コーチング

チームリーディングで気にしていること

• チームとしての方向性を定義する
• スムーズなプロジェクト進行
• 心理的安全性
• リーダーがボトルネックにならないようにする
• メンバーがスキルアップできる環境であること
• ルールより文化

ルールより文化

ルールを作ることの欠点

• 覚えないといけないので大変
• 守っているかどうかのチェックをしないといけないので大変
• 適切に改訂しないと陳腐化する
• 守ることだけ考えて思考停止する

文化として染みつかせる

• 意識しなくても当たり前にやる

ルールをできるだけ作らないことがルール

チームリーディングで気にしていること

MLOps チームの文化

• 心理的安全性(再掲)
• 思いついたら即相談
• 仕組み(orコード)を憎んで人を憎まず
• わからないことは聞ける雰囲気
• フェーズによって柔軟に変える
• やってみてダメなら辞める
• 技術力でぶん殴る

​

ルールより文化

フェーズによって柔軟に変える

フェーズによってハマるやり方は異なる

• 例) 開発フェーズではスクラムで良かったが、運用フェーズに入ると割り込みが増えてスクラムが機能しなくなってきた
• 例) 小規模の時は、全員が全てを見ることができたが、大規模になってきたら、専門職でチーム分けをしないと上手く回らなくなってきた
• フェーズによって、適切なタイミングで適切に切り替える

ひょっとしたら難しいことをやっているのかもしれない

ルールより文化

実例) Phase1におけるタスクアサイン

チームが立ち上がったばかり

• 扱っているプロジェクトもメインではまだ１つだけ

理想とするチーム像

• 全員が全部できるスクラムのような体制
• 期日が近い時は他のメンバがサポートできる
• 体調不良で休んでいても他のメンバがサポートできる
• アラートが鳴った時は気づいたメンバなら誰でも対処できる

カンバンでタスク管理

• 着手しているタスクが終わったら重要なものから勝手に持っていってもらう

フェーズによって柔軟に変える

実例) Phase2におけるタスクアサイン

チームで同時に扱うプロジェクトが増えてきた

• 2020年1月現在で６プロジェクトを扱っている
• 全員が全部カバーするのは覚えることが多すぎる

(そのっつ以外は)１プロジェクトあたりメインとサブの２人担当制に変更

• カバーできるように最低でも２人
• コンテキストスイッチは減りやりやすくなった(らしい)
• メイン担当がアサインされたので責任感が出るようになった
• 課題 - 改善の余地あり　
• それでもまだ人数に対してプロジェクトが多すぎる
• (心理的に)サブ担当よりもメイン担当のプロジェクトを優先してしまう
• メイン担当PJの瑣末なタスク vs サブ担当PJの重要タスク

フェーズによって柔軟に変える

やってみて、ダメなら辞める

チーム（つまり人間）によってハマるやり方はことなる

• チームマネジメントで良くあるプラクティスを試してもハマらないことがある
• 前職とは人間が違う

試すコストを小さく

• ダメだったらすぐ辞める前提なら、試してみるコストは小さい。試しやすい

​

実例) 「20%ルール (業務時間の20%を個人プロジェクトに当ててよいルール）」を試してみたが、メンバが本業しかやらなかったので取りやめた

ルールより文化

KPT(A)

KPT (Keep, Problem, Try)

• 定期的に KPT の会を開いている (これ自体、最初は Try の１つだった

ポイント: Action まで決めて、次回実施したか確認をする

• KPT で振り返っただけで Action をできていないチームが多すぎる(経験上
• Action として実施できるものを最後に決める
• 頑張ります、のようなものは Try として出るのは良いが Action としては管理しない

リーダーとしてやっていること

• その日のうちに Action を実施
• 他チームとの調整が必要なもの
• さらに上の上司（部長、社長）に言うべきもの

やってみて、ダメなら辞める

技術力でぶん殴る

チームプレーのプラクティスも良いけど、とにかく技術力を持てという派

• 技術力があれば調整しなくて良いパターンがあることを教える
• 例) サービスメンテナンス時間を調整するよりも、ゼロダウンタイムで置き換えられるように実装する

SREのやり方をなぞっても技術力が伴っておらず問題解決できないのであれば意味がない

技術力でぶん殴れ ╭( ･ㅂ･)و ̑̑

ルールより文化

SRE (Engineering) 事例

技術力でぶん殴れ ╭( ･ㅂ･)و ̑̑

SRE (Engineering) 事例

• 実際に遭遇した問題と、問題の解き方
• 当たり前のレベルを引き上げる
• 仮説と検証のサイクル
• 神は細部に宿る

ZOZO 画像検索

• 画像からアイテムを検出
• ZOZOTOWN で販売している類似のアイテムを表示する

​

​

​

​

（一般的な）画像検索の基本

深層学習を利用してアイテム画像の特徴ベクトルを取得

深層学習を利用して画像からアイテムを検出

取得した特徴ベクトルを予め構築しておいた Approximate Nearest Neighbor（ANN）Index から類似検索

https://www.slideshare.net/erikbern/approximate-nearest-neighbor-methods-and-vector-models-nyc-ml-meetup

CNN

Feature

Chainer

Chainer

annoy

https://github.com/spotify/annoy

遭遇した問題

ANN コンテナの挙動が不安定

• メモリを使う場合と使わない場合があるという報告
• たまに異様に遅いという報告

初回のリクエストが遅い問題

​

ANNがメモリを使ったり使わなかったりする問題

コードが読めたら読むの当たり前

• https://github.com/spotify/annoy というライブラリを使っていたので読んだ
• インデックスファイルを mmap(2) with MAP_POPULATE して Linux の disk cache に載せていることがわかった

仮説と検証のサイクル

• 仮説: disk cache はコンテナで隔離されず共用になる？
• 確認すると、やはりそのようだ
• 仮説: 同一ホストと別ホストでコンテナを上げた場合の挙動が異なるのではないか？
• 確認すると、どうやらそのようだ
• mmap と free と ps と cgroup - sonots:qiita

​

ANNがたまに異様に遅い問題

仮説: disk cache に頼っているからでは？

• annoy はindexファイルを Linux の disk cache に載せて検索を高速化する設計
• disk cache なのでメモリから追い出される可能性がある
• 経験的にも disk cache に頼ると速度が不安定

対処

• Indexファイルを tmpfs (linux 標準のオンメモリファイルシステム)に置いた
• 確実にオンメモリ検索できるようになり速度が安定した　

初回のリクエストが遅い問題

デプロイ直後の１発目が異様に遅い

• レイテンシ監視を入れておいたので気づけた

仮説と検証のサイクル

• 仮説: 初回に何かキャッシュする実装になっている？
• アプリ実装上はそうなっていない
• ライブラリとしては Chainer (CuPy) を使っている
• 仮説: CuPy (cuDNN) autotune のせい？
• 初回に複数のアルゴリズムを試して 1 番速いアルゴリズムを選択する機能
• そうだった

Chainer (CuPy) コミッタ便利

神は細部に宿る

• 細部を追う技術力がないとZOZO画像検索を安定化させるのは難しい
• SREのプラクティスだけ真似してもダメ
• アーキテクチャだけ良くてもダメ

人事評価

採用活動

Engineering Manager (EM)としての他の仕事

人事評価

究極的には、リーダーの仕事はメンバーの給与をあげること、という考え

• メンバーが活躍できるようにサポートする
• メンバーが活躍できるようにコーチングする
• メンバーが活躍できるような仕事を用意する

メンバーが活躍できれば、結果は自ずとついてくる

採用活動 - We’re hiring

https://tech.zozo.com/recruit/mid-career/detail66/

まとめ

• チームとしての方向性を決める
• 背中を見せる
• 「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」
• ルールより文化
• 思いついたら即相談
• 仕組み(orコード)を憎んで人を憎まず
• フェーズによって柔軟に変える
• やってみてダメなら辞める
• 技術力でぶん殴る - プロ意識を持つ
• リーダーの仕事はメンバーの給与をあげること
• メンバーが成果を出せるようにサポートする

チーム立ち上げ期に行ったこと

• 会議体を決める
• コミュニケーション、開発ツールを決める

​

会議体を決める

• 朝会やる or やらない？
• やる
• 週定例やる or やらない？
• やらない: すぐに相談できるチームであれば、チーム内での週定例はいらないはず　
• プロジェクト内でのMTGは行う(福岡研究所とのMTG
• リーダーのみがでるスタイルだったが、メンバーも出すようにした
• KPT
• 途中からやり始めた
• 1 on 1
• 途中からやり始めた

​

開発ツールを整える

• Slack チャンネルを用意
• Wikiスペースを作り、ドキュメントを書くルール(第一案)を定義
• タスク管理方法を定義

常にブラッシュアップ

​

開発基盤を整える

• CI/CD
• リポジトリ、ディレクトリ構造、ブランチ戦略
• ルールとして明確化したわけではないが、レールはできた
• もっと良いやり方が見つかったらすぐ変えるので明文化もあまりしていない

​