7-4 ハイブリッドアプローチ

Hybrid Approaches

ハイブリッドアプローチは、予測型とアジャイルを組み合わせた手法である。 現実のプロジェクトでは、純粋なウォーターフォールや純粋なアジャイルよりも、 状況に応じて両者を組み合わせることが多い。

1. ハイブリッドの必要性

1.1 なぜハイブリッドか

現実のプロジェクトでは、純粋なアジャイルや純粋なウォーターフォールを 適用することが難しい場合が多い。組織の制約、規制要件、 プロジェクトの特性などを考慮し、両者の良いところを 組み合わせるハイブリッドアプローチが有効である。

状況 ハイブリッドの理由
組織の制約 予算・契約が予測型を要求
規制要件 ドキュメントやゲートが必須
段階的移行 いきなり完全アジャイルは困難
プロジェクト特性 一部は明確、一部は不確実
大規模プロジェクト 全体調整と部分の自律性の両立

1.2 ハイブリッドの形態

ハイブリッドアプローチには、いくつかの形態がある。 フェーズごとに異なるアプローチを適用する方法、 コンポーネントごとに分ける方法、プラクティスを混合する方法などである。 プロジェクトの特性に応じて、最適な形態を選択する。

形態 説明
フェーズごと 設計は予測型、開発はアジャイル
コンポーネントごと 基盤は予測型、UIはアジャイル
プラクティス混合 予測型に一部アジャイルプラクティスを導入

2. 代表的なハイブリッドパターン

2.1 Water-Scrum-Fall

Water-Scrum-Fallは、最も一般的なハイブリッドパターンの一つである。 要件定義と基本設計は予測型で行い、開発フェーズでスクラムを採用、 最後のリリースは再び予測型で行う。 既存の組織プロセスを大きく変えずに、アジャイルの利点を取り入れられる。

Water-Scrum-Fallのフロー

図1: Water-Scrum-Fallのフロー

フェーズ アプローチ
要件定義・基本設計 予測型(ウォーターフォール)
詳細設計・開発・テスト アジャイル(スクラム)
移行・リリース 予測型(ウォーターフォール)

2.2 アジャイルリリーストレイン

アジャイルリリーストレインは、複数のアジャイルチームが 同期してリリースを行う方式である。 各チームはスクラムで開発しつつ、全体の統合ポイントを設ける。 大規模プロジェクトで、チーム間の調整と自律性のバランスを取るために用いられる。

PI(Program Increment)
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 テーラリングの考慮点

テーラリングを行う際には、プロジェクトの特性、組織の文化、 チームの成熟度、ステークホルダーの期待などを考慮する。 ただし、フレームワークの本質を理解せずに変更すると、 効果が失われる危険性がある。

要素 検討事項
プロジェクト特性 規模、複雑性、リスク
組織 文化、成熟度、制約
チーム スキル、経験、分散
ステークホルダー 関与度、期待

「守破離」の考え方

最初はフレームワークを忠実に守り(守)、 経験を積んでから応用し(破)、 最終的に自分たちの形を創る(離)。 基本を理解せずにカスタマイズするのは危険である。 まずはルール通りに実践し、理由を理解してから変更すべきである。

第7章完了
アジャイル開発の基本を学習しました。 次は「第8章 AI/LLMプロジェクト」で、AI時代のプロジェクト管理について学習しよう。
参考文献
[1] PMI (2021). PMBOK Guide 7th Edition.
[2] Scaled Agile, Inc. SAFe Framework.