アジャイル開発を学ぶ
用語
- マスターストーリーリスト（プロダクトバックログ）
プロダクトで実現したい価値を優先順位付きで並べた一覧。スクラムでは最重要の管理対象。 - ユーザーストーリー
「誰が」「何を」「なぜ」したいかを短文で表現した要求。例：ユーザーとして、履歴を確認したい。過去の作業を振り返るため。 - フィーチャー
ユーザーに価値を届ける機能単位。複数のストーリーで構成されることが多い。 - エピック
大きすぎて1スプリントで完了しない要求。分割して複数のストーリーに落とし込む。 - イテレーション（スプリント）
1〜4週間程度の固定期間で開発と検証を回す単位。 - ベロシティ
1スプリントで完了できた作業量（ストーリーポイントなど）。将来計画の参考値として使う。 - スコープ
その期間で「何を作るか」の範囲。期間固定・品質固定の中で調整対象になりやすい。 - スクラム
アジャイルの代表的フレームワーク。役割・イベント・成果物を最小限に定義し、経験主義で改善を回す。 - プロダクトオーナー
価値の最大化に責任を持つ役割。バックログの優先順位を決める意思決定者。 - バーンダウンチャート
残作業の推移を可視化するグラフ。進捗の遅れや計画の過不足を早期に検知できる。 - カンバン
作業の流れ（ToDo/Doing/Done）を可視化し、WIP制限で詰まりを減らす手法。 - インセプションデッキ
プロジェクト開始時に認識をそろえるための10の問い。目的・制約・優先順位の合意形成に有効。- 我々はなぜここにいるのか？
- エレベーターピッチ
- パッケージデザイン
- やらないことリスト
- 「ご近所さん」を探せ
- 解決案を描く
- 夜も眠れない問題
- 期間を見極める
- 何を諦めるのか
- 何がどれだけ必要か
スクラムの基本
スクラムは、変化の多い開発で価値を継続的に届けるための軽量なフレームワークです。
ポイントは「最初から完璧な計画を作る」ことではなく、「短いサイクルで作って学び、次に活かす」ことです。
スクラムは主に次の要素で構成されます。
- 役割（Accountabilities）
- プロダクトオーナー：何を作ると価値が出るかを決める
- スクラムマスター：スクラムが機能するように支援する
- 開発者：実際に価値を実装して届ける
- イベント
- スプリント：一定期間で成果を出す箱
- スプリントプランニング：何を作るか決める
- デイリースクラム：進め方を毎日調整する
- スプリントレビュー：成果を確認し、次の学びを得る
- レトロスペクティブ：進め方そのものを改善する
- 成果物（Artifacts）
- プロダクトバックログ
- スプリントバックログ
- インクリメント（動作する成果）
また、スクラムは経験主義（透明性・検査・適応）を基盤にしています。
計画と実績のズレを隠さず見える化し、ズレに素早く対応することで、結果として品質とスピードを両立しやすくなります。
スクラムの方法論
スクラムは「手順書を厳密に守る方法論」というより、原則に沿って運用を最適化するフレームワークです。
実務では以下の順で導入すると失敗しにくいです。
- 価値の定義を明確にする
- 何ができれば「成功」かを、POと関係者で合意する
- バックログを小さく分割する
- エピックをユーザーストーリーに分け、完了条件（DoD）を明確化
- 短いスプリントで回す
- まずは2週間を目安にし、レビューでフィードバックを得る
- 計測して改善する
- ベロシティ、リードタイム、バグ件数などを継続観測する
- プロセスを定期的に見直す
- レトロスペクティブで「次スプリントで試す改善」を1〜2個に絞る
重要なのは、形式だけスクラムにしないことです。
イベントをこなすだけでは成果は出ません。意思決定の速さ、優先順位の明確さ、改善サイクルの継続がセットで必要です。
PMBOK第7版
PMBOK第7版は、従来の「プロセス中心」から「原則・価値提供中心」へ重心が移っています。
この考え方はアジャイルと相性が良く、次の点で補完関係にあります。
- 価値志向：成果物そのものより、ビジネス価値の創出を重視
- テーラリング：プロジェクト特性に応じてやり方を調整
- 不確実性への対応：計画固定より、学習しながら適応
- ステークホルダー重視：レビューと対話を通じた期待値調整
つまり、PMBOK第7版はウォーターフォール専用ではなく、アジャイル実践にも十分使えるガイドです。
スクラム運用にPMBOKの視点（リスク、ガバナンス、価値測定）を加えると、現場と経営の会話がつながりやすくなります。
デジタル庁「アジャイル開発実践ガイドブック」
デジタル庁のガイドブックは、公共領域も含めた実践で役立つ観点がまとまっています。
特に参考になるのは次のポイントです。
- 利用者中心で要件を組み立てる
- 仕様先行ではなく、ユーザー課題を起点に優先順位を決める
- 小さく作って早く検証する
- 一括開発より、仮説検証を繰り返して確実性を上げる
- 発注側と受注側が同じゴールを見る
- 契約・体制・レビュー運用をアジャイル前提で設計する
- ドキュメントは必要十分に保つ
- 監査・説明責任を満たしつつ、開発スピードを落とさない
実務では、スクラムのイベント運用にこのガイドの観点を重ねると、
「スピードを出しながら説明責任を果たす」バランスを取りやすくなります。