アジャイル・スクラム開発の進捗統制とバーンダウンチャート

ビジネスの不確実性が高まる中、要求の変化に柔軟に適応する「アジャイル・スクラム開発」を採用するプロジェクトが急増しています。

しかし、アジャイルは「事前の計画や進捗管理が不要な自由勝手な開発」ではありません。むしろ、短いスプリント（1〜2週間）ごとに厳格な規律（プラクティス）を守り、「ベロシティの測定」や「バーンダウンチャート」を通じて科学的に進捗を統制することが求められます。高度試験の午後でも、スクラム特有のメトリクスと障害解決に関する出題が定着しています。

1. スクラム開発のコア指標と成果物判定

2. バーンダウンチャートの典型的な異常パターン

• 【水平停滞型（水平線が続く）】：スプリント中盤になっても残量が減らない。タスクの粒度が大きすぎる、あるいはチームメンバーが個別のストーリーを並行してつまみ食いし、どれも「完成」に到達していない（WIP過多）。

• 【突然急落型（最終日に垂直落下）】：スプリント最終日のレビュー直前に一気にゼロになる。テストやレビューを最終日に後回しにしており、潜在バグの先送りが疑われる。

• 【右肩上がり型（残量が増加）】：スプリント進行中に新たなタスクや仕様変更が勝手に追加され、スコープが膨張している。

3. 【実戦記述演習 問1】バーンダウンチャート停滞の原因と是正策

【シナリオ背景】FinTechベンチャーV社では、個人資産管理アプリの新機能開発（スプリント期間2週間、チーム規模5名）をスクラムで進めている。第3スプリントの第6日目（全10営業日中）の朝会において、スクラムマスターから以下の報告があった。

スプリント3の状況：
・コミットしたストーリー数：4件（合計20ストーリーポイント）
・第6日目時点の完了ストーリー：0件（残余ポイント：20ポイントのまま水平推移）
・各開発者の作業状況：
  - 開発者A：ストーリー1のフロント画面実装中（80%）
  - 開発者B：ストーリー2のAPIロジック実装中（70%）
  - 開発者C：ストーリー3のDBクエリ作成中（60%）
  - 開発者D：ストーリー4の外部連携調査中（50%）
  - 開発者E：各ストーリーの単体テスト環境整備中

設問1：スプリント中盤まで1件のストーリーも完了していない原因を開発者の作業スタイルの観点から分析し、残余期間で完了数を最大化するためにチームが取るべき処方箋を35字以内で述べよ。

【模範解答】

並行作業を制限し、単一ストーリーにメンバーを集中させて順次完成させる。（36字）

解説と採点基準（配点：10点）

• 出題意図：WIP（仕掛かり作業）の制限（Swarming / ペアプロ / モブプロ）により、「未完了の山」を排して確実に「Done」を積み上げるアジャイルの原則を問う。

• 加点キーワード：『並行作業（仕掛かり/WIP）の制限・排除』（4点）、『特定ストーリーへのリソース集中/共同作業』（4点）、『順次完成（Doneの達成）』（2点）。

• 減点対象：「全員で残業して4件すべて終わらせる」（持続可能なペースに反するため減点）。

4. 【実戦記述演習 問2】ベロシティ低下時のキャパシティ見直し

【シナリオ追加背景】第3スプリント終了後、チームのベロシティは過去平均の20ポイントから12ポイントへと急落した。原因をレトロスペクティブ（振り返り）で分析したところ、新技術の採用に伴う技術的負債の解消と、新人メンバーの教育に多くの工数が割かれたためであった。

設問2：次回スプリント計画において、PM（またはプロダクトオーナー）がコミットする作業量を決定する際に守るべき原則を35字以内で述べよ。

【模範解答】

直近の実績ベロシティに基づき、チームの実行可能容量に合わせて計画する。（36字）

解説と採点基準（配点：10点）

• 出題意図：願望や過去最高値ではなく、「直近の現実的な計測値（Yesterdays Weather）」に基づいてスプリントバックログを選択する規律を評価する。

• 加点キーワード：『直近実績ベロシティに基づく』（5点）、『チームの実行可能容量（キャパシティ）に合わせる』（5点）。

• 減点対象：「20ポイントに戻すようチームに努力を求める」（精神論であり0点）。

5. まとめ：アジャイル統制チェックリスト

• □ 完成の定義（DoD）に、コードレビュー、自動テスト合格、受入基準クリアが含まれているか？

• □ スプリント実行中に、プロダクトオーナーや外部から割り込みタスクが追加されていないか？

• □ デイリースクラム（朝会）は進捗報告会ではなく、「困りごと（インピーディメント）の共有と除去」の場になっているか？