カンバン・XP・スケーリング・ハイブリッド
1. カンバン（Kanban）
トヨタ生産方式のpull型を、ソフトウェア開発に適用。
4つの原則
- 現状から始める（Big Bang変革なし）
- 段階的・進化的変化を追求
- 既存の役割・責任・タイトルを尊重
- すべてのレベルでリーダーシップを奨励
6つの中核プラクティス
- Visualize（可視化）: タスクボードでフロー可視化
- Limit WIP（仕掛り制限）: 各カラムに WIP Limit
- Manage Flow（フロー管理）: 滞留を見つける
- Make Policies Explicit（ポリシーの明示化）: 各カラムの完了基準
- Implement Feedback Loops（フィードバックループ）: レビュー会議
- Improve Collaboratively（協働改善）: 継続的改善
Kanban の指標
| 指標 | 内容 |
|---|---|
| Lead Time | 要求受領 → 完了までの全期間 |
| Cycle Time | 作業着手 → 完了までの期間 |
| Throughput | 単位時間あたり完了数 |
| Cumulative Flow Diagram（CFD） | 各カラムのアイテム数を時系列で可視化 |
Little's Law
WIP = Throughput × Cycle Time → WIPを減らせば Cycle Time が短くなる。
スクラム vs カンバン
| 項目 | スクラム | カンバン |
|---|---|---|
| イテレーション | 固定（スプリント） | なし（連続フロー） |
| 役割 | PO/SM/Dev | 自由 |
| 計画 | スプリントプラン | 継続的（pull） |
| 変更 | スプリント中固定 | いつでも変更可 |
| 適合 | 新規開発 | 保守・運用・サポート |
2. XP（eXtreme Programming）
エンジニアリング・プラクティス重視のアジャイル。
主要プラクティス
- Pair Programming: 2人1ペアでコーディング
- TDD（Test-Driven Development）: テスト先に書く
- Continuous Integration: 頻繁なマージ
- Refactoring: コード改善継続
- Simple Design: シンプルさ追求
- Collective Code Ownership: 全員がすべてのコードを編集可
- Sustainable Pace: 持続可能なペース
- Whole Team: 顧客もチームの一員
スクラムとの関係
- スクラム = フレームワーク（プロセス）
- XP = エンジニアリング（実装プラクティス）
- 多くのスクラムチームは XP プラクティスを採用
3. リーン（Lean）
トヨタ起源、無駄の排除に焦点。
7つの無駄（Wastes）
- 部分完成作業（部分的にできた仕掛品）
- 余計な機能（Gold Plating）
- 再学習（同じことを何度も学ぶ）
- ハンドオフ（引き継ぎ）
- タスク切り替え
- 遅延
- 欠陥
リーン原則
- 無駄の除去
- 学習の増幅
- 決定をなるべく遅らせる
- なるべく早く提供
- チームのエンパワー
- 整合性を組み込む
- 全体最適
4. スケーリング・アジャイル
複数チームでアジャイルを展開する手法。
SAFe（Scaled Agile Framework）
最も広く使われる。
- 4つの構成レベル: Team / Program / Large Solution / Portfolio
- PI（Program Increment）: 8〜12週間の計画単位
- PI Planning: 全チームが集まる大規模計画イベント
- ART（Agile Release Train）: 5〜12スクラムチームが連動
- 役割: RTE（Release Train Engineer）、Product Manager、System Architect
LeSS（Large Scale Scrum）
- スクラムを最小限の追加でスケール
- 1つのプロダクトバックログ、1人のPO
- 複数チームが同じスプリントで動く
- LeSS（〜8チーム） vs LeSS Huge（〜数千人）
Scrum of Scrums
- 各チームから代表が集まり、依存・障害を調整
- スケール最小単位
Nexus
- Scrum.org公式の3〜9チーム向け
- Nexus Integration Team が統合管理
Disciplined Agile（DA）
- ツールキット型
- プロジェクト・組織の文脈に応じて選択
スケーリング選択の判断
| 状況 | 推奨 |
|---|---|
| 小規模・シンプル | Scrum of Scrums |
| 中規模・スクラム純度を保ちたい | LeSS |
| 大規模・プログラム管理必要 | SAFe |
| 多様なメソッド使いたい | DA |
5. ハイブリッド・アプローチ
Predictiveとアジャイルを組み合わせる。
ハイブリッドが選ばれるケース
- 規制業界で文書必要だが、変化対応も必要
- 組織のアジャイル成熟度が低い
- 設計フェーズは予測、実装は反復
- ハードウェア（予測） + ソフトウェア（アジャイル）
ハイブリッドのパターン
| パターン | 内容 |
|---|---|
| Phase-Based Hybrid | 設計・調達 = Predictive、開発 = Agile |
| Iterative Predictive | Predictiveだが、各フェーズで反復改善 |
| Agile Wrap | 全体は Predictive、内部チームが Agile |
| Stage-Gate + Agile | ゲートで承認、間はアジャイル |
Hybrid のリスク
- 文化の衝突（PMOがPredictive、開発がAgile）
- 報告フォーマットの乖離（ガントチャートとバックログ）
- 統合管理の複雑性
Hybrid 成功要因
- 組織変革とコミュニケーション
- 共通用語の整理
- ステークホルダー教育
- ガバナンスの明確化
6. アジャイル契約
固定価格契約とアジャイルは矛盾しがちなので、別途設計が必要。
契約パターン
| 種類 | 内容 |
|---|---|
| Time and Material（T&M） | 時間単価、最も柔軟 |
| Fixed-Price with Variable Scope | 固定金額、スコープ調整可 |
| Money for Nothing, Change for Free | 早期終了OK、スコープ変更無料 |
| Capped T&M | T&M + 上限金額 |
| Phased Pricing | フェーズ毎に価格 |
7. アジャイル文脈の試験ポイント
よくある状況問題
| 状況 | アジャイル流の対応 |
|---|---|
| ステークホルダーが新機能要求 | バックログに追加、優先順位はPO |
| スプリント中にスコープ追加要求 | 次スプリントへ（現スプリント保護） |
| ベロシティが予想を下回る | チームでリトロ、原因分析、無理に上げない |
| メンバーが障害で困っている | SMが障害除去、または1on1で支援 |
| 変更要求多発で混乱 | リファインメント徹底、PO関与強化 |
| ステークホルダーが進捗を疑問視 | スプリントレビューに招き、デモで透明性 |
チェック問題
Q1
カンバンで WIP Limit を導入する目的は？
A) チームを評価する B) フローを改善し、Cycle Time を短くする C) ベロシティを増やす D) スプリント長を固定する
Q2
Little's Law の式は？
A) WIP = Throughput / Cycle Time B) WIP = Throughput × Cycle Time C) Cycle Time = WIP × Throughput D) Throughput = WIP × Cycle Time
Q3
SAFe の PI の典型的な長さは？
A) 1〜2週 B) 4〜6週 C) 8〜12週 D) 6ヶ月
Q4
ハイブリッドアプローチが最適なケースは？
A) 完全に要件固定 B) 完全に要件流動 C) 規制ある業界で、設計はPredictive・実装はAgileにしたい D) 小規模単独プロジェクト
Q5
アジャイル契約で「スコープ可変・金額固定」のパターンは？
A) FFP B) Fixed-Price with Variable Scope C) CPFF D) IFB
解答
- B — Little's Lawから、WIP制限がCycle Time短縮に。
- B
- C — 通常8〜12週、5スプリント分。
- C — Hybridの典型ケース。
- B