株式会社ZOZO 技術本部 本部長 兼 VPoEの @sonots です。この記事は「ZOZO Advent Calendar 2022」のカレンダー1の最終回（25日目）です。
振り返ると2022年は、昨年度の記事でも最後に「会社の統合、そして BizDevOps へ」と掲げているようにビジネス部門と開発部門が融合しやすい下地となる組織を作るべく邁進した1年だったように感じます。私個人としても、2022年3月に執行役員(前ZOZOテクノロジーズ社長)の久保田が退任し、VPoEとしてエンジニア部門統括の役割を引き継いだ大きな変化のあった1年でした。
この記事では、ZOZOで私と組織がこの一年、組織面で取り組んできたものをいくつか取り上げたいと思います。プロダクト面の進歩については「ZOZO ファッションテックハイライト 2022」の記事にまとまっていますので、そちらも合わせてご覧ください。
開発戦略策定プロジェクト
ZOZOグループ再編のプロセスとして、開発戦略策定プロジェクトと称して、以下のような経営からの開発部門に対する疑問に対して回答する施策をZOZOTOWN開発本部長橋本と共にやってきました。
| テーマ | 問い |
|---|---|
| ①技術戦略・方針 | ファッションテックカンパニーであり続けるため、事業戦略をより前進させるには、どのような技術を、どう使っていくべきか？（注力ポイントや妥協ポイントの明確化） |
| ②業務プロセス | どのような業務プロセス（開発手順、ルール、ノウハウ共有、外部企業の利用など）が適切か |
| ③組織 | ①②を受けた上で、どのようなHRM方針（組織構造・採用・評価報酬・配属異動・育成）が適切か？ |
| ④コスト | 今後の適切なシステムコスト、人的コストとは？ |
まずは、ZOZOテクノロジーズ時代に行われてきた施策や策定してきた開発部門の方針・ルールなどをひたすらZOZO取締役陣にインプットさせていただき、次に、それを元に今後の開発部門の戦略を練り、以下のようなアウトプットを作成してきました。この活動により、ZOZO経営陣とのシンクと新たな戦略策定が進み、BizDevOps を加速するための下地が整ってきたように思います。
| テーマ | アウトプット（既存） | アウトプット (新規) |
|---|---|---|
| ①技術戦略・方針 | ZOZOの持つ技術資産の技術スタックと技術選定の方針 | ZOZOTOWN(EC、BASE、BO)リプレイスロードマップの策定 |
| ②業務プロセス | 開発ルール(ガイドライン、リリースフロー) | ZOZOTOWN案件管理プロセスの標準化 |
| ③組織 | エンジニアの採用・育成・評価制度・配属異動 | 事業戦略をより加速させるためのZOZOTOWN開発体制の計画 |
| ④コスト | ITコスト（ヒト・モノ）の構造化と詳細可視化、適正判断 |
人事制度の見直し
ZOZOグループ再編のプロセスとして、ZOZOと旧ZOZOテクノロジーズである開発部門の人事制度を見直す動きがありました。人事制度が異なることが、ビジネス部門と開発部門の距離を近づける BizDevOps な施策をする上でもハードルとなっており、非常に重要なプロセスであったと感じます。
ZOZOテクノロジーズ時代に人事制度設計や組織開発を行っていた組織開発チームが、グループ再編のタイミングで私の管轄する組織となり、私はエンジニア部門代表として制度設計に関わりました。
2022年10月、今まではZOZOと旧ZOZOテクノロジーズである開発部門で掲げている行動指針・バリューが異なっていたのですが、現在は「ソウゾウのナナメウエ」「日々進歩」「愛」という共通の内容が「ZOZOらしさ」として掲げられています。
新たな人事制度は
- 「ZOZOらしさ」を中心に据えること
- BizDevOpsの協創を促進すること
- 成長と安心を両立させること
を重視して検討しています。柔軟な組織変更に対応しやすく、「ZOZOらしさ」を中心とした挑戦を促す制度策定に向けて、現在社内にて準備中です。
職種によって等級制度を変える会社もありますが、その場合、エンジニアが企画職や人事にジョブチェンジしたら、給与が変わるのか？挑戦がしづらくなるのでは？などの議論もあり、BizDevOps促進のためにも等級制度は共通のものとし、ビジネス部門と開発部門の異動もしやすいような制度に4月からなる見込みです。(この辺りは中々難しいですね、、、正解はない気がします
ZOZOTOWN案件管理プロセス
今まではビジネス部門から開発部門へ現場レベルで、直接Slackで開発や作業依頼がされることも多くありました。人数が少ない場合は、それでも良かったのですが、ここ3,4年で一気に人も増え、水面下で何が行われているのかも分からないような状況も発生するようになったこともあり、ZOZOTOWN開発本部長橋本を中心にZOZOTOWN案件管理プロセスの標準化が行われました。
また以前は、ZOZOとZOZOテクノロジーズという別会社の関係にあったため、ZOZOテクノロジーズ側の会議体で開発効率を考えて優先順位を仮決めしたものを、親会社であるZOZOに提出し、質問やフィードバックを受けて見直しするというプロセスになっていました。それによりスピード感が失われたり、お互いに大事にしているものの齟齬も起き始めていたように思います。今はその「優先順位を決める」会議体に、ビジネス部門の執行役員にも加わって頂いており、その場での認識すり合わせと意思決定をスピーディにできるようになりました。
まとめると、以下のような施策が行われました。
- ビジネス部門執行役員を巻き込んだ開発案件意思決定プロセス（全社戦略が開発案件に反映）
- Bizの開発フローへの巻き込み（企画者・PMのアサイン、BizDevOps）
- 企画書フォーマットの整理（要求定義の事前整理、効果試算、懸念等の明確化による開発着手までのLT効率化）
- 暗黙的に点在していたBiz-Dev現場間での案件内容のすり合わせ会議体の明確化（コミュニケーションの効率化）
ビジネス部門に負担を強いる施策となってしまっていますが、これらは全て企画から開発までをスピーディに進め、ユーザへ素早く価値を届けるために必要であるとご理解いただき、ご協力を頂いています。
ZOZOTOWNリプレイス(EC、物流、基幹)ロードマップの策定
私は2021年4月にZOZOTOWNリプレイスプロジェクトの責任者を引き継ぎましたが、昨年度は私自身のZOZOTOWN全体理解がまだ弱く、向こう1年ないし2年の計画までしか引けていなかったというのが実情でした。
責任者を引き継いで1年経った2022年4月のタイミングで、「いつリプレイスが終わるのか」見込みを立てるべく、技術本部ECプラットフォーム部ディレクター高橋と共に、完了までのリプレイスロードマップの策定を始め、人員増強計画も含め、取締役陣からの承認を得ました。
2024年までの後2年ほどで、ZOZOTOWNのECサイト・アプリについては完了させる計画となっています。現場とも認識をあわせた現実的な線を引いたロードマップを可視化できたことによって、関係者全体の意識が統一され、事前に準備しておくような動きも見られるようになり、(とても苦労しましたが) とても効果の高い施策になったと思っています。
あわせて、物流・基幹システムのリプレイスロードマップも基幹システム本部長山本を中心に策定してきました。物流システムのリプレイスを2024年度末の3カ年、こちらはまだ荒いですが、基幹システムのリプレイスを2026年度末の5カ年で実施していく計画となっています。
ZOZOTOWNリプレイスの進捗としては、以下のようなプロジェクトを実施、リリースしてきました。来年もロードマップにあるような施策を引き続き実施していきます。
| プロジェクト | 説明 |
|---|---|
| セッションオフロードPh2 | セッションをウェブサーバのメモリに保持していたのを、外部オンメモリDB(Redis)に外出しした。ウェブフロントエンドリプレイスを開始する事前条件となっていた |
| ウェブフロントエンドリプレイスPh1 | ZOZOTOWNウェブサイトのアーキテクチャをSPA(React)にリプレイス。第一弾としてHOME面に着手した |
| カートリプレイスPh2 | Ph1ではカート投入処理にジョブキューを導入した。Ph2では在庫管理にDynamoDBを利用することで更新処理のスケーラビリティ向上を狙う |
| 会員基盤Ph1 | 会員情報を扱う機能のリプレイス第一弾 |
| プログレッシブデリバリー | マイクロサービス基盤にプログレッシブデリバリー機能を導入することで、N%リリースの割合増加リリースを自動化 |
おわりに
ZOZOグループ再編の効果を最大化するために、ビジネス部門と開発部門が融合しやすい下地となる組織を作るべく戦略策定に邁進した1年だったように感じます。役割の幅がアーキテクト・エンジニアリングマネージャからITストラテジストにまで広がったような感覚でした。戦略を策定するにあたっては、Zホールディングスグループ、特にYahoo! JAPANでの事例や数字をおおいに参考にさせていただきました。この場を借りて御礼申し上げます。
数々の戦略を策定してきましたが、執行に至らなければ価値はないので、きちんと実現し効果を出すために、来年さらに邁進していこうと思います。