受託スクラムの体制検討ポイント（PO編）

# はじめに

- 受託スクラムでPO/SM/DEVのチームを作るときに考えるポイントをまとめました。
- 有名なアジャイルコーチの意見
- 自分の体験談
- 今回はPO編

# POは誰がやるんか問題
## アジャイルコーチの考え

https://www.ryuzee.com/contents/blog/7143

以下それぞれのケースのメリデメを紹介してくれています。実際PJの特性に応じて、誰がやるべきか考えるのが良いと思うので、この記事を参考に考えるのは良いと思います。

- 事業責任者がプロダクトオーナーを担う
- ビジネスサイドの人がプロダクトオーナーを担う
- UXデザイナーやアーキテクトの人がプロダクトオーナーを担う
- 顧客がプロダクトオーナーを担う

https://www.ryuzee.com/contents/blog/7125

「そもそも」の部分だけ抜粋しておきますが、それ以外の記載内容も確かになぁと感じるものばかりなので見ておきましょう。

- 多忙すぎるプロダクトオーナー
- 不在のプロダクトオーナー
- スクラムイベントに参加しないプロダクトオーナー
- 単にマネージャーやリーダーという理由だけのプロダクトオーナー
- そもそも複数人で意思決定権限が分散されたプロダクトオーナー
- プロダクトオーナーとスクラムマスターを兼任する
- スクラムマスターと対話できない、スクラムマスターからのフィードバックを受け入れない

https://kawaguti.hateblo.jp/entry/2019/12/07/070000

こちらは受託の文脈に近い形で、「発注側」「受注側」の双方が信頼しあってPOを行う「共犯者モデル」を提唱なさっています。（あくまで仮説とのこと）
顧客側の都合なのでこちらがPOを名乗れない場合でも、この観点は個人的に重要視しています。

**おまけ**

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">発注者側にPOをおいて、SMとDevが受注者側という構図で、POの機能不全を20年近く見てきているので、契約でPOの責任を定義したところでどこまで効果があるものなのかなぁ（きちんとできているPOも少数ながら見てきたけども）。</p>&mdash; Ryutaro YOSHIBA (@ryuzee) <a href="https://twitter.com/ryuzee/status/1597195172022190083?ref_src=twsrc%5Etfw">November 28, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

例えばPO側がPO責任の本質的な部分を理解していない場合、そのリスク対策として契約書などでどれだけ定義したとしてもそれが機能するわけじゃないな、ってのは自分自身の体験としても感じています。

**もうちょっと体系立った定義が見たい場合**

https://less.works/jp/less/framework/product-owner



## 実際の例（自分の体験談）
### 何かしらアンチパターンを踏み抜くしかない
個人的な感覚として、受託開発の世界でアンチパターンを避けるように動こうとすると、おそらくPOになれる人はいないし、そもそもスクラムができない。
なので、何かしらのアンチパターンを踏み抜く覚悟が必要。何よりもそれが第一歩。
尚且つその覚悟はステークホルダーこそが担うべきものであって、現場の１メンバーだけで担うものではない。

とはいえ、覚悟だけでPJが成功するわけでもないので、対策を考えておく必要はある。
POとなる人にはアンチパターンを踏んでいること、それに伴う不都合な現実を伝え、お互いの責任のもとに対処していく方針を合意する必要がある。

### POチーム
POは一人でやるべきという考えが基本であり、複数人でPOを行うのはアンチパターンと表現されることが多いです。
合議制などになった場合、決断が遅くなり、せっかくスクラムで強みにしている適応速度が損なわれます。

ただ、受託開発の場合、対面顧客の担当者が単独でプロダクトの責任を負えるケースは少ないです。
また、他の仕事を兼務しているなどで、単独ではPO業務を回せないことが見えており、顧客側でパートナーを雇い、それをPO支援として取り扱い、PO支援も含めた形でPOチームを組成しているケースが多いです。

そりゃまぁそもそもの仕事を調整して、単一の人間でPOを担当できる方が良い。
権限や責任も単一の人間に任せられるのであればその方がスピードが出る。
顧客側にできませんかねぇ・・・と聞いたり、提案したりもしたけど、なかなか外部から顧客の業務分担にまでは力及ばず・・・
（最初からアジャイルコーチとして経営層とも含めて会話できてればいいんですけど、開発ベンダーの担当者からの意見ではアプローチが難しい。。。）

### PO支援（PMO寄り）
顧客のパートナーさんが実施していることが多い。顧客常駐しつつPMO的な作業をしている感じの役割。
POとの違いは決定権を持てないことや、業務知識がほぼないこと。
あくまでPOが意思決定をスムーズに行うための下準備を、DEVメンバーと協力しながら行う。

### PO支援(PO寄り)
権限の都合でPOとは自信を名乗れないが、POの判断に対して積極的に意見を述べるポジション。
顧客側がPOをやるケースでサポートが必要な時に、開発ベンダー側からこのポジションを出すことはある。
バランス感覚がめっちゃ難しいポジション。できる人は少ない。

### アジャイルコーチ/社外研修
POがアジャイル経験値が少ないケースは多い。
社外研修をお勧めするんですが、なかなか時間が取れないので行ってもらえないことが多い。
その場合はアジャイルコーチの導入をお勧めしています。

ちなみにアジャイルコーチ的なことは弊社もやってるので、ご興味あればご連絡してみてください。（唐突なPR。ただ私は所属部署が異なるので、万一この事業が活況になったとしても私のボーナスは増えない。）

https://www.tis.jp/service_solution/pmo_support/agile_service/

ただ、アジャイルコーチの導入すらもお金を理由に断られるケースはあります。
このケースの時、受注側であってもPO側の動きに口を出せるようにPO支援を兼務することにしました。

逆にいうなら、PO側の動きに口を出せるスキルがない場合は、ちょっと厳しいような気がします。
失敗を織り込んだ上で、失敗しながら成功に向けて頑張っていこう！っていうスタンスならいいんですけど、このケースはあまり失敗も許容されないことが多い気がする。

### POが自身の責務範囲が果たせないことをPOだけの責任にしない
受託アジャイルの現場では何かしらのアンチパターンを踏み抜くことになります。
結果として、POが自身の責務範囲を果たせないことがあります。

これをPOだけの責任にしてしまうとまずいです。
PJ課題として全員が対処すべき問題として取り扱うべきです。
別にPO以外でカバーしたっていい。
目的はPJが成功することであって、スクラムというやり方に拘ることではない。

# 従来の役割との違い（私見）
あくまで実体験ベースでの差異なので、他の現場から見た時と比べると間違ってる場合はあるかと思います。

## PMとの比較（従来のウォーターフォール案件のPMと比べて）

同じ

- プロジェクトとして目指すべき目標達成のために必要な戦略・道筋を決める。
- PJリスクを見極め必要な対処方針を決定する。
- 目の前の作業の優先順位を決定する。

違い

- POにはスコープおよび納期の調整権限がある。
- POはDEVとフラットな関係である。（命令ではなく、納得で動いてもらう場面を増やす必要がある。）

難しさ

- スコープや納期の調整権限を得ることが難しい。（顧客側がPOするにしても、顧客側の現場担当にまで権限が降り切らないことが多い）
- ウォーターフォール文化に慣れていると、「フラットな関係」が理解されにくく、「命令」として受け止められがち。
    - 不確実性の高い案件においては、場合によってはPOよりもDEVの方が情報を持っているケースがあります。
    - 「命令」として受け止められてしまった場合、DEVが得ていた情報が反映されず、間違った判断・結果につながります。

## 従来の顧客という立場との比較

同じ

- 顧客側ビジネスとしての判断をする。

同じであって欲しいけど現実的には違う

- ビジネス的な都合と、開発側の都合を上手く引き出し、折り合いを見つけるスキルが必要。
- 見積もりや見通しがブレるものであり、保証できるものではないという前提に立っており、状況に合わせてスケジュールやスコープを見直す。
- 不具合は発生するものであるという前提に立っている。
- PO/SM/DEVで同じ責任を背負っている前提にたち、DEV側だけに責任を押し付けない/POだけでやり切ろうとしない。
- PO/SM/DEVはお互いに尊重し合う関係性であるという前提に立っている。

違う

- 結構イベントなどに時間取られる。（特にPOの思いが現場に伝わりきってない初期はしっかり時間とってDEVの判断を修正していくための支援が必要）

難しさ

- 顧客側の現場担当は上記前提に立っていてくれたとしても、その上の権力を持っている人がこの前提に立っていないことが多い。
    - 世代感ギャップみたいなもんだと思ってる。当時は今の考え方が一般的ではなかったので、お互いの常識が異なるという印象。

# まとめ
## 「どこにでも通じるPM像」というものは無い
ぶっちゃけ各社の文化とかにも依存するし、どこまで分けられるのかって難しい。
試しに「PO PM 違い」とかでググって出てきた例で以下があるんですが。

- PMは要員リソースを管理しますが、POは管理しません、

「要員リソース」ってのが何を指すかですけど、「調達にどれくらいコストをかけるか」みたいなのは、私の関わる現場ではPO（顧客）が見てます。
だからこの例が間違いだ！とかではなく、それぞれPMと解釈していたものとかにも現場によって多少のずれはあると思いますし、POに求めるものも変わってくると思っています。権限としてどこまで下ろせるかなども変わってきます。
いろんなものを参考に今の現場としてのPOの役割を決めていただければと思います。

## アンチパターンは踏み抜くもの
受託アジャイルをするのであればアンチパターンは必ず踏みます。なるべく避けるべきですが、踏まざる得ないものは、周りの理解を得た上で対策を立てた上で踏み抜いていきましょう。

地雷原の先にしか受託アジャイルの未来はないです。
後続の受託アジャイルが少しでもやりやすくなるように、地雷を踏み荒らしていくのだ！という気持ちで進みましょう。

# 次回予告

次はスクラムマスター編。これも悩むよね。でもPOと比べて情報少ない印象。