プロダクトマネジメントとは？発注者がPOとPMの違いと役割を理解する

アジャイル開発を外部ベンダーに発注したら、キックオフで「プロダクトオーナーは発注者である〇〇さんにお願いします」と言われた——。そんな状況で、何をすればいいのか分からず戸惑っていませんか。

これまでウォーターフォール、つまり要件定義書を渡して完成品の納品を待つやり方しか経験がないと、「自分が開発に関わり続ける」という前提そのものに馴染みがないものです。ましてや社内に相談できる開発出身者がいなければ、「丸投げできないのは分かったけれど、では具体的に何を・いつ・どこまでやればいいのか」という疑問に答えてくれる人もいません。「自分の判断が遅れて開発が止まってしまったら」という責任のプレッシャーも重くのしかかります。

この不安の正体は、多くの場合「役割の全体像が見えていないこと」にあります。プロダクトマネジメントとは何か、自分が任された「プロダクトオーナー（PO）」とは何をする立場なのか、よく混同される「プロジェクトマネージャー（PM）」とどう違うのか。この土台が整理できれば、「自分の責任はここまで」という線が引け、漠然とした不安は「やるべきことの理解」へと変わります。

本記事では、開発実務の経験がない発注者の方に向けて、プロダクトマネジメントの基本から、POとPMの役割の違い、発注者がPOとして担う責任の全体像、そして1スプリント単位でどのように関与すればよいのかまでを、順を追って解説します。読み終えるころには「自分の役割はPOであり、何をつくるか・優先順位を決めることだ」と自己定義でき、週にどれくらいの時間を確保すればよいかの見通しも立つはずです。

なお、本記事は役割と責任の「全体像」を理解することに焦点を当てています。バックログの優先度の決め方やスプリントレビューでの具体的な振る舞いといった実務の手順は、関連する深掘り記事へのリンクで案内しますので、概念を理解したうえで段階的に学んでいけます。

Contents — 目次

プロダクトマネジメントとは？発注者が押さえるべき基本
PO・PMの役割の違い｜発注者はどれを担うのか
アジャイル開発でPO役を担う発注者の責任範囲（概観）
スプリントサイクルでのPO（発注者）の具体的な関与方法
まとめ｜発注者がPOとして自信を持って臨むために
画像指示

—Free Download / 資料ダウンロード

業務委託エンジニアのマネジメント実践ガイド

この資料でわかること

こんな方におすすめです

業務委託エンジニアのオンボーディングを効率化したい
正社員と業務委託が混在するチームのマネジメントを改善したい
業務委託エンジニアとの長期的な関係を構築したい

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

入力いただいたメールアドレスにPDFをお送りします。

プロダクトマネジメントとは？発注者が押さえるべき基本

プロダクトマネジメントという言葉を初めて意識したのは、おそらくアジャイル開発の文脈ではないでしょうか。まずはこの言葉が何を指すのかを、発注者の目線で整理していきます。

プロダクトマネジメントの定義｜価値を最大化し続ける活動

プロダクトマネジメントとは、ひとことで言えば「プロダクト（製品・サービス）の価値を最大化し続けるための活動」です。

ここでのポイントは「し続ける」という部分です。プロダクトは一度つくって終わりではありません。リリースした後も、利用者の反応を見ながら機能を改善し、市場の変化に合わせて方向性を調整していきます。「どんな機能を、どんな順番でつくれば、利用者や事業にとっていちばん価値が出るか」を考え、判断し続ける営みがプロダクトマネジメントです。

この活動の中心にいるのが、後ほど詳しく説明する「プロダクトオーナー」です。コードを書く役割ではなく、「何をつくるべきか」を決める役割だと考えると、開発実務の経験がない発注者の方でもイメージしやすいかもしれません。

プロダクトマネジメントとプロジェクトマネジメントの違い

プロダクトマネジメントと混同されやすいのが「プロジェクトマネジメント」です。名前は似ていますが、扱う対象も時間軸も異なります。

観点	プロダクトマネジメント	プロジェクトマネジメント
対象	プロダクト（製品・サービス）そのもの	期限のあるプロジェクト（特定の開発案件など）
時間軸	終わりがない（プロダクトが続く限り継続）	始まりと終わりがある（完了したら解散）
主な関心	何をつくれば価値が出るか	決めたものを期限・予算・品質の範囲で完成させられるか
代表的な役割	プロダクトオーナー（PO）	プロジェクトマネージャー（PM）

SCROLL→

たとえば「3カ月で新しい予約システムを開発する」という案件は、期限のあるプロジェクトです。これを期限内・予算内に完成させるのがプロジェクトマネジメントの領域になります。

一方、その予約システムをリリースした後も「次は決済機能を追加すべきか、それとも検索を改善すべきか」と考え続け、サービスの価値を高めていくのがプロダクトマネジメントです。発注者がアジャイル開発で求められるのは、多くの場合この「プロダクト側」の判断です。

アジャイル開発で発注者の関与が欠かせない理由

ウォーターフォール開発では、発注者は最初に要件定義書という「完成形の設計図」を渡し、あとは納品を待つのが基本でした。この進め方なら、発注者の継続的な関与は最小限で済みます。

ところがアジャイル開発は前提が違います。アジャイルは「最初にすべてを決めきるのは難しい」という考えに立ち、短い期間（スプリント）ごとに動くものをつくり、確認しながら方向を調整していきます。つまり「次に何をつくるか」「今できたものは期待どおりか」を、開発の途中で何度も判断する必要があるのです。

この「何をつくるか」「期待どおりか」を判断できるのは、ビジネスや利用者のことをいちばんよく理解している発注者をおいて他にいません。だからこそアジャイル開発では、発注者がプロダクトオーナーとして関与し続けることが構造的に求められます。丸投げが成立しないのは、誰かが手を抜いているからではなく、アジャイルという進め方そのものが発注者の判断を必要とするからなのです。

アジャイル開発の全体像や発注者としての契約・進め方をまだ押さえていない場合は、アジャイル開発とはもあわせてご覧ください。スクラムという代表的な進め方や役割分担についてはスクラム開発とはで整理しています。

PO・PMの役割の違い｜発注者はどれを担うのか

「自分はPOなのか、それともPMなのか」——役割を表す略称が複数あると、自分の立ち位置が分からなくなります。ここでは混同しやすい役割を整理し、発注者が任されるのはどれなのかをはっきりさせます。

プロダクトオーナー（PO）の役割｜何をつくるかと優先順位の決定者

プロダクトオーナー（PO）は、「何をつくるか」と「どんな順番でつくるか（優先順位）」を決める責任者です。

開発チームには「やってほしいこと」のリスト（プロダクトバックログと呼ばれます）が積み上がっていきますが、限られた時間と予算ですべてを同時にはつくれません。そこで「今のスプリントではこれを優先しよう」と決めるのがPOの仕事です。この優先順位の判断こそが、プロダクトの価値を左右します。

POは発注側、つまりビジネスを理解している側に立つ役割です。コードを書いたり技術的な実装方法を決めたりするわけではありません。「利用者や事業にとって何がいちばん価値があるか」を判断する——それがPOの中心的な役割です。

プロジェクトマネージャー（PM）との違い｜管理する対象が違う

プロジェクトマネージャー（PM）は、決まったものを「期限・予算・品質」の範囲で完成させるために、進捗やリスクを管理する役割です。

POとPMの違いは「管理する対象」にあります。POは「何をつくるか（What）」を決め、PMは「決まったものをどう完成させるか（How・進行管理）」を担います。料理にたとえるなら、POが「今日はどんな料理を出すかを決める人」、PMが「決まった料理を時間内に予算内で仕上げる段取りを管理する人」というイメージです。

外部ベンダーへの発注では、PMはベンダー側が担当することが一般的です。発注者がPM業務まで抱える必要はありません。ここを切り分けて理解しておくと、「自分は進捗管理まで全部やらないといけないのか」という過剰な負担感を手放せます。

スクラムにPMがいない理由とスクラムマスター・開発チームとの分担

アジャイル開発の代表的な進め方である「スクラム」の解説を読むと、PMという役割が出てこないことに気づくかもしれません。これは、従来PMが担っていた仕事が複数の役割に分散されているためです。

スクラムでは主に次の3つの役割で進めます。

プロダクトオーナー（PO）: 何をつくるか・優先順位を決める
スクラムマスター: チームがスムーズに進められるよう支援し、障害を取り除く
開発チーム（開発者）: 実際にものをつくる

従来のPMが担っていた「進捗管理」や「課題解決の段取り」は、スクラムマスターと開発チームが分担して担います。発注者はこのうちPOを担うのが基本であり、スクラムマスターや開発の実務はベンダー側に委ねられるケースがほとんどです。

発注者が任されるのは「PO（または代理PO）」

ここまでを整理すると、発注者が任される役割はほぼPO（プロダクトオーナー）に絞られます。下の表で、自分がどの立場かを確認してください。

役割	主な担当	発注者が担うか
プロダクトオーナー（PO）	何をつくるか・優先順位の決定	◎ 発注者が担うのが基本
プロジェクトマネージャー（PM）	期限・予算・品質の進行管理	△ 多くはベンダー側
スクラムマスター	チーム支援・障害の除去	× ベンダー側が担当
開発チーム	設計・実装	× ベンダー側が担当

SCROLL→

なお、発注者が忙しくて細かな判断をすべて担えない場合に、ベンダー側の担当者が発注者の意向を汲んで一部の判断を代行する「代理プロダクトオーナー（プロキシPO）」を立てることもあります。ただしその場合でも、最終的に「何をつくるか」を決める責任は発注者であるPOにあります。

つまり、あなたの役割は「PO＝何をつくるか・優先順位を決めること」だと自己定義してかまいません。進捗管理や実装はあなたの責任範囲ではない、と線を引けることが、まずは大きな一歩です。

アジャイル開発でPO役を担う発注者の責任範囲（概観）

「POだと分かったけれど、結局どこまでが自分の責任なの？」という不安に答えるため、ここではPOが担う責任を4つのカテゴリに整理して全体像を示します。責任は無限に広がっているわけではなく、この4領域に収まると理解してください。

POが担う責任の4カテゴリ

発注者がPOとして担う責任は、大きく次の4つに分けられます。

プロダクトのゴール・ビジョン設定 このプロダクトで何を実現したいのか、誰のどんな課題を解決するのかという「目指す方向」を示す責任です。ここが定まっていないと、開発チームは何を優先すべきか判断できません。発注者がいちばんよく知っているビジネスの目的を、チームに共有する役割だと考えてください。
プロダクトバックログの優先順位付け 「やってほしいこと」のリストに優先順位をつける責任です。限られたスプリントの中で、どれから手をつければ価値が早く出るかを判断します。アジャイル開発で発注者がもっとも頻繁に行う判断がこれにあたります。
受け入れ基準の明確化 「この機能はどういう状態になっていれば完成と認めるか」を事前に示す責任です。基準が曖昧なまま開発を進めると、できあがったものが期待とずれてしまいます。「何をもってOKとするか」を言葉にしておくことが、手戻りを防ぎます。
ステークホルダー（社内）調整 社内の関係部署や上長など、プロダクトに関わる人たちの意見をまとめ、プロダクトの方向性として一本化する責任です。社内で意見が割れたまま開発チームに別々の要望が届くと、現場は混乱します。社内の調整役を担うのも、ビジネス側にいる発注者だからこそできる役割です。

これら4つが「自分の責任領域」であり、逆に言えばこの4領域の外（実装の方法や進捗管理の段取りなど）は、あなたが直接抱える必要はありません。責任の輪郭が見えると、プレッシャーはずいぶん軽くなるはずです。

発注者がPO実務を深掘りするための参考記事

ここまでで「自分の責任は4領域だ」という全体像はつかめたと思います。一方で、「では優先順位は具体的にどう決めればいいのか」「自分で決めることと、ベンダーに委ねることの線引きはどこか」といった実務の進め方は、また別の知識が必要です。

これらの実務、つまりバックログの運用や優先度の決め方、「決めること/委ねること」の線引き、そして「形だけのPO」にならないための工夫については、バックログとはで詳しく解説しています。本記事で役割の全体像をつかんだら、次はこの記事で実務の手順に進むと、概念から実践へとスムーズに学習を進められます。

スプリントサイクルでのPO（発注者）の具体的な関与方法

最後の不安は「いつ・どれくらい関与すればいいのか」という時間の見通しでしょう。アジャイル開発は短い期間（スプリント）を繰り返して進むため、発注者の関与にも一定のリズムがあります。ここでは1スプリントの流れに沿って、発注者がどこで・どれくらい関わるかを具体的に見ていきます。

1スプリントの流れと発注者が関わるポイント

スプリントは2週間で区切るケースが一般的です。その2週間の中で発注者（PO）が関わる主なイベントは次のとおりです。

イベント	発注者がすること	関与の度合い
バックログリファインメント	やることリストの内容を整理し、優先順位や受け入れ基準をすり合わせる	中（事前準備として重要）
スプリントプランニング	今回のスプリントで何をつくるかを開発チームと合意する	高
デイリースクラム（朝会）	チームの進捗確認。発注者は基本的に参加任意	低（参加は任意）
スプリントレビュー	できあがったものを確認し、フィードバックする	最高（最重要）
レトロスペクティブ（振り返り）	進め方の改善を話し合う。発注者の参加は任意	低（参加は任意）

SCROLL→

ここで安心してほしいのは、発注者がすべてのイベントにフルで参加する必要はないという点です。デイリースクラムや振り返りは、基本的に開発チーム側で回るものです。発注者が確実に関わるべきなのは、プランニングとレビュー、そして事前のリファインメントだと押さえておけば十分です。

スプリントレビューが発注者の最重要イベントである理由

数あるイベントの中でも、発注者にとって最重要なのがスプリントレビューです。

スプリントレビューは、そのスプリントでできあがった「動くもの」を実際に確認する場です。ここで発注者は「これは期待どおりか」「次はどう改善してほしいか」をフィードバックします。このフィードバックが次のスプリントの優先順位に反映され、プロダクトの方向が少しずつ正しく調整されていきます。

逆にここで発注者が確認を怠ると、ずれたまま開発が積み上がり、後から大きな手戻りになりかねません。「自分が原因で開発が止まる」ことを恐れるなら、止めないためにこそ、このレビューにしっかり時間を確保することが効果的です。レビューは負担ではなく、軌道修正の安全装置だと考えてください。

スプリントレビューでの具体的な確認の仕方や、費用に見合った成果が出ているかの評価方法については、スプリントとはで詳しく解説しています。

発注者がPOとして確保すべき関与工数の目安

「結局、週にどれくらい時間を取られるのか」が気になるところでしょう。あくまで目安ですが、2週間スプリントの場合、発注者の関与時間はおおよそ次のように見積もれます。

スプリントプランニング: 1〜2時間（スプリント開始時）
バックログリファインメント: 1〜2時間（スプリント中盤など）
スプリントレビュー: 1時間前後（スプリント終了時）
日々のバックログ整理・問い合わせ対応: 週あたり1〜2時間程度

これらを合計すると、2週間スプリントで5〜8時間ほど、つまり週あたり3〜4時間前後が一つの目安になります。本業と兼務する発注者にとって現実的な範囲に収まることが多いはずです。

大切なのは、これらの関与があらかじめ予定できるルーティンだという点です。「いつ呼ばれるか分からない」状態ではなく、「プランニングとレビューはこの曜日のこの時間」とカレンダーに固定してしまえば、「自分が原因で止まる」という漠然とした恐怖は、予定管理の問題に置き換わります。関与のリズムをつかむことが、PO役を無理なく続ける鍵になります。

まとめ｜発注者がPOとして自信を持って臨むために

最後に、本記事の要点を振り返ります。

プロダクトマネジメントとは、プロダクトの価値を最大化し続ける活動であり、終わりのある「プロジェクトマネジメント」とは対象も時間軸も異なります。
アジャイル開発では「何をつくるか」を途中で何度も判断する必要があるため、ビジネスを理解している発注者の継続的な関与が構造的に欠かせません。
発注者が任されるのは基本的にPO（プロダクトオーナー）であり、その役割は「何をつくるか・優先順位を決めること」です。進捗管理（PM）や実装はベンダー側に委ねられます。
POが担う責任は、ゴール設定・優先順位付け・受け入れ基準の明確化・社内のステークホルダー調整という4カテゴリに収まります。責任は無限ではありません。
関与にはスプリント単位のリズムがあり、目安は週あたり3〜4時間前後。プランニングとレビューを軸に予定化すれば、無理なく続けられます。

ここまで読んで、「自分の役割はPOであり、何をつくるか・優先順位を決めること」と自己定義できたなら、最初の不安はかなり整理できたはずです。

次の一歩は、役割の理解から実務の手順へ進むことです。優先順位の具体的な決め方や「決めること/委ねること」の線引きはバックログとはで、スプリントレビューでの関わり方はスプリントとはで詳しく学べます。全体像をつかんだうえでこれらの実務記事に進めば、発注者としてのPO役に自信を持って臨めるようになります。