ISO 26262対応の勘所-国内の車載TIERが抱える潜在課題

前回に引き続きゲストスピーカー森川様をお迎えして自動車向け機能安全規格であるISO 26262対応、ASIL認証取得の潜在課題について分かり易く解説していきます。

ヴィッツ社 機能安全担当 取締役 森川聡久様

ヴィッツ社
取締役 機能安全スペシャリスト
森川 聡久 様

IARシステムズ ストラテジックセールス 兼 機能安全担当 山田優

IARシステムズ
テクニカルマーケティング マネージャー

大山 将城

ドイツの機能安全規格の作成担当者に「規格書を読むな」と言われた

大山

前回に引き続きISO 26262対応の請負人であるヴィッツ社 森川取締役をお迎えしています。前回は、新たな規格やスタンダードがでてくると新たな要求事項や新技術への対応が必要だと捉えがちだが、実際にはそうではないという話で終わりました。もう少し掘り下げて頂けますか?

森川

はい。こういった背景を熟知しているドイツの機能安全規格の作成担当者や認証機関らと深い議論を重ねたことがあります。彼らは、以下のようなことを言っていました。

  • PL訴訟対策のために作った、安全性の説明を容易にするためのツールであり
  • 機能安全規格に適合することでコスト削減が可能であり
  • 機能安全規格に愚直に対応してはならない

またショッキングなことに、「規格書を読むな!!!」ということも言われたことがあります。

大山

それは非常に興味深いですね。「規格書を読むな」という意図は、「本来は賠償責任の免責及びコスト削減が主旨の規格なのに、真面目な日本企業が規格書を読み込むとコストアップにつながる方向性に舵を切りがち」という意味でしょうか?

規格要求に振り回されると品質を下げかねない

森川

そうです。もともと日本企業は高品質の製品開発を実現してきています。これを、規格要求に振り回されて開発の仕方を大きく変えてしまうのは、コストだけアップし、かえって品質を下げることになりかねない、と懸念されていました。

大山

なるほど。弊社は車載以外にも様々なセグメントのお客様を担当していますが、この指摘は日本の製造業が抱える共通の潜在課題にもみえます。日本企業の機能安全対応方法の問題点についてはいかがでしょうか?

森川

前述の規格作成者や認証機関らの言葉は、多くの日本企業における対応方法や、取り組み姿勢と大きく異なるのではないでしょうか?

規格を作った人達の意図としては、
「意味のあることを実施する」
「ムダなことは実施しない」
なのです。

しかし、多くの日本企業の場合
「規格で要求されているから実施する」
になっていないでしょうか?

大山

確かに、もともと独自の品質管理が確立されている日本企業は、機能安全認証対応で外部に説明するというステップ自体が余計なものと捉えがちな点があるのですね。一方で、技術力が高く、プロセス/品質管理が得意な日本企業が、欧米企業ではやれているISO 26262対応を苦手とする原因はあるのでしょうか?

日本企業がISO 26262対応を苦手とする原因

森川

ISO 26262対応に際して、多くの日本企業が誤った対応を導入し、そのやり方が広く普及し、「日本基準」として浸透してしまったのかも知れません。
欧米企業のように、ツールとして上手く使いこなし、日本企業の強みを活かしたやり方をしないと、今後の国際競争力への影響が強く懸念されます。以下が弊社の経験から比較した日本企業と欧州企業の比較です。

大山

規格に対する姿勢としてはほぼ真逆ですね。課題はわかりましたが、どういう方策が効率的だと考えますか?

森川

第一に、基本的に新しい活動を極力「追加しない」ように対応することが望ましいです。従来の開発の仕方でも十分に高い品質・安全を実現できているはず、だからです。

もし、規格に書かれている要求事項“そのもの”が実施できていなかったとしても、少し立ち止まって考えてみましょう。

  • この要求事項は、何のための要求されているのでしょうか?
  • この要求事項を実施するとどんな良いことがあるのでしょうか?例えば、どんなリスクを防止/低減できるのでしょうか?
  • このリスク防止/低減は、今までの開発プロセスでは実施できていなかったことでしょうか?

このように、「従来の開発プロセスでもリスクが十分に低いよね」ということを確認しながら対応を進めるのが、本来期待された規格への適合方法です。ただ、第3者目線では、本当に規格に適合できているのか?と疑われる可能性もありますので、規格要求事項毎に上記の確認・検証した結果を記録しておくことが望ましいですね。

従来の開発プロセスの中で上手にエビデンスを残す

大山

なるほど。従来の開発プロセスを最大限活用する方向性や、外部へ説明できるエビデンスが重要だと。ただ、エビデンスを記録するのは大変そうな気もしますが・・・

森川

それが第二の方策となり、従来の開発プロセスの中で、上手く活動記録を残す工夫をすることです。日本企業の場合、必要な活動は実施していても、記録が残っていないことが多いです。例えば、レビューを実施しても、口頭で伝えるだけで、レビュー記録が残っていない、といったケースです。

日本企業は、活動記録を残すのが得意ではありません。残念ながら、すり合わせ開発の悪影響かも知れません。

一方、海外企業の場合、エンジニアの入れ替わりが激しく、今日いた人が明日いなくなることもあります。この場合、引継ぎ活動さえ十分に実施できませんので、他者がすぐに理解できるように、情報を常に記録・共有しておく必要があるのです。

日本企業にとっては、このような懸念は過剰な心配かも知れませんが、中長期目線で見ると、見習うべき活動かも知れません。例えば、数年後に流用開発したり不具合修正したりする際に、当時どのように検討して設計して評価をしたか、という記録が残っているのといないのとでは大きな違いです。当時の担当者も在籍しているかわかりませんし。

大山

弊社はグローバルで同じツールを販売しているので、地域ごとのエンジニア文化の差をよく感じます。例えば、アメリカのエンジニアはコンパイラを買う時にすべてのオプションを付けた最大金額から見積をとりますが、日本ではミニマム構成から見積をとります。これは、アメリカでは人は流動的なので、ツールでやれることはツールに任せる文化なのだととらえています。

話を戻すと、活動記録が大事なのはわかりましたが、日本文化ではやはり大変なのでしょうか?

森川

いえ、やり方は、全く難しくありません。

私は、以下を習慣化しています。

  • 実施したこと、検討したこと、判断したことなどをこまめに記録する
  • 参照情報や、判断根拠へのリンク(トレーサビリティ)をこまめに記録する

皆さんはエンジニアなので、普段からコンピュータを扱い慣れていて、タイピングも苦にならないと推測します。見た時、考えた時、判断した時に、それをタイピングして記録する習慣をつけるだけです。慣れてしまえば、コスト(工数)は殆ど増えず、メリットが大きいと、私自身実感しています。

最小限の必要事項をルールとして習慣化

大山

なるほど、最小限の必要事項をルールとして「習慣化」することがポイントですね。これを読んでいる読者様に対しても一言お願いします。

森川

現在のみなさんのISO 26262開発プロセスはいかがでしょうか?もし、実施しづらいプロセスに変わってしまっているようでしたら、改めてムダが無いか再確認されてはいかがでしょうか。

大山

ISO 26262対応のプロセスが構築された後も「常に現状が最適化か」を問い続けることが大事ということですね。

最後までお読みいただきありがとうございました。

 

ご相談(メール)

機能安全の必要なプロジェクト開発者のためのビルドツール活用法とコーディングの注意点を徹底解説!

本ウェビナーでは、機能安全認定されたIAR Embedded Workbenchを使用する際の、実用的なTips集やコーディングの注意点を徹底解説いたします。

上のダイジェスト版ビデオをご覧いただき、より詳しくお知りになりたい場合は、以下のリンクよりお客様情報をご登録の上、録画されたウェビナー(約1時間)をご覧ください。

申し訳ございませんが、弊社サイトではInternet Explorerをサポートしていません。サイトをより快適にご利用いただくために、Chrome、Edge、Firefoxなどの最新ブラウザをお使いいただきますようお願いいたします。