7-4 ハイブリッドアプローチ
Hybrid Approaches
1. ハイブリッドの必要性
1.1 なぜハイブリッドか
現実のプロジェクトでは、純粋なアジャイルや純粋なウォーターフォールを 適用することが難しい場合が多い。組織の制約、規制要件、 プロジェクトの特性などを考慮し、両者の良いところを 組み合わせるハイブリッドアプローチが有効である。
| 状況 | ハイブリッドの理由 |
|---|---|
| 組織の制約 | 予算・契約が予測型を要求 |
| 規制要件 | ドキュメントやゲートが必須 |
| 段階的移行 | いきなり完全アジャイルは困難 |
| プロジェクト特性 | 一部は明確、一部は不確実 |
| 大規模プロジェクト | 全体調整と部分の自律性の両立 |
1.2 ハイブリッドの形態
ハイブリッドアプローチには、いくつかの形態がある。 フェーズごとに異なるアプローチを適用する方法、 コンポーネントごとに分ける方法、プラクティスを混合する方法などである。 プロジェクトの特性に応じて、最適な形態を選択する。
| 形態 | 説明 |
|---|---|
| フェーズごと | 設計は予測型、開発はアジャイル |
| コンポーネントごと | 基盤は予測型、UIはアジャイル |
| プラクティス混合 | 予測型に一部アジャイルプラクティスを導入 |
2. 代表的なハイブリッドパターン
2.1 Water-Scrum-Fall
Water-Scrum-Fallは、最も一般的なハイブリッドパターンの一つである。 要件定義と基本設計は予測型で行い、開発フェーズでスクラムを採用、 最後のリリースは再び予測型で行う。 既存の組織プロセスを大きく変えずに、アジャイルの利点を取り入れられる。
@startuml !theme plain skinparam backgroundColor #FEFEFE skinparam defaultFontName Noto Sans JP title Water-Scrum-Fall rectangle "要件定義" as RD #DBEAFE rectangle "基本設計" as BD #DBEAFE rectangle "スプリント1" as S1 #D1FAE5 rectangle "スプリント2" as S2 #D1FAE5 rectangle "スプリント3" as S3 #D1FAE5 rectangle "スプリントN" as SN #D1FAE5 rectangle "移行準備" as MP #FEF3C7 rectangle "リリース" as RL #FEF3C7 RD --> BD BD --> S1 S1 --> S2 S2 --> S3 S3 --> SN SN --> MP MP --> RL note right of RD ウォーターフォール 予測型で全体計画 end note note right of S1 アジャイル(スクラム) 反復開発 end note note right of MP ウォーターフォール 計画的なリリース end note @enduml
図1: Water-Scrum-Fallのフロー
| フェーズ | アプローチ |
|---|---|
| 要件定義・基本設計 | 予測型(ウォーターフォール) |
| 詳細設計・開発・テスト | アジャイル(スクラム) |
| 移行・リリース | 予測型(ウォーターフォール) |
2.2 アジャイルリリーストレイン
アジャイルリリーストレインは、複数のアジャイルチームが 同期してリリースを行う方式である。 各チームはスクラムで開発しつつ、全体の統合ポイントを設ける。 大規模プロジェクトで、チーム間の調整と自律性のバランスを取るために用いられる。
8〜12週間の固定期間で、複数チームが同期して価値を提供する単位である。 SAFe(Scaled Agile Framework)で採用されている概念であり、 大規模プロジェクトでの計画と調整を可能にする。
3. スケールドアジャイル
3.1 大規模アジャイルの課題
アジャイルは元々小規模チーム向けに設計されており、 大規模プロジェクトに適用する際には追加の考慮が必要である。 チーム間の依存関係、全体のアーキテクチャ整合性、 優先順位の調整などが課題となる。
| 課題 | 説明 |
|---|---|
| チーム間調整 | 依存関係の管理、同期 |
| アーキテクチャ | 一貫性のある設計 |
| 優先順位 | 全体最適の判断 |
| リリース | 複数チームの成果物統合 |
3.2 主なスケーリングフレームワーク
大規模アジャイルを支援するために、いくつかのフレームワークが提唱されている。 SAFeは最も包括的で、大企業向け。 LeSSはシンプルさを重視し、スクラムの拡張として位置づけられる。 Nexusはスクラムの公式な拡張である。
| フレームワーク | 特徴 | 規模 |
|---|---|---|
| SAFe | 包括的、エンタープライズ向け | 大規模 |
| LeSS | シンプル、スクラムの拡張 | 中〜大規模 |
| Nexus | Scrum.org公式、軽量 | 中規模 |
| Scrum@Scale | Jeff Sutherland考案 | 中〜大規模 |
3.3 SAFeの概要
SAFe(Scaled Agile Framework)は、最も広く採用されている スケーリングフレームワークである。 チームレベル、プログラムレベル、ポートフォリオレベルの 3つのレイヤーで構成され、それぞれに役割、成果物、イベントが定義されている。
| レベル | 内容 |
|---|---|
| チームレベル | アジャイルチーム(スクラム/カンバン) |
| プログラムレベル | アジャイルリリーストレイン(ART) |
| ポートフォリオレベル | 戦略とファンディング |
大規模フレームワークは複雑であり、導入コストが高い。 まず小さく始め、必要に応じてスケールすることが推奨される。 フレームワークありきではなく、課題に応じた選択をすべきである。
4. テーラリング
4.1 テーラリングとは
テーラリングとは、プロジェクトの特性に合わせて、 手法やプラクティスをカスタマイズすることである。 どのフレームワークも「そのまま」適用するのではなく、 組織やプロジェクトの状況に合わせて調整することが重要である。
4.2 テーラリングの考慮点
テーラリングを行う際には、プロジェクトの特性、組織の文化、 チームの成熟度、ステークホルダーの期待などを考慮する。 ただし、フレームワークの本質を理解せずに変更すると、 効果が失われる危険性がある。
| 要素 | 検討事項 |
|---|---|
| プロジェクト特性 | 規模、複雑性、リスク |
| 組織 | 文化、成熟度、制約 |
| チーム | スキル、経験、分散 |
| ステークホルダー | 関与度、期待 |
「守破離」の考え方
最初はフレームワークを忠実に守り(守)、 経験を積んでから応用し(破)、 最終的に自分たちの形を創る(離)。 基本を理解せずにカスタマイズするのは危険である。 まずはルール通りに実践し、理由を理解してから変更すべきである。
アジャイル開発の基本を学習しました。 次は「第8章 AI/LLMプロジェクト」で、AI時代のプロジェクト管理について学習しよう。
[1] PMI (2021). PMBOK Guide 7th Edition.
[2] Scaled Agile, Inc. SAFe Framework.