🧱 プロセス参照モデル（PRM）は「やり方」を縛るものではない
🧭 はじめに
このページでは、A-SPICEにおける プロセス参照モデル（PRM：Process Reference Model） の位置づけと思想を説明する。
PRMはしばしば 「A-SPICEに書いてある標準プロセス」 「この通りにやらなければならない手順書」 のように誤解されがちである。
しかし実際のPRMは、 やり方（How）を定義するものではなく、達成すべき状態（Why / What）を定義する枠組み である。
🌍 背景・前提
📐 なぜ「プロセス」を定義するのか
A-SPICEは、個人や一時的な成功ではなく、 組織として再現可能な開発ができるか を評価する枠組みである。
そのために必要なのは、
- 誰がやっても
- どのプロジェクトでも
- どの会社でも
同じ水準で「説明できる」基準 である。
PRMは「評価の共通言語」を作るためのもの
🧩 PRMの構造と思想
🧱 プロセスは「目的」と「成果」で定義される
A-SPICEのPRMでは、各プロセスに対して次の2点が必ず定義されている。
- Purpose（目的） そのプロセスは、何のために存在するのか
- Outcome（成果） その目的が達成されたと判断できる状態は何か
ここで重要なのは、 具体的な作業手順や帳票は一切定義されていない という点である。
PRMに書かれていない手順を「勝手に決めるな」と読むのは誤解
🧭 PRMが定義しているのは「期待される状態」
PRMは、
- 会議のやり方
- ドキュメントの形式
- ツール構成
を指示しない。
代わりに、 「このプロセスが機能しているなら、結果としてこうなっているはずだ」 という状態像だけを示す。
現場に合ったやり方でOutcomeを満たしていれば、問題にならない
🧩 プロセスカテゴリ分解の意味
🧠 なぜこの分類なのか
PRMでは、開発活動を以下のように分類している。
- SYS：システム要求・システム設計
- SWE：ソフトウェア要求・設計・実装・テスト
- SUP：品質保証、構成管理、問題解決など
- MAN：プロジェクト管理、リスク管理
- ORG / PIM / ACQ：組織運営、改善、調達
この分類は、技術分野ではなく 責務と失敗パターン を基準に切られている。
「どこで事故が起きやすいか」を元にプロセスが切られている
🧱 PRMはV字モデルの骨格
PRMは、V字モデルの
- 左側（定義）
- 右側（検証）
を、プロセス単位で対応づけるための骨格でもある。
これにより、
- 要求とテスト
- 設計と検証
が「対応しているか」を 構造として説明できる ようになる。
🛠️ 実務上の意味
📌 PRMを「手順書」として扱うと起きること
PRMをそのまま現場に落とし込み、
- プロセス名＝部署名
- Outcome＝提出物
- Purpose＝建前
として運用すると、次のような問題が起きる。
PRM準拠なのに、なぜか品質事故が減らない
これは、PRMの本来の役割である 「状態を評価する枠組み」 を無視してしまっているためである。
🧠 正しい使い方
PRMは、
- 現場のやり方を縛るためのものではなく
- 現場の説明を助けるためのもの
である。
PRMを理解すると、アセスメント質問の意図が自然に読めるようになる
🧾 まとめ
🎯 このページで伝えたい一点
プロセス参照モデル（PRM）は、 「正しい手順」を押し付ける規格ではない。
「この活動が機能していると言える条件」を定義した評価の物差し それがPRMの本質である。
A-SPICEを理解するとは、 PRMに書かれていないことを想像する力を持つことでもある。