はじめに
こんにちは、ブランドソリューション開発本部プロジェクト推進部PMOブロックの三谷です。普段はPMOとして、ファッションコーディネートアプリ WEARの開発組織が企画を実現する上で発生する様々な課題の解決サポートを行っています。
WEARは2014年のローンチ以来アップデートを繰り返し、様々な機能をリリースしてきました。その中で、1つ1つの案件が大きくなってしまうことがしばしばあり、リリースまでのリードタイムや価値検証のサイクルが長くなりすぎてしまうことがありました。この課題を解決すべく、2024年5月より私たちPMOブロックは開発責任者@tsuwatchのもと、スクラム開発の導入を推進しました。本記事では、スクラム導入におけるPMOの取り組みをご紹介します！
なお、今回ご紹介する内容はWEARのアプリ開発に限った話であり、Webサイトの開発は対象外としています。
目次
背景
これまでWEARでは、ビジネス的な観点やUXの観点などから様々な要件が盛り込まれて工数が膨れ上がり、最終的な成果物によって得られる効果に見合わないほど工数が大きくなってしまうことが多々ありました。そこで、2024年5月のフルリニューアルが完了したことを機に、その後の機能開発は最低限の要件に絞って早くリリースし、ユーザーの反応を見て次の手を打つスクラム開発を導入しました。また、これまでの開発では企画〜リリースまでの各プロセスのリードタイムやリソースの効率などの各種メトリクスが可視化されておらず、チームの成長や積み上げ、生産性が向上しているかがわからない状態でした。スクラムの導入と共に、これらのメトリクスを可視化する仕組みも取り入れ、チームが振り返りながらより早くユーザーに価値を届けていける体制を構築しました。
スクラム開発の導入
WEARの内情に合わせたスクラム体制の構築
WEARの開発には、「PdM」「エンジニア」「デザイナー」「QA」など様々なロールのメンバーが関わっています。
その中でも特にWEARひいてはZOZO社（以下、ZOZO）の開発において特徴的と言えるロールが、「デザイナー」です。ZOZOではZOZOTOWN、WEAR、FAANS、ZOZOマッチなど様々なサービスを展開していますが、それらのユーザー体験はすべてデザイナーによってデザインされています。また、各サービスは独立してデザインされるのではなく、デザイナー組織のディレクター（以下、便宜上「デザインディレクター」と呼びます）が各サービスを統括して全体の世界観を保っています。そのため、WEARのデザインにおいてもデザインディレクターの承認を得る必要があり、そのこともスクラム体制に盛り込む必要がありました。
また、もう1つの特徴として「QA」がエンジニアから独立している点があります。エンジニアだけでテストを行う会社もあると思いますが、ZOZOではQA組織がエンジニアと独立して存在しており、開発が完了した成果物はQAによって検査することで品質を担保しています。この点もスクラム体制に盛り込みました。
このようなWEARの事情を考慮して構築したスクラム体制を以降で紹介していきます。
チームとロール
WEARではスクラム導入以前から、個別のKPIを立てた3つの開発チームが存在していました。スクラム導入ではこのチームをそのまま引き継ぎ、3チームそれぞれ個別のバックログを持った1つのスクラムチームとなるようにしました。1つのチームのメンバー構成は、主に以下の通りです。
| ロール | 人数 | 主な役割 | |
|---|---|---|---|
| PdM | 1名 | スクラムではプロダクトオーナーを担います | |
| デザイナー | 1〜2名 | デザインの作成を担います | |
| エンジニア | BEエンジニア | 2〜3名 | BEの開発を担います |
| iOSエンジニア | 2〜3名 | iOSの開発を担います | |
| Androidエンジニア | 2〜3名 | Androidの開発を担います | |
| QA | 1名 | 品質管理を担います | |
| アナリスト | 1名 | ユーザーの行動を分析し、チームの意思決定のサポートをします | |
また、開発責任者（1名）とPMOが3チームを横断的に支援する構成にしています。上記の各ロールをスクラムの3つの役割である「開発者」「プロダクトオーナー」「スクラムマスター」に割り振ってスクラムを行っています。以降では、その中でもWEAR特有の構成である「スクラムマスター」と「開発者」について具体的に説明します。
スクラムマスター
一般的なスクラムと比べると特殊かもしれませんが、以下のようにスクラムマスターの役割を2ロールで分担して担っています。
横断的に3チームを俯瞰するスクラムマスター
スクラム導入期には、3チームでの一斉導入にあたって本記事で紹介している体制の検討や基盤となる仕組みやルールの整備、メンバーへの教育など、様々な導入支援を行う必要がありました。この役割は、私の所属するPMOブロックが担いました。私を含めブロック内でスクラム開発に詳しい者がいなかったため、Scrum Allianceの「認定スクラムマスター（CSM）」を取得して学習したり、社外のスクラムコーチに相談したりして進めました。様々な観点を検討した上で、開発に関わるメンバー全員へスクラム導入のメリットが伝わるよう説明をしました。
スクラム導入後は、実運用で発生した課題に対する解決案の検討やそれに伴う仕組みの管理、スクラムチームがより良い開発をしていくための提案などを行っています。スクラムチームが直面する課題には、チーム外のステークホルダーが関わっていたり、複雑なため解決策を時間をかけて整理する必要があるなど、チームが単独で解決するにはコストのかかるものがあります。そういった課題に対して、実際に手や頭を動かして解決に導く役割を担っています。後述する、実運用で発生した課題とその解決策や今後より良い開発チームを目指してPDCAを行なっていくためにも、私たちPMOブロックが担った課題解決の一例ですので、ぜひご覧ください！
チーム専属でスクラムを進行するスクラムマスター
今回ゼロからスクラムを始めるにあたり各チームには進行役のスクラムマスターが必要でしたが、PMOはスクラム以外の課題も担当しており、さらに人数も不足していたため、アサインできませんでした。そのため、各チームにはスクラム導入以前から開発進行を管理する「チームリーダー」がエンジニアから1名設定されていましたが、彼らにスクラムマスターの役割もお願いしました。スクラムイベントの進行やチーム改善などを行ってもらっています。
また、PMOとチームリーダーは毎週定例会を実施しています。そこでは、各チームの課題相談やナレッジの共有、必要に応じて全体の共通ルールの検討なども行い、改善活動を行っています。
開発者
エンジニア、デザイナー、QAが担います。WEARではデザイン、開発、QAがそれぞれ専門のロールに分かれているため、スクラムチームではそれぞれのロールが専任で担当します。ただし、役割やタスクを綺麗に線引きするのではなく、互いに補完し合ってチームとして必要なことを全員で実施していくようにしています。
エンジニアについて補足すると、WEARはiOS、Androidで同様のアプリを提供しているため、機能開発を行う際は基本的に両OSで同じ機能を同時に開発します。そのため、1つのチームに両OSのエンジニアがそれぞれアサインされています。
また、WEARの特徴的なロールとして先述したデザイナーとQAもスクラムチームに含めて開発しています。
スプリントの動き
各チームが2週間のスプリントで開発し、スプリントプランニング、デイリースクラム、スプリントレビュー、レトロスペクティブ、リファインメントを実施しています。その他、一般的なスクラムと大きく差がない部分は割愛し、以降ではWEAR特有の仕組みをメインで紹介します。
リファインメント
毎週定期で開催（例：1時間 × 2回）し、次のスプリント以降で開発着手したいプロダクトバックログアイテム（以下、PBI）を着手できる状態（Ready）にしています。
デザインの作成もReadyの条件に含めていて、リファインメントで完了させています。先述したように、デザインの完了にはデザインディレクター承認が必要ですが、開発着手までにとる構成にしています。
また、リファインメントでは、バグとなりうる仕様をあらかじめ排除する等の目的で、QA観点での仕様検討も行っています。
開発〜リリース
リリースタイミングは定期で定めていて、スプリント終了後の翌営業日としています。開発が完了したPBIに対して順次、デザインレビュー・QAを行い、スプリント内でデザインレビュー・QAまで完了したものを次のリリースタイミングでリリースしています。以下の図は、いくつかのPBIの進行例を示しています。その中でも【A】と【D】のように、1週目で開発を完了させて2週目でデザインレビュー・QAを完了させることで、1スプリントでリリースできることを目指してPBIのボリュームを調整するようにしています。
ツールと運用方法
WEARでは、スクラムの進行にJiraを使用しています。Jiraにはバックログやスプリントの管理など、オンラインでスクラムを行う上で必要な機能が一通り備わっています。ここでは一般的なJiraの機能の紹介は割愛しますが、WEAR特有の使い方をしている部分を紹介します。
ストーリーポイント計算の自動化
PBIで必要な作業を各ロールがJiraの作業項目を作成して管理していますが、各作業のストーリーポイントを同名のフィールドにつけることで、スプリントプランニングやベロシティ計測に使用しています。WEARでは、1つの作業項目（親）をさらに細かい粒度のサブタスク（子）に分割して作業進捗を管理しており、サブタスク一つひとつにもストーリーポイントをつけています。
- 作業項目の粒度の例：〇〇画面のUI改修
- サブタスク粒度の例：ボタンのレイアウト追加、〇〇処理にログを追加
Jiraの仕様では、ベロシティに計上されるストーリーポイントは作業項目のもののみで、サブタスクのストーリーポイントはベロシティに計上されません。そのため、親の作業項目にサブタスクのストーリーポイントの合計値を計算してつけなければなりませんが、デフォルトでは、サブタスクを追加やストーリーポイントを修正する度に手動で計算する必要があります。WEARでは、Jiraの「自動化」機能を用いて、サブタスクのストーリーポイントが変更されたのをトリガーに自動で親の作業項目とストーリーポイントを同期するシステムを組み込んでいます。
リードタイム計測の自動化
WEARでは、スクラムにおける各工程のリードタイムを計測して振り返りを行っています。作業項目やサブタスクの「実施開始日」「実施終了日」というフィールドに、作業した実際の日付を入力することで計測していますが、通常は手動で入力する必要があります。こちらもJiraの「自動化」機能を用いて、作業項目やサブタスクのステータスが変更されたのをトリガーにして自動で実施開始日・実施終了日を入力するシステムを組み込んでいます。
実運用で発生した課題とその解決策
PBIの方針がチーム内で決まらずスピード感が損なわれる
PBIの方針は、前述のWEARの内情に合わせたスクラム体制の構築で説明したように、スクラム外のデザインディレクターの承認を得る必要があります。そのため、チームのリファインメント内で決定ができず別枠でMTGを設けてデザインディレクターを含めて検討することになりましたが、なかなか予定が合わず、決定までに時間がかかってしまうことがありました。解決策として、デザイナーがデザインディレクターとの定期MTGにて相談した上で次回のリファインメントに持ってきてもらうようにしました。また、PBIの方針案を固めてからディレクターに相談するのではなく、検討の初期段階から相談するようにして後から方針が再検討になることを防ぎました。これによって、リファインメントのスピードが向上しました。
QAのリソース不足によるリリース先送り
QAのタイミングについてスプリントの動き - 開発〜リリースで紹介しましたが、もともとはPBIごとではなくそのスプリントで開発完了したものをスプリントの後半1週間でまとめてQAをする運用でした。そのため、開発完了するPBIが多いスプリントではQAリソースが足りず、開発完了していてもリリースは次のスプリントに先送りというもったいない事態になることがありました。解決策として、QAでのバグ起票の多さがQAコストにつながっていたので、レトロスペクティブにバグを振り返る時間を作り、ユニットテストレベルのバグは開発段階で潰すことを目指しました。また、QA開始のタイミングをQA担当者に調整してもらい、PBIの開発完了タイミングでPBIごとに並行してQA開始できるようにしてもらいました。イメージはスプリントの動き - 開発〜リリースの図を参照ください。結果として、QAのリソース不足は解消され、リリースが先送りになることがなくなりました。
スクラムを導入した効果
リリーススピードが向上
スクラム導入以前はリリーススピードを計測していなかったため正確な評価ではありませんが、以前の体制で実施した一定期間の案件実施数と比較すると、案件実施数が増えました！また、PdMからも明らかにリリース件数が増やせたとコメントをいただきました！
チームの自己組織化
定期的なスクラムイベントの実施により、チーム内のコミュニケーションが円滑化し関係値も構築されました！また、PdMやアナリストからユーザーの行動やチームKPIの進捗が共有されることで、目標に対するチーム全体の意識が高まり、チームで振り返り→その後のアクションを立てられるようになりました！
今後より良い開発チームを目指してPDCAを行なっていくために
質と量を意識した開発
前述の通り、リリーススピードが向上し、従来よりもたくさんのアウトプットをユーザーへ届けられるようになりました。質も当然意識しつつ、ユーザーの反応を見ながら開発を進めていましたが、まずはアウトプットの量を増やすことを目標としていました。その点は一定達成できたため、次のステップとしては、質と量の両方を意識して効率よく大きなアウトカムを生み出すことを目指しています。具体的な取り組みとしては、PBIの期待度をスコア化して期待度と工数のバランスを見てチームの動きを改善していく仕組みを検証しています。今後、良い仕組みが確立できたら別の記事にて紹介します！
まとめ
本記事ではWEARのスクラム導入について、私たちPMOブロックが行ってきた支援について紹介しました。一筋縄ではいかない課題がたくさんありましたが、一つひとつ検討を繰り返して今のスクラム体制を築くことができました。開発チームに同じような課題を持たれている方がいれば、ぜひ参考にしてみてください！
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
