マツダ山﨑氏が語るサプライチェーン全体でのセキュリティ活動（後編）

重要論点：サプライヤーによる設計段階でのセキュリティ対策

奥山：
CASE（Connected、Autonomous、Shared、Electric）の考え方が出てくる前と後では、セキュリティの体制や考え方などにどう変化が起きましたか。

山﨑：
ライフサイクルやサプライチェーンを考えると、私たちの内部の話、外部の話があります。

品質の作り込みという点では、私たちOEM側が最終責任を持ちます。お客さまの使い方がイレギュラーであったとしても、できる限り安全に扱えるよう説明してきました。自動車の中では、開発の前提条件を基に要件を分析し、何が必要かをベースに設計してきています。それに関しては、セキュリティが入ってきたとしても全く変わらない部分でしょう。

奥山：
従来の安全の取り組みに、セキュリティの取り組みが追加されるのですね。

山﨑：
安全に向けた取り組みは、機能安全と実用安全に分けられます。機能安全とは最低限、自動車メーカーとしてここまでは絶対に行う必要がある部分です。実用安全には各社の考え方が出ます。企業の歴史として、これまで表面化した不具合のフィードバックを積み重ねたものでもあるでしょう。その判定基準こそが、性能や競争力の源泉になります。そこに、セキュリティ要素を開発側として組み込もうとしているわけです。

林：
もう一方の外部の話についても聞かせください。

山﨑：
外部の話で重要なのは、部品を提供してもらうサプライヤーの観点です。まさに、安全とセキュリティの要素が変わってくる部分です。これまではスペックを満たしてもらうのが、私たちがサプライヤーに求める事柄でした。大げさに言えば、機能に影響がなければ、バグがあってもある意味「良し」とされていた時代とも言えます。

しかし、これからは、セキュリティの要件に関しては、私たちが規定するだけでなく、サプライヤーが主体となって、世の中にある脆弱性情報やインシデントの発生情報を含め、しっかりとした設計をしてもらうことを求めていきます。現時点で分かっていることは、対処した上で納品してほしいのです。また、これらの活動をTier1と呼ばれる一次サプライヤーだけでなく、Tier2、3……nまで全てのエリアで実施してもらい、サプライチェーン全体でセキュリティ対策を進める必要があります。

自動車として販売した後は、研究機関などの外部組織、例えばPwC Japanグループのようなところがしっかりと脆弱性を発見してくれると考えています。そういうところから、いち早く情報を入手し、迅速に対処することが求められています。そこが従来の品質と異なる部分です。

マルチなエンジニアを育てる難しさ―人材育成は大きな課題

奥山：
次は「人」のお話を聞きたいと思います。今後、山﨑さんも次の世代を育成しなくてはならないと思うのですが、その点はいかがでしょうか。

山﨑：
大きな課題です。私たちの固有技術やOEMとしての知識を知っている必要は当然ありますし、セキュリティにも取り組まなくてはなりません。サプライヤーをはじめ、外の世界も知る必要があるでしょう。それらをバランスよく知る人を育てるのは非常に難しいことです。マルチなエンジニアを育てる難しさには、どの自動車メーカーも直面しています。

例えばセキュリティを学んでもらうために、情報系の大学に通わせたとしても、セキュリティのエンジニアから自動車のエンジニアとして活躍できるようにするためにはもう1段階学んでもらう必要があるわけです。技術は学べても、それを応用して実際に自動車の開発や製造のプロセスに生かすには、かなり難しいステップを経る必要があります。

林：
そうなると、やはり内部での育成が重要ということでしょうか。

山﨑：
OJT型の育成が圧倒的に優位です。基本技術は自動車エンジニアとして、5年なら5年というある程度の期間をかけて学んだ後で、さらに深めていくのか、もしくはプラスアルファとしてセキュリティを学んでマルチなエンジニアになるか、ということになるでしょう。

一方、外部から採用する場合、例えばソフトウェア領域でコード解析して脆弱性を発見できる人材など、私たちがもともと持っていない技術領域における専門性を求めています。そういった分野では常に最新技術を学ぶ必要があるため、社内に抱えてしまうとその技術が陳腐化した際にリスクが発生します。その意味で、社内で育成するのは難しいと言えます。