Automotive SPICEは守っているのに、なぜ機能しないのか　― WhatとHowの混同から読み解く設計思想 ―

Automotive SPICE（A-SPICE）は、車載ソフトウェア開発におけるプロセス能力を評価するためのアセスメントモデルです。

当社では先日、
「ソフトウェア開発組織をどう評価するか ～エンジニアリングチーム全体を評価し、組織改善につなげるために～」
というコラムの中で、SPICEを含む複数の枠組みを用いながら、開発組織をどのように評価し、改善につなげていくかを整理しました。

また、これまでのコラムでも、

「ドキュメントが作られているが活用されていない」

「プロセスが形骸化している」

といった課題が現場で起きやすいことを指摘してきました。

 

しかし、それらは“現象”としては共有されているものの、なぜ起きるのか、どうすれば防げるのかまでは十分に整理されていないケースも少なくありません。

本コラムでは、これらの前提を踏まえたうえで、A-SPICEを「評価モデル」として説明するのではなく、

「なぜその評価項目が定義されているのか」という観点から読み直します。

言い換えると、A-SPICEを「評価のための枠組み」としてではなく、「開発で問題が起きやすいポイントを示した設計思想」として捉え直す試みです。

現場でよく聞かれる、

「やるべきことはやっているはずなのに、なぜかうまくいかない」

という違和感を、この観点から整理していきます。

 

A-SPICEは「What」を定義するモデルである

A-SPICEはアセスメントモデルであり、「何ができているべきか（What）」を定義しています。

例えば、

• 要求が適切に管理されていること
• レビューが実施されていること
• トレーサビリティが確保されていること

といった状態が評価対象になります。

一方で、A-SPICEは「それをどのように実現するか（How）」までは規定していません。

 

問題の本質：WhatをそのままHowにしてしまう

現場でよく起きるのが、このWhatをそのままHowとして標準プロセスに落とし込んでしまうケースです。

例えば、

「レビューを実施する」という評価項目に対して、
「レビューを実施する」という手順だけが定義される。

一見すると問題はなさそうですが、ここには重要な抜けがあります。

 

具体例：レビューが“機能しない”ときに起きていること

あるプロジェクトで、レビューは確実に実施されていました。
チェックリストもあり、記録も残っています。

しかし、後工程で仕様の解釈違いによる不具合が繰り返し発生していました。

レビュー記録を見てみると、指摘の多くは

• 表記ゆれ
• 記述の抜け
• 軽微な整合性

といったものでした。

一方で、

• 前提条件の認識が揃っているか
• 想定しているユースケースが一致しているか
• 例外時の振る舞いが明確か

といった観点は、レビューの中でほとんど扱われていませんでした。

つまり、レビューは「実施されている」が、認識のずれを検出する仕組みとしては機能していなかったのです。

これは、「レビューを実施する」というWhatに対して、「何を確認するのか」というHowが設計されていなかったことに起因します。

 

なぜ“認識のずれ”は起きるのか

では、なぜこのようなことが起きるのでしょうか。

その背景には、人の認知の特性があります。

本コラムで扱っている問題は、操作ミスのような単純な誤りではなく、
仕様や前提の解釈違い、思い込み、見落としといった“認識のずれ”によって生じるものです。

人は、書かれていない前提を無意識に補完して読みます。

そのため、同じ文章を読んでも、前提や経験によって解釈がずれることがあります。

本来、レビューやトレーサビリティといった活動は、こうした認識のずれを早期に検知し、修正するための仕組みです。

しかし、その意図が共有されないまま形式だけが定義されると、「なぜやるのか」が抜け落ち、本来検出すべき認識のずれを見逃してしまいます。

 

なぜ再現性が生まれないのか

このWhatとHowの対応が曖昧なままでは、プロセスの再現性を確保することも難しくなります。

同じ「レビューを実施する」という定義であっても、何を確認するのか、どのような観点で見るのかが人やプロジェクトごとに異なれば、結果は大きくばらつきます。

つまり、

「プロセスが定義されている」だけでは不十分で、
「同じ結果を再現できる状態になっているか」が重要です。

WhatとHowが適切に接続されていない状態では、プロセスは存在していても、安定した成果にはつながりません。

 

A-SPICEを「地図」として読む

A-SPICEの評価項目は、単なるチェック項目ではありません。
開発の中で問題が起きやすいポイントに対応して整理されています。

• 要求
• レビュー
• トレーサビリティ

これらはいずれも、認識のずれや思い込みが入り込みやすい地点です。

その意味でA-SPICEは、アセスメントモデルであると同時に、「問題が起きやすい場所に印をつけた地図」として捉えることもできます。

このように読むことで、

「レビューを実施する」ではなく

「どの前提が食い違いやすいのか」

「トレーサビリティを確立する」ではなく

「どの因果関係が切れやすいのか」

といった問いに変わり、具体的な改善につながります。

 

問題が起きやすい地点から手当てする

地図があるなら、すべてを同じ力でなぞる必要はありません。

重要なのは、自分たちの現場で問題が起きやすい地点を見極め、そこから手当てすることです。

例えば、

• レビューの観点をあらかじめ定める（例：前提条件が明確か、ユースケースが具体化されているか、例外時の振る舞いが定義されているか）
• 要求を構文化し（例：EARSなどを活用する）、条件や例外を明示する
• 変更時に設計・テストまで影響を追う範囲を明確にする

といった工夫は、認識のずれが入り込みやすいポイントに直接効きます。

大きな仕組みを一気に導入する必要はありません。

問題の芽を先に潰すことが重要です。

 

まとめ

A-SPICEはアセスメントモデルであり、「何ができているべきか（What）」を定義しています。

一方で、それをどのように実現するか（How）は各組織に委ねられています。

評価項目をそのまま作業として定義するだけでは、活動は形式化しやすく、プロセスの再現性にもつながりにくくなります。

重要なのは、「なぜその項目が求められているのか」を理解し、自分たちの現場に合わせてHowを設計することです。

どの工程で認識のずれや思い込みが入り込みやすいのか、という観点でA-SPICEを読み直すことで、
問題が起きやすいポイントを把握し、改善の優先順位を見極めることができます。

もし、

• レビューが機能していないと感じる
• 要求の解釈が揺れてしまう
• 変更の影響が追いきれていない

といった課題がある場合、それはプロセスが不足しているのではなく、WhatとHowのつながりが十分に設計されていない状態かもしれません。

当社では、A-SPICEの評価項目をそのまま適用するのではなく、
現場の実情に合わせて「どのように実現するか（How）」を整理し、運用できる形に落とし込む支援を行っています。

どこから手を付けるべきかお悩みの際は、ぜひご相談ください。

（安部　宏典）