1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【プラクティス紹介】1分でさらっと分かる「エリアプロダクトオーナー」

Last updated at Posted at 2025-04-13

apo.jpg

プラクティス名(別名)

エリアプロダクトオーナー (APO、POチーム)

プラクティスの目的・狙い

  • 大規模プロダクトの要求事項を複数のPOで手分けして管理する

どんな時に使うか

  • プロダクトの規模が大きすぎて一人のPOが全領域をカバーすることが難しい時

LeSS: 2~8のスクラムチームで行う大規模アジャイル開発のフレームワーク
LeSS Huge:9チーム以上で行う大規模アジャイル開発のフレームワーク
APOというロールが登場するのはLeSS Hugeからです。8チームまではできるだけスクラムの原則通りに一人のPOが管理することが望ましいとされています。

実施手順

  1. プロダクトバックログ(PBL)に記載された要求事項(PBI)を特定の観点(例えば業務ドメインや顧客セグメントなど)で分類する(=要求エリア
  2. 全体を統括するPOとは別に、要求エリア毎に管理者を任命する(=エリアプロダクトオーナー
  3. APOはその要求エリアにおいて、POとして振る舞う
  4. APO間で要件調整や優先順位検討が必要な場合は全体POにエスカレーションする

エリアプロダクトバックログ(APB):
PBLを要求エリア毎に切り分けたものをエリアプロダクトバックログと呼びます。概念的にはAPBはPBLから特定のエリアの情報だけを抜粋した一種のビューのようなものであり、PBL自体はあくまでも1つ、というのがLeSSの考え方です。ただし実運用上はPBLとAPBは記載粒度が異なる場合もあり、物理的に分けて管理するケースが多いと思われます。

アレンジ例

  • 全体POがどこか一つのAPOを兼務する場合もある
  • 8チーム以下の規模でも、専門知識が必要となる特定の領域に関してはAPOを立てる場合もある

アンチパターン

  • 全体POがAPOに任せきりで、PBL/APBの全容(全体感)を把握していない
  • APO間のコミュニケーションが不十分で、各エリアで対応方針が異なる

参考情報

参考書籍

LeSS公式WEBサイト

こぼれ話(私的コメント)

スクラムガイドには「POは一人の人間であり、委員会ではない」とハッキリ書かれています。スクラムマスターやっててもPO複数名はやっぱアンチパターンだなぁ、と感じることも多いです。にもかかわらずPO委員会になってる現場って少なくないんじゃないかと。POできる人って業務側のキーマンだったりするので大抵忙しくて一人じゃ回らないんですよね。そもそも専任POじゃないケースも多いし。
APOというロール自体、POは本来一人がいいけど、プロダクト規模が大きくなると、もうしょうがないよね、という苦肉の策という印象です。POが複数名になることで、PO同士の認識合わせ/合意形成の時間も必要になってくるため、余計にPOの負荷が高まるという悪循環もあり、なかなか悩ましいです。少なくともDEVが誰に話しかければよいかは迷わないようにしておきたいところですね。


 アジャイルプラクティス一覧へ戻る

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?