発注側のプロダクトオーナーとは｜役割と判断のしかた
システム開発を外注すると、「作るのは開発会社だから、発注側は待っていればよい」と考えてしまいがちです。しかし実際には、発注側にも担う役割があります。この記事では、発注側の担当者が果たすプロダクトオーナーの役割と、判断に迷ったときの考え方を整理します。
新規事業の開発を想定し、何を決め、何を開発会社に任せ、どこで確認するのかを順に説明します。
プロダクトオーナーとは何か、発注側では誰を指すのか
プロダクトオーナーは、アジャイル開発の枠組みであるスクラムで使われる言葉です。スクラムガイドでは、プロダクトの価値を最大にすることに責任を持つ人として位置づけられています。作るものの優先順位を決め、開発チームに「何を作るか」を伝える立場です。
外注の場面に置き換えると、発注側のプロダクトオーナーは次のような人です。
- 開発するシステムの目的と、事業としての狙いを理解している
- 機能の優先順位について、発注側の意思として判断できる
- 開発会社からの質問に、社内の意見をまとめて答えられる
- 出来上がったものを見て、「これでよい」「ここは直す」と言える
肩書きは問いません。新規事業の立案者でも、事業部の責任者でも構いません。大切なのは、この人の判断が発注側の判断として扱われることです。
開発会社は、技術や進め方の面から提案できます。ただし、事業として何を優先するかは、事業を背負う発注側にしか決められません。ここが、プロダクトオーナーという役割が必要になる理由です。
なお、要件定義の考え方は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で、外注全体の流れはシステム開発の外注ガイド｜依頼の流れと失敗の防ぎ方で詳しく扱っています。
発注側の担当者が担う5つの役割
プロダクトオーナーの仕事は多岐にわたるように見えますが、整理すると5つに分けられます。
1. 目的と「うまくいった状態」を言葉にする
最初の仕事は、そのシステムで何を実現したいのかを言葉にすることです。「予約を取れるサイトを作りたい」は、機能の話です。目的は、たとえば「これまで電話でしか受けられなかった相談を、夜間にも受けられるようにして、新しい客層に届くかを確かめる」といったものです。
あわせて、「うまくいった状態」も決めておきます。数字で決められる場合は、それを置きます。決められない段階であれば、「利用者がこの操作を最後まで終えられる」のような観察可能な状態でも構いません。この基準があると、後の判断が楽になります。
2. 優先順位を決める
要望は、出し始めると増えていきます。すべてを最初から入れようとすると、開発は長引き、事業として何を確かめたいのかも見えなくなります。
そこでプロダクトオーナーは、「最初に必要なもの」「後でよいもの」「やらないもの」に分けます。分け方の基準はMVP開発の機能の絞り方｜最初に作るものと後回しの基準で整理しています。
優先順位を決めるのは、開発会社ではありません。開発会社が「これは後回しでも成り立ちます」と助言することはできますが、最終的に選ぶのは発注側です。
3. 社内の意見をまとめる
新規事業には、経営陣、現場、営業、法務など、多くの人が関わります。それぞれが違う期待を持っていることも珍しくありません。意見が個別に開発会社へ届くと、仕様がぶれて、作り直しにつながります。
プロダクトオーナーは、社内の窓口として意見を集め、整理した上で開発側に伝えます。すべての意見を採用するわけではありません。採用しない場合は、その理由を社内にも説明できるようにしておきます。
経営陣と現場で見ている目的は同じでも、判断の材料や速さが違うことがあります。この点は新規事業で経営陣と現場がすれ違う原因は進め方のズレで取り上げています。
4. 開発側からの質問に早く答える
開発が始まると、細かな質問が次々に出ます。「この項目は必須ですか」「この場合の画面遷移はどうしますか」といったものです。
この質問への返答が遅れると、開発はそこで止まります。あるいは、開発側が推測で進めることになり、後で「思っていたものと違う」となりかねません。プロダクトオーナーには、すぐに答えられる時間と権限が必要です。すぐに決められない場合も、「いつまでに誰が決めるか」を返すだけで、進行は止まりにくくなります。
5. 出来上がったものを確認し、受け入れを判断する
最後の役割は、出来上がったものを実際に触って確認し、受け入れるかを判断することです。仕様書と照らし合わせるだけでなく、実際に使う場面を想像しながら操作します。
文章で決めた仕様は、実物を見ると「思っていたものと違う」と感じることがよくあります。これは誰かの落ち度というより、言葉だけで合意した場合に起きやすいずれです。実物を見ながら確認を重ねる進め方は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで説明しています。
判断のしかた：迷ったときに使える4つの基準
プロダクトオーナーの仕事の中心は判断です。ただ、新規事業では正解が分からない状態で決めることになります。そこで、迷ったときに立ち返る基準を持っておくと、判断がぶれにくくなります。
目的に近づくかどうか
要望や機能案が出たら、「最初に書いた目的に近づくか」を確認します。便利そうに見えても、目的と関係が薄ければ後回しにします。「あれば嬉しい」と「なければ目的を確かめられない」は、分けて考えます。
後から変えやすいかどうか
判断のなかには、後で簡単に変えられるものと、変えにくいものがあります。画面の文言や配置、ボタンの位置は直しやすい部類です。データの持ち方や、他の仕組みとの連携方法は、後から変えると影響が大きくなります。
変えにくいものは、時間をかけて慎重に決めます。変えやすいものは、まず決めて動かし、実物を見て直します。この使い分けだけでも、会議の時間はかなり減らせます。
小さく試して確かめられるかどうか
「利用者はこの機能を使うだろうか」と議論を続けても、結論は出にくいものです。そうした場合は、小さく作って確かめるほうが早く済みます。考え方は新規事業の開発は小さく作って確かめる投資判断の進め方にまとめています。
判断できないことを、無理に議論で決めようとしない。確かめる方法に変える。これは、プロダクトオーナーが覚えておきたい姿勢です。
決めた理由を残せるかどうか
判断には、理由を添えて記録しておきます。「なぜこの機能を後回しにしたのか」を残しておけば、後から事情を知らない人が見ても納得できますし、状況が変わったときに見直すきっかけにもなります。
長い文書にする必要はありません。「判断した日・内容・理由」を短く書き残すだけでも十分に役立ちます。
プロダクトオーナーが不在・兼務のときに起きやすいこと
役割が曖昧なまま外注に入ると、次のような問題が起きやすくなります。
- 決める人がいない。 質問が社内で止まり、開発が進まない
- 決める人が複数いる。 人によって言うことが変わり、仕様が揺れる
- 決める人が忙しすぎる。 確認が後回しになり、完成間際に大きな修正が出る
- 決める人に権限がない。 判断が決裁者に差し戻され、そのたびに遅れる
兼務で担当すること自体は、珍しくありません。その場合は、どのくらいの時間を割けるのかを最初に確認しておきます。確認や返答にかけられる時間が少ないなら、判断の範囲を絞る、確認の頻度を決めておく、といった工夫が必要です。
ここで外注の失敗が起きやすいことは、システム開発の外注で失敗後のやり直し｜再依頼の見直し点でも触れています。
社内にエンジニアがいなくても務まるか
プロダクトオーナーに、プログラミングの知識は必須ではありません。必要なのは、事業と利用者を理解していることと、判断を引き受ける姿勢です。技術的な説明が分からないときは、遠慮なく質問して構いません。専門用語を平易に説明してくれるかどうかは、開発会社を選ぶときの確認点にもなります。
エンジニアがいない会社での進め方は、新規事業でエンジニアいない会社の進め方｜システム開発で詳しく扱っています。
決裁者・開発会社との関わり方
決裁者との関係
プロダクトオーナーは、決裁者とは別の役割です。決裁者が最終的な投資判断をする一方で、プロダクトオーナーは、その判断に必要な材料を集めて見せる役割を担います。
企画書だけでは、決裁者に「何ができるのか」が伝わりにくい場面があります。実際に動く画面を見せたり、利用者の反応を共有したりすれば、判断の材料が増えます。この点は新規事業の決裁を企画書だけで取るのが難しい理由で説明しています。
決裁者に「いつ、何を判断してもらうか」を先に決めておくと、プロダクトオーナーの判断が差し戻されることも減ります。
開発会社との関係
開発会社は、発注側の指示を受けて作るだけの相手ではありません。技術面や進め方について、提案をもらえるパートナーです。ただし、提案を採るかどうかの判断は発注側が担います。
開発会社を選ぶ際は、プロダクトオーナーとのやり取りがしやすいかどうかも確認します。質問への返答の速さ、説明の分かりやすさ、実物を見せながら進められるかは、日々の進行に直結します。選び方の視点はシステム開発会社の選び方｜新規事業で失敗しない7つの視点にまとめています。
AIを使った開発でも、決める役割は変わらない
近年は、AIを活用して開発を進める会社も増えています。AIが設計や実装の多くを担う場合でも、「何を作るかを決める」ことと「品質の最終判断」は人の役割として残ります。つまり、プロダクトオーナーの役割は、AI時代にも重要さを保ちます。むしろ、開発が速くなるほど、何を作るかを決める判断の質が結果を左右します。
AI駆動開発での役割分担はAI駆動開発とは｜AIと人の役割分担と発注側の要点で、確認の必要性はAI開発でも品質には人の確認が必要な理由で扱っています。
内製か外注か迷うときの視点
プロダクトオーナーを社内に置けるかどうかは、内製と外注の判断にも関わります。外注するにしても、事業の判断は社内に残るからです。開発そのものは外に任せられても、「何を作るか」を決める役割は外に出せません。
社内に判断できる人を置けるかを、外注先を探す前に確認しておくと、後の進行が安定します。内製と外注の比較は内製と外注どちらがいい？新規事業システムの判断軸で整理しています。依頼前の準備はシステム開発を依頼する前の準備と流れ｜新規事業編が参考になります。
まとめ
発注側のプロダクトオーナーは、開発を代わりに進める人ではなく、事業の意思を伝えて判断する人です。主な役割は次の5つでした。
- 目的と「うまくいった状態」を言葉にする
- 優先順位を決める
- 社内の意見をまとめる
- 開発側からの質問に早く答える
- 出来上がったものを確認し、受け入れを判断する
判断に迷ったときは、目的に近づくか、後から変えやすいか、小さく試せるか、理由を残せるか、の4点に立ち返ると整理しやすくなります。技術の知識よりも、事業と利用者への理解、そして判断を引き受ける時間と権限が大切です。
私たちJustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただける受託開発サービスです。プロダクトオーナーの方が言葉だけでなく実物で判断できるように進めており、JustFitのサービス紹介でその考え方をご覧いただけます。