小説で学ぶ自動車ソフトウェア開発 (その4) A-SPICE (2)
前回の「その3」では、A-SPICE編の前半として、V字モデル、A-SPICEの成り立ち、プロセスと能力という二つの軸、そしてSYS群・SWE群などの基本構造を見てきた。
今回は、その続きとして、A-SPICEを現場で評価・運用するための考え方に入っていく。
L0からL5までの能力レベル、N/P/L/Fという評定、BP・WP・GP・GRといった略語、そして要求・設計・実装・テストをつなぐトレーサビリティ。これらは一見すると細かく面倒な仕組みに見えるが、実は「後から説明できる開発」を支えるための骨格でもある。
A-SPICE編の後半では、主人公の成田剛志が、アセスメントの現場に立ち会いながら、車載ソフトウェア開発における「証拠を残すこと」の重みを学んでいく。
第10章 L0からL5までの階段
ASPICE.009：6段階の能力レベル（L0〜L5）
研修第二フェーズの初日、藤谷さんはホワイトボードに6段の階段を描いた。
L5：Innovating（革新）
L4：Predictable（予測可能）
L3：Established（確立）
L2：Managed（管理）
L1：Performed（実行）
L0：Incomplete（未達）
「これがA-SPICEの能力レベル。プロセスごとに、この6段階のどこにいるかを評価する」
L0：Incomplete（未達）
「L0は、プロセスがそもそも実施されてない、あるいは目的を達成してない状態。つまり、『やってない』」
「たとえばSWE.4のユニット検証で、ユニットテストをまったくやってない、あるいは形だけ書いてるけど誰も実行してない。これはL0」
L1：Performed（実行）
「L1は、プロセスが実施されていて、その目的を達成している状態」
「ユニットテストをちゃんと書いて実行している。テストケースは要求をカバーしてる。テスト結果は記録されてる。これでL1達成」
「ただし、L1は『やった』だけ。それがどう管理されているか、組織として標準化されているかは問わない」
L2：Managed（管理）
「L2は、L1に加えて、プロセスが"管理されている"状態。具体的には、プロセスのパフォーマンスが管理されていて、ワーク成果物が適切に管理されている」
「ユニットテストの実行計画が立ててあり、進捗が管理されてる。テスト結果が構成管理されてる。レビューされている。問題が発生したら是正される。これがL2」
「L1とL2の違いは、"場当たり的にやってるか、計画と管理のもとでやってるか"の違い」
L3：Established（確立）
「L3は、L2に加えて、組織の標準プロセスが確立されていて、プロジェクトでそれが適切にテーラリング（カスタマイズ）されて適用されている状態」
「つまり、プロジェクトごとに勝手にユニットテストの方法を決めてるんじゃなくて、組織全体で『標準ユニットテスト手順』があって、各プロジェクトはそれをベースに自分たちの状況に合わせて調整して使ってる。これがL3」
「L3が、車載業界で多くのOEMがサプライヤーに要求するレベル。"プロジェクトA-SPICE L3達成"が、契約の前提条件として書かれることが多い」
L4：Predictable（予測可能）
「L4は、L3に加えて、プロセスのパフォーマンスが定量的に管理されていて、プロセス成果が定量的に予測可能な状態」
「ユニットテストで、過去の不具合密度のデータがあって、『今回のプロジェクトでは△個のバグが見つかるはず』『カバレッジは□%になるはず』みたいな統計的予測ができる。実際に予測通りになる」
「L4は、世界的にも達成している組織は少ない。航空宇宙系の一部や、本気で品質改善に取り組んだ自動車メーカーの一部だけ」
L5：Innovating（革新）
「L5は、L4に加えて、プロセスが継続的に改善され、組織目標に対して革新的な改善が実施されている状態」
「これは"理論上の最高レベル"。実際にL5を達成している組織はほぼ存在しない、と言われる」
「ね、成田くん、ここで一つ大事なことを言っておくね」と藤谷さんは僕を見た。
「能力レベルは、プロセスごとに違う」
「えっ」
「あるサプライヤーが『うちは A-SPICE L3です』って言うとき、実は『一部のプロセスはL3、一部はL2、一部はL1』ってのが普通なの。サプライヤー全体の能力レベルって概念は本来ない。プロセス別の能力レベルがある」
「だからOEMからの要求も、たとえば『SYS.2、SYS.5、SWE.1〜6、MAN.3、SUP.8、SUP.10はL3以上、その他はL2以上』みたいに、プロセスごとに能力レベルを指定してくることが多い」
「これがA-SPICEの細かいけど重要な性質」
「Webだと、たとえば『うちの会社のエンジニアリングレベル』ってあいまいに言いますよね。でも、A-SPICEだとプロセスごとに評価されると」
「そう。だから、開発組織の強み・弱みが具体的に見える化される」
「L0からL5、覚えた？」と藤谷さんは聞いた。「L0：未達、L1：実行、L2：管理、L3：確立、L4：予測可能、L5：革新」
「業界の多くがL2かL3を目指す。L3が"組織標準が確立されてる"レベル。これがビジネス的には現実的な目標」
「L4以上は、品質の達人レベル。航空宇宙の一部や、特殊な医療機器みたいな世界の話」
「カイトプロジェクトは、SWEとSYSの主要プロセスをL3で達成することを目標にしてる。これは標準的な要求」
その日のノート。
剛志のノート（10）
・能力レベルはL0〜L5の6段階。
・L0：未達、L1：実行（やってる）、L2：管理（計画＋管理）、L3：確立（組織標準あり）、L4：予測可能（定量管理）、L5：革新（継続改善）。
・業界の多くはL2〜L3を目指す。L3が現実的な目標。
・能力レベルは"プロセスごと"に評価される。組織全体ではない。
・OEMはプロセス別にレベル要求してくる。
・カイトはSYS/SWE主要プロセスでL3達成が目標。
第11章 プロセス属性と、4つの評定
ASPICE.010：プロセス属性（PA）と評定（N/P/L/F）
「能力レベルがどうやって決まるか、もう少し深く見ようか」
藤谷さんはホワイトボードに表を描いた。
「能力レベルは、"プロセス属性（PA：Process Attribute）"の評価結果から決まるの」
L1：PA 1.1 プロセスパフォーマンス
L2：PA 2.1 パフォーマンス管理 ＋ PA 2.2 ワーク成果物管理
L3：PA 3.1 プロセス定義 ＋ PA 3.2 プロセス展開
L4：PA 4.1 定量的分析 ＋ PA 4.2 定量的制御
L5：PA 5.1 プロセス革新 ＋ PA 5.2 プロセス革新実装
「各レベルに、1〜2個のPAが対応してる。あるレベルに到達するには、そのレベルのPAと、それより下のレベルのすべてのPAを、ある一定以上のレベルで満たしている必要がある」
4つの評定：N/P/L/F
「で、各PAをどう評価するか。これに4段階の評定（rating）を使う」
・N：Not achieved（未達） ―― 0%〜15%
・P：Partially achieved（部分達成） ―― 15%〜50%
・L：Largely achieved（大幅達成） ―― 50%〜85%
・F：Fully achieved（完全達成） ―― 85%〜100%
「能力レベルNを達成するには、そのレベルのPAがすべてLまたはF、それ以下のレベルのPAがすべてFである必要がある。具体的に言うと、L1達成にはPA 1.1（プロセス実施）がL（Largely、50%以上）以上であればOK。L2達成にはPA 1.1がF（Fully、85%以上）、その上でPA 2.1とPA 2.2がL以上。L3以上も同じ要領で、下位レベルのPAはすべてF、対象レベルのPAはL以上、というルールね」
「ややこしいでしょ。具体例を出すね」
「あるプロジェクトでSWE.3のプロセスを評価したとする。結果が――」
PA 1.1（プロセスパフォーマンス）：F
PA 2.1（パフォーマンス管理）：L
PA 2.2（ワーク成果物管理）：F
PA 3.1（プロセス定義）：P
PA 3.2（プロセス展開）：N
「この場合、能力レベルはいくつになるか？」
「えっと......L1のPA 1.1がFだからL1はクリア」と僕は言った。「L2のPA 2.1がLとPA 2.2がFだから、両方L以上でL2はクリア」
「L3はPA 3.1がPだから、Lに達してないので、L3は未達」
「だから能力レベルはL2、ですか？」
「正解。能力レベルL2達成」
「PA 3.1がもう少し改善されてLになれば、L3に上がる」
用語
PA（Process Attribute）：プロセス属性。能力レベルを定義する評価軸。L1にPA 1.1、L2にPA 2.1・2.2、L3にPA 3.1・3.2、と各レベルに対応するPAがある。
評定（Rating）：各PAの達成度を表す4段階指標。N（Not achieved, 0-15%）、P（Partially, 15-50%）、L（Largely, 50-85%）、F（Fully, 85-100%）。
能力レベル判定の細かいルール
「もう一段深いルールを言うね。能力レベルNを達成するには――」
・レベル1のPA：Fであること
・レベル2〜(N-1)のPA：すべてFであること
・レベルNのPA：LまたはFであること
「つまり、下のレベルは完全達成、対象レベルは大幅達成以上。という条件」
「だから、L2を狙うなら、L1のPA 1.1はFじゃなきゃダメ。Fが取れてないなら、L1止まりになる」
「これも実務的にはよく問題になる。"L2達成"を主張するために、L1のPAをFに上げる必要があるんだけど、これが意外と難しい」
「PAをどうやって評価するか」
藤谷さんはマーカーを置いて、ホワイトボードの隅に小さく書いた。
・BP（Base Practice）：基本プラクティス。L1で評価する
・GP（Generic Practice）：汎用プラクティス。L2以上で評価する
・WP（Work Product）：ワーク成果物。各レベルで参照される
・GR（Generic Resource）：汎用リソース。L2以上で参照される
「これは次の章で詳しくやる。今日はPAと評定の関係まで」
その日のノート。
剛志のノート（11）
・PA（プロセス属性）が能力レベルの構成要素。L1=PA1.1、L2=PA2.1+2.2、L3=PA3.1+3.2、...。
・評定はN/P/L/Fの4段階（0-15-50-85-100%）。
・能力レベルNを達成するには、L1〜N-1のPAがすべてF、レベルNのPAがLまたはF。
・PAを評価する材料がBP（基本プラクティス）、GP（汎用プラクティス）、WP（成果物）、GR（リソース）。
・能力レベルは数字一つだけど、その背後にPAの達成度の組み合わせがある。
第12章 BP・WP・GP・GR ―― 略語の正体
ASPICE.011：プラクティスと成果物（BP/WP/GP/GR）
「成田くん、A-SPICEに出てくる略語、何個までいける？」と藤谷さんは僕に聞いた。
「ええっと、PRM、PAM、PA、BP、GP、WP、GR、SWE、SYS、SUP、MAN、ACQ、SPL、HWE、MLE、PIM、REU......結構たくさんあるんですね」
「うん、A-SPICEは略語の塊なの。今日はBPとGP、WPとGRをしっかり整理するね」
BP：Base Practice（基本プラクティス）
「BPは、各プロセスごとに定義された"基本的にやるべき活動"」
「たとえばSWE.3（詳細設計＆ユニット構築）のBPはこんな感じ――」
・SWE.3.BP1：ソフトウェアユニットを開発する
・SWE.3.BP2：詳細設計を確立する
・SWE.3.BP3：詳細設計の静的検証基準を満たす
・SWE.3.BP4：双方向トレーサビリティを確立する
・SWE.3.BP5：一貫性を保証する
・SWE.3.BP6：詳細設計とユニットコードのレビューを行う
・...（プロセスごとに4〜10個程度のBPがある）
「BPは、能力レベルL1のPA 1.1（プロセスパフォーマンス）を評価するための材料。BPが実施されているか、その成果が出ているかを確認する」
WP：Work Product（ワーク成果物）
「WPは、各プロセスから生み出される成果物」
「SWE.3のWPの例――」
・WP 11-05：ソフトウェア詳細設計
・WP 11-06：ソフトウェアユニット（ソースコード）
・WP 13-04：双方向トレーサビリティ記録
・WP 18-50：レビュー記録
・...
「WPは、A-SPICE全体で標準的な番号体系（11-xx、13-xx、18-xx、19-xxなど）で整理されてる。これがあるから、サプライヤーが何を出してくるべきかが、世界共通で定義される」
GP：Generic Practice（汎用プラクティス）
「GPは、能力レベル2以上のPAを評価するための"汎用的に適用される活動"」
「L2のPA 2.1（パフォーマンス管理）に対応するGPの例――」
・GP 2.1.1：プロセスのパフォーマンス目標を識別する
・GP 2.1.2：プロセスのパフォーマンスを計画・監視する
・GP 2.1.3：プロセスのパフォーマンスを調整する
・GP 2.1.4：責任と権限を明確化する
・GP 2.1.5：リソースと情報を提供する
・GP 2.1.6：関係者を関与させる
「これらは、プロセスの種類を問わず、すべてのプロセスに同じように適用される。だから"Generic（汎用）"」
「L2のPA 2.2（ワーク成果物管理）のGPは、成果物の管理に関するもの。L3のPA 3.1（プロセス定義）のGPは標準プロセスの定義に関するもの。L3のPA 3.2（プロセス展開）のGPはプロジェクトでの適用に関するもの」
GR：Generic Resource（汎用リソース）
「GRは、各PAを支援するリソース。人、ツール、インフラなど」
「これはGPと組み合わせて評価される」
整理：BP vs GP
「ここでよく混乱するから、整理ね」
・BP：プロセス固有の活動。L1の評価材料。
・GP：プロセスに依らない汎用活動。L2以上の評価材料。
「たとえばSWE.3だと、BPは『詳細設計を確立する』みたいなSWE.3固有のこと。GPは『プロセスのパフォーマンス目標を識別する』みたいな、どのプロセスでも同じこと」
「L1の評価では『SWE.3固有の活動をやってるか』を見る。L2以上の評価では『SWE.3を含むすべてのプロセスに対して、汎用的な管理活動をやってるか』を見る」
「L3だと、さらに『SWE.3の標準プロセスが組織で定義されてるか』『プロジェクトに展開されてるか』を見る」
その日のノート。
剛志のノート（12）
・BP（Base Practice）：プロセス固有の基本活動。L1評価の材料。
・GP（Generic Practice）：プロセス横断の汎用活動。L2以上評価の材料。
・WP（Work Product）：成果物。番号体系（11-xx、13-xxなど）で標準化。
・GR（Generic Resource）：人・ツール・インフラなどのリソース。
・SWE.3のBPは「詳細設計を確立する」など。GPは「パフォーマンス目標を識別する」など。
・L1はBP評価、L2以上はGP評価（＋WP/GR）。階層的に判定。
第13章 トレーサビリティという背骨
ASPICE.012：双方向トレーサビリティと一貫性
「成田くん、トレーサビリティ、聞いたことある？」と藤谷さんは僕に尋ねた。
「字面はわかります。"追跡可能性"でしたっけ」
「うん、追跡可能性。何の追跡か、わかる？」
「要求と設計とテストの対応関係、ですか」
「正解。それも、双方向で」
藤谷さんはホワイトボードに、二段の流れを描いた。
システム要求 → SW要求 → SW設計 → SW実装 → SWテスト
↑ ↑ ↑ ↑ ↑
「上から下へ"分解と詳細化"。下から上へ"検証と裏付け"。これが双方向トレーサビリティ」
「具体的に言うと、SYS.2のシステム要求の各項目に対して、SWE.1のソフトウェア要求のどれが対応してるか、識別子で繋ぐ。さらに、SWE.1の要求に対して、SWE.2の設計のどのコンポーネントが、どのSWE.3の関数が、SWE.4のテストケースのどれが対応してるか、すべて識別子で繋ぐ」
「リンクの数は、何百、何千になる。これを管理するためにDOORS、Polarion、Jamaみたいな要求管理ツールを使う」
なぜ双方向なのか
「上から下だけじゃダメなの？」と僕は聞いた。
「ダメ。理由は二つ」
「一つ目。下から上に追跡することで『この実装は、どの要求に基づいているか』が確認できる。逆に言うと、『どの要求にも基づかない実装』が見つかる。これは仕様外の機能、つまりバグの温床。"勝手機能"とも呼ぶ。これがあると、後で予期せぬ問題を引き起こす」
「二つ目。上から下に追跡することで『この要求は、ちゃんと実装されてるか、テストされてるか』が確認できる。これがないと、要求の取りこぼしが発生する。要求の取りこぼしは、納品時に致命傷になる」
「だから双方向。上→下と、下→上、両方向の繋がりを確認できることが、A-SPICEで要求される」
一貫性チェック
「トレーサビリティが取れてるだけじゃ足りないの。"一貫性"も大事」
「一貫性って？」
「たとえば、システム要求では『応答時間100ms以内』って書いてあるのに、SW要求では『80ms以内』、SW設計では『120ms以内を許容』って書いてあったら、トレーサビリティは取れてても、内容が矛盾してる」
「これを定期的にチェックして、矛盾があれば是正する。これが一貫性管理」
「これは人手では限界があるから、要求管理ツールに依存する。それでも、最終的には人がレビューしないと潰しきれない」
「成田くん、SWE.3に入ったら、まずDOORSの操作研修受けてもらうね」と藤谷さんは言った。「リンク作業が、車載エンジニアの日常作業の一部だから」
「Webだとあんまり聞かない概念ですね」
「Webだと、要求と実装の対応はあいまい。JiraのチケットとPRをひも付ける程度。車載は、要求の各項目（リクワイヤメント）と、実装の各ユニットを、ID で結びつける。何百項目×何百ユニット＝何万リンク。これが日常」
「面倒くさそうですね......」
「めっちゃ面倒くさい。でも、これがあるから、後で何か起きたときに、原因がたどれるの。"なぜこの実装になったか" を、20年後でも遡れる」
「20年？」
「自動車の使用期間は20年以上。リコールも20年後に起きることがある。だから、20年前の設計判断の根拠を、いま追跡できる必要があるの」
その日のノート。
剛志のノート（13）
・トレーサビリティ＝要求⇔設計⇔実装⇔テストの対応追跡。
・"双方向"が必須。上→下：要求の実装漏れ防止。下→上：仕様外実装の検出。
・一貫性チェック：トレーサビリティが取れてても、内容が矛盾してたらNG。
・ツール：DOORS、Polarion、Jama。何万リンクを管理する。
・自動車の寿命は20年。20年前の設計判断を遡れる必要がある。
第14章 アセスメントの日 ―― 「証拠を見せてください」
ASPICE.013：アセスメントの実施プロセス
カイト・プロジェクトが本格始動して三ヶ月が経ったある日、僕は初めて"A-SPICEアセスメント"の現場に立ち会った。アセッサ（評価者）と呼ばれる外部の専門家2名が、僕たちの開発プロセスを評価する。
当日朝、会議室には、僕、泉谷さん、藤谷さん、各プロセスの担当者、そして林さんが集まっていた。アセッサの一人は、白髪の50代男性、東京アセスメントセンターの川村さん。もう一人は、40代女性の海外アセッサ、ドイツのintacs認定アセッサのSchmidtさん。
そして、もう一名----顧客側から参加している人物がいた。財前 考平さん（57歳）。アイソーの主要顧客OEMの調達・品質担当だ。眼鏡をかけた小柄な男性だが、目の鋭さがとにかく違う。藤谷さんが「今回は顧客立ち合いアセスメントなので、財前さんもオブザーバーとして参加されます」と説明した。林さんは「は、そうなんですか」と少し顔が強張った。
「Good morning. 今日はSWE.1からSWE.6、SYS.2、SYS.5、MAN.3、SUP.8、SUP.10を、L3の能力レベルで評価します。8時間で1プロセスあたり60〜90分の予定」と川村さんは言った。
「では、SWE.3から始めましょう」
SWE.3の担当者として、僕も同席することになっていた。泉谷さんが概要を説明し、その後アセッサが質問を投げてくる。
「SWE.3.BP2：詳細設計を確立する、について。具体的にどのような成果物がありますか？」
泉谷さんがDOORSの画面を共有して、ADC（自動運転ドメインECU）の詳細設計書を示した。
「現在のADCソフトウェアには7つのSW-Cがあります。それぞれのSW-Cに対して、Polarionで詳細設計書を作成しています。設計書には、関数レベルの責務、入出力、内部ロジック、エラー処理が記載されています」
「サンプルとして、センサーフュージョンSW-Cの詳細設計書を見せてください」とSchmidtさんが言った。
泉谷さんは設計書を開いた。Schmidtさんは画面をしばらく見つめてから、質問した。
「BP3：詳細設計の静的検証基準を満たす、というのがあります。何を静的検証していますか？」
「コーディング規約（MISRA-C:2012）への準拠を、PolySpaceで静的解析しています。各SW-Cのコードに対して、MISRAルール違反がゼロであることを確認しています。違反がある場合は、deviation（逸脱）を文書化し、安全責任者の承認を得ています」
「逸脱の数は？」
「現状、SW-Cあたり平均3〜5件です。すべて文書化済みです」
「BP4：双方向トレーサビリティを確立する、について。トレーサビリティの管理方法は？」
「Polarionで管理しています。各詳細設計項目はSWE.1のSW要求項目にトレースリンクを持ち、各ユニットコードは詳細設計項目にトレースリンクを持っています」
川村さんが質問した。
「最近の変更で、SW要求が変わったケースはありますか？」
「先月、ADCの応答時間要求が変更されました。SYS.2の変更要求からSWE.1、SWE.2、SWE.3へと展開され、影響を受ける詳細設計とユニットコードを修正、再テストを行いました」
「その変更履歴を見せてください。SUP.10の変更要求管理プロセスに沿って実施されたか確認します」
泉谷さんはチケットIDを示し、変更要求の発行から、影響分析、設計変更、コードレビュー、再テスト、ベースライン更新までのフローを画面で見せた。
「OK」とSchmidtさんが頷いた。「BP6：詳細設計とユニットコードのレビューを行う、について。レビュー実施記録はありますか？」
「すべての詳細設計はレビューを経ています。Polarionでレビューワークフローを管理しています」
「では、L2の評価に移ります。PA 2.1：パフォーマンス管理について。SWE.3のパフォーマンス目標は何ですか？」
「ユニットコード作成のスループット、レビュー指摘の平均、再作業率、これらを月次で測定しています。目標値も設定しています」
「測定結果を見せてください」
泉谷さんはダッシュボードを表示した。月次のメトリクスが棒グラフで表示され、目標値との比較が示されていた。
「GP 2.1.1から2.1.6まで、すべて回答できますか？」
「はい」泉谷さんは順に答えていった。プロセス目標の識別、計画と監視、調整、責任の明確化、リソース提供、関係者の関与。それぞれに対して、ドキュメントと記録を示した。
セッションは90分にわたって続いた。
セッションの合間、財前さんが初めて口を開いた。
「アイソーさん」と財前さんは静かな声で、しかし明らかに圧のある口調で言った。「SWE.4の工程表の根拠が薄い。どういう判断でこのスケジュールを引きましたか」
藤谷さんが素早く林さんの方に目を向けた。林さんはPMとして、スケジュール全体を把握している人物だ。
「それは......」と林さんは言葉に詰まった。「開発の実績ベースで引いたスケジュールでして......」
「実績ベースとおっしゃいますが、先行プロジェクトとカイトはASILの要求レベルが違う。ASIL Bと ASIL Dでは検証工数が桁違いに変わる。その根拠を文書で示していただけますか」
林さんは黙った。藤谷さんが横から「財前さん、その点については是正計画の中で追補資料を提出します」とフォローした。財前さんは小さく頷き、「期待しています」とだけ言った。
----林さんが、あんなに言葉に詰まるのを、僕は初めて見た。スケジュールと要工数の根拠を、ここまで鋭く問い詰められるとは。財前さん、怖い。
「これがアセスメント」と藤谷さんは僕に小声で言った。「で、証拠は？----この一言が全て。主張だけでは認められない。文書、記録、データで客観的に示す。それだけ」
「これってかなりキツいですね......」
「キツいけど、合格すると客観的なお墨付きが得られる。OEMに対して『うちのSWE.3はL3です』って言えるのは、こういうアセスメントを通った後だけ」
「もし不合格だったら？」
「指摘事項リスト（findings）が発行されて、是正計画を出す。期限内に是正できれば、再アセスメントで合格判定が出ることもある。但し、是正できなければ、OEMとの契約見直しのリスクもある」
「事業命綱なんですね」
「そう。だから、年に1〜2回のアセスメントに向けて、日々のプロセス運用を整えてる」
廊下で池田さんとすれ違った。「SWE.6のセッション、Schmidtさんに30分みっちり聞かれましたよ。HILSの構成からカバレッジの根拠まで全部。正直しびれました」と池田さんは言った。「でも、記録はちゃんと出せました」と付け加えた。
その日の夕方、アセッサの帰った後、横田さんは結果を全員に共有した。
「SWE.3、L3 Largely achieved（大幅達成）。指摘事項3件。SWE.4とSWE.5もL3達成。SYS.2、SYS.5はL3 Largely。MAN.3とSUP.8はL3 Fully。SUP.10は2件の指摘でL3 Largely」
「指摘事項は何でしたか？」と僕は聞いた。
「SWE.3で、レビュー記録の一部にレビュアー署名が漏れてた。SUP.10で、影響分析の根拠記述が薄かった。これらを3ヶ月以内に是正する計画書を提出する」
「全体としては、カイト・プロジェクトはL3達成」と横田さんは続けた。「これでOEMとの契約条件を満たした。よくやった、みんな」
会議室で拍手が起きた。僕は、何かよくわからない感動を覚えていた。書類仕事と地味な手続きが、こうやって最後に"認められる"形に結びついている。それはWebの世界で見たことのない達成感だった。
その夜のノート。
剛志のノート（14）
・A-SPICEアセスメント：外部アセッサ（intacs認定など）が証拠ベースで評価。
・1プロセスあたり60〜90分のセッション。BP、GPに対する質問と証拠提示。
・主張だけではNG。必ず文書・記録・データで証拠を見せる。
・結果はPA別に N/P/L/F で評定。能力レベル判定。
・指摘事項（findings）には是正計画を提出。期限内に是正で合格。
・年1〜2回の頻度。OEM契約の前提条件。事業の命綱。
・カイトはL3達成。指摘事項は3ヶ月以内に是正。
第15章 二つの兄弟規格 ―― ISO 26262とISO 21434
ASPICE.014：ISO 26262・ISO 21434との関係
アセスメントが無事終わった翌週、僕は泉谷さんに連れられて、安全認証チームのフロアに行った。中月さんという、50代後半の機能安全担当に紹介された。中月さんは灰色のカーディガンにコーヒーの染みをつけていて、机の上には分厚い英語の規格書が積まれていた。
「君が新人の成田くんか」と中月さんは僕を見た。「A-SPICEはわかってきたか？」
「だいぶ慣れてきました」
「じゃあ、その次の話だな。ISO 26262とISO 21434」
中月さんは机の上の本を二冊取り出した。一冊は赤い表紙で「ISO 26262 - Road vehicles - Functional safety」、もう一冊は青い表紙で「ISO 21434 - Road vehicles - Cybersecurity engineering」。
「これがな、A-SPICEと一緒に考えるべき二つの兄弟規格だ。"プロセス三兄弟"とも呼ぶ。A-SPICEが長兄、26262が次男、21434が末弟」
ISO 26262：機能安全
「ISO 26262は、機能安全の規格。2011年に初版、2018年に2版が出た。"機能安全"ってのは、簡単に言うと"システムの誤動作によって人が傷つかないようにする"こと」
「具体的には、ハザード分析・リスクアセスメント（HARA）から始まって、ASIL（Automotive Safety Integrity Level：A、B、C、D の4段階）を決め、それに応じた開発プロセスを適用する」
「A-SPICEは"開発プロセス全般"を扱う物差し。ISO 26262は"安全関連の開発プロセス"を扱う規格。重なる部分も多いし、独立な部分もある」
「重なる部分というのは？」
「たとえば、要求の文書化、設計の文書化、テストカバレッジ、双方向トレーサビリティ、構成管理、変更管理。これらは両方の規格で要求される。だからA-SPICEを満たすプロジェクトは、ISO 26262の出発点を満たしてることが多い」
「逆に、独立な部分というのは？」
「ISO 26262固有の活動。HARA、ASIL分解、安全分析（FMEA、FTA）、安全要求の派生、ASILに応じた検証方法の選択。これらはA-SPICEには直接記述されてない」
「だから、A-SPICEだけでは安全認証は取れない。逆に、26262だけでは"開発プロセス全体"の品質は保証できない。両方が必要」
用語
ISO 26262：道路車両の機能安全に関する国際規格。2011年初版、2018年改訂。E/E（電気・電子）システムの誤動作によるハザード（人体への危害）を防ぐための開発プロセスを定義する。
ASIL（Automotive Safety Integrity Level）：A、B、C、Dの4段階の安全度水準。Dが最も厳しい。ハザードの重篤度・暴露頻度・回避可能性から決定される。
ISO 21434：サイバーセキュリティ
「ISO 21434は、車載サイバーセキュリティの規格。2021年に初版。日本ではUNECEのR155規制と連動して、2022年以降の新型車には対応が必須になった」
「車載セキュリティって、Webセキュリティとどう違うんですか？」と僕は聞いた。
「いい質問。Webセキュリティは"データの盗み・改竄"が主な脅威。車載セキュリティは"車両の制御を奪われる"が主な脅威」
「だから、車載セキュリティでは、TARA（Threat Analysis and Risk Assessment）から始まって、攻撃ツリーを描き、脅威レベルを評価し、対策を決める。"鍵を持ったECU"とか"暗号化通信"とか、暗号と認証が中心的な技術」
「OTAアップデートも、セキュリティの観点で署名・認証が必須。署名のないファームウェアは絶対にECUにインストールしてはいけない」
「A-SPICEと21434の関係はどうですか？」
「これも、A-SPICEに加えてセキュリティ固有のプロセス（TARAとか、セキュリティ要求の派生とか）が必要、っていう関係。A-SPICEには ASPICE for Cybersecurity という派生もあるんだ。これは21434とより親和性が高い」
三兄弟のマップ
中月さんはホワイトボードに三つの円を描いた。重なるベン図のようなもの。
・A-SPICE：開発プロセス全般
・ISO 26262：機能安全プロセス
・ISO 21434：サイバーセキュリティプロセス
「三つは、互いに重なってる。中央に大きな共通領域がある。それは"プロセスとして開発を進める"という共通原則。要求⇒設計⇒実装⇒テスト⇒検証、トレーサビリティ、構成管理、変更管理。これら基本部分は、どの規格でも要求される」
「で、それぞれの独立した部分が、固有のテーマ。26262はハザード・ASIL・FMEA・FTA。21434はTARA・暗号・侵入検知。A-SPICEはアセスメント・PA・能力レベル」
「だから、車載プロジェクトでは、これら3規格を組み合わせて、開発プロセスを設計する」
「カイトプロジェクトでは、機能安全はASIL D、セキュリティもCSMS（Cyber Security Management System）対応で進めてる」と中月さんは言った。
「ASIL Dって、4段階の中でいちばん厳しいやつですよね？」
「そう。L3自動運転だと、誤動作で人が死ぬ可能性が高いから、ASIL Dが要求される。これに対応する開発プロセスは、ハードとソフトとプロセス、全部含めて、車載業界で最高峰のレベル」
その日のノート。
剛志のノート（15）
・"プロセス三兄弟"：A-SPICE（開発プロセス全般）、ISO 26262（機能安全）、ISO 21434（サイバーセキュリティ）。
・重なる部分：要求⇒設計⇒テスト、トレーサビリティ、構成管理、変更管理。
・26262固有：HARA、ASIL、FMEA、FTA。
・21434固有：TARA、暗号・認証、OTA署名。
・カイトはASIL D要求、CSMS対応。L3自動運転だから最高峰。
・A-SPICEだけでは安全・セキュリティの認証は取れない。三兄弟セットが必要。
第16章 4.0という新しい衣
ASPICE.015：Automotive SPICE 4.0の変更点
中月さんとの話の後、僕はもう一度藤谷さんのところに行って、A-SPICEの最新版である「4.0」の特徴を聞いた。
「成田くん、4.0の話だね。これは2023年に出たばかりで、業界はこの数年でゆっくり移行中。3.1からの主な変更点を見ていこう」
藤谷さんはホワイトボードに変更点を箇条書きにした。
変更点1：プロセス群の追加（HWE、MLE）
「これは前にも触れた。Hardware EngineeringとMachine Learning Engineeringの追加。3.1までは"ソフトウェア中心"だったが、4.0で"ハードウェアと機械学習"が公式に加わった」
「これは時代を反映してる。SDV（Software-Defined Vehicle）の流れで、ハード／ソフト／AIが一体になった開発が増えてる」
変更点2：プロセスの再構成
「ここはちょっと正確に言うと――A-SPICE 3.1の時点で、SYS（System Engineering）と SWE（Software Engineering）はすでに独立したプロセスグループとして存在していた。3.1のころから両者は別建てだったの。4.0では新たに HWE（Hardware Engineering）が正式に採用され、加えて MLE（Machine Learning Engineering）が追加された、という整理になる」
「つまり、"エンジニアリング" 全体をハードと機械学習まで含めて、システム／ソフト／ハード／MLの4本柱で明示的に扱う、という方向」
変更点3：BPの再整理と簡潔化
「各プロセスのBPが見直され、表現がより明確になった。冗長な記述が削られ、必要な情報が前面に出るようになった」
「これは"見やすさ"の改善で、内容的な革命ではない。でも、現場の理解しやすさは上がった」
変更点4：WP（成果物）の再分類
「WPの番号体系も整理され、より体系的になった。Automotive SPICE for Cybersecurityなど、派生バージョンとも整合性が取れるようになった」
変更点5：機械学習エンジニアリング（MLE）の体系化
「MLEは VDA Guidelines for ML Engineering をベースに、4つのプロセスで構成されている――」
・MLE.1：ML要求分析（ML Requirements Analysis）
・MLE.2：MLアーキテクチャ（ML Architecture）
・MLE.3：MLモデル訓練（ML Training）
・MLE.4：MLモデルテスト（ML Model Testing）
「これは大きな前進。AIモデルの開発プロセスを、従来のソフトウェアエンジニアリングとは別建てで体系化した。データセットの管理、モデルの学習、評価、リリース、運用、これら全部をプロセスとして扱う」
「ただし、MLEは"発展途上"で、まだ具体的なアセスメント事例は少ない。これからの分野」
変更点6：アジャイル開発との親和性向上
「4.0では、アジャイルやDevOpsとの組み合わせをより意識した表現になった。"反復的開発"や"継続的検証"といった概念が、間接的に取り込まれている」
「これは、車載業界も完全なウォーターフォールではなく、アジャイル/イテレーティブな開発に向かいつつあることを反映してる」
「で、4.0への移行は、どう進めるんですか？」と僕は聞いた。
「業界全体でゆっくり進めてる。OEMによっては、まだ3.1を要求してくるところもあれば、4.0準拠を要求してくるところもある」
「カイトプロジェクトは、3.1ベースで始まって、途中で4.0対応に移行する計画。だから、両方の知識が必要」
「現実的には、3.1と4.0は連続的な改良で、革命的な変化ではない。だから、3.1をちゃんと運用していれば、4.0への移行も比較的スムーズ」
その日のノート。
剛志のノート（16）
・A-SPICE 4.0（2023年）は最新版。3.1からの主な変更点：
・HWE（ハードウェア）とMLE（機械学習）のプロセス群追加。
・3.1で既に分かれていたSYS/SWEに加え、4.0でHWEを正式採用、MLEを新規追加。
・BP/WPの再整理、表現の明確化。
・MLEの4プロセス（VDA準拠）：MLE.1要求分析／MLE.2アーキテクチャ／MLE.3訓練／MLE.4モデルテスト。
・アジャイル/DevOpsとの親和性向上。
・業界移行はゆっくり進行中。3.1と4.0は連続的改良。
第17章 現場に落とす、現場が変わる
ASPICE.016：実プロジェクトへの適用と運用
「成田くん、ここまでA-SPICEの理論をやってきたよね。最後に、現場で実際にどう運用するかの話をするわ」と藤谷さんは言った。
テーラリング：プロジェクトごとの最適化
「A-SPICEは標準だけど、それをそのままプロジェクトに適用するわけじゃない。各プロジェクトの規模、リスク、契約条件に合わせて、"テーラリング" するの」
「テーラリングって？」
「カスタマイズ。たとえば、小規模プロジェクトでは、SUP.4（合同レビュー）を毎回開く必要はないかもしれない。あるいは、ASIL Dのプロジェクトでは、SWE.4のユニットテスト基準をMC/DCカバレッジまで上げる必要がある」
「組織の標準プロセスをベースに、プロジェクトごとに削減・追加・調整して、プロジェクトプランに落とし込む。これがテーラリング」
QMSとの統合
「A-SPICEは単独で存在しない。会社の品質マネジメントシステム（QMS、ISO 9001ベース）の中に組み込まれる」
「QMSがあって、その中にプロジェクト管理プロセス、開発プロセス、QAプロセス、変更管理プロセス、これらがある。A-SPICEは、その開発プロセス部分を強化するためのフレームワーク」
「だから、A-SPICEだけ運用すればいいわけじゃなくて、QMS全体と整合的に運用する必要がある」
ツール環境
「実プロジェクトでは、ツール環境が極めて重要。手作業でA-SPICEを運用するのは非現実的」
・要求管理：DOORS、Polarion、Jama
・モデルベース設計：MATLAB/Simulink、IBM Rhapsody
・コード生成：Simulink Coder、TargetLink
・静的解析：PolySpace、Coverity、Helix QAC
・ユニットテスト：VectorCAST、Tessy、Cantata
・統合テスト：dSPACE、ETAS、Vector CANoe
・構成管理：Git＋PTC Integrity、IBM Synergy
・変更管理：Jira＋カスタムワークフロー
・トレーサビリティ：DOORSやPolarion内の機能
・メトリクス：自社ダッシュボード（PowerBI、Tableauなど）
「これらツールが連携して、要求⇔設計⇔実装⇔テスト⇔メトリクスのデータがリアルタイムに見える化される。これがないと、A-SPICEは運用しきれない」
人と組織
「最後に、人と組織の話」
「A-SPICEを運用するには、専任のプロセスエンジニア（プロセス設計とテーラリングを担当）、QAエンジニア（プロセス監査を担当）、アセッサ（社内アセッサ、外部アセッサ）が必要」
「これに加えて、各プロジェクトのリーダーがプロセスの意義を理解していること、エンジニアがプロセスに従う意識を持っていることが大事」
「カイトでは、私が品質保証担当、横田さんがプロセス管理を兼ね、各サブチームにプロセスチャンピオン（プロセス推進役）を立ててる」
失敗パターン
「A-SPICE運用の失敗パターンを知っておくと、避けやすい」
「失敗1：書類のための書類。A-SPICEに合わせるためだけに、形式的な書類を量産する。中身がない。誰も読まない。これは"形だけプロセス"の最悪パターン」
「失敗2：ツール導入失敗。要求管理ツールを入れたけど、使いこなせない。結局Excelに戻る。これは初期投資が無駄になる」
「失敗3：プロセスとの不整合。A-SPICEプロセスは整備されてるけど、実際の開発はそれとは別のフローで動いてる。記録だけ後付け。これは監査でバレる」
「失敗4：人材不足。プロセス設計者・QA・アセッサが不足してて、運用が回らない。よくある中堅サプライヤーの悩み」
「失敗5：上層部の理解不足。経営層が"A-SPICEは現場の仕事"と思って関与しない。結果、プロセス改善の予算もリソースも降りない」
「で、成功するには？」と僕は聞いた。
「成功には、こういう要素が必要」
・経営層のコミットメント
・QMSとの統合
・適切なツール環境
・プロセスチャンピオンの育成
・継続的な教育と研修
・現場の声を反映する改善サイクル
「ある意味、A-SPICEの運用は、組織文化そのものを変える話。"プロセスを守る文化" を育てる必要がある」
「これは数年がかりの活動。一朝一夕には変わらない」
その日のノート。
剛志のノート（17）
・テーラリング：標準プロセスをプロジェクトごとにカスタマイズ。
・QMSとの統合：A-SPICE単独ではなく、品質マネジメントシステム全体の一部。
・ツール環境：DOORS、Polarion、PolySpace、VectorCASTなど。連携でA-SPICE運用を支える。
・人と組織：プロセスエンジニア、QA、アセッサ。プロセスチャンピオン制度。
・失敗パターン：書類のための書類、ツール失敗、不整合、人材不足、上層部不関与。
・成功には経営コミットメント、教育、改善サイクル。組織文化が問われる。
第18章 A-SPICEを終えて ―― 剛志のノート
ASPICE.017：A-SPICE学習の総合まとめ
カイト・プロジェクトのアセスメントから一週間が経った金曜日の夕方、僕は給湯室で藤谷さんとお茶を飲んでいた。プロジェクトはL3達成で、雰囲気はだいぶ和やかだった。
「成田くん、A-SPICE、半年やってどうだった？」
「最初は、何でこんなに面倒くさい仕組みがあるんだろうって思いました」
「うん」
「でも、徐々にわかってきた気がします。これは、車載業界が、何十年もかけて、何百件もの事故とリコールから学んで、作り上げた仕組みだって」
「そうね」
「Webだと、僕は"早く出す"ことばかり考えてました。でも、車載では"確実に出す"が何より大事。そして、その確実さを担保するために、プロセスがある」
「だんだん、わかってきたじゃない」
「あと、A-SPICEは"OS"だっていう藤谷さんの言葉が、最近すごく腹落ちしてます。これがあるから、機能安全もセキュリティもOTAも、全部が成り立つ。基盤」
「そう。これが分かれば、君はもう車載エンジニアの仲間入りだ」
藤谷さんは微笑んだ。
「で、次は何が来ます？ 機能安全？」
「うん、機能安全（ISO 26262とASIL）。それからSOTIF（ISO 21448）。OTAとSDV（ISO 24089）。AUTOSAR。そして自動運転。一個ずつ、ちゃんと押さえていこうね」
「楽しみです」
「楽しみ、ね」と藤谷さんは少し皮肉っぽく笑った。「半年前の成田くんなら、絶対そんなこと言わなかったと思うわ」
「確かに」
その夜、僕はA-SPICE編の総まとめノートを書いた。
剛志のノート（A-SPICE 総まとめ）
- A-SPICEは評価モデル（規格ではない）。プロセスを"物差し"で測ることで、品質を間接的に保証する。
- 歴史：1990年代のISO/IEC 15504に源流。ドイツのHISが自動車専用版を作って、2005年A-SPICE 1.0。最新は4.0（2023）。
- 二次元フレームワーク：横軸=プロセス（PRM）、縦軸=能力レベル（PAM）。プロセス別にL0〜L5で評価。
- 3カテゴリ・10プロセスグループ：Primary（ACQ/SPL/SYS/SWE/HWE/MLE）、Organizational（MAN/PIM/REU）、Supporting（SUP）。計10プロセスグループ。
- V字モデル：左で分解、右で統合。対称構造でトレーサビリティを担保。
- SYS群：SYS.1要求引き出し→SYS.2要求分析→SYS.3アーキテクチャ→SYS.4統合検証→SYS.5システム検証。
- SWE群：SWE.1要求→SWE.2アーキテクチャ→SWE.3詳細設計＆コード→SWE.4ユニット検証→SWE.5統合検証→SWE.6ソフトウェア検証。
- MAN・SUP群：MAN.3プロジェクト管理、MAN.5リスク管理、MAN.6測定。SUP.1 QA、SUP.8構成管理、SUP.10変更管理など。
- 能力レベル L0-L5：L0未達、L1実行、L2管理、L3確立、L4予測可能、L5革新。多くの組織はL3を目指す。
- PAと評定：PAは能力レベルの構成要素。評定はN/P/L/Fの4段階。
- BP/GP/WP/GR：BP=プロセス固有活動、GP=横断的活動、WP=成果物、GR=リソース。
- 双方向トレーサビリティ：要求⇔設計⇔実装⇔テストの対応。20年間追跡可能。
- アセスメント：外部アセッサが証拠ベースで評価。年1〜2回、契約の前提。
- 三兄弟規格：A-SPICE（開発プロセス全般）、ISO 26262（機能安全）、ISO 21434（サイバーセキュリティ）。
- 4.0の追加：HWE（ハードウェア）、MLE（機械学習）。アジャイル親和性向上。
- 実運用：テーラリング、QMS統合、ツール環境、人材育成、組織文化。失敗パターンを避ける。
- 本質：A-SPICEは"車載開発のOS"。プロセスで品質を作り込む文化の体系化。
こうして、僕がアイソーに来てから半年、A-SPICEの基本を一通り浴びた。何百ページの仕様書、何十時間の研修、何度ものレビューとアセスメント。最初は呪文に見えた略語が、今では一つひとつ意味を持って見える。
でも、ここまでが"OS"の話。OSの上に乗るアプリケーションが、これからの章で待っている。
機能安全（ISO 26262）。SOTIF（ISO 21448）。OTAとSDV。AUTOSAR。自動運転。
藤谷さんに言われたように、一個ずつ、ちゃんと押さえていこう。
カイト・プロジェクトは、まだ始まったばかりだ。
（Part 1 完）