👀概要
パーソルホールディングス デジタル開発部 SBUデジタル開発室 の山中です。
一応スクラムマスターのはしくれです。
本記事は、実際の開発プロジェクトにおいて自身が経験、検討したことをベースに、プロダクトバックログ戦略としての「型」（あくまで私が考える推奨事項です）と、その背景にある考え方を整理した内容になっています。
これから新しくPoCをスクラムで始めようという方や、バックログの設計に悩まれている方に対して、ほんの少しでも参考になれば幸いです。
なお、具体については、実例には寄せすぎず、再現性のある（ありそうな形）に一般化しています。
👨👩👧👦対象者(Who)
- スクラムのバックログの役割について、もう少し理解を深めたい方
- PoCをスクラムで進めるときの考え方を知りたい方
- チーム単位でのタスク分担がうまくいかない経験をお持ちの方
- プロダクト開発前提の「DoD（Doneの定義）」をそのままPoCに当てはめることに違和感がある方
🗒️目次
- 分業構造（コンポーネントチーム）でもPoCの学びを止めないために
- PoCで「検証」が後ろ倒しになる構造
- コンポーネントチーム編成で起きがちな「ズレ」
- バックログを「タスク管理」から「検証可能な価値の管理」へ
- バックログの骨格
- 親PBIの切り方
- 子PBI（サブタスク）の切り方
- PoC版DoD
- Integration / Validation の置き方
- 運用リズム
- まとめ
📝 内容
1. 分業構造（コンポーネントチーム）でもPoCの学びを止めないために
通常、PoCでは、実装の完了そのものよりも、仮説を検証し意思決定を前に進められたかどうかの 学び が成果になります。
一方で、｛フロント / AI（バックエンド） / インフラ｝のように専門性が分かれたコンポーネントチーム編成では、各チームの進捗が別テンポになりやすく、学びの回転が落ちることがあります。
本記事では、そういったコンポーネントチームでも「設計・実装・検証」を同じリズムで回せるように、バックログを 「検証可能な価値の管理」 として設計する「型」を整理しています。
扱う範囲は以下です。
- PBIの階層設計（テーマ → シナリオ → 親PBI → 子PBI）
- PoC版DoD（Doneを「学べた」に寄せる）
- Integration / Validation の置き方（最後に詰まないように）
- 運用リズム（検証をスプリントに埋め込む）
PoCで難しいのは、作ること自体ではなく「学びを回し続けること」です。
そもそも、なぜ学びが止まるのでしょうか？
多くのPoCで学びが止まる背景には複数の要因がありますが、特に影響があるのが、バックログが「検証」を前に進める形に設計されていないことです。
たとえば "動くものは増えるのに、判断が増えない" という状態です。
補足：コンポーネントチームとフィーチャーチーム
スクラムのチーム構成はスクラムガイドに明記されているようにフィーチャーチームであることが前提になっています。
そして、チームスケーリングは、LeSS（Large-Scale Scrum: 大規模スクラム）で代表されるようにフィーチャーチームによるスケーリングが推奨されることが多いです。
こうした前提があるものの、特定のスキルセットが必要となったり、単純にプロジェクトの人数を増やそうとすると、組織の都合上、どうしてもコンポーネントチームによる体制になってしまうケースが少なくありません。
そのため、今回は「分業構造でも学びを落とさない」ための工夫にフォーカスしてみました。
図1. コンポーネントチームとフィーチャーチーム（構造の違い）
2. PoCで「検証」が後ろ倒しになる構造
現場では、バックログを「検証可能な価値の管理」にしたいと思っていても、いつの間にかタスク列挙に引っ張られてしまうことが往々にしてあります。
PoCは不確実性が高く、最初から検証の設計を完全に決めきれません。
そして途中で「仮説」「評価軸」「必要データ」「仕様」が動きます。
こうした状況で分業がベースになっていると、各チームは「今スプリントで進められる作業」を優先して可視化しがちで、結果としてバックログが「作業の進捗管理」としての単なるタスク管理に寄っていってしまいます。
その結果、次のような状態が起きがちです。
- 作業は進むのに、検証が進まない（"動くものは増えるのに、判断が増えない"）
- 検証が後回しになる（スプリント終盤に評価が残って終わらない）
- データ準備・評価指標・計測が宙に浮く（誰のタスクにも乗らない）
こういった「後ろ倒し」の状態になることを防ぐために、PoCにおける最適な課題設定は、「何を作るか」だけではなく、このスプリントで何を検証し、どんな判断を下すかです。
これをPBIに埋め込めるかがカギになります。
そしてこの「後ろ倒し」は、専門性で分業しているほど増幅します。
次に、分業（コンポーネントチーム）で起きがちなズレを具体化します。
3. コンポーネントチーム編成で起きがちな「ズレ」
コンポーネントチームは専門性を活かせる一方で、バックログ設計を誤ると「ズレ」が顕在化します。
- Doneの感覚が揃わない： UIは動くが、AIは暫定。インフラは未統合。結果として「完成した気がする」が検証できない。
- 粒度が揃わない： フロントは1日〜2日単位、AIは実験が1週間単位、インフラは調整待ちが出るなど、テンポがズレる。
- 依存関係が見えにくい： 「相手待ち」がバックログ上で表現されず、スプリント後半で合流失敗する。
このズレを「個々の頑張り」で吸収しようとすると、会議が増え、摩擦が増え、学びの回転が落ちます。
ここでの一番の問題は、ズレが起きること自体ではなく、ズレが バックログ上で吸収されず にスプリント、またはスケジュールの終盤へ持ち越されることです。
これを防ぐには、ズレが起きる前提でバックログに吸収設計を入れるのが筋が良いです。
そしてそのためには、バックログの役割を「タスクの棚卸し」ではなく、検証と意思決定を前進させることが出来る形に再定義する必要があります。
4. バックログを「タスク管理」から「検証可能な価値の管理」へ
PoCでのバックログは「忙しさを可視化するもの」ではなく、検証と意思決定を前進させる装置であるべきです。そのために、親PBI（ユーザーストーリー）を「成果物単位」ではなく 「検証単位」 として定義します。
親PBIに最低限入れるべき情報は3点です。（具体的な設計、Howについては次章以降）
- 仮説：何が成り立つと期待しているか
- 検証方法：どう確かめるか（データ・計測・比較・手順）
- 判定基準：OK/NG/保留をどう決めるか（成功/失敗/境界/次アクション）
Done = コードが書けた ではなく、Done = 意思決定に必要な材料が揃った です。
ただし、検証単位を定義しても、複数チームが別々に解釈するとすぐ崩れます。そこで、検証単位が自然に揃うように、バックログ自体の骨格 を先に決めます。
5. バックログの骨格
複数チームでテンポを揃える鍵は、バックログに 「共通言語」と「合流点」 を仕込むことです。
それをわかりやすく階層化した例が以下です。
- テーマ：狙う価値（何を良くしたいか）
- シナリオ：現場の一連の流れ（チーム間の「共通言語」）
- ユーザーストーリー（親PBI）：検証単位（仮説・検証・判定）
- サブタスク（子PBI）：領域別の作業（フロント/AI/インフラ/データ/評価…）
特にシナリオを挟むと、各チームの議論が「最終的に現場でどう使われるか」に接続されやすくなり、Doneや粒度のすり合わせが成立しやすくなります。
ここでいう合流点とは、各領域の作業が最終的に「統合」され、「検証（判定）」まで到達するためのタスク（Integration/Validation）です。
図2. バックログ階層（テーマ→シナリオ→親PBI→子PBI）
このあとは、親PBIをどう切るかが非常に重要になってきます。
6. 親PBIの切り方：検証から逆算する
ここからは「検証単位にする」を実務で成立させるための具体手順になります。
まずは親PBIの切り方ですが、実はここが一番つまずきやすいポイントです。
実際の開発現場では、作りやすさや見通し、手戻りへの不安から、検証単位で切る判断が難しくなりがちだからです。
そのため、適切な切り方をチームで合意できるよう、十分にすり合わせる必要があります。
親PBIを検証単位にするための、実務的なテンプレは以下のようなものが良いと思います。
親PBI作成テンプレ
-
検証したい問い（＝仮説）または仮説の入り口を書く
例：「このAI要約は、シナリオ○○○で「判断」に使えるか？」 -
判定基準を書く
例：「A条件ならOK / B条件ならNG / 境界は保留で追加実験」 -
検証に必要な最小の条件を決める
例：UIは簡易でよい、ログは必須、評価データは最低N件、など -
それを満たす形で 親PBI（検証単位） を定義する
よくあるアンチパターン
-
「画面を作る」「APIを作る」「モデルを作る」というような機能で切ってしまう
→ 統合・検証が後工程に押し出され、PoCの目的（学び）が遅れます。 -
「精度を上げる」「改善する」など、アウトカム/学習目標が曖昧なまま親PBIにする
→ 何をもってOK/NGか（判定基準）が書けず、評価データや計測も決まらないため、結局「作業の継続」になって検証と意思決定が後ろ倒しになります。
親PBIを検証単位にできたら、次は分業です。
ここで大事なのは、領域ごとに分けても最後に検証へ合流するように、子PBIのDoneを 「合流条件」 に揃えることです。
7. 子PBI（サブタスク）の切り方：分担しても検証に収束させる
一般的にPBIは価値をベースに縦に切ることを推奨されますが、ここでは子PBIは領域別に切ってOKです。
ただし、重要なのは 親PBIの検証へ合流する条件 を揃えることです。
子PBIの設計チェックリスト（推奨）
- 受け渡し条件が明確か（入出力、環境、データ、再現手順）
- 依存が最小化されているか（スタブ・モック・暫定I/Fで先行できるか）
- 合流点がバックログに存在するか（Integration / Validation が「別枠」※ で置かれているか）
- Doneが検証に寄与しているか（作業完了ではなく検証準備完了になっているか）
※子PBI（領域作業）とは別に、親PBIのDoneに必要な合流・検証作業として明示する、という意味です。
子PBIに含まれる作業カテゴリの例
- フロント：入力導線、表示、ログ表示、再現手順のUI
- AI/BE：推論I/F、プロンプト/設定、評価スクリプト、評価データ整備
- インフラ：環境、権限、デプロイ導線、監視・ログ収集
- データ/評価：ケース定義、正解データ、境界条件、比較対象
重要なのは「フロント/AI/インフラがそれぞれ何を作るか」ではなく、最終的にIntegration/Validationへ合流できる状態（入力・出力・環境・再現手順・計測）が揃うことです。
そのため、子PBIは成果物名だけでなく「合流条件（何が揃えば次へ渡せるか）」まで含めて書くことを推奨します。
しかし、このままでは不十分で、Doneの基準がチームごとに違うと、合流してから「やっぱり足りない」が発生してしまうのです。
そこでPoCでは、完成度の高さよりも 学べる最低条件 を揃えるDoD（PoC版）を先に定義します。
8. PoC版DoD：Doneを「動いた」から「学べた」へ
PoCでDoDが曖昧だと、各チームのDoneが揃わず、検証がやり直しになったりすることがあります。
推奨は、親PBIに対して PoC版の最小DoD を先に決めることです。
PoC版最小DoDの例
- 再現手順（誰でも追える）
- 計測/ログ（何が起きたか追える）
- 評価結果（定量＋定性所見）
- 制約条件（成立条件・前提）
- 次アクション（改善案 or 結論）
DoDは厳しくし過ぎると速度が落ちるので、「Mustだけ先に決める」 → 必要に応じて追加が運用しやすいです。
もし運用が可能であれば、子PBI（サブタスク）側に「親PBIのDoDを満たすためのサブDoD」をぶら下げると更にブレが減ります。
これでPoC版DoDとして「学べる最低条件」を揃えることが出来ました。
しかしこれでもまだ足りません。
統合（Integration）と検証（Validation）を適切に設定できないと、また同じ場所で詰まってしまいます。
9. Integration / Validation の置き方：最後に詰まないために
コンポーネントチームの典型的な事故は「統合と検証が終盤に寄る」ことです。
そうならないためには、Integration/Validationを 親PBIの一部 としてバックログに埋め込みます。
ここで大事なことは、「作業」ではなく 「検証の必須要素」 として扱うことです。
「作業」として独立させてしまうと、価値（学び）に繋がらないタスクとして優先度が低く扱われやすくなってしまうからです。
推奨パターン
- 親PBIごとに、Integrationタスク と Validationタスク をセットで持つ
- スプリント内に「検証会（レビューを兼ねる）」を組み込む
- 統合は「薄く早く」行う（暫定I/Fで先につなぐ）
よくあるアンチパターン
- スプリントやマイルストーンの最後にまとめて統合、検査
→ 不整合や問題が見つかる → 再検証が間に合わず、結論が出ない
ただし、Integration/Validationを「置いたつもり」でも、リファインメントやデイリー、レビューの運用が従来のままだと、結局後ろ倒しに戻ります。
そのため、最後に、検証が毎スプリント自動で発生するように、運用リズム側の設計も押さえます。
10. 運用リズムの設計
ここで扱うのはスクラムイベントの解説ではなく、「検証が毎スプリント確実に発生し、結論が出る」ための運用（リズム）の設計です。
特にレビューは「デモ会」ではなく「検証会」として扱うのが、PoCでは効果的です。
- リファインメントで 仮説・検証・判定基準 を先に書く
- プランニングで、このスプリントで 「何を学ぶか」 を明文化する（→スプリントゴール）
- デイリーで 依存・合流点・検証準備 をチェックする（進捗よりも「合流の危険」を見る）
- レビューを デモ会（動作披露） で終わらせず、検証会 として運用する
- レトロで「学びが回ったか」を振り返る（作業量ではなく 意思決定が進んだか）
最後に、本記事で伝えたい要点となります。
11. まとめ：編成の是非より「型でデメリットを吸収する」
ここまでに記載した内容は、すべて 「バックログの型」 に関する内容となります。
これらはチーム編成を理想形に寄せるための整理ではなく、現実の分業構造のままでも 学びを回し続けるための「吸収設計」 です。
コンポーネントチームにはデメリット（ズレ・依存・待ち）があり、放置するとPoCの学びが分断されます。
しかし、バックログを「検証可能な価値の管理」として設計し、DoD・Integration/Validation・運用リズムまでを 状況に応じた適切な「型」 にすることで、複数チームでも学びの回転を維持しやすくなります。
重要なのは「どのようなチーム編成が正しいか」ではなく、起こりうるデメリットを先に見立て、運用設計として埋め込むことです。
PoCを「作って終わり」にしないために、もし何かを変えたいと思っているのであれば、まずは親PBIを検証単位で定義するところから始めてみるのはどうでしょうか？
分業構造によるチーム編成はどうしても発生します。
だからこそ、分業のデメリットを「運用の型」として吸収し、PoCの学びを止めない仕組みを持つことが、現場では最も効果的なやり方だと思います。