本記事はZOZOテクノロジーズ アドベントカレンダー#2の25日目の記事です。

こんにちは。ZOZOテクノロジーズのそのっつです。ZOZOテクノロジーズではSREスペシャリストという肩書で、プラットフォームSREチームのリーダーとMLOpsチームを兼務で担っています。

約一年前の2020年1月に SRE Next 2020 にて ZOZO MLOps のチームリーディングとSRE (Engineering) というタイトルで私のチームリーディング術についての発表を行いました。それから約一年が経とうとしているので、一年の振り返りの意味も含めて、アップデートしたいと思います。

Image for post
Image for post

一年間の変遷

チームリーディングで気をつけていること


LINE DEVELOPER DAY 2020 にお声がけ頂きまして、LINEの @joohounsong さん、メルペイの @jollyjoester さん、そして私 ZOZOテクノジーズの @sonots で「エンジニアの成長を支えるOSSの価値と企業文化」というテーマで2020/11/26にトークをしてきました。

以前会社の techblog にも書いた OSS ポリシーの件でお声がけ頂いた経緯になります。

  • (1) 各企業のOSSの取り組みについて
  • (2) 各企業のOSS文化について
  • (3) 企業としてOSSに注目している理由
  • (4) OSSプロジェクトへの期待

について3社(者)交えてお話させていただきました。

Image for post
Image for post

ZOZOテクノロジーズでは、「社員がOSS活動しやすいようにする」というのをゴールに掲げて、2020年4月にOSSポリシーを策定しました。詳しくは techblog の方にも書いていますが、弊社のOSSポリシーには、以下のような特徴があり、非常にOSS活動がしやすい環境になったと思ってます。

  1. 業務時間中であっても指示なく自発的に作ったソフトウェアは個人のものにできる(例えば.emacsや.vimrcなどを指していますが、それに限りません)
  2. 業務時間中に指示があって書いたソフトウェアでも著作権譲渡申請の許諾によって個人のものにできる
  3. 従業員が自己の所有するOSSプロダクトに対して自己が業務で作成した著作物を取り込む場合、著作権譲渡申請がなくても個人の著作物にできる

合わせて、社内的にはOSS公開ガイドライン、OSSコントリビューションガイドライン、OSS利用ガイドラインを用意して、OSS活動しやすいように下地づくりを行いました。

特に、OSS利用に関しては、ライセンス違反をすると、損害賠償請求、ソースコードの開示、刑事罰、レピュテーション(信頼)の低下、システムのクローズ、といった大きな問題につながりうるのでガイドラインを用意しておくことが大事です。これは外注したシステムについても同様であるため、技術職だけではなく企画職にも周知して、技術職の検品フローを組み込むなど対策する必要があります。このような注意事項について、まとめることができました。

文化としては、まだ策定したばかりというのもあり、これからOSS文化を根付かせていこうとしているフェーズです。GitHub 上に会社の org はありますが、弊社発信の著名なOSSがあるというわけではなく、まだまだコレからだと思っています。

他社(者)のOSSにコントリビューションするような事例は増えてきていて、例えば Treasure Data 社が公開している digdag というOSSに対しては弊社に7名のコントリビュータがいて、世界最多コントリビュータを抱える企業なのではないかと思っています。

また、OSSを自作して公開するようなメンバーも増えてきていて、例えば @trsnium は Kubernetes や Digdag の Operator を自作して公開していて、彼が「著作権譲渡申請」の適用第一号になっています。また、今年度新卒入社の takezyou 君は Ansible のコードを文法チェックする ansible-lint の GitHub Action を自作して公開しており、新卒メンバーからこういうOSS活動のアウトプットが出てきたのは、OSSポリシーを策定して本当に良かったと思えた事例でした。

企業としてOSS活動を奨励している理由としては、使わせて頂いているのだから還元すべきという業界貢献の側面と、技術アピールの側面があります。また、OSSは問題があった場合に自分たちでコードを読んで問題解決することができるので、サポートに問い合わせて返答を待つよりも、能動的に素早く問題解決できる可能性があります。もちろん技術力が必要になりますが、そういう問題解決の方法が取れる強い組織にしたいという想いを持っています。また、個人的にもOSSのコードを読んで技術力を高めてきたというのがあるので、弊社のメンバー達にも同じように技術力を積んでほしいという想いがあります。OSSは納期ドリブンではなく、クオリティファーストで活動しているものが多いので、綺麗でメンテナブルなコードとはどういうものなのかを学ぶ上ですごく勉強になります。

OSSポリシーは策定しましたが、企業文化として根付かせるにはまだまだコレからだと思っています。トップダウンとしては、OSS活動(や技術ブログ公開)を評価項目に盛り込む形で支援しており、ボトムアップとしては、OSS活動の実例を背中で見せながら、けしかけて行くことで広げていきたいと思います。


11/5 に開催された弊社のテクノロジー Meetup で ZOZOTOWNのシステムリプレイスについての発表を行いました。

現在私は、「プラットフォームSREチームができました」の記事で記載しているようにZOZOTOWNのリプレイスプロジェクトに携わっています。ZOZOTOWNのリプレイスプロジェクト自体については2020年1月から戦略立案の立場で関わり始め、2020年4月からプラットフォームSREチームを作ってSREとして本格的に関わり始めました。

本 Meetup では、ZOZOTOWNのリプレイス戦略立案に携わっている私の方から、2017年から始めているZOZOTOWNリプレイスプロジェクトのおさらいを行い、2020年度以降の新体制と新アーキテクチャについて共有し、この半年で実現してきた成果について発表させて頂きました。また、リプレイスプロジェクトに関わっている弊SREチームメンバーの新卒氏と、バックエンドチーム2名から自分たちの成果について詳細を話して頂きました。

現在、我々はモノリスアプリケーションをマイクロサービス化しながらリプレイスを進めようとしています。これは、モノリスで開発を進めてきて課題になっている、(1) デプロイの順番待ち、(2) 影響範囲が大きすぎてライブラリの更改が難しい、といった問題を解決し、開発効率・体験を向上させることが狙いです。

Image for post
Image for post

4月から半年リプレイスプロジェクトを進めてきて数々の成果が出せましたが、まだまだ道半ばでやらなければいけないことが山のようにあります。リプレイスプロジェクトに戦略立案から携われて、アーキテクチャやソフトウェアデザインもできる楽しいフェーズだと思います。

https://docs.google.com/presentation/d/1nANtPZnVJODpVHZYSKrcvWy2KuwiQ5dGMSwAYA4myTE/edit?usp=sharing

是非、資料を参照して興味をもっていただけたらプロジェクトにJOINして頂けると幸いです。特に、Java と Golang それぞれの強力なバックエンドエンジニアを募集しています。是非よろしくおねがい致します。


Kubernetes meetup 〜オンプレ?クラウド?事例共有会〜 での登壇依頼を受けて、GKEとEKSの話をしてきたので資料を置いておきます。

https://docs.google.com/presentation/d/17d33MfFhaVEtJ6dhqxRf7N3JHrqeIBFBStHwSoDyrtQ/edit#slide=id.p1

会の趣旨的に、クラウドのマネージドサービスを横断的に解説すると良さそうだと思い、こういうテーマにしました。GKEとEKSのどちらかを使っている人達は多いと思いますが、両方を「本番で」「現役で」使っている人間は少ないだろうと想像しているので貴重な資料になったのではないかと思います。誰かのお役に立てれば幸いです。

ZOZOテクノロジーズ社内でも、両方を現役で使っているメンバーは、チームを兼務している私だけで、最初はチームメンバーに登壇依頼をフォワードしようと思ったのですが、この厚みで話せるのは私しかいないという話になり、自分で登壇することにしたという裏事情もあったりします。

まとめでも述べていますが、「GKEとEKSのどちらが良い」ということではなくて「GCPかAWSかという全体を見て選択する」ことになるかと思っています。それぞれ多少の差異はありますが、切磋琢磨している印象です。差分で混乱した時に本資料が役に立てば幸いです。


著者である小野さんは、起業したベンチャーを老舗金融起業に売却してその老舗企業でCTOを務めた人物である。私が現在、所属している企業と似たような状況にあるのではないか?と予想して読んでみた所、示唆に富んでいるところが多々あったので、久しぶりにブログにメモを残しておく。

第1章「谷」を埋めるな、「山」を作れ

特にベンチャーにおいては、競合他社がすでに実現している機能を実装するのに時間を費やすのではなく、自分たちの特色となる「山」に時間を費やすのが大事

コンサルを入れて実績のある方法論を導入して失敗するチームもある。

第2章「ハンマーと釘」の世界の落とし穴

新しい技術が日々生まれ、私たちエンジニアは「手にしたハンマーで釘を打ってみたい」衝動にかられながら仕事をしている。

とある企業のプロジェクトでは、新技術が出るたびに「新技術で既存の製品を作り替える」ということを繰り返していた。「新技術が出たからといってむやみに使わない」をチームの方針として周知徹底した。

「これから来そうだという技術は習得しておき、使うべきときがくるまでは無理して使わないように」という号令を出した。

ダメなアイデアが生まれる5つのパターン

  • プレッシャーを受けて無理やり考えるとき
  • 役職者の思いつきを取り入れるとき (的外れかどうかを吟味していない)
  • 変に差別化しようとする (差別化を目的にする)
  • 流行に安易に寄せるとき
  • 「この機能が追加されれば大型案件がとれる」というとき

ベンチャー企業と老舗企業をつなぐバイモーダル戦略

2つのモードをうまく活かし合いながら、切磋琢磨する

  • モード1: 失敗が許されない領域に適した安定性重視
  • モード2: 時代の変化にいち早く対応するスピード重視
Image for post
Image for post

稟議書を見直す2つのタイミング

うまくいっておらず、うまくいかないことが見えているのに計画が立てられているからといってそのまま進めるべきではない。リセットボタンを押すしかない。どういう時か

  • ぜんぜんうまくいっていないとき
  • 外敵要因が変わったとき(業界にイノベーションが起きた、など)

会社は大きくすべきか?

「スパン・オブ・コントロール」(人員適正範囲)を超えているなら大きくすべきではない。

第3章「ラストマン戦略」で頭角を表せ

「ラストマン戦略」とは、グループ内で自分が一番になれそうな領域を決め、最後の砦とも言うべきスペシャリストを目指す成長戦略。

領域は、最初は一つのツールや技術といった小さなものからスタートして良いし、一番を目指す範囲は最初は所属チームのような小さな範囲からで良い。そこから徐々に大きくしていく。

全ての要素について満点を目指すの止め、代わりに特定分野では満点のさらに上を目指していく。

マニュアルにとらわれず、むしろマニュアルがないことにこそ取り組む

いろいろなエンジニアのタイプがいる。同じタイプのエンジニアを集めるよりもいろいろなタイプのエンジニアを集めるのが良い。他人の劣っている能力ではなく、優れた能力に目を向ける。

戦略的に「見せ場」「強み」を見せる。信頼残高を増やしていく。


Cloud Native Days Tokyo 2020 にて「ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み」というタイトルで現在業務で絶賛取り組んでいる ZOZOTOWN のリプレイスプロジェクトの紹介と、ID基盤のリプレイスの話をしてきました。

https://docs.google.com/presentation/d/1pplRYOYTPJh9XRNEf3Y8QS5kzddfIqiN5pqUQM2Tcoo/edit?usp=sharing

動画はこちらです。

更新系ワークロードのリプレイス方法や、また EKS でセキュリティ強度を上げるために取り組んだ内容など、自分たちのことながら非常に示唆に富んだ内容になっていると思っています。是非ご参照ください。

以降は、今回の発表の個人的な感想です。

私個人として今回の発表の一番の目玉は、私自身の発表というよりも、幣チームメンバーの亀井(亀ちゃん)に発表してもらったことです。ID基盤についての設計思想から何から整理して最高の発表資料を仕上げてくれました。私は軽くレビューをしただけで何もする必要がありませんでした。

元々ID基盤のインフラは、1年ほど前にオンプレ歴は長いがクラウドも Kubernetesも初心者だったEnKUMAと亀ちゃん、そして私とインダクターの4人で始動した紆余曲折ありながらも進めてきたプロジェクトでした。今となってはチーム規模も大きくなり、新卒メンバーもJOINしたりと大きく変わっていますが、当初はオンプレとクラウドネイティブアーキテクチャの考え方の違いを教える所からスタートし苦労もありました。しかし、年下であるインダクターからも貪欲に学ぼうとする2人の姿勢は端からみていても感心できるものでしたし、新しい技術体系にしっかりキャッチアップできたのは2人に素直さがあったからだと思います。アンラーニング大事ですね。

この時のオンボーディングの話は、インダクターと EnKUMA の二人が同じく CNDT2020 で発表してくれているので、是非そちらもご参照ください。

クラウド初心者で Kubernetes 初心者だった亀ちゃんがここまで成長して、いまやこのID基盤という案件のリードを任せられているというのは非常に頼もしいです。EnKUMA も、横断して複数の案件を見て技術の横展開をしたり、こぼれそうな玉を拾ったり、いざとなった時に頼れるメンバーとしてバリバリ活躍してくれていて頼もしいです。自慢のメンバー達です。

リプレイスプロジェクトは、スキルチェンジも課題になるのが常なので、スキルチェンジに成功した2人がいるというのは全社的にも非常に重要で、今後もその流れを辿っていけるのではないかと期待されています。2人はその流れを先導する役割を今後担っていってくれることでしょう!今後も期待しています!

また、今回のようにチームメンバーに発表をしてもらって、そのっつ個人のプレゼンスというよりは、そのっつチームのプレゼンスを上げていこうと思っていて、どんどん発表機会を振っていくので引き続きよろしくお願いします! >幣2チームメンバー


背景: CNDT2020 フルオンライン開催とセッション公募延長のお知らせ にある通り、今年の CloudNative Days Tokyo はオンラインで開催され、講演方法は次の3つから選択してください、とのことであった。

(1) ご自宅からのリアルタイム配信

(2) 録画による配信(事前に録画データを提供いただきます)

(3) ネットワーク・録画環境に不安がある場合は、配信会場にお越し頂き講演(感染防止対策を徹底します)

そこで、今回は「(2) 録画による配信」を選択してみたので、調べた自宅収録のやり方を記録しておくメモ。

自宅収録ツール

リアルタイム配信の場合は次のような映り方にするとのことだったので、できるだけスライドと自身を合成して収録してみる。

Image for post
Image for post

このような収録には YouTuber 御用達の OBS を使うとできるようだ。OBS の使い方については YouTube に解説動画がたくさん上がっているので習得するのは難しくない。例えば私はこちらの動画で学ばせてもらった。
【初級者編】日本一わかりやすいOBS配信方法 Youtube Facebook 生配信

動画の切り貼りについては Mac であれば Quicktime もしくは iMovie でも十分にできるようだ。最初は Quicktime を使ってみたのだが、私の環境では保存時にエラーが出てイライラしたので iMovie で編集した。
iMovieで動画をトリミングする方法やその他の機能まとめ

iMovie の場合は音の波形も表示されるので、スピーチの範囲を波形からあたりをつけて、クリップを分割 > 削除、という流れで不要な範囲を削っていくとリズムよく編集できた。


新型コロナウイルスの影響でIT勉強会が軒並み中止または延期になってしまっている昨今ですが、4月24日に Forkwell さんの主催で大規模なオンライン勉強会 Infra Study Meetup #1 「Infrastructure as Code」が開催され、LT発表をしてきました。最終的には 2400 人を超える参加者表明があったようで、最初こそ配信トラブルがあってしまいましたが、非常に有意義な会だったのではないかと思います。

内容ももちろんそうですが、コロナの影響で勉強会が開けてない今、道を切り開く良いチャレンジだったのではないかと思っています。他の勉強会も続いてくれるキッカケになって、リモートで開催される勉強会が増えていくと個人的には嬉しいです。主催の Forkwell さん、まつもとりーさんありがとうございました。

さて、今回はリモートの勉強会で Infrastructure as Code の話をするということで、私が最近考えていた「フルリモートにおける Infrastructure as Code の効果」について発表をしました。資料と動画のURLはこちらになります。

https://docs.google.com/presentation/d/1Ez4wURim60oG49KDZ0W25GEGfiEeUrG5-3Hw6fNbh2A/edit?usp=sharing

https://www.youtube.com/watch?v=_bLzgd_UlbU&t=9140s

リモートにおいてもストレスなく作業できる環境を整える、ということについては、実は私にとってはZOZOテクノロジーズに入社してからの課題の1つでありました。

ZOZOテクノロジーズのオフィスは、青山、幕張、福岡、そして今年の4月から株式会社アラタナも吸収合併され宮崎オフィスも増え、多拠点に跨っています。私自身は青山オフィス勤務なのですが、MLOpsチームの業務の性質上、福岡研究所や幕張オフィスのメンバーと一緒に仕事をすることが多く、拠点が離れていてもスムーズに仕事ができるような仕組みが必要でした。

また、ZOZOテクノロジーズは 2019年8月からリモートワーク制度を導入しており、チーム内外でリモートでも滞りなく業務が進むような仕組みが必要でした。

さらに、2020年4月からは私自身がZOZOTOWN SRE(リプレース)チームのリーダーも兼務で務めることになり、今までは別チームとの協業だったのですが、これからは同じチームで青山と幕張の2拠点に跨って1つの仕事をするという難題を与えられ、コミュニケーション不足に陥らずにスムーズに仕事ができるような仕組みを考案する必要がありました。

その上で、新型コロナウイルスの影響による外出自粛要請です。

取った施策としては、もちろん Infrastructure as Code や CI/CD 化だけではないのですが、リモートでもコミュニケーション齟齬を少なくして働くための「前提」として考えている節が私の中にはあって、今回の発表でそれを言語化させていただきました。

インフラ構築をコード化することで、リモートでもレビューでき、CI/CD パイプラインの仕組みを整えておくことで、いつデプロイされたのかが把握しやい。このような仕組みを整えておくことが非常に重要だと感じています。

フルリモートと Infrastructure as Code、CI/CD は相性が良いので、是非やっていきましょう╭( ・ㅂ・)و ̑̑


2019/04/01付けでZOZOテクノロジーズにMLOpsチームができましたという記事を書きましたが、2020/04/01付けでプラットフォームSREチームというものができ、兼務で2チームのリーダーを務めることになりました。

プラットフォームSREチームというのは、雑に言うとZOZOTOWNリプレイスプロジェクトのSREチームになります。正確にはちょっと違いますが概ねそう捉えて頂いて差し支えないかと思います。ZOZOTOWNリプレイスプロジェクト自体は2017年頃からスタートしているのですが、私も参入してリプレイスの方針を仕切り直してこの4月から再始動する予定です。私の役割としては、SREチームのリーダーというのももちろんありますが、リプレイス戦略を練るアーキテクトとしての役割も担っていきます。

リプレイスプロジェクトという、ただでさえもややこしいものをやる必要がある中、2チームの現場リーダーを兼務でやってくれという無茶振りをされつつ(まだ複数チームを束ねるグループリーダーの方が楽そう)、コロナで顔を合わせて仕事ができない中チームの立ち上げを進めていきます。進捗は出来次第、外部登壇などで公開していきます。

そのっつ (Naotoshi Seo)

CRuby, Fluentd, and Chainer committer. SRE, Specialist at ZOZO Technologies, Inc. ex-DeNA.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store