「Automotive SPICE 4.0 実践ガイドブック」の見どころ（後編）

　前回のメルマガでは、2024年1月販売開始予定の「Automotive SPICE 4.0 実践ガイドブック」の見どころを紹介しました。（https://biz3.co.jp/download/5845）
　見どころの一つとして、製品開発全体を見た時の最適化視点で、技術領域（システム/ソフトウェア/ハードウェア）に共通する活動、およびその観点について、「要求分析プロセス」を取り上げて、具体的に解説しました。その他にも、「Automotive SPICE 4.0 実践ガイドブック」を使用したプロセス基礎トレーニングで取り扱う事例紹介について簡単に触れました。
　本メルマガでは、要求分析プロセスに続いて、「検証プロセス」を対象に解説します。また、事例紹介については、プロセス改善を進める上で役に立つ一例をご紹介します。
Automotive SPICE 3.1のテスト系プロセス（SYS.4～5、SWE.4～6）におけるテストという表現が、Automotive SPICE 4.0では、検証に変わっています。これは、設計通りに実装されていることや要求を満たしていることを確認する手法に、テストだけでなく、解析、シミュレーション、測定も含むことを意味しています。例えば、ハードウェア設計に対するテストでは、回路基板上のテストポイントで計測したデータ値（温度など）からシミュレーション、または解析によって求めた結果に対して合否を判定することが実際のプロジェクト開発現場では行われています。このようにテスト以外の手法を適用することも考慮して、検証プロセス（SYS.4、5、SWE.4～6、HWE.3、4）の目的を達成するための検証手段（検証手法、合否基準を含む検証仕様、検証技法、検証環境等）を仕様化することが重要です。
そして、検証手段を決定するための基準、検証活動（役割、責任、権限、必要なスキル、インフラ）および活動の監視・調整の仕組み（戦略）が体系的な文書として定義されていることが能力レベル２の要求に該当します。「戦略」の概念が、Automotive SPICE 4.0では、能力レベル２へ移行されていますが、これはアセッサー向けの観点のため、プロジェクト/組織は、Automotive SPICE 4.0に合わせて検証プロセスを変える必要はありません。例えば、プロジェクトの検証計画で、前述の検証手段、および戦略を定義している場合、それら分けて策定するようなプロセスに変更する必要はありません。
　ここで、プロジェクトの開発現場では、「体系的な文書として定義する」とは、どのような形式を指すのかという疑問を持っているのではないでしょうか。検証計画書の中に、検証戦略という章節を設けて記述する形式が一般的かも知れません。しかし、検証戦略を体系的な文書として定義する目的は、プロジェクトメンバー、および関係者が検証戦略を共有、理解できるようにすることです。この目的が達成できる形式であれば、検証計画書の中に検証戦略を定義する以外に、以下のような形式も、体系的に文書として定義されていると扱うことができます。
　•検証プロセスの目的と目標、該当する実施手順を説明したプレゼンテーションスライド
　•特定のワークフローを使用させるツール（構成管理、変更管理などのツール）
　•プロセス実施において重要な要素を説明しているホワイトボードの写しや動画などのメディア
このように、実プロジェクト活動において、現場で既に実施している方法が能力レベル1、または能力レベル2の要求を満たしていることを再認識できるように、抽象的な要求をより具体的な例として、ガイドブックの中で解説しています。

　続いて、「Automotive SPICE 4.0 実践ガイドブック」を使用したプロセス基礎トレーニングに追加されている事例について紹介します。
過去のトレーニングを通して、受講者から「エンジニアリング領域において、一般的にどのような問題がありますか」、「他社でも同様の問題が発生していますか」などの質問を受けることが多々あります。そのような質問に対する回答として、当社が過去に実施したアセスメント、およびギャップ分析の結果から、各プロセス群内で弱みが最も検出されているプロセスを能力レベル別に抽出し、その指摘内容およびその可能性のある原因について解説しています。
例えば、システムエンジニアリング（SYS.1～SYS.5）では、能力レベル1において、SYS.4とSYS.5が上位２プロセスとして抽出されています。「テストプロセスの境界が曖昧」、「テストケースを選択した時の根拠が残っていない」など、共通の指摘が見られます。特に、SYS.4で、下位の技術領域からのエレメントが統合されテストを行いますが、明確な根拠なしでビッグバン統合、SYS.4プロセスのSYS.5プロセスへの統合などが実態として見られます。このような場合、段階的な統合を行っていれば見つけられたはずの各エレメントの不具合が、統合状態では打ち消しあってしまうためにシステム検証では検出されずに出荷されてしまうといったリスクを考慮する必要があります。しかし、システムの定義（境界）、特にシステム・オブ・システムズ（System of Systems）のような複雑な構成において、テスト範囲や目的が技術領域間で識別されず、それらの一貫性が確保、および合意されていないのが原因と考えられます。
トレーニングでは、この例のようにアセスメントデータから見える共通の問題点を取り上げ、その原因についても解説していきます。皆様のプロジェクト実施状況を振り返る機会にもなりますので、興味がある方は、是非ご受講を検討頂ければ幸いです。

トレーニングの詳細は下記をご参照ください。
トレーニングコース名：Automotive SPICE 4.0 プロセス基礎トレーニング（サイバーセキュリティ、アジャイルを含む）
開催日：2024/3/4(月)～3/8(金)
お申込み先：https://biz3.co.jp/publictraining_category/automotivespiceengineer

2023/12/21 小西 晃輔