プロジェクト管理のための手法、アジャイルとそれを使ったツールの紹介を今回と次回にわたって行います。
目次
■アジャイル開発
アジャイルは、今や、ソフトウエア開発プロジェクトの大半が活用している概念です。
以下にその概要をメモにまとめてみました。
アジャイル開発の概要
- 目的：変化に強く、価値を早く継続的に届けること。段階的（イテレーション）にソフトウェアを作り、頻繁にリリース・検証してフィードバックを反映する。
- 特徴：短い反復（スプリント）・顧客との密な協働・動くソフトウェアを重視・変更を歓迎。
代表的フレームワーク
- Scrum（最も普及）: 役割（Product Owner, Scrum Master, 開発チーム）・スプリント（通常1〜4週）・定期イベントが特徴。
- XP（エクストリーム・プログラミング）：ペアプログラミング、TDD、継続的インテグレーションなど実践的技術に重心。
主な役割
- Product Owner (PO)：プロダクトの価値最大化責任。プロダクトバックログの優先順位決定、ステークホルダーとの調整。
- Scrum Master (SM)：プロセスの円滑化・障害除去・チームの自己組織化支援。
- 開発チーム：設計・実装・テスト・デプロイを担うクロスファンクショナルチーム（一般に5〜9名推奨）。
- ステークホルダー／ユーザー：要求提供とフィードバック。
主な成果物（アーティファクト）
- プロダクトバックログ：要件・ユーザーストーリーの一覧と優先順位。
- スプリントバックログ：そのスプリントで取り組む項目の集合。
- インクリメント：各スプリントで完成（Definition of Doneを満たした）したソフトウェアの成果物。
- Definition of Done（DoD）：「完了」の基準（テスト合格、ドキュメント、コードレビュー等）。
主要イベント
- スプリント（Sprint）：固定期間（1〜4週）。スプリント期間中は計画変更を避ける。
- スプリントプランニング：スプリントの目標定義とバックログアイテム選定。見積り（ストーリーポイント）も行う。
- デイリースクラム（Daily Standup）：15分以内、進捗・妨げ・当日の予定を共有。
- スプリントレビュー：インクリメントをステークホルダーにデモし、フィードバックを得る。
- スプリントレトロスペクティブ：チーム内でプロセス改善点を洗い出し次スプリントに反映する。
典型的な 1 スプリントの流れ（例：2週間）
- Day 0: バックログ整備（Refinement）でアイテムを準備
- Day 1: スプリントプランニング（目標・作業選定）
- Day 1〜10: 実装・テスト・CI（毎日デイリースクラム）
- Day 9: スプリントレビュー（デモ、フィードバック収集）
- Day 9〜10: レトロスペクティブ（改善点の合意）
- 次スプリントに向けてバックログを更新
要件やストーリーの書き方
ユーザーストーリー形式：As a <role>, I want <goal> so that <benefit>.
- Acceptance Criteria（受け入れ基準）を明確に書く（例：Given/When/Then形式）。
- INVEST原則：Independent, Negotiable, Valuable, Estimable, Small, Testable
見積り・計画
- ストーリーポイントを用いた相対見積り（プランニングポーカー等）。
- Velocity（ベロシティ）：スプリントあたり完了したストーリーポイントの平均。将来の計画に利用。
- バーンダウンチャート：残作業の減りを可視化。
- 自動化（ユニットテスト、統合テスト、E2E）と継続的インテグレーション（CI）を重視。
- Definition of Done にテストカバレッジや自動テスト通過を含める。
- TDD / ペアプログラミング / コードレビューなどを取り入れると品質向上。
デプロイ・運用
- 継続的デリバリ（CD）を導入してリリースの頻度を上げる。Feature flagを使うとリスク低減。
- モニタリングとフィードバックループ（運用から開発へフィードバック）を確立する（DevOps文化）。
指標（KPI）
- Velocity、リードタイム（要件投入からリリースまでの時間）、サイクルタイム、バグ件数、デプロイ頻度、平均復旧時間（MTTR）など。
よくある課題と対処法
- 課題：過度なスコープ追加（スプリント中の割り込み）→ 対処：PO が優先度管理、クリティカルな変更は次スプリントへ。
- 課題：不明確な要件→ 対処：早期プロトタイプ、頻繁なステークホルダー連携、Acceptance Criteria の強化。
- 課題：チーム外からの指示や上下の介入→ 対処：スクラムマスターが調整、チームへのルール周知。
- 課題：技術負債の蓄積→ 対処：バックログに技術負債項目を入れ、計画的に解消。
スケーリング（複数チーム）
- SAFe, LeSS, Nexus などのスケーリングフレームワークでチーム間の同期・アラインメントを取る。
- 共通のインクリメント、同じスプリントリズム、定期的なクロスチームレビューを実施。
実践のコツ（チェックリスト）
- スプリントは短め（2週間推奨）でフィードバックを早く得る
- DoD と Acceptance Criteria を必ず明確化
- 自動テストとCIの比重を高める
- デイリーを短く、問題の可視化に徹する
- PO は優先順位を継続的に手入れする（Backlog Refinement）
参考
CI/CD とテストフローを入れた DevOps 図
著者：松尾正信
株式会社京都テキストラボ代表取締役