PR

システム開発におけるプロセス成熟度と CMMI によるモデル化・運用

この記事は約9分で読めます。

1. プロセス成熟度が価値を生む条件

システム開発で「成果が安定しない」状態は、品質・納期・コストのブレとして現れます。ここで言う プロセス成熟度 は「担当者の頑張り」ではなく、「再現可能なやり方（プロセス）で成果を出す度合い」を指します。成熟度が上がるほど、次の効果が出やすくなります。

  • 見積もり精度が上がります（計画と実績の差が縮みます）
  • 欠陥の混入・流出が減ります（検出が早まり、再発が減ります）
  • 属人性が下がります（引継ぎ・チーム拡大を進めやすくなります）
  • データにもとづき改善できます（感覚ではなく測定にもとづく改善）

ただし、成熟度を上げてもビジネス成果に結びつかないケースもあります。典型例は「監査に通るための文書作り」が目的化する状態です。CMMI Institute も、改善目標はビジネス目標に基づくことが望ましい旨を明示し、限られた数の領域に優先順位をつけて取り組むことを推奨しています。(cmmiinstitute.com)

2. CMMI の位置づけ

CMMI（Capability Maturity Model Integration） は、組織の能力・パフォーマンスを高めるための ベストプラクティス（成功しやすい実践のまとまり） を体系化したモデルです。ISACA が運営する CMMI Institute が提供しており、組織の現状把握（アプレイザル）と改善活動の指針として使われます。(cmmiinstitute.com)

CMMI の要点は「プロセスが存在する」だけでは不十分で、実行→測定→制御→改善 のループが回っているかを段階的に捉える点にあります。CMMI Institute は、組織を評価する軸として Maturity Level（成熟度レベル） と、特定領域ごとの Capability Level（能力レベル） を提示しています。(cmmiinstitute.com)

3. CMMI の“モデル化”の中核：成熟度レベルと能力レベル

3.1 成熟度レベル（Maturity Levels）

CMMI Institute は、組織全体を段階的に捉える 成熟度レベル 1〜5 を定義しています。(cmmiinstitute.com)

成熟度レベル組織の状態（要旨）現場で起きやすいこと
0: Incomplete仕事が完了するか不明進め方が定まらず、やり直しが常態化
1: Initial反応的で予測不能炎上対応で乗り切るが、計画が外れる
2: Managedプロジェクト単位で計画・測定・管理個別PJは回るが、横展開が弱い
3: Defined組織標準が整い、予防的に動く標準＋テーラリングで再現性が上がる
4: Quantitatively Managed定量的に測定・制御し、予測できる品質・納期の予測がデータで可能になる
5: Optimizing継続改善が組織文化として定着改善が日常業務として回り続ける

（上表は CMMI Institute の記述を開発現場向けに要約しています）(cmmiinstitute.com)

3.2 能力レベル（Capability Levels）

成熟度レベルが「組織全体の段階」なら、能力レベルは「特定領域（Practice Area）ごとの達成度」です。CMMI Institute は 能力レベル 0〜3 を示し、領域内の実践が進化する道筋として説明しています。(cmmiinstitute.com)

能力レベル意味（要旨）実装の観点
0: Incomplete意図を満たさない／不安定ルール・手順がない、実施が偶発的
1: Initial一部の意図を満たすが不完全「やっている」が抜け漏れが多い
2: Managed意図を満たす“完結した”実践計画・実施・進捗監視が回る
3: Defined組織標準＋テーラリングで運用標準化と現場適用が両立する

(cmmiinstitute.com)

3.3 「成熟度」と「能力」を混同しない

現場では「成熟度レベル＝強い組織」と短絡しやすい傾向があります。実務では、次の順で捉えると破綻しにくくなります。

  1. 事業課題（例：品質事故、納期遅延、属人化）を定義します
  2. 課題に直結する領域の能力レベルを上げます
  3. 結果として組織の成熟度レベルを高めます（または維持します）

4. システム開発での適用手順：CMMI を“運用できる形”に落とす

ここでは「評価（アプレイザル）に耐える」より先に、「開発成果が改善する」設計を優先します。

4.1 スコープの固定（最重要）

最初に次を固定します。

  • 対象組織：全社／部門／特定プロダクトライン
  • 対象ライフサイクル：要件〜リリース〜運用のどこまで
  • 対象プロジェクト：代表PJ（3〜5件）など

※スコープが曖昧だと、改善施策が“どこにも効かない”状態になりやすくなります。

4.2 改善目標の「測定可能」化

例（指標は一例）：

  • 品質：流出欠陥密度、重大障害件数、再オープン率
  • 納期：リードタイム、スプリント達成率、見積もり誤差
  • 生産性：作業中断回数、レビュー指摘密度、手戻り工数比率

※指標は「現場が改ざんしにくい」「収集を自動化しやすい」ものを優先します。

4.3 現状把握（ギャップ分析）の進め方（証跡ベース）

開発組織での証跡例：

  • チケット（要件・変更・障害）
  • Git の履歴、レビュー履歴
  • CI/CD のログ、テスト結果
  • 品質レポート、リリース判定資料
  • 作業手順・テンプレート（標準＋テーラリング）

ギャップ分析は「ある／ない」ではなく、「意図を満たすか」「再現可能か」「測定できるか」で判断します（能力レベルの考え方と整合します）。(cmmiinstitute.com)

4.4 最小限のプロセス資産（Process Asset）の作成

過剰なプロセスは抵抗を生みやすくなります。最初は次に絞ります。

  • 標準テンプレート（計画、リスク、変更管理、リリース判定）
  • テーラリング指針（例：小規模PJではレビュー手順を簡略化）
  • 定例の測定レポート（自動集計を優先）

例：リリース判定の最小テンプレート（YAML）

release_decision:
  version: "1.2.3"
  scope:
    features: ["F-101", "F-102"]
    fixes: ["BUG-77"]
  quality_gates:
    test_pass_rate: ">= 95%"
    critical_open_bugs: "== 0"
    security_scan: "no high findings"
  rollout_plan:
    method: "canary"
    rollback: "supported"
  approvals:
    dev_lead: "approved"
    qa_lead: "approved"
    product_owner: "approved"

5. アプレイザル（評価）をプロセス改善に組み込む

アプレイザル（Appraisal） は、CMMI に基づいて強み・弱みを明らかにする評価活動です。CMMI Institute は、アプレイザルの種類として Benchmark / Sustainment / Evaluation / Action Plan Reappraisal を示しています。(cmmiinstitute.com)

5.1 種類と使い分け（実務向け）

種類目的レーティング（評定）有効期間（公式記載）
Benchmark厳格に評価し、改善機会を特定あり3年(cmmiinstitute.com)
SustainmentBenchmark 後の維持確認（“健康診断”）あり2年(cmmiinstitute.com)
Evaluation柔軟に現状把握し、Benchmark 準備に使うなし(cmmiinstitute.com)該当なし
Action Plan Reappraisal目標レベル未達時の再挑戦条件付き直前評価に依存(cmmiinstitute.com)

※公式な要件・運用は変更される可能性があるため、最新の定義は CMMI Institute の記載と認定リードアプレイザー（Certified Lead Appraiser）への確認が必要です。(cmmiinstitute.com)

5.2 典型的なロードマップ

  1. Evaluation でギャップと改善バックログを作ります
  2. 3〜6か月単位で改善スプリントを回します（測定を必ず入れます）
  3. Benchmark で外部評定＋次期改善テーマを確定します
  4. 年次で Sustainment を挟み、形骸化を防ぎます

6. よくある失敗パターンと回避策

6.1 「レベル取得」が目的化する

レベルは結果であり、目的にはなりにくいものです。CMMI Institute は、改善の焦点をビジネス目標とパフォーマンス結果に置くことが望ましい旨を述べています。(cmmiinstitute.com)
回避策：KPI を「監査用」ではなく「意思決定用」に設計します（例：欠陥トレンドがリリース判断を変える状態を作ります）。

6.2 文書が増え、開発速度が落ちる

回避策：証跡を“開発ツールに残す”設計に寄せます。チケット、Git、CI のログを一次証跡にします。

6.3 標準化が現場に適用できない

回避策：テーラリング指針を標準の一部として定義します（「例外運用」を正式化します）。

6.4 定量管理が「数値の収集」で止まる

成熟度レベル 4 は「測定・制御」を要点に含みます。(cmmiinstitute.com)
回避策：閾値（Quality Gate）とアクション（止める／戻す／追加テスト）を必ずセットにします。

7. 他の成熟度・アセスメント規格との関係（ISO/IEC 33000 など）

CMMI 以外にも プロセスアセスメント の枠組みがあります。日本では IPA（情報処理推進機構）の資料が、ISO/IEC 15504（後継として ISO/IEC 33000 シリーズ）や CMMI など複数モデルの存在と、アセスメントモデルが「魔法の杖ではない」ことを明確に述べています。(情報処理推進機構)

実務上の使い分けの目安は次の通りです。

  • CMMI：ベストプラクティスを“改善の設計図”として使う（改善活動のガイド）
  • ISO/IEC 330xx：アセスメントの整合性・共通ルールを重視する（評価枠組みの標準）

※どちらを採用する場合でも、契約要件や顧客監査要件が絡むと判断が変わる場合があります。

8. まとめ：CMMI を「現場が回せる改善」にする要点

  • スコープ固定 が成否を決める（組織・工程・対象PJ）
  • 成熟度レベルは“結果”、能力レベルは“てこ”として使います(cmmiinstitute.com)
  • 証跡は開発ツールに残し、文書は最小化します
  • 測定は「集める」ではなく「制御に使う」まで設計します(cmmiinstitute.com)
  • アプレイザルは改善サイクルに組み込み、Evaluation→Benchmark→Sustainment の順で現実的に進めます(cmmiinstitute.com)

A. 参考サイト

  • CMMI Institute「CMMI Levels of Capability and Performance」(cmmiinstitute.com)
  • CMMI Institute「Types of CMMI Appraisals」(cmmiinstitute.com)
  • ISACA「ISACA Updates CMMI Model…（2023-04-06）」(ISACA)
  • Carnegie Mellon SEI「CMMI: Staged or Continuous?（PDF）」(セイ)
  • SEA-SPIN「ソフトウェア能力成熟度モデル 1.1版 公式日本語版（CMU/SEI-93-TR-24）」(sea.jp)
  • IPA「プロセス診断活用編（PDF）」(情報処理推進機構)

B. 関連書籍

コメント