株式会社ZOZO 技術本部 本部長の @sonots です。この記事は ZOZOのAdvent Calendar 2021のカレンダー1の最終回（25日目）です。
2021年度、ZOZOにとっても、私にとっても大きな変化が2つありました。1つ目が2021年3月に前CTOの今村が退任し、私が全社技術戦略を策定する役割とZOZOTOWNリプレイスプロジェクト責任者を引き継いだこと、2つ目が2021年10月にZOZOとZOZOテクノロジーズの組織が再編され、私も含む開発部門がZOZOに併合されたことです。
この記事ではその変化の中で私と組織がこの一年取り組んできたものをいくつか取り上げたいと思います。
全社技術戦略策定
2021年4月にCTO的な役割を引き継いで、個人的に一番変わったのは経営陣（当時はZOZOテクノロジーズ）との対話が増えたことだと思います。私の考えているCTOの役割と、経営陣の考えているCTOの役割についての認識のすり合わせから行わせて頂き、具体的に実施しようと思っている施策についても共有させて頂きました。
新たに実施した施策から一部抜粋して取りあげていこうと思います。
- 全社技術スタックの策定
- Java、Golang トレーニングの開催
- エンジニア採用基準の平準化および面接官の任命基準の策定
- テックリードの任命・除名フローの策定
全社技術スタックの策定
まず最初に全社ないしはプロダクト単位の技術スタック統一方針を策定しました。対象としている技術領域は、最も方針転換の影響が大きいと考えているプログラミング言語、インフラ基盤（AWS, GCPなど）、DB（RDMS）の3つです。
ZOZOでは、かつては特定の技術スタックを十数年以上使ってきていましたが、ここ数年でのM&Aなどの歴史的経緯から、組織毎に得意な技術スタックが異なるという状況が生まれていました。技術スタックがバラバラなため、以下のような問題が生じ始めていました。
- 技術スタックの幅が広く、会社としてどのような人材を採用すべきか判断に困る
- 必要となる技術スタックが異なるため、異動時に勉強が必要で立ち上がりに時間がかかる
- 隣のチームが困っていても技術スタックが異なるのでヘルプすることが難しい
- ガイドライン類もカバーすべき範囲が広すぎるので抽象的にしか書けない
- 教育コンテンツ・トレーニングの提供対象の判断に困る
- 社内ライブラリを開発しても、全言語で同等のライブラリを開発する必要がある
去年までは今後のZOZOTOWNのリプレイスの方向性などもあやふやな所があり、将来の技術スタックを定めることができる状況にありませんでしたが、私もZOZOTOWNリプレイスプロジェクトに関わり始めて１年以上たち、どのようなプログラミング言語やインフラ基盤を使うのかが定まってきました。また、4月から全社の技術戦略も見る立場になり、このタイミングでまずは技術スタックをある程度定めておかないと、今後の全社的な技術戦略を立てづらいと感じていました。
そこで全社技術スタックの統一方針を策定しました。技術スタックを統一しないと、人事(採用・異動)と教育面で困るため、全社で統一したほうが良いという想いです。一方で現状がバラバラすぎて今から統一するのは難しいので、せめてプロダクト軸で統一するという方針としました。
一部抜粋すると、全社の基準となる技術スタックを以下のに定義し、新たに何かを作る際は、特別な理由がなければこちらに沿うように依頼しました。こちらの技術スタックは全社向けにトレーニングを開催するなど、全社的にも積極的に支援しています。
| 種別 | 技術 |
|---|---|
| プログラミング言語（UI/UX) | iOS: Swift / Objective-C Android: Kotlin / Java Web: JavaScript / TypeScript |
| プログラミング言語（バックエンド) | Java Golang Python（ML・データ系の場合） |
| インフラ基盤 | AWS GCP（ML・データ系の場合） |
| DB（RDBMS） | MySQL なお、RDBMSが不得意な領域の場合は他のDBエンジンを検討 |
その他、例えば WEARリプレイスプロジェクトは Ruby、計測プロジェクト (ZOZOMAT や ZOZOGLASS の環境）は Scala を使っており、プロダクト単位での独立性も持っています。
また、全く新しい技術や言語に挑戦できないというわけではなく、新しい技術への挑戦も行います。ただし新しい技術への挑戦は将来的な撤退も視野に入れる必要もあるため、技術戦略部で都度判断するものとしました。
Java、Golang トレーニングの開催
前述の全社技術スタックを策定したことにより、会社として支援すべき技術が明確になり、トレーニングの開催を企画することができるようになりました。弊社では以前から、AWSトレーニング、GCPトレーニングを開催したことがありました。今年は、加えてJavaトレーニングとGolangトレーニングの企画を進めており、Javaトレーニングは実施済みで、Golangトレーニングもすでに計画が立っています。
Java, Golangトレーニングを開催する目的としては主に２つありました。
- これからZOZOTOWNリプレイスに関わるメンバーを、事前にリプレイスもしくはリプレイス後の世界に誘う
- アプリケーション開発を経験する機会がなかったSREを、コードを読み書きできる強いSREとして育成する
ZOZOTOWNリプレイスプロジェクトを始めて数年立ちますが、まだ全てをリプレイスできたわけではありません。しかし、初期の頃はごく一部の人間だけがリプレイスプロジェクトを進めていましたが、リプレイスできたマイクロサービスの数も多くなり、リプレイス後の世界に入った人達の割合が確実に増えてきています。最終的には全員が新しい技術スタックに習熟していく必要があり、前もってトレーニングを開催することで土台づくりを始めています。
また、SREのリーダーとしてメンバーを率いていた頃から課題として捉えていたのが、強いSREになるためにはコードの読み書きができないといけないということです。私自身は、アプリケーションエンジニアからインフラエンジニアに転向したキャリアであるため、コードの読み書きができるのですが、新卒で配属された時からインフラエンジニア一本でやってきたメンバーの場合は、コードの読み書きにしっかり時間をかけた期間がないため、そこの経験がどうしても弱くなってしまいます。だからといって「一度アプリケーションエンジニアをやってこい！」と送り出すのも難しく、育成上の悩みとなっていました。そこで、今回のトレーニングはSREのメンバーにも受けてもらい一歩目を踏み出してもらうことにしました。今回のトレーニングだけで足りているとまでは思いませんが、一歩目を踏み出すかどうかで全く違う結果になると信じています。
エンジニア採用基準の平準化および新卒面接官の任命基準の策定
現在、ZOZOではエンジニア採用を積極的に進めており、中途および新卒採用共に人事とエンジニアで面接を行っています。面接の数が多くなり、以前の面接官の人数では負担が大きすぎるようになったため、新たに新卒面接官の任命を行うなど、より組織的に動けるように再設計しました。
面接官の人数を増やすのは良いのですが、人数を増やすだけでは、採用基準にブレがでてしまうため、採用基準の平準化も行いました。以前から、チェック項目はあったのですが、✕なのに合格になっている項目があったりと、形骸化していることがデータから見れたので、改めて文言を変えるなどの調整を行いました。
採用と育成は陸続きだと思っており、どういうエンジニア組織を作っていくか考える上で、両方に力を入れておくことが重要です。
テックリードの任命・除名フローの策定
ZOZOには正式にテックリードという肩書きがありまして、現在9名がその役割を担っています。
エンジニア採用が進んで今や350名ほどいる組織になったにも関わらず、あまりテックリードが増加しておらず健全ではないと考えており、そこで改めて、テックリードの役割の定義と、任命・除名フローの策定を行いました。
弊社におけるテックリードの役割は現在、以下のようになっています。
- チームの技術的な方向性、設計や開発手法、実装や品質などプロダクトの技術面での定義に対して責任を持つ
- 全社横断で、技術施策の策定と普及、スキルアップ支援、採用活動への協力など技術面での貢献を行う
フローは整ったので、次は次代のテックリードを担えるメンバーをピックアップし、育成を行い、テックリードの人数を増やしていくフェーズに入っていこうと思っています。
ZOZOTOWNリプレイスプロジェクト
2021年4月にZOZOTOWNリプレイスプロジェクトの責任者を継いで、個人的に一番変わったのはZOZO経営陣への進捗報告を私が行うようになったことと、現場から離れたことで俯瞰してものごとを見るようになったことだと思います。一方でリプレイス戦略については、元から前CTOと二人三脚で練ってきていたというのもあり、大きな方針変更の必要はありませんでした。ここはリプレイスのリプレイスを行わずに済んで良かったことなのではないかと思います。
今年度新たに実施した施策から一部抜粋して取りあげると以下のようになると思います。
- 2023年に向けたZOZOTOWNリプレイス計画の策定
- ZOZOTOWN SLO策定および可視化
- オンプレサーバ(IIS 及び SQL Server)のAWSへのリフト
- ログ収集基盤の構築
- カート・決済機能のリプレイス
- フロントエンドリプレイス
ZOZOTOWNリプレイス計画の策定
リプレイスプロジェクト責任者を引き継いだタイミングで、改めてZOZOTOWNリプレイスプロジェクトの計画について2023年までの大きな線を引き、ZOZO経営陣にプレゼンを行いました。ZOZOTOWNのEC機能(一般ユーザに見える所)については、リプレイスプロジェクト完遂までの道のりが見えてきており、見通しは明るいと我々は感じています。
また、ZOZOTOWN SLOを策定し、毎月サービスの状態を可視化して共有することも始めました。
オンプレサーバ(IIS 及び SQL Server)のAWSへのリフト
ZOZOTOWNリプレイスプロジェクトの大方針として、マイクロサービス化しながらリプレイスを進めているところですが、それはそれとして時間がかかるので、セール時の柔軟な台数増強などができるように、オンプレで動いているサーバをそのままAWSにリフトして、スケーラビリティを手に入れるということも平行して行っています。
ログ収集基盤の構築
ZOZOでは BigQuery を中心に据えたデータ基盤の構築を数年前から行っており、DBデータの取り込みについては、バッチ取り込みはもちろんのこと、リアルタイムで差分データを取り込む仕組みもできており、すでに十分な仕組みができあがっていると思っています。
一方で、ユーザの行動ログの取得については Google Analytics (GA) を全面的に頼っており、我々がデータを取得したいタイミングで取得できず柔軟性に欠ける点、データ構造が複雑でありGAのプロしか解析できない点、フロントエンドのログしか取得できない点、リアルタイムにログを取得できない点、などいくつかの課題がありました。その課題を解決するためにログ収集基盤を内製し稼働を始めており、すでにいくつかのログを取り込み始めている状況です。
カート・決済機能のリプレイス
カート・決済機能のリプレイスについては、Phase1 として、カート投入機能のキャパシティコントロールが可能なアーキテクチャに刷新するリリースを行いました。これにより、以前は福袋や人気商品の販売時に都度都度行っていた特別対応を行う必要がなくなり、運用が楽になりました。個人的にも入社前に「ZOZOTOWNで最大級のトラフィックを記録する福袋発売イベントで実施した負荷対策 - ZOZO TECH BLOG」の記事にはてなブックマークで
とコメントをしており、それを入社してから自分も関わって達成することになったということに感慨深いものを感じていました。この頃はまだ外部の人間で、内部事情も知らずに、無責任に思ったことを書いただけでした。実に3年越し(しみじみ…
フロントエンドリプレイス
まだカート・決済リプレイス Phase2 やその他のプロジェクトも進めていますが、あわせてフロントエンド技術のリプレイスプロジェクトも並行して進めています。こちらの成果については、時期をみてZOZO TECH BLOG や ZOZO Tech Talkで改めて詳細が話されると思いますので、ぜひご期待ください。
会社の統合、そして BizDevOps へ
2021年10月にZOZOとZOZOテクノロジーズの組織が再編され、開発部門がZOZOに吸収合併され１つの組織となりました。
かつてZOZO（旧称スタートトゥデイ）は、エンジニア・デザイナーを集めて子会社に分社化するということを行いました。その理由の１つは、エンジニア採用を強化するためで、数年かけてエンジニアにとって嬉しい福利厚生制度や給与制度、そして文化を築き上げてきたことで、一定の成果をすでに達成してきたと思います。しかし、一方でビジネス部門と開発部門が分かれたことによって、距離が遠くなってきたという声があがり始めていました。
私自身、2021年4月に前CTOの役割を引き継いだ際は、何かドラスティックな変更をする必要性は感じず、継続して追加の施策を行えば良い程度に考えていました。しかし、ビジネス部門と開発部門あわせての開発プロセスや、組織面での課題を徐々に感じ始め、数ヶ月後にはその課題解決を行うためにはドラスティックな変更も必要なのではないかと感じ始めていました。その状況下においての会社統合であり、確実に組織は良い方向に向かっていると信じています。
2021年10月の全社集会では「BizDevOps」をキーワードに会社統合について、全社に向けて話をさせていただきました。
BizDevOpsとは？
- Biz: ビジネス
- Dev: デベロップ(開発)
- Ops: オペレーション(運用)
3つのセクションが密に連携しあい、1つのゴールに向かっていく組織のことです。
まだ会社を統合したばかりで、福利厚生や制度、社内ITツールの統一を目指している最中で、ドラスティックな変化は起こせていませんが、まずはコミュニケーション促進、情報のオープン化から始めて、BizDevOpsをキーワードにビジネス部門と開発部門の融合を目指していきたいと思っています。