スクラムフレームワーク — 第二版

この章は、第二版の歴史的背景と実践的な説明を保持しています。第三版のカリキュラムも、下の目次から利用できます。

---

スクラムプロダクトバックログ：アジャイルのプロジェクトで価値を作る方法

皆さんのプロジェクトは、可能性を十分に生かせていますか？コーチのように機敏にチームを導こうと、スクラムの進め方を磨くのに苦労しているかもしれません。今こそ、ある構成要素（スクラムフレームワークの主な構成要素）に注目し直すときです。それが、スクラムプロダクトバックログです。活用不足や誤解も多い強力な道具ですが、使いこなせば確かな成功へ導けます。より良い提供のために、取り組む価値があります。役割、優れた実践、管理の切り札にする方法を学びましょう。まだ使っていない力を引き出すため、経験豊かな講師と、この興味深いシリーズを進めていきましょう！

定義：スクラムプロダクトバックログは、アジャイルのプロジェクトで、プロダクトを提供・改善するために必要な仕事を、順番に並べたリストです。 スポーツのコーチが学生を指導するように、バックログもチームを支えます。定期的な詳細化と優先順位付け、透明性、プロダクトゴールとの整合、検索や絞り込みを助ける電子ツールが、効果的な管理に含まれます。大きさを管理できる状態に保つため、古いチケットの削除や保管の変更を適切に伝えることも重要です。

最も簡単に言えば、プロジェクトで行う必要のある仕事の集まりです。 従来の要求仕様書に代わるものです。技術的な項目も、ユーザー中心の項目も含められます。責任者はスクラムプロダクトオーナーです（詳細： スクラムプロダクトオーナー）。スクラムマスター、チーム、他のステークホルダーも、学生を指導する講師のように、幅広く充実した実施事項のリストづくりに貢献します。

他の作成物を用意・利用してはいけない、という意味ではありません。利用者の役割の概要、ワークフロー、画面設計の指針、ストーリーボード、画面の試作品などがあります。ただし、バックログを置き換えるのではなく、内容を補い、詳しくするものです。開発を十分に行う姿勢を示します。

プロダクトオーナーはチームの支援を受け、プランニングでバックログ上位の項目を説明します（当サイトの スクラムの実例参照）。その後チームが、次のスプリントで完成できるものを判断し、提供を最適化します。

単なる実施事項のリストとは異なる、固有の性質があります。学ぶ人への指針となり、勝利を目指すコーチのように方向性を示します。

• 各アイテムは直接・間接に価値へ貢献すべきです。品質、リスク低減、技術改善、学習も含まれます。
• 項目に優先順位を付け、その順に並べます。
• 詳細さは、バックログ内での位置によって変わります。
• 次の判断と予測を支える必要に応じて、規模を見積もります。
• 変化し続ける文書です。
• 実装の詳細なタスクは通常、開発者のスプリント計画で扱います。バックログは、プロダクトの仕事と成果に集中します。

スクラムのバックログの定義

成功するアジャイルのプロジェクトの中心には、バックログがあります。プロダクトを成功へ導くため、開発チームが完了すべき、順序付きのアイテム（PBI）のリストです。コーチの献身に例えられるほど重要で、プロダクトオーナーが責任を持って仕事を優先し、効果的な提供を支えます。

機能、バグ、技術的負債、知識の獲得など、提供に必要だとわかっている項目をすべて含みます。 継続的な反応を通じて、時間とともに生まれ、変わる作成物です。初めは概要レベルの要件やエピックを並べ、取り組む際に、小さく詳細なストーリーへ分けます。各アイテムは、一つのスプリントで完成できる大きさにします。反復的・漸進的な開発を支える計画の道具でもあり、開発者やマスターには、アジャイルなリーダーシップの進め方を示す講座の地図に例えられます。

バックログはスクラムを含むアジャイルの成功に欠かせません。高い基準を満たすため、ユーザー体験の専門家もいるチームが完了すべき仕事を順序付けます。既知の要件を含み、フィードバックで変化します。責任を持って優先するのはプロダクトオーナーであり、開発者は各スプリントで完成できる量を予測します。複雑な開発からリーダーシップの講座まで、計画の重要な道具となります。

庭を育てるのと同じように、バックログにも丁寧な世話が必要です。開始時には、講座を構成するように、チームとオーナーが思いつくことを書き出します。通常は、それだけで、開発者が新機能に取り組む最初のスプリントに十分な量になります。

スクラムプロダクトバックログを使う

オーナーは責任を持ち、経験豊かな開発者がコードの効率を確かめるように、バックログを良い状態に保ちます。この版では、議論や見積もりなどの詳細化に、キャパシティの約10%を使うことを目安としています。全チームに必須の割合ではありません。専門家が研修の時間を確保するのに似ています。

初期の準備後も、継続的なリーダーシップのように、次の手順で維持し続けます。

• 新しく見つかったものを記述して追加し、既存のものを適切に変更・削除する。
• 並び順を決め、重要なものを上位へ移す。
• 優先度の高い項目を、次のプランニングに向けて準備する。
• 項目を見積もり、必要に応じて見積もり直す。

共同の維持作業は、要件を明確にするだけでなく、優れたユーザー体験の方針のように、チームの納得と参加も生みます。

各項目は、講座の各要素のように、何らかの顧客価値を持つ必要があります。妥当な価値への貢献がなければ除去できますが、間接的に価値を支える仕事も認めます。ニーズや技術的な選択肢の探索、機能・非機能の要求、公開に必要な仕事、環境準備、欠陥修正も含められます。教材の事例と同じく、直接の価値はなくても、長期の品質改善と障害低減を支えるものがあります。

スクラムプロダクトバックログの特徴

価値を加えるアイテムの、生きたリスト

定期的に更新するリーダーシップ講座のように、進行中ずっと変わります。新しい要件を加え、既存のものを変更・詳細化し、不要なら捨てます。従来の要求工学とは異なりますが、顧客価値を最大化し、開発の作業量を最小限にできます。

詳細さの違い

講座の概要と同じく、要件の粒度には違いがあります。近いスプリントで実装するものは詳細に定義し、それ以外は大まかに保ちます。実装前に変わりそうな仕様へ費やす時間と労力を減らす、効率的でアジャイルな方法です。

次の判断に十分な詳細さ

バックログには、次の判断、特に近く選びそうなアイテムについて、十分な詳細が必要です。実装の細かなタスクを、事前にすべて書く必要はありません。学びに応じて顧客や関係者と要件を明確にし、選んだ仕事のタスクへの分け方は開発者が決めます。必要な資源を適切に割り当て、開発するサービスの価値を高める使命を見失わないようにします。

プロダクトバックログの順序を決める

すべての項目に優先順位を付け、並べます。オーナーがチームの助けを借り、付加価値、費用、リスクなどに基づいて丁寧に調整します。その繰り返しにより、次に何をすべきかを素早く判断できます。

プロダクトバックログアイテムの規模を見積もる

開発者は、ストーリーポイントなどの共通の方法で、必要に応じて規模を見積もります。変わり続けるバックログの全体を、事前に見積もる必要はありません。この見積もり（詳細： スクラムの作業量見積もり）は、新版のソフトウェアを準備するように、優先順位付けとリリース計画の両方に使えます。

段階的に準備する

旅行の準備に似ています。時間をかけて荷物を詰め、旅券やビザを早めに用意し、予定を円滑に実行できるようにします。ここでの旅の計画は提供するサービスであり、その利用者はプロジェクトのステークホルダーです。

主体性と責任

バックログは、早い段階で作る必要があります。その後も、維持と詳細化の主体的な責任は、主にオーナーが負います。詳細化はスプリント中を通じて行える継続的な仕事であり、独立した必須イベントではありません。アプリを更新して透明性を高めるのに似ていますが、過度に細かな管理にしてはいけません。

例えば、株式市場のデータを即時に表示するアプリを開発し、需要が高いと反応が遅い版があるとします。緊急性のある問題を優先し、新しいデータが届いたとき素早く処理できるよう、具体的なアイテムとして追加するべきです。

オーナーには、増え続けるリストの世話が追加の負担に感じられることもあります。それでも、事業の必要と顧客要件を把握し、開発活動と結びつけることは不可欠です。多様な要素を調和させる使命なのです。

バックログ管理は、職能間の対話の道具です。関係者の意思疎通を良くし、目標への進捗を透明にします。全員に状況を知らせる、サービスのロードマップのようなものです。

勢いと集中を保つため、オーナーの維持責任を理解することが重要です。ソフトウェアの各版と同じく、丁寧な更新が必要です。その仕組みを詳しく見てみましょう。

オーナーは関係者を代表し、バックログを作成・維持します。中央の情報源として利益を反映し、次のスプリントに必要なアイテムを含めます。ニーズと事業目標を理解するために協力し、行動可能なプロダクトバックログアイテム（PBI）へ落とし込みます。

• Annual State of Agile Reportでは、調査組織の70%超が、スクラムや組み合わせ型を好んで使っており、バックログの普及を示しています。
• 同報告では、十分に詳細化したバックログを扱うことも含む、チームの管理のしやすさの向上が、アジャイル導入の主な五つの理由の一つです。
• Journal of Systems and Softwareの研究では、うまく管理すると、成功率が最大30%高まる場合があるとしています。

プロダクトオーナーの役割

強いリーダーシップ、ビジョン、優先順位の明確さ、市場動向と要件の情報が必要です。異なる要求のバランスを取り、目標へ集中します。最終的に、利用者が得るプロダクトとサービスの価値を最大化する責任があります。

開発チームとマスターも、作成と詳細化に積極的に関わります。現場の知見と資源を生かし、使命と各反復の方向性を保ちます。開発チームはオーナーと、スコープ、実現性、技術の詳細、日程を検討し、組み込める解決策を考えます。精度と、人間であるユーザーへの利点を高めます。

スクラムチームの参加

例えば、大きなデータベース変更が必要でも、今のスプリントでは実現できない場合、開発チームが伝えなければなりません。変更するか、オーナーの意見を踏まえて優先順位を調整します。正確さと適時の提供が重要な業界で、欠かせないプロセスです。

メンバーは、ユーザーストーリー（詳細： スクラムのユーザーストーリー）、技術検証のスパイク、テストで見つけたバグなど、全アイテムを見られる必要があります。大きな要件の中で、各項目が次のゴールにどう貢献するかを理解し、生産の流れとプロダクトの詳細を広く把握できます。

スクラムマスターは、必須のイベントを増やすことなく、詳細化を効果的にする助けとなります。相乗効果と協力を生かし、障害を除去しながら、効率的な目標達成を支えます。

各役割が、体系的に、互いに支え合って働くことが重要です。多様な業界で最終的なプロダクトを正確に届けるための解決策も含め、作成と詳細化の仕事を役割別に見てみましょう。

詳細化では、人を中心とした次のゴールの共通理解を目指します。不明点は開始まで待たず、早めに質問して、遅延の可能性を減らすことが大切です。

顧客や関係者など複数の情報源から反応が来たら、競合するニーズを管理し、目標に沿うユーザーの成果へ集中するのはオーナーです。開発チームは率直に対話し、現在のスプリントで各目標が達成できるようにします。

バックログは成功に必要な要素であり、全員が作成と詳細化へ積極的に参加します。明確な対話、透明性、協力が、うまく管理された生産ラインのような利点につながります。

明確なバックログが、価値を生むプロセスと、プロダクトの状態や成長の道筋を関係者に示します。プロダクトの詳細と、より大きな目標とのつながりが、詳細化を導きます。

作成と詳細化のプロセス

詳細化は、大きなものをより小さく正確に分け、定義し直す継続的な活動です。スプリント全体で行え、別の日程のイベントが必須なわけではありません。業界に必要な解決策を作り、プロダクトの正確さと有効性を高めます。

作成は要件の確立から始まります。準備の整ったチームが最終目標へ集中することで、利点を生かし、業界の需要に合うものを作れます。

チームが重視する基本的な実践の一つが、定期的なバックログのグルーミングです。 スクラムのグルーミング（バックログの詳細化）の会議 は、内容を最新で、適切に優先順位が付き、次のスプリントに備えた状態へ保ちます。効果的なバックログの礎です。

要件の確立

業務プロセスや想定する利用例から、必要な機能を引き出し、ユーザーのニーズを分析することから始めます。

要件を明確にすると、戦略目標と、成功する成果への方向性がそろいます。INVEST、すなわち独立性、交渉可能性、価値、見積もり可能性、適切な大きさ、テスト可能性は、ストーリーを書く際の確認に使えます。全アイテムに必須の形式ではありません。

顧客の調査やグループ討議、必要な非機能を指示するCTOやCEOなど、多様な情報源があります。ペルソナや重要な利用例を使うと、実際の状況を話し合いに持ち込め、要件収集を効果的に進められます。

収集後、具体的な手法で、バックログ内の優先順位を付けます（次節参照）。

優先順位付けの手法

顧客価値の最大化が主目的の一つであり、優先順位は極めて重要です。効果的な成果のため、次の手法を使えます。

戸棚の物から、一週間に必要そうなものを選んで手前に置き、あまり必要でないものを奥へ動かすことを想像してください。

• MoSCoW分析： 必須、重要、できれば欲しい、今回は対象外の四つに分ける、シンプルな方法です。
• 重み付き最短ジョブ優先（WSJF）： 遅延のコストを計算し、仕事の規模で割る方法です。
• 狩野分析： 顧客満足への影響に基づき、PBIの優先順位を付ける助けになります。
• 価値と複雑さの比較： 職能横断的なチームが評価した複雑さに対し、顧客にとっての価値を図に配置する方法です。

どの手法でも、メンバー同士が十分に協力し、必要なら関係者や顧客も加えるべきです。

ストーリーとタスクの作成

ストーリーは反復的に作り、全関係者の視点で何が必要かを捉えます。シンプルでも、必要な情報をわかりやすく伝えられる形式です。一方、タスクは、各側面を決められた期間内に実行できるかを具体的にします。

ユーザーストーリーの例です。

私は<利用者の種類>として、<理由>のために、<目標>を実現したい。

言い方はチームによって違っても、誰が、何を、なぜ求めるかを含めます。通常はユーザーの視点で書き、要件をすべて満たすのに必要な詳細を含めます。

各PBIのストーリーが決まったら、大きな仕事を実行可能なタスクへ分けます。各アイテムを、スプリント内に見積もり、完了できる、小さな仕事に落とし込む段階です。

適応と効果的な管理

アジャイルは、継続的な適応と、その時点の管理を重視します。スクラムでは、市場の反応を使い、仕事を可視化し、順序付け、適応させる、利用しやすいバックログで実現します。細かなタスクはスプリントバックログで管理します。職能横断的な意見を生かし、変わる要件に合わせて、継続的に詳細化できます。

顧客について知るたびに変化し、成長する、生きた文書だと考えてください。

透明性は、効果的な管理の基本です。全員がバックログを見られ、各項目の順序を理解できるようにします。開発チームと、詳細化で有益な意見を出すステークホルダーとの調整を助けます。

ただし、成功には、充実したバックログの詳細化だけでなく、プランニングに関わる主要な人たちの協力も必要です。そこで重要になるのが、スプリントのスコープの設定です。

スプリントのスコープを決める

厳しい期限内でスコープの変化に対応することは、重要な課題です。スコープの設定とは、境界を定め、開発の各段階で提供するものを特定し、全体の期間を慎重に決めることです。

例えば、ある機能に四週間かかるなら、一〜二回のスプリントで完成できる、二〜三個の小さな機能に分けます。提供の節目が小さくなることで、問題の早期発見とリスクの管理が容易になります。

プロダクトゴールの明確な目標に基づき、主要な関係者の十分な参加のもとで行います。スコープの設定時に「完成の定義」を明らかにすると、期間内に何を届けるかの期待を管理できます。

成功には、ロードマップを理解し、市場の需要と現実的な日程のバランスを取ることが必要です。原則に沿った、管理しやすく予測可能な進め方になります。

スコープを理解したところで、優先順位の変化への適応を見ていきましょう。

優先順位の変化に対応する

大きな課題の一つが、優先順位の変化です。進化とともに新しい機能や要件が生まれ、既存の計画を乱す可能性があります。継続的に確認し、変化を予測し、優先順位の変更がプロダクトゴールの達成能力を損なわないようにする必要があります。

例えば、オンライン学習サイトを開発し、一か月後に、他の基盤との連携を追加する必要に気づいたとします。適切に管理すれば機能を高められますが、今の仕事の流れを乱す可能性もあります。

その場合、反応を集め続け、レビューで成果を検査し、優先順位を調整します。レトロスペクティブは働き方を改善します。チームは、詳細化と計画の時間を十分に取れるよう、早く変化を予測する必要があります。

アジャイルのプロジェクトの成功への影響

成功は、バックログの項目を効果的に管理・優先できるかに左右されがちです。構造と管理が整うと、関係者からの見通し、効率、各スプリントの進捗の透明性が高まります。

価値の高いPBIの正確な情報があれば、管理側は、プロダクトゴールと会社の戦略の両方に合うものを見分け、安定した投資利益を得られます。必要な対応を定期的に知らせることで、関係者間の摩擦を減らし、変更も容易にします。

階層にかかわらず、価値に基づいて判断する人たちが、効果的に伝え合い調和するためには、バックログの重要性を理解することが出発点です。共通の目標へ、開発チームが効果的に協力できるようになります。

車のハンドルに例えてください。エンジンである開発チームも必要ですが、正しく進むには、方向を変える有効な仕組みが必要です。

チームとステークホルダーのための、バックログの質問と回答

バックログを準備するのは誰ですか？

通常はプロダクトオーナーが準備し、管理します。意見、要件、優先順位の変化に基づく、定期的な詳細化と更新も責任です。開発チームとマスターも意見を出せますが、内容と優先順位の最終的な権限はオーナーにあります。

バックログの大きさは、どのくらいですか？

複雑さとスコープによって違います。対応すべき機能、改善、修正を優先した動的なリストであり、大きさは固定されず、開発中に変わります。価値を最大限届けるため、積極的に管理し、優先順位を付けることが重要です。

どのくらいの頻度で見直し、更新しますか？

スプリント全体で見直し、更新します。重要な次の仕事を十分に理解した状態で、プランニングを始めるためです。最新の優先事項と要件を反映できます。Agile Allianceの研究では、頻繁に行うチームの成功率と生産性が高いとしています。継続的な見直しと更新は、成功に不可欠です。

管理上の、よくある課題は何ですか？

不適切な優先順位、曖昧な要件、ステークホルダーの管理などです。PMIの調査では、マネージャーの38%が、不明確または変化する要件を主な課題としました。Journal of Systems and Softwareの研究では、不十分な関係者管理が、詳細化の対立と遅延につながるとしています。安定し効率的に価値を届ける能力に影響する課題です。

適切に維持されたバックログの主要な要素は何ですか？

明確で優先順位の付いたストーリー、詳細な受け入れ基準、判断に役立つ場合の規模の見積もり、最新に保つ継続的な詳細化です。Scrum Instituteの調査では、十分に整備するチームは、生産性が22%高く、期限内に届けられる可能性が35%高いとしています。これらの要素の維持が重要です。

従来のプロジェクト管理の実施事項リストとは、どう違いますか？

通常固定的なリストとは違い、絶えず変化します。また、重要性と緊急性で機能を優先し、顧客価値の提供に集中します。従来のリストには、その顧客中心の考え方がない場合があります。McKinseyの研究では、効果的なバックログを使うプロジェクトは、従来の手法だけに頼る場合より、成功する可能性が28%高いとしています。

効果的な優先順位付けには、どんな戦略がありますか？

MoSCoW法では、今回のリリースに必須、重要、できれば欲しい、対象外に分けます。収益や満足への影響で並べる、事業価値の手法もあります。狩野モデルなら、顧客の好みや喜びに基づいて優先できます。研究では、価値ある機能の早期提供を助け、全体の成功率が最大30%向上するとしています。

チームとプロダクト価値における、スクラムプロダクトバックログの振り返り

バックログは、オーナーが整える、動的で優先順位付きの仕事のリストです。チーム、関係者、顧客の集合知を含み、仕事の内容とスコープ、段階的な価値への道筋を透明に示します。詳細化と反応の循環により、変わる要件へ適応し、顧客のニーズと方向性をそろえます。

効率的に価値を届けるチームには、スクラムプロダクトバックログの活用が重要です。 優先されたリストを維持すれば、影響の大きな仕事へ集中し、協力と生産性を最大化できます。継続的な学習と適応という考え方のもと、反応の循環を活用します。情報と仕事を磨くと同時に、ニーズへの理解も深まり、持続可能で価値を重視する歩みになります。

実践を続ければ、反復的なバックログが改善と成功へ導きます。お読みいただき、ありがとうございます！