ZOZOのテックカンパニーへの変遷、CTOとしての取り組みを振り返る
こんにちは、ZOZOテクノロジーズで執行役員CTOをしている @kyunsです。
本記事はCTOA Advent Calendar2020の 16日目の記事となります。
この記事ではZOZOでの2年半を振り返り、テックカンパニーを目指す中でCTOとしてどのようなことに取組み、結果としてどういう変化が起きたかについて紹介したいと思います。
同じような立場のCTOやこれからエンジニアリング組織を強化していきたい方々の参考に少しでもなればと思います。
自己紹介と背景
私はヤフーに2006年に新卒で入社し、3年働いた後に当時一緒に働いていた金山と一緒にVASILYというスタートアップを創業し、受託アプリ開発や「IQON」というサービスを開発していました。
何度かの資金調達などを経て、最終的に2017年にZOZOへ売却し、ZOZOの完全子会社となりました。その後、2018年の4月には当時のスタートトゥデイ工務店とVASILYが吸収合併する形で、スタートトゥデイテクノロジーズ（現ZOZOテクノロジーズ）が発足しました。
私はそのタイミングで本格的にZOZOへと合流する形となり、PMIおよびZOZOのエンジニアリング組織をみるようになりました。
このときに思い描いていた私のミッションはただひとつ
ZOZOをテックカンパニーへと生まれ変わらせること
エンジニアリング組織を強化し、技術を用いて中長期的に事業を伸ばすことのできる仕組みを作ること
です。
そもそもVASILYのM&Aが成立したのも、VASILYに対してファッションテックカンパニーとしての期待値があったからであり、その期待を裏切るわけにはいきませんでした。
ZOZOは当時ZOZOSUITを開発し始めたばかりで、これからは技術で事業をドライブさせていきたいという強い思いがありました。
また、当時界隈ではM&Aされた会社の人達はすぐに辞めていくのが日常茶飯事だったので、M＆Aされたからには日本一のM＆A成功事例にしたいという思いもありました。
■当時の課題は何か？
吸収合併が完了した2018年4月、当時ZOZOのエンジニアリング組織には非常に多くの課題がありました。
・プロダクトが抱える課題（技術スタック、開発フロー）
ZOZOTOWNの主要アーキテクチャは16年前から現在まで一度も変わることなく運営されてきました。
それらを構成する技術スタックはVBScript / IIS / SQLServer / オンプレミスとなっており、SQLServer上のストアドプロシージャに全てのロジックが記述されている状態でテストもなく、品質管理チームによる手動テストで品質を担保している状態でした。
・エンジニア組織の課題（採用、教育、評価）
基本的にそれまでのZOZOTOWNは限られた人数で最大の成果をだすという観点から、あまり外部のエンジニアを積極的に採用するという方針ではありませんでした。事業自体がZOZOTOWNだけであれば、その方針自体は問題なかったのですが、ZOZOSUITなどの新しい事業を立ち上げていくには、やはり積極的にエンジニアを採用していく必要があります。
しかしながら、情報の外部発信などもあまり行われておらず、優秀なエンジニアを集めていく土台はほぼありませんでした。
しかもプロダクトはVBScriptがベースであり、オフィスも海浜幕張がメインだったので、エンジニア採用も非常に難しい状態でした。
また評価制度なども存在せず、なかなかエンジニア達の成長支援がしづらい環境でした。
・社員の働き方の課題
Office365は導入されていましたが、そもそも家でメールを見るような文化はなく、オフィスに出社して業務を行うというのが当たり前の文化であったため、あらゆる業務はオフィスに出社しないと行えない状態でした。
またセキュリティルールの問題などもあり、リモートワークだったり、クラウドベースのツールを効率的に用いて業務を行うという働き方をすることが非常に難しい状態でした。
・セキュリティに関する課題
セキュリティ専門のチームがいるわけでもなく、なんとなくルールを守れているチームもあるという感じでレベル感はバラバラの状態でした。
脆弱性診断を行っていたため、最低限の対策は取られていましたがチームによって実装のばらつきがあったり、非常にリスクが高い状態でした。
ここにあげたのはほんの一例ですが、広範囲に渡ってこのような課題が散財している状態でした。
この状態を目の当たりにした時は一体この会社はどれほどポテンシャルがあるんだろうと興奮したことを覚えています。
これらを良くすれば確実にプロダクトの改善速度も上がり、しっかりと事業貢献できる体制をつくることができる、という思いでした。
どのように変えていったか
どこから手をつけていくのが最も効率的かを考えましたが、全て同時にはできないので、優先順位をつけてやっていくことにしました。
1人でできることにはもちろん限界があります。限られた時間の中で、最大速度で変えていくために以下のようなところからはじめました。
組織づくりを優先し、プロダクトはできるところから変えていく
まずは組織を整える方を優先し、会社を変えていくために必要な仕組みを構成する部分を一旦全て集約しました。
プロダクトの改善を行うにも規模が大きすぎるため、そもそも強いエンジニアをもっと集める必要があったという背景もあります。
元々VASILYにいたエンジニアのテックリード達を分散配置して、現状を把握していくのと並行して、まずは組織を整えていくことにしました。
何が起きているかを全て把握できる状態に、組織を変更する
まずはエンジニア達や開発の現状を把握しなければはじまりません。
そこで各部に散っていたエンジニアを開発部という一つの組織にまとめました。これによって、既存のエンジニア達が何をしているのかを把握できるようになりました。
次に、改革を進めていく上で重要になるのが情報システムでした。当時は、経営管理側にあった情報システム部門でしたが、開発部直下に異動させました。
また、全社横断での技術的な意思決定はCTOとして一括で取りまとめ
会社で何が起きているのかを全て把握できるようにしました。
そして、最後はセキュリティです。
セキュリティ相談やインシデントハンドリングなどを積極的に集約するようにしてどのようなセキュリティ課題があるかを把握するようにしました。
これにより、CTO、CIO、CISOとしてあらゆる状態を把握できる土台をつくりました。
もちろんこれは過渡期であるがゆえの一時的なものだという認識はしています。
ただし、改革を全速力で進めていくのに最も大事なのを攻め続けながら守りも固めることだと思います。攻めていくうちに守らなければならないところも把握できるようになります。
このように、改善できる体制のベースを作って、改革を進めていきました。
課題のカテゴリわけをして対応していく
様々な課題がありましたが、大きく分けて、以下の4つのカテゴリに分類されました。
・エンジニアリング組織マネジメント（CTO/VPoE）
・情報システムの整備（CIO）
・情報セキュリティ体制の構築（CISO)
・ZOZOTOWNリプレイス推進
ここからはそれぞれのカテゴリにおいて行った取り組みを紹介していきたいと思います。
エンジニアリング組織マネジメント
まずはエンジニアリング組織マネジメントです。
取り組みとしては以下に分類されます。
・技術戦略
・技術広報
・人事戦略
・成長支援制度
■技術戦略
まずは全社横断で、技術的な戦略の策定を行うことにしました。
内製化推進やクラウド化推進など、会社全体の開発ポリシーに影響するような意思決定は全てCTOに集約させました。
・ ベンダー窓口の集約
当時ZOZOには数十の開発ベンダーが関与しており、莫大な金額をそれぞれのベンダーに払っている状態でした。エンジニア組織を強化し内製化を進めていく上で、このような委託先を全て洗い出し、現状を整理する必要がありました。また、投資をしている金額も非常に大きく、これらの適正化を行う必要がありました。
AzureやAWSのようなクラウドベンダーに関しても、社内のいろいろなプロダクトで利用されていたものの、統合管理されておらずディスカウントやサポートを受け辛い状態でした。
そこでベンダーとのやりとりの窓口を一箇所にして、どういう業務内容でベンダーや業務委託先にいくら支払っているのかを把握し適切な金額に落とし込んでいく作業を行いました。
ブラックボックスになっていたような部分に関しても、極力内製化できるように推進し、システムのリプレースも進めていきました。
また、50以上あったAWSアカウントの全ての棚卸しや集約を行うことによって、大幅にクラウド費用を削減することもできるようになりました。
このベンダー整理とアカウント統合などにより、これだけでも数億円規模の費用削減となりました。
・ データ基盤整備
当時ZOZOには膨大なファッションのデータがありましたが、それらを活用できる状態ではありませんでした。
VASILY時代の教訓もあり、今後のデータ活用をふまえるとデータ基盤の整備が急務だと思い、まずはデータ基盤を整備することにしました。
全社のDWHにはBigQueryを選択し、全てのあらゆるデータはBigQueryに集約するようにしました。
最近では限りなくリアルタイムにデータをBigQueryに連携させることができています。
このDWHをベースにして、社内のデータを必要とする部門、例えばサービスの分析を行うために、分析部がBIツール経由でアクセスしたり、ZOZO研究所などのエンジニア達が機械学習や実験に必要なデータを取り出せるように
開発をしやすい環境を作り上げていきました。
データ基盤を整備したことにより、SQLを書いて分析する人数も増え、
機械学習や深層学習を用いたアルゴリズムの開発や機能の実装などもスムーズに行うことができるようになりました。
・テックリードの設置
プロダクトや組織を技術面から改善し、良い方向に持っていくためにも
やはり技術的な面でリードができるエンジニアが必要でした。
そこで技術的な意思決定をリードできる人、というのをわかりやすくするためにテックリードというラベルを作り、
旧VASILYメンバーを中心に、各プロダクトに配置し、iOS/Android/フロントエンド/バックエンド/SRE/データなどそれぞれの領域において、少しずつ技術的負債の解消やプロダクトの改善を行っていく体制をつくりました。
・開発ガイドライン整備
エンジニアが数百人もいる環境だとプロダクトを作る際にガイドラインなどがないとそれぞれのプロダクトの品質がばらばらになります。
パフォーマンス面だけの問題ならまだしも、セキュリティ対策やXSS対策、プライバシー情報の保護など、プロダクトとして守るべきルールが守られていないという自体も容易に起こるようになります。
これらの問題に対処するために、ZOZOテクノロジーズのサービス開発における「良い実装」の明文化に取り組みました。
テックリードを中心に技術戦略委員会を組成し、iOS/Android/フロントエンド/バックエンド/インフラなどそれぞれの領域において開発時に遵守すべき項目、推奨すべき項目などを定め、開発時に参考にできるような開発ガイドラインを策定しました。
ISMSやセキュリティルールなどに遵守できるような内容も取り入れているため、このガイドラインに則って開発を行えば、安心・安全なサービスの提供を行えるようになっています。
また、社内でもOSSのコントリビューターを増やしたいという思いもあり、
OSSの公開のガイドラインの整備をそのっつさんなどOSSに明るい社内の有志の方々を中心に策定を行いました。
また、社員がOSS活動をしやすいように社内の就業規則なども合わせて変更するなどの対応を行いました。
OSSポリシー策定の話
https://techblog.zozo.com/entry/oss-policy
■技術広報
次に技術広報です。エンジニア採用を強化していくためには、技術面での広報戦略が必須になってきます。
当時は前澤さんなどの話題により、ZOZOという名前自体は知られていましたが、その中にいるエンジニアのことや、そもそもどんな事業をしているかなどはあまり知られておらず、世間に対して我々エンジニアの取り組みなどを幅広く知ってもらう必要がありました。
そこでまず我々としてはアウトプットを強化していくという戦略をとりました。
具体的には
・テックブログ
・勉強会、イベント登壇、カンファレンス発表
・Qiitaなどへの執筆
などへのアウトプットを強化していきました。
・ テックブログ
技術広報において、重要な役割を占めるのがテックブログです。
しかしながら、テックブログの運営が大変という話は我々CTO仲間からもよく聞きます。たしかに、続けるためにはうまく回る仕組みが無いと継続は不可能でしょう、有志の熱量だけではとても運営はできないと思います。
そこで、まず社内のエンジニア達など協力者に理解してもらうためにも、
なぜテックブログをやるのか？という説明とともに、
テックブログ執筆の協力体制を築いていきました。
なぜテックブログが必要なのか
もちろん最初はそもそもアウトプットできるような内容が無かったり、
そもそも記事を書いたことがない人達がほとんどでしたので、なかなか記事を集めるのには苦労しました。
そのため、まずは記事を書いてもらう敷居を下げるために執筆のフローの整備や環境作りを行いました。
テックブログ公開フロー
テーマの壁打ちから、文章校正、OGPバナー画像の作成までみんなで協力して記事をかける体制を整えていきました。最近ではかなり仕組み化されており、3ヶ月ごとに、各チーム1記事ずつのような形で事前に内容などを決めてスケジューリングしておくという方法をとっています。
当然忙しかったり書けなかったりする場合もあるので、うまく順番を変わってもらったり代打を探す工夫などをして、継続してアウトプットできる仕組みを整えています。
各マイルストーンにおいてもリマインドを行ったりチェックリスト形式で、
抜けもれなく公開までできるような仕組みにしています。
マイルストーン
これらの仕組みを整えたことにより、今年は年末までに合計約100本のテックブログ記事が公開される予定です。
・登壇管理
テックブログの発信だけではなく、登壇なども非常に重要な要素です。
こちらもテックブログ同様に、社外で登壇する際のフローを整備して、
登壇資料の共通テンプレート作成や登壇資料のレビューなどを行える仕組みを作り、登壇までのフロー整備などを行いました。
ZOZOの場合上場起業であるため、IRに影響するような情報やZOZOSUITやZOZOMATなどの新しいプロダクトの情報など取り扱いの注意が必要です。そのため、どの情報を出していいか相談できるようにしたり、CTOと広報とで確認できるフローなども入れていたりします。
また合わせて会社としては、それぞれの分野で有力なカンファレンスのスポンサーを積極的に行い登壇機会の創出なども行っていきました。
登壇ルール
・Qiita
いきなりテックブログを書くのはハードルが高いというエンジニアには
まずはQiitaなどへの投稿を推奨しました。
また、Qiita主催のAdvent Calendarなどのイベントも活用し全社での発信を積極的に促しました。結果として、
2019年にはZOZOテクノロジーズアドベントカレンダーはvol.5まで(トータル125記事)
2020年もvol.4まで(トータル100記事）も自然に集まるぐらい情報発信に積極的になりました。
またOrganizationランキングでも常にTOP10に入るぐらいになりました。
このようにアウトプットに関して、全面的にバックアップ体制を整えることによって技術ブランディングを地道に行ってきました
また調査会社を用いて、年1回一般のエンジニアの方々に向けて技術ブランディング調査を行い、ZOZOテクノロジーズに対しての印象がどう変わったかなど、アンケートなどを用いて定量的に算出したりしています。
■ 人事戦略
次に人事戦略です。
エンジニアリング組織強化のためには、エンジニアに関わる採用、教育、評価、制度のすべてを見直しました。
・ エンジニア採用
採用基準の明確化
それまでのZOZOテクノロジーズの採用基準は良い人かどうか、そしてZOZOが好きかどうかが基準でした。特に企業理念への共感という部分を非常に大事にしていました。
その反面、スキルセットに関してはほとんど見ていなかったと思います。
それもそのはずで技術スタックが一定なので特に重要視する必要がなかったということだけだと思います。
もちろん、これはそれまでの環境が続くのであればそのままでも良かったかも知れませんが新しいプロダクトや既存プロダクトの大幅改善など、未来を見据え組織を変えていくためには、その現状を変えていけるぐらいのスキルセットを持ったエンジニアを採用する必要があります。
そこで、未来の組織を作るためにどんなエンジニアを採用すべきかという観点から我々が必要とするエンジニア像を新しく定義し直しました。
しかし採用基準を一新するといってもスキルさえあればいいのか？と言われると全くもってそうではありません。やはりカルチャーフィットは重要です。特にZOZOの場合はカルチャーフィットが非常に重要だと感じていました。
新しい基準をつくるにしてもZOZOの良い部分を壊すようなことはしたくなかったので僕自身がZOZOのカルチャーを理解し、言語化できるようになるまでは代表や人事と一緒に最終面接を行うことによって、彼らが何を重要視しているのかを理解するように務めました。
面接をともにし、繰り返すことよって、ZOZOのカルチャーとは何なのかが理解でき、それを言語化することで新しい採用基準が完成しました。
また面接フローにおいても、様々な仕組み化を行いました。
応募者一人一人専用のドキュメントページを作成し、面接中の全ての発言や質疑応答を人事がメモし、ドキュメント化を行うようにし、後から振り返れるようにしました。
こうすることによって、質疑応答の内容によって面接官がどういう判断をしたのか把握できるようになり面接官同士のトレーニングにも繋がります。
また、応募者が採用基準の各項目をどれぐらい満たせていたかを面接官自らがしっかりと記入し、言語化できるようにしました。
中途採用
中途採用においては間口を広げるためにもあらゆる媒体を利用しました。
Wantedly、BINAR、転職ドラフトなどのスカウト系のものを中心に運用し、
ヘッドハンター会社まで赴き、採用したい人物像の説明などを行ったりもしました。
また、リファラル採用を強化するためにも知り合いが入社したら○○万円支給（さらに自分よりもランクが高かったら倍の金額）というようなリファラル制度も作りました。
採用キャンペーンについても、常にZOZOらしい採用キャンペーンを行ってきました。
一時期話題となった天才採用や1億円採用など、前澤さんのおかげで話題になることもしばしばありました。
前澤さんと面談したときに、「やりたいこと全部やるとしたらエンジニアどれぐらい必要？」っていう話をして「500人ぐらいほしいです」
と言った次の日ぐらいに、前澤さんがいきなりエンジニアの皆さんからの質問に答えます！というツイートして、プロダクトの歓迎会の最中にエンジニア総出でTwitterに待機することになりました。
これが #ZOZOTech質問会 です。 https://twitter.com/i/events/1054196490325831681
当時の反響はものすごくて、このキャンペーンだけで150名以上のエンジニアからの応募がありました。
このおかげで入社してくれたエンジニアもいましたし、ZOZOらしさが出た採用キャンペーンだったなと思います。
・評価制度
元々ZOZOには評価制度は存在しなかったので、早急にエンジニアの成長を促すための評価制度を準備する必要がありました。
評価とは単純に給与を決めるための仕組みではありません。
評価とは会社として求める行動指針ができるように成長を促す仕組みだと思います。
そのため、会社としてどういう人間になってほしいのか、をベースに評価制度を整えていきました。
会社の掲げる行動指針に沿った行動が、どれぐらいできたのかをベースに評価できるような制度を作りました。
もちろん、前述したような体外的な情報発信などもきちんと評価制度に取り入れました。
当初は、VASILY時代にやっていたエンジニアリングマニフェストのZOZO版も作って運用してみましたが、時期尚早すぎたのか、あまりフィットしませんでした。そのため、新しい評価制度に統合する形で1年で廃止したりしています。
評価制度の導入から2年ぐらいはエンジニアの実態を確認するために、200名との評価面談を行うなどして評価基準のすり合わせや基準作りを行いました。
キャリアパスに関しても、通常のマネジメントコースだけでなく、技術を極めていくようなエキスパートコースのようなキャリアパスも用意しました。
また元々あった給与テーブルを採用市場で戦えるように大幅に調整したりもしました。
これにより、エンジニアをより成長させやすい環境を作ることができました。
教育
教育とは気づきを与えるもの by 呪術廻戦
エンジニアの教育に関しては色々な成長支機会の創出の支援を行いました。
またあわせて、様々な福利厚生やエンジニアの成長を促す取り組みを開始しました。
・AWS/GCPトレーニング
これまでのZOZOTOWNはオンプレミスで構築されており、AWSやGCPなどのクラウドを触ったことのあるエンジニアは一握りしかいませんでした。
しかし、ZOZOTOWNのリプレイスが進んでいくと、ほとんどのエンジニアは必然的にAWSに触れる必要がでてきます。
そのために、先手を打ってトレーニングを行う必要があると思い、AWSやGCPの協力を得てトレーニングプログラムを作り、希望者全員に対してトレーニングを実施しました。合計100名以上のエンジニアがトレーニングを受講しています。
トレーニング後のアンケートでは、9割以上のエンジニアが非常に満足度の高い結果となっており、
1ヶ月のアンケートでは約60%のエンジニアが早速業務で役立ったと回答していました。
このように、実際に実務で役立つものをベースに全社で技術力の底上げなどを行っていきました。
・国内外のカンファレンス参加費補助
国内外問わず、開催される技術カンファレンスや国際学会などへの参加のチケット代や移動費、宿泊費などを全て会社が負担するようにしました。
当然結構な費用もかかるので、参加した場合は参加レポートを書いてもらうか、後日登壇イベントを開催してもらうなどのルールを制定しました。
・ 資格取得手当
AWSの認定資格など費用のかかるような資格を取得した場合も、試験費用を会社が全て負担するというような制度もつくりました。
とくにクラウドの勉強を始めたばかりのでエンジニアに対しては、AWSの資格取得を促したりしていたので目標とする支えにもなっていたかと思います。
・クラウドトレーニング費用補助
AWSやのトレーニングを受けたあとで、自分で試したいとなってもそれなりのお金がかかります。
そこで会社としては、TCP/IP ( Try Cloud Program / Infrastructure Practice )と呼ばれるAWSのインフラ演習利用補助の仕組みを作りました。
毎月100ドルまで学習用途で各個人がAWS環境を自由に使える制度となっており、月100ドルの利用枠の中でコスト管理も意識しながら、AWSを実際に触れることでスキルアップを目指すことができるような仕組みになっています。
・ 書籍購入補助
エンジニア達にはもっと気兼ねなく技術書を購入してほしいという思いで
書籍の購入に関しては全額会社が負担するという制度をつくりました。
こちらは上限もなし、唯一あるルールは感想をSlackに書くことというルールだけです。
この制度に関しては、今年の新卒達が新卒開発研修でSlack専用アプリを開発してくれており、簡単にレビューを投稿できたり、機械学習によりおすすめの本を見つけることのできる機能などがあったり、非常に役立つSlackアプリとなっています。
社内の書籍レビューの集合知をAIとエンジニアリングで活用促進！ 社内ツール「BEAR」をフルリモート新卒研修で開発しました https://technote.zozo.com/n/nd2efa82852b9
・技術共有会
エンジニアが数百名いる組織となると、同じ職種同士で情報交換をする機会がなかなか持てません。
しかしながら同じ職種同士の横の情報共有は非常に大事だと考えています。
そこでiOS/Android/フロントエンド/SREなどのカテゴリにおいて技術共有会というものを月1で開催してそれぞれのチームの取り組みの紹介やLT大会、新しいOSの情報交換等を行うようにしました。
例えばZOZOTOWNやWEARなど違うプロダクトだったとしても、お互いにiOSの情報交換をしたりするきっかけとなっています。
・技術顧問制度
内製化を進めていく上で、各ジャンルのプロフェッショナルの方の意見をききたいと思うことがでてきます。
会社としてはそのようなケースに対応するために、技術顧問という制度を作りました。
元々VASILY時代からRubyの技術顧問であったMatzさんに加えて、iOSの岸川さん、マイクロサービスのdeeetさん、検索の大谷さん、DDDのかとじゅんさんなどあらゆるジャンルの一線で活躍する方々に技術顧問として手伝ってもらったりしています。
実際にプロダクトのコードレビューや一緒に設計や課題解決を行ってもらったり、勉強会などを開催してもらったりすることによって、エンジニア達の成長につながる貴重な機会となっています。
また技術顧問になってほしい人がいたら推薦してもらえればこちらで検討して、実際に顧問をオファーするという流れもできています。
エンジニアリング組織マネジメントとしては上記のようなことに取り組んできました。
2019年にはこれらの施策の推進をチームとして実行できるようにするためにCTO室を設置し、スケールできる体制を整えました。
CTO室はじめました 〜新設CTO室が1年目にやったことと課題
https://qiita.com/ikenyal/items/12a8939c4b79b48f044b
これらの多くの取り組みを社内のエンジニア達にも周知するためにも
CTO室通信を月1回発行し、エンジニアへの周知事項などをまとめて共有する社内レポートなども発行したりしています。
■ 情報システムの整備
次に情報システムの観点からどのような取り組みを行ってきたかを紹介します。
ちなみに情報システム部門も
「スタッフや組織の課題をテクノロジーの力で解決し、社員の生産性を支える」
というのをミッションにしました。
そして名前をコーポレートエンジニアリングという部署名に変更しました。
・ 働き方改革の推進
先述した課題にもあったように、ZOZOではリモートワークを行うことが難しい状態でした。
難しい原因は以下の2つです
・オフィスへの出社を前提とした業務プロセスになっている
・端末を外に持ち出すにはセキュリティを強化する必要がある
これら2つの原因に対して1つずつ施策を行っていきました。
また、当時は東京オリンピックの開催が予定されていたので交通網が麻痺し、出社できなくなる可能性もあるだろうという考えもあったので早急に整備をする必要がありました。
・クラウドベースの仕事環境構築
リモートワークを実現するためには、まず手元の作業を全てクラウド上に持っていく必要がありました。
そして情報共有を確実にしていくためにも、正式に社内ドキュメント共有ツールをConfluenceとし、誰もがドキュメントを書ける状態にしました。
次にG Suiteを導入し、ExcelやパワーポイントのファイルからSpreadSheetやGoogle Slideなどオンラインサービスへの移行を促しました。
オンプレミスにあったファイルサーバー達もGoogle Driveへと移しました。
当然日頃業務で利用していたものがクラウドに置き換わると、ツールに慣れておらず業務にこまる人たちも出てきます。
そこでG Suiteの導入時にはG Suite専属のトレーニング会社と協力して、利用マニュアルの準備や勉強会を複数回開催し、スムーズに使ってもらえるような工夫を行いました。
・リモート接続環境の整備、ゼロトラスト環境
認証基盤
まず社内の認証基盤をAzure ADをベースとして、多要素認証やSSOを取り入れることのできる認証基盤に整えました。
これをベースに社内の様々なツールをSAML/SSO連携していくことにより他のSaaS系アプリケーションのアカウント連携などの運用コストを下げることができました。
VPNとゼロトラスト
当時緊急用にVPNが存在していましたが、動作も非常に重くエンジニアからの評判も非常に悪い状態でした。
そこで、データセンターやオフィスのVPN機器を入れ替えAzure ADをベースとして、SSOできるように変更しました。
この連携により、例えばZOZOTOWNプロダクト所属の人はZOZOTOWNの開発環境のみに接続することができる、みたいな制御を実現しています。
さらにVPNの整備だけでなく、Azure Application Proxyを利用することによって、VPN接続なしに社内の業務アプリケーションへのアクセスを制御するような仕組みも整えました。
・端末セキュリティ強化
端末セキュリティ系に関するソリューションは多くありますが、そんなに人を割ける会社もそう多くないと思います。
当時色々と試していた中で、運用コストの観点などから全てMicrosoftに統一したほうが良いという判断をしました。
よってセキュリティソリューションに関してはMicrosoft製品で全て統一しています。
MDMにはIntuneを用い、EDRにはMicrosoft Denfender for Endpointを利用しています。
どちらもWindows/Mac/iOS/Android対応になったので非常に助かっています。
またゼロタッチキッティングという手法を用いて、完全リモートでの端末セットアップも実現しています。
ゼロタッチキッティングによるテレワーク環境下のWindows 10デバイス展開の自動化と運用効率化
https://techblog.zozo.com/entry/windows-zero-touch
端末管理にはSKY SEA Client Viewを利用、端末ログはSentinelへと連携し、SIEMとしても利用できるようにする予定です。（現在はBigQueryに連携して、働きすぎていないかどうかなどの調査を行っていたりします）
CASBにはMicrosoft Cloud App Securityを用いて、様々なクラウドアプリケーションの脅威スコアの確認やアラート対応などを行っています。
これらを別の製品で補うことも検討しましたが、やはり管理コストの観点からここは統一しておいてよかったと思います。
これらのセキュリティ面での強化により、端末を外に持ち出すことが可能になりました。
・ 個人情報へのアクセス
エンジニアがリモートで作業する上で、個人情報の取り扱いには非常に注意しなければなりません。
本番DBへのアクセスルールをより厳密にするために、個人情報の対象となるデータをすべて洗い出し、ラベル付けを行い個人情報に該当するデータにアクセスできないようにマスク化を行いました。
結果としてほとんどのエンジニアからは本番DBへの個人情報へのアクセス権限を削除しました。
その代わり障害などの緊急時の対応の際に、一時的に特権アカウントが発行されるようなワークフローと連携した仕組みを整えたりして万が一のときでも円滑に業務を行えるような仕組みを整えました。
またカスタマーサポートなどについては、VDI経由での業務が行えるような検証も同時に進めています。
・リモートワークルールの制定
端末やセキュリティなどの環境の整備を進めると同時にリモートワークに関するルールについても制定しました。
労務と連携して、リモートワーク勤務規定を制定したり、セキュリティ規定を新しくしたりしました。
また、パスワードの管理などに関しても、1passwordを全社導入したりしました。
備品の持ち出しルールなども改定することによって、モニターの持ち帰りを許可したりしました。
リモートワークのルールづくりにおいて非常に良かったことは
リモートワークの細かいルールはチームリーダーに委ねる
ということです。
メンバーが自由にリモートワークをすることによって一番困る人は誰か、を考えたときにリーダーが一番困るという結論になりました。
よって、リーダーに裁量をもたせ、それぞれのチームごとにローカルルールを作っても良いとすることでリーダーがパフォーマンスを発揮しやすいチーム状態を作れるようになりました。
もちろん、リーダーはメンバーの色々な事情を鑑みて、定例や出社したい日などを決めているので、結果として全社共通で決めるよりも、スムーズに運用することができていると感じます。
・リモートワークならではのコミュニケーション
リモートワークが中心になると、当然メンバー間のコミュニケーション量も低下します。
そこでDiscordを用いて、気軽に話しかけれるような環境をつくったりして
コミュニケーションを促すような仕組みを用意していたりします。
Slack通話じゃだめなのかとか、ZOOM繋ぎっぱなしじゃだめなのかとか色々あると思いますが、Discordは非常に気軽に利用できるので、心理的なハードルも他のアプリに比べて低い気がしています。
障害が起きたときなどは、自然とDiscordに集まってくるような文化も生まれています。
このように情報システムにおいても、色々と改革を進めていったことで、無事に全社でリモートワークを行うことが可能になりました。
■ 情報セキュリティ体制の構築
次はセキュリティ体制の構築です。
当時脆弱性診断を受ける中で、セキュリティに関する事案なども増えている状況でした。これらの問題をどのように対処していったかについて紹介したいと思います。
・ZOZO CSIRT立ち上げ
これらに関する問題をどのように対処しようか考えていたときに、丁度弊社メンバーの中に前職でCSIRTの立ち上げに関わっていた人がいたということもあり、CSIRTへの加盟のアドバイスをもらいました。
丁度よいタイミングだったので、これを期に個人情報や、ISMS，脆弱性、インシデント対応など幅広い問題を扱う窓口としてグループ全体のセキュリティに対する情報交換・方針決めを進めていく組織、ZOZO CSIRTを立ち上げました。
メンバーには各クラウドの管理者などをあつめ、隔週で定例を行い、それまでに起きたインシデントの共有やセキュリティ情報の共有、早期警戒情報などの共有などを行っています。
また、日本シーサート協議会に加入することで、他社のインシデントハンドリング例や早期警戒情報などを入手しやすくなりますし、ワークショップなども頻繁に開催されているので、加入して良かったなと感じています。
・ZOZOグループリスクマネジメント委員会の発足
ZOZOは2019年11月にZHDの子会社になりました。
ZHDの一員としてZOZOもERMの観点からあらゆるリスクマネジメントを強化する必要性がでてきました。
CSIRTでは今まで情報セキュリティをメインに扱ってきていたのですが、そのようなリスク以外の様々なリスクに対してもZOZOグループ一丸となって対応していく必要があります。
そこで、全社的なリスクマネジメントを行う体制として、ZOZOグループリスクマネジメント委員会を発足し、グループ横断的にあらゆるリスクマネジメントを行う体制を整えました。
今後はZHDとしてもNIST基準でのセキュリティ基準が求められる様になっていくと思いますし、さらなる体制の強化をしていく必要があると考えています。
■ ZOZOTOWNリプレイス推進
4つ目はZOZOTOWNのリプレイス推進です。
ZOZOTOWNのアーキテクチャリプレイスは2017年頃から計画されており
過去にはベンダーに頼んでいた背景などもあり、うまくいかずあまり進捗はしていませんでした。参照系の一部のみをクラウドに載せたりというところまでは進んでいましたが、思うようにスピードがでないということで2019年末のある程度エンジニアリング組織が固まってきたタイミングでZOZOTOWNのリプレイス責任者としてを改めて、リプレイスを主導するようになりました。
そこから改めてZOZOTOWNの未来のアーキテクチャ図を描き、メンバー達とのディスカッションを重ねてリプレイスのロードマップを引きました。
モノリシックなアーキテクチャをマイクロサービスへと移していくというロードマップを当然円滑に進めるためには逆コンウェイの法則に則り、組織もアーキテクチャにあわせて変更したりしました。
今年に入って本格的に再始動した結果、2020年上期はロードマップ通りの進捗をすることができており、また同時に非常に多くの成果が出ています。
・VMware Cloud on AWSによるスケーラブルなインフラの実現
・検索エンジンのSQL Server脱却、全面ElasticSearch化による検索速度劇的改善
・マルチクラウド廃止によるコスト削減
・ID認証基盤リプレイスによる安定稼働
・API Gateway化
・APIガイドライン策定
・Infrastructure as Code, CI/CD環境整備
まだまだリプレイスの道半ばですが、引き続きリプレイスを推進していければと思います。
ZOZOTOWNのリプレイスに関してはこちらのスライドにまとまっています。
ZOZOTOWNリプレイス2020 by @sonots
https://speakerdeck.com/sonots/zozotownripureisu2020
CTOとして
もちろんここまで紹介してきた以外にもCTOとして様々な業務を行っていますが、記憶に残っているのを1つだけ紹介します。
技術DD（デューデリジェンス）
これまでもZOZOにおける海外の子会社買収時の技術DDを行ったりしていましたが、皆さんも御存知の通り、ヤフー親会社ZHDによるZOZOのM&Aが行われました。
ZOZO側の技術DD担当をすることになったので、今回の話は早いタイミングで聞いたのですが、初めて話を聞いた時は流石に変な声をだして驚いたことを覚えています。
まさか古巣の会社に買収されると思ってもいなかったですし、それを自分が逆側から担当することになるなんて、、、人生は本当に不思議としかいいようがありません。
ヤフーさんとは現在様々な取り組みを一緒にさせてもらっているのですが、
知っている人達がいるおかげで、非常にやりやすくて助かっているので、結果オーライだったかなと思っています。
色々推進してきた結果、どう変わったか？
冒頭に掲げた、ミッション
「ZOZOをテックカンパニーへと変遷させること」
これの実現までまだまだ道のりは長いですが、少なくともこの2年で別の会社と思えるぐらいには劇的に変化したと思います。
本当に多くのメンバーに協力してもらいながら、幾多の困難や衝突を乗り越えて、ようやくここまで来れたと思っています。メンバーのみんなには本当に感謝しかありません。
抱えていたそれぞれの課題に対しても
・ZOZOTOWNのリプレイスがロードマップ通りに進捗、プロダクトの速度改善や開発環境整備が進んだ
・毎年新卒が20名程度採用できるように、さらに強いエンジニアも採用できるようになった。結果エンジニアが350名になった
・エンジニア達が自発的に情報発信できるようになってきた（登壇年間100回、テックブログ100本、アドベントカレンダー100記事）
・クラウドベースの働き方が当たり前になり、リモートワークにも慣れ、以前よりも効率的に業務を行うことができるようになった
・リプレイスを進めていく中で、エンジニアの生産性も約1.3倍(Githubデータ参考）になった
と様々な成果がでるようになりました。
特にZOZOとしては「MORE FASHION x FASHION TECH」という経営戦略を堂々と掲げれるぐらいまでにはなりました。
企業理念、経営戦略
https://corp.zozo.com/about/philosophy/
70億人のファッションを技術の力で変えていく、そんな世界を一歩ずつ着実に歩み始めていると思います。
また変遷の途中でCTO協会によるDX Criteriaも登場し、改めて項目を見てみると自分たちが掲げて改善してきたことがある程度正しかったんだなというのがわかり安心しました。
CTOの仕事とは何か？
このZOZOでの2年半を通して常に感じでいた事、
それはCTOが最もやらなければいけない仕事とは何か？ということです。
組織のフェーズによってCTOの仕事は変化します。事実この2年半でも役割は変化してきました。
ただ、今回のコロナ禍を経験したことにより私の中で、1つ答えが出ました。それは
起こりうるべき未来から逆算して、プロダクトやエンジニアリング組織をマネジメントしながら技術的な側面から中長期ビジョンの策定と実行、事業を成長させていく こと
です。
今回コロナの影響により、緊急事態宣言などもあって、強制的にリモートワークを行うことになりました。
2年前からオリンピックを見据えて準備をしていたおかげで、ZOZOは全員リモートワークを行うことができましたし、結果として売上を伸ばすことができました。2年前から取り組んでいなかったら今頃大変なことになっていたと思います。大事なのは未来からの逆算です。
目の前の短期的な課題は優秀なエンジニア達によってどんどん解決されていきます。
しかし、1年後2年後3年後、どういう世界がやってきて、そこに対してどういうスタンスで自分たちは戦うのか、その時の自分たちの武器、技術は何なのか、ということを全力で考えなければなりません。
そして、その未来に対して時間を使うことがCTOの最も重要な仕事なのではないかと思います。
当たり前を疑い、
あるべき未来の姿を想像し、
そこに到達するために足りないものを考え抜いて
準備をしておくこと
その中心にあるのが技術でありイノベーションなんだと思います。
まとめ
長々と書いてしまいましたが、ZOZOにおけるテックカンパニーへの変遷について、CTOとして取り組んだことを紹介させていただきました。
スタートアップと大企業両方ともCTOを経験した身としてはどちらも楽しいですし、出てくる課題は似たような物が多いです。
だからこそ、自分が経験した学びをなんらかの形で次世代のCTO達に紡いでいきたいと思いますし、世の中のエンジニアがもっとCTOに興味をもってくれるためにも、今後はCTOとしての面白さも、もっと発信していこうと思います。
記事が役立ったなと思ったらサポートお願いします、色々と情報発信をしていく励みになります。