ASPICE (Automotive SPICE) とは自動車開発プロセスの評価モデルを徹底解説

ASPICE (Automotive SPICE) とは？ 

ASPICE とは、Automotive Software Process Improvement and Capability dEtermination の略称で、自動車業界における車載ソフトウェアおよび車載システムの開発プロセスを評価・改善するための国際的なフレームワークです。ISO/IEC 15504 (SPICE) をベースに、ドイツ自動車工業会品質管理センター (VDA QMC) が策定・管理しており、OEM (自動車メーカー) がサプライヤーの開発能力を客観的に評価する業界標準として活用されています。

車載システム開発の現場で「ASPICE 対応が必要」と言われたものの、何から手をつければよいかわからない。そんな経験はないでしょうか。

自動運転や電動化の進展により、自動車 1 台あたりに搭載される ECU (Electronic Control Unit) の数は増え続けており、それに伴い車載ソフトウェアの規模と複雑性も急速に拡大しています。この環境下で、ソフトウェア開発の品質と一貫性をどう担保するかは、自動車業界全体の喫緊の課題です。

本記事では、ASPICE の基本概念から能力レベル、プロセス構成、最新バージョン 4.0 の変更点、そして ISO 26262 との違いまでを体系的に解説します。これから ASPICE に取り組む方にとって、全体像をつかむための実践的なガイドとしてお役立てください。

ASPICE の基本概念: 何を評価するフレームワークなのか

ASPICE (A-SPICE) は、自動車業界におけるソフトウェア開発プロセスの品質と能力を客観的に評価するためのプロセスモデルです。正式名称の software process improvement and capability determination が示すとおり、プロセスの「改善」と「能力判定」を二つの柱としています。

成り立ちと管理体制

ASPICE は、国際規格である ISO/IEC 15504 (通称 SPICE) をベースとして開発されました。現在は ISO/IEC 330xx シリーズとして改訂された国際標準に準拠しています。この規格を自動車産業の特有の要件に合わせてカスタマイズしたものが ASPICE であり、VDA (ドイツ自動車工業会) の品質管理センター (VDA QMC) が策定と維持管理を担っています。

「開発プロセス」ではなく「評価モデル」

ASPICE を理解するうえで最も重要なポイントは、これが「開発プロセスそのもの」ではなく、「開発プロセスの成熟度を評価するモデル」であるということです。ASPICE は各企業に対して特定の開発手法を強制するものではありません。ただし実務では、多くの OEM によって事実上の標準プロセスとして扱われるケースも多く、準拠が強く求められる場面が一般的です。自社の開発環境や文化に合った開発プロセスを構築したうえで、その能力を ASPICE の基準に照らし合わせて評価する仕組みです。

ASPICE が求められる背景

自動車メーカー (OEM) は、サプライヤーの開発能力を客観的に把握するため、ASPICE のプロセスアセスメントを取引条件として求めるケースが増えています。とくに欧州市場では、主要 OEM が特定のプロセス群でレベル 2 以上、場合によってはレベル 3 以上の達成をサプライヤーに要求するのが一般的です。

この背景には、車載システムの高度化に伴うリスクの増大があります。自動運転、サイバーセキュリティ (cybersecurity)、電動化といった技術トレンドにより、開発プロジェクトの規模は拡大し続けています。OEM は自社の製品開発の品質を確保するため、サプライヤーのプロセス能力を定量的に評価できる共通のフレームワークとして ASPICE を採用しているのです。

あらゆる仕事の課題解決に、Asana。

仕事を最大限効率化し、チームの生産性を上げるためには、Asana のプロジェクトマネジメント機能をお試しください。日々の業務と目標をつなげ、「誰が・何を・いつまでに行うのか」を可視化します。

Asana とは？

Automotive SPICE プロセス参照モデル (PRM) の全体像

ASPICE の中核をなすのが、プロセス参照モデル (PRM: Process Reference Model) です。PRM は、車載システム開発に必要なプロセスを体系的に分類・定義したもので、組織がどのようなプロセスを実施すべきかの「参照枠」を提供します。

プロセスカテゴリーの構成

ASPICE 4.0 の process reference model は、以下の 3 つのプロセスカテゴリーで構成されています。

1. 主要ライフサイクルプロセス

開発の中心となるプロセス群で、以下のドメインが含まれます。

• ACQ (Acquisition/取得): OEM がサプライヤーを選定し、開発委託を管理するプロセス

• SPL (Supply/供給): サプライヤーが OEM への供給を管理するプロセス

• SYS (System Engineering/システムエンジニアリング): システム要求分析 (SYS.1) からシステムアーキテクチャ設計、統合、検証までを扱うプロセス

• SWE (Software Engineering/ソフトウェアエンジニアリング): ソフトウェア要求分析 (SWE.1) からアーキテクチャ設計、詳細設計、ユニット構築、検証までを扱うプロセス

• HWE (Hardware Engineering): ハードウェア要求分析から設計・検証までのプロセス (4.0 で新設)

• MLE (Machine Learning Engineering): 機械学習モデルの要求分析からトレーニング・テストまでのプロセス (4.0 で新設)

• VAL (Validation/妥当性確認): 実際の使用環境やユースケースに基づき、システムがユーザー要求を満たしているかを確認するプロセス

2. 支援ライフサイクルプロセス

エンジニアリングプロセスを横断的にサポートするプロセスです。

• SUP.1 (品質保証/Quality Assurance): プロセスと作業成果物の品質保証活動を管理

• SUP.8 (構成管理): 成果物のバージョン管理と変更管理

• SUP.9 (問題解決管理): 問題の分析・解決・再発防止

• SUP.10 (変更依頼管理): 変更要求の評価と承認プロセス

• SUP.11 (機械学習データ管理): 学習データの品質管理 (4.0 で新設)

3. 管理・組織ライフサイクルプロセス

開発プロジェクト全体の管理やプロセス改善に関するプロセスです。

• MAN.3 (プロジェクト管理): 計画、監視、リスク管理

• PIM (プロセス改善管理): 組織レベルでの改善活動の推進

• REU (再利用管理): 再利用可能な資産の管理

プロセスアセスメントモデル (PAM)

PRM が「何をするか」を定義するのに対し、プロセスアセスメントモデル (PAM: Process Assessment Model) は「どの程度できているか」を評価するための指標を提供します。PAM では、以下の 3 つの構成要素で評価を行います。

ASPICE の能力レベル：レベル 0 からレベル 5 までの評価基準

ASPICE では、各プロセスの成熟度を 6 段階の能力レベルで評価します。この能力レベルは、プロセス属性 (PA: Process Attribute) で定義され、開発組織がプロセスをどの程度体系的に実施・管理・改善しているかを示します。

N-P-L-F 評価スケール

各プロセス属性の達成度は、以下の 4 段階で評価されます。

• N (Not achieved): 未達成 (0～15%)

• P (Partially achieved): 部分的達成 (15～50%)

• L (Largely achieved): 概ね達成 (50～85%)

• F (Fully achieved): 完全達成 (85～100%)

評価はレベルを順に積み上げる仕組みになっており、下位レベルが未達成であれば上位は評価されません。たとえばレベル 1 の達成度が「P（部分的達成）」にとどまった場合、そのプロセス全体の能力レベルは 0 と判定されます。レベルの達成には「L（概ね達成）」以上が必要です

intacs 認定アセッサー

ASPICE のアセスメント (評価) は、intacs (International Assessor Certification Scheme) に基づいた資格を持つアセッサーによって実施されます。アセッサーには、Provisional Assessor (仮アセッサー)、Competent Assessor (コンピテントアセッサー)、Principal Assessor (主席アセッサー) などの資格レベルがあり、プロセスアセスメントの品質と客観性を担保しています。

V 字モデルと ASPICE の関係

ASPICE のエンジニアリングプロセス (SYS、SWE、HWE、MLE) は、自動車業界で広く採用されている V 字モデルに沿って設計されています。

V 字モデルとは、要求定義から実装までの「作る工程」と、それに対応する検証・妥当性確認の「確かめる工程」を左右に対置させた開発モデルです。左辺で定義した要求や設計が、右辺の各検証フェーズで漏れなく確認される構造になっており、トレーサビリティの確保に適しています。

この構造により、各フェーズで必要な基本プラクティス (BP) と作業成果物 (WP) が明確に定義され、要求からテストまでのトレーサビリティが確保されます。上流で定義した要求が下流の検証で漏れなく確認される仕組みは、車載システムの品質と安全性を支える重要な基盤です。

Asana のようなワークマネジメントツールや、要求管理・トレーサビリティに対応した ALM ツールを活用することで、V 字モデルの各フェーズにおけるトレーサビリティをデジタルで管理し、要求と成果物の紐づけを効率化できます。

ワークフローで組織を効率化する方法

この電子書籍では、「今の働き方がうまくいかない理由」「柔軟なプロセスを構築する 7 つの重要ステップ」「一般的な戦略・運用ワークフローへのステップの適用方法」を紹介します。

電子書籍をダウンロードする

ISO 26262 と ASPICE の違い

ASPICE としばしば比較されるのが、ISO 26262（自動車機能安全規格）です。両者はともに自動車の E/E システム開発に関わりますが、問いかけていることが根本的に異なります。

ASPICE が問うのは「どのように開発しているか」です。開発プロセスそのものの成熟度を能力レベル 0〜5 で評価し、組織の開発能力を可視化します。対象はハザードの有無にかかわらず、あらゆる E/E システム・ソフトウェア開発です。

ISO 26262 が問うのは「何を達成しなければならないか」です。ハザードにつながる可能性のある機能に対して ASIL 等級（A〜D）を設定し、その等級に応じた安全要求とライフサイクル全体の活動を規定します。ISO 26262 自体は直接的な法規制ではありませんが、多くの OEM が取引先への調達条件として準拠を求めており、実質的に業界標準として機能しています。

両規格は対立するものではなく、役割分担の関係にあります。ASPICE で高い能力レベルを達成している開発組織は、プロセスの定義・管理・実行が安定しているということであり、それは ISO 26262 が求める体系的な安全活動を実践するうえでの組織的な土台となります。

ASPICE 4.0：最新バージョンの主な変更点

2023年11月リリースの ASPICE 4.0 は、約6年ぶりのメジャー改訂です。変更の方向性は大きく4つに整理できます。

1. 「何を評価するか」が広がった

従来の評価対象はソフトウェア開発（SWE）が中心でしたが、V4.0 ではハードウェア設計（HWE）と機械学習モデルの開発（MLE）が新たに加わりました。自動運転や ADAS の普及により、AI・ハードウェアを含むシステム全体の品質管理が求められるようになったことへの対応です。MLE の実務適用は現時点では発展段階にあります。

2. 「どう評価するか」が変わった

V3.1 では検証活動を SUP.2 という独立プロセスで扱っていましたが、V4.0 ではこれを廃止し、各エンジニアリングプロセスの中に組み込む形に再設計されました。「テストを行う」という一元的な捉え方から離れ、目的や対象に応じてシミュレーション・静的解析・計算・測定なども検証手段として明確に位置づけられています。

3. 「どんな開発スタイルにも使える」ようになった

V3.1 の記述はウォーターフォール型の開発フローに寄っており、アジャイルを採用する組織には解釈の余地が狭い面がありました。V4.0 では作業成果物の定義や各プロセスの記述が見直され、反復型・漸進型の開発スタイルにも適用しやすい構造になっています。

4. セキュリティリスクへの対応が加わった

コネクテッドカーの普及に伴い、サイバー攻撃への対策は開発プロセスの一部として切り離せなくなっています。V4.0 では ISO/SAE 21434 や国連法規 UN-R 155 との整合を踏まえ、CSMS（サイバーセキュリティマネジメントシステム）構築を支えるプロセス評価が強化されています。

アジャイル手法によるプロジェクト管理を紹介

この電子書籍では、組織はどのようにアジャイルを導入すれば機敏性の高い効果的な職場を作れるのかなど、アジャイルについて深く掘り下げています。

電子書籍を無料ダウンロード

ASPICE 導入でよくある課題と誤解

ASPICE 対応を進める現場では、いくつかの典型的な課題と誤解が見られます。これらを事前に理解しておくことで、効果的なプロセス改善につなげられます。

誤解 1：ASPICE をそのまま開発プロセスにしてしまう

ASPICE の評価項目をもとに開発プロセスを構築すると、現場の実情に合わないプロセスが導入され、作業効率の低下や不要なチェックポイントの増加を招くおそれがあります。ASPICE はあくまで「監査項目」であり、これを満たすためのプロセスは各組織が自社の開発環境に合わせて構築する必要があります。

誤解 2：レベル達成が目的化してしまう

「レベル達成」を優先しすぎると、本来の目的であるプロセス改善が形骸化するリスクがあります。基本プラクティスや作業成果物を形式的に用意するだけでは、実質的な品質向上にはつながりません。

課題：膨大な文書化と証跡管理

ASPICE 対応では、各プロセスの実施記録、作業成果物の管理、トレーサビリティの確保など、膨大な文書化が求められます。スプレッドシートやメールベースの管理では、情報の散逸やバージョンの不整合が起きやすく、アセスメントの際に大きな負担となります。

Asana で ASPICE 対応のワークフローを効率化

ASPICE 準拠の開発プロセスでは、要求管理、トレーサビリティの維持、作業成果物の文書化と管理、そしてチーム間の連携が同時に求められます。これらを手動で管理し続けることは、開発プロジェクトの規模が大きくなるほど困難になります。

Asana のようなワークマネジメントツールや、要求管理・トレーサビリティに対応した ALM ツールを導入することで　、こうした課題を効率的に解決するためのデジタル基盤を構築できます。

• プロセスの可視化: Automotive SPICE プロセスに沿ったプロジェクトテンプレートを作成し、各プロセスの進捗と依存関係をリアルタイムで把握

• トレーサビリティの確保: タスクの親子関係や依存関係を活用し、要求から検証結果までの紐づけをデジタルで一元管理

• 作業成果物の管理: 各プロセスで生成される文書やレビュー記録を一か所に集約し、バージョン管理と承認フローを自動化

• 一貫性のある運用: 標準プロセスをテンプレート化し、開発プロジェクトごとのテーラリングを効率的に実施

• 改善活動の推進: ダッシュボードやレポート機能でプロセスのパフォーマンスを定量的に把握し、継続的な改善活動につなげる

日本の自動車産業は人手不足やデジタル需要の急増など、構造的な課題を抱えています。開発規模が拡大する中で、ASPICE 対応のプロセス管理を手動で維持することはますます困難になっています。Asana を活用したワークマネジメントの導入は、こうした業界課題の解決にもつながります。

ワークフローで組織を効率化する方法

この電子書籍では、「今の働き方がうまくいかない理由」「柔軟なプロセスを構築する 7 つの重要ステップ」「一般的な戦略・運用ワークフローへのステップの適用方法」を紹介します。

電子書籍をダウンロードする

導入事例: スズキ株式会社が実現した業務の可視化と標準化

ASPICE 対応に限らず、自動車業界における複雑なプロセス管理の課題は、日本を代表する自動車メーカーにも共通しています。

スズキ株式会社では、コロナ禍を機に DX 推進が急務となり、業務の効率化と情報共有を目的としてAsanaを導入。2021年4月の導入開始から、現在では社内 15 本部で 700 以上のアカウントがアクティブに活用されています。

同社が特に注力したのが、繰り返し業務のテンプレート化による標準化です。代理店契約の締結・解約、新人受け入れ、出張前準備など、手順が決まっている業務をすべてテンプレートとして公開。属人的なやり方やミスの削減を実現しました。これは、ASPICE が求める「標準プロセスの定義と展開（レベル3）」の考え方と本質的に重なります。

進捗の可視化においても顕著な成果が出ています。ワークロード機能でチーム全体の負荷を一目で把握できるようになり、特に活用が進んだチームでは残業時間が35％削減されました。

頻繁に利用するユーザーの約9割が効果を実感しており、仕事の可視化、やり残しの防止、スケジュール管理、業務進捗の把握といった点で改善が見られています。

ASPICE 対応の現場でも、プロセスの可視化・標準化・証跡管理は共通の課題です。スズキの事例は、自動車業界においてAsanaがこれらの課題を解決する実践的な基盤となり得ることを示しています。

ASPICE に関するよくある質問