バックログとは｜スクラム発注者が押さえる優先度の決め方ガイド

「スクラムでやりましょう。発注者の方がプロダクトオーナーとしてバックログの優先度を決めてください」。ベンダーとのキックオフでこう言われ、戸惑っている発注担当者の方は少なくありません。ウォーターフォール開発では要件定義書を一度作れば、あとは進捗報告を受けるだけで済んでいました。ところがスクラムでは「バックログ」と呼ばれる動的なリストを、発注者自身が並び替えながら開発を進めることになります。

問題は、優先度の判断基準が手元にないことです。社内の上長や経理から「なぜこの機能が先なのか」と問われたとき、根拠を持って説明できなければ意思決定はできません。「ベンダーに任せたい」と思っても、スクラムでは仕様の優先度は発注者の責任範囲とされているため、丸投げするわけにもいきません。

本記事では、初めて外部ベンダーとスクラムを組む発注者の方に向けて、バックログの基本概念から、優先度を決める判断基準・フレームワーク（MoSCoW・WSJF・カノモデル）、社内ステークホルダーへの説明テンプレートまでを実務目線で解説します。読み終えたあと、次回のスプリントプランニング前に自信を持ってバックログを並べ替えられる状態を目指します。

なお、本記事は「発注者がプロダクトオーナーを担う」ケースに絞って書いています。自社内でプロダクトオーナー候補が複数いる場合や、すでにスクラム経験豊富な企業向けの一般論ではなく、外部委託の発注側に立った視点で読み進めてください。

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

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

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

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

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

バックログとは｜スクラム開発における「やることリスト」の正体

バックログとは、スクラム開発で「これから作るべき機能・改善項目を、価値の高い順に並べたリスト」を指します。単なるTODOリストではなく、プロダクトの方向性を意思決定するためのドキュメントとして機能します。

スクラムガイドの公式定義では、バックログは「プロダクトの改善に必要な項目を順序付けた創発的なリスト」とされています（Scrum Guide 2020 日本語版）。「創発的」という言葉が重要で、バックログは固定された仕様書ではなく、開発を進めながら継続的に更新されることが前提です。

スクラム開発でバックログが果たす役割

スクラム開発において、バックログは3つの役割を担います。第一に、開発チームが次に何を作るべきかを示す「作業の単一情報源」となります。第二に、プロダクトの方向性に関する意思決定を可視化する「合意形成の場」として機能します。第三に、ステークホルダーが「いつ何が届くか」を把握するための「進捗の見通し」を提供します。

発注者（プロダクトオーナー）にとってのバックログは、「限られた予算と期間で、どの機能を優先するか」を決める場所です。すべてを作る時間はないため、価値の高い順に並べ替え、リリースに含める範囲を継続的に決めていくことが求められます。

ウォーターフォールの要件定義書との3つの違い

ウォーターフォール開発の要件定義書とバックログには、本質的に異なる点が3つあります。

1点目は凍結性です。要件定義書はプロジェクト開始時に凍結され、変更には変更管理プロセスが必要です。一方バックログは、毎スプリント（通常1〜2週間）の終わりに見直され、優先度の変更や項目の追加・削除が日常的に行われます。

2点目は粒度です。要件定義書は最初から全ての機能を詳細に記述します。バックログは、近い将来に着手する項目は詳細に、遠い未来の項目は概要だけ記述する「冷凍庫の解凍」のような階層構造を取ります。

3点目は更新頻度です。要件定義書は数か月単位で更新されますが、バックログは週次〜日次で組み替えが発生します。この更新の主体が発注者である点が、ウォーターフォールとの最大の違いです。

スクラム開発全体の流れについては、アジャイル・スクラム開発の基本ガイドもあわせて参照してください。

プロダクトバックログとスプリントバックログの違い

バックログには2種類あります。発注者として混同しやすいポイントですが、責任分界を理解する上で最重要の前提知識です。

プロダクトバックログ（What・Why を決める／発注者の責任）

プロダクトバックログは、「プロダクトに必要な機能・改善項目の全体リスト」です。発注者（プロダクトオーナー）が管理責任を持ち、What（何を作るか）とWhy（なぜ作るか）を定義します。

具体的には、機能要望・バグ修正・技術的負債の解消・新規アイデアなどがすべて含まれます。項目1つを「プロダクトバックログアイテム（PBI）」と呼び、ユーザーストーリーの形式（「〇〇として、△△したい、なぜなら□□だから」）で記述するのが一般的です。

スプリントバックログ（How を決める／開発チームの責任）

スプリントバックログは、「次の1〜2週間（スプリント）で実際に着手する項目を、開発チームが詳細化したリスト」です。開発チームが管理責任を持ち、How（どう作るか）を定義します。

プロダクトバックログの上位項目（最優先のもの）の中から、スプリントプランニングで開発チームが「今回のスプリントで実現できる量」を見積もり、抜き出して詳細化したものがスプリントバックログです。発注者はスプリントバックログの詳細（タスク分解・実装手順）には立ち入りません。

比較表で見る責任分界と更新タイミング

この表のとおり、発注者が触るべきはプロダクトバックログのみです。スプリントバックログは開発チームの領域であり、タスクの分解方法や実装手順について発注者が口出しする必要はありません。

発注者がプロダクトオーナーを担う際の役割と責任範囲

発注者がプロダクトオーナーを兼任するケースは、外部委託のスクラム開発でよく見られます。役割を整理しないまま開始すると「丸投げ」か「過剰関与」のどちらかに振れがちです。プロダクトオーナーが担う4つの責任を明確化しましょう。

プロダクトオーナーの4つの責任

1. ビジネス価値の定義: 各機能が「事業にとってどれだけ価値があるか」を判断する。売上貢献・コスト削減・顧客満足度向上などの軸で評価する。
2. 優先順位付け: プロダクトバックログ全体を価値の高い順に並べ替える。後述のフレームワーク（MoSCoW・WSJF など）を使って判断する。
3. 受け入れ判断: スプリント終了時に成果物が「完成」しているかを判定する。事前に定義した受け入れ基準（Acceptance Criteria）を満たしているかを確認する。
4. ステークホルダー調整: 社内の上長・経理・関連部署からの要望を吸い上げ、優先順位に反映する。同時に「なぜこの順番か」を説明し、合意を得る。

スクラムマスター／開発チームとの責任分界表

「受け入れ基準を満たしているか」の判断は発注者の責任ですが、「どんなコード設計にするか」「テスト戦略をどう組むか」は開発チームに任せます。ここを混同して実装方法にまで口出しすると、開発チームの自律性を損ね、結果的にスピードが落ちます。

スクラム開発を外部委託する際の全体像については、スクラム開発を外注する進め方を参照してください。発注者の責任範囲に関するリスクは、アジャイル開発の外注リスク管理で詳しく解説しています。

「発注者がPOを兼ねる」場合の現実的な工夫

発注者がプロダクトオーナーを兼ねる場合、本業との両立が課題になります。実務で機能している現実的な工夫を3つ紹介します。

1つ目は意思決定の窓口を一本化することです。社内の複数部署から要望が直接ベンダーに飛ぶと、優先度が混乱します。発注者を窓口にする運用ルールを最初に決めましょう。

2つ目は週次のバックログリファインメント時間を確保することです。スプリントとは別に、週1時間程度でも「次のスプリントに何を入れるか」を考える時間を予定に組み込みます。

3つ目はプロキシPOの活用です。発注者が忙しい時間帯には、ベンダー側のスクラムマスターやテックリードに「優先度判断の補助役（プロキシPO）」を依頼する手もあります。ただし最終的な意思決定は発注者が行う前提です。

バックログの優先度の決め方｜判断基準と3つのフレームワーク

本記事の核となるセクションです。優先度判断の基本要素を整理し、自社で運用できるフレームワークを3つ紹介します。

優先度を判断する4つの基本要素

優先度を決める際は、以下の4要素を組み合わせて評価します。

1. ビジネス価値: 売上貢献・コスト削減・顧客満足度向上など、事業へのインパクト
2. リスク: 「やらないこと」のリスク（競合に先行される・法令違反になる等）と、「やること」のリスク（技術的不確実性・依存先トラブル等）
3. 依存関係: 他の機能の前提となる基盤機能か、後工程に影響する機能か
4. 工数: 開発チームによる見積もり（ストーリーポイント等）

これら4要素を頭の中で総合判断するのは難しいため、明文化されたフレームワークに沿って優先度を決める方法が広く使われています。代表的な3つを紹介します。

MoSCoW分析（必須・推奨・可能・先送り）— シンプルさ重視で初回に推奨

MoSCoW（モスコウ）分析は、バックログアイテムを以下の4カテゴリに分類する手法です。

MoSCoW の最大の利点はシンプルさです。誰でもすぐに理解でき、社内の非エンジニアにも説明しやすい構造になっています。スクラム未経験の発注者が初回スプリント前に運用を始めるなら、まずMoSCoWから入ることを推奨します（MoSCoW分析の詳細はAgile Business Consortium の解説を参照）。

WSJF（重み付け最短ジョブ優先）— ROIで定量説明したい時の選択肢

WSJF（Weighted Shortest Job First）は、SAFe（Scaled Agile Framework）で採用されている定量的な優先度算出手法です（SAFe 公式ドキュメント）。

計算式はシンプルです:

WSJF = (ビジネス価値 + 時間的緊急度 + リスク低減・機会創出) ÷ 工数

各要素を1〜10などのスコアで評価し、WSJF スコアが高い順に並べ替えます。WSJFの利点はROIを意識した定量説明ができることです。経理や上長に「なぜこの順番か」を数値で示せるため、金額の根拠を求められる場面で有効です。

ただし、各スコアの付け方を社内で合意形成する必要があり、MoSCoWに比べて運用負荷が高い点に注意してください。

カノモデル — 機能の魅力度を顧客満足度視点で評価

カノモデル（狩野モデル）は、機能を「顧客満足度への寄与の仕方」で分類する手法です。日本人研究者である狩野紀昭氏が提唱しました。

カノモデルは、新規プロダクトで「どの機能で差別化するか」を決める場面に向いています。ただし顧客アンケート等の調査が前提のため、運用負荷は高めです。

自社にどれを選ぶか｜選び方フローチャート

以下の判断軸で、自社に合うフレームワークを1つ選んでください。

• 初めてのスクラム発注 / スピード重視: → MoSCoW
• 社内に「ROIの数値根拠」を求める文化がある: → WSJF
• 新規プロダクトで顧客差別化軸を探したい: → カノモデル

完璧を求めず、まずMoSCoWで運用を開始し、慣れてからWSJFやカノモデルに進む二段階アプローチが現実的です。優先度判断とスコープ管理は密接に関連するため、アジャイル開発におけるスコープ・コスト管理もあわせて参照してください。

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

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

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

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

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

社内ステークホルダーに優先度を説明するための型

優先度を決めるだけでなく、社内に説明し合意を得ることもプロダクトオーナーの責任です。説明テンプレートと意思決定ログの残し方を紹介します。

優先度説明の3点セット（採用基準・トレードオフ・次の見直しタイミング）

社内の上長・経理・関連部署に優先度を説明する際は、以下の3点を含めた型で話すと納得を得やすくなります。

1. 採用基準: 「どのフレームワークに基づき、何を根拠に並べたか」を明示する

• 例:「MoSCoW分析を使い、リリース必須の Must have を上位3項目に置きました」

2. トレードオフ: 「優先度を上げた結果、何が後回しになったか」を明示する

• 例:「決済機能を優先したため、レポート機能は次スプリント以降に回しています」

3. 次の見直しタイミング: 「いつ、どの場で再評価するか」を明示する

• 例:「次回のスプリントレビュー（2週間後）で、ユーザーテスト結果を受けて並び替えを再検討します」

この型に沿って説明することで、「決めて終わり」ではなく「継続的に見直す前提の意思決定」だと相手に伝わります。社内ステークホルダーが「途中で並び替えてもよいのか？」と不安を感じる場面で特に有効です。

意思決定ログの残し方（どのフレームワークで・誰と・いつ決めたか）

優先度の意思決定は記録に残しましょう。説明責任を果たすうえでも、後から振り返って学ぶうえでも重要です。最低限、以下の項目を残します。

記録媒体はNotion・Confluence・Googleドキュメントなど何でも構いません。重要なのは「いつでも遡って確認できる場所」に残すことです。

スプリントレビューで発注者が確認すべきこと

優先度は決めて終わりではなく、スプリントごとに見直すものです。毎スプリントの最終日に開催される「スプリントレビュー」は、発注者にとって優先度を更新する重要な場になります。

受け入れ基準に照らした成果物確認

スプリントレビューでは、開発チームが「完成した機能」をデモします。発注者は事前に定めた受け入れ基準（Acceptance Criteria）に照らして、各機能が完成しているかを判定します。

受け入れ基準は、PBI を作成する段階で「この条件を満たせば完成」と明文化しておきます。例えば「ユーザーがメールアドレスとパスワードでログインできる」というPBIの受け入れ基準は、以下のように具体化されます。

• 有効な認証情報でログインに成功する
• 無効なパスワードでエラーメッセージが表示される
• 3回連続失敗するとアカウントが一時ロックされる

受け入れ基準を満たしていない場合は「未完了」として、次スプリントのバックログに戻します。曖昧な「だいたい動いている」を受け入れないことが、品質を担保するポイントです。

学びを次スプリントの優先度に反映する3つの問い

スプリントレビューでは、完成したものを確認するだけでなく、次の優先度に反映すべき学びを引き出します。以下の3つの問いを開発チームに投げかけてみてください。

1. 「予想外に時間がかかった部分はどこですか？」: 技術的複雑性が見えてきた箇所は、今後の見積もりに反映できる
2. 「実装してみて見えた、追加で必要な作業はありますか？」: 当初の見積もりに含まれていなかった項目を発見できる
3. 「次に着手するなら、どの項目が技術的にリスクが高いと感じますか？」: リスクの高い項目を早期に優先度に組み込める

これらの問いから得た情報を、次回のリファインメント（バックログ手入れ）でプロダクトバックログに反映します。

バックログ管理を支えるツール

バックログ管理ツールは多数ありますが、発注者にとって重要なのは「自分が無理なく関与できるか」の一点です。開発チームが詳細なタスク管理をするのは前提として、発注者が優先度の並び替え・コメント・受け入れ判断を行いやすいツールを選ぶ視点で見ていきます。

主要ツールの発注者目線比較

ベンダーが既にツールを採用済みの場合は、それに合わせる方が現実的です。新規選定の場合は、以下の発注者目線の3観点で評価してください。

発注者目線のツール選定3観点

1. 学習コスト: 発注者が30分以内に「優先度を並び替える」「コメントする」「受け入れ判定する」操作を習得できるか。学習コストが高いツールは、結局触らなくなり「ベンダー任せ」状態に陥ります。

2. 通知のうるささ: デフォルト通知設定で、発注者のメール・Slackが埋もれないか。すべての更新が通知されると重要なメンションを見逃します。発注者が確認すべき通知だけを絞れる設定機能があるかを確認してください。

3. 優先度の可視化: バックログを上から下に並べた状態で「優先度の高い項目」がひと目で分かるか。色分け・ラベル・ドラッグ&ドロップでの並び替えなど、視覚的な操作性が重要です。

ツール選定はベンダーと相談の上、最終的に発注者が触る画面を実機で見て判断することをおすすめします。

アジャイル vs ウォーターフォール｜発注者の関与の違い

最後に、ウォーターフォール経験者がスクラムに移行する際のメンタルモデルの転換について整理します。

関与頻度・意思決定タイミングの違い

ウォーターフォールでは「要件定義書を一度作れば、あとは進捗報告を受けるだけ」というスタイルが成立しました。スクラムでは、それを続けると「優先度の意思決定が止まる」結果になります。

「決めて終わり」ではなく「決め続ける」発注スタイルへ

スクラム発注の最大のマインドセット転換は、「決めて終わり」から「決め続ける」への切り替えです。最初に完璧な要件を定義しようとせず、初回はざっくり並べた状態でスタートし、スプリントを重ねながら優先度を磨いていく姿勢が成功の鍵になります。

これは「いい加減でよい」という意味ではなく、「変化を前提に意思決定の仕組みを設計する」ということです。社内ステークホルダーにもこの前提を共有し、「途中で並び替わるのは正常な動作」と理解してもらうことが、スクラム発注を機能させる土台になります。

まとめ｜明日から動かすための3ステップ

ここまで読んでいただいた発注者の方が、明日から動き出せるよう、要点を3ステップに圧縮します。

ステップ1: バックログを2種類に分けて理解する

• プロダクトバックログ（What・Why）は発注者の責任、スプリントバックログ（How）は開発チームの責任。ここを混同せず、自分が触るべき範囲をプロダクトバックログに絞る。

ステップ2: 自社に合う優先度フレームワークを1つ選ぶ

• 初回はMoSCoW分析から始めるのが現実的。ROIを定量化したい場面ではWSJF、新規プロダクトの差別化軸を探すならカノモデルに進む。フレームワークは複数併用せず、まず1つで運用を回す。

ステップ3: スプリントレビューで継続的に見直す

• 毎スプリント終了時に成果物を受け入れ判定し、開発チームから学びを引き出し、次の優先度に反映する。意思決定ログを残し、社内ステークホルダーには「採用基準・トレードオフ・次の見直しタイミング」の3点セットで説明する。

スクラムにおけるバックログ管理は、最初は戸惑うかもしれませんが、スプリントを2〜3回回すうちに自分なりのリズムができてきます。完璧を目指さず、まず一歩を踏み出してください。発注者がプロダクトオーナーを担うスクラム開発の全体像については、スクラム開発を外注する進め方も参考になります。

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

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

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

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

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