小説で学ぶ自動車ソフトウェア開発 (その3) A-SPICE (1)

前回では、プロジェクト・カイトの全体像と、本書で扱う6つの世界――A-SPICE、機能安全、SOTIF、OTA・SDV、AUTOSAR、自動運転――のつながりを見てきた。

今回から、いよいよ最初のテーマである A-SPICE に入る。

A-SPICEは、自動車ソフトウェア開発における「開発プロセスの物差し」であり、この後に続くISO 26262、SOTIF、OTA、AUTOSAR、自動運転のすべてを支える土台でもある。いわば、車載ソフトウェア開発の"OS"のような存在だ。

内容が大きいため、A-SPICE編は今回の「その3」と次回の「その4」の2回に分けて掲載する。今回はまず、Web系エンジニアだった主人公・成田剛志が、車載ソフトウェア開発の世界に入って最初に感じる戸惑いから始めたい。

Part 1　開発プロセスの基礎 ―― A-SPICE という "OS"

すべての始まり。

車載ソフトウェアの世界に共通する "物差し" を、 ある若手エンジニアの視点から見ていく。

プロローグ ―― 「車のソフトって、Webと何が違うんですか？」

2026年4月、東京郊外。アイソー株式会社 本社・第三開発棟。

転職してきて半年。正直に言うと、僕は毎日のように泣きそうになっていた。

前の会社では、自分はそこそこできるエンジニアのつもりだった。React Nativeでスマホアプリを作って、Goでバックエンドを書いて、AWSにデプロイして、Datadogでメトリクスを見て、月曜の朝にはSlackで「先週のリリース、p99レイテンシ80msまで下がりました」みたいなことを書いていた。同期からも「あいつ伸びてるよな」と言われていたと思う。たぶん。

それが、ここに来てから一週間で打ち砕かれた。

初日に渡された資料の表紙には「Automotive SPICE 4.0 準拠 開発標準（社内版 Rev. 12）」と書いてあって、ページを開いた瞬間に意味のわからない英略語が3つ続いた。SYS.2、SWE.4、MAN.3。ファイル名みたいだが、ファイル名ではない。プロセスの名前だという。プロセスに名前があるという発想自体が新鮮だった。

「成田くん、配属はカイトプロジェクトね。SWEの3から5あたりに入ってもらうから、4月中にA-SPICEの社内研修と、ISO 26262の基礎パート、それからAUTOSAR Classicの方の入門は終わらせておいて」

人事の人が、まるで「来週までにこの本3冊読んでおいて」くらいの軽さで言った。横を見ると、僕より前から座っていた中途の同期、ニック（にっく）さんが涼しい顔で頷いていた。あとから知ったが、彼女は前職で自動運転のE2Eモデルをぶん回していたらしく、組込みの世界に来たのは初めてとはいえ、土俵勘そのものが違った。

とにかく僕は、自分が車のソフトについて本当に何も知らないことを認めるところから始めなければならなかった。

その日、廊下でさっき会議で隣になった太田さんにばったり会った。太田さんも人事説明を終えたばかりらしく、手に同じ「Automotive SPICE 4.0 準拠 開発標準」の分厚い資料を抱えていた。

「太田です。前職はFA系です。組込みは多少わかるんですけど、車載は初めてで」と太田さんは言った。どこかほっとしたような顔をしていた。

「成田といいます。僕はWebからの転職なんで、組込みも車載も全部ゼロです」

太田さんはしばらく黙って、それからニカっと笑った。「......じゃあ、お互い助け合いましょうか」

「それしかないですね」と僕は言った。

二人で廊下に立って、しばらく苦笑いした。お互い、何も知らないもの同士が、これからものすごく深い穴に落ちていくような予感がしていた。

その日の夕方、給湯室に行くと、藤谷さんがいた。昨日の会議と地図の章で話してくれた、品質保証部の藤谷 紀子さん。背が低くて、銀縁メガネで、いつも黒いカーディガンを着ている。社内では「藤谷さんに聞け」が合言葉になっているらしい----それは配属の説明で先輩に聞いた話だ。

「成田くん、人事の説明、終わった？」

「はい、さっき。なんか、いきなりA-SPICEとAUTOSARとISO 26262を4月中に覚えておいてって言われて......」

藤谷さんは小さく笑った。「あの人たちはいつもそういう言い方するのよ。まあ、昨日の地図を覚えてれば、最初の研修はついていけるから」

「あの、昨日の話、まだ半分くらいしかわかってないんですけど」

「それでいい、って言ったじゃない」と藤谷さんは湯気の立つマグカップにお茶を注ぎながら言った。「で、今日一日やってみて、どう思った？　正直に」

「......自分が何もわかってない感じがしてきました」

「ねえ、成田くん、一個聞いていい？」

「はい」

「車のソフトって、Webと何が違うと思う？」

これは、テストだった。即答できないと「あ、こいつ何もわかってないな」と思われる類の質問。でも、僕には嘘をつくほどの知識もなかった。

「......正直、まだよくわからないです。基本的にはコード書いて、テストして、デプロイするって意味では同じじゃないですか？」

藤谷さんは、湯気を見ながら少し黙った。それから、目を上げてこう言った。

「成田くん。Webで作ったアプリが落ちたら、ユーザーが画面をリロードしてくれるよね。最悪、もう一回ログインしてくれる。腹は立てるけど、命は失わない」

「はい」

「でも、私たちが作るソフトは、時速100キロで高速道路を走ってる車の中で動くの。落ちたら、人が死ぬ。誰の命が消えるかもわからないまま、明日の新聞の見出しになる」

「......」

「だからね、私たちの世界には、ルールが多いの。たくさんある。多すぎるくらい。最初は嫌になるよ。でもね、そのルール一つひとつに、過去の誰かが流した血と汗の意味があるの。覚えておいて」

そう言うと、藤谷さんはマグカップを持ってさっさと給湯室を出ていった。僕は、なんとなくその場でしばらく立ち尽くしていた。

その夜、僕は会社から支給された分厚い社内資料を、自分の小さなアパートの机の上に広げた。表紙は「Automotive SPICE 4.0 準拠 開発標準」。研修課題は明日からだ。

「ルール一つひとつに、過去の誰かが流した血と汗の意味がある」

藤谷さんの言葉が頭の隅で繰り返された。

それなら、わかってやろうじゃないか。少なくとも、そのルールがなぜ存在するのか、ちゃんと意味を知った上で、文句を言うか、好きになるか、決めてやる。

僕は表紙をめくった。最初のページにはこう書いてあった。

「ソフトウェアは、書くより前に、設計する。設計するより前に、要求を決める。要求を決めるより前に、何を作るかを決める。──そして、決めたことすべてを、後から検証できるようにしておく」

これが、僕がこれから半年で叩き込まれることになる「V字モデル」の入り口だった。

第1章　会議室の壁に貼られたV字

PROC.001：開発プロセス入門 ― V字モデルの基本構造

翌朝、僕は会議室B-2に呼ばれていた。「カイト・キックオフ」と書かれた予定表。プロジェクト・カイト。それが僕が配属された案件のコードネームだった。聞くところによると、国内大手のOEMから受注した、次世代EVプラットフォーム向けの統合車両制御ソフトウェア一式。SDV対応、OTA前提、L3自動運転モジュールも視野に入っているらしい。

会議室の壁には、模造紙が貼ってあった。大きく「Ｖ」の字が描かれていて、左の斜め下に降りる線と、右の斜め上に登る線が、谷底で繋がっている。線の上にはそれぞれ箱が並んでいた。

左側、上から：

　・お客様の要求

　・システム要求

　・システム設計（アーキテクチャ）

　・ソフトウェア要求

　・ソフトウェア設計

　・実装（コーディング）

右側、下から上に：

　・ユニットテスト

　・ソフトウェア統合テスト

　・ソフトウェア適格性テスト

　・システム統合テスト

　・システム適格性テスト

　・お客様への納入

「これがV字モデル。車載ソフト開発の、いちばん基本の地図」

そう言ったのは、リードアーキテクトの泉谷 賢人さんだった。35歳。ドイツ出向経験あり。背が高くて、シャツのボタンを一番上まで留めていて、声に妙な落ち着きがある。僕の目には、なんとなく「できる人」のオーラがあった。

「左側は『何を作るか』を細かくしていく工程。右側は『ちゃんと作れたか』を確かめる工程。重要なのは、左側のそれぞれの段階に対して、右側に対応する検証段階があるってこと。これを"対称性"と呼ぶ」

泉谷さんは、左側の「システム要求」と右側の「システム統合テスト」を矢印で結んだ。

「システム要求で『前方車両を検知して、必要なら自動でブレーキをかける』と決めたら、システム統合テストで『前方車両を出して、自動ブレーキが本当に効くか』を試す。要求があれば必ず対応するテストがある。テストがあれば必ずそれを正当化する要求がある。これが対称性の意味だ」

横に座っていたニックさんが手を挙げた。

「泉谷さん、これってウォーターフォールの一種ですよね。なんでアジャイルじゃないんですか？」

非常にもっともな質問だった。僕も同じことを聞きたかった。

「いい質問だね、ニックさん」泉谷さんは少し笑った。「答えは、アジャイルでもいい。でも、車載ではアジャイルの中にもこのV字の構造を組み込む。なぜか？」

彼は壁のV字の右下、「お客様への納入」と書かれた箱を指でつついた。

「ここから先、世界中の道路を走るんだ。リコールが起きたら、何百万台に対して対応しなきゃいけない。バグ一個で人が死ぬ可能性もある。だから、『作るときに何を考えたか』を、後から追えるようにしておかないとダメなんだよ。アジャイルでスプリント回しても、最終的にV字のそれぞれの段階の証拠が揃ってないと、認証もとれないし、品質も担保できない」

「証拠......」

「そう、証拠だ。Webだとログとモニタリングが証拠だけど、車載では設計書とテスト結果が証拠になる」

用語
V字モデル：システム開発の流れを「分解（左側を下る）」と「統合（右側を上る）」のV字形で表現したモデル。左側の各段階（要求／設計）に対して、右側の対応する段階（テスト／検証）が存在することを示す。起源はドイツ連邦軍のソフトウェア開発標準であるV-Modell（1986年〜）**で、これがウォーターフォールの欠点を補う形で広まった。なお、ボーム（Boehm）はしばしばV字モデルと混同されるが、彼は別系統の**Spiral Modelの提唱者であり、V-Modellそのものの設計者ではない。現在のV字モデルは、車載開発の事実上の基本構造となっている。

泉谷さんは、模造紙の中央、Vの谷底のあたりを指した。そこには「実装」と書かれていた。

「ここが、君たちエンジニアが普段いちばん長くいる場所。コードを書いて、コミットして、テストを走らせる。でも、谷底からは登っていく必要があるんだよ。実装を作ったら、それを単体テスト、結合テスト、システムテストへと積み上げていく。降りるときに刻んだ階段を、登るときも同じ階段で戻ってくる」

「もし、降りるときの階段と、登るときの階段がズレていたらどうなるんですか？」と僕が聞いた。

泉谷さんは満足そうに頷いた。

「鋭いね、成田くん。それが起きると、最悪な状況になる。たとえば、システム要求では『時速30km以下では自動ブレーキは動作しない』と書いてあるのに、実装では『時速10km以上で動作』と書いてあって、システム統合テストでは『30km以下で動作しないこと』を確認してたら？　ユニットテストは通る、システム統合テストも通る、でも実装は要求と違う。納入後、駐車場で勝手にブレーキがかかって、後続車に追突される事故が起きる」

「うわ......」

「これが、V字の対称性が崩れたときに起きる典型的な事故パターンだ。だから、要求・設計・テストの間で、何と何が対応しているかを必ず追跡できるようにする。これを"トレーサビリティ"と呼ぶ。後でまた出てくるよ」

泉谷さんは模造紙の右側、上から下へ赤いマーカーで矢印を描き加えた。

「もう一個重要なこと。V字は単に開発の段階を表してるだけじゃない。"早期検出"の考え方を内包してるんだ。バグは、それが混入した段階で見つけるほど安く修正できる。要求段階で見つかった矛盾を直すのに必要なのは、ホワイトボードの文字の書き換え。実装段階で見つかったら、コードの修正と再テスト。納入後に見つかったら、リコール費用は数百億円」

「桁が違いますね......」

「これが現実。だからV字の左側、上の方ほど、慎重にやる。慎重にやれば、右側のテストが楽になる。"テストで品質を作り込む"ことはできない。"設計で品質を作り込む"ものなんだ」

会議が終わった後、僕は会議室B-2に一人で残って、しばらく壁のV字を眺めていた。

Webの世界で僕がやっていたことは、たぶん、このV字でいうと右下の「実装」と、右側の「ユニットテスト」だけだった。お客様の要求は誰かが決めてくれていて、システム設計も別の人がやってくれていて、僕は降りた谷底でコードを書いて、登るときも一段か二段しか登らずに、CI/CDというエレベーターで一気にデプロイまで運ばれていく。エレベーターが壊れたら、コミットを戻せばいい。それでよかった。

でも、車では、エレベーターはない。階段しかない。一段ずつ降りて、一段ずつ登る。それぞれの段に、誰かの仕事と、誰かの責任と、誰かの証拠がある。

「ルール一つひとつに、過去の誰かが流した血と汗の意味がある」

藤谷さんの言葉が、また頭の中で繰り返された。

僕は、ノートを取り出した。最初のページに、こう書いた。

剛志のノート（1）
・V字モデル：左で分解、右で統合・検証。左右は対称。
・対応：要求⇔システムテスト、設計⇔結合テスト、コード⇔ユニットテスト。
・バグは早く見つけるほど安い。要求段階で気づけば文字の修正だけ。納入後ならリコール。
・トレーサビリティ：要求と設計とテストの「対応関係」を追跡可能にしておく。
・テストで品質は作れない。設計で品質を作る。

これが、僕のノートの最初の一ページ目だった。

第2章　A-SPICEは "OS" だ

ASPICE.001：A-SPICEの本質 ― なぜ車載業界に独自の評価モデルが必要だったのか

翌週、僕は社内研修「A-SPICE 入門」に呼ばれていた。講師は、藤谷さんだった。

研修室には、僕とニックさんを含めて中途・新人合わせて8人が座っていた。隣には太田さんもいた。太田さんはノートを開きながら「これ、全部今日やるんですか？」と小声で聞いてきた。「わかんない」と僕は正直に答えた。

それから、部屋の後ろの席に池田 佑介さん（31歳）の姿があった。藤谷さんの部下で、テストエンジニアだという。少し仕事に疲れたような顔をしていたが、藤谷さんが前に立った瞬間、手を上げた。

「藤谷さん、また最初から全部やるんですか。僕、もう3回目ですよ」

藤谷さんは一切表情を変えず、「じゃあ3回目ということで、今日は全部あなたに答えてもらいます」と返した。研修室に笑いが起きた。池田さんは「そんな......」と頭を抱えた。

----この人、面白い人だな、と僕は思った。

藤谷さんは黒板に「A-SPICE」と大きく書いた。Aの下に小さく「Automotive」、SPICEの下に「Software Process Improvement and Capability dEtermination」と書き足した。

「Automotive SPICE。略してA-SPICE。日本ではアスパイスとかエースパイスって呼ぶ人もいるけど、業界では普通に "A-SPICE" で通じます」

藤谷さんはチョークを置いて、僕たちを見渡した。

「最初に言っておくと、A-SPICEは『標準』じゃないの。『規格』でもない。これは『評価モデル』なの。違いがわかる？」

誰も手を挙げなかった。藤谷さんは続けた。

「ISO 9001っていう、有名な品質マネジメント規格があるよね。あれは『こういう仕組みを持っていなさい』っていう要求事項を並べた規格。でもA-SPICEはちょっと違う。『プロセスをこういう観点で評価しなさい』っていう"物差し"なの。だから、A-SPICEに準拠するとは言わない。A-SPICEで評価される、と言う」

横でニックさんがメモを取っているのが見えた。中国でも同じ概念があるのかどうか、僕には知りようがなかった。

「で、なんで車載業界はわざわざ専用の評価モデルを作ったか。これが今日の本題」

藤谷さんは、黒板に三つの単語を書いた。「複雑性」「サプライチェーン」「安全」。

「車って、何個のECUが乗ってると思う？」

「ECU」が何かピンと来なかった僕は、隣のニックさんを横目で見た。彼女は即座に答えた。

「100個から、ハイエンド車だと150個くらいですね」

「正解。プレミアム車だと200個に達することもある。Electronic Control Unit、電子制御ユニット。エンジンを制御してるECU、ブレーキを制御してるECU、エアコンを制御してるECU、ドアミラーを動かしてるECU、ぜんぶで100個。そして、それぞれが別の会社、別のサプライヤーが作ってる。OEMはトヨタとかフォルクスワーゲンとか。でも、ブレーキECUはボッシュかコンチネンタルかデンソー。エアバッグECUはオートリブ。MCU（マイコン）はルネサスかインフィニオン。ソフトウェア部品はETASとかVectorとか。これら全部が組み合わさって、一台の車になる」

用語
ECU（Electronic Control Unit）：自動車に搭載される電子制御ユニット。エンジン、ブレーキ、ステアリング、エアコン、ドアロックなど、ほぼあらゆる車載機能はECUで制御される。1台の自動車には100〜200個のECUが搭載されることもあり、それぞれがCAN・LIN・FlexRay・自動車Ethernetなどのバスで相互通信する。

「OEMは、それらサプライヤーが作ってくる部品を、ぜんぶ"信用"しないといけない。でも、信用するためには根拠がいる。『お宅のソフト、品質大丈夫？』って聞かれて、『はい、大丈夫です、信じてください』だけじゃダメなの。何百のサプライヤー全員が同じレベルの品質保証をしていることを、共通の物差しで確認する必要がある」

「それがA-SPICE」と僕は呟いた。

「そう。OEMがサプライヤーを評価するための、業界共通の物差し。これがA-SPICEの存在意義の一つ」

藤谷さんは黒板に戻って、「サプライチェーン」のところに大きく丸をつけた。

「もう一個、もっと深い意味がある。それは、品質を"プロセス"で担保しようっていう発想なの」

「プロセスで......？」

「うん。たとえばさ、テストをいくらやっても、テストしてないところのバグは見つからないでしょ。製品そのものを完璧に検査するのは不可能なの、特に自動車みたいに複雑なものは。だったらどうするか。"良いプロセスで作られたものは、結果も良い"っていう仮説に賭けるの」

藤谷さんは、黒板の右端に二つの円を描いた。一つには「製品の品質」、もう一つには「プロセスの品質」と書いた。

「製品の品質を直接保証するのは難しい。でも、プロセスの品質はもっと観察しやすい。要求はちゃんと書かれてるか？　設計はレビューされてるか？　テストは要求をカバーしてるか？　これは外から見てチェックできる。だから、A-SPICEは"プロセスを評価することで、間接的に製品品質を担保する"っていうアプローチを取ってるの」

「Webだと、デプロイ後にメトリクス見ますよね」と僕は言った。「エラー率とか、レイテンシとか」

「そうだね。でも、車載でその発想はできないの。だって、メトリクスが悪くなった時点で、もう事故が起きてるかもしれないんだから。だから事前に、プロセスで作り込む」

藤谷さんは僕の目を見て、はっきりと言った。

「A-SPICEは、車載開発の"OS"なんだよ。アプリじゃなくて、OS。これがあるから、その上で機能安全（ISO 26262）も、サイバーセキュリティ（ISO 21434）も、OTA（ISO 24089）も、全部成り立つ。基盤なの」

OS、という比喩は、僕にはぴったり来た。アプリを乗せる土台。それ自体は派手じゃないけど、ないと何も動かない。

研修の終わりに、藤谷さんはホワイトボードの隅に、こう書いた。

「A-SPICEは、製品を直接見ない。プロセスを見る。
良いプロセスで作られたものは、結果も良い。
これは仮説だ。でも、車載業界はこの仮説に40年賭けてきた。
そして、今のところ、賭けは外れていない」

その日の夜、僕はノートにこう書き足した。

剛志のノート（2）
・A-SPICEは規格じゃなくて評価モデル（物差し）。
・OEM⇔サプライヤーの間で、品質を共通の物差しで測るための仕組み。
・プロセスを評価する＝間接的に製品品質を担保する戦略。
・"車載開発のOS"。機能安全もセキュリティもOTAもこの上に乗る。
・100〜200個のECUが100社以上のサプライヤーで作られる。だから共通言語が必要。

第3章　ドイツから来た物差し ―― 30年の歴史

ASPICE.002：A-SPICEが生まれた背景 ― 歴史と策定経緯

三回目の研修で、藤谷さんは年表をホワイトボードに描いた。

• 1991年　ISO/IEC が "SPICE プロジェクト" 開始（ソフトウェアプロセス評価の国際標準を作ろう、という運動）
• 1998年　ISO/IEC 15504 ―― 初版が出る
• 2000年代初頭　欧州の自動車メーカー（HIS：Hersteller Initiative Software）が "自動車向けのSPICEが必要だ" と言い出す
• 2005年　Automotive SPICE 1.0 ―― 初版誕生
• 2010年　A-SPICE 2.5
• 2015年　A-SPICE 3.0
• 2017年　A-SPICE 3.1
• 2023年　A-SPICE 4.0

「これね、ぜんぶ覚えなくていい。流れだけ感じてほしい」

藤谷さんは年表の左端、1991年のところを指した。

「1990年代の初め、ソフトウェアって今ほど信用されてなかったの。"ソフトはバグだらけ"っていうイメージが強かった。なぜか？　決まったプロセスがなかったから。会社ごと、プロジェクトごとに、好きにやってた。そりゃ品質もばらつく」

「アメリカのカーネギーメロン大学が、CMMっていうモデルを作って、これが流行ったの。CMM、後にCMMI。ご存知の方も？」

誰かが頷いた。僕は名前は聞いたことがあった気がした。

「で、CMM/CMMIに対抗、というか同じ問題意識から、ISO/IECがSPICEプロジェクトを始めて、ISO/IEC 15504っていう規格を作った。これがソフトウェアのプロセス評価モデルの先祖」

藤谷さんは年表の真ん中、2000年代初頭のところに丸をつけた。

「で、自動車業界はどうなってたか。1990年代後半から、ECUの数が爆発的に増えてた。エンジン制御だけだったECUが、ABS、エアバッグ、トラクションコントロール、エアコン、ナビ、ドアロック......次々と機能がデジタル化された。ソフトウェアの量も、それを作るサプライヤーの数も、爆発的に増えた」

「そうなると、OEMはどうなる？」と藤谷さんは僕たちに聞いた。

「サプライヤーの管理が大変になる、ですね」とニックさんが即答した。

「そう。バラバラの品質、バラバラの開発方法、バラバラの提出物。これを統一しないと、OEM側がパンクする。そこでドイツのHIS、Hersteller Initiative Softwareっていう連合――要するにBMW、ダイムラー、フォルクスワーゲン、ポルシェ、アウディの開発担当が集まって、"自動車専用のSPICEを作ろう" って動き出したわけ」

「ドイツが主導したんですね」と僕は言った。

「うん、Automotive SPICEは基本的にドイツ生まれ。だから今でも、A-SPICEに関するセミナーとかアセッサ資格って、ドイツに本部があるVDA（ドイツ自動車工業会）が中心になってる。日本のOEMも欧州OEMも、結局このVDA系の物差しを使ってる」

用語
HIS（Hersteller Initiative Software）：ドイツの主要自動車メーカー（BMW、ダイムラー、フォルクスワーゲン、ポルシェ、アウディ）が共同で結成したソフトウェア品質に関するイニシアチブ。Automotive SPICEの策定母体となった。

VDA（Verband der Automobilindustrie）：ドイツ自動車工業会。A-SPICEのバージョン管理・アセッサ認定・ガイドライン整備を担う。

「2005年に1.0が出て、徐々にバージョンアップして、今は4.0。最新版は2023年に出たばかり」

「バージョンが上がると、何が変わるんですか？」と僕が聞いた。

「お、いい質問。詳しくは別の章でやるけど、ざっくり言うと――2.0系では『プロセスの種類』が増えていって、3.0でちょっと整理されて、3.1で細かい記述が改善されて、4.0では機械学習やサイバーセキュリティの観点が織り込まれた。あと、ASPICE for Cybersecurityっていう派生もできた。これも別途扱う」

藤谷さんは年表の下に矢印を引いた。

「結局、A-SPICEの歴史っていうのは、自動車業界が"ソフトウェアの複雑さに、組織的にどう対応するか"の歴史なの。最初はECUが数個だったから、各社の独自プロセスで何とかなった。でも、何百個に増えると、共通のルールが必要になった。サプライチェーンが何層にも深くなると、共通の物差しが必要になった。そして安全機能が増えると、プロセスでの品質保証が不可欠になった」

「歴史って、必要だから生まれるんですね」と僕は言った。

「そう。だから歴史を知ると、ルールの存在意義が見えてくる」

藤谷さんは少し笑った。

「もう少しスケールの大きい話をしようか」

「2010年、トヨタが米国でアクセルペダル問題のリコールを大規模に起こした。ソフトの問題ではなかったって最終的には結論づけられたけど、当時は『電子制御がおかしいんじゃないか』って大騒ぎになった。NHTSA（米国運輸省道路交通安全局）が大規模調査を入れて、トヨタは数千億円規模の罰金と訴訟リスクを抱えた」

「2014年、GMが点火スイッチの不具合で何百万台のリコールを行った。これは死亡事故にもつながった。何が問題だったか――社内に問題が報告されてたのに、エンジニアリングプロセス上で適切にエスカレーションされなかった、と」

「2015年、フォルクスワーゲンのディーゼル排ガス不正問題。これはソフトウェアの問題。排ガス検査時だけ動作モードを変える"defeat device"が、ECUのソフトに仕込まれていた」

「これらの事件があるたびに、業界は『プロセスの強化』に向かう。A-SPICE 3.0、3.1、4.0と進化してきた背景には、こうした事件の影響もあるの」

研修室は静かになった。藤谷さんは年表の下に、追記した。

「A-SPICEは、抽象的なルールじゃない。現実の事故・リコール・訴訟から学んできた、業界の集合知の結晶。
それを"うざい"と思うか、"先輩たちの遺言"と思うかで、エンジニアとしての姿勢が決まる」

研修が終わった後、僕はノートに書いた。

剛志のノート（3）
・A-SPICEの源流は1990年代のISO/IEC 15504（SPICE）。
・2000年代に独・HISが「自動車専用版」を作ろうとして、2005年A-SPICE 1.0誕生。
・ドイツ自動車工業会（VDA）が中心。日本も欧州もこの物差しを使う。
・現在は4.0（2023年）。バージョンごとに業界の事件・課題に対応してきた歴史。
・歴史を知ると、ルールの意味が見えてくる。

第4章　プロセスと能力、二つの軸で世界を読む

ASPICE.003：プロセスと能力の2次元フレームワーク（PRMとPAM）

「成田くん、A-SPICEはね、二つの軸でできてるの」

藤谷さんは、ホワイトボードに大きな十字を描いた。横軸に「プロセス」、縦軸に「能力」。

「これがA-SPICEの本質。横軸は"どんな仕事をするか"。縦軸は"その仕事をどれくらいできるか"」

「プロセスは仕事の種類。たとえば『システム要求を分析する』『ソフトウェアを設計する』『テストする』『構成管理する』『不具合を解決する』。こういう活動それぞれが、一つの"プロセス"。A-SPICEではこれらを全部で30個以上に分類してる」

「で、それぞれのプロセスに対して、"能力レベル" を縦軸で測るの。レベル0からレベル5まで、6段階」

藤谷さんは縦軸に数字を書いた。L0、L1、L2、L3、L4、L5。

「L0は『そもそもやってない』。L1は『一応やってる』。L2は『管理されてる』。L3は『標準化されてる』。L4は『定量的に管理されてる』。L5は『継続的に改善されてる』。詳しくはまた別の回で扱うけど」

「だから、たとえばあるサプライヤーの『ソフトウェア要求分析』というプロセスを評価したら、"L2レベル達成"とか"L3レベル不達"とか、そういう判定になるの。プロセスごとに、能力レベルが付く」

用語
PRM（Process Reference Model）：プロセス参照モデル。A-SPICEで定義されたプロセスの一覧と、それぞれのプロセスが達成すべき目的・成果を記述する。「何の仕事があるか」を定義する。

PAM（Process Assessment Model）：プロセスアセスメントモデル。PRMで定義されたプロセスを、能力レベル（L0〜L5）の観点でどう評価するかを定義する。「その仕事をどう測るか」を定義する。

「PRMっていうのが、横軸のプロセスを定義してる文書。Process Reference Model。プロセス参照モデル。"何のプロセスがあるか" を全部列挙してる」

「PAMっていうのが、縦軸の能力レベルを評価する文書。Process Assessment Model。プロセスアセスメントモデル。"そのプロセスをどう測るか" を定義してる」

「この二つでセット。"プロセス×能力" の二次元マトリクスで、サプライヤーの開発力が見える化される。これがA-SPICEの構造」

藤谷さんはマーカーをくるくる回しながら言った。

「ね、成田くん、Webの世界で開発を評価するときって、何を見る？」

「うーん、デプロイ頻度とか、リードタイムとか、変更失敗率とか......DevOpsのFour Keysですかね」

「いいね。あれはアウトカム指標、つまり"結果"を見てる。早く出せてるか、壊れてないか。A-SPICEは違うの。"プロセス" を見る。"早く出せてる" の前に、"要求はちゃんと書かれてるか"、"設計はレビューされてるか"、"テストは要求をカバーしてるか" を見る。結果指標じゃなくて、過程指標」

「だから、A-SPICEと相性のいい組織は、ドキュメントとプロセスを大事にする組織。逆に、"動くものを早く" を最優先する組織は、A-SPICEと相性が悪い場合もある」

「これって、トレードオフですよね......」と僕は呟いた。

「そうなの。だから、現実の現場では、A-SPICEで求められるプロセスを"形だけ"作って、実態はアジャイルやリーンで回す、っていう運用が多い。これは悪いことじゃなくて、規制と現実の妥協点」

「形だけ作って意味あるんですか？」

藤谷さんは少し考えてから、慎重に答えた。

「形は大事なの。なぜなら、トレーサビリティとか、変更管理とか、構成管理とか、ああいう"形"を作っておくと、後から不具合が起きたときに原因究明が可能になるから。"形だけ"って言ったけど、実は形そのものが価値を持つの。中身がアジャイル的でも、外側のフレームがA-SPICE的なら、それは両立する」

「なるほど......」

「ま、これはまた応用編の話ね。今日は『プロセスと能力、二つの軸』だけ覚えて」

その夜、僕はノートに書いた。

剛志のノート（4）
・A-SPICEは二次元のフレームワーク。横軸=プロセスの種類、縦軸=能力レベル（L0〜L5）。
・PRM（Process Reference Model）：プロセスの定義（横軸）。
・PAM（Process Assessment Model）：能力レベルの評価方法（縦軸）。
・"何のプロセスがあるか" × "どれくらいできてるか" = 開発力の見える化。
・Webは結果指標、A-SPICEは過程指標。アプローチが根本的に違う。

第5章　3つのカテゴリ、10のプロセスグループ ―― 地図を広げる

ASPICE.004：プロセスの全体像 ― 3カテゴリ・10プロセスグループ

研修四回目、藤谷さんは大きな模造紙を持ってきて、ホワイトボードに貼った。模造紙には、ピラミッド型の図が描かれていた。

「これがA-SPICE 4.0のプロセス全体像。よく見てね」

藤谷さんは、ピラミッドを三層に分けた。

　・上：Primary（基本プロセス群） ― 製品を作る直接的な活動

　・中：Organizational（組織プロセス群） ― 組織全体の改善活動

　・下：Supporting（支援プロセス群） ― すべての活動を支える基盤

「A-SPICEのプロセスは、まずこの3つのカテゴリに大きく分かれる。Primary、Organizational、Supporting。日本語だと、基本・組織・支援って感じ」

「で、それぞれのカテゴリの中で、さらに"プロセス群（Process Group）"に細分化される。4.0では全部で10プロセスグループあるの。Primaryの中にACQ／SPL／SYS／SWE／HWE／MLEの6つ、Organizationalの中にMAN／PIM／REUの3つ、SupportingにSUPが1つ。順番に行くね」

藤谷さんはピラミッドの各層にラベルを書いていった。

　【Primary（基本プロセス群）】

　　・ACQ：Acquisition（取得） ― 部品やサービスを外から買う活動

　　・SPL：Supply（供給） ― 自社製品を顧客に納める活動

　　・SYS：System Engineering（システム工学） ― システムレベルの要求・設計・統合・テスト

　　・SWE：Software Engineering（ソフトウェア工学） ― ソフトウェアレベルの要求・設計・実装・テスト

　　・HWE：Hardware Engineering（ハードウェア工学） ― ハードウェア開発 ※4.0で追加

　　・MLE：Machine Learning Engineering（機械学習工学） ― ML/AI開発 ※4.0で追加

「ここまでがPrimary。製品開発の本流。SYSとSWEは、君たちが普段の業務で一番接する場所」

　【Organizational（組織プロセス群）】

　　・MAN：Management（管理） ― プロジェクト管理・リスク管理・測定など

　　・PIM：Process Improvement Management（プロセス改善管理） ― 組織のプロセスを良くする活動

　　・REU：Reuse（再利用） ― 既存資産の再利用を組織的に管理

「で、Organizational。組織全体に関わる話。プロジェクトマネジメントもここ」

　【Supporting（支援プロセス群）】

　　・SUP：Support（支援） ― 品質保証、構成管理、変更管理、不具合管理、レビュー、ドキュメント管理など

「Supportingには大きく一つのグループ、SUPがあって、その中にQA（品質保証）、CM（構成管理）、CHM（変更管理）、PM（問題解決管理）など、複数のプロセスが含まれてる」

「全部で30個以上のプロセスがある、って前の章で言ったけど、それがこの構造の中に振り分けられてるの」

構造図
A-SPICE 4.0 プロセス分類：
Primary（製品開発の本流：ACQ・SPL・SYS・SWE・HWE・MLE）／
Organizational（組織活動：MAN・PIM・REU）／
Supporting（横断支援：SUP）
の3カテゴリ・計10プロセスグループ。全プロセス数は約32（4.0時点、細分化により変動）。

「ねえ藤谷さん」と僕は手を挙げた。「4.0で追加された "HWE" と "MLE" って、何ですか？」

藤谷さんは嬉しそうに頷いた。

「いい着眼点。これね、A-SPICE 4.0で初めて公式に追加されたプロセス群」

「HWEはHardware Engineering。今までA-SPICEはソフトウェアにフォーカスしてたんだけど、車載って結局ハード設計と分離できないでしょ。ECUの基板設計とか、センサーとアクチュエータの選定とか、ハードウェア側のプロセスも体系化する必要があった。それでHWEが3.1の補足から4.0で正式採用になった」

「MLEは Machine Learning Engineering。これは時代的な話。AI・機械学習が自動運転やADASでがっつり使われるようになって、"NNモデルの開発プロセス"を従来のソフトウェア開発プロセスとは別に扱う必要があると認識された。それでMLEが追加された」

「これは大事な変化なの。"ソフトウェアの定義" が広がってるっていうこと。コードを書くだけがソフトじゃない。データセット作って、モデル学習して、評価して、デプロイする。これも全部"ソフトウェア開発"だけど、従来のV字モデルとは違う発想が必要。だからプロセスも別建てになった」

「自動運転のところで詳しくやるけど」と藤谷さんは付け足した。

ニックさんが手を挙げた。

「中国だと、AIの方が主流の開発になってきてるんですけど、MLEはA-SPICEの中でちゃんと評価されるんですか？」

「いい質問。実はね、MLEはまだ"発展途上"なの。プロセスとしての枠は4.0で定義されたけど、具体的な評価事例はまだ少ない。中国系OEMがどれくらいMLEを真剣に運用するかは、これからの動向次第」

「面白いですね」とニックさんは呟いた。

「ピラミッドの構造、わかった？」と藤谷さんは振り返って僕たちに聞いた。

「上のPrimaryが製品を作る本流。中のOrganizationalが組織活動。下のSupportingがすべてを支える基盤。一個ずつのプロセスを覚えるんじゃなくて、まずはこのカテゴリの位置関係を頭に入れて」

「Webだと、たとえば SRE と Dev と SecOps と Platform Team があるイメージで、それぞれがプロセスとして整理されてる感じですかね」と僕は言った。

「うん、近いね。ただA-SPICEの場合は、プロセスは"組織"じゃなくて"活動の種類"を表してる。同じ人が複数のプロセスを担当することもあるし、一つのプロセスを複数チームで分担することもある」

「あと、A-SPICEは『誰がやるか』を決めない。『何をやるか』『どう測るか』だけを定義してる。組織の作り方は各社の自由」

「これは大事な性質なの。だからA-SPICEは、ウォーターフォール組織にもアジャイル組織にも、両方適用できる」

藤谷さんは、最後に模造紙の隅に書き加えた。

「プロセスは"活動の種類"。
組織の形を縛らない、共通の枠組み。
だから世界中の自動車メーカーが、サプライヤーが、これを共通言語にできる」

ノートに、僕は書いた。

剛志のノート（5）
・A-SPICEは3カテゴリ・8グループ・約32プロセスの構造。
・Primary：ACQ／SPL／SYS／SWE／HWE／MLE。製品を作る本流。
・Organizational：MAN／PIM／REU。組織活動。
・Supporting：SUP。横断支援（QA・構成管理・変更管理など）。
・4.0でHWEとMLEが追加 ―― ソフトの定義そのものが拡張された。
・A-SPICEは"何をやるか"を定義し、"誰がやるか"は組織の自由。

第6章　V字を歩く ―― 左下から右下へ

ASPICE.005：V字モデルで見るエンジニアリングプロセス

その日、僕は泉谷さんに連れられてプロジェクト・カイトの会議に初めて参加した。会議室にはホワイトボードに大きなV字が描かれていて、その上に色とりどりの付箋が貼られていた。

「成田くん、見てごらん。これがカイトの全体スコープ」

泉谷さんは、V字の左上から順に解説してくれた。

【V字の左側（分解・設計）】

　・お客様の要求（OEMのRFQと仕様書）

　・ステークホルダー要求（社内営業・量産・サービス・規制対応など）

　・SYS.1：システム要求引き出し

　・SYS.2：システム要求分析

　・SYS.3：システムアーキテクチャ設計

　・SWE.1：ソフトウェア要求分析

　・SWE.2：ソフトウェアアーキテクチャ設計

　・SWE.3：ソフトウェア詳細設計とユニット構築

　・（同様に、HWE.1〜3：ハードウェア要求・アーキテクチャ・詳細設計）

【V字の右側（統合・検証）】

　・SWE.4：ソフトウェアユニット検証

　・SWE.5：ソフトウェアコンポーネント検証と統合検証

　・SWE.6：ソフトウェア検証

　・SYS.4：システム統合と統合検証

　・SYS.5：システム検証

　・（同様にHWE.4〜6：ハードウェア検証）

「Aspice 4.0では、これにACQ、SPL、MAN、SUP、PIM、REU、MLEが、V字を支える周辺プロセスとして付属する」と泉谷さんは言った。

「左側のSYS.1〜3、SWE.1〜3が"設計を細かくしていく"工程。右側のSWE.4〜6、SYS.4〜5が"作ったものを統合して検証する"工程。それぞれの段階で成果物が定義されている」

「成果物って、具体的には？」と僕は聞いた。

「たとえばSYS.2のシステム要求分析だと、システム要求仕様書、機能安全要求の初期分析、サイバーセキュリティ要求の初期分析。SYS.3のシステムアーキテクチャ設計だと、ハイレベルアーキテクチャ図、コンポーネント間インタフェース仕様。SWE.2のソフトウェアアーキテクチャ設計だと、コンポーネント分解図、SW-Cの責務定義、コンポーネント間データフロー」

「全部ドキュメント......」

「全部ドキュメント。コードもあるけど、コードを書く前に、まず文書が要る。これが車載のスタイル」

「で、対応するテスト工程では、それぞれの要求・設計を網羅するテストケースを作る。SYS.2の要求はSYS.5のシステム検証でカバー、SWE.1の要求はSWE.6のソフトウェア検証でカバー、SWE.3の詳細設計はSWE.4のユニット検証でカバー、っていう感じで」

泉谷さんはV字の上に矢印を描き加えた。

左：お客様の要求 ⇔ 右：受け入れテスト

左：システム要求 ⇔ 右：システム検証（SYS.5）

左：システムアーキテクチャ ⇔ 右：システム統合検証（SYS.4）

左：SW要求 ⇔ 右：SW検証（SWE.6）

左：SWアーキテクチャ ⇔ 右：SW統合検証（SWE.5）

左：SW詳細設計 ⇔ 右：SWユニット検証（SWE.4）

「これがA-SPICE的なV字の正式版」

「全部のレベルでテストするんですか？」と僕は驚いた。「重複しないんですか？」

「重複は完全には避けられない。でも、それぞれのレベルで"見ている観点"が違うんだ」

「SWE.4のユニット検証は、コードレベルの細かい振る舞いを検証する。SWE.5はコンポーネント間のインタフェースが期待通り動くか。SWE.6はソフトウェア全体として要求を満たしてるか。SYS.4はソフトとハードを統合したシステムが期待通り動くか。SYS.5はシステム要求がすべて満たされているか」

「観点が違うから、見つかるバグも違う。ユニットテストでは見つからないバグが、統合テストで見つかることはよくある。逆に、システムテストでは見つけにくいバグがユニットテストで見つかることもある」

「だから、V字の各段で対応するテストをやるのは、無駄じゃなくて"観点の網羅" なんですね」

「その通り」

泉谷さんは、ホワイトボードの隅に小さく書いた。

「V字は、上から下への階段。
階段の段差ひとつひとつに、別の観点と別の責任がある。
省略すると、必ずどこかで落ちる」

「カイトでは、V字の各段に担当者を割り当てる。SYS担当、SWE担当、HWE担当。それぞれが、自分の段の責任を持つ」

「成田くんは、SWE.3〜5あたりを担当してもらう。詳細設計とユニット検証、そしてコンポーネント統合検証。これは"V字の谷底に近い場所" で、いちばんコードに近い」

「正直、ホッとしました」と僕は言った。「いきなりシステム要求とか言われたら、どうしようかと」

「最初は谷底でいいんだ。ただ、谷底にいるからこそ、谷の両側からどんな指示が降りてくるかを意識しておくこと。SWE.3の詳細設計に間違いがあると、SWE.2のアーキテクチャ設計を見直す必要が出てくる。それは時間とコストがかかる。だから、上から降りてくる前提条件を、しっかり読んで、納得してから着手すること」

「了解です」

泉谷さんはホワイトボードのV字の谷底に、僕の名前とニックさんの名前を書いた。「Yuma & Ryouka, SWE.3-5」と。

「明日からだ。よろしく頼む」

その日、ノートに僕はこう書いた。

剛志のノート（6）
・V字を細分化すると、左：SYS.1-3 → SWE.1-3。右：SWE.4-6 → SYS.4-5。
・各段に対応するテストがある（対称性）。観点が違うから無駄じゃない。
・成果物はほぼ全部ドキュメント＋設計図。コードは谷底に近い場所。
・自分はSWE.3-5担当。詳細設計とユニット〜統合検証。
・上の段から降りてくる前提を必ず確認してから着手する。

第7章　システムを刻む人たち ―― SYS群の物語

ASPICE.006：システムエンジニアリングプロセス群（SYS.1〜5）

カイト・プロジェクトの最初の三週間、僕は泉谷さんが率いるシステムエンジニアリング・チームの会議に同席させてもらった。SWE.3担当に入る前に、上の段で何が起きているのかを見ておけ、というのが泉谷さんの方針だった。

SYS群と呼ばれるシステムエンジニアリングは、A-SPICEでは5つのプロセスに分かれている。

　・SYS.1：要求引き出し（Requirements Elicitation）

　・SYS.2：システム要求分析（System Requirements Analysis）

　・SYS.3：システムアーキテクチャ設計（System Architectural Design）

　・SYS.4：システム統合と統合検証（System Integration and Integration Verification）

　・SYS.5：システム検証（System Verification）

泉谷さんは、それぞれを順に説明してくれた。

SYS.1：お客様の声を聞く

「SYS.1は、お客様、つまりOEMから、ステークホルダー全員から、要求を引き出すフェーズ。何が欲しいのか、何ができないと困るのか、どんな環境で使うのか」

「これはエンジニアリングの仕事じゃなくて、半分マネジメント・半分対話の仕事に見えるかもしれない。でも実は、ここで聞き漏らした要求は、後工程で必ず爆発する」

「カイトの例で言うと、OEMからは『L3自動運転対応』『OTAでのアップデート可能』『2027年量産開始』『欧州型式認証取得』『ASIL D含む機能安全対応』みたいな、ばっくりした要求が来た。これだけだと、何を作るかわからない。だからSYS.1のプロセスでは、それを"具体的に聞き出す"」

「具体的って、どこまで？」と僕は聞いた。

「L3自動運転、ってだけだと不明。高速道路だけ？　市街地も？　最高速度は？　ODD（運用設計領域）はどう定義する？　ドライバーの引き継ぎ時間は何秒？　失敗時のフォールバック挙動は？　夜間・雨天・雪はサポートする？　......全部聞く。聞かないと設計できない」

「聞いてないことを勝手に決めると？」

「お客様と認識がズレて、最後の検収でひっくり返される。何百万、何千万、下手したら億単位の損失になる。だからSYS.1は地味だけど、めちゃくちゃ重要」

SYS.2：要求を「分析」する

「SYS.2は、SYS.1で引き出した要求を、システム視点で構造化・分析する」

「分析って、何を？」

「機能要求と非機能要求を分ける。機能要求は『何をするか』、非機能要求は『どう動くか』。たとえば、機能要求『前方車両を検知する』に対して、非機能要求『応答時間100ms以内』『誤検知率0.1%以下』『動作温度-40℃〜+85℃』。これを揃えないとアーキテクチャが描けない」

「機能安全要求も、ここで初期分析が入る。たとえば『前方衝突警報がASIL B』『緊急ブレーキがASIL D』みたいに、機能ごとに安全度を見積もる。これはISO 26262と密接に絡む」

「サイバーセキュリティ要求も、ここで初期分析。たとえば『OTAアップデートは認証必須』『CANメッセージは暗号化』みたいに、セキュリティ要求を識別する。これはISO 21434と関連」

「だから、SYS.2のアウトプットは、すごく分厚い『システム要求仕様書』になる。何百ページ規模。これがプロジェクトの全体設計の起点」

SYS.3：システムをコンポーネントに分解する

「SYS.3は、システムを"コンポーネント"に分解して、アーキテクチャを定義する」

「カイトでは、車両全体を以下のように分解した――」

　・パワートレインECU（モーター制御）

　・バッテリ管理ECU

　・ブレーキECU

　・ステアリングECU

　・統合車両制御ECU（VCU）

　・自動運転ドメインECU（ADC）

　・ボディドメインECU

　・コネクテッドECU（OTA・テレマティクス）

　・センサー類（カメラ、レーダー、LiDAR、超音波）

「これらが、どのバスで、どんなメッセージをやり取りするか、をすべて定義する。CANで繋ぐのか、Ethernetか、FlexRayか。応答時間はどれくらい必要か。冗長化はどう取るか。フェイルセーフはどう設計するか。これらを全部、SYS.3で決めていく」

「これはもう、Web開発の"システム設計"と発想が違いますね」と僕は言った。「Webだと、マイクロサービスを増やすのも比較的簡単じゃないですか。でも車だと、後からECUを増やすことはほぼできないですよね」

「その通り。だからSYS.3の段階で、将来の拡張可能性まで考えておく必要がある。OTAでアップデートできる範囲は何か、ECUの計算余力はどれくらい確保するか、メモリの余裕は、通信帯域の余裕は......これを"アーキテクチャマージン"と呼ぶ。これを誤ると、製品化後に詰む」

SYS.4：統合する

「SYS.4は、ソフトウェアとハードウェアを統合して、システム全体として動くかを検証する」

「個々のECUは単体ではテスト済み。SW-Cレベルでもユニットテスト済み。それを実車（または実車相当のテストベンチ）に統合して、コンポーネント間のインタフェースが期待通り動くかを確認する」

「ここで見つかる典型的なバグ：タイミング異常、通信負荷オーバー、エラー伝播の問題、フェイルセーフの誤動作、電源シーケンスの問題」

「SYS.4は、HIL（Hardware-in-the-Loop）テスト、ベンチテスト、台上テスト、実車テストの段階を踏んで進める。各段階で発見されるバグの種類が違う」

SYS.5：システム要求を満たしているか

「SYS.5は、お客様の要求がすべて満たされているかをシステム全体として検証する」

「SYS.1で引き出した要求、SYS.2で分析した要求、これらが全部、システムレベルで実装され、動作することを確認する」

「ここで使われる典型的なテスト：機能テスト、性能テスト、ストレステスト、環境試験（高温・低温・振動・EMC）、寿命試験」

「SYS.5を通過したら、ようやくお客様に納品できる。納品後、お客様が独自に受け入れテストを行って、最終的にOK判定が出る」

そこで、会議室のドアが開いた。林さんだった。

「泉谷さん、SYS.2の仕様書、いつ固まるんですか」と林さんは言った。「それ、いつ終わるの」

泉谷さんは「2週間後の予定です。今、SYS.1のレビューが終わったところで」と答えた。

「顧客に説明できる？　来週月曜にOEM側へ中間報告するんで、スケジュール表だけでも先に出してほしい」

泉谷さんは少し考えてから「わかりました。今週中に進捗表だけ先行で出します」と答えた。林さんは頷き、さっさと出ていった。

----先輩が言っていた「スケジュールのことになると目の色が変わる」という話は、本当だった。でも、PMとしてはそれが仕事なのかもしれない、とも思った。

「SYS.1からSYS.5まで、これが車載の"システム設計から検証までの流れ"」と泉谷さんは結んだ。

「SWE群は、このSYS群の中にネストする形で動く。つまり、SYS.2でシステム要求が決まったら、その下でSWE.1のソフトウェア要求が決まる。SYS.3でアーキテクチャが決まったら、その下でSWE.2のソフトウェアアーキテクチャが決まる」

「だから、SYSとSWEは平行ではなく、SYSが先・SWEが後、という流れになる。これは時系列的にもそう」

「ただし、現実にはSYSが完全に確定してからSWEを始めるわけにはいかない。並行に進める。並行に進めながら、SYSの変更がSWEに、SWEの実装上の制約がSYSに、お互いにフィードバックされる。これを"反復"と呼ぶ」

「反復は良いんだけど、ちゃんと管理しないと、SYSとSWEの間で要求のバージョン違いが発生する。Aさんは『前方車両検知の応答時間100ms』を見て設計してるけど、Bさんは『80ms』に変わったあとの要求を見て設計してる、みたいなことになる。これを防ぐのが構成管理と変更管理」

「これも、後でSUP群のところで詳しくやる」

その日、ノートに書いた。

剛志のノート（7）
・SYS.1：お客様・関係者から要求を引き出す。
・SYS.2：要求を機能・非機能・安全・セキュリティで構造化分析する。
・SYS.3：システムをコンポーネントに分解、アーキテクチャを定義（CAN/Ethernetなど通信も含む）。
・SYS.4：ソフトウェアとハードウェアを統合・統合検証。HIL→ベンチ→実車。
・SYS.5：システム要求がすべて満たされているか検証。性能・環境・寿命試験を含む。
・SWE群はSYS群の中にネストする。SYSの中で並行に走るが、構成管理と変更管理で同期する。

第8章　ソフトウェアの六姉妹 ―― SWE群の物語

ASPICE.007：ソフトウェアエンジニアリングプロセス群（SWE.1〜6）

「成田くん、明日からはSWE群の解説をする。これが君の直属の仕事のフレーム」と、泉谷さんはホワイトボードに新しいV字を描いた。今度はソフトウェアにフォーカスしたV字だった。

SWE群は6つのプロセスからなる。SWE.1からSWE.6まで、ちょうど6人の姉妹のように、順番に役割を担う。

　・SWE.1：ソフトウェア要求分析

　・SWE.2：ソフトウェアアーキテクチャ設計

　・SWE.3：ソフトウェア詳細設計とユニット構築

　・SWE.4：ソフトウェアユニット検証

　・SWE.5：ソフトウェアコンポーネント検証と統合検証

　・SWE.6：ソフトウェア検証

SWE.1：ソフトウェアにとって、何を要求するか

「SWE.1は、SYS.2で定義されたシステム要求のうち、ソフトウェアが担当する部分を切り出して、ソフトウェア要求として定義する」

「たとえば、SYS.2で『前方衝突警報の応答時間100ms以内』という要求があったとする。SWE.1では、これを"ソフトウェア視点で何が要求されるか"に翻訳する。具体的には、『カメラ画像取得から警報トリガー出力までのソフトウェア処理時間が80ms以内（残り20msはハードと通信のため）』というように、ソフトウェア固有の要求に変換する」

「あと、ソフトウェア固有の非機能要求もここで定義する。たとえばメモリフットプリント、CPU使用率、起動時間、ログレベル、エラー時の挙動、再起動シーケンスなど」

SWE.2：ソフトウェアの中身を設計する

「SWE.2は、ソフトウェアをコンポーネントに分解する。"SW-C"と呼ばれるソフトウェアコンポーネントの集合として、アーキテクチャを描く」

「たとえば自動運転ドメインECU（ADC）のソフトウェアは、以下のようなSW-Cに分解される――」

　・センサーフュージョンSW-C

　・物体追跡SW-C

　・行動予測SW-C

　・経路計画SW-C

　・車両制御コマンド生成SW-C

　・診断SW-C

　・ログ管理SW-C

「それぞれのSW-Cが、どんなインタフェースで、どんなデータをやり取りするかを定義する。これはAUTOSARの世界では"ポート"と"インタフェース"として実装される」

「Webだと、これってマイクロサービスのAPI設計に近いですよね」と僕は言った。

「うん、似てる。ただ、SW-Cは"同じECU内"で動く場合が多くて、その場合は通信オーバーヘッドが小さい。マイクロサービスとAUTOSARのSW-Cは、似てるけど分散の度合いが違う」

SWE.3：詳細設計、そしてコードへ

「SWE.3は、各SW-Cの内部実装を詳細設計する。アルゴリズム、データ構造、内部ステートマシン。そして実装、つまりコードを書く」

「ここが、君が一番手を動かす場所だ、成田くん」

「SWE.3の成果物は、詳細設計書とソースコード。詳細設計書には、関数レベルの責務、入出力、内部ロジックの記述、エラー処理ポリシー、コーディング規約（MISRA-Cなど）への準拠が記載される」

「MISRA-Cって何ですか？」と僕は聞いた。

「車載C言語のコーディング規約。Motor Industry Software Reliability Associationが定めた。"未定義動作を避ける"、"暗黙の型変換を禁止"、"動的メモリ確保を制限"とか、安全に書くためのルール。約150〜200個のルールがある」

「これに準拠しないコードは、車載組込みでは基本受け付けない。最近はMISRA-C:2012が主流、Cの場合。C++ならMISRA-C++またはAUTOSAR C++ Coding Guidelines」

用語
MISRA-C：自動車業界向けのC言語コーディング規約。1998年に初版、現在は2012年版（MISRA-C:2012）と2023年版が主流。安全クリティカルな組込みソフトウェアで、未定義動作・暗黙変換・動的メモリ確保などを制限する。違反は静的解析ツール（PolySpace、Coverity、Helix QAC等）で検出する。

SWE.4：書いたコードを試す

「SWE.4は、SWE.3で実装したユニット（関数レベル・モジュールレベル）を検証する」

「Webのユニットテストと基本的には同じ。ただ、車載では『要求と実装の対応関係（双方向トレーサビリティ）』が要求される。つまり、ユニットテストケースは、必ずSWE.3で定義された詳細設計の要求／仕様にトレースできなければならない」

「もう一つの違いは、"カバレッジ"の要求。ISO 26262でASILの高い機能（ASIL C/D）は、MC/DCカバレッジ（Modified Condition / Decision Coverage）まで要求されることがある。これは『分岐条件のすべての組み合わせをテストする』もっとも厳しいカバレッジ」

SWE.5：コンポーネントを繋いでみる

「SWE.5は、複数のSW-Cを統合して、コンポーネント間のインタフェースが期待通り動くか検証する」

「たとえば、センサーフュージョンSW-Cと物体追跡SW-Cを繋いで、フュージョンの出力データが追跡の入力として正しく機能するか。デッドラインを守れるか。エラー時の挙動が設計通りか」

「これはユニットテストでは見えないバグが顕在化する場所。タイミング、データの不整合、共有資源の競合、メモリリーク、リソース使用量の予期せぬ増加......」

SWE.6：ソフトウェアを丸ごと検証する

「SWE.6は、すべてのSW-Cを統合した状態のソフトウェア全体として、SWE.1で定義した要求を満たしているか検証する」

「これがソフトウェア検証の最終フェーズ。この後はSYS.4のシステム統合検証に進んで、ハードと組み合わせる」

「SWE.1〜6、これが君が直接触れるプロセス群だ」と泉谷さんは言った。「特にSWE.3〜5は毎日の仕事になる」

「SWEで大事なのは、上のSYS、下の検証、両方への意識を持つこと。SYSから降りてきた要求は、確実にSWEに反映されているか。SWEで書いた実装は、検証で確実に拾えているか。これを"トレーサビリティ"の章でまた扱う」

「あと、SWE群は単独で完結しない。SUP群（特に構成管理・変更管理・問題解決）と密接に連携する。コードをコミットしたら、それは構成管理に登録される。バグが見つかったら、問題解決プロセスに乗る。要求が変わったら、変更管理プロセスを通る」

「全部、後でやる」と泉谷さんは笑った。

廊下ですれ違った池田さんが、ドアの外から声をかけてきた。「SWE.6の話、いまやってましたか？」

「ちょうど終わったとこ」と泉谷さんが答えた。

「HILSとSILSの検証環境、先月整備したんで、SWE.6のキャンペーンテスト、僕が仕切ります。成田さんも要件定義のトレースで協力してほしいんですけど」と池田さんは言った。軽い口ぶりだったが、目は真剣だった。

「よろしく頼む」と泉谷さんは頷いた。池田さんは「ぜひぜひ」と軽い調子で去っていった。

その日のノート。

剛志のノート（8）
・SWE.1：ソフトウェア要求分析（システム要求からSW部分を切り出す）。
・SWE.2：ソフトウェアアーキテクチャ設計（SW-Cへの分解）。
・SWE.3：詳細設計＆ユニット構築（コードを書く）。MISRA-C準拠。
・SWE.4：ユニット検証。要求⇔テストのトレーサビリティ必須。ASIL高いとMC/DCカバレッジ。
・SWE.5：コンポーネント検証＆統合検証。インタフェース・タイミング・競合のバグ。
・SWE.6：ソフトウェア検証（SW全体としての要求満足）。
・SWE群はSUP群と密接連携（構成管理・変更管理・問題解決）。

第9章　守る人たち ―― MANとSUPの仕事

ASPICE.008：管理プロセス（MAN）と支援プロセス（SUP）

翌週、僕は藤谷さんに引っ張られて、品質保証部のフロアを見学していた。SWE群が"製品を作る"プロセスだとすると、MAN群とSUP群は"製品作りを支える"プロセスだという。

MAN：管理する

「MANはManagement、管理。ここには5つのプロセスがあるの」と藤谷さんは説明した。

　・MAN.3：プロジェクト管理

　・MAN.5：リスク管理

　・MAN.6：測定（メトリクス）

　・（A-SPICEには元々 MAN.1／MAN.2 は存在しない。MAN.1/2はISO/IEC 12207系の番号で、A-SPICEでは MAN.3〜MAN.6 が中心）

「MAN.3はプロジェクト管理。スケジュール、リソース、コスト、進捗、関係者調整。これは普通のPM業務。ただし、車載プロジェクトは規模が大きいから、ガントチャートも巨大になるし、関係者も多い」

「MAN.5はリスク管理。プロジェクト上のリスクを識別、評価、対策する活動。ここで言うリスクは、機能安全のリスク（ハザード）とは別の、プロジェクトリスク。納期遅延、技術的不確実性、サプライヤー依存、規制変更など」

「MAN.6は測定。プロジェクトの状態を定量的に把握するための指標を定義・収集・分析する。たとえば、不具合密度、テストカバレッジ、コードレビュー指摘数、要求変更頻度、再テスト率......」

「Webだとよく聞くようなメトリクスですね」と僕は言った。

「うん、似てる部分はある。ただ、ここでも目的が違うの。Webだと『改善のため』にメトリクスを使うけど、車載では『プロセス能力を証明するため』にメトリクスを使う。アセスメントの際に、"うちはちゃんと測ってます"を証拠として見せる」

SUP：支える

「SUPはSupporting。横断的な支援活動。ここが私の本拠地」と藤谷さんは少し誇らしげに言った。

　・SUP.1：品質保証（Quality Assurance）

　・SUP.2：検証（Verification）

　・SUP.4：合同レビュー（Joint Review）

　・SUP.7：文書化（Documentation）

　・SUP.8：構成管理（Configuration Management）

　・SUP.9：問題解決管理（Problem Resolution Management）

　・SUP.10：変更要求管理（Change Request Management）

「SUP.1は品質保証。これは"品質をチェックする"んじゃなくて、"プロセスが定義通り回ってるかチェックする"の。ここ間違える人多いんだけど、QAは検査じゃない。プロセス監査なの」

「SUP.2は検証。SWE.6やSYS.5みたいな、プロダクト検証とは別に、"プロセスや成果物が要求を満たしているか"を独立に検証する活動。たとえばコードレビューを第三者がやる、テストケースが要求を網羅してるかを第三者がチェックする、みたいな」

「SUP.4は合同レビュー。複数の関係者でレビューする活動。OEMとサプライヤーの合同レビュー、自社内の複数部門合同レビューなど」

「SUP.7は文書化。ドキュメントのライフサイクル管理。作成、レビュー、承認、改版、廃棄」

「SUP.8は構成管理。これがすごく重要。何が、どのバージョンで、誰によって、いつ変更されたか、全部追跡する。Gitに似てるけど、Git以上に厳密。要求書、設計書、ソースコード、テスト結果、すべてが構成管理の対象」

「SUP.9は問題解決管理。バグや不具合の管理プロセス。検出から修正・確認・クローズまでの流れ」

「SUP.10は変更要求管理。要求や設計を変更する場合の手続き。インパクト分析、承認、伝達、確認」

「全部、Webでも似たような仕組みはあるけど、車載では"プロセスとして定義され、文書化され、評価される" のが違い」

「ねえ藤谷さん」と僕は聞いた。「QAって、品質をチェックする部署じゃないんですか？」

「うん、誤解されがちなんだけど、QAは"品質保証"。"品質"そのものをチェックするのは検査部門。QAは"プロセスが定義通り運用されているかを保証する"のが本来の役割なの」

「具体的に言うと、私が普段何やってるかというと、各プロジェクトを巡回して、『SWE.3の詳細設計レビューが規定通り行われてますか？』『SWE.4のユニットテスト結果は構成管理に登録されてますか？』『SUP.10の変更要求は手続きを踏んでますか？』みたいなチェックをしてるの。プロダクトじゃなくて、プロセスを見る」

「もしプロセス違反を見つけたら？」

「指摘して、改善計画を出してもらう。是正処置（CA：Corrective Action）と再発防止策（PA：Preventive Action）。これも全部記録に残す」

「めちゃくちゃ官僚的ですね......」

「そう。でもね、これがあるから、品質が一定以上に保たれるの。人間って、放っておくとサボるから。QAはサボらないための仕組み」

藤谷さんは笑った。

「私、自分のことを"プロセスのお目付け役"だと思ってるの。エンジニアからは煙たがられるけど、製品が世に出てから事故を起こさないように、毎日チェックリストを持って回ってる」

その日のノート。

剛志のノート（9）
・MAN群：プロジェクト管理（MAN.3）、リスク管理（MAN.5）、測定（MAN.6）。
・SUP群：QA（SUP.1）、検証（SUP.2）、合同レビュー（SUP.4）、文書化（SUP.7）、構成管理（SUP.8）、問題解決（SUP.9）、変更管理（SUP.10）。
・QAはプロダクト検査じゃなくて、プロセス監査。
・構成管理（SUP.8）はGit以上に厳密。要求・設計・コード・テストすべてが対象。
・変更管理（SUP.10）は要求や設計の変更に対するインパクト分析と承認手続き。
・MAN/SUPは"製品作りを支える"プロセス群。