ASPICE SUP.8 構成管理とは？— なぜ「変更履歴」が安全につながるのか

「構成管理」と聞くと、地味な事務作業のように感じるかもしれません。しかし自動車のソフトウェアで一度フィールド不具合が起きたとき、最初に問われるのは「その車両には、いつの時点のどのソフトウェアが載っていたのか」「その版はいつ、誰が、なぜ変更したのか」ということです。

これに即答できるかどうかを支えているのが、Automotive SPICE®のSUP.8（構成管理）です。

SUP.8とは何か

SUP.8は、開発の過程で生まれる成果物（要件書、設計書、ソースコード、テスト仕様、ツール設定など）を「構成品目」として管理し、いつでも特定の版を一意に取り出せる状態を保つためのプロセスです。

SUPは「支援プロセス（SUpporting Process)」の略で、SYSやSWEのように直接ものを作るプロセスではありませんが、それらすべてを裏側から支える基盤にあたります。

たとえばSYS.3のアーキテクチャ設計書やSWE.4のユニットコードがどれだけ丁寧に作られていても、「今この瞬間、正式版としてどれが有効なのか」を一意に指せなければ、レビューもテストもリリースも成立しません。

SUP.8は、他のプロセスが生み出す成果物に「版」という背骨を通す役割を担っています。

なぜ「変更履歴」が安全につながるのか

自動運転やADASのように、ソフトウェアが安全に直結する領域では、次のような場面で構成管理の質がそのまま問われます。

Field Impact
・フィールドで不具合が発生したとき：対象車両に搭載されていた正確なソフトウェア構成を再現できなければ、原因調査そのものが始められません。
・変更が及ぼす影響を追うとき：ある修正がどの要件・どのテストに関係するかをたどれなければ、修正漏れや再発防止の抜けが生まれます。
・アセスメントや監査のとき：「なぜこの版を採用したのか」「誰が承認したのか」を後から説明できることが、プロセスの信頼性の証明になります。

つまり構成管理は書類仕事ではなく、「何かが起きたときに、正確に説明できる状態を先回りして作っておく」ための保険のようなものです。

具体例で考えてみます。ある機能でセンサーの誤検知が報告されたとします。構成管理が機能していれば、「その車両に搭載されていたソフトウェアのベースライン」→「そのベースラインを構成する各構成品目の版」→「各版がいつ・どの変更によって生まれたか」という順に、数分でたどり着けます。

逆にこれが整備されていないと、まず「当時のソースコードはどれだったか」を探すところから始まり、原因調査そのものに何日も費やすことになりかねません。

基本となる3つの用語

構成品目（CI）

バージョン管理の対象として扱う成果物の単位。何を1つの単位として管理するかを最初に決める必要があります。

ベースライン

ある時点での構成品目一式を「これが正式な版」として固定したもの。以降の変更はこの差分として扱われます。

トレーサビリティ

変更理由・変更内容・影響範囲を、要件からコード、テスト結果までたどれる状態のこと。

SUP.9・SUP.10との違い（混同しやすいポイント）

構成管理は「問題管理」や「変更管理」としばしば混同されますが、担っている役割はそれぞれ別物です。3つのプロセスは次のように役割分担しています。

SUP.8
構成管理
成果物の「版」そのものを管理する。何が正式版で、それはどう構成されているかを保証する土台。

SUP.9
問題解決管理
発生した不具合や問題をどう報告・分析・解決したかを管理する。「何が起きたか」の記録が主役。

SUP.10
変更依頼管理
「こう変えてほしい」という依頼をどう受け付け、承認し、実施状況を追うかを管理する。

実務上の流れとしては、SUP.9で問題が報告される、あるいはSUP.10で変更が依頼される→影響分析のうえ承認される→実際の修正がSUP.8の管理下で新しい版・新しいベースラインとして記録される、という順序になります。

SUP.8だけを整えても「なぜ変更したか」の経緯は残りませんし、SUP.9・SUP.10だけを整えても「結果としてどの版に反映されたか」が追えません。3つがそろって初めて、変更の一連の流れが説明可能になります。

SUP.8が求めている取り組みの全体像

ASPICEのSUP.8では、おおまかに次のような取り組みが期待されています（標準の文言そのままではなく、実務的に言い換えたものです）。

1. 構成管理の進め方を決める：何を、どのタイミングで、どのツールで管理するかの方針を先に固める。プロジェクトの規模やASILレベルによって、求められる厳格さも変わってきます。
2. 構成品目を識別する：管理対象とその粒度（ファイル単位か、機能単位かなど）を明確にする。粒度が粗すぎると差分が追いにくく、細かすぎると管理コストが跳ね上がります。
3. 構成管理の仕組みを用意する：バージョン管理システムやリポジトリ構造など、実際に運用する基盤を整える。
4. ブランチ運用を決める：並行開発やリリース対応をどう枝分かれさせ、どう統合するかのルールを持つ。派生開発が多い自動車ソフトでは特に重要な取り組みです。
5. 変更とリリースを制御する：変更が無秩序に取り込まれないよう、承認や記録のプロセスを通す。
6. 状態を記録する：各構成品目が今どの版・どの状態（レビュー中・承認済みなど）にあるかを常に把握できるようにする。
7. 保管・バックアップを行う：過去の版を失わず、必要なときに復元できるようにする。
8. リリースを管理する：どの版を、いつ、どこに（どの車種・どのECUに）提供したかを記録し追跡できるようにする。

現場でつまずきやすいポイント

よくある落とし穴
・命名規則やバージョン番号の付け方が人によってバラバラで、後から追えなくなる。
・ベースラインを「いつ」取得するかのタイミングが曖昧で、レビューの基準がぶれる。
・変更履歴に「何を直したか」は書いてあっても「なぜ直したか」が残っていない。
・Gitなどのツールは導入されていても、運用ルール（ブランチ戦略・マージ条件・タグ付け基準）が現場任せになっている。
・レビュー中や承認待ちの間にベースラインの中身が更新されてしまい、「レビューした版」と「実際にリリースされた版」がずれる。
・サプライヤから納品される成果物の構成管理ルールが自社と揃っておらず、統合した瞬間にトレーサビリティが途切れる。

まとめ

SUP.8構成管理の本質は、ツールを入れることではなく「あとから正確に説明できる状態」を作ることにあります。何を構成品目とし、いつベースラインを切り、変更をどう記録し、誰が承認したかという一連の仕組みが揃って初めて、フィールドで何かが起きたときに胸を張って説明できます。特に自動運転・ADASのようにフィールドでの説明責任が重い領域では、変更履歴の整備が単なるプロセス要求ではなく、実際の安全性・信頼性の土台になります。次回は、ベースラインの具体的な取り方と、SUP.9・SUP.10との実務上の連携パターンについて、もう一段掘り下げて解説します。