2-4 方法論の比較
Methodology Comparison
1. 主要な方法論・フレームワークの概要
1.1 方法論とフレームワークの違い
方法論（Methodology）は具体的な手順やプロセスを規定したものであり、 フレームワーク（Framework）は考え方や原則を提供する枠組みである。 PMBOKは「ガイド」であり、PRINCE2は「方法論」、Scrumは「フレームワーク」と分類される。
| 名称 | 分類 | 発祥 | 特徴 |
|---|---|---|---|
| PMBOK | 知識体系ガイド | 米国（PMI） | ベストプラクティスの集大成 |
| PRINCE2 | 方法論 | 英国（OGC/Axelos） | プロセスベース、ガバナンス重視 |
| Scrum | フレームワーク | 米国 | 軽量、反復開発 |
| XP | 方法論 | 米国 | 技術プラクティス重視 |
| 共通フレーム | 標準規格 | 日本（IPA） | ISO/IEC 12207ベース、日本向け |
2. PMBOK vs PRINCE2
2.1 比較表
代表的なプロジェクトマネジメント標準を比較する。
| 観点 | PMBOK | PRINCE2 |
|---|---|---|
| 性質 | 知識体系（何を知るべきか） | 方法論（どのように実行するか） |
| アプローチ | プロセス指向 | プロセス＋原則指向 |
| 構成要素 | 10の知識エリア、5のプロセス群 | 7原則、7テーマ、7プロセス |
| ガバナンス | PMに権限集中 | プロジェクトボードによる監督 |
| ステージ管理 | フェーズゲート（推奨） | ステージゲート（必須） |
| ビジネスケース | 参照程度 | 継続的な妥当性確認を重視 |
| テーラリング | 推奨 | 必須（テーラリングしないと適用できない） |
| 認定資格 | PMP、CAPM | Foundation、Practitioner |
| 普及地域 | 北米、グローバル | 欧州、英連邦諸国 |
2.2 PRINCE2の7原則
PRINCE2は7つの原則を中核としている。これらの原則が守られないプロジェクトは PRINCE2プロジェクトとは呼べないとされている。
| 原則 | 説明 |
|---|---|
| 継続的なビジネス正当性 | プロジェクトはビジネス上の正当な理由が必要 |
| 経験からの学習 | 過去の教訓を活用し、新たな教訓を記録 |
| 役割と責任の明確化 | 全員が自分の役割を理解 |
| 段階的なマネジメント | ステージ単位で計画・レビュー・承認 |
| 例外によるマネジメント | 許容範囲を超えた場合のみ上位にエスカレーション |
| 成果物への焦点 | 活動より成果物の品質を重視 |
| プロジェクト環境への適合 | プロジェクトの規模・環境に合わせてテーラリング |
PMBOKとPRINCE2は対立するものではなく、併用することも可能である。 PMBOKの知識をベースに、PRINCE2のガバナンス構造を適用するなど、 組織の状況に応じて組み合わせることができる。
3. 予測型 vs アジャイル
3.1 アジャイル宣言
アジャイルソフトウェア開発宣言（2001年）は、アジャイル開発の価値観を表明したものである。 4つの価値と12の原則で構成され、多くのアジャイル手法の基盤となっている。
| 左側（より重視） | 右側（価値があるが相対的に軽視） |
|---|---|
| 個人と対話 | プロセスやツール |
| 動くソフトウェア | 包括的なドキュメント |
| 顧客との協調 | 契約交渉 |
| 変化への対応 | 計画に従うこと |
3.2 予測型とアジャイルの比較
予測型とアジャイルは異なる特性を持ち、プロジェクトの性質に応じて選択する。
| 観点 | 予測型（Waterfall） | アジャイル（Scrum等） |
|---|---|---|
| 計画 | 詳細な事前計画 | 適応的計画（随時更新） |
| 要件 | 初期に確定 | 反復ごとに優先順位付け |
| 変更 | 変更管理で厳格に制御 | 変更を歓迎 |
| リリース | プロジェクト終盤に一括 | 反復ごとにインクリメント |
| 顧客関与 | マイルストーン時点 | 継続的、頻繁 |
| チーム構造 | 機能別チーム | クロスファンクショナルチーム |
| 成功指標 | 計画との適合度 | 価値の提供、顧客満足 |
| ドキュメント | 詳細なドキュメント | 必要最小限 |
3.3 主要なアジャイル手法
アジャイルには複数の手法があり、それぞれ特徴が異なる。
| 手法 | 特徴 | 主な要素 |
|---|---|---|
| Scrum | 軽量フレームワーク、役割・イベント・成果物を定義 | スプリント、デイリースクラム、レトロスペクティブ |
| XP（Extreme Programming） | 技術プラクティス重視 | ペアプログラミング、TDD、継続的インテグレーション |
| Kanban | フロー最適化、WIP制限 | カンバンボード、リードタイム測定 |
| SAFe | 大規模アジャイルフレームワーク | PI Planning、ARTs、ポートフォリオ管理 |
| LeSS | 大規模Scrum | 複数チームでの単一プロダクトバックログ |
アジャイル宣言は「包括的なドキュメントより動くソフトウェア」を重視するが、 これはドキュメントが不要という意味ではない。必要なドキュメントは作成すべきであり、 特に規制産業や保守を考慮すると、適切なドキュメントは重要である。
4. 共通フレーム（SLCP）
4.1 共通フレームとは
共通フレーム（SLCP: Software Life Cycle Process）は、IPA（情報処理推進機構）が 策定した日本のソフトウェア開発標準である。ISO/IEC 12207をベースに、 日本の商慣習に合わせてカスタマイズされている。
4.2 共通フレームの構成
共通フレームは複数のプロセスで構成される。
| プロセスカテゴリ | 主なプロセス |
|---|---|
| 合意プロセス | 取得プロセス、供給プロセス |
| テクニカルプロセス | 要件定義、設計、実装、テスト、運用、保守 |
| プロジェクトプロセス | プロジェクト計画、管理、評価 |
| 組織プロセス | 組織のプロセス改善、人材育成 |
| 支援プロセス | 品質保証、検証、妥当性確認、構成管理 |
共通フレームは、発注者と受注者間の共通言語として機能する。 RFP（提案依頼書）の作成、契約範囲の明確化、見積り根拠の説明などで 活用されることが多い。特に官公庁・公共系のプロジェクトでは参照されることがある。
5. 方法論選択の指針
5.1 選択の観点
どの方法論を採用するかは、プロジェクトの特性だけでなく、 組織の成熟度、チームのスキル、顧客の特性なども考慮して決定する必要がある。
| 状況 | 推奨アプローチ |
|---|---|
| 要件が明確、規制が厳格 | 予測型（PMBOK/PRINCE2） |
| 要件が不明確、変化が激しい | アジャイル（Scrum/Kanban） |
| 大規模プロジェクト、ガバナンス重視 | PRINCE2またはPMBOK＋ガバナンス強化 |
| 大規模アジャイル | SAFe、LeSS |
| 日本の官公庁・公共系 | 共通フレーム参照 |
| 混合要件（一部明確、一部不明確） | ハイブリッド型 |
5.2 組織の成熟度との関係
アジャイルは「軽量」であるが、実践するには高い規律と成熟度が求められる。 組織やチームの成熟度が低い場合、より構造化された予測型アプローチから始め、 徐々にアジャイル要素を取り入れていく段階的アプローチが有効な場合もある。
方法論に振り回されない
重要なのは方法論に忠実に従うことではなく、プロジェクトを成功させることである。 どの方法論も「テーラリング」を前提としており、プロジェクトの状況に合わせて 柔軟に適用することが求められる。方法論は手段であり、目的ではない。
プロジェクトマネジメントの概論を学習しました。 次は「第3章 要件定義」で、プロジェクトの最も重要なフェーズについて学習しよう。
[1] PMI (2017). PMBOK Guide 6th Edition.
[2] Axelos (2017). PRINCE2 Manual.
[3] Beck, K. et al. (2001). Manifesto for Agile Software Development.
[4] IPA (2013). 共通フレーム2013.