ZOZOTOWNのiOSチームを支えるチーム運用

ZOZOTOWNのiOSチームを支えるチーム運用

こんにちは、ZOZOTOWN開発本部でZOZOTOWN iOSの開発を担当しているらぷらぷです。

2024年8月現在、ZOZOTOWN iOSチームは正社員と業務委託の方をあわせて全14人で構成されてます。

組織上、ZOZOTOWNのiOSチームは開発1部と開発2部の2チームに分かれています。しかし、リリースバージョンの計画・開発フロー・技術課題・その他チームに関わる課題意識はiOSチームメンバー全員で共有しながら改善を進めています。

そのような共有・議論がここ数ヶ月、週次イベントとして固定化してきたので、各イベントの振り返りも兼ねて皆さまにZOZOTOWNのiOSチームを支えるチーム運用の数々を紹介します。

1つのバージョンがリリースされるまで

まずはこちらの図をご覧ください。

QA準備からリリースまでの流れの図

ざっくりですが開発期間を省いてQA準備からリリースまでの流れを描きました。今年から毎週金曜に定期的にQA配布する流れになりました。

週次イベントは「リリース系」と「チーム活動改善系」に分けられます。

  • リリース系
    • バージョン計画会
    • ぽちぽち会
    • QAビルド配布
    • App Store申請
  • チーム活動改善系
    • 開発生産性MTG
    • Rethink!
    • Confluenceリファクタリング会
    • 今週の振り返り

スタンドアップ

毎日スタンドアップミーティングを30分設けてます。図中金曜日の「今週の振り返り」はスタンドアップミーティングの中でやってます。

スタンドアップおしらせさんのスクリーンショット

ちなみにこのSlack AppはZapierで実装しました。毎週火曜日は1時間枠の定例なので、その曜日だけはConfluenceの議事録を取得してSlackに投稿するよう分岐してます。

リリース系

バージョン計画会

担当する案件を持つメンバー(以下案件オーナー)とともにリリースバージョンを整理し、スケジュール進行およびリスクを定点チェックします。

各案件オーナーは主に以下の情報を整理します。

  • 案件情報(Confluence、Jira)
  • 開発時期
  • QA時期
  • App Storeに掲載するリリースノートの有無
  • App Storeへのリリース日が固定か
    • 固定の場合、バージョンに同梱される他案件のスケジュールも当案件に優先される
  • リリースノート・リリース日に影響する要素の有無
  • スケジュール決定・進行にまつわるTODO・リスク

各リリースバージョンにはバージョンマネージャーが決まっており、バージョンマネージャーは上記の案件オーナーと協力して以下の情報を整理します。

  • 各イベント開催日
    • ぽちぽち会
    • QAビルド配布
    • App Store申請

毎週金曜日のQAビルド配布という動きが決まるまでは、リリース日から逆算してバージョンをどう調整するかパズルのように組み合わせるのが大変でした。

加えて案件以外の小さなbugfixを入れるタイミングがルール化されてなかったので、「この案件に相乗りしてもいいのか、でもそれはQA負荷高いのかな?」と思考することも多かったです。

今では定期リリース枠に何が入るかを整理しているので、スケジュール立ては以前ほど考えることが少なくなっています。その結果、開発からリリースまでのスケジュール立てに対する認識が全員揃いやすく、小さな改善も定期的にリリースできるようになりました。

ぽちぽち会

リリース対象の機能・修正をQAビルド配布前にチェックする会です。

Gatherで集まってJiraの内容を確認しつつ実機・シミュレーターで“ぽちぽち”やっています。このタイミングでバグを見つけることもあり、見つけ次第修正してからQAチームに配布しています。

例えば「この動作って想定外ですか?」といった仕様確認や、「このテキストをこう変えるとお客さんに伝わりやすいかも?」「このタップエリアはもっと広くした方が使いやすいね」などのフィードバックが出てきます。

この会に力を掛け過ぎるとQAチームのチェックと重複することもあり、お互いにどう品質をカバーしあうと良いか模索中です。

QAビルド配布・申請・リリース

QAチームにチェックをお願いし、問題なければApp Storeへ申請します。

このルールが言語化されて他チームに伝えやすくなってから、スケジュール立てが楽になりました。そうとはいえ、このドキュメントは他チームに伝え続けないといけないので、参照されやすさをどうConfluence上またはSlackで実現したらいいかなと考えてます。

チーム活動改善系

開発生産性MTG

コードベースの技術的な課題を除くチームの課題に対して議論する場です。

技術的課題を外すという意味で「開発生産性(仮)」と付けてましたが、よい候補が見つからずこのままの名前になってます。案件オーナーとしての開発マネジメント、PRレビュー、メンバー間の情報格差など、チームがより成熟するのに必要な課題を整理してアクションを設計してます。

Rethink!

技術的な課題をチームメンバーで定期的に見直す会です。技術的負債と感じてること、Appleが提示している技術への所感や適応への方針、自分だけしか分かってないかもと不安になることなど、お題は多岐に渡ります。

Rethink!で話したことはアーカイブとしてConfluenceに残し、過去の意思決定資料として参照します。

開発生産性MTGとRethink!は「立ち止まって振り返って分析する」イベントで、ファスト&スローでいうところのスローにあたります。案件開発中の迅速な意思決定(ファスト)だけで方針の方向性を埋めないようにしてます。

Confluenceリファクタリング会

iOSチームのドキュメントはConfluenceにまとまっていますが、時が経つにつれてドキュメント(知識・運用)も風化していきます。この会は、メンバーの入れ替わりや運用の改善などチームの状況に応じてドキュメントを絶えず改善するための会です。

主に以下の内容を話しています。

  • 最近追加したドキュメント
  • 最近削除したドキュメント
  • 今後欲しいドキュメント
    • 書きたい
    • 可能なら誰かに書いてほしい

ちなみにiOSチームのConfluenceは以下のような階層リストになっています。

  • 背景
    • コードを読んでも理解できないドメインの説明
    • 設計方針
  • ルール
    • 実装例
    • 開発・デバッグ方法
    • 運用ガイド
  • メモ
    • 背景・ルール以外
    • 書き始める場所に困った時ここから書き始める
  • アーカイブ
    • 過去の経緯・議事録など、最新情報ではないが資料として残したいもの

今でこそ、このような階層リストになってますが、それまでは欲しい情報を辿るのに難しく整理しづらい状態でした。この構造に決めるまでの議論を開発生産性MTGで進めていました。

今週の振り返り

毎週金曜日はスタンドアップ中にチーム振り返りをしてます。うまくできたこと、思うようにいかなかったこと、来週の不安などをシェアしています。

また、業務委託の方含め全員が揃う木曜日は「今週の凄い人達を褒める」ことを習慣化しています。導入時はチームメンバー内の褒め合いになり、褒め合い慣れてない独特の空気がちょっとおもしろかったです。今では他のチームの褒めも積極的にやっていこう、というのがZOZOTOWN iOSチームのテーマになってます。

スタンドアップおしらせさんのスクリーンショット

おわりに

ZOZOTOWNのiOSチームの開発、雰囲気、文化を維持して改善するための運用を紹介しました。

ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください!

hrmos.co

corp.zozo.com

カテゴリー