PocochaでProduct Owner（PO）兼Engineering Managerをしている松田です。

Pocochaは2017年1月に日本でリリースされ、2021年3月末時点で255万DLを突破しました。 現在では日本の他にもUSとインドでもリリースされています。 グローバルに挑戦しているPocochaでは、今後の成長を実現するための組織拡大を進めており、エンジニアチームとしても200名規模の大規模な組織となることを想定しております。

スケーラブルな開発組織を構築していくため、Scaled Agile Framework®（SAFe®）やExtreme Programming（XP）、Behavior Driven Development（BDD）を導入し、アジャイル化を推進してきました。 アジャイル化を開始して、1年が経とうとしているので、導入の背景やSAFe®という大規模アジャイルの紹介などできればと思います。

アジャイル化した課題と背景

Pocochaには、組織全体が肥大化する中で、以下のような問題が起こり始め、チームが崩壊するリスクが存在していました。

• チーム単位でのフロー/リソース効率のマネジメント能力が低下
• チームトポロジーやキャリアラダーの導入などにより、結果としてコミュニケーション不全が発生

複雑性の高い開発をよりリーンに推進し、ビジネスアジリティを上げていくための解決策のひとつとして、Pocochaをみんなアジャイル化するPoco-agileが2022年7月に始動しました。実際に、Pocochaのプロデューサーである水田がPdMやエンジニアに1on1等でヒアリングを行い、現場の課題を把握した上で、「PocochaをみんなAgile化するぞ！」という号令をかけました。

まずは、アジャイルについての深く理解するための学習ギルドが設立され、読書会や議論を行いました。

Product Ownerとして、開発チームから生み出される価値を最大化するために、アジャイルQA学習ギルドとSAFe®学習ギルドに参加し、理解を深め、その後、開発チームとプロダクトマネジメント全体のアジャイル化に取り組みました。

開発チームのアジャイル化

元々、Pocochaでは、QA組織がチームの外にいたため、仕様書を提供し、テスト項目の作成やテストを実施してもらうといったウォーターフォールな開発をしており、基本的にリリースの頻度が月に1回となっていました。

そこから、アジャイルテスティングやXP、BDDの考えやプラクティスをもとに、QAをチーム内に入れるのを前提としたアジャイル開発フローを策定し、実践する1チームを立ち上げてトライアルを開始しました。

今では、1つのアジャイルチームの基本的な構成としては、PO 1人、QA 2人、Server 2人、iOS 2人、Android 2人として、アジャイル開発の実践チームを拡大して行っています。

アジャイルテスティングやBDDの考えやプラクティスの詳細は こちら の記事で紹介しています。

プロダクトマネジメントのアジャイル化

本記事では、プロダクトマネジメントのアジャイル化として行った「SAFe®の導入」について、主にSAFe®を導入した理由や導入のプロセスをご紹介します。

記事の流れ

1. SAFe®とは何か
2. SAFe®を採用した理由
3. どのように導入したか

SAFe®とは

Scaled Agile Framework®（SAFe®）は、リーンやアジャイル、DevOpsなどのプラクティスから構成されているナレッジベースのフレームワークです。

昨今、SAFe®はエンタープライズアジャイルと言われている大規模アジャイル開発として注目されています。

特にSAFe®は組織変革、組織にリーンアジャイルなマインドセットを根付かせるためのフレームワークでもあるという点が、他のエンタープライズアジャイルとは大きく違う点です。

Pocochaでは、まずはEssential SAFe®から導入を始めています。以下はEssential SAFe®のBig Pictureです。

SAFe®はナレッジベースのフレームワークと言いましたが、Big Pictureをみて分かるように、

Discoverに関するCustomer CentricityやDesign Thinkingなどの手法や、Deliverに関するScrum XPやContinuous Delivery Pipelineといった手法がまとめられています。

ARTと役割について

SAFe®では、バリューストリームに沿ってAgile Release Train（ART）と呼ばれる仮想チームを形成します。ARTは仮想チームであるため、サイロ化された階層構造の組織とも両立することができます。

ARTは、複数のアジャイルチームと、それを横断するプログラムチームで構成されます。そのうちアジャイルチームは、POとScrum Master、エンジニアで構成され、プログラムチームはProduct Manager（PdM）とRelease Train Engineer（RTE）、System Architectureで構成されます。

Release Train Engineerは、Scrum Masterの上位職であり、ART全体の進捗や進行に責任をもちます。複数のアジャイルチームの開発進捗やPdMやPOの要件定義の進捗を俯瞰的に見て、課題を取り除いたりします。（ここではPdMやPOの説明は省略します）

Pocochaでは、アジャイルチームは、POとエンジニア、QAでプログラムチームにはPdMとRTEを明確に定義しています。

POの役割は開発チームの生み出す価値を最大化させDeliverに責任を持つことです。PocochaのPOは、元々Pocochaでのエンジニア経験がある人が担っており、施策に対してより技術的な観点からリーンにスコープを定め、リスクの最小化し、仕様を策定していきます。また、アジャイルチームのフロー効率を高めるための改善を回したり、Engineering Managerとしてアジャイルチームのメンバーがプロダクトへの貢献を最大化できるようマネジメントしています。

Program Incrementについて

SAFe®におけるProgram Increment（PI）とは、時間枠のことです。PIは12週間（四半期）などの周期に設定され、この時間枠で上の図のサイクルを回していきます。

SAFe®の大きな特徴として、PIの開始直前に、PI Planningという計画策定会を実施します。PI Planningでは、PdMやPOが事前に準備したフィーチャーやそのユーザーストーリーをもとに、開発チームでプランニングポーカーなどで見積りや認識を合わせ、チーム間の依存を考慮して、いつ何ができるようにするのかをPI Objectiveとして目標を作成します。そして、その目標についてPdMやビジネスオーナーと合意をとります。

その後、PI期間に入ると、アジャイルチームはイテレーションを回し、スクラムオブスクラムズなど進捗や課題についてプログラムチームに共有しながら開発を進めていきます。

PI期間中、PdMは、次の試作の検討や要件定義を行い、PO SyncでPOに進捗やビジネス状況を共有ながら、次のPI Planningに向け準備します。PdMはDiscoverに注力できることで施策のクオリティが上がり、事前にリスクの相談などを行っておくことができるのがSAFe®のメリットでもあります。

SAFe®を採用した理由

大規模アジャイル開発として、SAFe®の他にLarge Scale Scrum（LeSS）が知られています。

LeSSは、Scrum@ScaleやScrum of Scrumをベースに提唱された手法で、最大8チームまで対応している手法です。

基本的に、複数のチームでスプリントを回しており、全体のスプリントプランニングを行なった後、チーム毎にスクラムと同様にスプリントプランニングや開発、バックログリファインメント、レトロスペクティブ、スプリントレビューを回します。

LeSSは、2週間などのスプリント単位で計画を行なって行くため、常に優先度が高い施策の開発やそれに適したチーム編成を行なって行くことができます。そのため、より柔軟で、自己組織化された組織には向いています。

ただし、プロダクトによってはそれがメリットでもあり、デメリットでもある場合もあります。デメリットの一例として、スプリント単位で施策の優先度を見直し、施策の要件や仕様を定義して行くことは、PdMやPOへの負荷が多くなりやすいといったこともあります。

Pocochaの場合は、OKRの運用を行なっており、四半期毎にOKRを策定していますが、開発チームには1つの施策の開発が終わるタイミングで、次に優先度が高い施策がアサインされるフローになっていました。そのため、開発チームは1,2ヶ月後には何を開発しているかはっきりしておらず、OKRが発表される時点では、開発チームとしてはどのOKRに貢献できるのかわからないような状態でした。

PI Planningを行うことで、開発チームで四半期分に開発する目標を立て、どのOKRに貢献していけるのかが明確にできるようになるため、PocochaではSAFe®を導入することとなりました。

どのように導入したか

PocochaでSAFe®を実際に導入するにあたってどう進めたかを紹介できればと思います。

まず、そもそもSAFe®というものを知らなかったため、SAFe®学習ギルドでは、外部のアジャイルコーチにSAFe®について講習を開催していただき、SAFe®の全体像について知りました。

ただ、SAFe®について情報をインプットした直後は、情報量が多すぎて何から手をつけて良いのかわからないといった状態でした。 Essential SAFe®のBig PictureにPocochaの体制やフローを当てはめ、SAFe®はやってるがPocochaでできていないことを整理しました。 例えば、ARTはプロダクト開発チーム全体のこと、ART BacklogはPocochaで運用していたプロダクトバックログ、SAFe ScrumはXP、Team Backlogsは各チームのJIRAバックログ、PIは四半期、PI Planningは対応なし、PI Objectiveは対応なし、 Scrum Masterは対応なし、など。

それぞれ当てはめながら議論を何度も重ねることで、共通認識を作りつつ、理解を深めていきました。そして、SAFe®はやってるがPocochaでできていないことが明確になっていきました。 上の例でも書きましたが、Pocochaで対応していないものの例として、Scrum MasterとPI Planningがあり、Pocochaではどうしていくかという議論を行いました。

Scrum Masterに関しては、アジャイル導入初期のチームには、アジャイル有識者がコーチとして入る。しかし、その後チームからは外れ、POやQA、エンジニアのチームメンバーで自律して運用していくこことしました。そのため、PocochaではScrum Masterというポジションは定義しませんでした。

PI Planningに関して、PI Planningのアウトプットとして、開発チームメンバーで「いつ、何を開発し、どういう価値を提供するのか」をPI Objectivesとして四半期分に開発する目標を設定します。それにより、OKRをチームまで浸透させ、またチームが四半期にどこまで開発できるかをPdMと認識を合わせることができるため、PI Planningの導入を最優先に進めました。

導入の基本的な方針としては、小さく始めて徐々に拡大です。

実際に、まずは2022年11月に1チームからPI Planningを始め、次に導入するチームのPdMを先に巻き込んでいました。 そして、2023年1月には3チームでPI Planningを実施し、さらにART Syncと呼ばれるScrum of ScrumsやPO Syncなども実践し、PI単位でのサイクルが周り始めました。 2023年4月には4チームでPI Planningの実施を予定しており、今後も2年分のスケジュールを決めており、実践するチームは徐々に拡大していっています。 ちなみに、Pocochaチームのほとんどの業務はフルリモートで行っているのですが、PI Planningはオフラインで実施しています。

PI Planningを実施したことで、「3ヶ月分の開発施策が事前にわかるので動きやすい」や「それまでオンラインでしか話したことがなかったので、コミュニケーションが取りやすくなった」、「他のチームの施策を聞けたことで連携しやすい」などエンジニアからポジティブな声がほとんどでした。 また、アジャイル化の成果が少しずつ見え始めており、わかりやすい成果としては、月1回だったリリースから、2週間に1回のリリースをできるようになりました。

PI Planningを実際に実施した詳細は、こちらの記事（近日公開予定）でも紹介しています。

今後

Pocochaはローンチして6年間で、ライブ配信アプリトップクラスとなり、USやインドにも進出し、グローバルに拡大しています。品質を落とさずに、Pocochaのビジネスアジリティをさらに加速させられるような組織を作っていかないといけません。

今、導入し、整備していっているようなフローやプラクティスをするだけでは「アジャイルをしている（Do Agile）」状態であり、やがて失敗する時が来てしまいます。SAFe®の導入などを通して、アジャイルのマインドセットを広め、Pocochaの文化として根付かせ「アジャイルである（Be Agile）」状態にしていくことが重要となります。

Pocochaの開発体制や開発フローがウォーターフォールからアジャイルになるなどこの1年で、大きく変わりましたが、Pocochaではまだより開発に近いところからしかアジャイルを初めていっている段階です。Pococha全体でみると、戦略やポートフォリオなど、まだまだスコープを広げていける余地があります。

アジャイル化やグローバル化といったチャレンジングな環境でサービスのスケールを成功させたい方、是非一緒にPocochaで働きましょう！