バックログはなぜ一つであるべきか？スクラムチームの適応力を因果ループで読み解く

バックログはひとつであるというスクラムの前提について探求します。

Transcript

1. バックログはなぜ一つであるべきか？ス クラムチームの適応力を 因果ループで読み解く Hiroyuki Honda(@hiroyuki810216) BIPROGY inc. 2025/08/30 スクラムフェス仙台 2025
2. 自己紹介 • 名前：本多裕之 • 所属：BIPROGY inc. アジャイル推進室 ◦ 発音は、びぷろじー ◦ 旧社名：日本ユニシス株式会社 • 業務： ◦ AXLabというサービスを提供。主に社内向けのアジャイルコーチ。 ▪ https://www.biprogy.com/solution/service/axlab.html ◦ 他には、社内勉強会主催 • メタファシリテーション1級 • NLPプラクティショナー受講中
3. Learning Outcome • 「バックログは一つであるべき理由」を構造的に理解でき、バックロ グ分割の影響を説明できる
4. Agenda • バックログがひとつとは？ • バックログの数がふえると？ ◦ Agileとは？ ◦ Orgtoporogyとは？ • バックログ数と適応力との関係を因果ループで見てみよう • まとめ
5. バックログがひとつとは？
6. まずは、スクラムガイドを見てみる • スクラムガイドにはプロダクトバックログは、It is single sourceという 記述がある。単一の情報源ということは分かる。 https://scrumguides.org/scrum-guide.html
7. バックログはひとつじゃない状況 （単一の情報源ではない状況）
8. コンポーネントチーム※で構成されるケース ※特定の機能とか技術コンポーネ ントだけを担当するチーム Ex：UIだけ、データベースだけ、 バックエンドAPIだけを専門にやる チーム
9. コンポーネントチームで構成されるバックログ
10. 事実上分かれている
11. チームに色を付けるとバックログは分かれてしまう • 工程で分ける • アーキテクチャで分ける • プロジェクトで分ける • エピックで分ける • バリューストリームで分ける • ドメインで分ける
12. でも同じバックログ※を見ていれば他のチーム の状況分かるからいいんじゃない？ ※同じJira、同じExcel、同じ壁
13. 同じバックログでもチームごと見るものが決まってしまえば、暗 黙的（Implicit）に異なるバックログになる。 ＝
14. バックログが1ファイルだったら他のチームのも見る？ • やらなくてもいい、知らなくてもいいなら見ない • 見たとしても本気で理解するか？ • コンポーネントチームなどに分けるという戦略は、前提としてスコー プを減らすという狙いがある
15. うちは1チームなので問題はないですね。
16. メンバーに役割を付与したら同じ話になりえる
17. バックログが分かれると何が悪いの？
18. Agileという言葉
19. Agileという言葉はマーケティングのためにつくられた • LeSSを考案者のひとりであるCraig Larman。 • Craig Larman曰く、Agileというキーワードを作ったのはマーケティ ングのため であった。 • Agileのほか、AdaptiveやFlexibleなどが候補に挙がった。 • AdaptiveはJim Highsmithがすでに使っていた。 • そして、Agileという言葉が選ばれた。
20. Agile=適応力 • Agile、Adaptive、Flexibleの3つの候補を考えると、適応する能力に 重きが置かれていることが読み取れる。 • Agileは単語は、適応より素早さというニュアンスが強い。 • Agileを学習している人であれば適応力が重要な要素であると理解 できるが、そうでない人にとって、Agileという用語をそのまま受け取 ると「早いんでしょ？」と理解するのは自然。 • マーケティングとしては大成功したアジャイルであるが、誤解を招き やすい言葉でもあると考える
21. 適応力とは何か？ Orgtoporogyを参考に考える
22. Orgtoporogyとは？（https://www.orgtopologies.com/） • Org Topologies（OT） は、組織のかたちを「仕事の範囲」と「スキルの範囲」とい う二つの軸で整理します。 ◦ 仕事の範囲（Scope of Work Mandate） ▪ どのくらいの範囲の仕事を任されているか。 ▪ （小さなタスクだけ／一部の仕事／製品全体 など） ◦ スキルの範囲（Scope of Skills Mandate） ▪ どのくらいスキル幅を持っているか。 ▪ （専門だけ／複数スキル／一連の価値提供を全部できる など） • この2軸を組み合わせて、組織を16種類のタイプに分類。 • 自分たちのチームや会社をマップに置くことで、「今どんな形なのか」を分かりや すく表せるのが特徴です。
23. Orgtoporogyの図
24. 横軸の説明：スキルの範囲（Scope of Skills Mandate） • 左の Functional（機能特化） は単一の専門スキルに限られ、他チームへの依 存が大きい状態です。 • そこから Multi-skill（多能工）、End-to-End（端から端まで） と進むにつれてスキ ルの幅が広がり、依存を減らして自己完結できるようになります。 • さらに Expanding、Unbounded では、新しい領域を柔軟に取り込み、スキルの 制約に縛られないチームとなります。 • つまり横軸は、他チーム・組織への依存度が高い専門チームから、クロスファ ンクショナルで自己完結できるチームへ進化する流れを表しています。
25. 縦軸の説明：仕事の範囲（Scope of Work Mandate） • 縦軸は、チームがどれだけ広い範囲の仕事を任されているか を示しています。 • 下の Tasks（タスク単位） は小さな作業をこなすだけの状態です。 • そこから Capabilities（能力単位）、Partial Business（一部事業） と範囲が広が り、やがて Whole Business（全事業） を扱えるようになります。 • 最上位の Unbounded（無制限） では、事業や組織の枠を超えた範囲を担うこと も可能です。 • つまり縦軸は、個別作業に閉じた状態から、事業全体を任される状態へと広 がっていく流れ を表しています。
26. Scope of Skills Mandateが狭いとチーム間で依存が生まれ、 フローが遅くなる。この状況の適応力は高い？低い？
27. Scope of Work Mandateが狭いと優先順位通りに作れない この状況の適応力は高い？低い？
28. バックログの増える要因
29. バックログが増える要因は、分業が進むこと
30. 分業というアプローチは、とても身近で安心感が ある。生産性という言葉も魅力的だが適応力を 損なうことにつながる。 適応力を向上させるには、Scope of Skills Mandateに加えてScope of Work Mandateの 考慮が必要となる
31. 【参考】Orgtoporogyは最近Updateされました 表現がCostからMandate(委任された権限、指令、範囲）に 縦軸： 製品全体を学習する流暢さ switching costs 横軸： 単一の顧客価値アイテムを 提供する流暢さ transactional costs
32. バックログの数と適応力の因果関係を探求する
33. 因果ループの説明 • 因果ループは、要素間を矢印で結び、要素の増減（因果）を表すモ デリング手法。
34. 【参考】モデリング諸注意 • 「All models are wrong, but some are useful.」 すべてのモデルは間違っているが、役に立つものもある。 • あるチームで作成したモデルを、別のチームに見せても理解される 可能性は低い。 • モデルを作る過程（対話、思考）での気づき、発見、共通理解、学習 が大事。
35. 前提となるコンテキスト • 複数チームのケースを想定 • 黄色の付箋：通常の変数 • ピンクの付箋：適応力に関する変数
36. 【ワーク】 因果ループを作 ろう！ 問題 要素間に線を つなぎ＋かーを 入れてモデルを 作ってみよう
37. Step1 バックログの数 • バックログの数 • PBIの個数ではなく、PBLの個数（リストの数）
38. Step2 チームが 熟知している PBIの 割合 • 例えば、PBLが4個で40個PBIがあったとき に、チームが熟知しているPBIは10個なら割合 は25％ • バックログが複数増えていくとどうなります か？ • バックログが10個になったら？バックログが1 個になったら？
39. Step3 チームが 熟知している PBIの 割合 • バックログの数が増えると、チームが熟知して いるPBIの数は減る。 • ひとつのチームが見るバックログは大体ひと つ。バックログが増えたら、熟知している PBI の数は減る。
40. Step4 作業アイテムに関する知識がどれだけチーム内・組織内で分断さ れているか • チームが熟知しているアイテムの割合が増えたとき、チーム内や組 織内で情報の分断が生まれるでしょうか？ • また、情報の分断が増えていくと、チームが熟知しているアイテムの 割合はどうなるでしょうか？
41. Step5 作業アイテムに関する知識がどれだけチーム内・組織内で分断さ れているか • チームが熟知しているアイテムの割合が増えたとき、チーム内や組 織内で情報の分断は減る。 • また、情報の分断が増え ていくと、チームが熟知しているアイテムの 割合は減る。
42. Step6 組織、チーム全体での方向転換に対するチームの適応 力 • チームが熟知しているPBIの割合が増えると、方向転換に対応する 能力、適応力は増えますか？減りますか？
43. Step7 組織、チーム全体での方向転換に対するチームの適応 力 • チームが熟知しているPBIの割合が増えると、方向転換に対応する 能力、適応力は増える
44. Step8 各スプリントで取り組まれたアイテムのうち、全体最適 の観点で最も価値が高いと仮定されたアイテムの割合 • 全体最適の観点（ビジネス価値、POの戦略など）を反映したアイテ ムの取り組めているか？という点 • 方向転換に対応する能力、適応力は増えたら、 全体最適の観点を 反映したアイテムの取り組める割合は？
45. Step9 各スプリントで取り組まれたアイテムのうち、全体最適 の観点で最も価値が高いと仮定されたアイテムの割合 • 方向転換に対応する能力、適応力は増えたら、 全体最適の観点を 反映したアイテムの取り組める割合は増える。
46. Step10 会社の収益 • 全体最適の観点を反映したアイテムの取り組める割合は増えたら 、 会社の収益はどうなるか？
47. Step10 会社の収益 • 全体最適の観点を反映したアイテムの取り組める割合は増えたら 、 会社の収益は増える。 • 注：POの能力など様々な変数の影響は考慮してない
48. Step11 単一のチームが、自分たちが全体最適で見ると価値 の低いアイテムに取り組んでいる可能性があることに気づく確 率 • バックログの数が増えたら 、チームは価値の低いアイテムを取り組 んでいることに気づく確率はどうなる？
49. Step12 単一のチームが、自分たちが全体最適で見ると価値 の低いアイテムに取り組んでいる可能性があることに気づく確 率 • バックログの数が増えたら 、チームは価値の低いアイテムを取り組 んでいることに気づく確率は減る • ※チームの能力など様々な変数の影響は考慮してない •
50. 【モデル例】 因果ループを作 ろう バックログの数 が増えると適応 力が下がる
51. おまけ
52. 大規模フレームごとのバックログの扱いは違います • LeSS ◦ バックログはひとつ ◦ LeSS HugeはAreaごとにバックログが分かれる • Nexus ◦ バックログはひとつ • Scrum@Scale ◦ 協調するスクラムチームごとにバックログをもつ • SAFe ◦ バックログは複数種類ある 各フレームには特性がある。バックログの取り扱いは特性の１要素すぎない。組織がど のような体制を目指して、どのように達成しようとしているのか を踏まえて選定すること が重要。 https://www.amazon.co.jp/dp/4297136619 https://framework.scaledagile.com/ https://www.amazon.co.jp/dp/4802079117
53. まとめ
54. 今日お伝えしたこと • 複数バックログのケース • バックログが分かれる弊害 • Agileの成り立ち • Org Topologies（OT）での整理 • 横軸：スキルの範囲（Functional → Multi-skill → End-to-End → Expanding） • 縦軸：仕事の範囲（Tasks → Capabilities → Partial Business → Whole Business） • 因果ループでの分析
55. 待て待て、事業全体とか、そんなに沢山のことを は覚えられないよ。 忙しいんだよ私たちは！
56. ”スクラム”の源流 • “スクラム”と言っている チーム全体で一丸となるために バックログの数はいくつが良い？ • “Multi learning”と言っている 様々なことを学習することを 前提としている https://hbr.org/1986/01/the-new-new-product-development-game
57. おしまい