A-SPICE準拠の要件定義・アーキテクチャ設計、AI駆動開発時代になぜ重要性が増すのか

「ものが作れれば、まずは作ってしまう」——モデルチェンジや新製品開発のスピードが優先される開発現場では、珍しくない光景です。しかしA-SPICEやISO 26262といった国際規格は、実装の前に「なぜそう作るのか」を要件・アーキテクチャとして言語化し、後から誰でも追跡できる状態にしておくことを求めます。この記事では、開発が先行してドキュメントが後追いになってしまった現場を例に、AI駆動開発が進む今こそ価値が上がる上流工程の本質を考えます。

なぜ「開発が先行し、ドキュメントが後追いになる」現場が生まれるのか

組み込み・車載領域の開発現場では、要件定義書やアーキテクチャ設計書を整備してから実装に入るのが本来の順序です。しかし実際には、モデルチェンジや新製品の立ち上げに伴う納期優先の判断から、設計フェーズを省略していきなりソフトウェア実装から着手してしまう現場は少なくありません。「動くものができればいい」という現場の実感と、品質保証責任を負う上位管理層が求める「規格に準拠したプロセスの証跡」との間には、構造的な温度差が存在します。

この温度差が放置されたまま開発が進むと、後から上流ドキュメントを整備しようとした際に、思わぬ壁にぶつかります。すでに実装が進んでいる状態からの文書化は、通常の「要件定義→設計→実装」という順序が逆転しているため、開発側からの仕様変更が頻発する中で文書を作り続けなければならないという難所を抱えることになるからです。現場が「なぜ今さら設計書が必要なのか」と感じる背景には、この順序の逆転という技術的な難しさも影響しています。

A-SPICE・機能安全が求める「トレーサビリティ」とは何か

Automotive SPICE（A-SPICE）は、ドイツ自動車工業会（VDA）の品質マネジメントセンター（QMC）が定める、車載ソフトウェア開発のプロセスアセスメントモデルです。ISO/IEC 330xxシリーズを基盤とした国際的な枠組みで、要件定義からアーキテクチャ設計に至るシステムエンジニアリングプロセス群（SYSプロセス）を含む複数のプロセス領域が定義されています。単に「ドキュメントを作ればよい」規格ではなく、開発プロセスそのものの成熟度を評価する点に特徴があります。

この規格が重視する概念のひとつが「トレーサビリティ」です。要件から設計、そして評価項目まで、一貫して関連づけを追跡できる状態を指します。抽象的な概念に聞こえますが、実務上の意味は明確です。評価・検証を担当する第三者が、「なぜこの評価項目が必要なのか」を要件書・設計書に立ち戻って確認できるかどうか、という使い手視点の設計品質そのものを表しています。逆に言えば、トレーサビリティが取れていない文書は、規格上の体裁が整っていても、実際の評価工程では使いづらいものになってしまいます。

「要件定義ができない」のではなく、「定義しきれない」——複雑に絡み合う3つの要因

生成AIの進化に伴い、「要件定義もいずれAIに代替される」という見方を耳にすることが増えました。しかし実態はやや異なります。正確には、要件定義は「AIにできない」のではなく、顧客自身の言葉にならない意図、業界特有のドメイン知識、積み重ねてきた要望や制約が複雑に絡み合っているため、本当の意味では定義しきれないという表現の方が実態に近いといえます。

定義しきれない3つの要因

この「定義しきれなさ」は、大きく3つの要因に分解できます。第一に、顧客自身がまだ言語化できていない意図や要望です。ヒアリングの場で初めて輪郭が見えてくることも珍しくありません。第二に、業界・製品特有のドメイン知識です。過去のトラブル事例、規制動向、商慣習といった、文書として残りにくい前提知識が設計判断に影響します。第三に、顧客との関係性の中で長年積み重ねられてきた暗黙の制約です。これらはいずれも、対話や経験を通じてしか引き出せない性質のものであり、言語化・構造化された情報の処理を得意とするAIが苦手とする領域でもあります。

特に第二のドメイン知識は、組み込み・車載領域では影響が大きい要素です。ECU間の構成や連携方式を理解した上で「この要件だと、後工程でこの検討が漏れやすい」と先読みできるかどうかは、その領域での実務経験の蓄積に左右されます。STELAQでは自動車・組み込み開発領域の経験が豊富なエンジニアが数十名在籍しており、プロパー社員の方々と設計レベルの議論ができる体制を整えています。車載開発の経験を土台に、現場の機能別担当者から言葉少なに語られる情報の中から、検討漏れや矛盾を拾い上げていく——これが、単なるヒアリングと要件定義支援を分ける違いです。

口頭の情報を体系化するプロセス——現場ヒアリングから段階的合意まで

上流ドキュメントが存在しない現場では、インプットとなる文書自体が用意できません。この場合、現場の機能別担当者への個別ヒアリングを重ね、口頭で語られる情報を体系的にドキュメント化していくアプローチが有効です。ただし、単に聞いた内容をそのまま書き起こすだけでは、要件同士の矛盾や抜け漏れを見逃してしまいます。設計レベルの知見を持った上で聞くからこそ、「この要件とあの制約は両立しない」といった検討漏れを、ヒアリングの場で指摘・提案できるようになります。

もう一つ重要なのが、完成度の追求の仕方です。最初から100点の完成形を目指すのではなく、「まずここまでを合意する」という段階的な合意形成を重ねていく進め方は、完璧主義による停滞を避けながら文書の精度を高めていく現実的な方法です。加えて、開発が先行している環境では仕様変更が頻発することを前提に、機能変更が生じても影響範囲を局所化できる記載方式を採用することで、変更のたびに文書全体を作り直す事態を防ぐことができます。

規格対応を「負担」ではなく「資産」にする視点

A-SPICEやISO 26262への対応は、認証取得やレビュー通過のためだけの作業と捉えられがちです。しかし、要件・設計情報を体系的に整備するという行為自体は、規格対応にとどまらない価値を持ちます。AI駆動開発が進むほど、AIへの指示や生成物の検証には、精度の高い要件・設計情報が前提として必要になるためです。上流ドキュメントの整備は、規格対応の証跡であると同時に、今後の開発を支える資産としても機能します。

とはいえ、社内に車載・組み込み開発の経験を持つ人材が十分でない場合、この整備を自力で進めるのは容易ではありません。外部の第三者視点と、ドメイン知識を持つ人材が伴走することで、現場の口頭情報を要件・設計文書へと落とし込みながら、規格対応と実開発の両立を進めることができます。

よくある質問

まとめ

• 開発が先行しドキュメントが後追いになる現場でも、変更を吸収できる文書設計とヒアリング設計によってA-SPICE準拠のトレーサビリティは確保できる
• 要件定義は「AIにできない」のではなく、顧客の意図・ドメイン知識・積み重ねた要望が複雑に絡むため本当の意味では定義しきれない領域であり、そこにこそ経験を持つ人材の価値がある
• 口頭の情報を体系化し、段階的合意で完璧主義の停滞を避けるアプローチが、規格対応を現実的に前進させる

出典：Automotive SPICE® / VDA QMC（ドイツ自動車工業会 品質マネジメントセンター）公式サイト https://vda-qmc.de/en/automotive-spice/