CMMIとの比較
30.5.1. CMMIの概要
CMMI（Capability Maturity Model Integration、能力成熟度統合モデル）は、組織のプロセス成熟度を評価し改善するためのフレームワークです。カーネギーメロン大学ソフトウェアエンジニアリング研究所（SEI）が開発し、現在はISACA傘下のCMMI Instituteが運営しています。
CMMIは元々、米国国防総省のソフトウェア開発プロジェクトの品質管理のために生まれたCMM（Capability Maturity Model）から発展したものです。2002年にCMMI V1.1が発表され、2018年にCMMI V2.0へと大幅に改訂されました。CMMI V2.0は従来バージョンと比較して構造が簡素化され、成果中心の評価方式が強化されました。
CMMIは主に大規模ソフトウェア開発組織、SI（システムインテグレーション）企業、国防/航空宇宙分野で広く採用されています。韓国国内では大手SI企業や公共プロジェクトの受注のためにCMMIレベル3以上を要求されるケースがあります。
CMMIの核心的な特徴は、組織のプロセス能力を段階的に評価する「成熟度モデル」にあります。組織がどのレベルにあるかを客観的に診断し、次のレベルに上がるためにどのプロセスを改善すべきかを提示します。
30.5.2. 成熟度5段階
CMMIは組織のプロセス成熟度を5段階に区分しています。
| レベル | 名称 | 説明 | 核心的な特徴 |
|---|---|---|---|
| 1 | 初期（Initial） | プロセスが定義されていない状態。個人の能力に依存 | 予測不可能、事後対応的、一貫性なし |
| 2 | 管理（Managed） | プロジェクトレベルで基本プロセスが定義され管理されている状態 | プロジェクト計画、要件管理、構成管理、品質保証 |
| 3 | 定義（Defined） | 組織レベルで標準プロセスが定義され、すべてのプロジェクトに適用されている状態 | 組織標準プロセス、教育訓練、意思決定分析 |
| 4 | 定量的管理（Quantitatively Managed） | プロセスの成果を定量的に測定し制御している状態 | 統計的プロセス制御、定量的プロジェクト管理 |
| 5 | 最適化（Optimizing） | 継続的なプロセス改善が組織文化として定着している状態 | 根本原因分析、継続的改善、イノベーション |
各レベルは前のレベルのプロセスを包含しています。レベル3を達成するには、レベル2のすべてのプロセスを充足した状態でなければなりません。ほとんどの組織はレベル3の達成を目標としており、レベル4と5に到達する組織は世界的にも少数です。
30.5.2.1. レベル別所要期間および費用
CMMI評価に要する期間と費用は、目標レベルによって大きく異なります。
| 目標レベル | 準備期間 | 評価費用 | 備考 |
|---|---|---|---|
| レベル2 | 6〜12ヶ月 | 数千万ウォン | 基本プロセスの定義および適用 |
| レベル3 | 12〜24ヶ月 | 数億ウォン | 組織標準プロセスの策定が必要 |
| レベル4 | 24〜36ヶ月 | 数億ウォン以上 | 定量的管理体系の構築が必要 |
| レベル5 | 36ヶ月以上 | 数億ウォン以上 | 継続的改善文化の定着が必要 |
準備期間にはプロセス定義、教育、パイロット適用、内部評価などが含まれます。外部コンサルティングを活用する場合はコンサルティング費用が追加で発生します。
30.5.3. プロセス領域
CMMI V2.0はプロセス領域（Practice Area）を4つのカテゴリに分類しています。
30.5.3.1. カテゴリ構成
| カテゴリ | プロセス領域数 | 主要内容 |
|---|---|---|
| Doing（実行） | 7領域 | 製品/サービスの開発および提供に直接関連するプロセス |
| Managing（管理） | 6領域 | プロジェクトと作業の計画および管理プロセス |
| Enabling（支援） | 5領域 | 実行と管理を支援する基盤プロセス |
| Improving（改善） | 2領域 | プロセス成果改善プロセス |
30.5.3.2. 主要プロセス領域
| プロセス領域 | カテゴリ | 説明 |
|---|---|---|
| 要件開発および管理（RDM） | Doing | 製品要件の導出、分析、検証、管理 |
| 技術ソリューション（TS） | Doing | 設計、実装、単体テスト |
| 製品統合（PI） | Doing | コンポーネント統合、統合テスト |
| 検証および妥当性確認（VV） | Doing | 製品の検証（技術要件の充足）と妥当性確認（ユーザー要件の充足） |
| プロジェクト計画（PLAN） | Managing | プロジェクト計画の策定、リソース/スケジュールの見積もり |
| プロジェクトモニタリングおよび制御（MC） | Managing | 計画対比の進捗モニタリング、是正処置 |
| 構成管理（CM） | Enabling | 作業成果物の完全性維持、変更管理 |
| プロセス品質保証（PQA） | Enabling | プロセスおよび成果物の品質保証 |
| プロセス管理（PCM） | Improving | 組織プロセスの定義、展開、改善 |
| 成果改善管理（PIM） | Improving | プロセス成果の定量的分析および改善 |
30.5.3.3. 評価方法（SCAMPI）
CMMI成熟度レベルの評価は、SCAMPI（Standard CMMI Appraisal Method for Process Improvement）という公式評価方法を使用します。
| タイプ | 名称 | 用途 | 所要期間 |
|---|---|---|---|
| SCAMPI A | 公式評価 | 公式成熟度レベルの付与、外部公開用 | 1〜2週間（現場評価） |
| SCAMPI B | 中間評価 | 公式評価の準備状態点検、内部診断用 | 3〜5日 |
| SCAMPI C | 簡易評価 | 初期診断、改善計画策定用 | 1〜2日 |
SCAMPI A評価は、CMMI Instituteが認定した主任評価者（Lead Appraiser）が実施します。評価チームは組織のプロセス文書、プロジェクト成果物、従業員インタビューを通じて、各プロセス領域の履行レベルを判定します。
30.5.4. TQSとの比較分析
以下の表は、CMMIとTQSを核心的な比較軸に基づいて整理したものです。
| 比較軸 | CMMI | TQS |
|---|---|---|
| 認証目的 | 組織のプロセス成熟度評価および改善 | コードレベルの技術品質検証 |
| 検証対象 | 組織のプロセス（要件管理、構成管理、品質保証など） | プロジェクトのソースコード、ビルド設定、CI/CDパイプライン |
| 検証レベル | プロセスレベル（「プロセスが定義され運用されているか」） | コードレベル（「コードが基準を満たしているか」） |
| 成熟度モデル | 5段階（初期→管理→定義→定量的管理→最適化） | 5段階（TQS独自の成熟度モデル） |
| 成熟度の焦点 | プロセス能力の成熟度 | 技術実装の成熟度 |
| 審査方法 | SCAMPI評価（文書審査 + インタビュー + 現場評価） | 自動化検証 + コードレビュー |
| 構成管理の検証 | 「構成管理プロセスが定義されているか」 | 「GitHub Flowが適用され、Conventional Commitsを使用しているか」 |
| 品質保証の検証 | 「品質保証プロセスが実施されているか」 | 「テストカバレッジ80%以上、ESLint通過、ビルド成功」 |
| 検証周期 | 3年（SCAMPI A評価） | コミットごと（CI/CD自動検証） |
| 認証費用 | 高コスト（数億ウォン規模） | 無料（自社内部認証） |
| 所要期間 | 12〜36ヶ月（準備 + 評価） | 1〜2週間（審査） |
| 認証機関 | CMMI Institute（ISACA傘下） | ティエニピア技術標準委員会 |
| 対象組織 | 大規模ソフトウェア開発組織 | すべての規模のプロジェクトチーム |
30.5.4.1. プロセス成熟度 vs 技術成熟度
CMMIとTQSの最も根本的な差異は、「成熟度」が意味するものにあります。
CMMIは、組織がソフトウェアを開発するプロセスがどれほど成熟しているかを評価します。「要件管理プロセスが定義されているか」「構成管理手順がすべてのプロジェクトに一貫して適用されているか」「プロセスの成果を定量的に測定しているか」といった質問に答えます。
TQSは、組織が作ったソフトウェアの技術的実装がどれほど成熟しているかを検証します。「コードフォーマッティングが一貫して適用されているか」「テストカバレッジが十分か」「セキュリティ設定が正しく実装されているか」といった質問に答えます。
たとえるなら、CMMIは「工場の生産工程がどれほどよく整備されているか」を検査し、TQSは「工場で生産された製品の品質が基準を満たしているか」を検査します。
30.5.4.2. 費用および期間の差異
CMMI評価は準備から公式評価まで最低12ヶ月以上を要し、外部コンサルティングと評価費用を含めると数億ウォンの費用が発生します。これはCMMIが組織全体のプロセスを対象としているためです。
TQSはプロジェクト単位で認証を付与し、CI/CDパイプラインにすでに自動化検証が統合されているため、審査期間はわずか1〜2週間です。別途の認証費用も発生しません。
30.5.5. TQS成熟度モデルとの関係
TQSも5段階の成熟度モデルを運用しています。CMMIの成熟度モデルがプロセス能力を基準とするのに対し、TQSの成熟度モデルは技術実装能力を基準としています。
30.5.5.1. CMMIとTQSの成熟度段階マッピング
| 段階 | CMMI成熟度 | CMMIの焦点 | TQS成熟度 | TQSの焦点 |
|---|---|---|---|---|
| 1 | 初期（Initial） | プロセス未定義、個人能力依存 | 初期 | コードコンベンション未適用、テストなし |
| 2 | 管理（Managed） | プロジェクト基本プロセス定義 | 基礎 | フォーマッター適用、基本テスト存在 |
| 3 | 定義（Defined） | 組織標準プロセス定義および適用 | 標準 | TQS必須項目全体充足、CI/CD統合 |
| 4 | 定量的管理（Quantitatively Managed） | プロセス成果の定量的測定 | 高度化 | カバレッジ90%以上、パフォーマンス最適化、セキュリティ強化 |
| 5 | 最適化（Optimizing） | 継続的プロセス改善文化の定着 | 最適化 | 自動化レポーティング、品質推移分析、先制的改善 |
30.5.5.2. 両モデルの補完的適用
CMMI成熟度とTQS成熟度は互いに独立的ですが補完的です。
- CMMIレベル3の組織であっても、TQS成熟度が低い場合があります。プロセスはよく定義されていますが、実際のコード品質が基準を満たしていない状態です。
- 逆にTQS成熟度が高いプロジェクトであっても、CMMIレベルが低い場合があります。コード品質は優秀ですが、組織レベルのプロセス標準化が行われていない状態です。
理想的な組織は、CMMI成熟度（プロセス能力）とTQS成熟度（技術実装能力）を共に高めていくことです。CMMIで「どのように仕事をするか」を標準化し、TQSで「仕事の成果物が基準を満たしているか」を検証する双方向の品質管理が最も効果的です。
30.5.5.3. 適用シナリオ
CMMIとTQSを併用することが効果的なシナリオは以下の通りです。
- 大規模SIプロジェクト: CMMIレベル3以上を要求する公共/国防プロジェクトで、CMMIでプロセス能力を証明しTQSで成果物品質を保証します。
- 多数プロジェクト運営組織: CMMIで組織標準プロセスを定義し、各プロジェクトにTQSを適用してプロジェクトごとのコード品質を一貫して管理します。
- プロセス改善推進組織: CMMIレベルの向上を推進しながら、TQSを通じてプロセス改善の実質的な効果（コード品質向上）を定量的に測定します。
CMMIは「組織が成熟したプロセスを運用しているか」を評価し、TQSは「成熟したプロセスが実際に高品質のコードを生み出しているか」を検証します。2つのモデルはプロセス（原因）と成果物（結果）という因果関係の両端をそれぞれ担当します。