安全を売りにするな！安全を食いものにするな！

最近、どうしてもペンを取りたいと思わせることが二つ起こった。ひとつは、マツダの安全装備の体感試乗会で起きた「CX-5」の事故で、もうひとつは2007年に起こったトヨタの急加速事故に関するトンデモ検証記事だ。

マツダの安全装備の体感試乗会で起きた「CX-5」の事故

【Car Watch NEWS より】

　マツダは11月12日、埼玉県内でマツダオートザム店を展開する坂田自動車工業が開催した安全装備の体感試乗会で、11月10日に発生した人身事故についての第一報を発表した。 

　埼玉県深谷市の坂田自動車工業 駐車場内で発生した今回の事故では、「CX-5」に装備されている「スマート・シティ・ブレーキ・アシスト（SCBS）」の機能を体感するイベントのなかで参加者が運転する車両がフェンスに衝突。車内にいた参加者と販売店従業員の2人が負傷し、参加者が頚椎捻挫（軽傷）、販売店従業員が右腕骨折（重傷）となっている。 

　SCBSは近赤外線レーザーで前方の車両を検知し、ドライバーの操作に応じてブレーキをサポートするシステム。障害物の大きさや種類、周辺環境、車速、ドライバーの運転操作によって正常に作動しない場合があるとしており、マツダではSCBSの体感試乗会を開催するにあたって、上記の項目を考慮し、一定の条件を設定してその条件下で実施するよう全国の販売店に案内している。 

　今回の坂田自動車工業による体感試乗会がマツダの案内する条件に沿って実施されたか否かを確認中で、事故に至った原因や状況などについても含めて警察による調査で明らかになると考えているとのこと。一刻も早い原因究明と再発防止に向け、坂田自動車工業とともに警察の調査に全面的に協力するとしている。なお、SCBSに起因する公道での事故発生についてはこれまで報告がないとの発表だ。 

　また、今回の事故原因が判明して対応が決まるまで、安全装備の体感試乗会は自粛するとしている。

【参照終わり】

なお、この出来事に関するマツダの第一報はこちら。(PDF）

最近はやりの自動ブレーキには種類がある。

• 赤外線式
• ミリ波レーダー式
• カメラ式

マツダ　CX-5 に搭載されていたのは赤外線式で、時速　30km以上では作動しない仕様の模様。赤外線式の自動ブレーキはコストが安く、軽自動車に搭載されているのも赤外線式のようだ。最近盛んに自動ブレーキを搭載を強調したCMが流れている。

CX-5 の試乗会で起こった事故の原因は調査中ということだが、自分は単純に 時速 30km 以上で障害物に突っ込んでしまったのだろうと思っている。時速 30km 以上では効かないということを一瞬忘れたディーラーの販売員と血気盛んな運転手がおそるおそるではなくガーンとマットにぶち当たりにいったシーンが目に浮かぶ。

さて、下記のようにどのメーカのCMでも安全機能を売りにさんざん宣伝した後、注意表記が読むまもなく一瞬取って付けたように言い訳がましく一瞬表示され消える。

でも、どのCMもそれぞれの会社のWEBサイトで動画で見られるようになっているので、その部分だけボーズして画面キャプチャすればこのようにじっくり読むことができる。

仮に今回の事故が時速 30km 以上で走っていてブレーキを踏まずに障害物に突っ込んでいって自動ブレーキが効かなかったのなら、それは「i-ACTIVSENSE に搭載されているセンサーは、反射しにくい対象物、天候状況、速度状況、道路状況などの条件によって適切に作動しない場合がありますので、あらゆる状況での事故を回避するものではございません。これらの安全技術だけに頼った運転は行わず、安全運転を心掛けてください。」の注意書きの速度状況によって適切に動作しない場合に当たるのだと思う。

ただ、上記の注意書きの書きぶりだと、速度の条件はセンサーの性能限界のように読み取れるが、自分はそうではなくて明確に時速 30km 以上では自動ブレーキを動作させない制御をしていたのではないかと考える。

もしそうなら、時速29kmでは自動ブレーキは作動し、時速31km なら作動しない。このような Crisp な1か0かの設定が、人間のアナログ的な感覚に合わないということはよくある。

何はともあれ、ここで声を大にしていいたいのは、自動車業界は安全を売りにするなということだ。（【ISO 26262との向き合い方 (16) 安全を売りにすることの意味】参照）

なぜか。それは安全には絶対的な安全というものはなく、相対的な概念だからである。だから、安全機能に絶対大丈夫はない。だから、安全機能の提供者は上記のような Excuse（言い訳）を示す。でも言い訳を書くことでは、残留リスクは許容されないのだ。

※マツダのプリクラッシュセーフティ技術の解説（これによると、プリクラッシュセーフティには3種類あって、低速で作動するスマートシティブレーキサポートとAT誤発進制御とスマートブレーキサポートで、CX-5 には中・高速で動作するミリ波レーダー式のスマートブレーキサポートは搭載されていない。そんなのユーザーはわかんないよ。）

セーフティ（安全）の定義

セーフティ（安全）とは，〔ISO/IEC GUIDE 51:1999〕※1　によれば，『受容できないリスクがないこと』と定義される。すなわち，セーフティ（安全）は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。 

安全はリスクを経由して定義され，リスクはその時代，社会の情勢，環境によっても変化するため安全の尺度を一定にすることはできず，絶対的な安全を定義することはできない。そのため，製品，プロセスまたはサービスは相対的に安全であるとしか言えない。 

安全は，リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは，使用者の利便性，目的適合性，費用対効果，並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって，許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み，製品，プロセスまたはサービスの使用と両立して，最小リスクを達成できるような改善が経済的に実現可能になったときは，特に見直しが必要である。 

※1 ISO/IEC Guide 51 は，規格に安全に関する規定を導入する際に参照され，機械，電気，医療，科学など幅広い分野で作成される安全規格に適用されるガイドラインである。

しかし、自動車の販売サイドは安全機能を前面に出すと他社と差別化できると考えるため、安全機能をことさら強調する。これにより、ユーザーは安全は相対的なものではなく、絶対的なものと勘違いしてしまう。※1

※1 小泉元首相が11月12日に日本記者クラブで原発ゼロの記者会見をする前、「自分は首相時代にさんざん原発は安全だと聞かされ信じていたがだまされていた」と言ったそうだ。

安全機能を過信する、または過信させることでこのような事故が起こることは予想していた。（このサイトの右上側のISO 26262 との向き合い方 の特集記事を読んで見て欲しい。）この事故は試乗会だからまだよかったが、実際の道路走行中に自動ブレーキが効かずに事故が起こったら、メーカー側はどのように対処するのか心構えができているのだろうか。

裁判では運転手の過失かどうかが問われると思うが、運転手に過失があっても事故にならないという安全機能を自動車メーカーと販売会社はCMで宣伝しているのだ。一瞬表示する言い訳は利用者との契約とは見なされないから、本当の事故が起これば自動車メーカーが安全機能をことさらアピールしているCMも不利な証拠として採用されると思っている。

最近、自動ブレーキを売りにしている自動車会社は、安全機能を売りにすることの恐ろしさが分かっていない。安全には絶対はないのだから、安全を過信するのようなイメージをユーザに植え付けることは絶対にやってはいけないのだ。（トヨタはやっていないと思う）

それを平気でやってしまうのは、事故と正面から向き合っていないからだ。または、事故と正面から向き合う品質保証部門と、販売が増えればよいと考えキャンペーンを打つ販売部門が分かれていて、会社のトップマネジメントが販売増の方にしか目がいっていないとチェックが効かずに安全を売りにするCMが世に出て行く。

そういう会社は記者会見でユーザやマスコミに頭を下げなければいけない事件が起こったときにはじめて、安全を売りにしたことを後悔し、反省する。

販売部門が計画を達成したいばかりに、売りにつながる要素を宣伝したがる気持ちも分からないではない。

しかし、安全機能は慎ましく、黙ってしっかり実装し、その評価は自ら宣伝するのではなく、お客さんから「あれがあって助かったよ」と言ってもらうものだと思っている。それが侍エンジニアというものだ。

自動車業界も今まではそうしていたじゃないかと思う。アクティブ・セーフティとしての機能、例えばABSを前面に出して宣伝していただろうか、そんなことはなかった。当たり前品質はどういったものかを日本の企業は分かっていた。

プリクラッシュ・セーフティに関しては、誰かが最初に安全を売りにしてしまい、それを横目で見ていた者達が「乗り遅れるな」と一斉にマネをしてしまったのだ。

まじめな話、自動車業界は プリクラッシュ・セーフティ・システムに対するリスク分析を早くやり、コストとのトレードオフについて、企業横断的に議論をした方がよい。

ようするにプリクラッシュ・セーフティという安全機能に対して、コストダウンを優先した結果、センサを赤外線に絞ったことで、どんなリスクが残留するのかを分析し、どういった場合にそのリスクは許容できて、どういったときの許容できないのかを検討するのだ。（議論する内容はコストダウンの要素だけでなく、さまざまな新しく経験したことのない Hazardous Situation があるだろう）

医療機器業界で長年リスク分析を行ってきた者としてアドバイスすると、コストダウンによって性能が低下した場合のリスクコントロール手段は、多くの場合表記上の対策となる。

表記上の対策とは機器のオペレータに対して注意表記をすることで、残留リスクが具現化するのを防ぐ対策の一つだ。機器へのラベリングや画面表示、取扱説明書での注意表記がそれに相当する。

ところが、自動車は取扱説明書は見ないでも使えることが通例になってしまっている。この場合、自動車を使い始めるときに契約書でガチガチの縛りをかけない限り、使用者が当たり前だと考えていること、当たり前だと認識されてもしかたがないことに関しては、自動車メーカーが保証をしなければいけなくなる。

自分は自動ブレーキが時速 30km 以下でないと作動しないという情報をどこかで見ていたような気がするが、あれだけ毎日、自動ブレーキの効果をCMで見せられるとすっかりそのことは忘れて、どんなにスピードを出していても作動するというイメージに自然とすり替わっていた。

そういったイメージを植え付けておいて、自動車を売り渡すときにユーザーに契約書、誓約書も交わしていないのだとしたら、事故が起こったときのことを考えずに突っ走っているとか考えられない。

リスク分析・設計の考え方や方法論についてはこちらを参考にして欲しい。

もういちど言う「安全は売りにするな！」「安全機能は慎ましく、黙ってしっかり実装し、効果はお客さんから評価してもらえ！」

2007年に起こったトヨタの急加速事故に関するトンデモ検証記事

次はトンデモ記事の話題。

何はともあれ、まずは、EE Times Japan の『トヨタの急加速事故は欠陥だらけのファームウェアが原因？――原告側調査の詳細』の記事を読んでみて欲しい。

自分はひさびさに安全を食いものにしているひどい記事を見た。もとの情報提供者の Barr GroupのCTO Michael Barr 氏は、とんでもないひどいヤツだ。開発者やコンサルタントとしての優れた実績を誇る他、大学教授や編集者、ブロガー、著者として活躍した経歴も持つらしいが、この記事はひどいし、安全の実現にこんな経歴は関係ないんだなと思った。そう考える理由はこれだ。

• 安全を楯に正義面しているが安全を保証したことなどない単なる評論家だ。
• 安全が絶対的な概念ではなく相対的な概念であることを理解していない。
• ソフトウェア品質とシステムの安全をごっちゃにしている。

21世紀になっても Fault Avoidance のみを求める愚かさ。

高い性能が要求され、特に安全性が最重要視される場合、設計やコーディング、試験に関する評価・基準は最も重要な課題となる。欠陥が生じることは決して許されず、確実な安全性が求められる。

この記事の冒頭にこう書いてある。一見正しいように見えるが間違っている。ソフトウェアが起因の欠陥は 決定論的故障 (Systematic Failure) と呼ばれる。特にシステムをリリースした後に発見するのは難しいが、一度発見されると100%再現できることが多く、ソフトウェアの改変によってまったく出なくなるという ハードウェアの部品故障とはまったく異なる性質を持つ。

このような Systematic Failure を数百万行クラスのソフトウェアシステムでゼロにすることなど不可能であることは、現場のソフトウェアエンジニアならみな分かっているし、ハードウェアエンジニアでも組織の上位層でもゼロにしたいがなかなかそうできないことが分かっている。

「欠陥が生じることは許されない」という考え方は下記の図の、Fault Avoidance すなわち、個々の構成要素の信頼性を高めることで安全性を確保しようとする設計思想であり、Specific Optimaization すなわち個別最適の発想だ。

フォールト・アボイダンス

個々の構成要素の信頼性を高めることで安全性を確保しようとする設計（構成要素の故障やバグを認めない）

フェール・セーフ

個々の構成要素に故障やバグがあっても必ず安全側に落ち着くようにする設計（信頼性よりも安全性を優先する）

フォールト・トレランス

個々の構成要素の故障やバグがあっても別の手段（冗長性や多重化など）によって機能を維持しようとする設計（構成要素の故障やバグを前提とする）

エラー・プルーフ（フール・プルーフ）

間違った操作をしようとしても危険が発生しないようにする設計。

そしてFault Avoidance だけで、システムの安全を確保しようとする考え方はもう古く、まったく現実的ではない。Fault Avoidance の方法論のとして、Formal Method（形式手法）があるが、それは、巨大なシステムの一部に使えることはあったとしても、数百万行クラスのシステム全体になど使える訳がない。

なぜなら、ソフトウェアの最大の特徴はフレキシビリティであり、曖昧さを許容できるところであり、変更容易性であるからだ。

きっちりきっちり決めた部品を積み上げてシステムを構成できるのなら、ハードウェアの組合せで実現できるはずだ。

ソフトウェアって物語を書くようなものだと思う。一つのストーリーを伝えるのにも複数の書き味がある。分かりにくい文章もあれば、最後にどんでん返しを持ってきたりもできる。ソフトウェアのフレキシビリティは欠点かもしれないが、最大の特長でもあるのだ。

だから、構成部品の信頼性を追求し、それを積み上げていく Fault Avoidance と 個別最適だけの考え方は現代のセーフティ・クリティカルなソフトウェアシステムの安全設計では現実的ではない。

今は、個々の部品に問題があるかもしれないと仮定した上で、フェールセーフ設計やフォールトトレランス設計を考える。そうした上で、信頼性を高める必要性があるソフトウェアアイテムに対して、Fault Avoidance を目指す。（でも、絶対に誤りがないと決めつけてはいけない）

そして、相手が人間だった場合、人間が侵すミスは完全には防げないことから、ユーザーがミスを犯しにくいユーザインタフェースを設計する。

これが Total Optimization （全体最適）の考え方であり、大規模、複雑化したソフトウェアシステムにおいて安全を実現するための方法論だ。

組み込み機器向けのコンサルティングを手掛けるBarr GroupのCTO（最高技術責任者）であり、共同創設者でもあるMichael Barr氏＊）は2013年10月、EDNの問い合わせに対し、今回の調査結果を明らかにした。Barr氏は同僚とともに、裁判の原告側の専門家証人として徹底的な調査を実施した結果を明らかにした。これは、セーフティクリティカルシステム開発に携わる全ての人々に対する教訓となるだろう。自動車業界や医療機器業界、航空宇宙業界などのいずれの分野においても、欠陥が生じることは決して許されない。

冗談だろう。教訓にもなにもならない。Fault Avoidance & Specific Optimization の視点で、重箱の隅を突っついているだけだ。

SAFEWARE をまじめに読めばこんな記事にはならないはずだ。

ソフトウェア
　今回の技術調査は、ECMソフトウェアに焦点を絞って行われた。
　まず、ミラーリングが常時実行されていなかったことが明らかになった。ミラーリングでは通常、重要なデータが冗長変数に書き込まれる。スタックオーバーフローが発生する可能性を考えると、非常に重大な問題だといえる。 

　トヨタは、割り当てられたスタック領域のうち41％しか使用していないと主張していたが、Barr氏の調査の結果、実際に使われているのは94％だったことが分かった。さらに、コードの内部において、MISRA-Cに違反する再帰が発見された。これは、スタックにとっては致命的な問題だ。またCPUには、スタックオーバーフローを防ぐためのメモリ保護機能も搭載されていないという。 

　さらに、RTOSのクリティカルな内部データ構造と、スロットル角度関数という2つの重要なアイテムに対して、ミラーリングが不完全だったことが明らかになった。

ここで言っているミラーリングということが、冗長設計（フォールト・トレランス）のことだとすれば、冗長設計がなされていないのは悪だといった口ぶりだが、そんなことはない。

重要なデータが何らかの要因で化けたときのことを考えて、変数を複数持ったり、3つ持って多数決を取るよいという者がいるが、実際にはそんなに簡単ではない。

フォールト・トレランスはシステムを複雑にし、テストパターンを増やしてしまう。仮に複数に格納した変数が一致しなかった場合、どれを正しいと判断するのか。テストすべきパターンは一つではない。よってサンプルテストは通ったとしても、テストパターンがすべて網羅されておらず、漏れがあった場合、非常に分かりにくいバグにつながる。

よって、対象となるリスクによっては、フォールト・トレランスではなく、高信頼性部品を使ったシンプルな設計の方が安全の確度が高まる場合がある。Total Optimization （全体最適）の中では、一部分に Fault Avoidance & Specific Optimization を採用した方がよい場合がある。

皆さんは電波時計をご存じだろう。標準時間の信号に毎日合わせ込みをすることによって、時間を正確に保つ。時間合わせを毎日行うために、水晶発信子の精度は通常の時計よりも悪い。

福島の原子力発電所の事故が起こってしばらくの間、電波時計の掛け時計の時間がずれるなあと感じていた。それは、標準電波を発信する福島のおおたかどや山標準電波送信所（40 KHz） がしばらく停止していたからだ。

電波時計は標準時刻に合わせ込むことで水晶発振子の精度を下げる（フォールト・トレランスの一種）、一般の時計は自動の合わせ込みができないので精度の高い水晶発振子を選別して採用する（フォールト・アボイダンスの一種）という違いがある。

どちらが優れているとは一概にはいえないが、標準電波が発信されてる状況なら電波時計の方が顧客満足度は高いと言えるかもしれない。しかし、標準電波が発信されるという条件は絶対ではないのだ。

安全に絶対はないから、想定したリスクに対して、どんな思想でリスクコントロールをしたのか根拠をもって説明できないといけない。電波時計の場合は、標準電波の発信が条件になる。

よって、この記事は重要なアイテムに対してミラーリングをすることが絶対条件のような書き方をしているが、それはおかしい思った。

さらに、MISRA-C （コーディング規約）への違反を次のように書いている。

Barr氏は、「トヨタのプログラムは、自動車業界で広く採用されている『MISRA-C』への対応が不十分だ。準拠していない箇所が8万個も見つかった。トヨタの内部規格には、MISRA-C規格のうち11個のルールしか適用されていなかった。しかも、ETCSのコードは、そのうち5個に準拠していなかった」と述べている。MISRA-Cとは、欧州の自動車業界団体であるMISRA（Motor Industry Software Reliability Association）が策定したC言語のためのソフトウェア設計標準規格である。1998年に発行されたMISRA-Cの初版「MISRA-C:1998」には、93個の必要要件と34個の勧告要件があるが、トヨタはこのうちの6個にしか準拠していなかったのだ。
　同氏は、「トヨタは、コードのピアレビューが不十分であるか、まったく行っていなかった可能性がある。バグ管理システムも存在しない」と指摘した。

これも現場を知らない者の評論家的発想だ。そもそも、MISRA-C はC言語の表記法の作法の一例だ。その表記法に従ったソースコードで安全が保証されるのかと言えばそうではない。

MISRA-C でのコード表記がシステム安全の条件のような書き方をしているが、それは違う。人間は機械ではない。ソフトウェアを一行一行書いているのは突き詰めれば一人のエンジニアだ。人間はそんなに簡単な生き物ではない。行為は同じでも、動機が間違っていれば効果は現れない。

コーディングルール、コーディングスタイルをそろえましょうという取り組みは、作法がよいと考える書き方をみんなで実践することで、より見やすいコードを書きましょうといったものだ。それなのに、Barr氏はMISRA-C への逸脱を悪だと決めつけ、鬼の首を取ったかのように逸脱を見つけたことを自慢している。

これを見ると、1960年代にエドガー・ダイクストラが構造化プログラミングを発表し、関数は一行80文字以下、50行以下にした方がレビューしやすいという設計の規範が、いつの間にか50行以上の関数を許してはいけないというルールに変質したことを思い出す。

トヨタは大人だから黙っていると思うが、「コードのピアレビューが不十分であるか、まったく行っていなかった可能性がある。バグ管理システムも存在しない」などど言い放って、もしそれが本当でなかったら名誉毀損で訴えられてもおかしくないと思う。（和解で決着が付いた裁判に使われた途中の証拠を使って一方的に評論するのは間違っている。アメリカ人のくせにフェアーでない。）

コーディング規約はプロジェクトの内部で設計の規範をリーダーのリーダーシップの下で実践していった時のソフトウェア品質に効果を及ぼす。業界標準だからという説得力の薄いルールでコーディング規約の縛りをかけても効果はそれほど高くない。（ISO 26262との向き合い方 (22) テンプレートで乗り切る功罪2）

NASA（米航空宇宙局）は、Barr Groupよりも前にトヨタ車の調査を行い、ETCSに実装された5つのフェイルセーフモードについて報告している。トヨタのフェイルセーフモードは、3つの「リンプホームモード（非常時の動作モード）」と、RPM（1分間当たりの回転数）制限、エンジンの停止で構成されている。だが、これらのフェイルセーフモードはすべて、同一タスクで処理されている。そのタスクが停止したり、故障したりした場合はどうなるのだろうか？

この部分もしかり。フェイルセーフの機能はどのように分離するかどうかの有効性は、リスクコントロールを行った後の残留リスクの評価によって判断する。

この記事では残留リスクがあるということだけをにおわせておいて、残留リスクが許容できない根拠が書かれていない。あえて読み取るとすれば、NASAが指摘しているから？か。NASAが言っていることはすべて正しいのか、一基何十億円もするシステムのフェールセーフと一台数百万円のシステムのフェールセーフを比べてもいいのか。

人の命はお金には換算できないって。そう、その通り。だから、リスクは何かを想定し、リスクコントロールを実施しても許容できないのなら、そんな商品は売ってはいけないのだ。

安全を確保するということは、多くの場合コストも含めてギリギリのところで、せめぎ合ってリスクヘッジしているのだ。重箱の隅をつつくだけのお気楽な奴らとは、立場が違う。彼らは重箱の隅を突っついて、それが出来ていないと「危ないですよ」とクライアントを煽り立て、それを指導することで儲けるが、仮にその指導の結果、事故が起こっても何の保証もせず、「こっちの方法論もやっていなかったですよ」といけシャーシャーと言う。

機器の製造業者は安全という責任を背負って日々の活動をしている。だから、そういう活動をしているにも関わらず、事故が起こってしまったときのショックは大きいし、自責の念も強い。

だから、正義面して重箱の隅をつついて、白馬の騎士を気取っているヤツを見ると本当にむかつく。

安全システムを扱っている人なら誰でも、何としても単一障害点（SPOF：Single Point of Failure）を回避すべきだと認識しているだろう。だが今回のケースでは、2個のCPUに車両状態情報を供給するA-Dコンバータが、SPOFになっていた。

前述のように、フォールト・トレランスが常にフェール・セーフに有効とは限らない。高信頼性部品を使い、構造をシンプルにすることで全体のリスクを低減することだってある。

最後に、この記事の結論の一つ一つに突っ込みをいれていこう。

結論

　ソフトウェアの欠陥が明らかになった今回の問題から、われわれは何を学べるだろうか。

• 全てはエンジニアリングの文化から始まる。品質を実現するには、適切な相互評価、文書化されたルールの実施、コード品質のツールや基準の使用などに取り組む文化が必要となる。

安全の実現には文化が必要という主張なら同意する。しかし、安全と品質を混同しているのなら、それは間違い。安全は絶対的な概念ではなく、ルールやツール、基準を絶対的な存在と位置づけたら、そっちの方がよっぽど危険だ。

• 複雑なシステムでは、ハードウェアやソフトウェアによって引き起こされる可能性のある故障のシナリオを、全てテストするのは不可能だ。欠陥のないコードを作成するには、考えられるあらゆる最善策を施し、使えるツールは全て利用するくらいの心構えで設計しなくてはならない。

前半は同意。しかし、欠陥のないコードを作成するにはあらゆることをしろというのは不同意。使えるツールはすべて利用しろだって。バカを言うな。どんなツールがどんな効果があるのか、ツール自体の Validation（妥当性確認）が必要だといったことが分かって言っているのか。ツールの導入とコストと効果のバランスを考えないで導入できると思っているのか。言ってることが正しくても、それを言う心根がまっすぐではないのがかんに障る。欠陥のないコードを目指すことはよいが、それでも残ることを想定してシステム全体としてリスクが許容できることと目指す。

• 適切なところにはモデルベース設計を用いる

モデルベース設計は、モデルをコードに変換する部分の人的関与を減らすリスコントロールだ。でもモデル変換の部分を作ったり、変更したりするのは人間だからその部分に不具合が絶対にないとは言えない。モデルベース設計だから安全と考えるのは間違い。

• 異なるエンジニアリングチームで、徹底的にシステムをテストする必要がある。自分で設計したものを、自らテストするという間違いを犯してはならない（トヨタがどのようにテストを行ったのかは、特に説明されていない）。

欧米の人は必ずそう言い、NASAはV&Vは独立しているべきと言い、IV&V(IはIndependent）が重要という。でも、そのソフトウェアの要求仕様やアーキテクチャを一番よく知っているのは、そのソフトウェアを作成したソフトウェアエンジニアだ。単純に性善説、性悪説ということではなく、ユーザーの使用環境やソフトウェアシステムのアーキテクチャよく考慮した効果的なテストを設計できるのは、そのソフトウェアを設計したソフトウェアエンジニアではないか。そのソフトウェアシステムのことをよく知らないエンジニアリングチームが闇雲にテストして、分かりにくい不具合を見つけ出すことができるとは到底思わない。NASAが IV&V を盛んに言うのも、自分ではソフトウェアは作ってないからではないかといつも疑っている。自分で作っていないから、アーキテクチャを考慮したテストができないので、独立したチームでテストした方が効果が高いといっているのでは？

• 基本となるハードウェアは、ファームウェアと連携して信頼性を実現する必要がある。例えば、SPOFは回避しなければならない。タスクを完全に分離し、保護するために、ロックステップCPU、EDACメモリ、適切なウォッチドッグ、MMU（メモリ管理ユニット）といった技術で、信頼性を向上しなければならない。さらに、故障モードを決定し、設計の改善に結び付けるために、FMEA（Failure Mode Effect Analysis：故障モード影響解析）を徹底的に実施する必要がある。

信頼性と安全性は異なる。信頼性をいくら高めても安全を保証することはできない。信頼性を追求すれば際限がない。ユーザーに対して、何らかの安全を保証するのなら、製造業者はどこかに線を引かないといけない。その線の要因の中に企業間競争やコスト、リリース期限の要素は必ず含まれる。

それらのさまざまな要因を考えて線を引き商品をリリースし、フィールドで何かあったときに走り回るのが、機器の製造業者の責務だ。

そんなに苦しいのなら、やめればいいのにと思うかもしれない。しかし、その苦しい責務以上に、製品を通した社会への貢献を感じ、ユーザーから感謝の気持ちを受け取る喜びを感じることができる。だからこの仕事を続けている。

6月7月に行った SESSAME のソフトウェア安全分析・設計セミナで、自動車業界の方達と接し、自動車のサプライヤとOEMの関係を少し実感したので、そんな単純ではないなということが分かったが、もう少し安全と信頼の違い、リスク分析とリスクコントロールの設計について、業界全体として理解を深めて欲しいと思った。

今回のブログのタイトルをもう一度叫んで終わりにしようと思う。

「安全を売り物にするな！安全を食いものにするな！」

---

P.S.

ソフトウェア安全分析・設計セミナ Part 1 の最後で紹介している、放射線治療器 Therac-25 の事故分析の結果、ナンシー・レブソン教授が出した結論をここに紹介する。なんだ、上記の結論を似ているじゃないかと思うかもしれないが、それは違う、上記は裁判で勝訴することを目的とした論証の結論であり、下記は事故に向き合い事故の再発防止を目的とした教訓だと思っている。実際に、FDAは Therac-25 の事故の後、この研究結果を医療機器ソフトウェアのガイダンスに盛り込んで、実践させ、それによって事故が減ってきているかどうかをウォッチし続けている。前者の結論は責任のない評論家の結論。後者の結論は、どうしたら事故を再発させないか真剣に考えた研究者の結論だと思っている。

ナンシー・レブソンが解く 事故の原因因子

ソフトウェアへの過信
・ソフトウェアは故障しないし、故障できないという意識があった。

信頼性と安全性の混同
・Therac-25 は過剰照射が起きるまで何万時間も可動しており、誤動作はしなかった。
・信頼性が高かったためにAECLは自分達のソフトウェアは安全であると思い込んでいた。

防御的設計の欠如
・技術者は最悪の場合に備えて、内部で何が起こっているのかを調査しうる仕組みを組み込むべき。

根本原因の排除の失敗
・ソフトウェアの不具合が分かりにくいからといって、根本原因を追及せずに見込みで判断してはいけない。
・ソフトウェアに欠陥が見つかるたびに個々にそれらを解決しても機器の安全性の問題を解決することにはならなかった。

自己満足
・過去10年、20年、医療用加速器の使用において重大が放射線事故がなかったことで安全であると思い込んでしまった。

非現実的なリスクアセスメント

・確率論的リスクアセスメントが機器への過信を生み、リスクアセスメントの結果自体を過度に信頼することになった。（ソフトウェアの特性を排除していた。Systematic Failure） 

不十分な原因調査、あるいは事故報告書の不十分な追跡調査

・セーフティクリティカルなシステムを構築しているすべての企業は、監査証跡と、事故を招くかもしれない問題の兆しが見つかった時に適用されるインシデント分析手順を備えるべきである。

ソフトウェアの再利用

・レガシーソフトウェアや COTS（商用ソフトウェア）の使用が安全性を増加させるだろうと単純に思い込んでいた。

・ソフトウェアモジュールの再利用は移行した新たなシステムにおける安全性を保証するものではない。

安全なユーザインタフェース対使いやすいユーザインタフェース

・機器をできるだけ使いやすくすることは安全目標と相容れないこともあり得る。(Usability)

ユーザー及び政府の監督と規格

・Therac-25の事故があってから、FDAは報告システムの改善を始め、ソフトウェアを含めるように手順や指針を拡大し始めた。

・ユーザーからの情報や働きかけも機器の問題を解決するには重要だった。


ソフトウェアエンジニアリングの不十分な実施

原文	訳文
Software specifications and documentation should not be an afterthought.	ソフトウェア仕様と文書類は後知恵の産物となるべきではない。（最後に揃っていればいいやはダメ）
Rigorous software quality assurance practices and standards should be established.	ソフトウェア品質保証に関する厳正な実施とその基準が確立されるべきである。
Designs should be kept simple and dangerous coding practices avoided.	設計は単純にしておくべきであり、危険なコーディングを行うことは避けるべきである。
Ways to detect errors and get information about them, such as software audit trails, should be designed into the software from the beginning.	ソフトウェア監査証跡のように、エラーを検出し、そのエラーに関する情報を取得する方法を、最初からソフトウェアに組み込んで設計するべきである。
The software should be subjected to extensive testing and formal analysis at the module and software level; system testing alone is not adequate. Regression testing should be performed on all software changes.	ソフトウェアは、詳細なテストとモジュールレベルやソフトウェアレベルでの形式的分析を受けるべきである。システムテストだけでは不十分である。ソフトウェアのあらゆる変更に対して回帰テストを行うべきである。
Computer displays and the presentation of information to the operators, such as error messages, along with user manuals and other documentation need to be carefully designed.	エラーメッセージなど、コンピュータディスプレイとオペレータへの情報の提示は、ユーザーマニュアルや他の文書とともに設計に十分な配慮が必要である。

ナンシー・レブソンの言葉

• どんなに慎重に作ってもソフトウェアは満足できるほどに完璧にはならないため、ソフトウェアがどんな動きをしたときでも、人命に危険が及ばないようにシステムを設計する必要がある。ソフトウェアの信頼性をできるだけ高めるのは悪いことではないが、それでソフトウェアが安全になるわけではない。プログラマは要求を満たすようにコードを書くが、要求が正しいとは限らない。事故のほとんどは、プログラミングのエラーではなく、要求が間違っていたり、不完全であったりしたために起きている
• われわれの目標は、だれもがこの経験を生かせるようにすることであり、装置のメーカーや他の人を批判することではない。間違いは、このメーカーにだけ起きたのではなく、残念ながら、安全が最優先されるべきその他のシステムにも、きわめて日常的に起きている。
• いくつかの出来事が複雑に絡み合って起きた事故が、一つの原因にされることが多すぎる。ほとんどの事故は、システム事故、つまり、さまざまな構成部分や機能が複雑に作用しあって起きるものだ。事故の原因を一つに特定することは、大きな間違いだ。