はじめに
リリースしたコードは、放置すると年単位で「触りづらい」状態にじわじわ変化していきます。
気がついたらそうなっていた、という感覚を持つ開発者は多いはずです。
この記事ではその変化を「構造的な現象」として捉え直し、
プロダクトとプロセス両面の対抗手段を整理します。
「保守は地味」「プロセス改善は他人事」という見方が、
整理を通して別の景色になればと思います。
TL;DR
- ソフトウェアは「使い続けていればいずれ複雑化し品質が低下する」という法則的な傾向を持ち、無策のままだと保守は総開発コストの6〜7割まで膨らむ
- プロダクト側の対抗策は4種類の保守（是正／適応／完全化／予防）と、リファクタリング・リエンジニアリング。なかでも予防的な改善が劣化を遅らせる中核
- プロセス側の対抗策がSPI。評価→教育→選択→導入→評価のサイクルを回すフレームワーク（CMMI、SAMM等）が用意されており、現代は軽量・チーム単位のアジャイルSPIへの転換が進んでいる
ソフトウェアは放っておくと劣化する
「保守が大変」「コードが触りづらい」という体感は、構造的な事実として古くから観察されてきたものです。劣化の正体をコストの数字と法則の両面から確認していきます。
保守は総コストの6〜7割を占めることがある
数年以上アクティブに使われるソフトウェアでは、組織が割く全リソースのうち6〜7割が保守に費やされることも珍しくありません。
長期運用システムほど保守・運用が全体コストの大半を占める、というのが業界の共通認識です。
ここで強調したいのは、これが「保守がうまくない組織の数字」ではなく、
ソフトウェアの構造に組み込まれた現象だという点です。
コードは時間とともに変更要求を吸収し続け、そのたびにコストが発生します。
プロセス改善やリファクタリングへの投資は「余計なコスト」ではなく、保守コストを下げるための主要な手段と位置づけられます。
なぜ劣化は避けられないのか ── Lehmanの法則
数十年にわたる工業用ソフトウェアの観察から、ソフトウェア進化に関するいくつかの法則が提案されており、Lehmanの法則と呼ばれています。
1974年に3法則として提唱され、最終的には8法則まで拡張された経緯があります。
対象は「現実世界の業務環境に組み込まれて使われ続けるソフトウェア」で、
E-type（Evolving）と呼ばれます。
一度書いて終わりの教育用プログラム（S-type）とは違い、
実環境の変化を吸収しながら動き続けることが前提のシステムです。
8法則のうち、保守と関連が深い3つに注目します。
┌────────────────────────────────────┐
│ 劣化は何もしなければ起きるデフォルト │
│ （E-type システムの宿命） │
└────────────────┬───────────────────┘
│ 観察結果から導かれた
┌────────────────────┼────────────────────┐
│ │ │
┌───────▼────────┐ ┌────────▼───────┐ ┌────────▼───────┐
│ 継続的変化の法則 │ │ 複雑度増大の法則 │ │ 品質低下の法則 │
│ │ │ │ │ │
│ 変化し続けな │ │ 何もしないと │ │ 継続的な保守が │
│ ければ次第に │ │ 複雑さは増す │ │ なければ品質は │
│ 役に立たなくなる │ │ │ │ 低下して見える │
└────────────────┘ └────────────────┘ └────────────────┘
3つに共通するのは「複雑度を維持・低減する仕事をしない限り、複雑さは増す」という点です。
劣化は何もしなければ起きるデフォルト状態であって、
誰かが手を抜いた特殊な失敗ではありません。
この捉え方の転換が、本記事の出発点になります。
近い概念として「技術的負債」という言葉が広く使われるようになりました。
短期的な妥協（テスト不足、安易な実装、ドキュメント省略）が将来の保守コストとして利息のように積み上がる現象を指します。
Lehmanの法則は、技術的負債が個人や組織の怠慢だけが原因ではなく、
構造的な傾向として存在することを示しているとも読めます。
プロダクトを直す ── 保守の4分類
劣化が法則として避けられないなら、対抗手段を整理しておく必要があります。
「保守」を目的別に4種類に分けて捉えると、
自分のチームが「何をしているか」「何が足りていないか」が見えやすくなります。
多くのチームでは是正と適応に追われ、完全化や予防に手が回らない状態になりがちで、
この偏りが劣化を加速させます。
是正・適応・完全化・予防 ── 4つの保守の役割
ソフトウェアの保守性（maintainability）とは、
既存ソフトウェアを修正・適応・拡張することの容易さを指します。
保守性が低いと、どの保守タイプも高コスト化します。
| 種類 | 目的 | きっかけ | 代表例 | 新機能追加 |
|---|---|---|---|---|
| 是正保守（corrective） | バグの修正 | ユーザー報告／運用監視／内部テスト | 不具合チケット対応、ホットフィックス | 基本なし |
| 適応保守（adaptive） | 環境変化への追従 | OS／ライブラリ更新、法規制、ハード変更 | ランタイム更新、依存ライブラリのアップグレード、個人情報法対応 | 基本なし |
| 完全化保守（perfective） | 動いている機能の改善・拡張 | ユーザー要望、業務変化 | 機能追加、性能改善、UI改善 | あり |
| 予防保守（preventive） | 将来の保守を楽にする先回り | 内部判断、メトリクス | リファクタリング、ドキュメント整備、テストカバレッジ向上 | 場合により |
是正と適応は「直さなければ困る」性質で放っておかれませんが、
完全化と予防は「直さなくても今日は困らない」ので後回しにされがちです。
だからこそ予防への投資が将来の是正・適応のコストを下げる、
という構造的な見方が重要です。
「保守＝バグ修正」のイメージで止まっていると、
4種類のうち1種類しか視野に入っていないことになります。
なお、アジャイル開発では新規機能追加と保守の境界が曖昧になりやすく、
開発と保守を分けるか同じチームで扱うかは組織によって判断が分かれます。
反応的な保守だけでは追いつかない ── 予防保守という発想
是正・適応はトラブルが起きてから動く反応的な活動です。
これだけだと、劣化のスピードに保守活動が追いつかなくなる構造に陥りがちです。
反応的だけのチーム 予防を回すチーム
───────────────── ──────────────
バグ発生 メトリクスで劣化兆候を検知
│ │
▼ ▼
火消し対応 予防保守（リファクタ／テスト追加）
│ │
▼ ▼
別の場所で副作用 劣化スピードが緩む
│ │
▼ ▼
さらに火消し ─── ループ ───┐ バグ発生時の影響範囲も縮小
│ │ │
▼ │ ▼
予防に手が回らない ────────┘ 火消しコストが下がる
予防保守は、トラブルが起きる前に劣化の芽を摘む発想です。
具体的にはリファクタリング、技術的負債の返済、ドキュメント更新、テスト追加などが該当します。
判断材料としては、ソフトウェアアナリティクス（コードや運用データの集計・分析）の活用が広がっています。
欠陥発生率、変更頻度の高いコード領域、バグ修正にかかる平均時間などを集計し、
劣化が進んでいる箇所を特定する使い方です。
AWSで例えると、CloudWatch Logsに集まったエラーログをCloudWatch Metricsで集計するイメージです。
そのうえで、特定の関数で例外が増えている時期と相関するコミットを洗い出す、
といった運用が近いです。
入力源は運用データだけでなく、アプリストアのレビュー、SNS上の言及、自動収集されたクラッシュレポートなどユーザー側からのフィードバックも含まれます。
ただし、ユーザーデータを収集する際は「何のために何を集めるか」を明示し、
倫理的な範囲を守ることが前提です。
2020年代の文脈：DevOps／SREでの予防保守
エラーバジェット（許容できるエラー量を予算として管理する仕組み）、SLO/SLI（サービスレベル目標／指標）に基づく劣化検知、トイル削減のためのリファクタリング自動化などは、予防保守を日常業務に組み込む現代的な仕組みと言えます。
リファクタリングとリエンジニアリング ── 規模に応じた打ち手
予防保守の中核となるのがリファクタリングとリエンジニアリングです。
両者は「既存コードを直して品質を上げる」点は共通ですが、
変更の規模も目的も異なります。
どちらをいつ使うかを誤ると、過小な手当てで劣化が進むか、
過大な再構築でリソースを使い果たすことになりがちです。
既存システムへのアプローチを規模で並べる
既存システムを改善する手段は、変更の規模で並べると以下のスペクトラムになります。
小 大
◀─────────────────────── 変更の規模 ────────────────────────────▶
┌──────────────┐ ┌─────────────────────┐ ┌──────────────────┐
│リファクタリング│ │ リエンジニアリング │ │ リライト／リプレース │
│ │ │ （ソフトウェア進化） │ │ │
├──────────────┤ ├─────────────────────┤ ├──────────────────┤
│ モジュール内の │ │ アーキテクチャ／データ │ │ 全部を捨てて │
│ 整理 │ │ 構造を含めた再構築 │ │ 一から作り直す │
│ │ │ │ │ │
│ 外部振る舞い │ │ 部分的に振る舞いも │ │ 振る舞いも一新 │
│ は変えない │ │ 変わりうる │ │ する前提 │
└──────────────┘ └─────────────────────┘ └──────────────────┘
守備範囲： 守備範囲： 守備範囲：
コード／ローカル コード＋データ＋ 全部
データ アーキテクチャ
選択軸はおおまかに3つ：
- アーキテクチャが健全でモジュール内部だけが荒れている → リファクタリングで足りる
- アーキテクチャ自体が崩れている → リエンジニアリングが必要
- 両方が崩れていてビジネス的にも作り直す価値がある → リプレース
リエンジニアリングするか保守を続けるかの判断には、
費用対効果分析のモデルが提案されています。
使うパラメータは「現在の保守コスト」「リエンジニアリング後の予測保守コスト」「リエンジニアリングコスト」「期待寿命」「リスク係数」などです。
これらを使い、累積保守コストと作り直しのコスト＋初期投資を寿命とリスクで割り引いて比較する、という発想です。
全アプリを同時にリエンジニアリングする余裕はないため、
現実的にはパレートの法則（全体の80%が原因の20%から生じるという経験則）に従って
「問題の80%を生んでいる20%のソフトウェア」から手をつける戦略をとります。
リファクタリングは3層に分かれる
リファクタリングを「コードの整形」のことだと捉えていると、
半分以下しか見えていません。次の3つの層があります。
| 層 | 対象 | 典型例 | リスク |
|---|---|---|---|
| データリファクタリング | データ構造、命名、形式、DB | 別名（エイリアス）の解消、命名規則の統一、データ形式変換、テーブル正規化、フラットファイル → RDBへの移行 | プログラム全体に波及する。アーキテクチャ／コード変更を巻き込みやすい |
| コードリファクタリング | 個別モジュールの内部設計 | スパゲッティコードの構造化、重複の除去、命名の改善、アンチパターンの解消 | テスト不足のままだと外部振る舞いを壊しやすい |
| アーキテクチャリファクタリング | 制御フロー、コンポーネント境界、依存関係 | 巨大モジュールの分割、層構造の整理、依存方向の見直し | 大規模で時間がかかり、本格的な再設計に近い領域に踏み込む |
3層は独立ではなく相互に影響し、データ構造を変えるとコード全体に波及し、
アーキテクチャを変えるとモジュール内部の実装も変わります。
実務的な要点は、外部振る舞いを変えないことを保証する仕組み（テスト、ステージング環境、フィーチャーフラグ）と組み合わせる必要があるという点です。
テストがないコードのリファクタリングは賭けに近く、「リファクタリングする前にまずテストを書く」という順序は守りたい原則だと自分は考えます。
ごく簡単なコードリファクタリングの例：
# Before: スパゲッティ気味の関数
def process(rec):
if rec[0] == "A" and rec[3] > 0 and rec[5] != "":
rec[7] = rec[3] * 1.1
rec[8] = "ok"
elif rec[0] == "B":
rec[7] = rec[3] * 1.0
rec[8] = "ok"
else:
rec[8] = "ng"
return rec
# After: 外部振る舞いは同じまま、意図が読める形に
def process(record: Record) -> Record:
if record.is_eligible_a():
return record.with_amount(record.base * 1.1, status="ok")
if record.is_type_b():
return record.with_amount(record.base, status="ok")
return record.with_status("ng")
外から呼ばれたときの結果は変わらず、内側だけが整理されている、
というのがリファクタリングです。
リエンジニアリングは6つの活動の組み合わせ
ここでリバースエンジニアリングという用語を導入します。
既存コードから設計情報（データ構造・処理・UI）を取り出す活動で、
リエンジニアリングを進めるとき既存システムを理解する出発点になります。
リエンジニアリングは循環的なプロセスで、以下の活動から構成されます。
すべてを毎回実施するわけではなく、必要な活動だけを取り出して回す形です。
- インベントリ分析：全アプリをビジネス重要度・寿命・保守性などで並べ、候補を選ぶ
- ドキュメント再構成：既存システムのドキュメントを最低限整える（完璧を目指さない）
- リバースエンジニアリング：ソースから設計情報を抽出し、より高い抽象レベルの表現を作る
- コードリファクタリング／データリファクタリング：前項で扱った3層のリファクタリング
- フォワードエンジニアリング：抽出した設計情報を活用し、新しい技術スタックで再構築する
注意したいのは、リバースエンジニアリングが
「ソースコードを入れたら設計書が出てくる魔法のスロット」ではない点です。
半自動的なツールは補助になりますが、人間の判断は依然として必要です。
LLMによるコード解析が広がっていますが、
業務ロジックの背景や暗黙の制約は人間の文脈理解に依存しているのが現状です。
もう1つの要点は、アーキテクチャ・データ・コードの3つを揃ってリファクタリングしてはじめて効果が最大化する点です。
コードだけ整えてもアーキテクチャが崩れていれば、長期的な改善にはつながりません。
プロセス側の改善 ── 同じ問題のもう一面
プロダクトを丁寧に直しても、
それを生み出すプロセスが劣化していれば劣化は再生産されます。
レビュー不十分・テスト不十分・要件理解不十分なまま新規機能を作り続ければ、
いくらリファクタリングしても追いつきません。
プロセス側の改善は、劣化の上流に手を入れる活動として位置づけられます。
プロダクトの劣化とプロセスの劣化は連動する
「プロダクトの劣化」と「プロセスの劣化」は別物に見えて、
互いに食い合うサイクルとして連動しています。
┌────────────────────────────────────────────────────────────────┐
│ プロセスの劣化サイクル │
│ │
│ レビューが手薄 ───▶ 欠陥が流出する ───▶ 火消しに追われる │
│ ▲ │ │
│ │ │ │
│ └──────── レビューに割く時間がさらに減る ◀────┘ │
│ │
└────────────────────────────┬───────────────────────────────────┘
│ プロセス劣化が
▼ プロダクトの劣化サイクル
（前述の「火消しループ」）に流れ込む
プロダクト側の改善だけでは、上のプロセス劣化サイクルが残り続け、
新しいコードが今まで通りに荒れて入ってきます。
両方の改善が必要、というのが構造的な要請です。
ソフトウェアプロセス改善（Software Process Improvement、SPI）は、
組織の開発プロセス自体を継続的に改善する活動を指します。
「より集中した、より繰り返し可能な、より信頼できる」プロセスへの転換が目標です。
「プロセス成熟度」という尺度
SPIの中核にはプロセス成熟度という考え方があります。
組織のプロセスがどれだけ整備され、共通理解され、
実行されているかを段階的に表す指標です。
- 低い段階：プロセスが個人技に依存し、結果が予測できない
- 高い段階：プロセスが文書化され、組織全体で一貫して適用され、データに基づいて継続的に改善されている
成熟度モデルは「絶対的な正解」を示すものではなく、
現状と目指す姿のギャップを把握するためのものさしです。
フレームワークの選択は組織の規模や文化に依存します。
大規模組織にはCMMIのような包括的フレームワークが機能する一方、
少人数のスタートアップでは過剰になりやすい、という傾向があります。
小さい組織でもSPIは無関係ではない
かつてSPIは大企業のものという認識が強かったのですが、
今は100人未満の組織や24人未満のスタートアップも多くのソフトウェアを作っています。
規模が小さくても、プロセスを観察して改善する活動は無縁ではありません。
| 観点 | 大規模組織 | 小規模組織 |
|---|---|---|
| 既存プロセスの形式度 | 高い（手順書・役割が文書化済み） | 低い（口頭・暗黙知ベース） |
| SPIフレームワークとの相性 | 包括的なCMMI等が機能しやすい | フレームワークをそのまま入れると「重い」 |
| 改善の入口 | 評価→ギャップ分析→計画 | レトロスペクティブ・ペアレビュー |
| 投資判断の軸 | 契約・規制・全社方針 | 自組織にとってのROI |
小さい組織は柔軟・自己組織化されやすく、
フレームワーク的なSPIを「重い」と感じがちです。
ただ、規模に関係なく「自分たちのやり方を客観的に見直し、ボトルネックを直す」活動の必要性は変わりません。
アジャイルメソドロジー自体が軽量SPIの一形態として機能している、
という見方もあります。
小さい組織でのSPIの鍵は、フレームワークをそのまま導入するのではなく、
自組織にとっての投資対効果（ROI）で判断することです。
「重すぎる」と感じたらほぼ間違いなく重すぎる、
という感覚は結構大事です。
SPIの活動サイクルとリスク
SPIが必要だと納得したとして、具体的に何から始めるのか。
SPIには定石となる活動の流れがあり、
評価→教育→選択→導入→結果評価という循環構造になっています。
各活動の役割と、つまずきやすいポイントを把握しておくと、
取り組むときの地図になります。
評価（assessment）── まず現在地を知る
SPIの最初の活動は評価で、現在のプロセスの強みと弱みを明らかにすることが目的です。
評価対象は「プロセスモデルを採用しているか」ではなく、
組織が実際にやっている活動・成果物・役割・基準などです。
評価の問いは大きく4つの観点で整理できます。
- 一貫性：重要な活動がプロジェクト横断で一貫して行われているか
- 洗練度：管理・技術活動がベストプラクティスに照らして十分洗練されているか
- 受容：プロセスや実践が現場で広く受け入れられているか
- コミットメント：経営層が資源投入を続けているか
結果は現在のやり方とベストプラクティスの間の「ギャップ」として表現され、
これが改善活動の出発点になります。
評価は1回で終わるものではなく、定期的に繰り返して次のサイクルの始点にもなります。
教育・訓練 ── 改善の土台
良いプロセスを選択しても、現場のメンバーが理解していなければ機能しません。
教育の対象は次の3層に整理できます。
- 汎用的なソフトウェアエンジニアリング概念（設計・テスト・レビュー等）
- 選択した技術・ツール（採用したフレームワークやCI/CDツール等）
- コミュニケーション・品質スキル（レビュー観点、インシデント対応の所作等）
「ジャストインタイムの教育」が現実的、というのはよく言われます。
理論を一括投下するより、
必要なタイミングで必要な内容を提供するほうが定着しやすいためです。
形式は問わず、動画、社内ドキュメント、外部講座、ペアワークなど、
組織文化と予算に合うものを選びます。
選択・正当化 ── 何をどう変えるかを決める
評価で見えたギャップに対して、
どのプロセスモデル・手法・ツールを採用するかを決める段階です。
基本的な選択軸は次のとおりです。
- 自組織のステークホルダー（経営層・現場・顧客）の優先度
- 開発するソフトウェアの性質（規模、ライフサイクル、リスクの大きさ）
- 組織文化（トップダウン／ボトムアップ、変化への抵抗感）
- 合意のとりやすさ（既存業務とのフィット感、習得コスト）
完璧な選択肢を待つと「分析麻痺」に陥りいつまでも改善が始まらないため、
一定の基準を満たすものがあればいったん選んで実行する判断も大事です。
「正当化」フェーズでは、
選んだ手法のコスト・期待便益・リスクを経営層・現場に説明し、合意を取り付けます。
なぜそれを今やるのかを説明できないと、途中で資源を引き上げられがちです。
導入・移行 ── 現場に組み込む
選んだ変更を実際の業務プロセスに反映させる段階です。
「導入」は新しい活動を組み込むこと、
「移行」は既存活動を別の形に変えることを指します。
ソフトウェアプロセス再設計（SPR）の文脈では、
3つのプロセス状態を区別すると整理しやすいとされます。
時間軸 ──────────────────────────────────────▶
┌──────────┐ ┌────────────────┐ ┌──────────┐
│ as-is │ ──▶ │ here-to-there │ ──▶ │ to-be │
│ （現状） │ │ （移行） │ │ （目標） │
├──────────┤ ├────────────────┤ ├──────────┤
│ 今の │ │ 過渡期のやり方 │ │ 目指す │
│ やり方 │ │ ・段階的変更 │ │ 最終形 │
│ │ │ ・部分採用 │ │ │
│ │ │ ・並走運用 │ │ │
└──────────┘ └────────────────┘ └──────────┘
現状と目標が離れているほど過渡期の設計が重要になります。
一気に変えると現場が混乱するため、過渡期を段階的に組み立てる、
というのが基本方針です。
大規模変更は文化変容を伴うため、
テクノロジー以上に「人がついてこられるか」が成功要因になります。
結果評価 ── 効果を測り、次サイクルへ
導入した変更が効果を上げているかを測ります。
これが次サイクルの評価のインプットにもなります。
- 定性：現場と経営層の意識・態度の変化（プロセスへの信頼感、レビューへの抵抗感など）
- 定量：欠陥率、リワーク率、リードタイム、納期遵守率などのメトリクス変化
「変えた → 効果が出た／出なかった」を確認できるようにしておくこと自体がSPIの基礎です。
SPIにはリスクが伴う
SPIの取り組みの半数以上が失敗する、という報告もあります。
主要なリスクとしては次のようなものが挙げられます。
- 経営層の支持の欠如（途中で資源が引き上げられる）
- 技術スタッフの文化的抵抗（新しいやり方が「面倒」と受け取られる）
- 計画の不備、過度に形式的なアプローチ
- 不適切なプロセス選択、予算不足、研修不足
- 組織の不安定性（人事異動・組織再編の最中に始める）
リスクは(1)SPI開始前の事前評価、(2)5活動の実行中、(3)結果評価のタイミング
の3点で管理するのが推奨されます。
代表的な失敗要因は「文化的抵抗」で、
導入前に対話を重ね現場の声を反映する仕組みが必要になります。
トップダウンで降ってきたプロセス改善ほど、現場で形だけ運用されて中身が骨抜きになる、というパターンが起きやすいと自分は感じています。
SPIフレームワークの全体像 ── CMMIから現代的選択肢まで
5活動サイクルを自前で組み立てることもできますが、
成熟度フレームワークを土台にすると評価軸や改善ターゲットが明確になります。
代表格はCMMIですが、組織の文化や規模に合った選択肢は他にもあります。
CMMI ── 最も知られたSPIフレームワーク
CMMI（Capability Maturity Model Integration）は、
最も知られているSPIフレームワークの1つです。
カーネギーメロン大学のSEI（Software Engineering Institute）が1990年代から発展させてきました。
運営主体の変遷を時系列で整理すると以下のとおりです。
- 2013年：SEIからCMMI Instituteへ移管
- 2016年：ISACAがCMMI Instituteを買収し、ISACAの子会社として運営
- 2023年4月：最新版CMMI V3.0をリリース
CMMIには段階的表現（組織全体の成熟度を1〜5段階で評価）と連続的表現（プロセス領域ごとに能力レベル0〜5で評価）の2つがあります。
本記事では段階的表現の5段階を中心に説明します。
| レベル | 名称 | 特徴 | 代表的なプロセス領域の例 |
|---|---|---|---|
| 1 | Initial | 場当たり的。成功は個人技に依存 | （特になし） |
| 2 | Managed | プロジェクト単位で計画・追跡・レビューが行われる | 要件管理、プロジェクト計画、構成管理 |
| 3 | Defined | 組織標準プロセスを各プロジェクトがテーラリングして使う | 検証、組織訓練、リスク管理 |
| 4 | Quantitatively Managed | プロセスがメトリクスで定量的に管理される | 定量的プロジェクト管理、組織プロセス性能 |
| 5 | Optimizing | 定量データに基づきプロセスが継続的に改善される | 因果分析と解決、組織イノベーションと展開 |
各レベルに到達するには、
特定のプロセス領域（process area）の目標を達成する必要があります。
プロセス領域は「プロセスのまとまった単位」のことで、
要件管理、プロジェクト計画、構成管理、リスク管理などが該当します。
なお、CMMI V2.0以降では「プロセス領域」は「プラクティス領域（practice area）」へと名称が変わり、構成も再編されています。
本記事では古典的かつ広く知られている「プロセス領域」の呼称で説明します。
CMMIは「過剰では？」という議論が長年続いています。
大規模・複雑なシステムを長期間扱う組織には適合する一方、
小規模で機動性重視の組織には過剰になりやすいとされています。
ただし細部を採用しなくても、「ソフトウェア開発を計画的・統制的・職業的に行う」という精神は普遍的に有用、という見方も共有されています。
その他の主要フレームワーク
CMMI以外にも組織の状況に応じた選択肢があります。
| フレームワーク | 提供主体 | 焦点 | 適用しやすい状況 |
|---|---|---|---|
| CMMI | CMMI Institute（元SEI） | プロセス全般の成熟度 | 大規模・長期・契約上の評価が必要 |
| People CMM | 同上 | 人材・組織文化 | 人材育成を体系化したい組織 |
| SPICE / ISO 33000系 | ISO／IEC | プロセス評価の国際標準 | 公的機関・国際取引で標準準拠が求められる |
| TickIT Plus | TickIT Group | 品質マネジメント全般 | 既にISO 9001を運用している組織 |
| OWASP SAMM | OWASP | セキュリティの成熟度（部分採用可） | スタートアップ含む幅広い組織、特にWeb／クラウド |
表に並べた各フレームワークの補足は次のとおりです。
- People CMM：優れたプロセスも優秀でモチベーションのある人がいなければ機能しない、という問題意識から生まれた派生
- SPICE：国際標準ベースの評価フレームワーク。ISO/IEC 15504系として始まり、2015年以降はISO/IEC 33000系へ移行が進んでいる。自動車業界向けのAutomotive SPICEなど派生もある
- OWASP SAMM：セキュリティ視点のオープンフレームワーク。CMMIに比べて軽量で、部分採用しやすい点が特徴
セキュリティに限らず、現代のSPIではこうした「軽量・部分採用可能」なフレームワークの存在感が増しています。
SPIを継続させる ── ROIとアジャイルなトレンド
SPIを始めても、半数以上が途中で止まるという現実があります。
継続させるためには、投資対効果（ROI）を経営層に示す枠組みと、
組織全体に重い変化を強いない軽量な実装方針が必要です。
「より軽く、より素早く」というSPIのトレンドは、
2020年代の今もさらに加速しています。
SPIのROIをどう考えるか
ROI（投資対効果）は、投じたコストに対する便益の比率を表す指標です。
- 便益：品質向上による欠陥減、変更対応コストの低減、市場投入時間短縮による収益増、保守コスト低減
- コスト：研修費、計測ツール、品質統制の追加工数、厳格な手法（モデリング・レビュー）の導入工数
数字を出しにくい便益（顧客満足、ブランド毀損回避）も多いですが、
定性的な指標も含めて全体像を示すことが説得力につながります。
参考までに、古典的な大規模アプローチでのSPIの典型的な投資規模は
「1人あたり25,000〜70,000ドル、数年単位」とされています。
現代の軽量アプローチでは、これより遥かに少ない投資で始められます。
小さい組織でも、自分たちが実施している活動のROIを把握しておくこと自体に価値がある、というのが現代的な見方です。
アジャイルSPI ── 軽く・チーム単位で・素早く
21世紀に入って、SPIフレームワークはアジャイル化の方向に進化しています。
組織全体を年単位で変えるのではなく、
チーム単位で週〜月単位で改善する、という方向です。
従来型SPI アジャイルSPI
───────── ─────────────
スコープ：組織全体 スコープ：チーム単位
時間軸：年単位 時間軸：週〜月単位
プラクティス：包括的（数百） プラクティス：少数のピボタル
教育：教室での集合研修 教育：Web教材・動画・ペアラーニング
文化変容：一気に組織を変える 文化変容：小さなグループから
推進主体：専門部署が押しつけ 推進主体：現場が自ら回す
評価サイクル：年次／半期 評価サイクル：レトロスペクティブ
主要な変化を挙げると次のようになります。
- 包括的なフレームワークから、ピボタルプラクティス（核となる少数の実践）への絞り込み
- 多数のキープラクティスと数百の補助プラクティスから、必要最小限のセットへ
- 教室での集合研修から、Web教材・動画・社内ペアラーニングへ
- 組織文化を一気に変えるのではなく、小さなグループから始めて転換点（ティッピングポイント、変化が一気に広がる閾値）に到達させる
- スクラムのレトロスペクティブをSPIサイクルとして活用する実践
DevOps／SREの普及により、
SPIに近い活動は日常業務に組み込まれるようになっています。
ポストモーテム（インシデント振り返り）は評価活動の一形態と言えます。
エラーバジェットを使った保守と新規開発のバランス調整、SLO/SLIに基づくプロセス改善の優先順位付けも、軽量SPIの実装と捉えられます。
DevSecOpsの文脈では、セキュリティ活動をCI/CDパイプラインに自動化して組み込み、軽量なSPIとして機能させる動きも広がっています。
アジャイルSPIは「フレームワークを軽くする」だけでなく、
「改善を日常業務に溶け込ませる」という質的な変化でもあります。
専門部署が押し付けるのではなく、現場が自ら回す、というのが大きな違いです。
おわりに
整理してみると、保守とプロセス改善は「劣化への対抗」という同じ目的を、
プロダクト側とプロセス側の両面でアプローチしている同じ取り組みだと見えてきます。
自分も最初は、保守は「動かなくなったものを直す作業」で、
プロセス改善は「組織の上層部の話」と捉えていました。
整理の過程でLehmanの法則という構造的な事実が両者の根に共通していると気づき、
見え方が変わったというのが正直なところです。
実務で明日から始められる小さな1ステップとしては、
次のあたりが個人的にはおすすめです。
- 自分のチームの直近3ヶ月の作業時間を「是正・適応・完全化・予防」のどれに該当するかでざっくり分類してみる。予防が極端に少なければ、それが今後の投資対象
- リファクタリングしたいコード領域を、変更頻度・バグ密度などのメトリクスで1つだけ可視化してみる
- チームのレトロスペクティブで「プロセスのどこが詰まっているか」を1項目だけテーマにし、次のスプリントで小さく改善案を試す
最後に、残された論点も挙げておきます。
- Lehmanの法則は経験則であり、AI支援開発時代にも同じ形で当てはまるかは観察が続いている。LLMによるコード生成は劣化を加速するのか抑制するのか、まだ定まっていない
- 大規模リエンジニアリングの判断は依然として難しい。「リファクタリングで足りるか／作り直しか」の分水嶺は、組織のリスク許容度・市場のスピード・技術的負債の蓄積具合の総合判断になる
- SPIフレームワークそのものも進化し続ける。CMMIやSAMMといった既存のフレームワークが今後10年でどう変わるかは、SPI自体への適用問題（フレームワークもまた継続的に改善されるべき対象）として興味深い
ソフトウェアもプロセスも「完成」しません。改善を続けることそのものが、ソフトウェアエンジニアリングの営みの本体だと、整理しながらあらためて感じました。