外注&アジャイルでシステムを開発・導入する場合、プロダクトオーナーはどちらに立てるべきか

エンタープライズシステムを外注で作る際にプロダクトオーナー(PO)を発注側(事業会社側)か受注側(ITベンダ側)のどちらに立てるべきかについて、『エンタープライズアジャイル開発実践ガイド』に面白い記載があったので、それを参考にPOの配置について考えてみたいと思います。

なお、この記事では参考書籍と同じくスクラムによるアジャイル開発を前提としています。

結論
発注側(事業会社)に立てるほうがよい場合:
・発注側が既にアジャイル開発を理解または実践している場合
受注側(ITベンダ側)に立てるほうがよい場合:
・発注側に思いがない場合
・プロダクトに十分にコミットメントできるPO候補がいない場合
・業務改革を含むシステム開発・導入案件でITベンダ側があるべきを理解している場合
・Fit to standardによるSaaS導入などITベンダの方が業務にも技術にも精通している場合

プロダクトオーナーはベンダ側に置くべき？

POはプロダクトの価値を最大化することに責任を持ち、プロダクトバックログを管理することでプロダクトの方向性やどんな機能をどんな優先度で実装するか、といったことを決定します。

そのため、外注でシステムを開発・導入する場合、プロダクトオーナー(PO)は、発注側(事業会社側)で立てるのが自然だと思います。しかし、『エンタープライズアジャイル実践ガイド』では、外注(ITベンダが開発する)の場合、次のような問題に直面することが多いことから、基本的にベンダ側に置くべきだとしています。
・プロダクトオーナーと開発チームが密に連携するのが難しい
・他業務との関係で、プロダクトオーナー起因の遅れが生じる可能性が高い

ベンダーとその顧客の受発注の携帯で開発をする場合、根本的な解決策として、プロダクトオーナーはある程度発注側の業務を知っているベンダー側の人間が担当します。理由は、プロダクトオーナーにはある程度のシステム開発の知識が求められるからです。そしてベンダー側の人間の方が開発チームとのコミュニケーションが取りやすくなります。
(中略)
ベンダー側の人間は発注者側がプロダクトオーナーを担当したいと申し出ない限り、自社にプロダクトオーナーをおいてください。従来の要件定義の際の折衝と、プロダクトオーナーでは必要な目線、価値観、作業時間が全く異なります。にも関わらず顧客側にプロダクトオーナーを任せてしまうのは、ベンダーが無責任と言っても過言ではありません。

『エンタープライズアジャイル開発実践ガイド』 p.30

確かに、POを担当するためには、業務と技術両方の知識を持ち、長期的な視野でプロダクトの方向性を考えられる人材である必要があります。このような人材は事業会社の中でも貴重で、多忙であることが多いため、POとしてプロダクトに十分な時間コミットして頂くことは難しく、プロジェクト推進上、ベンダ側にPOを立てるという選択肢は一定の合理性が認められるでしょう。

ここからは、POを発注側(事業会社側)と受注側(ITベンダ側)のそれぞれに立てた場合の役割分担と、その場合に必要なことを考えてみたいと思います。

プロダクトオーナーを発注側(事業会社)で立てる場合

役割分担

役割分担としては次のようになります。スクラムマスターや開発チームはリソースの状況に応じて発注側と受注側で分担されることになると思います。この分担は、内製でアジャイル開発を実施する場合に近く、あくまで受注側(ITベンダ)は専門性の提供にとどまります。

どんな場合に適する？

こちらは発注側が既にアジャイル開発を理解または実践しており、POあくまで専門性の提供や、要員不足の補填の目的でベンダが使われることになります。

一方で、発注側のアジャイル開発に対する理解が不足している状態で、ベンダ側主導でこの体制を提案するのはリスクが高いと言えます。

事前に合意しておくべきこと

この体制を取る場合、トラブルを避けるため、プロダクトバックログの管理やステークホルダーへの説明責任などのPOが果たすべき役割・責任について文書化し、合意しておく必要があるでしょう。

さらに、他業務による当該プロダクトへの影響を最小にするために、POを可能であれば専任アサインにしてもらうなど、POが当該プロジェクトのために十分な時間コミットして頂くことの合意も必須と考えます。

プロダクトオーナーを受注側(ITベンダ)で立てる場合

役割分担

役割分担としては次のようになります。基本的にプロダクトオーナー、スクラムマスター、開発チームという開発に関わる要因は全て受注側(ITベンダ)で持ち、発注側はステークホルダにします。場合によっては開発チームに発注側の一部メンバが入ることもあるでしょう。

どんな場合に適する？

こちらは『エンタープライズアジャイル開発実践ガイド』で指摘されている次のような問題がある場合に適しています。
・プロダクトオーナーと開発チームが(会社を超えて)密に連携するのが難しい
・他業務との関係で、プロダクトオーナー起因の遅れが生じる可能性が高い

個人的な経験としては、本来あるべきではないですが、発注側(事業会社)に思いがなく、丸投げしようとしている場合などもこの方式を取らざるを得ないと考えます。

また、業務改革を含むシステム開発・導入案件でITベンダ側があるべきを理解している場合や、エンタープライズシステムでよくあるFit to standardによるSaaS導入などITベンダの方が業務にも技術にも精通している場合は、ポジティブにこの方式を選択できるのではないかと考えます。

事前に合意しておくべきこと

この役割分担には一定の合理性があるものの、注意が必要だと考えます。受注側に開発チームがあり、発注側が要望を出す構図は、実は伝統的な外注&ウォーターフォールの構造と同じです。そのため、油断するとPOがPOとしての役割を果たせず、長期的な方向性も、技術的な考慮もないままに単に発注側の言う通りにシステムを作ることになってしまう可能性があります。（しかも、最悪なことにアジャイル開発を行う契約だとITベンダ側が自らの身を守るウォーターフォールの最後の砦であるQCDが存在しない！）

そのため、ステークホルダーとしてプロダクトに対してフィードバックを行う担当者よりもさらに上位の役職の方と、POがPOとしての仕事を全うできるように守ってもらえるように、つまり最終決定者はPOであり、感情的、非合理的な口出しはできないように合意をしておく必要があるでしょう。

おわりに

まとめると、次のような使い分けができるのではないかと思います。
発注側(事業会社)に立てるほうがよい場合:
・発注側が既にアジャイル開発を理解または実践している場合
受注側(ITベンダ側)に立てるほうがよい場合:
・発注側に思いがない場合
・プロダクトに十分にコミットメントできるPO候補がいない場合
・業務改革を含むシステム開発・導入案件でITベンダ側があるべきを理解している場合
・Fit to standardによるSaaS導入などITベンダの方が業務にも技術にも精通している場合

個人的にはPOは発注側(事業会社)に立てるの一択だと思っていたのですが、現状受注側(ITベンダ)に立てた方がよい場合も多いことがわかりました。