ビジネスガレージ株式会社

Automotive SPICE レベル3を“現場視点”で解説する動画コンテンツを公開

当社では、Automotive SPICEに関する知見を発信する取り組みとして、ショート動画シリーズの配信を開始しました。本シリーズは、「Automotive SPICE 能力レベル３とは何か？ ― それは『プロセスの話』だけではない」の記事内容をベースに、現場での実践を踏まえて再構成したものです。前編：Automotive SPICE 能力レベル３とは何か？ーそれは「プロセスの話」だけではない（前編） - ビジネスガレージ株式会社後編：Automotive SPICE 能力レベル３とは何か？ーそれは「プロセスの話」だけではない（後編） - ビジネスガレージ株式会社単なるモデル解説ではなく、・なぜ形式的な適用では評価につながらないのか・レベル3で問われる実態とは何か・組織として達成すべき状態とは何かといった観点から解説しています。現在3本を公開しており、今後もシリーズとして継続予定です。Automotive SPICEの導入・改善に取り組まれている方は、ぜひご覧ください。

コラム

2026/05/21

日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか（前編）　〜　生産性向上と品質維持に向けた提言　〜

１．なぜ、車載ソフトウェア開発にDRBFMが使われているのか日本の車載ソフトウェア開発では、DRBFM（Design Review Based on Failure Mode）が当然のように使われている。これは筆者にとって、驚き以外の何ものでもない。そもそもDRBFMは、「機械部品」の設計変更や環境変化に伴うリスクを洗い出すために生まれた手法である。「ボルトの径を変えた」、「材質を変えた」、「使用条件が変わった」。そうした物理的な変化点を起点に、摩耗や破断といった実体のある故障モードを徹底的に深掘りすることに、その本質的な価値があった。ではなぜ、その手法がソフトウェア開発に使われ続けているのか。なぜ「コード一行の変更」を、「機械部品の設計変更」と同じ発想で扱わなければならないのか。この問いに、工学的に納得できる明確な説明を聞いたことがない。実際の開発現場では、今もなお多くの技術者が相当な時間と労力をかけてDRBFMを実施している。「故障モードを〇〇個出せ」「もっと深掘りできるはずだ」「宇宙線によるビット反転が起きたらどうするのか」。そうした指摘が飛び交い、現実にはほとんど起こらない事象まで含めて、延々と議論が続く。DRBFMは、本来の「変更点に着目した検討」という枠を超え、起こるかどうか分からない最悪事象を列挙する儀式になってしまっているのではないだろうか。あまりに負担が大きいため、「ここまでやる必要が本当にあるのだろうか？」と疑問を投げかけると、返ってくる答えは、ほぼ決まっている。「上司の指示だから」、「会社のルールだから」。そこには、技術的な必然性よりも、慣習や前例を優先する空気が色濃く見て取れる。技術革新のスピードは年々加速し、開発は急速にグローバル化している。各国のエンジニアが分業し、並列に開発を進めることが当たり前になった現在、このような開発スタイルを続けていて、本当に日本製品の優位性は保てるのだろうか。ソフトウェアが車の価値を決め、ソフトウェアの開発スピードが競争力の源泉になるSDV時代において、「ソフトウェアの変更点を人間が集まって延々と深掘りする」という方法論は、生産性・品質の両面で限界に達していると筆者は考えている。問題は、個々の技術者の能力や意識ではない。前提としている開発思想そのものが、すでに時代と乖離し始めているのである。本コラムで扱おうとしているテーマは、いわば「触れてはいけない」とされがちな領域である。日本の車載ソフトウェア開発において長年 “当たり前” として受け入れられてきたDRBFMを、工学的・構造的な視点から問い直すことは、少なからず反発を招く話でもある。しかし、この違和感に目をつぶり続けたままでは、議論はいつまで経っても現場の苦労話や精神論に留まり、何も変わらない。そこで今回は、この問題に正面から踏み込むため、あえて前編・後編の二部構成という形を取ることにした。前編では、なぜソフトウェア開発においてDRBFMがここまで重く運用されるようになったのか、その技術的背景と、日本特有の開発文化・構造を整理する。現場で起きている「無限の深掘り」による疲弊が、個々の技術者の問題ではなく、どのような前提の上に生まれているのかを明らかにしていく。そして後編では、視点を一度外に移し、世界では同じ課題にどう向き合っているのか、なぜDRBFMがソフトウェア開発で使われていないのかを見ていく。その上で、この先どの地点を目指すべきなのかを考えたい。これは手法の是非を問う話ではない。日本の車載ソフトウェア開発が、これからも競争力を持ち続けるために、何を疑い、何を変えるべきかを考えるための議論である。２．DRBFMは本来ハードウェアの手法だった — メカ開発の成功体験が生んだミスマッチ前章では、ソフトウェア開発の現場でDRBFMが儀式化し、技術者を疲弊させている実態を見てきた。では、なぜそもそもこのような違和感が生じるのか。その答えは、DRBFMという手法のルーツにある。DRBFM（Design Review Based on Failure Mode）は、その名の通り「故障モード」を起点として設計変更のリスクを洗い出す手法である。そして重要なのは、この手法が機械部品を中心としたハードウェア開発のために生まれたという事実だ。ハードウェアの世界では、DRBFMは極めて合理的に機能する。ボルトの径を細くした、材質を変えた、使用温度範囲が広がった。そうした「変化点」から、摩耗、クラック、破断、漏れといった物理的な故障モードを因果関係として追っていくことができる。部品は実体を持ち、力の流れや劣化のメカニズムも説明可能だ。この世界では、「どこまで深掘りすべきか」は明確であり、深掘りそのものが品質向上に直結する。一方、ソフトウェアはまったく異なる性質を持つ。ソフトウェアには摩耗も劣化もない。故障の正体は、ほぼ例外なく設計ミス、すなわちバグである。「なぜ壊れたのか」を物理現象として説明できるハードウェアと違い、ソフトウェアの不具合は論理の誤り、前提の勘違い、仕様の曖昧さ、考慮漏れといった人間の思考に起因するものだ。この本質的な違いを無視したまま、ハードウェア由来のDRBFMをソフトウェアに適用すると、問題が生じる。物理部品のDRBFMでは意味を持っていた「深掘り」が、ソフトウェアでは行き場を失うからだ。変数の型変更、条件分岐の追加、タイミングの微調整など、こうした変更点から「どの段階まで故障モードを掘り下げるべきか」を、物理的な根拠なしに決めることはできない。結果として、ソフトウェアDRBFMでは次のような現象が起きる。論理的にはあり得るが、確率的には極めて低い事象までが同列に扱われる。最終的には「宇宙線によるビット反転」や「OSの内部不具合」といった、設計者が制御不能な領域にまで議論が及ぶ。ハードウェアであれば「そこから先は部品設計や材料特性の問題」として切り分けられていた議論が、ソフトウェアでは切り分けられないままDRBFMの中に押し込まれてしまう。本来、こうした問題の解決はソフトウェアアーキテクチャの役割である。エラー検知、フェイルセーフ、リカバリーの設計によって、「起きても安全に処理できる」状態を構造として担保するべき領域だ。しかし、アーキテクチャという抽象的な仕組みへの信頼が十分に確立されていない場合、その代替として「とにかく心配事を洗い出す」DRBFMが肥大化していく。ここで強調しておきたいのは、DRBFMそのものが悪いわけではない、という点である。DRBFMは本来、ハードウェア開発において大きな成果を上げてきた優れた手法だ。問題は、その成功体験をほぼ無批判にソフトウェアへと移植し、本質的な違いを考慮せずに運用してきたことにある。ソフトウェア開発におけるDRBFMは、ハードウェアの作法をそのまま当てはめた結果、生まれたミスマッチの産物と言える。そしてこのミスマッチこそが、現場で語られる「終わらない深掘り」「何のためのレビューなのか分からない」といった違和感の正体なのである。では、なぜ日本の車載ソフトウェア開発では、このミスマッチを抱えたままDRBFMが使われ続けてきたのか。次章では、その背景にある日本特有の設計文化と意思決定構造について掘り下げていく。３．なぜ日本の車載ソフトウェアではDRBFMが生き残ったのか－すり合わせ文化とハード主導の設計思想前章で見てきたように、DRBFMは本来ハードウェア開発のための手法であり、ソフトウェア開発と相性が良いとは言えない。それにもかかわらず、日本の車載ソフトウェア開発では、DRBFMが長年にわたって当然のように使われ続けてきた。この背景を説明するために、「DRBFMの優劣」や「現場の努力不足」に話をすり替えてはいけない。ここで問うべきなのは、なぜ日本の開発現場では、この違和感を抱えたままでもDRBFMに頼らざるを得なかったのかという点である。ハード屋とソフト屋の「共通言語」としてのDRBFM日本の自動車メーカーでは、長年にわたってハードウェア中心の開発が行われてきた。品質保証、設計審査、意思決定の枠組みも、その多くはハードウェア開発で成功した方法論をベースに構築されている。その中でDRBFMは、「変更点に着目してリスクを洗い出す」という分かりやすい思想を持つ、極めて都合の良い共通言語だった。メカ設計者にも、電気設計者にも、そしてソフトウェア設計者にも、「今回どこを変えたのか」「それによって何が起き得るのか」を同じフォーマットで説明させることができる。本来であれば、ソフトウェアの機能や品質は要求仕様書やアーキテクチャ設計書を通じて説明されるべき存在だ。しかし、それらのドキュメント文化が十分に整備されていない環境では、DRBFMが部門を超えた意思疎通のための代替手段として機能してしまう。結果として、DRBFMは品質手法というよりも、「みんなが理解できる説明の形式」として定着していったのではないか。意思決定層がハード出身であるという構造的問題もう一つ無視できないのが、意思決定層のバックグラウンドである。日本の自動車開発において、開発責任者や品質保証部門の多くは、長年ハードウェア開発に携わってきた人たちである。彼らにとって、DRBFMは「品質を作り込むための正統な手法」であり、それによって数多くの成功体験を積み重ねてきた。一方で、ソフトウェアアーキテクチャや自動テスト、CI/CDといった概念は、必ずしも直感的に理解しやすいものではない。その結果、意思決定の場ではどうしても、「目に見える」「議論できる」「紙に書ける」DRBFMが重視される。ソフトウェア側が「アーキテクチャで担保している」と説明しても、それが完全には信用されず、「ではDRBFMで確認しよう」という結論に落ち着きやすい構造が生まれてしまう。「ネジ一本」と「コード一行」を同列に扱う設計変更思想車載ソフトウェアが問題をさらに複雑にしているのは、ソフトウェアがすでに車の中核機能を担っているという事実である。ブレーキ、ステアリング、パワートレイン制御など、「走る・曲がる・止まる」の多くがソフトウェアによって制御されている。このため、「ネジ一本を変えること」と「コード一行を変えること」を同じ重みの「設計変更」として扱わなければ危険だ、という考え方が強く根付いた。安全を最優先するという点では、この思想自体は理解できる。しかしその結果、ソフトウェア開発が本来前提としている「アーキテクチャによる影響範囲の局所化」、「テスト自動化による回帰検証」、「反復的な変更を許容する開発スタイル」といった要素が十分に考慮されないまま、「変更したのだから徹底的に不安を潰すべきだ」という発想だけが肥大化していった。リコールコストという「恐怖」が生んだ過剰な保守性このような構造の背景には、車載開発特有の“恐怖”もある。一度市場に出た製品で不具合が見つかれば、数百万台規模のリコールにつながり、企業に甚大な損失をもたらす。この失敗コストの大きさが、「万が一を見逃すより、やり過ぎる方が安全だ」という判断を正当化してきた。そしてDRBFMは、その「やり過ぎ」を制度として固定化するための、極めて都合の良い枠組みだった。結果としてDRBFMは、リスクを減らすための工学的手法というよりも、これだけやったのだから大丈夫だと言える材料誰か一人の判断にしないための責任分散装置としての性格を強めていったのであるここまで見てきたように、DRBFMが日本の車載ソフトウェア開発に生き残ったのは、偶然ではない。文化、組織、意思決定構造、そして恐怖――それらが絡み合った結果として、DRBFMは“必要不可欠なもの”に見える存在へと変質していった。そしてこの構造の帰結として、現場には「どこまで深掘りすれば終わるのか分からない」DRBFMが残ることになった。次章では、その象徴的な姿である「無限深掘り」という地獄について、さらに踏み込んでいく。４．ソフトウェアDRBFMが生む「無限深掘り」という地獄前章までで見てきたように、DRBFMは本来ハードウェア開発の文脈で成立してきた手法であり、日本の車載ソフトウェア開発では、その前提が十分に吟味されないまま持ち込まれてきた。その結果として現場に現れるのが、多くの技術者が口を揃えて語る「終わらないDRBFM」、すなわち無限深掘りという状態である。この無限深掘りは、単なる運用ミスや一部現場の暴走ではない。ソフトウェアという対象と、DRBFMという手法の組み合わせがもたらす構造的な帰結である。ハードウェアDRBFMとソフトウェアDRBFMの決定的な違いハードウェア開発におけるDRBFMでは、「深掘り」は品質向上に直結する行為だ。ボルトの径を細くする、材質を変える、使用条件を厳しくする。そうした変化点から、応力集中、疲労、破断といった故障モードを因果関係として追っていくことができる。物理現象に基づくため、「どこまで掘れば十分か」という判断にも、経験則や工学的裏付けが存在する。一方、ソフトウェアにはこのような「物理的な終点」が存在しない。条件分岐の変更、変数型の変更、タイミング調整といった変更点から不具合を想像することはできるが、その連鎖は理論上いくらでも続いてしまう。ハードウェアDRBFMでは、「そこから先は現実的に起こらない」と線を引ける。しかしソフトウェアDRBFMでは、「理論上は起き得る」という一言で、議論を次の階層へ進めることができてしまう。この違いこそが、ソフトウェアDRBFMを終わりのない作業へと変質させる最大の要因である。なぜ「何段階まで深掘りするのか」が決まらないのかソフトウェアDRBFMが最も苦しいのは、「どこで止めるべきか」を判断する共通基準が存在しない点にある。ハードウェアであれば、材料強度、設計マージン、規格といった形で、深掘りを打ち切るための工学的根拠が共有されている。しかしソフトウェアでは、「アーキテクチャで影響は限定されている」「この層でフェイルセーフする」といった説明が、必ずしもレビューの場で十分な納得材料として機能しない。結果として、「ではそれが壊れたらどうなるのか」「もし検知できなかったらどうするのか」という問いが繰り返され、議論は自然に次の階層へと進んでいく。問題は、この問い自体が論理的には正しいことだ。完全に間違っていないがゆえに、誰も「そこまでで十分だ」と言い切ることができず、深掘りを止める責任を取りたがらない。こうしてDRBFMは、不安が完全になくなるまで続けるべき検討へと変質していく。宇宙線・ビット反転問題が象徴する「議論の暴走」ソフトウェアDRBFMの象徴的なトピックとして、しばしば持ち出されるのが「宇宙線によるビット反転」である。車載環境においてソフトエラーが実際に発生することは事実であり、この現象そのものを否定することはできない。しかし、この話題がDRBFMの場に登場した瞬間、議論の性質は変わる。それはもはや「今回の設計変更による影響」を検討する場ではなく、「このシステムは絶対に壊れないと言えるのか」という問いへとすり替わる。ビット反転が起きたらどうするのか。検知できなかったらどうなるのか。検知機構自体が壊れたらどうなるのか。これらの問いは理論上いくらでも連鎖し、しかも設計担当者が直接制御できない領域へと踏み込んでいく。にもかかわらず、それらがDRBFMという枠組みの中で同一平面に並べられることで、現場には「どこまで考えれば許されるのか分からない」という疲弊だけが残る。本来アーキテクチャで解決すべき問題まで、DRBFMに押し込めている現実ここで本来問われるべきなのは、役割分担である。宇宙線やランダムエラーへの対処は、個別機能のDRBFMで毎回検討すべき話ではない。それはプラットフォームやアーキテクチャの責務として、一度決めた前提のもとで扱われるべき問題だ。ソフトウェア開発が本来前提としているアーキテクチャによる影響範囲の局所化、テスト自動化による回帰検証、そして反復的な変更を許容する開発スタイルが十分に信頼されていれば、DRBFMが無限に深掘りされることはない。しかしその前提が共有されていない、あるいは信用されていない場合、あらゆる不安がDRBFMという一枚の表に集約される。アーキテクチャで扱うべき話も、運用ルールとして決めるべき話も、最終的には「DRBFMで説明してください」という形で押し戻されてしまう。こうしてDRBFMは、本来の役割である「変更点に着目した設計レビュー」を超え、あらゆる不確実性を一度の会議で解消しようとする万能装置になってしまう。結果として残るのは「終わらせたという安堵感」と引き換えに失われた膨大な時間だけである。ここまで見てきたように、ソフトウェアDRBFMが「無限深掘り」という地獄に陥るのは、現場の技術者が未熟だからでも、真面目さが足りないからでもない。それは、ハードウェア起点で生まれた手法を、性質の異なるソフトウェアに適用し続けてきた結果として、ほぼ必然的に生じた現象である。DRBFMは本来、変更点に着目して設計上のリスクを洗い出すための手法だった。しかし日本の車載ソフトウェア開発では、アーキテクチャや工学的な前提への信頼が十分に共有されないまま、あらゆる不安をDRBFMという一つの場に集約しようとしてきた。その結果、DRBFMは「設計レビュー」ではなく、「起こり得るすべてを想像し尽くすための儀式」へと変質してしまったのである。重要なのは、これはDRBFMそのものの是非を問う話ではない、という点だ。問われているのは、日本の車載ソフトウェア開発が、ソフトウェアをどのような工学対象として捉え、品質と安全性をどのレイヤーで担保するのかという前提そのものである。前編では、日本の車載ソフトウェア開発の内部構造に目を向け、なぜDRBFMがここまで重く運用され、現場を疲弊させる存在になったのかを整理してきた。では、同じ「ソフトウェア」という技術を扱いながら、世界はこの問題にどのように向き合ってきたのだろうか。なぜ車載以外のソフトウェア開発では、DRBFMのような手法が品質保証の中心に据えられることはないのか。そして日本の車載ソフトウェア開発は、この先どの地点を目指すべきなのか。後編では視点を一度外に移し、グローバルなソフトウェア開発の前提や設計思想を踏まえながら、DRBFMを前提としない品質保証がどのように成立しているのか、そしてDRBFMと距離を取るための現実的な道筋について考えていく。（日吉昭彦）

Automotive SPICE 能力レベル３とは何か？　ーそれは「プロセスの話」だけではない　（後編）

前編では、能力レベル3の本質が「プロセス定義」だけではなく、People・Process・Technology を通じて組織として改善が回り始める状態にあること、そしてAutomotive SPICE（以下、A-SPICE）の文脈では、なぜその本質が見えにくくなってきたのかを整理してきた。前編はこちらから。後編では、その理解を前提として、能力レベル3の先に位置づけられるレベル4・5が何を意味するのか、さらにそれが事業運営や競争力とどのようにつながっていくのかを考えていく。５．レベル３はゴールではないーレベル４・５が示す世界能力レベル3は、組織として改善を回し始めるための重要な節目である。しかし、それは決して到達点ではない。むしろ、改善がようやく自律的に回り始めた状態に過ぎない。レベル3に到達した組織では、改善はもはや個々のプロジェクトの工夫に依存するものではなく、組織の仕組みとして回り始める。標準プロセスやプロセス資産が整備され、プロジェクトはそれを前提として運営され、実績は組織に還元される。前編で見てきたのは、まさにこの状態であった。しかし、改善が回り始めることと、組織がどこへ向かって進んでいるかは別の問題である。能力レベル3の段階では、関心の中心は依然として「やり方」にある。どのプロセスを使っているか、標準は守られているか、改善活動が実施されているかといった点が議論の主軸になる。能力レベル4・5の世界では、この関心の置きどころが変わる。ここで重要なのは、改善がより高度になることではない。組織の視線そのものが変わるという点にある。この視線の違いは、データの使われ方に最も端的に現れる。能力レベル3までにおけるデータの扱いは、主として過去を振り返るためのものである。どのプロセスがうまく機能したのか、どこに問題があったのかを確認し、現状を把握するために用いられる。このデータの使い方は、自動車で言えばバックミラーを見る行為に近い。過去に何が起こったかを確認し、その結果をもとに現在の状況を判断する。一方、能力レベル4に進むと、データの意味合いが変わる。レベル4では、プロジェクトやプロセスの実行結果が定量的に捉えられ、ばらつきが管理される。品質、工数、納期といった指標が過去の実績と結び付き、組織として「予測可能な状態」に近づいていく。ここでの特徴は、データが単なる記録ではなく、意思決定の材料として使われ始める点にある。この段階でのデータの役割は、バックミラーではなくナビゲーションに近い。過去の実績をモデル化することで、将来どのような結果が起こり得るのかを見通し、その上で進路を選択するために使われる。さらにレベル5では、そのデータを用いて、組織としてどこを改善すべきか、どこに投資すべきかが議論されるようになる。改善は「現場の工夫」ではなく、組織として選択される活動になる。この段階では、改善テーマがプロジェクトの中だけで完結することはほとんどない。重要なのは、ここで求められているのが「高度なプロセス技法」ではないという点である。レベル3まではプロセスの設計や運用が議論の中心だったのに対し、レベル4・5では、組織の視線がプロセスそのものから事業成果へと移っていく。改善はもはや目的ではなく、事業を成り立たせ、競争力を維持・強化するための手段として扱われるようになる。この意味で、能力レベル3をゴールとして捉えてしまうと、組織は改善のやり方を洗練させるところで立ち止まりやすい。一方、能力レベル3を通過点と捉えた組織は、その先で「改善を何のために行うのか」という問いに直面することになる。次章では、この視点の違いが、実際の組織ではどのような差として現れるのかを、具体的な経験をもとに見ていく。６．20年後を語る企業と、目の前を語る企業能力レベル4・5が示している本質が、手法や技術の高度化ではなく「組織の視線の向き」であるとすれば、その差はどこに最もはっきりと現れるのだろうか。その一つの答えは、組織が何を語っているか、もう少し言えば、どれだけ先の話をしているかにある。筆者が北米のあるCMMIレベル5企業を訪問したのは、今から20年以上前のことである。先進的なプロセス改善の現場を見る機会を得て、多くの示唆を受けたが、今でも強く印象に残っているのは、プロセスそのものではなく、そこで交わされていた会話の内容である。その企業では、SEPG（Software Engineering Process Group）に属する人材が、プロセスの話と同じ熱量で、事業の話をしていた。彼らが語っていたのは、「次のプロジェクトをどう回すか」ではなく、「この事業を10年後、20年後にどういう姿にしたいのか」という問いだった。プロセス改善は頻繁に話題に上ったが、それは決して目的ではなかった。改善は、商品競争力をどう高めるか、市場でどのポジションを取るのかといった議論の中に自然に組み込まれていた。プロセスは、事業の意思を実現するための手段として語られていたのである。興味深かったのは、こうした議論を主導していたSEPGのメンバーの多くが、経営学やビジネスの素養を持っていた点である。中にはMBAを取得している人材もおり、プロセスと事業の話を行き来しながら議論することが、ごく自然なこととして行われていた。一方で、筆者がこれまでに見てきた多くの組織では、状況はかなり異なる。そこでは、SEPGはプロセスを定義し、維持し、評価対応を行う組織として位置づけられることが多い。語られる話題は、「このプロセスで問題はないか」「監査に耐えられるか」「定義が最新か」といったものが中心になる。もちろん、こうした活動自体が無意味なわけではない。前編で述べた通り、能力レベル3までの世界では、これらは不可欠な役割である。しかし、その状態に留まる限り、組織の議論はどうしてもプロセスの内側に閉じてしまう。ここに、能力レベル3とレベル4・5の間に横たわる大きな断層がある。能力レベル3では、改善は回っている。しかし、その改善がどこへ向かうためのものなのかは、必ずしも明確ではないことが多い。改善は改善として正当化され、「なぜそれをやるのか」という問いは後回しにされがちになる。これに対し、能力レベル4・5の組織では、改善は常に別の問いと結び付けられている。「それは事業にどう寄与するのか」「競争力の源泉になるのか」「投資する価値があるのか」。プロセス改善は、こうした問いに答える一つの選択肢として扱われる。この違いは、組織文化にも強く影響する。目の前のプロジェクトや、直近の評価結果を語る組織は、通常、改善の視野も短期に留まる。問題があれば対処するが、その積み重ねがどこへ向かうのかは共有されにくい。一方、長期の時間軸で話をする組織では、改善は最初から「積み上げていくもの」として位置づけられる。ここで注目すべきなのは、この差がプロセス技術の巧拙から生まれているわけではないという点である。多くの場合、違いを生んでいるのは、誰が改善を語っているのか、そして何の文脈で語っているのかである。能力レベル4・5に到達した組織では、改善を語るSEPGが、同時に事業の文脈を語ることができる。逆に言えば、改善の議論がプロセスの範囲に閉じている限り、組織は能力レベル3の先に進むことが難しい。次章では、この問題を個々の人材の能力論としてではなく、組織構造や役割設計の問題として捉え直す。なぜ多くの組織は能力レベル3を維持できず、再びレベル1・2に戻ってしまうのか。一方で、なぜ一度能力レベル4に到達した組織は、その水準を下回ることがほとんどないのか。その違いを考えていく。７．プロジェクトフォーカスから、いつ抜け出すのか第6章では、能力レベル4・5に到達した組織の姿を見てきた。そこでは、改善は単なるプロジェクトの成果や品質向上としてではなく、組織や事業の言葉として語られていた。改善は、個々の善意や努力に委ねられる、いわゆるボトムアップ的なものではなく、経営の意図として位置づけられ、組織全体に引き受けられるべき営みとして扱われていた。では、なぜ多くの組織は能力レベル3に一度は到達したように見えても、それを維持できず、再びレベル1・2に戻ってしまうのか。一方で、なぜ一度能力レベル4以上に到達した組織は、その水準をほとんど下回らないのか。この違いは、個々の人材の能力や現場の頑張りによって生じているものではない。能力レベル3の段階では、フォーカスはすでにプロジェクトから組織に移っている。標準プロセスは整備され、改善活動も行われている。「やっていない」わけではない。それにもかかわらず、能力レベル3は不安定になりがちで、維持されにくい。問題は、改善そのものの量や手法ではなく、改善とどう向き合ってきたか、その向き合い方にある。日本の組織は、長年にわたり、課題が顕在化してから対処する「課題解決型の改善」に強みを持ってきた。品質問題が発生すれば徹底的に原因を究明し、個別のプロジェクトとしては高い完成度に持っていく。その力は、世界的に見ても極めて高い水準にあった。一方で、A-SPICE や CMMI に代表されるプロセス改善モデルに対して、世界で確立されつつあるベストプラクティスを、そのままの形で学び、自分たちの事業に引き直して引き受けるという向き合い方は、必ずしも強くなかった。これらのモデルは、もともと欧米の研究者が日本の製造業、とりわけ生産方式とカイゼンを徹底的に研究し、曖昧になりがちなノウハウや暗黙知を理論化・形式知化しようとした試みから生まれている。言い換えれば、CMMI や A-SPICE は、「日本のやり方を否定するためのもの」ではなく、日本の強みを世界基準で捉え直し、誰もが再現できる形にするためのグローバル標準として発展してきたものである。しかし日本では、それらのモデルはしばしば評価対応や要求対応の道具として理解され、プロジェクト単位で真面目に適用されてきた。課題解決型の改善が得意であったがゆえに、目の前の問題に対応することに重心が置かれ、外部で積み重ねられてきた改善の知を、経営として引き受け続けるという営みは、必ずしも中心的な関心にはなりにくかった。その結果、改善は「できる人」「頑張る人」に依存しやすく、組織として守られるものにはならない。忙しさや人事異動、環境変化が起きれば、優先順位は下がり、能力レベル3の状態は容易に崩れてしまう。これは、改善が個人の姿勢や努力に委ねられ、組織としての役割や責任として設計されていないことを意味している。一方、能力レベル4以上に到達した組織では、改善は善意や努力に委ねられていない。改善は事業を回し続けるための前提条件として位置づけられ、経営の意思と役割の中に組み込まれている。だからこそ、一度その段階に入ると、元の状態に戻ることがほとんどない。日本の経営者が将来を考えていなかったわけではない。むしろ、日本の自動車産業は長年にわたり、世界的に見ても高い競争力を維持してきた。ただし、その成功体験があまりにも強かったがゆえに、ソフトウェアという分野において世界の最先端がどこまで進んでいるのかと、正面から向き合う必然性が見えにくかったという側面は否定できない。能力レベル3が維持できない理由は、手法やプロセスが足りなかったからではない。グローバル標準として確立された改善モデルと、経営としてどこまで真剣に向き合い、それを自分たちの事業として引き受ける覚悟があったかどうかにある。こうした違いを分けているのは、時間でも経験年数でもない。プロジェクトフォーカスから抜け出せるかどうかの分岐点は、経営層が A-SPICE のようなプロセス改善モデルを、評価対応ではなく、事業と組織を設計するためのグローバルスタンダードとして理解し、組織的な活動を自ら主導するかどうかである。その前提に立った瞬間、能力レベル3は「分からない概念」ではなく、「組織の振る舞い」として認識できるようになる。８．このままで、本当にいいのか？ここまで、能力レベル3とは何か、そしてそれがなぜ分かりにくかったのかを見てきた。能力レベル3は、プロジェクトをうまく回すための段階ではなく、プロジェクトを素材として、組織としての仕事の仕方を設計し、学習を回し始める状態である。そして、その正体はプロジェクトの中では決して見えない。それでも、これまで多くの組織はプロジェクト中心の見方に留まり続けてきた。それは誤りだったからではない。組込みソフトウェアが長らく“無償に近いもの”として扱われ、製品価値の中心がハードウェアにあった時代には、その立ち位置で事業が成立してきたからである。しかし、状況はすでに変わっている。Teslaを見れば分かるように、ソフトウェアは機能の集合体ではなく、事業そのものになりつつある。ADAS、そしてSDVの世界では、製品価値や競争力はソフトウェアによって定義される。ソフトウェアは価値として問われ、有償化の時代に入りつつあり、欧米との直接競争も、もはや避けられない現実である。この環境において、プロジェクト単位での対応を積み重ねるだけで十分なのか。評価要求に応え続けるだけで、事業としての競争力は維持できるのか。ここで問われているのは、やり方ではなく立ち位置である。能力レベル3はゴールではない。それは、レベル4・5で事業を回すための最低限の土台に過ぎない。能力レベル3を「分からない概念」のままにしておくのか。それとも、組織として引き受け、次の段階へ進む準備を始めるのか。これは評価の都合や一部のプロジェクトの事情で決まる話ではない。組織としての意思決定を伴う選択である。このままで、本当にいいのか。この問いに、今すぐ明確な答えが必要なわけではないかもしれない。しかし、プロジェクト中心の見方を続けるのか、それとも組織として仕事の仕方を設計する立場に立つのか。その選択を意識しないまま進むことだけは、避けるべきだろう。能力レベル3とは、何かを新しく付け加えた結果として得られる到達点ではない。どこに立って仕事を見るのか、その視点を選び直したときに、あとから振り返って「そこにあった」と気づく状態に過ぎない。答えは、モデルや評価の中にはない。組織自身の選択の中にしか存在しない。（日吉昭彦）

B'zine - 2026年４月号（Webinar：AI時代のQA（品質保証活動）など）を発行しました

B'zine ４月号を発行いたしました。ショート動画(約30秒)も公開していますので、弊社公式YouTubeより是非ご視聴ください。 B'zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。 B'zineビジネスガレージ通信（2026年4月号） B'zine 4月号をお届けします。新緑の季節になり、もうすぐ待ちに待ったゴールデンウィーク突入ですね。昨年秋頃から頻繁に取り上げられていたクマ出没ニュースですが、今月になって再びクマの市街地出没ニュースも出ていますので、キャンプ、ハイキング等で山岳地帯にお出かけの際は単独行動を避け、安全に十分留意してください。【今月のトピックス】イベント：５月２８日（木）第９回Webinar開催：AI時代のQA（品質保証活動）とは何か？～人が行うQA、AIが行うQAを考える～コラム：Automotive SPICEは守っているのに、なぜ機能しないのか～ WhatとHowの混同から読み解く設計思想～コラム：制御仕様書という怪物～世界標準とプロセスはズレているのに何故品質は良いのか？～コラム：Automotive SPICE 能力レベル３とは何か？それは「プロセスの話」だけではない（前編）動画公開：【第8回Webinar】AIを活用した次世代要件分析プロセスの考察お知らせ：HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」始動お知らせ：Automotive SPICE ガイドライン第３版のドラフトが公開されています【イベント】 2026年5月28日 Webinar：AI時代のQA（品質保証活動）とは何か？～人が行うQA、AIが行うQAを考える～生成AIをはじめとした技術の進展により、開発環境や仕事の進め方は大きく変わりつつあります。それに伴い、QA（品質保証活動）やQAグループに求められる役割や価値についても、見直す必要があるのではないでしょうか？本webinarでは、AI活用そのものを目的とするのではなく、AI時代にQAやQAグループが担うべき役割や価値を改めて整理します。１．期待されているQAとは２．現状の品質保証グループが抱える構造的な課題３．AIが得意なQA領域／人が担うべきQA領域４．AI時代におけるQAモデルの考察詳細、お申し込みはこちらから→https://www.bgarage.co.jp/event/1930/ 【コラム】 Automotive SPICEは守っているのに、なぜ機能しないのか～ WhatとHowの混同から読み解く設計思想～Automotive SPICE（A-SPICE）は、車載ソフトウェア開発におけるプロセス能力を評価するためのアセスメントモデルです。当社では先日、「ソフトウェア開発組織をどう評価するか～エンジニアリングチーム全体を評価し、組織改善につなげるために～」というコラムの中で、SPICEを含む複数の枠組みを用いながら、開発組織をどのように評価し、改善につなげていくかを整理しました。また、これまでのコラムでも、「ドキュメントが作られているが活用されていない」、「プロセスが形骸化している」といった課題が現場で起きやすいことを指摘してきました。しかし、それらは“現象”としては共有されているものの、なぜ起きるのか、どうすれば防げるのかまでは十分に整理されていないケースも少なくありません。本コラムでは、これらの前提を踏まえたうえで、A-SPICEを「評価モデル」として説明するのではなく、「なぜその評価項目が定義されているのか」という観点から読み直します。詳細はこちら→https://www.bgarage.co.jp/news/1721/ 制御仕様書という怪物～世界標準とプロセスはズレているのに何故品質は良いのか？～「制御仕様書」。 Automotive SPICEと正面から向き合おうとした瞬間、この文書は必ず行き場を失う。Automotive SPICEの成果物として当てはめようがない。かといって、「これは間違っている」「不要だ」と一刀両断できるほど単純でもない。内容そのものは決して無意味ではなく、むしろ多くの現場で実際に機能してきた歴史がある。だからこそ厄介なのである。Automotive SPICEの成果物に、日本の「制御仕様書」をきれいに当てはめられた人は、果たしてどれくらいいるだろうか？詳細はこちら→https://www.bgarage.co.jp/news/1871/ Automotive SPICE 能力レベル３とは何か？それは「プロセスの話」だけではない（前編）Automotive SPICE（以下、A‑SPICE）の能力レベル3という言葉から、多くの組織が思い浮かべるのは「組織標準プロセスの整備」や「標準化されたやり方が定義されている状態」ではないだろうか。実際、能力レベル3はそのような文脈で語られることが多い。しかし、それは能力レベル3がもたらすの“結果の１つ”であって、“本質”ではない。能力レベル3が本来問いかけているのは、プロジェクト依存のやり方から脱却し、組織として仕事の仕方を意図的に設計し、再利用可能な形で運用できているか、という一点に尽きる。そしてこれは、決して個々のプロジェクトの努力だけで到達できるレベルの話ではない。詳細はこちら→https://www.bgarage.co.jp/news/1901/ 【動画公開】第8回Webinar「AIを活用した次世代要件分析プロセスの考察」のアーカイブ動画を公開しました。本Webinarでは、生成AIを活用することで、従来の要求分析プロセスがどのように変わり得るのかを整理しています。Webinar動画はこちらから（YouTube）→https://www.youtube.com/watch?v=-NX1B97FBUI 【お知らせ】 HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」始動HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」はじめました。当社HPで公開しているコラムは、Automotive SPICEをはじめとしたプロセス改善や設計現場における「違和感」や「つまずき」を、現場視点で言語化してきました。コラムでは書ききれなかったなぜそのテーマを取り上げたのか、何に違和感を感じ、どこで議論が分かれたのか、設計思想やプロセスを形骸化させないために何が必要なのかといった、思考の背景や議論のプロセスをお届けするため、動画座談会シリーズ「B’talk（ビートーク）」をスタートしました。記念すべき第1回のテーマは、「Automotive SPICEは守っているのに、なぜ機能しないのか― WhatとHowの混同から読み解く設計思想 ―」です。詳細はこちらから→https://www.bgarage.co.jp/news/1915/ Automotive SPICE ガイドライン第３版のドラフトが公開されていますVDC QMDから Automotive SPICE Guidelines 3rd edition のYellow Book が一般レビュー用に公開されています。2026年5月12日までの期間でフィードバックを受け付けているようです。資料はこちら→https://vda-qmc.de/en/publikationen-und-apps/gelbbaende/ ゴールデンウィーク休業のお知らせ誠に勝手ながら、下記の期間をゴールデンウィーク休業とさせていただきます。ゴールデンウィーク休業期間：2026年4月29日（水）から2026年5月6日（水）まで休業期間中にいただきましたお問い合わせにつきましては、5月7日（木）以降、順次対応させていただきます。お客様にはご不便・ご迷惑をおかけいたしますが、何卒ご理解賜りますようお願い申し上げます。

Automotive SPICE 入門　一般開催トレーニング（6月開催）のご案内

Automotive SPICE 入門一般開催（6月分）の日程をご案内いたします。詳細およびお申込みは、下記リンクあるいは「イベント開催日程」からお願いいたします。 Automotive SPICE 超入門2026年6月10日詳細はこちらからAutomotive SPICE 入門管理支援編2026年6月12日詳細はこちらからAutomotive SPICE 入門システムエンジニアリング編2026年6月17日詳細はこちらからAutomotive SPICE 入門ソフトウェアエンジニアリング編2026年6月25日詳細はこちらからAutomotive SPICE 入門ハードウェアエンジニアリング編2026年6月24日詳細はこちらから Teamsを使ったオンラインでの開催となります教材は、原則開催日の５日前までにご指定場所に郵送いたしますご請求書はPDF版をメールで送付いたしますお支払い期日は、ご請求書発行日の翌月末となりますご請求書発行後のキャンセルは、お断りしています（代理出席などの手配をお願いします）お申込者以外の方の聴講および録音は固く禁じます

第９回 Webinar　AI時代の品質保証活動とは何か？　～人が行うQA／AIが行うQA ～　開催のご案内

第９回 Webinarは、AI時代の品質保証活動について考察します。生成AIをはじめとした技術の進展により、開発環境や仕事の進め方は大きく変わりつつあります。それに伴い、QA（品質保証活動）や品質保証グループに求められる役割や価値についても、見直す必要があるのではないでしょうか。本webinarでは、AI活用そのものを目的とするのではなく、AI時代にQAや品質保証グループが担うべき役割や価値を改めて整理します。アジェンダ期待されているQAとは現状の品質保証グループが抱える構造的な課題 AIが得意なQA領域／人が担うべきQA領域 AI時代におけるQAモデルの考察参加ご希望の方は、こちらのページからお申込みください。

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プロセスは固定的なルールではなく、人の能力や使われる技術を前提として設計され、必要に応じて見直されるべきものである。誰が何を意図して設計したのか、なぜそのプロセスが選ばれているのかが説明できなければならず、常に改善の対象として意識されていなければならない。人や技術の成熟なしに、プロセスだけを高度化することはできない。 TechnologyTechnology は、QCD や生産性を向上させるために、設計・実装・テストといった開発活動をどのように支えるかという観点で捉える必要がある。設計やテストに関する新しい技術の導入、使用するツール類の選択、開発環境の整備は、いずれも成果に直結する重要な要素である。重要なのは、技術やツールを単に導入することではなく、人のスキルや能力、そしてプロセスの設計と整合した形で活用されているかという点である。新しい技術の導入は、必要とされるスキルや作業の進め方を変え、結果としてプロセスの見直しを促す。この意味で Technology は、People や Process とは独立した要素ではなく、組織として成果を引き上げていくための重要な構成要素である。適切に選択・活用された Technology は、人とプロセスの力を増幅し、QCD や生産性の継続的な向上を支える。このように、People・Process・Technology は独立して存在するものではない。どれか一つの軸だけが伸びても、組織全体としての成果（QCDや生産性）は頭打ちになる。三つの要素が相互に影響し合いながら、スパイラル的に伸びていく状態を作って初めて、組織の力は継続的に向上していく。能力レベル3における組織とプロジェクトの関係能力レベル3においては、改善が組織として回り始め、その結果として、組織とプロジェクトの役割分担と関係性が具体的な形を取るようになる。組織は、標準プロセス、プロセス部品、テンプレート、ツール、テーラリングガイド、そしてプロセス実績データベースといったプロセス資産ライブラリを整備し、プロジェクトに提供する役割を担う。プロジェクトは、これらの標準プロセスや過去の実績データを参照しながら、プロジェクトの特性に応じたプロジェクト用プロセスを設計し、それを前提としてプロジェクト計画を作成する。プロジェクトは設計したプロジェクトプロセスに従って運営され、その結果として得られた実績データが、再び組織のプロセス実績データベースに蓄積されていく。この組織とプロジェクトの間で回るPDCAこそが、能力レベル3における改善の実体である。改善はプロジェクトの中だけで完結するのではなく、組織によって集約され、次のプロジェクトに活かされることで、組織全体としての能力が高まっていく。帰結として現れるプロセス定義の変化このような前提でプロセス改善が継続的に行われていくと、プロセス定義の在り方そのものも変わってくる。改善が一過性ではなく、PPTの3要素が組織的に回り始めると、プロセスは単なる手順書の集合では維持できなくなる。どの作業がどの目的を持ち、どの成果に結び付いているのか、そして変更がどこに影響するのかを、組織として把握できる形が必要になるからである。その結果として、プロセス定義は必然的に、いわゆるプロセスモデリングに基づいた、よりフォーマルな形へと移行していく。ここで言うプロセスモデリングとは、業務や開発における作業の流れや役割、成果物、相互関係を構造的に表現し、変更や改善の影響を組織として把握・管理できるようにすることを指す。具体的な文書化の考え方やテクニックについては、弊社コラム「プロセスモデリング〜プロセス文書化のテクニック」も参照していただきたい。重要なのは、プロセスのフォーマル化そのものが目的なのではなく、改善を継続可能なものにするための自然な帰結として現れる点にある。レベル3におけるプロセスモデリングは、成熟の証明ではなく、改善が組織の中で本当に機能し始めた結果だと言える。４．なぜ、この誤解は生まれたのかーAutomotive SPICEという枠組みが生んだ構造的なズレ前章までで見てきたように、能力レベル3は本来、People・Process・Technology を通じて組織としての力を高めていくための入口であり、単なるプロセス定義の段階ではない。しかしA‑SPICEの文脈では、能力レベル3が「組織標準プロセスを整備する段階」として理解されるケースが少なくなかった。この誤解は、特定の組織や個人の理解不足によって偶然生じたものではない。A‑SPICEというモデルがどのような目的で設計され、どのような文脈で使われてきたかを振り返ることで、その背景は構造的に説明できる。サプライヤー評価モデルとして使われてきたA‑SPICEA‑SPICEは、欧州OEMがサプライヤーを評価するための枠組みとして発展してきた。その主眼は一貫して、OEMに影響を与える開発リスクの可視化と低減にある。評価の対象となるのは、あくまで進行中、あるいは予定されているプロジェクトであり、プロジェクトが安定して遂行されるかどうかが最重要関心事であった。この文脈において、能力レベルは「将来に向けた組織変革の成熟度」を測る尺度というよりも、プロジェクトをどの程度安心して任せられるかを判断するための指標として受け止められてきた側面がある。プロジェクト視点で読み取られた能力レベル３こうした文脈の中では、能力レベル３は自然と、プロジェクト間で共通に使えるものがあるか標準化されたプロセスが存在するかといった観点で理解されるようになる。これは、プロジェクトの安定化という目的に照らせば合理的な読み方であり、誤りと断じることはできない。ただし、この理解はプロジェクトを中心に据えた解釈であり、第3章で述べた「People・Process・Technologyを意図的に育て、組織力を高めていく段階」という能力レベル3本来の姿とは、焦点が異なっている。このズレが積み重なった結果、能力レベル3は次第に「組織標準プロセスを整備した状態」とほぼ同義に扱われるようになっていった。組織としての改善が前面に出にくいモデル構造もう一つ見逃せないのが、A‑SPICEのモデル構造そのものである。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を到達点として捉えるのか、それとも次の段階へ進むための入口と捉えるのか。その違いは、改善活動の進め方だけでなく、組織がどこを向いて変わろうとしているのかを映し出す。続く後編では、能力レベル3の先に位置づけられるレベル4・5が何を意味するのか、そしてそれが事業運営や競争力とどのようにつながっていくのかを考察し次のテーマを取り扱うつもりである。後編はこちらから。レベル3はゴールではない ― レベル4・5が示す世界 20年後を語る企業と、目の前を語る企業プロジェクトフォーカスから、いつ抜け出すのかこのままで、本当にいいのか（日吉昭彦）

HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」始動

HPコラムの執筆背景や想いを語る動画シリーズ「B’talk」はじめました当社HPで公開しているコラムは、Automotive SPICEをはじめとしたプロセス改善や設計現場における「違和感」や「つまずき」を、現場視点で言語化してきました。ありがたいことに、「自分たちが抱えていた課題そのものだった」「長年モヤモヤしていたことが整理できた」といったお声を、お客様から多くいただいています。こうした反響を受け、コラムでは書ききれなかったなぜそのテーマを取り上げたのか何に違和感を感じ、どこで議論が分かれたのか設計思想やプロセスを形骸化させないために何が必要なのかといった、思考の背景や議論のプロセスをお届けするため、動画座談会シリーズ「B’talk（ビートーク）」をスタートしました。記念すべき第1回のテーマは、「Automotive SPICEは守っているのに、なぜ機能しないのか― WhatとHowの混同から読み解く設計思想 ―」コラムをすでにお読みいただいた方はもちろん、これからAutomotive SPICEやプロセス改善に向き合う方にも、考えるヒントを得ていただける内容です。関連コラムとあわせて、ぜひご覧ください。▶B’talk #01（YouTube）はこちら⇒https://youtu.be/-9W4wwwxISQ▶本動画の元となったHPコラムはこちら⇒https://www.bgarage.co.jp/news/1721/

新着情報

Automotive SPICE レベル3を“現場視点”で解説する動画コンテンツを公開

日本の車載ソフトウェア開発では、何故いまだにDRBFMが使われているのか（前編） 〜 生産性向上と品質維持に向けた提言 〜

Automotive SPICE 能力レベル３とは何か？ ー それは「プロセスの話」だけではない （後編）

B'zine - 2026年４月号（Webinar：AI時代のQA（品質保証活動）など）を発行しました

Automotive SPICE 入門 一般開催トレーニング（6月開催）のご案内

第９回 Webinar AI時代の品質保証活動とは何か？ ～ 人が行うQA／AIが行うQA ～ 開催のご案内

Automotive SPICE 能力レベル３とは何か？ ー それは「プロセスの話」だけではない （前編）