Automotive SPICEに対応した開発プロセスの構築 ～断片的な開発管理から、統合・標準化された開発管理へ～

皆さま、こんにちは。
IDAJの石原です。

自動車産業は今、極めて短期間のうちに「ソフトウェア産業」へと変貌を遂げています。
衝突回避、ADAS、自動運転、EV制御など、安全・信頼性に直結するソフトウェアが猛烈な勢いで増加し、品質リスクの低減が急務となっています。そのため欧州や北米の主要な自動車メーカーでは、納品条件やサプライヤー選定基準として「Automotive SPICE（以下、A‑SPICE）」というプロセス評価におけるフレームワークでの高い評価（レベル2～3の能力レベル保持）を求めています。
一方、車載ソフトウェアの開発現場では、いくつかの理由から、A‑SPICEの本質である組織的プロセス能力の向上を実現できない状況にあります。

• 部門ごとに異なるExcel、Word、独自テンプレート
• 誰が何を作り、どこにあるのかわからない成果物
• プロセスは「紙の上で」だけ定義され、運用が追従できない
• トレーサビリティが後付けで作成され、監査直前に煩雑な確認作業が発生

そこで必要なのが、「プロセスそのものを運用レベルで一元管理するためのシステム基盤」です。
Aras Innovatorは本来「製品構成管理」に強みを持つPLMですが、柔軟なデータモデルとワークフロー機能により、A‑SPICEで求められるプロセスの標準化、成果物の管理、トレーサビリティの保証、継続的改善の仕組みをシステムとして再現できる点が最大の強みです。
IDAJでは、A-SPICE対応の業務に合わせたテンプレートをご準備していますので、実業務に合わせてテンプレートを組み替えることで、短期間でA-SPICEに準拠した業務システムの構築をご支援することが可能です。
ここでは、カスタマイズ性の高いPLMとして定評があるAras Innovatorをデータ基盤のプラットフォームとして、A‑SPICEに準拠した開発プロセスの構築方法についてご紹介します。

Automotive SPICE（A‑SPICE）とは

まずは、A‑SPICEについてご説明します。
A‑SPICEは、2001年にアウディ、BMW、ダイムラー、フォルクスワーゲンなど、欧州の主要な自動車メーカーを中心に策定された国際規格で、ISO/IEC 15504（SPICE）をベースに車載ソフトウェア開発向けに調整したものです。これまでに複数回のプロセス見直しが行われ、2023年にはversion4.0がリリースされました。A-SPICEでは“車載ソフトウェアを開発するプロセス”を評価するために、プロセスの能力レベルを6段階に分類しています。

1.プロセス参照モデル

開発プロセスを32のプロセスに分類し、各プロセスには、実施すべき基本プラクティスと、プロセス属性の達成成果の程度を示す共通プラクティスがあります。基本プラクティスでは“アウトプット情報などの成果物を含む実施すべき内容”を、共通プラクティスでは“達成度・成熟度”を定義しています。

プロセス参照モデルの概要

プロセス毎のアウトプット情報項目（一部抜粋）

以下はアウトプット情報項目の一例です。このようにアウトプット情報項目は、それぞれどのような内容を含むべきか、さらに細かく記述されています。これらは評価の着眼点となるため、準拠した形でプロセスを構成し、アウトプット情報をまとめる必要があります。

アウトプット情報項目の記述例

プロセス標準化のための業務テンプレート

IDAJはA-SPICEに準拠したプロセス構築をご支援するにあたって、プロセスを標準化する機能をもった業務テンプレートを、プロセス導入時にご提供しています。ここでは、その業務テンプレートをご紹介します。

1.A-SPICE準拠プロセスの構築（能力レベル2への対応）

製品アイテムの配下の「開発タブ」に、開発のVサイクルの左バンクに該当する「開発」プロセスを作業順に配置し、同様に「検証タブ」に右バンクの「検証」プロセスを配置します。

製品と開発タブ内のプロセス例

各プロセス単位で必要な成果物を専用の格納箱に保存します。すべての成果物が必要な承認ワークフローを経てリリースとなったとき、当該プロセスは完了し、すべてのプロセスが完了すると製品開発が完了します。

プロセス内の成果物タブ

成果物としては、CADデータ、PDF、Excelなどの一般的なファイルを添付保存する機能のほかに、以下に示したAras Innovator上で編集できる記述式ドキュメントがあります。このタイプのドキュメントは、予め記載すべき複数の項目のタイトル“章”で構成された定型のフォームです。“章”は独立したアイテムなので、記述については個別の改廃が可能です。

記述式ドキュメントのフォーム例

複数のドキュメント間で“章”同士の関連を持たせることができるので、相互に影響する範囲がわかりやすくなることが期待できます。例えば顧客の「要求」のある章の記述を受けて「設計仕様」の該当の章を記述し、さらにそれに該当する「ソースコード」などを登録すると、設計変更の際に影響する元の「要求」が即座にわかり、確認漏れを減らせます。また同類の「要求」の項目に対して、さまざまな「対応方法」や「問題点と解決例」などが蓄積されることによって、ナレッジとしての活用も期待できます。これが、記述式のドキュメントを多用する設定としている理由です。

2.プロセスの標準化（能力レベル3への対応）

製品ごとのプロセス構成の設定と、記述式ドキュメントのフォーム設定の標準化のために、それぞれに対応するテンプレート機能を追加しました。これらのテンプレートは組織標準の改定に対応しており、承認ワークフローを経てユーザーが自由に変更できますので、プロセスの継続的な改善にも対応できます。

おわりに

テンプレートのデフォルトの設定は、最新のversion4.0のプロセス分類とその成果物の定義に準拠したものとなっていますが、お客様の実際のプロセスやドキュメントフォームと合致しない部分が多々あるかと思います。このような場合は、IDAJがお客様の組織構成や業務の流れ、既存のドキュメントフォームなどを考慮して、テンプレートをカスタマイズさせていただきますので、お気軽にご相談いただけますと幸いです。

本記事についてご興味がございましたら、お気軽に営業担当または以下からお問い合わせくださいますようお願いいたします！

■オンラインでの技術相談、お打合せ、技術サポートなどを承っています。下記までお気軽にお問い合わせください。ご連絡をお待ちしています。

Webからのお問い合わせはこちら

E-mail：info@idaj.co.jp

TEL： 045-683-1990