機能安全は技術者であれば必ず具備すべき普通の技術である：MONOistオートモーティブセミナーリポート（1/2 ページ）

MONOistオートモーティブフォーラム主催のセミナー「もう待っていられない！ISO26262対応をいかに進めるべきか」の基調講演に、日本自動車研究所（JARI）でITS研究部次長を務める小谷田一詞氏が登壇した。本稿では小谷田氏の講演を中心に、同セミナーのリポートをお送りする。

[馬本隆綱，MONOist]

　2014年6月17日、東京都内で、MONOistオートモーティブフォーラムが主催する、自動車向け機能安全規格ISO 26262をテーマにしたセミナー「もう待っていられない！ ISO26262対応をいかに進めるべきか」が開かれた。

　本稿では、日本自動車研究所（JARI）でITS研究部次長を務める小谷田一詞氏による基調講演を中心に、同セミナーをリポートする。

全社上げて安全文化を構築すべし

　小谷田氏の講演タイトルは、「機能安全は、技術者として当然持つべき『コアコンピタンス』である」。同氏は講演の中で、機能安全の本質や開発現場での機能安全活動に対する考え方、取り組み方などを示した。

JARIの小谷田一詞氏

　小谷田氏と言えば、2012年のMONOistオートモーティブフォーラム主催のISO 26262セミナーでも基調講演を務めている。その際には、JARIに転籍する以前の大手電機メーカーでの経験などを中心にした講演を行っている（関連記事：プロセス改善あっての機能安全、ISO 26262はツールにすぎないことを理解すべし）。

　今回の講演で小谷田氏は、冒頭で前回のセミナーから2年間の活動を振り返りながら、「ISO 26262は品質を向上させるためのプロセス改善活動であり、あくまでも車両が安全であることの説明責任を果たす道具でしかない。日本人の性格かもしれないが、ISO 26262に準拠することが機能安全活動だと思い込んでいる人が依然として多い」と述べた。

　また、「機能安全活動で成果を上げるには安全文化が重要だ」と指摘し、経営トップ以下、全社員でプロセス改善活動に取り組む土壌づくりが大切であると強調した。それには、開発現場における活動を尊重することが重要であり、個人のスキルレベルを向上することが、会社全体のスキルアップにもつながるという。JARIは、企業の安全文化を構築するための第1ステップとして、「入門コース」から「技術者コース」、「アセッサコース」といったレベルに応じた教育プログラムを用意している。中でも、「安全文化構築にはトップダウンでの取り組みが不可欠である。そういった意味で経営者・管理者向け教育が重要だ」（同氏）という。

　もう1つ、小谷田氏が指摘したのが、組み込みシステム分野におけるクオリティマネジメントシステム（QM）の考え方である。例えば、組み込みシステムでは開発を担当する工程が細分化されすぎて、システム全体を俯瞰（ふかん）して見ることができる技術者がほとんどいないというのが現状だ。車両レベルでの機能安全が求められている中で、「顧客の目線で安心を与えられているのか」（小谷田氏）という疑問を投げ掛けた。

　ISO 26262は、車載電子システムで起こりうるさまざまな障害を想定し、それを避けるために達成すべき安全度レベルを、ASIL（Automotive Safety Integrity Level）として4段階（A〜D）で表現している。そして、主にランダム故障となるハードウェア故障だけでなく、ソフトウェアのバグによるシステマチック故障も含めた残存リスクについて、「設計」や「教育」、「開発プロセス」といった安全機構を用いて、「社会的に許容されるリスク領域」まで下げることが機能安全活動の目的である。

　つまり、故障率を改善するなど定量的なアプローチで信頼性を向上しつつ、それでも回避できないリスクに対して定性的な安全性を担保し、顧客満足度を高めることが機能安全の本質なのだ。小谷田氏は、「機能安全活動は、こういったQMをベースとしたものでないと砂上の楼閣となる」と話す。

リスクを回避するために、定められた車両の安全度レベルを達成することで、社会的に許容されるリスク領域まで下げていく（左）。そして機能安全活動はQM活動がベースとなる （クリックで拡大） 出典：JARI

　小谷田氏は、組み込みシステム分野の開発現場における課題にも触れた。「組み込みシステムの開発では派生品開発が多く、それが安全文化を推進するための弊害となっている」（同氏）というのである。例えば、開発現場の状況として、押し付けのテンプレート開発が多く、過去のドキュメントが保存されていない。工程管理が十分ではなく、設計書には更新履歴が記載されていないことも多い。最終設計に至った経緯、設計コンセプトなどの説明がないケースもある。

　また、まずソースコードを記述してから、とりあえずブレッドボード上でその動作を確認したいというソフトウェア技術者の習性が問題になることについても指摘した。こういった開発手法では、機能安全に関する討論を十分に行うことはできない。この他、割り込み処理を行ったときこそシステムエラーが発生する確率は高いので、ソフトウェア開発時であってもタイミングチャートの作成が必要になる、といった点を挙げる。「このような現状で、機能安全が求めているプロダクトの安全は担保することができるのか」と警鐘を鳴らす。

ISO 26262対応に悩む技術者への提言

　小谷田氏はこうした現状を踏まえて、ISO 26262対応に悩む技術者に幾つか提言を行った。

• 技術者は自ら活動した成果物に対して、その設計コンセプトや開発プロセスを説明する責任がある
• 市場で顕在化したバグは開発者自身のスキルを超えたものである。だからこそ、自らの非を認めるとともに、新たにチャレンジするためのチャンスと考えるべき
• 自分の担当部分だけ満足できる成果を出すのではなく、システム全体を俯瞰する商品目線が必要
• 設計する場合に、正常に動作するように開発するのは当然で、全体の80％は異常が発生した時の処理について考えることが必要

　そして、「ISO 26262は、安全を確保していることの説明責任を果たす道具であり、機能安全は技術者であれば必ず具備すべき普通の技術」（同氏）と結論付けた。