Automotive SPICEにおけるプロセスの解釈について（初心者でもわかる！PRM/PAMの正しい理解）
はじめに
私がTier-1サプライヤーに在籍していた2008年、欧州OEMからAutomotive SPICEの能力レベル達成に向けたプロセス改善の要求を受けました。当時は、プロセス改善に関して参考にできる情報が少なく、Automotive SPICEに対する誤解から、誤ったプロセス改善のアプローチを取ってしまっていました。それは、Automotive SPICEのPAMに記載されたBP（基本プラクティス）やGP（共通プラクティス）をそのまま自社のプロセスとしてしまったことです。
誤解による誤ったアプローチとしては、主に以下の２つです。
１． PAMにはWhatのみが書かれており、それを参照するだけでは具体的なHowが欠落し、使いにくいプロセスになってしまいました。
２． PAMに書かれている内容は、プロジェクトの特性やフェーズに関わらず、常に実施しなければならないと理解し、無駄な活動を増やしてしまった。
特に２つ目については、プロジェクトの現場から不満が噴出する結果となりました。
例えば、プロジェクトの初期フェーズにおいて、顧客が要求の変更を頻繁に繰り返している際にも、SYS.1やSUP.10の全BPを厳格に反映した活動が必要だと解釈し、個々の変更依頼に対して厳格な手順（SUP.10）を適用してしまった結果、多くの工数を費やすことになってしまいました。それによって明らかに開発効率が落ちていたのです。今思えば、初期フェーズにおいては顧客要求がある程度固まって、顧客と正式に合意され、要求ベースラインが確立される前は、厳格な変更依頼の手順は不要でした。そのような試行錯誤を繰り返しながら、Automotive SPICEの本質は合理的なプロセス実施であることに気づくことができました。
現在はコンサルタントの立場で様々な顧客の開発現場をご支援しておりますが、その中には以前の私と同様の誤解をされているケースも見かけます。また、私の誤解としてご紹介した以外で、私がよく目にするケースとして、PAMのプロセスの区分けにそのまま従ってしまったために、使いにくいプロセスになってしまっているケースがあります。MAN.3やSWE.3、4あたりはその傾向が強いのですが、特にSWE.3については傾向が顕著です。PAMでは、SWE.3に「ソフトウェア詳細設計」と「コーディング」が含まれます。これはあくまでもV字左側の要件、設計プロセスと右側の検証系プロセスの水平方向の位置づけを分かりやすくするためのPAM上の構造です。このSWE.3に含まれる「ソフトウェア詳細設計」と「コーディング」を単一のプロセスとして定義してしまうとどうなるでしょうか。本来は、ソフトウェア詳細設計が行われ、設計書に対するレビューが完了し、設計完了としてのベースラインが確立された上で、そのベースラインに基づいてコーディングが開始されます。しかし、無理やりSWE.3としてプロセスを定義してしまったために、ソフトウェア詳細設計書に対するレビューとソースコードに対するレビューがまとめて実施されるようなプロセスになっている場合があります。しかも、ソースコードレビューはPAM上ではSWE.4の一部として位置付けられるため、検証の観点も曖昧になりやすくなります。
このように、PAMはプロセスの区分けを標準プロセスとして使いやすい形に構造化しているわけでもありませんので、SWE.3の枠にとらわれることなく、必要な検証も含めてソフトウェア詳細設計、コーディングのプロセスをそれぞれ位置付ける必要があります。
以降では、プロセス改善を推進する上でのAutomotive SPICE PRM/PAMの正しい解釈について整理していきたいと思います。
PRMとPAMの正しい理解
多くのエンジニアがPRM/PAMについて抱いている印象と、真の姿には大きなギャップがあります。「Automotive SPICEは厳格で融通が利かない」「決められた手順通りにやらなければならない」といった印象を持たれがちですが、実際のPRM/PAMは驚くほど柔軟で実用的な設計思想に基づいています。
それらを理解するうえで、表1ではAutomotive SPICEでのPRM/PAMの概要をおさらいします。次の表2では、プロセスをカレー料理のレシピに例えて理解を深めていきましょう。
PRM（プロセス参照モデル）
開発で必要な活動を論理的にグループ化し関連する活動をまとめて「プロセス」という単位で整理したものです。そのプロセスが達成すべき成果を提供します。
（下図赤の棒線部分です）
PAM（プロセスアセスメントモデル）
それらのプロセス（PRM）がきちんと機能しているかを測るための「ものさし」です。アセスメント（評価）のための指標を提供します。
（下図緑の棒線部分です）
＜表1：Automotive SPICE PRM/PAMの概要＞
出典：『Automotive SPICE プロセス参照モデル プロセスアセスメントモデル Version 4.0』
PRM（プロセス参照モデル）
目的のカレーを提供するために、最低限出来ているだろう料理過程での成果が「何」のレベルで書かれています
このリストは、誰が、どこのキッチンで作ろうとも共通する、普遍的な目的と成果であり、これがPRMの考え方です
PAM（プロセスアセスメントモデル）
左記の「プロセス成果」が、あなたの料理でどれだけ達成できたかを測るための「ものさし（評価基準）」で、具体的なチェック項目（指標）が書かれています
この「ものさし」を使って、あなたのカレーが成果を達成しているかを客観的に評価します
＜表2：Automotive SPICE PRM/PAMを料理に例えて ～レシピとものさしの話～＞
多くの現場で起こりがちな誤解は、この「ものさし（PAM）」を「最高のレシピ（開発プロセス）」そのものだと勘違いしてしまうことです。「ものさし」は、あくまで評価の単位です。自分たちのキッチン（現場）に合った、最も効率的で品質の高い「秘伝のレシピ（開発プロセス）」をまず確立すればよいのです。アセスメントでは、その「秘伝のレシピ（開発プロセス）」が、結果として「ものさし」のチェック項目をクリアできていることを説明すれば良いのです。
ここまで、大まかにご理解いただけたと思います。更に正しく理解いただくために、よくある誤解を解きながらPAMの本質を整理していきましょう。
PAMの本質を整理する
• PAMは標準プロセスではありません：
多くの方が勘違いされやすいのですが、PAMは「測定するためのものさし」であり、そのまま開発プロセスとして使うものではありません。
• 「どうやるか（HOW）」ではなく、「何を達成するべきか（WHAT）」：
PAMが教えてくれるのは具体的な手順ではなく、達成すべきゴールです。実際のやり方は、皆さんの組織やプロジェクトに合わせて自由に決めていただけます。
• 実施する順序も自由：
PAMは作業の順序を定義したものではありません。アジャイルでも従来の開発スタイルでも、現場に最も適した流れで進めることができます。
• 作業成果物の形も自由に：
特定の成果物の構造を強要していません。今お使いの社内資料の形式をそのまま活かしていただけます。
• 一貫性こそが重要なポイント：
これだけの自由度がある一方で、PAMが最も大切にしているのは「一貫性」です。この点さえ押さえていれば、形式にとらわれず本当に価値のある品質向上に取り組んでいけます。
※「一貫性」につきましては、過去のメルマガ「Automotive SPICEにおけるプロセスの解釈について（トレーサビリティ）」も合わせてご参照ください。
まとめ
いかがでしたでしょうか、PRM/PAMを正しくご理解いただけたでしょうか？
Automotive SPICEは皆さんの開発を制約するものではなく、品質向上のための道しるべです。プロセス構築や改善活動で本当に大切なのは、「ものさし」を眺めて形だけのプロセスを作ることではありません。現場の実態に合った最高の「レシピ」を追求し、その結果として「ものさし」の基準をクリアすることをご理解いただけたと思います。正しく理解し、この順番を間違えないことが、形骸化しない、本当に価値のあるプロセス構築・改善の鍵となるのです。
本メルマガを最後までお読みいただきありがとうございます。
「PRM/PAMは理解できたものの、プロセスを見直したいがどこから手を付けてよいかわからない」といった困りごと等ございましたら、まずは簡単なご相談でも結構ですので、お気軽にお問い合わせいただけたら幸いです。
2025/6/19 牛込 一安