「体制図にプロジェクトオーナー（PO）というのがいるけど、何をする人だろう？」「プロジェクトマネージャー（以下PM）とプロジェクトオーナー（PO）にはどのような違いがあるのだろう？」
ITプロジェクトに携わったことがある方で、このような疑問を持ったことはありませんか？
プロジェクトマネージャー（PM）とプロジェクトオーナー（PO）には似たような役割にも見えますが、権限と責任の範囲が異なります。POにどんな役割・責任を果たしてもらうかを明確にしておき、POとなる人と事前に調整しておけば、PMは現場のことに集中できます。が役割・責任を定義したところで、実際、境界があいまいになることもありますが、まずは、基本的な違いを適切に理解しておくことが重要です。
この記事では、JQ流の視点でPMとPOの違いを整理していきます。JQでは、役割と責任範囲の違いを明確にすることで、PM含め、プロジェクトのメンバーが迷うことなく業務を遂行できる環境を整えることができると考えています。
PMとPOの基本的な違い
PMの役割：
プロジェクトの現場における計画、推進実務を担う人。そしてプロジェクトの現場における意思決定者になります。
- プロジェクト計画実務（計画立案、スケジュール管理など）
- プロジェクト推進実務（課題解決、リスク対策など）
POの役割：
プロジェクトの企画内容、計画、結果の承認を担う人。そして、会社における意思決定者になります。
- プロジェクトのスコープ・成果の承認
- プロジェクトの体制・マイルストーン・予算の承認
- 社内外のステークホルダー調整
PMが立てた企画、計画をPOが承認し、プロジェクトがスタートします。
PMはプロジェクトの中で発生した課題を解決しながら、プロジェクトを推進していきます。
途中で、スコープやマイルストーン（スケジュール）、予算に影響が与えるような課題が出てきたら、対応方針をPOに示し、POは対応方針について是か非か判断します。
そして、例えば、他の役員と調整が必要であれば、POが率先して調整を図ります。
PMとPOの関係性はこのようなものです。
現場はPMが回し、会社としての承認や調整はPOが行うという分担です。
POの3つの主要な役割と責任
POの具体的な役割は以下の3つに整理できます。
1.プロジェクトのスコープ・成果の承認（Why/What）
POはプロジェクトの目的（Why）と範囲（What）を最終的に承認する役割を担います。
企画構想フェーズでの役割：
- ビジネス的な目的や目標の明確化
- プロジェクトのスコープ（対象範囲）の決定
- 期待成果（売上目標、コスト削減額など）の設定
開発フェーズでの役割：
- 要件定義の結果や開発進捗の結果に基づく、ビジネス的な目的や目標、スコープ、期待成果の変更の承認
POはプロジェクトの企画内容を承認するということで、当然、その企画の結果＝アウトカムについての責任を持つことになります。例えば、新規事業であれば、その事業の成否、システム刷新であれば刷新の成否、例えば、コスト削減につながったかなどに対して責任を持つことになります。
2.プロジェクトの計画・体制・予算の承認（Who/When/How much）
スコープ（企画構想）を決めた後は、そのスコープをどのような開発体制で実現していくか（体制）、また何か月、何年かけて実現していくのか（マイルストーン）、そしていくら投資をするのかという予算を整理していきます。
この整理もやはりPMがリードして行いますが、POの役割は、PMが整理した体制、マイルストーン、予算を承認することです。
要件定義以降の開発フェーズに入ると、例えば、要件定義の結果、スコープが膨らむ、コンサルやベンダーに問題があり体制組み換えが必要、遅延や品質問題に伴うマイルストーンの変更や予算の追加など、様々な変更が発生する可能性があります。
この変更の案をとりまとめるのは、PMが行いますが、その変更を承認するのはPOです。
企画構想フェーズでの役割：
- 開発体制（Who）の承認
- マイルストーン（When）の承認
- 予算（How much）の承認
開発フェーズでの役割：
- 開発進捗・品質の結果に基づく、体制、マイルストーンや予算の変更の承認
POは体制やマイルストーン、予算に責任を持つことになります。例えば、スケジュールが守れなかった、コストを超過したなどの事態になった場合は、最終的にはPOの責任となります。
3.社内外のステークホルダーの調整
POになるのは、そのプロジェクトを管掌する部門のラインの長や役員であることが多いと思います。
会社の組織形態によって変わりますので一概にはいえませんが、例えば、新サービスであれば、事業部門内のサービスであれば、事業部門長がPOになりますし、マーケ系のサービスであればマーケ部の部長やまたはマーケの管掌役員がPOになります。
業務システム系は、多くの場合は情報システム部門の長、または情シス管掌役員がPOです。
サービスであっても業務システムであっても多くの場合は、主管部門以外の部門に影響がでます。新規サービスであれば、事業部門やマーケ以外に情シスが関係しますし、業務システムであっても連携先システムの部門が関係したりします。
関係というのは具体的な作業が発生する可能性があったり、業務を一時的に止める、変える必要があるなどのことです。
また社内だけでなく、上場会社であれば株主への報告が必要なケースもあります。また、提携している会社や販売店などの外部パートナー、また規制当局の対応なども必要になるケースがあります。
この時に、POがステークホルダーと必要な調整を行います。例えば、他の部門の管掌役員に、影響を伝え、協力を依頼する、社長や株主への説明をおこなうなどです。PMが現場で動きやすいようにステークホルダーに情報を共有し、期待値をコントロールするなどのもPOの仕事です。
なお、POがステークホルダーと調整するといっても、例えば、外部パートナーにテストを依頼する、など具体的な作業調整は、PMの指揮の下、現場で行われるものです。POが調整するというのは基本的には、トップ間の調整という意味です。
社内ステークホルダー調整：
- プロジェクト主管部門以外の影響を受ける部門の管掌役員との調整
- 連携先システムの部門の管掌役員との調整
社外ステークホルダー調整：
- 上場会社の場合の株主への報告
- 外部パートナーとの調整
- 規制当局などへの対応
このように、POはステークホルダーへの説明責任を持つことになります。そのため、POもプロジェクトの内容をしっかり把握し（PMに報告してもらい）、内外の関係者と調整できるようにする必要があるのです。
ステアリングコミッティの課題
大規模プロジェクトでは、POの代わりにステアリングコミッティ（ステコミ）が設置されることがあります。しかし、ステコミには以下のような課題があります。JQでは、このような体制がプロジェクトを複雑にし、意思決定を遅らせる原因になるケースが多いと考えています。
合議制による意思決定の遅延：
- 責任回避により誰も決定を下さない
- 意見がまとまらずスピーディーな意思決定ができない
- プロジェクトのスピードが低下する
影響力の強い役員の口出し：
- 抽象的な要求によりプロジェクトが混乱する
- PMが役員対応に時間を取られ、本来の業務に集中できない
- プロジェクトの停滞を招く悪循環に陥る
これに対し、明確なPOが1人いる場合は、意思決定が迅速に行われ、PMが現場業務に集中できるため、プロジェクトのQCD（品質、コスト、納期）を守りやすくなります。
POが適切な役割を果たせる体制を整えることは、プロジェクトの成功に直結します。
まとめ
PMとPOの違いは、以下の点に集約されます。
PM：
- プロジェクトの実行責任者
- 計画立案と推進実務を担当
- 現場レベルの課題解決とチームマネジメント
PO（プロジェクトオーナー）：
- プロジェクトの最終責任者（会社全体のレベル）
- スコープ、体制、予算の承認を担当
- ステークホルダー調整と説明責任
PMが現場で整理したこと、まとめたことをPOに報告し、POはそれを承認する。
また、PMが現場で動きやすいように、POはステークホルダーに各種説明を行い、調整する。
PMとPOの間で、ここでまとめたような、役割と責任分担ができていれば、プロジェクトやよりスムーズに進み、成功確率が向上すると思います。
