モバイル開発におけるタスクグルーミング：概念、目的、実施プロセス

タスクグルーミングとは？

Backlog Grooming（整理）は、今後のスプリントのためにProduct Backlogタスクを準備するプロセスです。これは、Product Ownerと開発チームがタスクをレビューする会議です：要件を明確にし、Acceptance Criteriaを追加し、複雑さを評価し、依存関係とリスクを特定します。Scrum Guideには「グルーミング」という必須イベントはありません—これは、Sprint Planningでの不確実性を減らすためにScrumチームが採用する追加の実践です。推奨される頻度はスプリントに1回、所要時間は60分以内です。

「グルーミング」という用語は本質を反映しています：チームはバックログを「梳き」、古いタスクを削除し、不明確なものを明確にし、あまりに大きいタスクを分解します。モバイル開発では、プラットフォーム特有の事情によりグルーミングが特に重要です。AndroidタスクはiOSバージョンと複雑さが異なる場合があり、targetSdk、compileSdk、APIレベルの互換性を考慮する必要があります。グルーミングなしでは、Sprint Planningがカオスに変わります—チームが初めてタスクを見て、評価できず、不可測性とデッドラインの遅延につながります。

グルーミングの結果は、Sprint Planningに備えたいくつかのタスクです：これらには説明、Acceptance Criteria、評価があり、Definition of Readyを満たしています。Product Ownerは優先順位でタスクをグルーミングする必要があります：現在のスプリントに最も近いタスクが最も詳細になります。3–4スプリント先のタスクは、エピックレベルのみです。段階的整理技術（Progressive Refinement）：タスクがスプリントに近いほど、説明が詳細になります。現在のスプリントのタスク—完全な整理（AC、デザイン、API件書）。2スプリント先のタスク—ストーリーレベル（実装詳細なしのユーザーストーリー）。3+スプリント先のタスク—エピックレベル（名称とビジネス価値のみ）。

Definition of Ready：タスクがスプリントに備えているとき

Definition of Ready（DoR）は、Sprint Backlogに含められる前にタスクが満たすべき基準のチェックリストです。DoRは、Product Ownerとチームの間の契約です：POは開発に必要な情報がすべてわかっていることを保証し、チームはタスクを評価し完了できることを保証します。DoRは一般的なものではありません—各チームが独自の基準セットを定義します。DoRがなければ、不明確な要件を持ったタスクがスプリントに入ってしまい、再作業やデッドラインの遅延につながります。

モバイル開発の典型的なDoR：1）Acceptance Criteriaが記述されている（Given-When-Then形式）。2）UIタスクの場合、Figmaでデザインモックアップが用意されている（すべての状態：default、loading、error、empty state）。3）API件書が承認されている（OpenAPI/Swagger、リクエストとレスポンスの例）。4）ストーリーポイントの評価がある。5）他のタスクへの依存関係が特定されている。6）タスクが未完了の外部コンポーネントに依存していない。7）モバイル特有の要素：ターゲットOSバージョンの定義、feature flagの必要性、古いAPIレベルへのサポート。

タスク評価の手法

Planning Pokerは、グルーミングで最も人気のある評価手法です。各開発者は、フィボナッチ数（1、2、3、5、8、13、21）のカードデッキを受け取ります。POがタスクを提示し説明します。議論後、全員が同時にカードを示します。評価が大きく違う場合（例：3と13）、開発者は理由を説明して再投票します。繰り返しは合意が得られるまで続けられます。Planning Pokerの目的は正確な評価ではなく、タスクの理解の違いを明らかにすることです。

T-Shirt Sizingは、簡易的な評価手法です：XS（1 SP）、S（2）、M（3）、L（5）、XL（8）、XXL（13）。多くのタスクがあっておよそのサイズ様が必要な場合の初期バックログ整理に適しています。T-Shirt Sizingの後、次のスプリントのタスクについて、Planning Pokerでより正確な評価が行われます。Affinity Estimationは、数字を使わずにタスクを最も簡単なものから最も複雑なものまでテーブルに並べ、クラスターにグルーピングし、各クラスターに評価を与えるグループ整理技術です。

モバイル開発では、評価にプラットフォームの複雑さを考慮する必要があります。Androidタスクが5 SPと評価されるのに対して、同じタスクがiOSでは3 SPになることがあります（またはその逆）。これは正常です：異なるプラットフォームは実装の複雑さが異なります。ヒント：チームがクロスプラットフォームの場合は、プラットフォームごとに別々に評価してください。相対スケールを使用します：ベースタスク（例：テキストとボタンのある画面）= 1 SP。その他のすべては、それに相対して評価されます。Scrum.org（2025）によると、3—4スプリント後に、チームの評価精度は実際の複雑さの±20%に達します。

分解：大きなタスクの分け方

8 SPを超えるタスクは、より小さなタスクに分解すべきです。大きなタスクは1つのスプリントで完了できず、評価が難しく、進捗感が得られません。分解技術：水平レイヤー（UI → ViewModel → Repository → Network/DB）または垂直スライス（機能：1つの完全な画面）でタスクを分割します。水平分解はモバイル開発に向いています：サブタスク1 — UIレイアウト（XML/Jetpack Compose/SwiftUI）、サブタスク2 — ViewModel + State、サブタスク3 — Repository + Network、サブタスク4 — 単体テスト。

垂直分解は、ユーザーストーリーを独立した価値をもつ小さなストーリーに分けます。例：エピック「ショッピングカート」 → ストーリー1 「カートに商品を追加」、ストーリー2 「カートを表示」、ストーリー3 「カートから商品を削除」、ストーリー4 「購入手続き」。各ストーリーには自分のビジネス価値があり、独立してリリースできます。SPoK（Kanoによるストーリーポイント）：ストーリーをビジネス価値（Must-have、Should-have、Could-have）でランク付けし、価値の順に実装します。

グルーミングでの分解チェックリスト：1）タスクは8 SPより大きいか？ → 分解する。2）Acceptance Criteriaが定義されているか？ → ない場合は追加する。3）他のタスクに依存しているか？ → 依存関係を特定し記録する。4）不確実性を含むか？ → 主なタスクの前にSpike（調査）を追加する。5）デザインが必要か？ → モックアップの準備状況を確認する。INVESTルール：Independent（他のタスクから独立）、Negotiable（話し合い可能）、Valuable（ビジネスに価値がある）、Estimable（評価可能）、Small（小さい）、Testable（テスト可能）。タスクがINVESTを満たさない場合、スプリントの準備ができていません。

グルーミングのプロセス：ステップバイステップ

ステップ1：ウォーミングアップ（5分）。Scrum Masterがチームにグルーミングの目的とDoRを思い出させます。チームはボードを見て、POが議論されるタスクを示します。ステップ2：タスクレビュー（30分）。POが現在のスプリントの終わりから次のスプリントの始まりまでのタスクを順番に提示します。各タスクについて：名称、説明、Acceptance Criteria（あれば）、デザインリンク、API件書。チームは確認問いをします：「空の状態のモックアップはありますか？」「どのHTTPメソッドですか？」「iOSの最低デプロイメントターゲットは何ですか？」

ステップ3：評価（15分）。チームはPlanning PokerまたはT-Shirt Sizingでタスクを評価します。違いが2 SPを超える場合、理由を話し合って再投票します。ルール：タスクを評価できない場合（要件が不明確、デザインがない）、POに戻され、次のグルーミングで再度議論されます。不明な要素を含むタスクを評価しないでください—スプリントのミスにつながります。ステップ4：結果の記録（10分）。POはJira/Linearに評価を記録し、タスクの説明を更新し、優先順位を設定します。

グルーミングの結果：Sprint Planningに完全に準備できた3–7つのタスク（DoR、評価、デザイン、API付き）。POはバックログを更新します：古いタスクを削除し、重複を統合し、優先順位を調整します。重要：グルーミングはPOの仕事を終了させません—グルーミングセッションの間に、POは次のタスクを準備する必要があります。推奨されるペース：POがグルーミングのために3—4つのタスクを用意し、チームがそれらを取り組みます。バックログに50を超えるタスクがある場合、POはグルーミングの前に優先順位付け（MoSCoWまたはWeighted Shortest Job First）を行う必要があります。

グルーミングとSprint Planningの違い

グルーミングは準備です。コミットメントはありません—タスクは単に明確化され評価されるだけです。Sprint Planningはコミットメントです。チームはグルーミングで準備されたタスクから選択し、スプリント内で完了することを約束します。主な違い：グルーミングは特定のスプリントに縛られておらず（バックログ全体の整理）、グルーミング中にSprint Goalはなく、グルーミングはスプリント中のいつでも行えます。Sprint Planningはスプリントの開始時に実施され、常にSprint Goalを生成します。

グルーミングでは、タスクは評価されるだけで、スプリントには持ち込まれません。Planningでは、タスクは準備されたプールから選択されます。グルーミングがなければ、Sprint Planningに6–8時間かかります（4時間の代わりに）。なぜならチームが初めてタスクを見て、すばやく評価できないからです。80/20の法則：Sprint Planningの80%のタスクは完全に準備されている必要があり（グルーミングを経ている）、20%は新しいもの（緊急バグ、ホットフィックス）でもかまいません。Planningで20%を超える未評価タスクがある場合、グルーミングが不十分だったことを意味します。

グルーミングの一般的な誤り

誤り1：月に1回のグルーミング。チームは3—4スプリント分のタスクを蓄え、2時間ですべてを整理しようとします。結果：半分のタスクが未評価のままで、Planningが終日かかります。解決策：グルーミングは定期的であるべきです—スプリントに1回、60分間。多くのタスクがある場合は、スプリントの中間に2回目のグルーミングを追加してください。多くのタスクを浅く整理するより、少ないタスクを徹底的に整理するほうが良いです。ペース：1回のグルーミングで3—5つのタスクを、それぞれ完全な議論と評価を行います。

誤り2：コンテキストなしの評価。POがデザイン、API、ACなしで「ショッピングカート画面を実装」するタスクを提示します。チームは「目安で」13 SPと評価します。Planningで実際には5 SPであることが判明します（画面が簡単だから）。解決策：デザインやAPIがなければタスクは評価されません。POはグルーミングの前に材料を用意する必要があります。ルール：「モックアップなし= 評価なし」。例外：Spikeタスク—不確実性の調査、これらはデザインなしで別々に評価されます（調査の複雑さによって2–5 SP）。

誤り3：グルーミングがPlanningに変わる。チームが個人にタスクを割り当て、誰が何をするかを議論し始めます。解決策：グルーミングは明確化のためであり、割り当てのためではないことを思い出させます。割り当てはスプリント開始後のDailyで行います。グルーミングは「何をするか？」を考え、Planningは「いつするか？」を考え、Dailyは「誰がするのか？」を考えます。これらの問題を1つの会議で混合すると、それぞれの効果が減少します。Scrum MasterはPlanning類似の議論を止め、タスクの明確化に注力させる必要があります。

誤り4：技術負債を無視する。グルーミングでは新しい機能のみが議論され、技術的なタスクは無視されます。3—4スプリント後、技術負債が危機的なレベルに達します。解決策：各グルーミングで、少なくとも1つの技術タスクを評価する必要があります。比例：機能3つに対して技術タスク1つ。Tech Debt Ratioメトリックを使用します：スプリント内の技術タスクと機能タスクの比率。ターゲット値：0.25–0.3（技術負債に25–30%の時間）。比率が0.2を下回る場合、次のスプリントで開発スピードが低下します。