Automotive SPICE 能力レベル３とは何か？ ー それは「プロセスの話」だけではない （前編）
１．はじめに
Automotive SPICE（以下、A‑SPICE）の能力レベル3という言葉から、多くの組織が思い浮かべるのは「組織標準プロセスの整備」や「標準化されたやり方が定義されている状態」ではないだろうか。実際、能力レベル3はそのような文脈で語られることが多い。
しかし、それは能力レベル3がもたらすの“結果の１つ”であって、“本質”ではない。能力レベル3が本来問いかけているのは、プロジェクト依存のやり方から脱却し、組織として仕事の仕方を意図的に設計し、再利用可能な形で運用できているか、という一点に尽きる。そしてこれは、決して個々のプロジェクトの努力だけで到達できるレベルの話ではない。
本来、能力レベル3はプロセス改善モデルの中で、組織としての力を高めていくために、改善を継続的に推進できる状態を指している。プロセス定義は、そのために不可欠な手段の一つではあるが、目的そのものではない。改善を通じて組織力を引き上げるという狙いがあってこそ、プロセスは意味を持つ。にもかかわらず、A‑SPICEの文脈では、能力レベル3が「プロセスを整備したかどうか」という見えやすい側面で捉えられがちであった。その背景には、A‑SPICEがサプライヤー評価モデルとして使われてきた歴史や、プロジェクト中心で読まれやすい構造がある。
本稿では、まず能力レベル3の考え方を起点として、レベル2との決定的な違いを整理し、PPTトライアングル（People・Process・Technology）が示すレベル3の本質を確認する。その上で、なぜA‑SPICEの文脈では、この本質が見えにくくなってきたのかを整理する。なお、本稿は前編として位置づけ、能力レベル3の理解と、その誤解が生まれた背景までを扱う。
２．能力レベル２との決定的な違い ー 「守る」から「設計する」
能力レベル2と能力レベル3の違いは、しばしば「標準プロセスがあるかどうか」や「組織で統一されているかどうか」といった表層的な比較で語られる。しかし、それでは能力レベル3の本質を捉えたことにはならない。
能力レベル2までの世界では、プロセスの主語はあくまでプロジェクトである。
計画を立て、進捗を管理し、レビューを行い、成果物を管理する。つまり、「決められたことを守れているか」「管理が回っているか」というプロセスの状態が焦点となる。言い換えれば、決められたことを守れているか、が問われる世界である。
この段階では、プロジェクトマネージャの力量や、プロジェクト固有の流儀が大きな影響を持つ。うまく回っているプロジェクトは確かに存在し、成果も出る。しかし、それは「そのプロジェクトがうまくいった」という事実に留まり、なぜうまくいったのかが組織として説明できるとは限らない。
能力レベル3で起きるのは、この問いの変化である。
- そのプロセスは、誰が何を意図して設計したのか
- なぜそのプロセスが選ばれているのか
- プロジェクトごとの違いを踏まえ、どのようにテーラリングするのか
- 組織として、プロセスをどのように進化させていくのか
ここで初めて、プロセスは「守るべきルール」ではなく、「意図を持って設計され、使いこなされ、変えていく対象」として扱われるようになる。
レベル3とは、プロセスを単なるルールやチェック対象として扱う段階から、組織の知的資産として扱う段階への転換である。
プロセスを通じて、組織としてどのような仕事の仕方を選び、どのように改善していくのかを考え、実行できる状態に移行することを意味している。
能力レベル2が「プロジェクト運営を安定させる状態」だとすれば、能力レベル3は「組織としての仕事の仕方そのものを設計する状態」であり、質的に異なる段階なのである。
この違いを理解せずに能力レベル3を目指すと、「決め事を増やす」「文書をそろえる」といった活動に陥りやすい。しかしそれは、レベル2の延長線上でできることに過ぎず、レベル3が本来求めている転換点を越えたことにはならない。
３．プロセスだけでは組織は変わらない ー PPTトライアングルが示すレベル３の本質
CMMIの世界では古くから、能力レベル3を説明する際に PPTトライアングル（Process・People・Technology） が語られてきた。これは今でも、能力レベル3の本質を的確に突いた考え方である。
能力レベル3を「組織標準プロセスを整備する段階」と理解してしまう組織が多い理由の一つは、プロセスという要素が最も目に見えやすく、説明もしやすいからだ。しかし、第2章で述べたように、能力レベル3が目指しているのはプロセスそのものではない。組織として仕事の仕方を設計し、継続的に進化させていく力にこそ本質がある。その前提に立つと、「プロセスだけでは組織は変わらない」という現実が見えてくる。
PPTトライアングルは、CMMIなどのプロセス改善のノウハウとして広く知られるようになったが、その考え方自体は新しいものではない。起源をたどれば、リービットのダイヤモンド・モデルに行き着く。リービットのモデルは、組織を「仕事」「人」「技術」「組織構造」という要素の相互作用として捉え、どれか一つだけを変えても、組織は意図したとおりに変わらないことを示したものである。PPTトライアングルは、この考え方をプロセス改善という実務の文脈で簡潔に整理し直したものだと理解できる。
ここでは、PPTを構成する People・Process・Technology の三要素を取り上げる。ただし、これらを独立した要素として説明する意図はない。三つは相互に影響し合いながら、組織としての仕事の仕方を設計・進化させていくための要素である。
People
もっとも重要でありながら、もっとも変化に時間がかかる要素が「人」である。ここで言う「人」とは、単に人数を指すものではない。作業を遂行するためのスキルや技術力、その使い方、さらにはそれを支える文化や価値観を含めた概念である。
能力レベル3で問われる「人」とは、プロセスを守るための存在ではない。実際の作業を確実に遂行するために必要なスキルや技術力を備え、それを継続的に向上させていくことが求められる。人の能力が高まれば、より高度なプロセスや技術が必要となり、その結果としてプロセスも変わっていく。人の成長は、プロセス改善の前提条件である。
Process
プロセスは固定的なルールではなく、人の能力や使われる技術を前提として設計され、必要に応じて見直されるべきものである。誰が何を意図して設計したのか、なぜそのプロセスが選ばれているのかが説明できなければならず、常に改善の対象として意識されていなければならない。人や技術の成熟なしに、プロセスだけを高度化することはできない。
Technology
Technology は、QCD や生産性を向上させるために、設計・実装・テストといった開発活動をどのように支えるかという観点で捉える必要がある。設計やテストに関する新しい技術の導入、使用するツール類の選択、開発環境の整備は、いずれも成果に直結する重要な要素である。
重要なのは、技術やツールを単に導入することではなく、人のスキルや能力、そしてプロセスの設計と整合した形で活用されているかという点である。新しい技術の導入は、必要とされるスキルや作業の進め方を変え、結果としてプロセスの見直しを促す。
この意味で Technology は、People や Process とは独立した要素ではなく、組織として成果を引き上げていくための重要な構成要素である。適切に選択・活用された Technology は、人とプロセスの力を増幅し、QCD や生産性の継続的な向上を支える。
このように、People・Process・Technology は独立して存在するものではない。どれか一つの軸だけが伸びても、組織全体としての成果（QCDや生産性）は頭打ちになる。三つの要素が相互に影響し合いながら、スパイラル的に伸びていく状態を作って初めて、組織の力は継続的に向上していく。
能力レベル3における組織とプロジェクトの関係
組織は、標準プロセス、プロセス部品、テンプレート、ツール、テーラリングガイド、そしてプロセス実績データベースといったプロセス資産ライブラリを整備し、プロジェクトに提供する役割を担う。
プロジェクトは、これらの標準プロセスや過去の実績データを参照しながら、プロジェクトの特性に応じたプロジェクト用プロセスを設計し、それを前提としてプロジェクト計画を作成する。プロジェクトは設計したプロジェクトプロセスに従って運営され、その結果として得られた実績データが、再び組織のプロセス実績データベースに蓄積されていく。
この組織とプロジェクトの間で回るPDCAこそが、能力レベル3における改善の実体である。改善はプロジェクトの中だけで完結するのではなく、組織によって集約され、次のプロジェクトに活かされることで、組織全体としての能力が高まっていく。
帰結として現れるプロセス定義の変化
このような前提でプロセス改善が継続的に行われていくと、プロセス定義の在り方そのものも変わってくる。改善が一過性ではなく、PPTの3要素が組織的に回り始めると、プロセスは単なる手順書の集合では維持できなくなる。どの作業がどの目的を持ち、どの成果に結び付いているのか、そして変更がどこに影響するのかを、組織として把握できる形が必要になるからである。
その結果として、プロセス定義は必然的に、いわゆるプロセスモデリングに基づいた、よりフォーマルな形へと移行していく。ここで言うプロセスモデリングとは、業務や開発における作業の流れや役割、成果物、相互関係を構造的に表現し、変更や改善の影響を組織として把握・管理できるようにすることを指す。具体的な文書化の考え方やテクニックについては、弊社コラム「プロセスモデリング 〜 プロセス文書化のテクニック」も参照していただきたい。
重要なのは、プロセスのフォーマル化そのものが目的なのではなく、改善を継続可能なものにするための自然な帰結として現れる点にある。レベル3におけるプロセスモデリングは、成熟の証明ではなく、改善が組織の中で本当に機能し始めた結果だと言える。
４．なぜ、この誤解は生まれたのか ー Automotive SPICEという枠組みが生んだ構造的なズレ
前章までで見てきたように、能力レベル3は本来、People・Process・Technology を通じて組織としての力を高めていくための入口であり、単なるプロセス定義の段階ではない。しかしA‑SPICEの文脈では、能力レベル3が「組織標準プロセスを整備する段階」として理解されるケースが少なくなかった。
この誤解は、特定の組織や個人の理解不足によって偶然生じたものではない。A‑SPICEというモデルがどのような目的で設計され、どのような文脈で使われてきたかを振り返ることで、その背景は構造的に説明できる。
サプライヤー評価モデルとして使われてきたA‑SPICE
A‑SPICEは、欧州OEMがサプライヤーを評価するための枠組みとして発展してきた。その主眼は一貫して、OEMに影響を与える開発リスクの可視化と低減にある。評価の対象となるのは、あくまで進行中、あるいは予定されているプロジェクトであり、プロジェクトが安定して遂行されるかどうかが最重要関心事であった。
この文脈において、能力レベルは「将来に向けた組織変革の成熟度」を測る尺度というよりも、プロジェクトをどの程度安心して任せられるかを判断するための指標として受け止められてきた側面がある。
プロジェクト視点で読み取られた能力レベル３
こうした文脈の中では、能力レベル３は自然と、
- プロジェクト間で共通に使えるものがあるか
- 標準化されたプロセスが存在するか
といった観点で理解されるようになる。
これは、プロジェクトの安定化という目的に照らせば合理的な読み方であり、誤りと断じることはできない。ただし、この理解はプロジェクトを中心に据えた解釈であり、第3章で述べた「People・Process・Technologyを意図的に育て、組織力を高めていく段階」という能力レベル3本来の姿とは、焦点が異なっている。
このズレが積み重なった結果、能力レベル3は次第に「組織標準プロセスを整備した状態」とほぼ同義に扱われるようになっていった。
組織としての改善が前面に出にくいモデル構造
もう一つ見逃せないのが、A‑SPICEのモデル構造そのものである。
CMMIなどのプロセス改善モデルでは、「組織標準プロセス定義」、「組織プロセス改善」、「組織トレーニング」、「測定と分析」といったプロセスが組織プロセス群として定義されている。一方A‑SPICEでは、唯一「PIM.3（プロセス改善）」プロセスが選択されているだけで、「やるべき活動がわからない」という状態になりやすい。このため、能力レベル3を目指す組織の多くが、
- まずプロセス文書を整える
- プロジェクトでそれを使っていることを示す
というアプローチに集中し、People や Technology、さらには改善を回すための組織的な仕組みが必要だという発想に至るのは容易ではなかった。なお、組織系プロセスが欠落していることの詳細については、A-SPICEの成り立ちや他のプロセス改善モデルとの比較という観点から、弊社の別コラム「Automotive SPICEの活動を効率良く進めるために」で詳細を整理しているので、併せて参照していただきた。。
誤解は「間違い」ではなく「帰結」である
こうして見てくると、A‑SPICEにおける能力レベル3の理解は、誰かが本質を取り違えた結果として生まれたものではなく、A‑SPICEがサプライヤー評価モデルとして設計され、プロジェクトを中心に使われてきたという背景の中で、自然に形成されてきた理解だと言える。
問題は、その理解が固定化され、「能力レベル3＝プロセス定義」というイメージだけが残ってしまった点にある。本来、能力レベル3は、People・Process・Technologyを意図的に育て、組織としてQCDや生産性を継続的に高めていくための出発点に過ぎない。
あらためてレベル3の意味を問い直す
- レベル3はゴールではない ― レベル4・5が示す世界
- 20年後を語る企業と、目の前を語る企業
- プロジェクトフォーカスから、いつ抜け出すのか
- このままで、本当にいいのか
（日吉 昭彦）