「優先度はPO（プロダクトオーナー）が決めるので」——アジャイル開発を外部のベンダーに委託していると、スプリントレビューでこう説明される場面が少なくありません。自社の要望を出したはずなのに、いつ実装されるのか見えず、気づけば「ご要望の機能は次々回以降です」と後ろ倒しになっている。そんな経験はないでしょうか。
かといって、要望を強く言いすぎると「現場が混乱する」と渋い顔をされてしまう。優先度を決める立場ではないのに、自社の事業にとって重要な機能をどうにか前に進めたい。この「関与しすぎず、放置もせず」という塩梅の難しさは、プロダクトオーナーを開発ベンダー側や社内の別部署に任せている発注者の多くが抱える悩みです。
結論から言えば、優先順位の最終決定はPOの責任ですが、その判断材料を提供する役割は発注者にあります。つまり発注者は「決める人」ではなく「価値を伝える人」として、正しい場で・正しい伝え方で関与することで、自社の優先要望をバックログに反映させられます。逆に、関与の場と伝え方を知らないまま要望を投げると、後回しにされるか、割り込みとして煙たがられるかのどちらかになりがちです。
本記事では、プロダクトオーナーを自ら担わない発注者（ステークホルダー）の立場に絞り、バックログの優先順位づけに「どこで・どこまで・どう関与すればよいか」を解説します。関与すべき3つの会議の場、優先要望を通すための「価値の根拠」の伝え方、そして過干渉でも放置でもない関与の境界線まで、明日の打ち合わせから使える形で整理します。
なお、発注者自身がプロダクトオーナーを務め、自分で優先度を決める手順（MoSCoW・WSJF などのフレームワーク運用）を知りたい場合は、バックログとは｜スクラム発注者が押さえる優先度の決め方ガイドで詳しく解説しています。本記事は「決め方」ではなく「関与の仕方」に集中します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
バックログの優先順位は誰が決めるのか｜発注者の立場を整理する
関与の仕方を考える前に、まず確認しておきたいことがあります。それは「自分は優先度を決める立場なのか、それとも影響を与える立場なのか」という点です。ここが曖昧なまま要望を出すと、決められないことに口を出して混乱を招いたり、逆に伝えるべきことを伝えずに放置したりしてしまいます。
「バックログ」とは、開発するべき機能や改善項目を、価値の高い順に並べた一覧のことです。スクラムでは、このバックログをどの順番で開発するかを管理する責任は、プロダクトオーナー（PO）にあります。バックログ自体の詳しい定義やプロダクトバックログ・スプリントバックログの違いについては、本記事では立場の整理に必要な範囲にとどめ、詳細は前述の決め方ガイドに譲ります。
優先順位の決定責任はプロダクトオーナーにある
スクラムの公式ルールであるスクラムガイド2020では、プロダクトバックログの並び順（順序）を決める責任はプロダクトオーナーにあると明確に定められています。POはプロダクトの価値を最大化する責任を持ち、その手段としてバックログの並べ替えを行います。
ここで大切なのは、「優先順位を決めるのはPOである」という原則が、関与をあきらめる理由にはならないという点です。POが価値を最大化する判断をするためには、その判断材料となる「事業上の価値」が必要です。そして、その価値を最もよく知っているのは、開発を発注した事業側、つまりあなたです。POが優先度を決める主体であることと、発注者が価値を伝える役割を持つことは、両立します。
発注者がPOを担うケースと担わないケースの違い
発注者とアジャイル開発の関わり方には、大きく2つのパターンがあります。
1つ目は、発注者自身がプロダクトオーナーを務めるケースです。この場合、優先度の最終決定権はあなたにあり、MoSCoW や WSJF といったフレームワークを使って自分で並び順を決めていきます。決定者として振る舞うため、関与の悩みは「どう決めるか」になります。
2つ目は、プロダクトオーナーを開発ベンダー側や社内の別部署が担い、発注者は「要望を出すステークホルダー」の立場にとどまるケースです。この場合、最終決定権はPOにあり、あなたは決定権を持ちません。だからこそ「どこまで関与してよいのか」「自社の要望をどう反映させるのか」という、本記事のテーマである悩みが生まれます。
本記事が対象とするのは後者、つまり発注者がPOを担わないケースです。決定権がないことを前提に、それでも自社の優先要望を正しく反映させるための関与の仕方を、このあと具体的に見ていきます。
「優先度はPO任せ」でよいのか｜発注者が関与すべき理由
「決めるのはPOなのだから、こちらは任せておけばよい」——一見すると、これは役割分担として正しいように思えます。しかし、発注者が一切関与しないと、自社にとって不利益な事態が静かに進行することがあります。一方で、関与しすぎても別の問題が起きます。この章では、関与しない場合と関与しすぎる場合の両方のリスクを整理し、なぜ「適切な関与」が必要なのかを確認します。
関与しない場合に起きること
発注者が価値を伝えずにPO任せにすると、次のような事態が起こりやすくなります。
- 事業要望が後回しにされる: POは手元にある情報をもとに優先度を判断します。あなたが「この機能は四半期末のキャンペーンに間に合わせたい」という事業背景を伝えていなければ、POはその緊急性を知る由がありません。結果として、本来優先すべき機能が後ろのスプリントに回されてしまいます。
- 優先度の根拠がずれる: POが推測で優先度を決めると、技術的に作りやすいものや、声の大きい別のステークホルダーの要望が優先されることがあります。事業価値の物差しが共有されていないため、開発は進んでいるのに事業成果につながらない、という状態に陥りがちです。
- 「言った／言わない」のすれ違いが増える: 関与の場を持たないと、要望は断片的なメールやチャットで伝わり、文脈が抜け落ちます。後から「優先してほしいと伝えたはず」と主張しても、根拠が残っていなければ調整は難航します。
つまり、関与しないことは「POを信頼している」のではなく、「事業価値を伝える責任を放棄している」状態に近いのです。
関与しすぎる場合に起きること
では、積極的に関与すればよいかというと、過干渉にも明確なリスクがあります。
- 割り込みでスプリントが乱れる: スプリントの途中で「やっぱりこれを今すぐやってほしい」と差し込み要望を入れると、開発チームは進行中の作業を中断せざるを得ません。生産性が落ち、見積りも崩れます。
- 全件を「最優先」と主張してしまう: すべての要望に「最優先」のラベルを貼ると、優先度という概念そのものが機能しなくなります。POは何を本当に優先すべきか判断できず、結局は推測で並べることになります。
- POの決定権を侵食する: 「この順番で作ってください」と並び順そのものを指定すると、POの責任領域に踏み込むことになります。プロダクト全体の整合性を考えて並べているPOの判断を覆すと、プロダクトの一貫性が崩れます。
関与は「権利」ではなく、事業価値を正しく伝える「責任」です。だからこそ、伝えるべきこと（価値）と委ねるべきこと（並び順の決定）を区別した、適切な関与が求められます。次の章からは、その「適切な関与」を具体的な会議の場と伝え方に落とし込んでいきます。
発注者が優先順位づけに関与する3つの場面
「関与しよう」と思っても、いつ・どの場で発言すればよいかが分からなければ動けません。実は、発注者が優先順位づけに影響を与えられるタイミングは、アジャイル開発の会議体の中にきちんと用意されています。ここでは代表的な3つの場面を取り上げ、それぞれで発注者が「何を持ち込み、何を発言すべきか」を整理します。逆に言えば、この3つの場以外でのスプリント途中の割り込みは避ける、という線引きにもなります。
バックログリファインメント｜要望の背景と価値を共有する場
バックログリファインメント（または「グルーミング」）とは、バックログのアイテムを整理し、内容や優先度を見直していく継続的な活動です。なお、リファインメントはスプリントプランニングやスプリントレビューのような正式なスクラムイベントではなく、進め方に厳密なルールはありません（スクラムガイド2020）。
この場には、PO・開発チームに加えてステークホルダーである発注者も参加することが推奨されています。ビジネス面と技術面の両方から要望を検討できるため、発注者が同席することで、開発チームからの質問にその場で答えられ、認識のずれを早期に解消できます（SHIFT ASIA）。
発注者がこの場で持ち込むべきは、要望そのものよりも「要望の背景と価値」です。「なぜこの機能が必要なのか」「実現すると事業にどんな効果があるのか」を共有することで、POはアイテムの価値を正しく見積もれます。逆に「いつ作るか」「どう作るか」の決定は、この場でも開発チームとPOに委ねます。
スプリントプランニング前｜次に優先したい要望をPOに伝える
スプリントプランニングは、次のスプリントで何に取り組むかを決める会議です。ここで何を実装するかは、その時点のバックログの並び順に基づいて決まります。
したがって、発注者が「次のスプリントでこの機能を進めてほしい」と考えるなら、プランニングが行われる前のタイミングでPOにその意向を伝えておくことが効果的です。プランニング当日にいきなり要望を出すと割り込みになりますが、事前にPOと価値の認識をすり合わせておけば、POが並び順に反映する余地が生まれます。
ここでも発注者の役割は「並び順の指定」ではなく「優先したい理由の提示」です。最終的にどのアイテムをそのスプリントに含めるかは、開発チームの見積りとPOの判断に委ねます。
スプリントレビュー｜成果物を見て次の優先度に学びを返す
スプリントレビューは、スプリントの成果物（動くソフトウェア）をステークホルダーに見せ、フィードバックを受ける場です。発注者にとっては、関与の「締めくくり」であると同時に、次の優先度づけの「始まり」でもあります。
完成した機能を実際に触ってみると、「思っていたものと違う」「この方向なら次はこちらを優先したい」といった気づきが生まれます。この気づきを言語化してPOに返すことが、次のバックログの並べ替えに活きます。スプリントレビューを「報告を受ける場」で終わらせず、「次の優先度を一緒に考える場」として使うことが、継続的に自社要望を反映させる鍵になります。
この3つの場を意識するだけで、「いつ関与すればよいか分からない」という状態から抜け出せます。そして、これらの場で「何を伝えるか」をさらに具体化したのが、次の章で解説する「価値の根拠」の伝え方です。
優先要望を「通す」伝え方｜価値の根拠をセットにする
関与する場が分かっても、伝え方を間違えると要望は通りません。「この機能を優先してほしい」とだけ伝えても、POは他の要望との優先度を比較できないからです。決定権を持たない発注者が自社の要望を反映させる最大の武器は、POが優先度判断に使える「価値の根拠」を添えることです。この章では、要望を通すための具体的な伝え方を整理します。
「要望」ではなく「価値の根拠」を渡す
POは限られた開発リソースの中で、どのアイテムが最もプロダクトの価値を高めるかを判断しています。そのため、発注者が「価値の根拠」を渡せば渡すほど、POはその要望を優先度に反映しやすくなります。価値の根拠は、次の4つの観点で整理すると伝わりやすくなります。
- 売上インパクト: その機能が売上・契約・継続率にどう影響するか（例: 「決済方法の追加で離脱していた層を取り込め、月間数百件の成約機会につながる」）
- ユーザー離脱: その機能がないことで、どれだけのユーザーが離れているか（例: 「登録フローの途中離脱率が高く、改善すれば登録完了率の向上が見込める」）
- 期限・コンプライアンス: 法令対応やキャンペーンなど、動かせない期限があるか（例: 「改正法の施行日が決まっており、それまでに対応が必須」）
- 依存関係: その機能が他の機能や事業施策の前提になっているか（例: 「この基盤がないと、来期予定の新サービスが開始できない」）
「優先してほしい」という気持ちを、これらの数字や事実に翻訳することが、要望を通す出発点です。
要望の伝え方テンプレート
価値の根拠を整理したら、次の型に沿って伝えると、POが優先度判断に使いやすい形になります。
- 背景: なぜこの要望が生まれたのか（事業の状況・きっかけ）
- 価値: 実現するとどんな効果があるのか（前述の4観点で根拠を示す）
- 希望時期: いつまでに実現したいのか、その理由は何か
- 譲れる線／譲れない線: 完璧でなくてもよい部分と、絶対に外せない部分
たとえば「キャンペーン開始の◯月までに、最低限の決済機能だけは動かしたい。デザインの細部は後回しでよい」といった伝え方をすると、POは「いつまでに・何を・どこまで」を踏まえて並び順を判断できます。「全部を完璧に、今すぐ」という伝え方とは、反映されやすさが大きく変わります。
この「譲れる線／譲れない線」を示すことは、過干渉を避けるうえでも重要です。すべてを最優先と主張するのではなく、優先度の濃淡を自分から示すことで、POとの調整がスムーズになります。なお、優先度とスコープ・費用の関係については、アジャイル発注のスプリント費用とスコープ管理もあわせて参考になります。
優先度フレームワークを共通言語にする
MoSCoW（Must/Should/Could/Won't）や WSJF といった優先度フレームワークは、本来はPOが優先度を決めるための道具です。発注者がこれらを使って並び順を指定する必要はありません。
ただし、POがどのフレームワークで優先度を判断しているかを知っておくと、「同じ物差し」で会話ができるようになります。たとえばPOがMoSCoWで管理しているなら、発注者も「この要望はMust（必須）だと考えています、理由は◯◯です」と伝えることで、POの判断プロセスに沿った形で要望を届けられます。フレームワークの具体的な運用手順を知りたい場合は、バックログとは｜スクラム発注者が押さえる優先度の決め方ガイドで解説しています。ここで重要なのは、決め方を覚えることではなく、「POと同じ言葉で価値を語る」ことです。
発注者が関与すべきこと／POと開発チームに委ねること
ここまで「どこで・どう関与するか」を見てきましたが、関与の不安の根っこには「どこまでなら口を出してよいのか」という境界の曖昧さがあります。この章では、発注者・PO・開発チームそれぞれの領域を整理し、過干渉でも放置でもない関わり方の線引きを明確にします。
役割分担の早見表
優先順位づけにまつわる役割を、3者で整理すると次のようになります。
領域 | 発注者（ステークホルダー） | プロダクトオーナー | 開発チーム |
|---|---|---|---|
事業価値・要望の背景 | ◎ 提供する（最も詳しい） | ○ 受け取り判断に使う | △ 参考にする |
優先度の根拠（売上・期限など） | ◎ 言語化して伝える | ○ 比較・検討する | — |
バックログの並び順（最終決定） | △ 意見は言うが決めない | ◎ 決定する | △ 見積りで助言 |
実現方法・技術的な設計 | — | △ 方針を共有 | ◎ 決定する |
見積り・実現可能性 | — | ○ 把握する | ◎ 行う |
成果物の受け入れ判断材料 | ◎ 事業観点で評価する | ◎ 受け入れを判断する | ○ 説明する |
ポイントは、発注者の領域が「価値を伝えること」と「事業観点で評価すること」に集中している点です。並び順の最終決定や実現方法は、POと開発チームに委ねます。この境界を意識すれば、「伝えるべきことは遠慮なく伝え、決めることには踏み込まない」という関わり方ができます。
なお、PO不在や関与の偏りによるリスクをどう管理するかについては、アジャイル開発の外注リスク管理で体制づくりの観点から整理しています。
やってはいけない関与のアンチパターン
最後に、発注者が陥りがちな関与のアンチパターンを3つ挙げます。いずれも「関与したい」という思いが裏目に出るパターンです。
- 割り込み要望の乱発: スプリント途中で「今すぐこれを」と差し込むと、進行中の作業が止まり、チーム全体の生産性が落ちます。要望は前述の3つの場で、計画的に出しましょう。
- 全件を「最優先」と主張する: すべてに最優先のラベルを貼ると、優先度の概念が崩壊します。自分から優先度の濃淡（譲れる線／譲れない線）を示すことが、結果的に要望を通す近道です。
- 並び順そのものを指定する: 「この順番で作って」とバックログの並びを直接いじろうとすると、POの責任領域を侵食します。発注者が渡すのは「価値の根拠」であり、それをどう順番に落とし込むかはPOの判断に委ねます。
これらを避けるだけでも、「口を出しすぎて混乱させる発注者」から「価値を的確に伝える頼れるパートナー」へと、ベンダーからの見え方が変わります。
よくある質問｜発注者の関与に関するQ&A
ここまでの内容を踏まえても、実際の現場では細かい疑問が出てきます。よくある質問に答えておきます。
Q. リファインメントに発注者が参加してよいのか？
参加して構いませんし、むしろ推奨されます。リファインメントは厳密なルールが定められた正式なスクラムイベントではなく、参加者の範囲も柔軟です。ステークホルダーである発注者が参加することで、要望の背景や価値をその場で共有でき、開発チームの理解が深まります（SHIFT ASIA）。ただし、参加の可否や頻度はチームの運用方針によるため、まずはPOに「リファインメントに同席させてほしい」と相談するのがよいでしょう。
Q.「優先順位」と「順番」は何が違うのか？
混同しやすいのですが、この2つには明確な違いがあります。「優先順位」は個々のアイテムの重要度を示すのに対し、「順番（順序）」は、プロダクト全体の価値を最大化するために実装する順序を総合的に判断したものです。スクラムガイドも2011年版以降は「優先順位」ではなく「順序付け」という言葉を使っています（アトラクタ、Ryuzee.com）。
これは発注者にとって重要な示唆を含みます。「自分の要望の優先度が高いのに、なぜ後の順番なのか」と感じる場面があるかもしれませんが、POは個別の優先度だけでなく、プロダクト全体の整合性や依存関係を踏まえて順番を決めています。優先度が高い＝必ず最初に作る、とは限らないのです。この前提を理解しておくと、POの判断に納得しやすくなります。
Q. 複数部署で優先要望が衝突したらどうするか？
社内の複数部署がそれぞれ別の要望を「最優先」と主張すると、POは板挟みになります。この場合、POに調整を丸投げするのではなく、要望を出す部署側で事前に優先度の調整を試みることが望ましい状態です。
その際の物差しになるのが、本記事で繰り返し述べてきた「価値の根拠」です。「どちらが声が大きいか」ではなく、「どちらが事業価値（売上・期限・離脱など）が高いか」で比較すれば、部署間でも建設的に優先度を話し合えます。それでも合意できない場合は、各部署の価値の根拠を整理したうえでPOに判断材料として渡し、最終的な順番づけはPOに委ねます。
まとめ｜明日のリファインメントから始める3ステップ
バックログの優先順位は最終的にはPOが決めますが、発注者が「価値を伝える人」として正しく関与すれば、自社の優先要望をしっかり反映させられます。決定権がないことと、影響力を持てないことは、別の話です。
最後に、明日からの関与を3つのステップにまとめます。
- 自分はPOかステークホルダーかを確認する: 自分が優先度を決める立場なのか、価値を伝える立場なのかを最初に整理します。本記事の対象である「PO を担わない発注者」であれば、決定権はPOに委ね、価値を伝える役割に徹します。
- 優先要望に価値の根拠を添えて、関与の場で伝える: 「優先してほしい」だけでなく、売上・離脱・期限・依存関係といった根拠をセットにし、バックログリファインメント・スプリントプランニング前・スプリントレビューの3つの場で計画的に伝えます。
- 決定権はPOに委ね、関与する場と引く場を線引きする: 並び順の最終決定や実現方法には踏み込まず、スプリント途中の割り込みは避けます。境界を守ることで、過干渉でも放置でもない、信頼される関与ができます。
まずは次回のリファインメントやスプリントレビューで、自社の優先要望をひとつ、価値の根拠とともに伝えてみてください。「決める」のではなく「伝える」関与の第一歩が、自社要望を確実に前へ進める力になります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
