2026.05.08
Automotive SPICE(ASPICE)は、欧州の自動車メーカーを中心に策定された、車載ソフトウェア開発のプロセス改善と能力評価のための標準モデルです。機能安全規格「ISO 26262」を満たすための基盤となる重要な規格であり、要件定義からテストに至る厳密な「双方向トレーサビリティ」の確保が求められます。
これまで現場では、IBM DOORSによる厳格な要件管理や、Excelによる膨大なドキュメント維持が主流でした。しかし、近年のSDV(ソフトウェア定義車両)化に伴う開発規模の爆発的な拡大により、従来のツール運用だけでは現場の工数が限界を迎えつつあります。―――プロセスの厳格さを維持しながらも、日々の開発タスクと証跡管理をいかに効率化するか―――本記事では、DOORSとの連携も視野に入れた、JiraやConfluenceによる新しいASPICE対応の形を解説します。
ASPICE(Automotive SPICE)とは、車載ソフトウェア開発プロセスの格付けを行うための国際標準規格です。 ソフトウェアが車両の価値を定義する「SDV(Software Defined Vehicle)」時代において、品質を客観的に証明するASPICEへの準拠は、欧州OEMをはじめとする自動車メーカーからの必須要件となっています。サプライヤーにとって、ASPICE能力レベルの達成は、取引継続と新規受注のための不可欠なパスポートです。
車載ソフトウェアの規模と複雑性が飛躍的に増大し、従来の手法ではリコールリスクを制御できなくなったことが策定の背景にあります。ASPICEの目的は、開発プロセスを「見える化」し、「要件定義からテストまでの一貫性」を確保することにあります。これにより、不具合の早期発見と開発の効率化、そして継続的なプロセス改善を実現します。
「ISO 26262」が安全な製品を作るための「機能安全規格」であるのに対し、ASPICEは適切な手順で開発を行うための「プロセス規格」です。
この両者は「車の両輪」として機能し、両方に準拠することで初めて、安全で高品質なソフトウェア開発が可能になります。
ASPICEは、開発組織がどの程度の品質管理能力を持っているかを測る指標を提供します。アセスメントでは、定義されたプロセスがどの程度実行されているかが「能力レベル」として判定されます。
ASPICEは、自動車開発の標準である「V字モデル」に沿ってプロセスを定義しています。
これらの各工程(左側の設計と右側のテスト)が1対1で対応し、すべての情報がリンクしていることが求められます。
| レベル | 状態 | 詳細 |
|---|---|---|
| レベル1 | 実施済み | プロセスが実行され、成果物が作成されている。 |
| レベル2 | 管理済み | 計画に基づき管理され、成果物の品質が確保されている。 |
| レベル3 | 確立済み | 標準プロセスが定義され、組織全体で一貫して運用されている。 |
多くの自動車サプライヤーは、受注条件として「レベル2」または「レベル3」の達成を目標としています。
能力レベルの定義は、国際規格(ISO/IEC 33020)に基づき、国際的な認定団体であるintacs(International Assessor Certification Scheme)によって厳格に管理されています。アセスメントでは、認定アセッサーが「開発プロセスが標準通りに実行されているか」を客観的な証跡から判定します。
ASPICE準拠を目指す現場では、規格が求める「厳格な証跡管理」と「開発スピード」の両立に苦しんでいます。特に以下の3点が大きな負担となります。
ASPICEではあらゆる作業の証跡が求められますが、ExcelやWordによる手動管理では限界があります。
一度の仕様変更で複数の文書に修正が必要となり、転記ミスや修正漏れが頻発。結果として「どれが最新の正しい情報を反映しているデータ」が誰にも分からなくなるリスクを常に抱えます。アセスメント(審査)の直前に、膨大な関連資料との整合性を合わせるためだけにエンジニアが徹夜を強いられるなど、本来の開発業務を圧迫する大きな要因となっています。
ASPICEアセスメントで最も厳しく問われるのが、「顧客要件がどの設計に基づき、どのテストで検証されたか」という双方向の繋がりです。数万件に及ぶ要件をExcelの行・列単位の情報で管理し、手作業で紐付けるのは、もはや現実的ではありません。
リンク切れや転記ミスが常態化し、一つの要件変更がどこまで影響するかを即座に特定できない状態は、品質保証上の大きな弱点となります。手動管理によるトレーサビリティ維持は、現場の工数を際限なく奪い続けます。
近年の自動車開発では一部のUI系機能開発などにアジャイル開発の適用が普及していますが、厳格な文書化とプロセス遵守を求めるASPICEとは一見、対極にあります。
素早い試作と改善を繰り返したい現場にとって、各工程での緻密なエビデンス採取は「開発の足かせ」と感じられがちです。このスピード感と規格が求めるガバナンスの板挟みになり、形骸化したルールだけが残って開発効率が著しく低下してしまうという悩みは、多くの現場共通の課題です。
ASPICE対応の救世主となるのが、Atlassian社のプロジェクト管理ツール「Jira」 とナレッジ管 理ツール「Confluence」です。従来の「管理のためのツール」とは一線を画し、現場のエンジ ニアが日々使うツールそのものをASPICEの証跡プラットフォームへと進化させます。
Jiraを使用すると、要件、設計、テストを「チケット」としてデジタル管理できます。
ASPICE対応の救世主となるのが、Atlassian社のプロジェクト管理ツール「Jira」 とレッジ管理 ツール「Confluence」です。従来の「管理のためのツール」とは一線を画し、現場のエンジニ アが日々使うツールそのものをASPICEの証跡プラットフォームへと進化させます。
Jira上で顧客要件、システム設計、テストケースをそれぞれ独立した「チケット」として発行し、それらを強力なリンク機能で数珠つなぎに管理します。これにより、上位要件から下流のテスト結果までをデジタル上で一気通貫に可視化できます。
従来のようにExcelを手書きで更新する必要はなく、リンクを辿るだけで影響範囲を瞬時に特定。Jiraを使用すると、要件、設計、テストを「チケット」としてデジタル管理できます。
<ポイント>

Confluenceは、仕様書の作成からレビュー、承認までを一つの画面で完結させます。
Confluenceは、仕様書の作成からレビュー、承認までを一つの画面で完結させます。
Confluenceは、バラバラになりがちな仕様書や設計書を一つのプラットフォームに集約し、ASPICEで求められる「文書の最新化」と「レビューの透明性」を両立させます。Jiraチケットとページを直接紐付けることで、開発タスクと設計根拠を常に一体化。ページ更新履歴がタイムスタンプ込みで残るため、「いつ、誰が、何を確認し、承認したか」というプロセスが自動で記録されます。アセスメント時に過去のメールや印影を探し回る必要はなく、確かなレビュー証跡を瞬時に提示可能です。
<ポイント>

JiraやConfluence導入は、ASPICE準拠という困難な山を登るための装備です。ツールはあくまで開発プロセスを支える「装備」に過ぎません。重要なのは、規格の要求事項を自社の開発スタイルにどう適合させ、現場が迷わず入力できる設定にカスタマイズするか、そしてツールを「正しく使い続ける」ための定着支援があるかです。
自社の成熟度に見合わない過度な自動化や複雑なルール設定は、かえって現場の形骸化を招きます。ツールとプロセス、そして人の運用をセットで最適化することこそが、アセスメントを突破する唯一の近道です。
最初から組織全体で「レベル3」の達成を狙うと、ルールの多さに現場が拒絶反応を示し、挫折するリスクが高まります。
まずは特定のプロジェクトをパイロットとして選び、情報のデジタル化と一元化に集中する「レベル1〜2」相当のスモールスタートを推奨します。初期段階では「Excelの転記作業が減った」「トレーサビリティが自動で繋がった」という現場の成功体験を優先すべきです。
小さなプロジェクトで運用を磨き、その成果をテンプレート化して他部署へ展開することで、無理なく着実に組織全体のレベルを底上げすることが可能になります。
可能です。 Jiraを活用することで、アジャイルの柔軟性を保ちながら、裏側でASPICEが要求す る「変更履歴」や「トレーサビリティ」を自動的に蓄積できます。「Agile SPICE」への対応 も、Jiraならスムーズです。
BM DOORSが「上流の要件管理」に特化したプロ仕様であるのに対し、Jira/Confluenceは「現 場の作業と管理の統合」に強みがあります。DOORSのデータをJiraに同期し、開発現場はアジャ イル開発に特化した管理ツールのJiraを利用する「共存」による効率化も多くの企業で採用され ています。
ツール導入を成功させる鍵は「スモールスタート」です。最初から全てのプロセスを自動化しようとするのではなく、まずは特定のプロジェクトで「情報のデジタル化(レベル2相当)」を目指しましょう。リックソフトでは、ツール設定からプロセス定着まで、自動車業界特有の課題に合わせた伴走支援を提供します。