システム開発基礎開発プロセス・進め方公開日2026.10.16

プロダクトオーナーとは？発注側が担う5つの仕事とPMとの違い

「開発会社から『プロダクトオーナーを決めてください』と言われた」
「アジャイルで進めるらしいが、自社が何をすればいいのか分からない」
受託開発を初めて発注する会社から、こうした相談をよくいただきます。

プロダクトオーナー（PO）は、開発チームが「何を、どの順番で作るか」を決める責任者です。
もとはスクラムという開発手法の役割ですが、受託開発では発注する会社側の担当者が務める場面が増えています。
本記事では、POの定義とPMとの違いを押さえたうえで、発注側がPOを担うときの仕事・向いている人・外部に任せられる範囲・失敗パターンまでを解説します。

発注側全体の関わり方はシステム開発の丸投げが失敗する理由｜発注側が管理すべき6項目で整理しています。
本記事は、その中でも「意思決定の担い手」であるPOに絞った内容です。

プロダクトオーナーとは？スクラムでの定義

プロダクトオーナーとは、プロダクトの価値を最大化することに責任を持つ人です。
スクラムの公式ガイド「スクラムガイド」では、スクラムチームを構成する3つの責任の1つとして定義されています。

役割	主な責任
プロダクトオーナー	プロダクトの価値を最大化する。プロダクトバックログを管理する
スクラムマスター	チームがスクラムを正しく実践できるよう支援する
開発者	スプリントごとに、動く成果物（インクリメント）を作る

スクラムガイドでは、POの仕事の中心を「プロダクトバックログの管理」としています。
プロダクトバックログとは、作りたい機能や改善を優先順に並べたリストです。
具体的には、次の4つがPOの責任とされています。

プロダクトゴール（目指す姿）を決め、チームに明確に伝える
プロダクトバックログの項目を作り、内容を分かりやすく伝える
プロダクトバックログの項目に優先順位をつけて並べる
プロダクトバックログを誰でも見られる状態にし、理解されるようにする

項目を書く作業そのものは、開発者に手伝ってもらっても構いません。
ただし最終的な責任はPOが持ちます。
スクラムガイドでは、POは「委員会ではなく1人の人間」とも書かれています。
複数人の合議で決めると判断が遅れるため、決める人を1人に絞るという考え方です。

プロダクトオーナーとPM（プロジェクトマネージャー）の違い

POは「何を作るか」に、PMは「どう計画どおりに進めるか」に責任を持ちます。
混同されやすい2つの役割を、表で比べます。

観点	プロダクトオーナー（PO）	プロジェクトマネージャー（PM）
責任の対象	プロダクトの価値	プロジェクトの進行（QCD）
主な問い	何を作れば成果が出るか	予定どおりの品質・費用・納期で終わるか
主な道具	プロダクトバックログ、プロダクトゴール	WBS、進捗表、課題管理表
決めること	機能の優先順位、作る・作らないの判断	体制、スケジュール、リスク対応
受託開発での担い手	発注側の担当者が多い	開発会社側が多い

QCDとは、品質（Quality）・費用（Cost）・納期（Delivery）の頭文字です。
受託開発では、開発会社のPMが進行を管理し、発注側のPOが中身を決める分担がよく見られます。
中小企業では、社長や事業責任者が1人でPOとPMの両方を兼ねることもあります。

開発手法そのものの違いは、旧ブログのアジャイル開発とウォーターフォール開発の違いで解説しています。

受託開発で、発注側がプロダクトオーナーを担う理由

受託開発では、POを発注する会社側に置くのが基本です。
「その機能が事業にとって必要か」を判断できるのは、発注側だけだからです。

開発会社は、技術的にできるかどうかや、作るのにかかる工数は答えられます。
一方で、次のような判断は発注側の事業の事情で決まります。

今月のリリースに、AとBのどちらの機能を入れるか
現場から出た要望を、今回の開発に含めるか見送るか
予算が足りないとき、どの機能を削るか
でき上がった画面が、業務で使えるかどうか

これらを開発会社に任せると、技術的に作りやすい順で進んでしまいます。
でき上がった後に「現場で一番困っていた機能が後回しになっていた」と気づくケースは珍しくありません。

なお、アジャイルで進める受託開発は準委任契約で結ぶことが多くなります。
契約の違いは準委任契約と請負契約の違いにまとめています。

発注側プロダクトオーナーの5つの仕事

発注側POの仕事は、決めること・伝えること・確かめることの3種類に集約されます。
受託開発の現場に合わせて、5つに分けて説明します。

1. プロダクトゴールを決めて共有する

最初に「このシステムで何を実現したいか」を一言で決めます。
たとえば「電話とFAXの受注入力をなくし、1日2時間の転記作業をゼロにする」のような形です。
ゴールが決まっていれば、迷ったときに優先順位をつける基準になります。

ゴールの元になる経営・業務の要求の整理は、要件定義は3層で考えるが参考になります。

2. プロダクトバックログに優先順位をつける

要望を一覧にし、上から順に並べるのがPOの中心の仕事です。
並べ方の目安は「事業への効果が大きく、作る手間が小さいもの」から先に置くことです。
全部を「優先度：高」にすると、並べていないのと同じになります。

迷ったときは、要望を次の4つに振り分ける「MoSCoW（モスコウ）法」が使えます。

Must：ないと業務が回らない。最初のリリースに必ず入れる
Should：あると効果が大きい。Mustの次に入れる
Could：あれば便利。予算や期間に余裕があれば入れる
Won’t：今回は作らない。次の改修で検討する

「Won’t」を決めるのが、POの仕事で最も難しく、最も大切な部分です。
作らないものを決めない限り、予算と期間は守れません。

3. 開発チームの質問にすばやく答える

開発が進むと「この場合はどう動けばいいか」という質問が毎日のように出ます。
POの回答が1週間遅れると、その分だけ開発が止まるか、推測で作られます。
質問の窓口をPOに一本化し、回答の期限を決めておくと進行が安定します。

4. でき上がった成果物を確かめて判断する

スクラムでは、1〜4週間ほどの区切り（スプリント）ごとに動く成果物を確認します。
発注側POは、その場で実際に画面を触り、業務で使えるかを判断します。
「次のスプリントで直す」「このままリリースする」を決めるのもPOの役目です。

確認の進め方をテストの観点から詳しく知りたい場合は、テスト代行サイトのシステム開発で受入基準を設定する方法も参考になります。

5. 社内の関係者の意見をまとめる

経営者・現場・情報システム担当など、社内には立場の違う関係者がいます。
それぞれの要望を聞き、1つの優先順位にまとめてから開発会社に伝えるのがPOです。
社内の意見が割れたまま開発会社に伝えると、手戻りの原因になります。

合意形成の進め方は経営者・現場・システム会社の認識がズレる理由で詳しく解説しています。

仕事	主なタイミング	やらないと起きること
ゴールの決定と共有	開発開始前	優先順位の基準がなく、議論がまとまらない
バックログの優先順位付け	スプリントごと	作りやすい順で進み、重要な機能が後回しになる
質問への回答	毎日〜毎週	開発が止まる、または推測で作られる
成果物の確認と判断	スプリントの終わり	完成間際に「使えない」と分かる
社内の意見の取りまとめ	随時	要望が途中で変わり、手戻りが増える

スプリントの流れと、プロダクトオーナーの関わり方

スクラムでは、1ヶ月以内の決まった期間（スプリント）を繰り返して開発を進めます。
POが必ず関わるのは、スプリントの「始まり」と「終わり」です。
スプリントの中で行うイベントと、発注側POの関わり方は次のとおりです。

スプリントプランニング（始まり）
このスプリントで何を目指し、どの項目に取り組むかを決める。
POは優先順位の高い項目と、その理由を説明する。
デイリースクラム（毎日）
開発者が15分で進み具合を確かめる場。
POの参加は必須ではないが、出た質問には当日中に答える。
スプリントレビュー（終わり）
でき上がった成果物を関係者と確認し、次に何をするかを話し合う。
POは画面を触って判断し、バックログの順番を見直す。
スプリントレトロスペクティブ（終わり）
チームの進め方を振り返り、改善点を決める。
受託開発では、発注側と開発会社のやりとりの改善も話題にする。

このほか、次のスプリントに向けてバックログの項目を詳しくする「リファインメント」という作業があります。
項目の中身を開発会社と一緒に確認し、見積もれる粒度まで分けておく作業です。
POが事前に準備しておくほど、スプリントプランニングが短く済みます。

ウォーターフォール型の開発でも、月1回の定例で成果を確かめるなど、考え方は応用できます。
大切なのは「作り終わってから初めて見る」状態を避けることです。

プロダクトオーナーに向いている人・必要な時間

POに必要なのは、ITの知識よりも「業務を知っていて、決められる立場にあること」です。
システムの専門用語は、開発会社が説明すれば足ります。

条件	理由
対象の業務をよく知っている	機能が現場で使えるかを判断できる
予算や範囲を決める権限がある	その場で判断でき、持ち帰りが減る
社内の関係者と話せる立場にある	意見を集め、1つの優先順位にまとめられる
継続して時間を確保できる	質問への回答や確認が止まらない

中小企業では、社長や部門長が務めるケースが多く見られます。
注意したいのは、時間の確保です。
スプリントの確認会や定例に毎回出られる人でないと、POの役割は果たせません。

多忙な社長がPOになる場合は、日々の質問への回答を担う補佐役を置く方法があります。
その場合も、最終的に決める人は1人に決めておきます。

プロダクトオーナーの仕事で、外部に任せられる範囲

POの作業は手伝ってもらえますが、決める責任は外に出せません。
社内に経験者がいない場合、開発会社やコンサルタントに支援を頼むことはできます。

作業	外部に任せられるか	補足
要望のヒアリングと整理	任せられる	開発会社が現場に聞き取りをして一覧にする
バックログ項目の文章化	任せられる	POが内容を確認して承認する
優先順位の案づくり	案までは任せられる	最終的な順番はPOが決める
成果物の確認作業	一部任せられる	テストは外部、業務で使えるかの判断はPO
作る・作らないの最終判断	任せられない	事業の責任と結びつくため

「PO代行」のようなサービスもありますが、判断まで委ねると丸投げと同じ状態になります。
支援を頼む場合も、決める場面には発注側のPOが必ず出席するようにします。

発注側プロダクトオーナーの事例：決め方で結果が変わった3つの場面

当社が受託した開発でも、発注側の判断がプロダクトの形を大きく左右しました。
公開している業務実績から、3つの場面を紹介します。

イメージ資料から始め、約3ヶ月でリリースした災害情報サービス

IoTカメラと天気・地震・雷の外部APIを組み合わせた災害情報サービスでは、スタート時点に詳細な仕様書はありませんでした。
いただいたのは、おおまかなイメージ資料だけです。
開発会社側が実現方法の仮説を立て、短い区切りで検証と実装を繰り返して約3ヶ月でリリースしました。

仕様書がなくても進められたのは、ゴールとなるイメージが発注側からはっきり示されていたからです。
POの仕事は、細かい仕様を書くことより「何を実現したいか」を示すことだと分かる例です。

取引の安全性をどこまで作るかを決めたマッチングサービス

スキルを売買するマッチングプラットフォームの開発では、本人確認・評価・秘密保持契約（NDA）をどこまで用意するかが大きな論点になりました。
安全対策は増やすほど費用と期間が伸びます。
こうした「どこまで作るか」の線引きは、事業のリスクをどこまで取るかという発注側の判断です。

シナリオを現場が組み替えられる形にした商談システム

動画と設問で初回商談を自動化するシステムでは、商談シナリオを営業の現場が自分で組み替えられる編集画面を用意しました。
開発会社に頼まないとシナリオを直せない形にすると、使われなくなるためです。
「誰が日々使い、誰が直すのか」まで含めてプロダクトを定義するのも、POの視点です。

イメージ資料から始めた開発の詳細は、以下のページでご覧いただけます。

プロダクトオーナーがうまく機能しない4つの失敗パターン

失敗の多くは、POの「時間」と「権限」が足りないことから起きます。
よくある4つのパターンと対策をまとめます。

名前だけのPO
役職で選ばれたが、定例に出られず質問への回答が滞る。
対策：毎週の確認会に出られる人を選ぶ。
決められないPO
判断のたびに上長の承認が必要で、1件の回答に数日かかる。
対策：予算と範囲の判断権限を、事前にPOへ渡しておく。
全部「高」のPO
どの要望も優先度が高く、並び順がつかない。
対策：プロダクトゴールに照らして、上から1列に並べる。
複数人のPO
部署ごとに担当がいて、開発会社への指示が食い違う。
対策：窓口と最終判断者を1人にする。

打ち合わせ自体がかみ合わないと感じる場合は、なぜシステム会社との打ち合わせがうまくいかないのか？もあわせてご覧ください。

プロダクトオーナーを決める前の準備チェックリスト

開発会社に相談する前に、社内で次の6点を確かめておくと立ち上がりが早くなります。
特に「誰が最終判断をするか」は、契約前に決めておくことをおすすめします。

POを務める人を1人決め、社内に周知したか
POに予算と範囲を判断する権限を渡したか
毎週の確認会や定例に出られる時間を確保したか
プロダクトゴールを一言で言える状態か
社内の関係者（経営・現場・情報システム）から要望を集めたか
要望をMust・Should・Could・Won’tに仮で分けたか

すべてがそろっていなくても、相談は始められます。
足りない部分は、開発会社と話しながら埋めていけば問題ありません。

プロダクトオーナーに関するよくある質問

Q. ウォーターフォール型の開発でも、プロダクトオーナーは必要ですか？

POはスクラムの役割名なので、ウォーターフォール型では使わないこともあります。
ただし「何を作るかを決める発注側の責任者」は、どの手法でも必要です。
名前は「発注側の責任者」「プロジェクトオーナー」などでも構いません。

Q. プロダクトオーナーにITの知識は必要ですか？

専門的な知識は必須ではありません。
業務を知っていて、優先順位を決められることのほうが大切です。
技術的な選択肢は開発会社に説明を求め、その中から事業に合うものを選べば十分です。

Q. プロダクトオーナーを2人にしてもいいですか？

スクラムガイドでは、POは1人と定められています。
相談相手や補佐役を置くのは問題ありませんが、最終判断者は1人に絞ってください。

Q. プロダクトオーナーの仕事には、どれくらいの時間がかかりますか？

開発の規模や進め方によって変わるため、一律の時間は決められません。
最低限、スプリントプランニングとスプリントレビューには毎回出席する必要があります。
それに加えて、開発チームからの質問に答える時間を毎日少しずつ確保してください。
開発の初期は要望の整理で負担が大きく、後半は確認と判断が中心になります。

Q. 開発の途中でプロダクトオーナーが交代しても大丈夫ですか？

交代は可能ですが、判断の基準が変わると手戻りが起きやすくなります。
交代する場合は、プロダクトゴールとバックログの並び順、これまでに「作らない」と決めた項目とその理由を引き継いでください。
決めた理由が残っていないと、後任が同じ議論を最初からやり直すことになります。

Q. 要件が固まっていなくても、開発会社に相談できますか？

相談できます。
ゴールのイメージがあれば、要件の整理から一緒に進められます。
準備しておくとよいことはシステム開発の要件定義、発注側は何を準備すればいい？にまとめています。

まとめ：プロダクトオーナーは「決める人」を1人に絞ることから

プロダクトオーナーとは、プロダクトの価値を最大化するために「何を、どの順番で作るか」を決める責任者です。
受託開発では、事業の事情を知る発注側が担うのが基本です。

POの中心の仕事は、プロダクトバックログの優先順位付け
PMは進行、POは中身に責任を持つ
必要なのはITの知識より、業務の理解と決める権限
作業は外部に任せられるが、最終判断は任せられない
決める人は1人に絞り、毎週の確認に出られる時間を確保する

株式会社みんなシステムズでは、要件が固まる前の段階から、発注側のPOと一緒にプロダクトを形にしています。
「POを誰にすればいいか分からない」「社内で決めきれない」といった段階でも構いません。
まずはお問い合わせフォームからお気軽にご相談ください。