今年の反省

年末も近づいてきたのでブログ上での自分を振り返ってみようと思う。

ISO 26262 との向き合い方1回目の記事を書き始めたのが、2011年の12月からだからちょうど1年になる。

ブログでは誰かを批判的に書くことはできるだけしないように気をつけているつもりでも、どうしてもこの話題を取り上げると、ISO 26262 で商売をしようとしている者を批判的に書いてしまう。

そういう口調になってしまう理由は、安全な商品を提供しようと努力している日本のエンジニアが自分たちがやってきた良いことを認識できずに、外から言われるがままに欧米で培われたやり方に心酔し、これまでの自分たちのやり方をあっさり方向転換して、結果的にこれまでより商品の価値を低くしてしまう間違いを何とか防ぎたいと思っているからである。（欧米からの思想、方法論もよいところは取り入れ、説明責任を果たすために、本音と建て前をどう使い分けるべきかを考えて欲しい。）

でも、そう言いながら、自分自身がソフトウェアの安全設計に関するコンサルテーションを生業とする可能性は将来あるかもしれない。

万が一そうなったら、自分がさんざん批判的に書いてきた方の立場の側に身を置くことになるかもしれない。そんな状況は自分自身の信条に反するので決してないと思うが、未来の自分の進路を狭めることにつながるので、世渡りの上手な賢者はブログで誰かを批判するとは決してしない。

また、自分は『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事で紹介した「評論家くん」にだけは絶対なりたくないと思っている。常に問題解決キッズでなければいけない、そうなりたいと思っている。

このブログではできるだけ自分自身をエンジニアの当事者として一人称で書くように努めているつもりだ。だからこそ、時にエンジニアにとってプラスにならないと思うと、批判的に書いてしまうことがある。

そういうとき、自分は評論家くんになっていないかと自問自答することがある。評論家的に言うことは簡単だが、じゃあ、クライアントとなるエンジニアを安全設計エンジニアとして自立させ、価値の高い商品をアウトプットできるように育てられるのかと自分に問うたときに、ドメイン違いではなかなか自信は持てない。

また、ISO 26262 で商売をしたい、売り上げを伸ばしたいと考えている組織、営業、コンサルタント、ツールベンダーがクライアントをだまそうと悪意を持って行動しているわけではない。彼らは彼らで自分たちが正しいと思って行動している訳だし、生きていくため、景気がまだよくない中、売り上げを上げたいと必死に努力しているだけなのだ。彼らのサービスを受ける側の当事者でないのなら、その活動を妨害する権利はないようにも思う。

賢明な当事者の技術者は、いろいろな誘い、セールスに対して選択することができる立場にある。正しい判断ができない者は、後に間違いに気がつくか、競争の中で淘汰されるだけなので、余計なお世話を焼かない方がよいとアドバイスしてくれる人もいる。

ブログへのアクセスはきっちり分析しているので、コンサルタントとおぼしき組織から頻繁にアクセスがあることも分かっている。

ということは、エンジニアに向けて情報発信しているつもりが、エンジニアを言いくるめるネタを彼らに提供しているだけではないかと思うこともある。このブログサイトで学習しているのは、エンジニアではなくコンサルタントでは？と思うこともある。

まあ、何はともあれ、読者となっているエンジニアが関わっている商品のエンドユーザに対する価値向上に役立つ記事を書いているはずだと信じて続けていくしかないのだろう。

これ、英語圏ならもっと読者レスポンスがガンガンあるはずなので何とか英語で情報を発信できるようにしたいとういのが将来の目標である。

このブログ、Google Adsense で広告掲示すると利益が出ますよと Google からアドバイスされるのだが、批判的な記事を書いている対象の企業の広告が出ていたりすると、洒落にならないので、その誘惑だけは断ち切るようにしている。

第二次世界大戦の時代を生き抜いた妹尾河童の自伝的小説「少年H」で、戦時中威張っていた学校の教師が、敗戦、民主主義の社会になったとたんに態度を一変させるくだりを読んで、そういう立場が変わって手のひら返すような人間には絶対になりたくないと思う一方で、そういう自分の弱さを認めたり許容できないかっこつけの考え方が人間の幅を狭くしているのだと考えることもある。

単なるブログではあるが、書く方もいろいろ悩みながら書いているのだ。

今年のブログの反省点はこんなところかな。

工業会主催のホンモノのセミナーが開催されるようです

Google Alarm で 「ISO 26262」とキーワード登録しておくと、いろいろなニュースが引っかかる。

「またかぁ」というものが多いが、これは参加する価値があるセミナーだと思う。

東京：2013 年2 月6 日（水）～8 日（金）3 日間
名古屋：2013 年2 月18 日（月）～ 20 日（水）3 日間

「ISO 26262 規格原文読み込みワークショップ～ISO 26262 の要件を原典で理解できる！」

なぜ、そう思うかというと、主催が（公社）自動車技術会（そのドメインの工業会）で講師が規格の適合を目指す当事者側の方たちだからだ。

テキストが規格の対訳で全部そろえると10万円くらいかかるが、本気で取り組むつもりなら持っていないと話が始まらないのでしようがないだろう。

ISO 26262との向き合い方 (19) 事故の再発防止について考える

2012年12月2日に中央道 笹子トンネルで天井が崩落する事故が起こった。事故に遭われた方、ご親族の方、お悔やみ申し上げます。

エンジニアができることやらなければいけないことは、一つは事故が起こらないようにリスクを分析し設計に活かすこと、そしてもう一つは事故が起こってしまったときに再発をしないような仕組みを作ることである。

むろん、規格に適合することが目的ではない。エンジニアには安全を確保するために今よりも前進できるかどうかが問われている。

よって、エンジニアは評論家のように単純に批判を繰り返すだけではいけない。「自分の関わっている製品、システムだったら」という観点で考えなければいけない。

設計 FMEA を実施した例

笹子トンネルの天井崩落事故について、エンジニアが考えなければいけないのは、まずは、FMEA(Failure Mode and Effect Analysis)の視点である。つり金具の老朽化が疑われているようだが、システム（今回の場合はトンネルの天井構造）の構成部品の故障モード（つり金具の脱落もその一つ）が起こったときの次の項目についての分析が必要となる。

下記に設計FMEAを実施した例を示す。

【設計FMEAの分析項目例】

1. 故障モード（具体的に）
2. 故障原因
3. 故障の影響：部分的影響
4. 最終システムへの影響（天井の崩落）
5. 故障検出方法（打音検査→それで正確に分かるのか）
6. 故障の重要性（重要度は極めて高いことが分かっている）
7. 故障の発生頻度（過去にどれくらい発生したことがあるか）
8. 対策案
9. 検出難易度
10. 致命度ランク（重要度×発生確率×検出難易度）

※設計FMEAの分析項目はこうでなければいけないという決まりはない。形式にとらわれないことが大事である。

トンネル構造部の設計FMEA の例（一部）

故障モード	故障原因	故障の影響		故障検出方法	故障の重要性	故障の発生頻度	対策案	検出難易度	致命度ランク
		部分的影響	最終システムへの影響
つり金具が折れるまたは脱落する。	つり金具の振動、腐食による老朽化。	天井ユニットの脱落。	連結している天井ユニットの連鎖的脱落。	打音検査等による定期検査。	走行中の車両に当たると死に至る可能性がある。	全国のトンネルに付き、○○年に○回。	異常が発見された場合、一週間以内に補修し、トンネルあたりの修理数が○回を超えたら、○ヶ月以内に恒久対策を講じる。	中程度	最上

【設計 FMEA の分析のしかた】

FTA に見られるトップダウンの安全分析方法に対して、FMEAはボトムアップの解析手法と言われる。FTA が最終的に起こしてはならない事象をトップにおいて分析を始めるのに対し、FMEA では故障モードを左端において解析を進める。

よって、FMEA の使い方としては、市販前の製品の設計段階において故障モードを洗い出し分析、対策し、市販後に起こった障害や事故の故障モードの分析をそれに追加するという使い方をするのが一般的であろう。

[故障モード]
システムの構成部品が故障するときの状況について具体的に記述する。故障モードの前（左側）にシステム全体に対して、どの部分に関する故障であるかを示すための階層を追加することもできる。

例) トンネルシステム→天井部分→接続部

[故障原因]
故障モードが発生する推定原因を記載する。

[故障の影響：部分的影響]
故障が引き起こす部分的な影響、例えば「天井ユニットの脱落」を書く。

[故障の影響：最終システムへの影響]
部分的影響がもたらす最終システムへの影響の可能性を書く。

[故障検出方法]
故障の検出方法を書く。ちなみに「仕業点検」や「目視」という検出方法もあるが、故障の重要性が大きい場合、人間の目に頼る検出方法はお勧めできない。

[故障の重要性]
故障の重要性をシステム利用者が被る危害に焦点を当てて書く。

[故障の発生頻度]
故障の発生頻度を定量的（定量的に計算できない場合は、定性的）に記載する。数値化することが難しい場合のために、目安となる指標（頻繁に起こる、まれ、極めて少ないなど）をあらかじめ準備しておく。

[対策案]
具体的な対策を示す。設計上の対策を行うことがベストであるが、表記上の対策（説明書記載のラベリング）でしか対策できない場合もある。

[検出難易度]
故障モードを検出する難易度を示す。

[致命度ランク]
故障の重要性、発生頻度、検出難易度の3つのパラメータから致命度ランクを計算する。決まりはないため分析対象物やドメインに対して、判定基準をあらかじめ作成し、SOP(Standard Operation Procedure) に記載しておく。

今回のトンネル天井崩落事故の場合、注視すべき点は故障モードが起こす部分的な影響と最終システムへの影響である。つり金具の脱落という天井のユニット（板）に発生する部分影響が連鎖的に周りにユニットの崩落につながっていることを認識した上で再発防止の対策を考える必要がある。

事故が起こると「なんで、こんなことが分からなかったのか」と皆が思う。しかし、事故が起こる前に危険性を指摘すると「今から変えられない」とか「コストがかかる」とか「これまで起こっていなかった」という理由で動かない組織はたくさんある。

そのネガティブな組織判断をサイエンスとエンジニアリングによって突破するのがシステムの安全に対して責任を負うエンジニアの役目であり、それを組織的に支援・管理するのが品質マネジメントシステムである。

今回のような事故の場合、故障検出方法の設計、故障発生頻度、検出難易度の決定が再発防止に大きな影響を与える。実際には打音検査によるボルトの緩み等のチェックが行われているようであるが、人間の感性、感覚に頼る検査方法は本質的なリスクとは異なるヒューマンエラーのリスクを伴う。

FMEA の結果は、表にしなくても見識者ならだいたい思いつくような内容だ。しかし、FMEA を行う意味は、他のリスクと同様にある一定の手順に基づいて、故障によるリスクを分析することにある。

人間の記憶は時間と共に薄れていくものなので、知見を継承するためにも、同じ様式による分析結果を組織が保持することが大事なのだ。

FMEAには市場からのフィードバックとして修理情報や苦情情報などをインプットするため、設計 FMEA はどんどん積み重なっていく。故障モードや想定されるハザードは無限に存在するのでFMEA では追加対策自体が新たな Hazardous Situations を生み出したり、故障モードはハザードが多すぎて、どこの焦点を合わせたらよいかわかりにくくなる傾向を持つ。

そのため、故障の重要度、発生頻度、検出難易度から致命度ランクを計算し、これによって対策に優先順位を決めたり、重大な被害につながる故障に焦点を当てたり FTA を行うことで、対策が多すぎてコストや開発期間が優先になって、安全対策が後回しにならないようにする。

FTA によって他の事象との関係を確認する

「トンネル内の火災により死傷者が出る」をトップ事象にしたときのFTA図につり金具の老朽化による天井の崩落の事象を追加した例を示す。

トンネル内の火災となる原因は他にもあるはずなので左記はほんの一部の現象を切り取ったに過ぎない。

FTA が FMEA に比べて優れている点は、起こしてはならないトップ事象に対して、想定した事象がどのように影響しているのかを容易に判断できることである。

別な言い方をするとどの事象が一発でトップ事象を引き起こしてしまうのか、また、どんな歯止め、どんなリスクコントロールが失敗するとトップ事象を引き起こしてしまうのかを把握しやすいということだ。

つり金具の脱落が金具の老朽化とボルトの緩みが原因だったとして、それが仮に起こったとしても、打音検査によって見つけることができれば事故を未然に防ぐことができるかもしれない。（FMEAのところでも書いたように打音検査はヒューマンエラーのリスクを含む）

よってつり金具の故障と打音検査の失敗が AND で重なったときにトップ事象に到達してしまう。このように、FTA では着目すべき事象が、他の事象とどのような関係性を持っているのか、どのリスクコントロール手段がトップ事象への到達を押さえているのかを把握するときに有効である。

FMEA によってリスクコントロール手段を次々と追加していった場合、それらのリスクコントロールがどのようにシステムを複雑にしているのか分析するときにも  FTA が役に立つ。闇雲にリスクコントロール手段を追加していくと、かえってシステムの安全性を低下させることもあるので注意が必要である。

システム全体としてシンプルなリスクコントロールにより、トップ事象を起こさない(=安全を確保できる）ことを目指す。

リスクマネジメントのフィードバックプロセス

左図は、ISO 14971(医療機器－リスクマネジメントの医療機器への適用)のリスクマネジメントプロセスの一部である。

注目して欲しいのは、10 の製造情報及び製造後情報のアウトプットが 5 のリスク分析のインプットにつながっている点である。

ようするにリスクマネジメントのプロセスはフィードバックすることが前提であり、リスク分析、リスク評価、リスクコントロールは製品やシステムが市場にある限り継続し続けなければならないのだ。

そのとき、FMEA や FTA は、リスク分析、リスク評価、リスクコントロール、残留リスクの評価、リスクマネジメント報告に各プロセスで利用することができる。

対象となる商品やシステムを取り巻くリスクは無限に存在する。リスクが無限に存在するからといって、リスク分析やリスクコントロールを永遠に続けることはできない。組織は有限なコストや開発期間のために、リスク分析をどこかで打ち切らざるを得ないのだ。

そのため、組織はできるだけ短期間にリスクを洗い出し、有効な対策を設計に活かす必要がある。それが上手くいけば、それらの対策は商品や組織のアドバンテージとなり、商品の潜在的価値を高めることにつながる。

ただ、残念ながらそのような努力を最大限行ったとしても、事故は起こってしまうし、時代とともにリスクに対する人々の感性は変わっていく。

だからこそ、上記のリスクマネジメントプロセスはフィードバックしなければならないのだ。

CAPA（Corrective Action & Preventive Action：是正処置及び予防処置）の実施

リスクマネジメントプロセスを実施していたにもかかわらず、事故が起きてしまった場合、CAPA（Corrective Action & Preventive Action：是正処置及び予防処置）を行う。事故が起きてしまった後に実施するのが Corrective Action で 事故が起こらないように未然に察知する対策を取るのが Preventive Action となる。

Corrective Action: 是正処置で重要なのは、実際に起こった問題を除去する処置＝修正（correction）と是正は異なるという点だ。是正処置は、検出された不適合又はその他の検出された望ましくない状況の原因を除去するための処置(ISO 9000 用語の定義）であるから、根本原因を除去する処置を執らなければいけない。

つり金具を補強するとか、緊急点検するといった行為は根本原因の除去ではない。自分が考えるこの事故の根本原因は、天井構造を設計する際のリスク分析/ハザード分析の不足及び、事故が起きたときのメインテナンス事業計画への見直しのプロセスの欠如である。

対象製品やシステムのリスクが無限に存在することを考えたとき、事故発生後に根本原因を追及して、取り除くことができるかどうかが、同様の事故の発生を効果的に防止することにつながる。

事故発生後にその場しのぎの対策を取ってしまうことは根本原因を取り除くことにはならない。

高速道路上のトンネルで笹子トンネルのような天井ユニットを取り除く検討が各地で進められているようだが、それは根本原因の除去になっているだろうか。トンネル上部の天井構造は1960年代の自動車の排ガスを効率的に排出するために設計されたと聞く。現在では、排ガスをクリーンにする技術が進んだためトンネル内の排気はファンで十分なのだそうだ。

そうなると根本原因の除去として必要なのは、時代の変化、環境の変化、構造物の老朽化要因をトンネルのメインテナンス計画にインプットし、リスクが受容できるかを判定するプロセスを追加することだと考える。

12月11日の毎日新聞のニュースサイトに『トンネル崩落：中日本高速、米事故後も対応取らず』という記事が掲載された。

米国の高速道路で０６年に極めて似たトンネルの天井板崩落事故が起き、独立行政法人が０８年に作成した調査文書で事故原因などを国や高速道路各社に伝えていたことが分かった。国や中日本高速道路も事故を把握していたことを認めているが、具体的な対応は取らなかったとみられる。専門家は「緊急点検などの対処をすべきだった」と批判している。

事故が起こった後に批判するのは簡単だが、批判と是正処置（Corrective Action）は違う。このケースでは次のようなことをやりきらないと是正処置（Corrective Action）にはつながらないと思う。

• 高速道路の関する“自組織が管理する高速道路”の事故、修理、苦情情報を収集するプロセスを現行プロセスに追加する。
• “日本国内の他組織が管理する高速道路”の情報も含める。
• 関係独立行政法人からの報告書も含める。
• 海外の事故情報も含める（かどうか判断する）。
• これらのデータを品質保証部門が集計、統計的な分析を加えて、定期開催される組織の品質保証委員会に提出する。
• 品質保障委員会にて、これらのデータについてどう判断したのかを記録に残す。
• 上記のプロセス及び手順を SOP （Standard Operation Procedure）に記載し、定期内部監査によって実施されていることを確認する。

こうしておけば、海外で起きた事故のデータについて「動かない」判断をしたトップマネジメントの責任が明確になり、問題が発生したときの判断ミスがはっきりする。

これは ISO 9001 （品質マネジメントシステム）のアプローチそのものなので、ISO 9001 を取得している組織はできるはずなのだが、ISO 9001 の認証を取得することが目的になっていると、事故が起こったときに本当にやらなければいけないことができない。（このブログで口を酸っぱくして言っているのは、ISO 26262 も同じで、規格に適合できても、安全を確保する能力が高まらないのであれば意味がないということだ。）

何か問題が起こったときに批判して評論だけするのが「評論家」くんで、Corrective Action をやりきれるのが問題解決キッズである。（人気の記事『問題解決能力（Problem Solving Skill)：自ら考え行動する力』を参照されたし。）

「評論家」くんは、何か事件が起こったときに鬼の首を取ったように生き生きと問題を指摘するが、再発防止にはあまり貢献しない。本来は火消しよりも、防火活動を地道に行っている者を組織は評価するべきだと思う。

修正（correction）はそのときだけの対策であり、是正処置（Corrective Action）は、根本原因を取り除くことで、将来に渡っても同様の問題を起こさない対策である。その違いを十分に認識できていないと、事故は再発してしまう。

前述の FMEA , FTA の結果により、リスクを最小限にするにはどのような構造設計がふさわしいか、ふさわしくないかが分かる。今回のように構造物として簡単に取り替えがきかないのだとしても、保守計画はあるだろう。保守計画プロセスに、例えば過去20年間の事故や事故に至る前の予兆現象をインプットできていれば、そのための予算策定や行動計画が立てられる。事故が起こってからではなく、事故が起こる前に Preventive Action が取れるかどうかが安全エンジニアの力量が問われるところであり、そのためには予兆の検出技術が不可欠となる。

予防処置（Preventive Action）を実施するためには、対象物に対する定期的な検査が不可欠となる。

左図にあるように、定期検査の結果が管理限界に達したときに、事故が起きる前の予防処置を実施する。

破壊するところまで達してしまっては遅いので、管理限界点は過去の統計的なデータに基づいて余裕を持って設定する。

予防処置を確実に実施できるようにするためには、事故に至る前の予兆をいかに予知できるかどうかにかかっていることが分かるだろう。

したがって、この故障の予兆を検出する技術こそが、リスクコントロール手段と並んで安全を確保するを実現する重要な技術であることが分かる。

品質の向上と安全の確保は異なる

商品の安全に対して責任を負った経験がない者は「品質の向上」と「安全の確保」を同義にとらえる傾向がある。品質向上にはここまでという一線がないため、品質向上を商売にしている者にとっては都合がよい。一方、安全には超えてはならない一線が存在する。想定したリスクが受容できない限り商品を市場に出すことはできない。そして、やるべきことをやっても事故が発生してしまったときは、その経験をフィードバックしていく。

品質向上施策には Best Practice がいろいろあって、「あれをやった方がいい」「これが有効だ」などと無責任に助言できるが、「安全の確保」はそんなもんじゃない。

特にソフトウェアの場合、やれ「ISO 26262 ではフォーマルメソッドが推奨されている」とか「トレーサビリティアナリシスをやらないとダメだ」などと、言葉の知識がない者に品質向上施策の単語を並べる者がいるが、安全の確保はリスクマネジメントプロセスのフィードバックを繰り返すことによって少しずつ強固になっていくのだ。（安全の領域にも銀の弾丸はないのだ）

そして安全を強固なものにするためには、不具合や事故が起こったときの根本原因の分析と、根本原因を取り除くための対策を講じることが重要になる。

それを繰り返すことによってのみ組織は顧客から信用を得ることができる。

※この記事に書いたことは、医療機器ドメインを含む既存の安全工学に基づいた知見の応用である。自動車ドメインが安全の領域に進んで行くのであれば、規格要求を理解をするだけでなく、他のドメインや自動車ドメインで安全のためにどんな取り組みがなされてきたのかを調べてみるとよいと思う。

P.S.

2012年12月4日 日刊工業新聞に下記の記事が掲載された。（詳細は有料会員登録が必要）

【日刊工業新聞の記事より引用】

日本自動車研究所（JARI）は主要な自動車および自動車部品メーカーなどと連携し、自動車の機能安全規格「ISO26262」に対応する際の日本の自動車業界の共通見解を取りまとめる。 

　同規格の個別内容にどの程度厳格に対応するか見解をまとめることにより、対応過剰や対応不足など完成車メーカーと部品メーカーの同規格に関する考え方のミスマッチを防ぐ。2013年2月にワークショップを開き公表する予定。 

　JARIのISO26262運営委員会が進める共同研究のワーキンググループには、トヨタ自動車をはじめ完成車メーカー9社と、関連する自動車部品や電機などサプライヤー17社の合計26社が参加している。規格の1文1文について、「何を意味しているか、どうやって、どこまで対応するかを検討してきた」。

【引用終わり。】

JARIは自動車業界の中にいて安全性の試験をしているわけだから自動車ドメインのことは、何も知らない第三者認証機関よりよく知っているだろう。

また、上記の運営委員会は自動車完成メーカー9社とサプライヤー17社が参加しているので、現場の目線でISO26262で見ていると思われる。

よって、JARIから見解が出たら、雑音に惑わされずにそれを参考にするのがよいと思う。

ISO 26262との向き合い方 (18) ツール認証って何だ？

ISO 26262 Part 8: Supporting processes （支援プロセス）には「ソフトウェアツールの使用への信頼」という章がある。

いろいろな国際規格を見てきたが、商業目的につながることが目に見えているツール種別の推奨やツール使用の条件のような内容を規格の本文に書いているのは、IEC 61508-7(Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures) と、ISO 26262-8 (Supporting processes) だけではないかと思う。

ET2012 で富士設備工業（株）の浅野さんに FAA(アメリカ連邦航空局：Federal Aviation Administration)では、当初、航空機開発を行う際に使用するツール認証を一般的なソフトウェア開発プロセスの判断基準で行っていたが、問題があったので止めたことを教えてもらった。

【The Latest Trends in International Standards Required for Certification 国際スタンダード認証に必要なテストの最新動向 October 5, 2012 Tokyo　LDRA資料より引用】

The FAA and Tool “Certification” FAA のツール認証について

• The United States Federal Aviation Administration (FAA) once tried issuing “letters of certification credit” for using “pre-qualified” tools.
かつてFAA (《米》連邦航空局) では、“認定済み” ツールの証明書の発行を試みた。

– The pre-qualified tools were evaluated against a generic set of software development process criteria.
認定済みツールは一般的なソフトウエア開発プロセスの判断基準で評価された。

– The letters of certification credit imposed constraints on the use of the tools to match the generic development process criteria.
それら認定済みの証明書では、一般的なソフトウエア開発プロセスの判断基準に従ってツール
を用いるといった制約を強いた。

• Because the FAA’s software development guidance allows for various development methodologies to satisfy the objectives, it was found that many tool usage scenarios did not meet the constraints on tool use.
FAAのソフトウエア開発ガイダンスではオブジェクティブを満たすうえで、様々な開発方法論を認めている。それゆえ認定上のツール用法の制約に、様々なツール使用のシナリオは合わないことが明らかになった。

【引用終わり】

ストレートには書いていないが「認定済みの証明書があるこのツールを使え」という制約は、実際のツール使用のシナリオに合わない、すなわち本末が転倒していたことを認めている。認証済みのツールを使った方が航空機ソフトウェアシステムの安全や信頼の確保の効果が高いという傾向が見られなかったのだろう。

医薬品や医療機器の世界では、アメリカのFDA が CSV（Computer System Validation）を製造業者に求めている。CSVの目的は、クリティカルな製品を開発、製造する際に、ツールや自動工程で使うソフトウェアの妥当性を評価することである。

簡単に言えば、危ないものを作るのに何らかのソフトウェアを使っているのであれば、それが製品の安全を脅かしていないことを確認して根拠を示せと言っている。

根拠を示さなければいけないのは、製造業者サイドであって、ツールベンダーではない。（ツールベンダーやサプライヤと協力して根拠を示すことはある）

買ってきて設定だけしか変えないツールやそのまま使うソフトウェア製品（カテゴリ1と3）であってもバリデーション計画や報告、運用時の点検などは、使用者である製造業者側が行わなければいけない。

ツールやソフトウェアシステムが使われる場面、用途を知らないツールベンダーがツール認証を掲げるのとは、考え方がまったく違う。

ツールを含むコンピュータシステムのバリデーションを求めているのは、対象となる医薬品や医療機器の安全がコンピュータシステムによって脅かされないかどうかの確認であり、それを示すためには、どんなリスクが存在するのか特定しなければいけない。

どんなリスクがあるのかを知っているのは、ツールやコンピュータシステムを使う側なので、使う側がリスクに対して検証結果の有効性を確認する。一般的なソフトウェア開発プロセスに従って開発されていることを示したツール認証では、リスクを回避できることは証明できない。なぜなら、ツールを認証する際に、ツールを使用する側にどんなリスクがあるのかを想定していないからである。

例えば、モデルや高級言語からコードをジェネレートするツールがあったとしよう。それらのツールがツール認証を持っていたとして、バグが絶対にないかといったらそうではないし、ツール認証はバグがないことを保証している訳ではない。だから、ツール認証だけを安全の根拠にしてクリティカルなモジュールの開発には使えない。

だから、FAA もツール認証を止めたのだろう。（ It was found that many tool usage scenarios did not meet the constraints on tool use. )

じゃあ、ISO 26262-8 の「ソフトウェアツールの使用への信頼」が何を要求しているのか、キチンと読んでみよう。

ISO 26262-8 ソフトウェアツールの使用への信頼

11. ソフトウェアツールの使用への信頼
11.1 目的

この節の第一の目的はソフトウェアツールに対する信頼の要求水準を決めるための基準を提供することである。

この節の第二の目的はそのソフトウェアツールが ISO 26262 で要求される活動や、タスクのテーラリングに使用するのが適切であるという証拠を作成するための認定手段を提供することである。（すなわち、ユーザーは ISO 26262 で要求される活動やタスクのためのソフトウェアツールの正しい機能を信頼できる）

11.2 総則

システム、そのソフトウェア又はハードウェアエレメントの開発で使われるソフトウェアツールは、ISO 26262 によって要求される活動とタスクのテーラリングを通じて、安全性ライフサイクルのテーラリングを支援あるいは可能にすることができる。その場合、ソフトウェアツールが効果的に下記の目標を達成できるという信頼が必要である。

a) 誤った出力につながるソフトウェアツールの故障に起因する、開発された製品のシステマティックフォールトのリスクを最小にすること。

b) ISO 26262 によって要求される活動やタスクが、使用されているソフトウェアツールの正しい機能に依存するものであれば、開発プロセスは ISO 26262 に十分適合しうること。

備考："ソフトウェアツール"は、個別に使用されるスタンドアロン・ソフトウェアツールからツール・チェーンに統合された一連のソフトウェアツールまでを含むと考えてよい。

例：そのようなソフトウェアツールは、市販のツール、オープン・ソース・ツール、フリーソフトウェア・ツール、シェアウェア・ツール又はユーザーによって社内で開発されたツールでもかまわない。

上記の状況の下の開発で使用されるソフトウェアツールに対する信頼の要求水準を明らかに決定するために下記のような基準が評価される：

－機能不全のソフトウェアツールとそれにともなう誤った出力が開発中の安全関連アイテム又はエレメントにエラーをもたらす若しくはエラー検出ができないという可能性。

－その出力におけるそのようなエラーを防ぐ若しくは発見できることに対する信頼

防止または発見方策に対する信頼を評価するために、安全関連アイテム又はエレメントの開発プロセスに実装されるソフトウェアツールに対する外部からの方策（例えばガイドライン、テスト、レビュー）だけでなく内部からの方策（例えば監視）も考慮され評価されることができる。

決定されたツール信頼水準により必要と判断されれば、適切な認定方法はこのツール信頼水準とソフトウェアツールを使用して開発されることになっているアイテム又はエレメントに割り当てられるすべての安全要求の最大のASIL両方に適合するために適用される。その必要がなければ、そのような認定方法を適用する必要はない。

というのが総則の内容で、この後、次のような節が続く

11.3 この節への入力
11.3.1 前提条件
11.3.2 追加の支援情報
11.4 要件及び推奨
11.4.1 一般的な要件
11.4.2 あらかじめ定められたツールの信頼水準または認定の妥当性
11.4.3 ソフトウェアツールの評価基準またはその認定に対する遵守性
11.4.4 ソフトウェアツールの使用法の計画
11.4.5 分析によるソフトウェアツールの評価
11.4.6 ソフトウェアツールの認定
11.4.7 使用実績による信頼性の向上
11.4.8 ツール開発プロセスの評価
11.4.9 ソフトウェアツールの妥当性確認
11.4.10 ソフトウェアツール認定の確証レビュー

11.4.9 でソフトウェアツールの妥当性確認(Validation of the software tool)があるが、この内容なら、医療機器の世界ではValidation ではなく、Verificationになる。11.4.6 のソフトウェアツール認定の手法の中に、11.4.9 のソフトウェアツールの妥当性確認が推奨されているのだが、ツールベンダーや第三者認証機関が、そのツールを使う対象の Intended Use を知らないのに、Validation できるはずがない。

できるのは一般的なソフトウェア開発プロセス通りに作ってますよということの証明でしょ。それをクリティカルシステムに使用する際の信頼性の根拠（安全性の根拠でないことに注意）として胸を張られてもなぁと思う。

総則 a) の 「誤った出力につながるソフトウェアツールの故障に起因する、開発された製品のシステマティックフォールトのリスクを最小にすること。」を製品の Intended Use を考慮せずにやろうとしたら、検証は永遠に終わらない。「リスクを最小にする」というところがミソだ。リスクを最小にするということは、リスクは完全にはなくらならないということを示している。

医療機器ドメインでは、このような場合 「リスクコントロール手段によってリスクが受容できるレベルまで下がっていることを確認する(ISO 14971)」 となる。リスクを受容するためにはリスクとリスクを制御するための手段を特定しなければいけないが、システマティックフォールトのリスクと言ってしまったらそれはソフトウェアのバグのことになってしまう。バグの数を最小にせよというのは努力目標にしかならず、目に見える具体的なゴールにはなり得ない。

実際に、バグが一個もないツールなんてあるわけがないし、仮に一個あったとして、それがどんなことに影響するかはツールを作る側には分からない。

かつて、複雑なコンパイルオプションを指定して、特定のC言語のコードを記述すると、期待されないアセンブラが吐き出されるといったコンパイラの不具合通知を見たことがあるが、たいていの場合、そのような特殊な複合条件（例えばメモリ最小化オプションとの組合せ）で製品開発はしていないからセーフであることが多い。しかし、どこかのプロジェクトでそんな使い方をしている可能性はゼロではない。万が一、その不具合に合致した使い方をしていた製品がとても危ないところの制御をするソフトウェアだったら問題だ。

認証には保証を伴う場合もある。例えば日本の場合、医薬品の許認可をするのは国であり厚生労働省である。よって、認可した医薬品に問題があれば、国はその責任を負う。薬害エイズや肝炎訴訟では国が許認可に対する非を認め再発防止と被害者に賠償の責任を負った。だから認証する側も同じ問題を見逃してはいけないので真剣だ。

アメリカもすごい。会計検査院が 「FDA（食品医薬品局）の取り組みがなっていないから、認可した医療機器が問題を起こして国民が不利益を被っている」と平気で指摘する。

FDA が指摘に対してアクションプランとその進捗状況を公開しているので興味のある方は参照されたし。（こちら）

一方、ISO 26262 のツール認証はどうだろうか。ツールを認証した第三者認証機関は、そのツールの不具合が原因で問題が起こったときに、何らかの保証をしてくれるのだろうか。何かしらの責務を負って認証しているのだろうか。

自動車業界はツール認証も含めて、ISO 26262 の取り組みが、製品開発にどのように影響したのか、効果があった点、効果がなかった点、逆に品質向上に足を引っ張った点を今後振り返って情報発信する義務があると思う。

経営層にとっても規格適合に投入した金が、エンドユーザーの価値向上に貢献し、組織の利益にとってプラスに働いたのかどうかをいずれ検証しなくてはいけないだろう。

また、ツール認証をことさら強調するツールベンダーの人には下記のことを聞いてみるとよいだろう。

• 認証によって何が確認されたの？
• 認証によって何が保証されるの？
• ツールのバージョンが上がったら認証やり直すんですか？
• ツールの妥当性確認って何をやったの？
• ツール認証時の審査結果のサマリを見せてもらえる？

ISO 26262との向き合い方 (17) 安全機能の複雑性を分析する

最近、ISO 26262 の ASIL D に対応した○○を開発しましたとか、△△（ツールの名前）が ISO 26262 の認証を取りましたとか、ISO 26262 の適合支援をしますといったニュースリリースをよく見かける。

そのような喧噪をよそに、今回も複雑な安全機能に対してエンジニアはどう対処してけばよいのかについて書こうと思う。

さて、前回の記事『ISO 26262との向き合い方 (16) 安全を売りにすることの意味』の冒頭で取り上げた日産自動車が開発したという「緊急操舵回避支援システム」について掘り下げて考えてみる。（公開情報だけで考えているので想像している部分と現実とは違っているかもしれません。ブログでは特定の会社のシステムを評価したいのではなく、安全機能の複雑性について理解を深めたいだけなので、その点、誤解なきようよろしくお願いします。）

緊急操舵回避システムの分析

日産自動車が2012年10月17日に発表した日産のニュースリリース『日産自動車、「緊急操舵回避支援システム」を開発』は、よく読んでみると、まだ市販の乗用車への搭載の予定は書かれていなかった。実用実験の成果を発表した段階ということのようだ。

ニュースリリースを読むと、緊急操舵回避支援システムは1台のカメラ、3つのレーダー、5つのレーザースキャナを入力源として使っている。添付されいている資料によると、「前方衝突回避支援コンセプト」と「緊急操舵支援システム」が作動する一般的なシナリオは次のようなものが想定されている。（YouTubeによる動画はこちら。すごいです。）

【前方衝突回避支援コンセプト】

1. 対象物を検知・識別する。
2. ドライバーに警告を発する。
3. 緩やかな減速を開始。
4. 衝突に備えてシートベルトをきつく締める。
5. コンマ数秒後、システムが衝突回避の限界に近づきドライバーが自力で衝突を回避できないと判断すると緊急ブレーキを作動しはじめ、衝突回避動作を支援する。

【緊急操舵支援システム】

1. 対象物を検知・識別する。
2. ドライバーに警告を発する。
3. 物理的に回避可能な限界に近づきドライバーの操作は不十分と判断する。
4. ECUは緊急ブレーキと緊急ステアリングのどちらで対応するかを一瞬で決定する。
5. ステアリングが最適な措置の場合ハンドルを切ることが可能な方向をドライバーにモニタで知らせる。
6. その直後に必要な操作（緊急ブレーキの作動か、緊急操舵か、それらの両方）を正確に実行する。

資料には「考えられるすべてのシナリオでこのシステムを検証し、高い効果を確認した。」とあったが、シナリオは無限に存在するので検証が終わったと判断するのはなかなか難しいと思う。

記事をもとに緊急操舵支援システムの入力部と衝突リスクを分析判定するECUの関係を図に書いてみた。分析判定のECUはもしかしたら一個ではないかもしれないが、ここはシンプルに一つだと仮定した。

ちなみに、レーダーとは電磁波を照射してその反射波を受信するデバイスで、照射された電磁波は広範囲に広る。一方レーザーは直進性が高く探りたい方向に向けて首を振らなければいけない。だからレーザーの方はスキャニングする必要がある。レーダーよりはデバイスの内部構造が複雑になると想像する。

まず、これらの入力装置だけを考えてもこの安全機能の複雑性がうかがえる。1つのカメラ、3つのレーダー、5つのレーザースキャナはそれぞれ監視するエリアがオーバーラップしてはいるものの、各自持ち場、見張る方向、センシングの方法が異なるので、どれかが故障すると緊急操舵支援システムは期待通りの働きができない。

合わせて9つのセンサを使っていて、どれか一つが故障してもシステムは正常動作しないという状態を FTA で描くと左記のようになる。

どのセンサが故障してもトップ事象の「緊急操舵支援システムのセンサ入力が利用できない」に至るため各基本事象は OR で接続される。

仮に各部品の故障率が 0.0001（1万分の1）だった場合、トップ事象としての故障率は各故障率を足すため0.0009 となり、およそ10倍の故障率にあたる 1000分の1に近づく。

たぶん、現実はそんなに故障率は高くないだろう。1000万分の1くらいかもしれない。頻度の低い使用なら問題ないレベルだろうが、例えば自動車の場合は販売量が非常に多い。10万台売れて100回使えば、トータルで1000万回になる。センサの故障は無視できるレベルではないことが分かる。

なお、故障状態を検出する手段があれば、どれかのセンサが故障した時点で故障状態を表示して修理に出して欲しいとドライバーに訴えることになる。修理をしてもらえば確率は元に戻るから、この足し算は必ずしも現実的とは言えない。また、部品の故障率は自動車のライフサイクルに対して一定であるとも限らない。自動車が生産されて廃棄されるまでの期間が仮に10年だったとして最後の1年がその前の9年と同じ確率かどうかは分からない。部品の故障率がバスタブ曲線状に変わる場合、製造後10年経過したときの「緊急操舵支援システムのセンサ入力が利用できない」確率は上記の確率よりも高くなっているかもしれないのだ。だから、FTAにおける事象発生の確率が一人歩きしないように注意しなければいけない。FTA における確率は目安というか、分析者がどれくらいの故障率を考えているかの程度の意思表示のようなものだ。後述する Systematic Failures や Usability が絡んでくると Random Failures の確率はトップ事象の発生に対して影響が小さくなってくる。（部品の故障に気を配っても、ソフトウェアの不具合やユーザーの誤使用で簡単にトップ事象が発生してしまうようになるということ） FTA における確率は 1/100 か 1/1000 か 1/10000 かくらいのおおざっぱなことを示すことが多いような気がする。（厳密な測定結果に基づく場合もあるかもしれないが・・・）

よって、上記の FTA 図で分析者やレビューワーが認識すべきなのは、9つのセンサがトップ事象に与える影響が同等であるということだ。別な言い方をするとどのセンサが故障しても緊急支援システムの正常動作の障害になるということである。そのリスクを軽減するための手段として、Fault Tolerant (構成部品の一部が故障しても正常に処理を続行するシステム)の構成を考えることはできる。ようするに部品の故障を見越して同じ役割分担のセンサを複数設置するという考え方だ。故障率の低い高信頼性部品に頼らず、標準部品を並列に設置して信号出力の OR を取るという安全設計の方法は故障期間がわずかでもあるとまずいようなシステムで使われている。

このケースでは例えば、前方レーダーが故障したときのことを考えて、もう一つ前方レーダーを設置する。宇宙で簡単に修理ができないときは、そういう選択肢は大いにありうるだろう。しかし、自動車の場合、前述の例のように部品が故障したことが分かれば、ドライバーに異常を知らせ、販売店で修理をしてもらえるので、コストアップにもつながるし、このケースでは Fault Tolerant は採用されないと考えられる。

そうなると重要なのは各センサが故障しているかどうかを正確に判定できるかどうかだ。衝突リスク分析判定ECUに入力される情報だけでセンサの故障が判定できれば一番よいが、センサからの入力だけでは確実に判定できない場合、故障検出のためのハードウェアを追加しなければいけない。

上記のセンサ故障の FTA の図にセンサの故障検出デバイスの故障事象を追加して、トップ事象を「緊急操舵支援システムを故障状態で使ってしまう」にしてみた。センサが故障していても、ドライバーがそれに気がついていればリスクを減らせる。しかし、センサの故障検出デバイスが故障していたら、センサの故障を知らせることはできない。

それなら、センサの故障検出デバイスの故障を検出するデバイスを追加するかと考える。こうやって、リスクコントロール手段は追加すればするほど、リスクが具現化する確率を減らすことができる。（AND接続が可能となるため、確率はどんどん小さくなっていく。）

しかし、リスクコントロール手段を追加するたびにコストは上がるし、システムが複雑化する。システムが複雑になることにより新たな Hazardous Situation が生まれるかもしれない。設計者が恐れるのは前者よりも後者の方だ。アーキテクチャが複雑になるとシステムが完全に動作するかどうかの検証作業も増える。故障検出機能の検証のためには故障状態を再現しなければいけない。完成品ではなかなか再現できないから、劣化の加速試験やシミュレーションが必要になる。シミュレーション環境を準備したら、シミュレーション環境が期待通りに動いているかどうかを Validation（妥当性確認）しないといけない。もう、切りがないのである。

なお、ここまで書いたことは FTA が発明された 1960年代の分析とそれほど変わりはないと思っている。静的な構造ベースでの 故障解析はなんだかんだ言っても有限の場合分けにしかならない。複雑でもいろいろなケースを想定して積み上げていけば、トップ事象を起こさない確率を高めることはできる。

故障の原因が統計的な要因のみ、すなわち Random Failures だけならなんとかなる 。しかし、そこに、Systematic failures や Usability が絡んでくると問題はそんなに簡単ではなくなる。

機能の独立性が脅かされるということ

緊急操舵回避システムの制御モデルを描くとこんな感じかではないかと思う。ブレーキ制御やステアリング制御はこんなに単純ではないと思うが、まずはこの単純なモデルで考えて見たい。

さきほどは、センサ類の入力側のデバイスの故障について考えたが、緊急操舵回避システムでは「表示灯」「表示装置」「警告ブザー」といった出力系のデバイスも制御しなければいけない。

それぞれの出力デバイスの故障も入力系と同じだが、表示装置となるモニタはもしかするとTVやカーナビと共通で使用するかもしれないので複雑性はさらに増加する。

緊急操舵回避システムでは、緊急時のドライバーがどちらにステアリングを切ればよいかを指示する。その指示をドライバーが実行できないとシステムが判断したときに初めてシステムが自動でステアリングを操作する。

だから、表示装置で方向を指示しなければいけない。カーナビ画面に小さく赤い矢印を出したのでは気づかれないかもしれない。いったん画面を全部消してでかでかと矢印を表示しないといけないだろう。しかも滅多に表示されるものではないから、それが何を意味するのか瞬時に判断できるようでなければいけない。ドライバーが20代でも30代でも40代でも50代でも60代でも70代でも判断できなければいけない。人が絡んだ安全オペレーションを考えるときは、Usability の分析も必要になる。相手が人間になると、統計的な手法の信頼性は低下する。Usability 分析で有効なのは シナリオである。どんなユーザーシナリオを想定したのかを記録しておく必要がある。よく使われるシナリオ、最大負荷となるシナリオを分析段階で記録しておき、それをもとに作ったシステムで事故が起こったら、事故のシナリオを追加して再分析する。人間の行動には一貫性はないから、設計時に想定できないような振る舞いをされることは現実にある。したがって、このフィードバックサイクルを積み重ねることが Usability 起因のリスク対策には有効となる。だから、実戦経験のない機能を初めて市場に出すときは、 Usability 対策が未熟であることはよくある。

さて、緊急操舵回避システムとカーナビとTVで表示装置を共有したのなら、緊急操舵回避システムが他に対して優先順位が高くなければいけないのだが、期待通りに動いていることは誰が検証するのか。カーナビ屋さんが「オレには知ったこっちゃない」と考えていると、思わぬコミュニケーションギャップにより緊急時に画面が切り替わるかどうかのテストが漏れる可能性がある。リスクレベルが高いシステムとリスクレベルが低いシステムでデバイスを共有する場合は、そこにある意識の違いがミスを生む可能性がある。

それはそれとして、緊急操舵回避システムで最も大きな問題は機能の独立性が崩れることだと考えている。

左の図を見てもらいたい。かつて自動車はその基本機能である、ステアリング、ブレーキ、エンジン（加速）の機能は完全に独立していた。

それぞれの機能は他の機能を意識する必要がなく、各機能の信頼性を高めることに集中すればよかった。これはソフトウェアの構造化設計、オブジェクト指向設計の基本である高凝集(High Cohesion)、疎結合(Low Coupling) の状態である。高凝集・疎結合が実現できていると、開発チーム側の役割分担もしやすい。

また、この図で分かるように機能にトリガーをかけるのはすべてドライバーである。それぞれの機能が正常に動作していれば、ステアリングのミス、ブレーキの遅れ、アクセルとブレーキの踏み間違いはすべてドライバーの責任になる。（『ISO 26262との向き合い方 (16) 安全を売りにすることの意味』参照のこと）

その後、ステアリングもブレーキもエンジン・アクセル制御も ECUとソフトウェアが絡むようになって、ブレーキとアクセルが同時に踏まれたときは、ブレーキを優先させるという判定をECU内部で行うようになった。このことは、ブレーキ制御とアクセス制御のECUに間に結合が生まれたことになるが、この程度であれば非常に小さな結合で留まっていると言えるだろう。

それがプリクラッシュセーフティのように自動でブレーキを制御することになるとシステムの中に大きな結合ができてしまう。

衝突回避のための自動ブレーキなら入力はもっと少なくてもよいかもしれないが、それでも衝突リスクを分析・判定するシステムの複雑性は小さくない。

一番の懸念事項は運転手のブレーキ操作、ステアリング操作と衝突リスク分析判定ECUの判断が異なった場合はどうするかだ。

衝突回避のブレーキシステムの場合は、ドライバーがステアリング操作をした場合、緊急ブレーキは動作させない仕様だったと思う。この場合は、上記の図でステアリング制御ECUから衝突リスク分析判定ECUに向かう矢印が一本増える。それによって、ステアリング制御と衝突リスク分析判定機能は結合したことになる。

そして、緊急操舵支援となるとこのように結合度はさらなに強くなる。

ドライバーのハンドル操作やブレーキペダル、アクセルペダルの操作と衝突リスク分析判定ECUの判断が相反したときの問題もさることながら、刻々と変わる状況に対して、センサーからの入力やドライバーの操作、ブレーキかステアリングかといった複雑な判定が必要になる。しかも、その判断は時間毎に変えなければいけないのである。

部品故障に関しても、緊急事態でないときに故障が分かればよいが、仮に衝突回避の直前または回避中にセンサ類に異常が検出されてしまった場合、どのような対応をしなければいけないだろうか。

故障検出が割り込み処理で入ってくるのか、ポーリングなのかによっても状況は変わってくる。衝突リスク分析判定ECUが自分で故障検出デバイスをポーリングするようになっていれば、衝突回避動作中はポーリングをやめればテストケースは減る。（衝突回避動作に入ったらセンサの情報は使わないという設計にした場合）

しかし、割り込み処理だったら、衝突回避中だろうがなんだろうが割り込まれてきて、故障認識時の処理が意図せず動いてしまうかもしれない。衝突回避中だけは割り込みを無視するようなソフトウェア設計にすると、ソフトウェアアイテムの高凝集(High Cohesion)、疎結合(Low Coupling)が崩れてくる。そうなってしまったソフトウェアを完璧にテストしようと思ったら、すべてのタイミングで期待通りの動作するかどうか検証しなければならず、有限の場合分けができなければ永遠にテストは終わらない。

この記事の前半で、静的な構造に関する問題だけならば有限事象なので検証は時間がかかっても収束するといったのはこのことだ。静的な構造の要素だけでなく、時間によって状況が変わる事象を考えなければいけないとなると、シナリオはすぐに爆発し、検証作業が時間切れになる可能性が高まる。

3.11 の後に「想定外を想定する」といったキーワードをよく聞いたが、時間によって状況が変化してしまう場合、想定外はあるという前提でシステムを設計しないと事故は起こってしまう。「想定外を想定する」のではなく、「想定外が起こる前提で最も効果的な安全対策を考えよう」が正しいアプローチだと思う。

システマティック故障

これまでの話の中で、ソフトウェアの中の問題（=バグ）は考慮していなかった。しかし、9つのセンサの入力をリアルタイムに解析するとなると、解析の中には画像解析も含まれる訳だから、ソフトウェアの複雑化は避けらず、バグがまったくない状態にするのは相当難しい。ソフトウェアの内部構造を高凝集・疎結合にする努力はしたとしても、メモリリークなどがあるとその影響は他に伝搬してしまうし、仕様変更や不具合対策でソフトウェアを変更するとそれによって新たなバグを生む可能性もある。

ただ、だからといってツールや開発プロセス、各デバイスの高信頼性化だけに着目するのは木を見て森を見ずであると感じる。もっと上位層、要求仕様や安全やリスク分析の中で考えるべき問題、抽象化できない具体的なリスクやハザードに対するリスクコントロールについて考えることが遙かに重要である。抽象論ではなく、具体的なリスクを前にして、そこに対処することがシステムやユーザーの安全への寄与が大きいということを安全設計をするエンジニアは忘れてはいけない。

機器製造業者としては複雑な安全機能を追加しないことによってシステムのアーキテクチャをシンプルにし、テストケースを減らして、システム全体で安全性や信頼性を高めるという選択肢もあるのだ。安全機能を追加しない方がユーザーへの利益が大きいケースはあると思っている。

複雑な安全機能はソフトウェア設計者としてもイヤな感じがするが、安全システム設計者としてシステム全体を見なければいけない立場だったら、そのイヤな感じは増大する。

それは、ソフトウェアの世界で凝集度が低く、結合の強いソフトウェアの集まりが起こす、原因が非常に分かりにくい不具合の数々をこれまで見てきたからそう思うのかもしれない。

そのようなシステムで頭を悩ませてこなかった人たちは、独立性の高いハードウェアを組み合わせることで、多少複雑性が高くなっても、付加価値が高まればよいだろうと考えているのかもしれない。

いったん複雑なシステムを作ってしまうと、予防・是正の取り組みを繰り返しただけでは追いつかない場合がある。変更によって新たな不具合を作り込んでしい、負のスパイラルに陥ってしまう可能性があるからだ。複雑な安全機能にさらなるリスクコントロール手段を追加すると、それによって新しい Hazardous　Situation が生まれる。

Random Failures, Systematic Failures, Usability に絡む問題がそれぞれ独立して考えられるのなら、そのようなアーキテクチャを選択した方が絶対にいい。この3つの要素が絡み合うシステムを作ってしまったら、後が大変で、ブログで解決方法を解説するレベルではなくなる。

実際の自動車制御はこんな単純なものではないことはわかっている。だからこそ、独立した機能同士の結合を弱くしておく努力の重要性を感じる。そこを崩してしまうと際限がなくなる。付加的安全機能は際限をなくしてしまうトリガーになるような気がするのである。

どんなに複雑でも、どうせソフトウェアで制御するなら一つの高性能なECUにやらせてしまえという考え方が出てくると、1980年代に医療機器の世界で起こった Therac-25 の事故が、自動車ドメインでも起きるかもしれない。

ISO 26262との向き合い方 (16) 安全を売りにすることの意味

2012年10月17日 日産自動車が回避支援を行う「緊急操舵回避支援システム」を開発したことを発表した。（日産のニュースリリース『日産自動車、「緊急操舵回避支援システム」を開発』）

緊急操舵回避支援システムとは（ニュースリリースから引用）

このシステムは、ブレーキでは衝突を避けることが難しい状況において、障害物に衝突しそうになった際、自動ブレーキだけでなく自動操舵も行うことにより、高度な回避の支援を行うシステムです。低速域での急な飛び出しのような予測できないリスクが発生した場合、また、ドライバーの認知の遅れにより高速で渋滞末尾に追突しそうになった場合などにその効果は発揮されます。

スバルのプリクラッシュセーフティシステムは自動ブレーキをかけるシステムだったが、日産の緊急操舵回避支援システムは、自動ブレーキに加えて自動でハンドルも切って衝突を回避するシステムとなっている。

このニュースを見たとき、自動車業界は「こっちの世界に来たな」と思った。こっちの世界というのは、ソフトウェアエンジニアが製品やシステムとユーザーとの間に立って安全を確保が脅かされる恐怖に立ち向かい、そして不幸にして事故や事件が起こってしまったときの再発防止に取り組む責任を負わなければならない世界のことだ。

自動車メーカーの経営層は「安全を売りにすること」の重みについてまだ実感がないと思う。その重みは事故・事件があっちこっちで大小さまざま起きるような環境になったときに初めて感じることになる。

先進国の自動車メーカーは自動車の本質的な機能や性能、見た目のかっこよさ、価格などではもう他社と差が付けられなくなってきたのだろう。そこで、安全を売りにしようと考えた。スバルがEyeSightで大々的に宣伝を始め、その後各社ともプリクラッシュセーフティシステムを市販車に搭載し、日産がさらに機能を追加した。そうなると、安全機能での競争は止まらなくなり、安全機能の複雑化が加速する。

市販車に搭載済みの自動停止まで行う衝突防止装置(Wikipedia より)

2008 - ボルボ・シティ・セーフティ
2010 - スバル・アイサイト
2011 - フォルクスワーゲン・シティエマージェンシーブレーキ、ボルボ・ヒューマン・セーフティ、メルセデス・ベンツ・PRE-SAFEブレーキ
2012 - マツダ・スマート・シティ・ブレーキ・サポート、BMW・ドライビング・アシスト・プラス、トヨタ（最高級車レクサスのみ衝突回避する）・衝突回避支援型プリクラッシュセーフティシステム

リスクマネジメントがとてつもなく多様化しているクリティカルデバイスの開発の世界にいて感じるのは、安全のためにもっとも効果があるのはシンプルなアーキテクチャだということだ。自動車業界は安全のためと言いながら、最初は安全機能は単純だったのに、その後わざわざ安全機能を複雑化させ、安全を脅かす方向に向かおうとしている。

安全機能の複雑化に伴うリスクと対策については次回以降に書こうと思う。安全機能を複雑にするリスクと共に非常に大きな問題は、安全機能を自動車の付加価値にしたことで、事故・障害が発生したときの責任についての社会の見方が変わるということだ。

• 運転手がブレーキペダルを踏んでその圧力を油圧で伝達しブレーキパッドをプレートに押しつけることで摩擦によりタイヤを制動する。
• ハンドルを傾きをタイヤの向きの制御に変換する。

こういったシンプルな構造で自動車の機構が成り立っているときに発生する事故の責任は運転手にあった。このことは社会通念上、誰もが認識していることであり、口を挟むものはいない。ブレーキとアクセルを踏み間違えたり、居眠りしたり、ハンドル操作をミスした責任は運転手にあると考える。

そして、時代は変遷し、パワーステアリングやABSなどの機能が自動車に付加されるようになり、ハイブリッド車や電気自動車が出てきたことで、ブレーキやハンドル操作のメカニズムはすでにシンプルではなくなっている。

だから、正確には「こっちの世界にようこそ」は何年も前に起こっていた。しかし、これまでは自動車の安全機能はキチンと動いて当たり前だったし、自動車メーカーやサプライヤも安全・安心の堅い信用を守り通してきた。だから、自動車の内部システムが複雑になっていても自動車事故が起こったときに事故の責任は運転手にあると未だにみんなが認識しているのだ。

当たり前品質はシステムが正常に動いているときは、誰もその機能や性能について関心を持たないし、ありがたみも感じない。だから当たり前品質を提供する側がシステムを正常に動かしている限り、事故の責任は運転手にあるという社会的なコンセンサスは変わらない。

しかし、プリクラッシュセーフティシステムや緊急操舵回避支援システムは、どの自動車メーカーも実現している当たり前品質ではなく、自分達しか実現できていないユーザーに対する付加価値だ。ユーザーは他社にはない差別化された安全機能を目当てにその車を買うのだ。

安全機能を売りにして差別化を図った自動車メーカーは禁断の果実に手を出したようなものだと思う。安全を売りにした以上、そこに問題があることは許されない。そこに問題があった場合の社会に与えるマイナスの印象は非常に大きい。リスクの大きい賭けとなる。医療機器の場合、装置が与える効果効能と安全・信頼を確保するためのリスクは表裏一体であり、エンジニアもそういうものだと思ってこの世界に入ってくる。社会への貢献度も高いがその裏に大きな責任やリスクがあることも分かってこの仕事を選んでいる。

自動車業界のエンジニアはどれくらいそういう感覚を持っているのだろうかと思う。ブレーキを作っているサプライヤのエンジニアはその責任の重さを認識しているだろう。でも、複雑な安全機能を複数のサプライヤで分担したり、異なる専門の技術者が協力して安全機能を開発したときに、安全に関する責任やリスクについてメンバー全員が同じような感覚を持てるかが疑問だ。システムが複雑化すると「それは俺たちの担当じゃない」という場面が増えてくる。その台詞に言葉では言い表せない恐怖を感じるのは品質保証担当やプロジェクトリーダーであり、経営者ではない。

さて、安全に関する機能がシステムに隠れていて正常に動作している間は、社会は事故の責任は運転手のミスと認識する。しかし、安全機能をシステムの付加価値にして表に出し、それを顕在的な価値（=カタログスペック）として他社との差別化に使って、安全機能の不具合が原因で事故が起こった場合、責任は自動車メーカーにあると誰もが考える。

自動車メーカーが安全機能を売りにすることの最大の経営上のリスクは、実は複雑な安全機能システムに内在するソフトウェアのバグではない。発生した事故の原因が安全機能の不具合なのか運転手の運転ミスなのかはっきりと切り分けができないことが自動車メーカー自らが新たに抱えることになった最大のリスクなのである。

アメリカ人なら発生した事故が運転手のミスではなく、プリクラッシュセーフティシステムや緊急操舵回避支援システムが正常に動かなかったからだと訴訟を起こすことは必ずあると思う。一回でもユーザー側が勝訴すれば後に続く人は増えるだろうし、そんなことが続けばよかれと思って他社と差別化を図るために付けた安全機能は一転してメーカーのマイナスイメージになりかねない。

それを見越して自動車メーカーは飛行機のフライトレコーダーのような事故が起こったときにどのような制御がなされていたのかを記録するデバイスを搭載しているだろう。ようするに表では新しい安全機能によりドライバーの安心に貢献していますという顔をしておきながら、裏では事故が起こったときに「安全機能には問題がありません。」「悪いのは運転手です。」ということを証明するための証拠を集めながら自動車は走っているのだ。（事故の再発防止のためにはログの収集は必要であり、この表現はこういう見方もあるよという意味。）

しかし、事故が起こったときに自動車メーカーが「安全機能には瑕疵がない」と主張するのは事故の当事者以外に対しても極めて印象が悪い。なぜなら、自動車を売るときだけはプラスのことだけ宣伝しておいて、事故が起こったとたんに守りに入る姿が不誠実に映るからだ。

安全機能が当たり前品質として、また、潜在的価値としてシステムの内部に隠蔽されていたときは、事故の責任は運転手にあると社会は認識しているが、自動車メーカーが安全機能を表に出して顕在的な価値として大々的に宣伝し始めると、事故が起きたときの責任は自動車メーカーにもあるという認識が社会全体に生まれる。このことを自動車メーカーの経営層は実感していないだろうと思っている。自動車メーカーの経営者は技術者に「そんなことがないようにしろ」というだけだ。リスクマネジメントによってあらゆる問題に対して対策を取り、それらのリスクコントロール手段が確実に動くようにすることがいかに難しいか実感があるわけもない。

こういうときメーカーは問題が起こったときの防衛線を張ろうとする。それが、スバルのEyeSightのコマーシャルに現れている。スバルのEysSight のCMの一番最後にチラッと白地の画面に注意書きのようなものが表示されているのにみんな気がついているだろうか。「こっちの世界」にいる者として、ここに安全機能が期待通りに動かないときの注意が書かれていることは分かっていたが消えるのが早くて読み取れなかった。

そこで、You Tube でお目当てのCMを探して問題の部分を静止して文言を読み取ってみた。書いてあることはこうだ。

EysSight(ver.2)はお客様の安全運転を前提としたシステムです。道路・天候等の条件によっては衝突を回避できず、減速による被害軽減になる場合があります。
詳しくは最寄りのSUBARU販売店にお問い合わせください。

「衝突を回避できず、減速による被害軽減になる場合がある」は言い換えると「衝突回避は完全ではなく、減速するだけとなって怪我をすることもあります」であり、また、運転手が安全運転をしていなかったら衝突回避できないかもしれませんと言っている。

EyeSight（アイサイト）クイックユーザーガイドにはもっと直接的な注意文が書かれている。

EyeSight（アイサイト）は自動運転／自動衝突回避システムではありません。EyeSight（アイサイト）を過信せず、交通環境に注意して安全にご使用ください。ご使用の前には必ず取扱説明書をお読みください。

CMの注意文が表示されている時間はストップウォッチではかったら0.8秒だった。0.8秒では注意文を全部読めないから、この注意文表示は後で何かあったときに「一般の方にもCMで注意喚起しています。」という既成事実を作っておきたかったのだろう。ちなみに、フォルクスワーゲンの「シティエマージェンシーブレーキ」のCMでの注意文も同様に読み取れないくらい早く消える。

左の図を見て欲しい。システムに問題が起こったとき（自動車の場合は事故が発生したとき）青い部分がメーカーの責任で赤い部分がユーザーの責任である。使用者から見たときの通常使用の範囲とメーカーから見たときの誤使用の範囲が重なっているのが分かるだろう。

ここがグレーゾーンであり、メーカーとユーザーの認識のギャップとなる。メーカーとユーザーの間の安全に関する認識のギャップはメーカーがユーザーにどのような事前注意を求めているかで推し量ることができる。メーカーはユーザーが勘違いしそうなことについては、ユーザビリティ分析を行いできるだけ設計上の対策で回避しようとするが、設計上の対策でも防ぎきれない場合は注意喚起によりリスクを軽減しようとする。

しかし、ユーザーはメーカーサイドが表示する注意喚起を気にしてくれるとは限らない。この図は機器のユーザビリティに関するリスクマネジメントの判断基準を説明するときのものだが、原因がはっきり分からない場合の事故でも同じで、いったん事故が起こればユーザーはメーカーの責任を拡大解釈し、メーカーサイドの瑕疵の可能性を徹底的に追求する。

自動車は免許証を持った人しか扱えないが、一般的な運転の技術しか学んでいないし、機器を扱うスペシャリストではないから、基本機能以外の部分で起きた事故の責任はよりメーカーに強く求めるだろう。

また、リスクに対する意識は時間が経つにつれてメーカー責任の範囲が広くなる方向に動く。初めて導入された画期的な安全機能は仮に問題が起こっても「新しい技術だから」ということでユーザーサイドも割り引いて考えてくれるとこもあるかもしれないが、正常に動いて当たり前という状況、時代になった場合、責任はメーカー側に強く求められるようになる。リスクに対する意識は時代と共にメーカーにとっては厳しい方向に動くのである。

では、リスクマネジメントはどこまでやればよいのあろうか。それは、左図にあるように、意図した使用目的に基づき、世間の常識、他社の状況を参考にし、そのときに考えられる使用条件（シナリオ）をベースにリスク分析をするのだが、ここまで述べてきたように自動車の安全機能を表に出したのは「付加価値」であり「商品価値」にしたことになるので、リスクマネジメントの要求レベルはさらに高くなっている。

際限のないリスクマネジメントが辛くなり、時間切れになると、警告や注意文といった表記上の対策で逃げようと考えるようになる。

上記の注意文がその典型的な例だが、実際に事故が起きて裁判になったとき、事前に注意喚起をしたことが有利に働くとは言い切れない。なぜなら、社会通念上、自動車の運転者が取扱説明書をじっくり読むとは誰も思っていないからだ。ユーザーが注意喚起を認知する努力をどれだけしたのか、ユーザーが実質的にどれだけ認知していたのかは裁判でも争点になる。刑事責任を逃れたいのならば、契約書を交わすのが確実だ。これは笑い話ではなく、自動車の付加的安全機能を使う際に契約書にサインする時代は必ず来ると思っている。

ちなみに、契約書にサインさせても民事裁判では負ける可能性はある。日本では生命保険の契約内容が保険加入者に伝わっておらず、保険金が払われていない実態が問題視され、きちんと説明するように生命保険会社に行政指導が行われた。

たとえ契約書にサインしても、ユーザーが書かれている内容を理解しないでサインさせた場合、メーカーの社会的責任は免れない。

だから、注意文をCMで0.8秒間だけ表示する行為はPL（製造物責任）の対策にはなっていないし、リスクコントロール手段にもなっていない。逆に不誠実さをさらけ出しているだけのように感じる。

安全を売りにするということは、こういったことをすべてひっくるめてリスクマネジメントできているという自信があるということだと思う。

エンジニアが絶対やってはいけないのは、設計上の対策でできることがあるのに、権威を笠に着た言い訳やユーザーへの注意文を取扱説明書に書いて、安全に対する責任から逃れようとすることだ。（権威に傘を着るというのは ISO 26262 への適合証明をもって安全が確保できていると説明すること）

日産の緊急操舵回避支援システムを FTA で分析したらどうなるか、アーキテクチャ的にどんなリスクが想定できるのかまで書こうと思ったのだが、安全機能に対する考え方の解説だけで終わってしまった。複雑な安全機能をいかにユーザーに安全に使ってもらうかについては、今後我々が乗り越えなければならないハードルであることは分かっているので、次回以降に書こうと思う。

知られたくない部分を隠しながら、安全機能のプラスの面だけを強調しておいて、実際に事故が起きると言い分けを始めるのでは、3.11 の教訓がまったく活かされていない。安全は静かに硬く実現するものであり、派手派手しく前面に押し出すものではないと個人的には思っている。

P.S.

自分は『機能安全』という言葉がどうしても好きになれない。機能と安全はくっつけるべきものではないと思う。緊急操舵回避支援システムは間違いなく安全のための機能だが、安全のために本当に必要かどうかは緊急操舵回避支援システムの効果効能が緊急操舵回避支援システムに不具合が起きるリスクを上回かどうかの判断で決まる。安全機能のシステムが複雑になるとソフトウェアによるシステマティック故障が起こる可能性が上がってくるので、安全機能の御利益がリスクを相当上回らないといけない。付加した安全機能があってもなくてもよい程度のものであると効用よりリスクの方が大きくなる。リスクの重大さを考えて効用の方を切るという判断もあってしかるべきだと思う。リスク効用分析が十分でなく、効用の方ばっかりに目が行くようになると危ない。機能安全という言葉はリスクの存在はあってもしようがないという前提で、効用の方に注目を集めようとする言葉のような気がする。『機能安全』は主役がリスクによって危害を被るユーザーではなく、安全機能を提供する機器製造業者側の視点の言葉になっていないだろうか。


11月14日からパシフィコ横浜で開催されるET2012 のプライベートカンファレンスの 「組込システムの安全性と信頼性 ～ISO26262の認証証明だけで本当に安心できますか？～」のコマで、「市販ソフトウェアの信頼性検証」についてのプレゼンをします。（時間60分）

これは、OTS(Off The Shelf Software:商用で即利用可能な市販ソフトウェア）をクリティカルデバイスで使用する際には、どんな検証を行い、どのように検証記録を残すべきか、どうすれば根拠のある信頼性の説明となるのかについて実例を使って解説するものです。サブタイトルの～ISO26262の認証証明だけで本当に安心できますか？～は、ISO 26262 の適合証明は信頼性の根拠として説得力がなく、対象物の何をどうやって検証したのかを説明できるようにすることが重要であるという想いから付けました。

ET2012 プライベートカンファレンス 「市販ソフトウェアの信頼性検証」

プライベートカンファレンス
IARシステムズ株式会社＆イー・フォース株式会社

11月14日(水)　10:00～16:45
会場：会議センター4F［414＋415］
10:00～11:45 PIA-1 組込システムの安全性と信頼性 ～ISO26262の認証証明だけで本当に安心できますか？～

ISO 26262との向き合い方 (15) FTAを描いてみる1

今回は、FTAを描くときの注意点、特にソフトウェアが原因となって障害が発生する場合について考えてみる。

自分はFTAを描くときに Enterprise Architect というUMLツールを使っている。FTA だけでなく、ソフトウェアはモデルを描いて分析しなければ全体を俯瞰できないところまで規模が拡大し複雑性が増している。

しかも、モデルはプログラムと同じで一回描いたら終わりということはない。ソフトウェア開発の上流工程である要求分析からアーキテクチャ設計、詳細設計まで頻繁に書き換えるし、テストしながらモデルの問題に気がついて直すこともある。

だからそこモデルは容易に変更が可能で情報を共有したり場合によってはドキュメントとして印刷できるようになっていた方がよい。

そういった背景があってUMLのモデルを描くのに Enterprise Architect を使っている。Enterprise Architect はバージョン9.3以降でインストーラにFTAの作図機能が同梱されており、すべてのエディションで後から追加して利用できるようになっている。

FTAの作図

Enterprise Architect を提供する、スパークスシステムズ・ジャパン のサイトにFTAの作成について解説があるので、そこから少し引用したいと思う。

【FTA作図の要素】

事象		トップ事象あるいは中間の事象。他の事象の組み合わせで表現される。
通常事象		通常の状況で発生する事象。
基本事象		展開不可能な、基本的な事象。展開することはできない。
否展開展開事象		現時点では展開できない事象。追加の情報取得や状況の変化などにより、将来的に展開可能になる場合がある。展開することはできない。
移行記号		図を分割する場合に利用する記号。
ANDゲート・ORゲート		上位(上)の事象と、複数の下位(下)の事象の関係を示す。ANDゲートは、下位の全ての事象が発生すると上位の事象が発生する。ORゲートは、下位の少なくとも1つが発生すると、上位の事象が発生する。 (ANDゲートは、下位の事象の発生確率の積が、上位事象の発生確率となる。ORゲートは、下位の事象の発生確率の和が、上位事象の発生確率となる。)
制約ゲート・条件		事象に発生条件がある場合、その条件を明示するためのゲートと要素。 (下位の事象の発生確率と条件の確率の積が、上位事象の発生確率となる。)

【FTAの特徴】

FTAの特徴はある事象が発生するための要因を複数描くことができ、しかもその要因がANDの要因で発生するのか、ORの要因で発生するのかを図で表せる点にある。

描いてしまえばどうってことない図だが、1961年当時ミニットマンミサイルをなんとしても固体燃料で飛ばしたいという意志とベル研究所のH・A・ワトソンのグループのアイディアがこの表記法を生んだのである。その歴史を踏まえつつ、ありがたく使わせてもらおう。

さて、上記の図で○の基本事象はこれ以上展開できないということをしてしており、長方形の事象を起こす要因は別にあると考えられるためさらに展開が可能だ。だから、FTAはトップから下に向かって広がっていく。その様が故障の木：Fault Tree と表現されているのである。

FTA の特徴として、このように各事象の発生確率を追記することができる。 Enterprise Architect はこの確率を自動的に計算する機能もある。

ここで気をつけて欲しいのは、FTAの事象の発生確率は一人歩きしやすいという点だ。

モデルに数値が追加されるととたんにもっともらしくなって、例えば論文などに好んで使われるようになる。

自然科学の場合は論文に記された数字は裏付けとなる根拠が求められる。しかし、品質工学、情報工学で示される確率の数字はあてにならない場合があるので鵜呑みにしてはいけない。

FTA で事象の確率を記載できるようにしたのは画期的ではあった。ORゲートで結合されている事象の場合低い確率の事象と高い確率の事象があれば、高い確率の事象の発生を抑える対策を取った方が、トップ事象の発生確率を低くできるはずだ。

議論を進める前に、ここで Random Failures （ランダム故障）とSystematic Failures/Faults  （決定論的原因故障/障害）の違いをおさらいしておきたいと思う。

■Random Failures （ランダム故障）

• 構成部品・機器などの多様な劣化のメカニズムの下で時間的に無秩序に発生する故障。
• 故障率を計測することで統計的に品質を管理する。
• まず、ランダム故障は故障率が計測できる故障だから統計的に管理できる。だからこそ、統計的品質管理論によって品質を高めることができる。

■Systematic Failures/Faults  （決定論的原因故障/障害）

• ハードウェアの設計に起因するもの、ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率の予測が難しい故障/障害
• 出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
• 開発のプロセス（工程）、ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し、検証や妥当正確認によって発見・除去する。

FTA で事象の発生確率を論じることができるのは、事象が Random Failures のときだけだ。Systematic Failures が要因であった場合、発生確率を論じるのは極めて困難だ。例えば、滅多に通らないパスで NULL ポイントを使っていて、そこを通ると過大なエネルギーが照射されて患者が火傷を負うとする。

一万回ユーザビリティの実験を実施して一回のみオペレータがその滅多に通らないパスを通るような条件で操作をしたとしよう。この場合、この Systematic Failure が起こる確率は一万分の一と言えるだろうか。その希な操作を好んで実施するオペレータがいた場合、Systematic Failure の起こる確率は高くなる。

この問題は、製造業者とユーザーの心理的な感情そして、技術者の倫理に関わる問題なのだ。Systematic Failures の場合、問題のある箇所のソフトウェアを修正すれば永久にその不具合の発生を防ぐことができる。それができるのに発生確率が低いという論理で、既知の不具合を放置することは、事故が起こってしまえばユーザーは製造業者を許さないだろうし、技術者の倫理的観点から見ても許されることではない。

機器製造業者は Systematic Failure が発生するまでは、 Systematic Failure を生み出す可能性のあるバグを作り込まないまた、摘出する努力（さまざまな品質向上活動やマネジメント）を最大限したかどうかを問われるのだが、一度でも重大な Systematic Failure につながるバグを見つけたらすでに市場に出回っているソフトウェアも含めて確実に修正しなければいけない。 Random Failure の場合は、その確率の低さを根拠に修正しないという選択肢もあるのでその点が最大の相違点である。

したがって、 Systematic Failure に起因するリスクを考えるとき、一般的にはリスクの Severity（重大度）のみを評価し、Probability（発生確率）は1と置くのである。ようするに、Systematic Failure に起因する障害により事象が発現する可能性があるのであれば、事象の発生確率を担保に安全対策を取らないという選択をしてはならないのである。

1980年代に事故を起こした放射線治療器 Therac-25 の開発では「コンピュータが誤ったエネルギーを選択する」が発生する確率は 10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっていた。

「コンピュータが誤ったエネルギーを選択する」と「コンピュータが誤ったモードを選択する」は、正確に言えば、「ソフトウェアが誤ったエネルギーを選択する」と「ソフトウェアが誤ったモードを選択する」となり、これらは Systematic Failure が要因になりうるので、確率は10のマイナス11乗、4×10のマイナス9乗どころか1と考えなければいけない。

結局、コンピュータをハードウェア部品と考えランダム故障しかしない部品としたことが、そもそもの間違いだ。自分は Therac-25 の FTA が 1980年代という古い時代のものであったとしても、たましいの入っていない分析になっていたと思っている。 Therac-25 が人を簡単に殺せるような巨大なエネルギーを照射できることがエンジニアの頭に残っていれば、このような分析にはならなかったのではないかと思う。

FTA における事象の発生確率を見るときには二つのケースがあり、二つの視点が必要だ。一つは相当な根拠があり発生確率を考慮してもよい場合、もう一つは、発生確率に再現性の裏付けがなく、「まあ、そんなもんだろう」という程度で数字を見ないといけない場合だ。

クリティカルな事象を検討するとき、発生確率に統計的な裏付けがある場合は、FTAのダイアグラムにノートとして事象の発生確率の根拠を書き示しておくとよい。

ところで、FTA の事象の要因が Random Failures だったとしてもその発生確率を過大評価するのは危険だと思う。

例えば、事象の発生要因がハードウェア部品の故障だったとしよう。ハードウェアの部品故障ならば、統計的に発生確率を計算できるし、その値もそれなりに信頼できるだろう。しかし、その部品を高信頼性部品としてシステムのクリティカルな部分に使う場合、本当にその確率の数字を信用していいのかよく考えて見る必要がある。

ハードウェアの部品の故障は Random Failures だといっても、さいころを振ったときの1の目がでる確率のようには起こらない。

部品の故障率が時間とともにバスタブのように変化することはよく知られている。初期故障期間では故障の発生確率は高く、その後故障率は一定になり、耐用寿命を過ぎるとまた故障率は高くなる。

FTA に使われる確率はバスタブ曲線の偶発故障期間の値だろう。しかし、システム導入初期また、耐用寿命を過ぎてからの高い故障率は考慮しなくてもよいのだろうか。耐用寿命を超えてもシステムを使い続けて事故が起こった場合の責任はユーザーにあるのだろうか。
40年を耐用期限としている事故が起こると甚大な被害を及ぼす機器の使用期限を延ばしたときに、FTAに使った確率は変わらないのだろうか。

また、Random Failure の部品であっても、バスタブ曲線のような変化をしないものもあるだろう。そう考えると FTA における事象の発生確率は確率が低いからといって決して過信してはいけない。

ランダムかシステマティックかといったことではなく、ソフトウェアの品質向上に関する方法論を適用して、従来より○○%向上したという記述をよく見かけるが、その数字も自分は信用していない。人間の活動を評価しようと思っても、技術者のソフトウェア開発という活動が統計的な母集団を持つとは思えないからだ。癖のあるやつは常に癖があるし、慎重な者でも体調が悪ければミスを犯す。人種や組織文化などにも影響を受ける。

同じプロジェクトにならその数字もある程度再現性はあるのかもしれないが、他の組織や、他の業種、他の国で同じ結果がでるかどうかはわからない。

だから、FTAはトップ事象をどうしたら起こさないで済むか、製品やシステムをエンドユーザーに安全に使ってもらうことができるかを考えるエンジニアの「品質を心配する意識（Awareness: Worrying about Quality）」が良い解析ができるかどうかを左右すると思う。

ISO 26262との向き合い方 (14) FTAとFMEAの歴史

ISO 26262の世の中の動きをウォッチしていくこと自体にいささか疲れてきた。正直言って、本当にユーザーのことを考えて安全や安心を実現したいのなら、自動車業界の規格適合に関する浮かれた熱が冷めるのを2～3年待った方がよいと考えるようになってきた。若しくは機能安全に群がる商魂たくましい人たちとは一線を画して、クリティカルデバイス、クリティカルソフトウェアに役立つことは何かに集中していくかだ。

今回は後者を選択して、FTAとFMEAの歴史を調べてみたいと思う。リスク分析のツールとしてFTA,, FMEA, HAZOP などいろいろあるが FTA と FMEA は特に歴史が古い。

FTA や FMEA がそもそも軍事産業から開発されたことは何となく知っていたが、今回、Wikipedia などで調べて改めてその歴史的背景を知ることで、いろいろ思うことがあった。

FTAの歴史

FTAとは、Fault Tree Analysis （フォルトツリー解析）の略で故障・事故の分析手法の一つだ。フォルトツリーというくらいだから、左のような感じで木のように上から下に向かって広がった形になる。

Fault（不良、傷害）が発生する要因を論理的にたどり、望ましくない事象がどのようなメカニズムでまたどのような発生確率で起こるのかを論理的に分析する方法だ。望ましくない事象に対してその要因を探るトップダウンの解析手法で、FMEA（故障モード影響解析）とは逆のアプローチだと言われている。

個人的には、FMEAは既知の問題の再発防止に有効であり、経験を積み重ねていくほど発散しがちであるのに対し、FTAはどうしてもこれだけは発生させたくないという事象に対して、何を押さえなければいけないのか、どんな故障を考慮すべきなのかを分析する集中思考型の手法だと思っている。

さて、FTAの歴史の話を戻そう。FTAは、1961年にアメリカで開発されたミニットマンミサイルの信頼性評価・安全性解析を目的として、その協力先であるベル研究所のH・A・ワトソンのグループが考案し、その後ボーイング(BOEING)社により完成された。

Wikipedia で解説されている FTA の歴史の解説はこんなもんである。ここから歴史的背景を掘り下げていく。1961年と言えば、米ソ冷戦のまっただ中の時代だ。ミニットマンミサイルはアメリカが開発した大陸間弾道ミサイルで、1962年にミニットマン I、1965年に ミニットマン II、1970年にミニットマン IIIが配備された。核弾頭も搭載できる。ミニットマン IIIの全長は18.2m, 重量は35トン、価格は700万ドル、日本円なら一機およそ5億6千万円だ。

ミニットマンミサイルが開発される前は液体燃料ロケットであるアトラス及びタイタンが配備されていた。アトラスやタイタンは酸化剤に液体酸素が用いられており、発射直前に酸化剤注入の必要があリ著しく即応性を欠き、また電波による初期誘導を行なう方式であったため、全弾発射に長時間を要した。

さらに、アメリカ空軍はタイタンⅡミサイルの毒性の非常に強い推進剤が金属部品を腐食して燃料漏れ事故がたびたび発生し、死傷者が出て、そして維持管理費が高いことに悩んでいた。

そこに海軍がロッキード社の潜行中に潜水艦から発射できる固体燃料式ポラリス核ミサイルを配備したことで、危険な点検作業など運用コストのかかる液体燃料方式でなく、燃料漏れが起きない固体燃料を入れたまま長期保存ができ、整備、点検作業が不要でコストも安い、ミニットマン核ミサイルをボーイング社に開発させ、地下サイロのタイタンミサイルをすべてミニットマンミサイルに交換した。

これにより、冷戦時代の米国は当時、ソ連に対して核戦略で優勢に立った。なぜなら、ソ連のミサイルはすべて液体燃料方式で大型だったため、地下サイロの建設コストが膨大で、さらに整備、点検作業の運用コストに悩んでいたからだ。その当時、ソ連は大型固体燃料ロケットを製造する技術が未熟で、さらに固体燃料ロケットには、その振動に耐える集積回路の半導体電子回路で構成された誘導コンピユータの技術がなかった。

左が、固体燃料ロケットが発生する強烈な振動や加速度で故障しない頑丈な集積回路のミニットマンの誘導コンピュータである。

軍事機密のせいかミニットマンミサイルのFTAの事例はインターネットでは見つからなかった。ただ、容易に想像できるのは、一機700万ドルもする新規開発の大陸間弾道ミサイルを安定的に発射し目的を達成するためには、強烈な振動にも耐えうる部品と制御システムが必要だったのだろう。

失敗が許されない開発であり、信頼性評価・安全性解析の方法としてベル研究所のH・A・ワトソンのグループがFTAを考案し、ミサイルの開発を請け負ったボーイング社がFTAを完成させた。

FTAはトップ事象と基本事象の因果関係をブール論理を用いてつなげていく表現方法であり、図自体はすぐに書き始めることはできる。だから、1961年から半世紀たった現在では、誰でも簡単に使うことができる信頼性評価・安全性解析のツールになった。こんな歴史的背景を知ることもなくあちこちの安全解析に使われている。

当時、ミニットマンミサイルの開発はアメリカの国家プロジェクトであっただろう。だから、米軍はトップレベルの頭脳集団であったベル研究所に信頼性評価・安全性解析の手法の開発を依頼した。

このような背景を知って二つのことを思う。一つは今となっては故障や事故の分析手法の定番となったFTAは当時、何千万ドルといった国家規模のプロジェクトで精鋭の頭脳集団が考えた新しい方法論だったということ。そして、もう一つは、FTAはそもそも、使えば大量の人を殺すことができる軍事兵器の開発のために考えられ、今では逆に人の安全のために広く使われているという点だ。

自分はFTAを学びたいと思う人に FTA という手法が大事だとは思って欲しくない。

FTAの向こう側には必ず達成したい目的があるはずだ。当時FTAには FTAが必要な理由、FTAを必要とした背景があった。

米軍にはそれまで液体燃料で即応性が乏しく欠点の多かったミサイルを固体燃料のロケットにしたいという強い目的意識があり、そのためには固体燃料が発生する強力な振動や加速度で故障しないシステムを作る必要があった。何も対策しなければ、振動や加速度であちこちの部品が壊れたり期待どうりに動かなくなったりする。これらの故障を防いで目的であるミサイルの発射を成功させるためにはどうすればよいか、何を対策すればよいのか考えなければならない。

そのためには、故障の原因となる事象が発生するメカニズムを分析する必要があるのだが、複数の事象が従属的に起こったり、同時に発生しないと故障には至らないケースなどいろいろなケースが考えられる。また、部品の故障や事象の発生の確率もそれぞれ異なる。

これらを整理して図に表したのが FTA だ。そして、ミニットマンミサイルの場合、FTAは過酷な条件下でも故障なく安定してミサイルを発射する目的のために考えだされた。

その目的があったからこそ、FTAの分析には心血が注がれ、その結果、安定性の高いミサイルが完成したのだろう。軍事目的という点が引っかかるが、現実にはその方法論が後に社会に貢献したのである。（軍事目的で開発された手法や方法論が現代の科学技術の発展に貢献したことはよくある）

FTA は目的があるからこそ使う意味があるのであって、使い方を知っているだけでは何も寄与しない。FTAを使う者が、FTAが作られた歴史的背景を知って欲しいと考えるのはFTAを使うには何かしら発生させたくない故障や障害、リスクがあるかだということを認識して欲しいからである。

発生させたくない故障、障害、リスクに対して、分析者の思い入れがないと障害事象を抽出することさえできないだろう。そういう人が FTA を学んでも一つも組織や社会に貢献しない。

すでに完成しているシステムに新たな機能を追加するとき、それまでそのシステムに構築されてきた故障対策、安全対策をぶち壊してしまう危険性があるし、明示的に安全対策を壊さなくとも、まれな条件で発生するような安全対策のほころびを埋め込んでしまう可能性がある。

そうならないように安全を確保したい、当たり前にできていることをそのまま保持したいと思う気持ちがなければ、有効な FTA はできない。

一機700万ドルもする機器のプロジェクトならみんな本気にもなるよなと思う。でも、我々だって「FTA の向こう側にはシステムを使っているエンドユーザーが誰かしらいるんでしょ」と言いたい。その人達のために自分は何ができるかという気持ちで FTA に取り組めばよい分析ができると思う。たましいの入っていない安全分析ほど役に立たないものはない。

FTAをやりながら、先人の知恵をありがたく使わせてもらっているという感謝の気持ちも必要だろう。

そういう気持ちがないと冷たい無機質なFTA 図ができあがる。1980年代に事故を起こした放射線治療器 Therac-25 の開発では FTA 図が書かれており、「コンピュータが誤ったエネルギーを選択する」が発生する確率は 10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっていた。

当時、ソフトウェアによるシステマティック故障という概念がなかったため、コンピュータは複雑なことができるリレーのようなものだと認識されていたのだろう。Therac-25 ではこのFTAの結果をもとに、ソフトウェアの不具合要因は横に置かれ、コンピュータの故障確率は非常に低いと判断され、コストダウンの目的でハードウェアの安全装置を外したことで潜在的なソフトウェアの不具合が表面化して事故を起こしてしまった。（『ソフトウェアの特性を考慮せず事故が起きた事例』を参照のこと）

ミニットマンミサイルを開発していた技術者は当時、強烈な振動や加速度にも耐えてミサイルの発射実験が成功したとき、達成感を得て純粋にうれしかっただろうと想像する。（平和利用のロケットだったらなおよかっただろうが）

ツールを使うときは常にツールを使う目的を思い浮かべて置かなければダメだ。目指すべきゴールが何かを考えていないと、都合のよい結果を導くだけの道具になってしまう。

FTA で図を書く者は今一度、誰のために、何のために分析をするのかを考えて欲しい。そこに気持ちが集中していれば、いろいろな事象が思いつき、漏れの少ない FTA ができるはずである。

FMEAの歴史

FMEA（Failure Mode and Effect Analysis）とは、故障モード影響解析のことで、設計の不完全や潜在的な欠点を見出すために構成要素の故障モードとその上位アイテムへの影響を解析する技法である。

FMEAは Wikipedia によい歴史解説が載っているのでそれを引用しよう。

FMEAは1940年代にアメリカ陸軍が正式に導入した。その後、航空宇宙開発の分野では、製造量も少なく費用のかかるロケット技術において、間違いをなくすために使用した。例えばアポロ計画でも使用している。アポロ計画でのHACCPプロセスに適用され、その後、HACCPは食品業界全体に普及した[6]。人間を月に送り、安全に地球に帰還させる方法を開発する際、つまり1960年代にはFMEAを導入する重要な原動力があったわけである。1970年代になると、フォード が、ピントの問題後、安全と規制遵守のためにFMEAを自動車業界に導入した。自動車業界では、FMEAを製造プロセスにも適用し(PFMEA または工程FMEA)、故障を引き起こす恐れのある工程を量産開始前に検討し始めた。

FMEAは、1950年ごろのジェット機開発（アメリカ合衆国：グラマン社）の際、操縦システムの信頼性評価のために、最初に使用されたともいわれている。日本では1970年ごろから一般に使われるようになった。 

FMEAは、最初は軍が発展させた手法である。現在では半導体、食品、 合成樹脂、ソフトウェア、医療健康などを含む各種産業で広く用いている。FMEAはまた、米国自動車工業会(AIAG、自動車産業行動委員会と訳す)の先行製品品質計画(APQP)のプロセスに取り入れ、製品開発及び製造プロセス設計の際にリスクを低減することに役立てている。APQPでは、製品と製造工程に対する影響(故障)を拾い上げるために、潜在的な原因を考えなければならないことになっている。リスクの度合い(RPNと呼ばれる指標)に基づいて対策しなければならないことを決め、対策した後に再度リスクの度合いを評価する。 

自動車業界では，ISO 9000の技術仕様を定めたISO TS 16949でFTA, FMEAを参照しており幅広く取り組んでいる。 トヨタ自動車ではFMEAを｢故障モードに基づく設計レビュー(DRBFM:Design Review based on Failure Mode)｣をGD3（GDキューブ：良い設計、良いディスカッション、良い観察）の一部として取り入れている。現在、このDRBFMはアメリカ品質協会が対応しており、詳細な手引きを提供している。

FMEAは1949年11月9日に米陸軍により "Procedure for performing a failure mode effect and criticality analysis, November 9, 1949, United States Military Procedure, MIL-P-1629" という名前の軍事手順として発行された。この手順は、システムや機器の障害の影響を決定するために、信頼性評価技術として使用されていた。 障害はミッション成功と人員/機器の安全への影響に応じてクラス分類された。

結局、FMEAも軍事的な目的から開発されたのだが、その後アポロ計画でも使われ、人類が初めて月面に降り立った業績に貢献したと言われている。と言っても、アポロ計画ではNASAが、FMEAの実施を開発受注業者に義務付けたことから普及したらしく、あらゆる経験を集めて起こるであろう故障を予測し、帰納的な事前対策をサプライヤに課すことで効果を上げていたのだ。

その後、自動車業界では1972年にフォードモータースのピントの事故の再発防止のためにFMEAを導入した。ピントの事故とは次のようなことであった。

事例概要：米国フォード社の「ピント」が高速道路で突然エンストして停車していたところ、約50km/hの速度で走ってきた後続車に追突されて炎上し、運転者が死亡、同乗者が重度の火傷を負う事故が発生した。ガソリンタンクの配置の悪さが直接の原因であった。他社との競争のための開発期間短縮と安全軽視のポリシーが起因と考えられる。この事故は、1億ドルを越える陪審の評決がでたことで有名である（ただし控訴審で減額）。

事象：米国フォード社の「ピント」が高速道路で突然エンストして停車していたところ、約50km/hの速度で走ってきた後続車に追突されて炎上し、運転者が死亡、同乗者が重度の火傷を負う事故が発生した。

自動車業界でもこのような事故の再発を防止したいためにFMEAを導入した。

また、FMEAはHACCPにも使われた。HACCPとは食品の中に潜む危害（生物的、化学的あるいは物理的）要因（ハザード）を科学的に分析し、それが除去（あるいは安全な範囲まで低減）できる工程を常時管理し記録する方法である。例えば、ハンバーグを焼くときに、挽肉中の感染症や食中毒原因細菌などが、ハンバーグの中心の温度が何度にどれだけの時間経過すれば安全なレベルになるかを科学的に分析して、分析の結果決定した管理方法を実施して、実施した結果を記録する。これによりかつて行われていた抜き取り検査のみの管理では為し得なかった全品の安全性が高いレベルで効率よく確保され、このことを記録から証明することができる。

マクドナルドは1980年代に病原性大腸菌腸管出血性大腸菌O157の問題を解決するために自主的にHACCPに取り組んだ。合衆国ではまたHACCPは従業員数名の小規模の企業でも義務化され実践されており、効果を上げている。

食品業界では食の安全のために FMEA が使われているのである。

今回の記事で言いたかったことは、FTA や FEMA を目的意識をしっかり持って使いましょうということである。そのためには、FTA や FMEA が開発された歴史を知ることが重要である。

ISO 26262 の規格適合についても同じことが言える。誰のために、何のために規格に適合するのかを見据えていない者は機器やシステムの安全性や信頼性を向上させることはできず、その結果エンドユーザーにも社会にもプラスの貢献にはならない。

ISO 26262との向き合い方 (13) 機能安全の歴史的背景1

ISO 26262の理解を深めるために、書籍『機能安全/機械安全規格の基礎とリスクアセスメント―SIL、PL、自動車用SILの評価法』 を読んだ。

今回は、この本に書かれていることの一部を紹介したいと思う。ちなみに、国際規格を理解するためにはその規格が制定された背景を知るべきだと常々感じていたのだが、この本を読んでよりいっそうそのことを痛感した。一般的に、国際規格自体にはその規格が制定された裏側の背景は詳しくは書かれない。規格のAppendix に表の背景が書かれることがあるので、Appendix は読み飛ばさずにじっくり読むべきだが、表も裏も含めた背景を知るのに一番いいのは規格策定に参加した委員に話を聞くことだ。

ISO 26262 は　IEC 61508 に強い影響を受けいる、というよりはISO 26262 は自動車版の機能安全規格である。だから、ISO 26262 を知る上で IEC 61508のことを知ることは意味がある。『機能安全/機械安全規格の基礎とリスクアセスメント―SIL、PL、自動車用SILの評価法』 の著者、現東京海洋大学海洋工学部 佐藤吉信 教授 は、現在、IEC 61508の策定・改訂国内委員の主査である。よって、IEC 61508 や ISO 26262 ができてきた歴史的な背景も詳細にこの本に記載されている。ISO 26262 について理解を深めたい人はこの本を一度読んでみることをお勧めする。

IEC 61508 が制定された歴史的背景

まずは、歴史的背景から、その一部を紹介しよう。

<仕様規定と非関税障壁の問題>

• 1985年前後に欧州で製造物責任法の相次いで施行され、製品製造業者がこの法律に過度に反応した。
• それに伴い製品に関わる安全規定策定の動きが各国において一斉に生じた。
• それらの規定は各国の製品製造業者によって策定されることも多く、結果的に製造業者の製品に合致する設計仕様規格となった。
• このようにして1980年代から1990年代には、欧州各国の安全規格による非関税障壁の問題が多発した。
• 欧州内での製品の流通を円滑にするために各国ごとの安全規格を統一することが必要になったが、すでに詳細な設計仕様に基づいて策定されてしまった各国の安全規格を欧州安全規格として統一することは現実的には不可能であった。
• この反省点に基づき、1990年代になって、ISO機械類の安全規格などにみられるように、製品の定性的あるいは定量的な安全性能に立脚した、いわゆる性能標準化の必要性が認識され始めた。

PL(Product Liability）法（製造物責任法）がきっかけで自己防衛のために、各製品系統ごとの安全規定策定が進んだという点が興味深い。製造業者が製造する商品によって消費者に危害が及んだ際、PL法により製造業者は製造物責任が問われる可能性がある。設計、製造に落ち度があって結果として商品に欠陥があったと判定された場合、その責任を問われるというものだ。

「製造物責任の意義」（2012年8月18日 版）『ウィキペディア日本語版』より引用

損害賠償責任を追及する場合、民法の不法行為法における一般原則によれば、要件の一つとして加害者に故意・過失があったことにつき被害者側が証明責任を負う。

つまり民法で損害賠償を請求する際には、被告の過失を原告が立証する必要がある。しかし多くは、過失の証明が困難であるために損害賠償を得ることが不可能になる場合があるとの問題意識から、同法で製造者の過失を要件とせず、製造物に欠陥があったことを要件とすることにより、損害賠償責任を追及しやすくした。このことに製造物責任の意義がある。 

無過失責任としての製造物責任に関する扱いとしては、まず、1960年代初めのアメリカで、fault（過失）を要件としない strict liability（厳格責任）の一類型として判例で確立された。また、ヨーロッパでは製造物責任の扱いについて各国でかなりの差異があったが、その均一化を図る必要があるとして、1985年に当時のEC閣僚理事会において製造物責任に関する法律の統一に関する指令が採択され、その指令に基づき各国で製造物責任に関する立法が導入された。

PL法での焦点は製造物に欠陥があったのか、なかったのかという点である。もっとも、「欠陥があることが証明できれば過失を認定できるのが通常であることや、欠陥の有無に関する判断基準は過失の有無に関する判断基準と重なることが多いとして、過失と欠陥がどれだけ質的に異なるかにつき、疑問を呈する見解もある。」ということなので、欠陥の認定と過失の有無は表裏一体と言える。要するに過失があったから欠陥が生まれる、過失がなければ欠陥ではないという論理もあり得るということだ。

何はともあれ、PL法において製造物に欠陥があったことが明確になれば製造業者の負けになる。逆に言えば、製造物に欠陥があったとはいえなければ責任は問われないということだ。

この解釈は非常に難しいだろうし、毎回裁判で議論していたのでは欠陥のあるなしではなく、裁判の進め方如何で欠陥認定が変わる事態になりかねない。

そこで、製造業者は商品系統ごとに安全規定を策定したのだろう。ようするに、安全規定に沿って製品を設計、製造したことを証明することで、過失がない、すなわち安全に関する欠陥がなかったことを主張することを考えたのだろう。（本当にそうかではなく、過失がないことの根拠の一つにしたかったのだ。）

実はこの流れは21世紀になっても変わっておらず、製造物によって起こった事故について、製造業者は常にPL法の脅威にさらされており、国際規格が製造業者に商品の設計に関して過失がなかったことを証明する根拠の一つに使われている。それは製造業者が欠陥を隠蔽しようとするために行っているのではない。例えば、アメリカではオペレーションミスなのか製品の欠陥なのか原因のよく分からない事故において、欠陥がないことを証明しきれない場合、裁判で黒と認定されることがある。これを防ぐためには客観的な根拠が必要であり、国際規格への適合は客観的な根拠の一つとなっている。

なお、各国が商品系統ごと作った設計仕様規格は結果的に、非関税障壁となってしまい、EU統合の際の商品流通の障壁にもなった。しかし、詳細な設計仕様に基づいて策定されてしまった各国の安全規格を欧州安全規格として統一することは現実的には不可能であったため、商品系統を超えた統一した安全規格の制定が希求された。

そのような背景により幅広い商品系統に使用できる機能安全規格 IEC 61508 が策定された。

また、このような背景もある。

<事後安全計画から事前安全計画へ>

事故・災害が起こってから対策を立てる事故後安全計画は20世紀終盤までは効果的であったが、その後飽和（限界）状態になって、事前安全計画の必要性が高まってきた。

また、製品システムは複雑化し、コンピュータ技術の導入が進み、ソフトウェアに起因する不具合が増えてきた。

これにより、全安全ライフサイクルの実現が叫ばれるようになり、IEC 61508で次の事前安全計画の方法論の基本的枠組みが形成された。

【事前安全計画の方法論の基本的枠組み】

a) 全ライフサイクルのそれぞれのフェーズを有機的に関連づける
b) 安全性の尺度として（危害の）リスクを用いる

a) は製品開発を概念形成から廃棄までのプロセスに分離して進めるプロセスアプローチ考え方で、ソフトウェアの品質向上施策の歴史から見ても納得できる。（『ソフトウェア品質論の歴史的推移』を参照のこと）
b) が製品にまつわるリスクをベースに安全を考えるリスクベース設計の考え方で、IEC 61508 の SIL や ISO 26262 のASIL の概念に通じている。

安全のためのリスク軽減戦略

『機能安全/機械安全規格の基礎とリスクアセスメント―SIL、PL、自動車用SILの評価法』には、リスク軽減戦略について具体的な事例がたくさん掲載されている。その一部を掲載して考察してみよう。

-プラントのリリーフバルブの例-

たとえば、プラントのリリーフバルブを例に取れば、旧版(ISO/IECガイド51)では、過圧による容器の爆発災害を防止するため、単純に当該バルブを解放することをリスク軽減処置として採用できた。改訂版によると、化学物質を大気中に放出して環境の価値を害するなら、バルブの開放では単純に安全を確保したことにならない。したがって、リスク事象「容器の加圧による破裂」を招かぬように、プラントの安全設計システムの機能が著しく重要になる。

ISO／IECガイド51は 「規格に安全面を導入するためのガイドライン」で IEC 61508 や ISO 26262 の上位に位置するガイドラインである。

このプラントのリリーフバルブの例は、3.11 の福島の原子力発電所の格納容器の弁の解放を思い起こされる。（弁を解放したことが原因で放射性物質が大気中に放出されたかどうかは定かではない。こちらを参照のこと。）

-鉄道信号の例-

また、鉄号信号を例に取れば、従来、列車の衝突を防止するために、なんらかの傷害が信号系に発生すると列車を先ず停止させてきた。これがフェールセーフ技術と呼ばれるもので、常に列車の停止が安全側の状態とされている。しかし、改訂版ガイド51によると、長時間の停止により乗客の財産に毀損が発生し、あるいは急病発生への救急処置が遅延するなどにより乗客の健康逸失が発生すると、単なる停止はそれらの潜在危険に対して安全とは言い切れない。したがって、信号系のデジタル化などによる系の冗長化や、自己診断機能を充実させて信号系のアベイラビリティ向上を目指し、一方では速やかな傷害復旧を促進して、乗客のリスク軽減を計ることがなお一層必要になる。

鉄道の場合、何かあれば列車を停止させれば安全が確保されると考えられていた。それは現在でも正しいフェールセーフの考え方だ。しかし、列車を止め続けることで乗客の時間という財産の毀損は確実に生じる。よって、安全のために列車を止めるという対策だけでは、リスク軽減策は完全ではない。さらに、リスク軽減策を積み重ねると、複雑化するためその複雑化が新たなリスクを生む。だからこそ、現代の安全設計はとても難しいと言える。

-自動車の追突の例-

例えば、自動車が走行中に先行車に追突することにより、当該運転手が自車のハンドルに強打して傷害（危害）が発生する事故シナリオを考える。

この場合、当該自動車がある程度の速度をもって走行している状態、低速先行車が存在する状態、追突危険事象、自車の破損と急激な停止側加速事象、運転手とハンドルとの急激な接近状態、運転手とハンドルとの衝突リスク事象などが事故シナリオの構成要素となる。

<潜在危険の同定>

潜在危険の同定では、最低限1個のリスク事象を特定することが必要である。上記の事例では「当該自動車がある程度の速度を持って走行している状態」、「低速先行車が存在する状態」、「両者の衝突リスク事象」によって、潜在危険(1)が同定できる。さらに、これに「自動車の破損と急激な停止側加速状態」、「運転手とハンドルとの急激な接近危険状態」、「運転手とハンドルとの衝突リスク事象」の諸状態と事象を付け加えることにより潜在危険(2)が同定できる。当然、潜在危険(1)の方が潜在危険(2)よりも広い事故シナリオを包括している。すなわち、潜在危険(2)は潜在危険(1)の部分集合となっている。 

潜在危険(1)と(2)とに対するリスクでは、その内容が異なる。前者のリスクは、後者のリスクを包含し、後者以外の潜在危険、例えば、追突によって、当該運転者が車外に投げ出されるという潜在危険によるリスクも含む。
リスクは、潜在危険をもとに存在するため、潜在危険の解消は、根本的なリスクの解消となる。しかし、決定論的原因故障から生じるものも含めて、あらゆるリスクを根絶することは不可能である。

この部分ちょっと分かりにくいのだが、ようするに潜在危険(1)は自動車が先行車両と衝突するリスクまでのことを関心事にしていて、潜在危険(2）は衝突後に運転手がハンドルに強打するまでのことを関心事にしているということだろう。この後、潜在危険(1)と潜在危険(2)ではリスク軽減策が考え方が異なるということが書かれている。

-自動車の追突事故のリスク例-

一例として、自動車の追突事故のリスクについて考えてみよう。現在、広く実用化されている自動車の安全関連装置として、車間距離警報装置、（能動型）シートベルト、（衝突時）エアーバッグなどが知られている。前述の自動車の衝突の例で同定した潜在危険(1)「当該自動車がある程度の速度をもって走行している状態-低速先行車が存在する状態-両車両の衝突リスク事象」によるリスクを考えれば、車間距離警報装置の安全機能は主としてリスク軽減戦術b)を、シートベルトやエアーバッグなどの安全機能はリスク軽減戦術a)をそれぞれ遂行すると言える。

次に、同様に同定した潜在危険(2)「当該自動車がある程度の速度をもって走行している状態-低速先行車が存在する状態-両車両の衝突危険事象-自車の破損と急激な停止側加速状態-運転手とハンドルの急激な接近危険状態-ドライバーとハンドルとの衝突リスク事象」に対するリスクを考えれば、最終的なリスク事象は「運転手とハンドルとの衝突」であるから車間距離警報装置はもとよりシートベルトやエアーバッグなどの安全機能もリスク軽減戦術b)をそれぞれ遂行すると言える。 

すなわち、同一の安全関連系の安全機能であっても、どのリスクを対象とするかによって異なるリスク軽減戦術をして分類されることに注意すべきかである。このことは、リスク解析・評価と機能安全との関連において重要な意味を持つ。 

固有（本質）安全に対して機能安全とは、「ある安全機能をある確からしさ（確率）で遂行することによってリスクを軽減する能力を持つ安全関連系（装置）によって確保される安全」ということができる。固有（本質）安全では、たとえば、構造物の地震に対する耐震性能など信頼性評価基準が問題となる。機能安全では、安全関連系の機能遂行確率が問題となり、これも信頼性の問題と深く関わってくる。このように、固有（本質）安全および機能安全においては、ディペンダビリティと機能安全が少なからず接点を持つことになる。

これもやや分かりにくいが、解釈すると自動車が先行車両と衝突するリスクである潜在危険(1)については、車間距離警報装置が主たるリスク軽減策であり、シートベルトやエアーバッグは主のリスク軽減策とは追加のリスク軽減策とう位置づけで、衝突後に運転手がハンドルに強打するまでリスクである潜在危険(2)では、車間距離警報装置、シートベルト、エアーバッグが同列のリスク軽減策ということを言っているのではないかと考える。

何はともあれ、著者が強調したいのは潜在危険あるいは潜在危険群によるリスクを明確にすることの重要性であろう。

IEC 61508 と ISO 26262の相違点

a) プロセス産業では早くからプロセスの自動化が進展し、プロセス産業からのエキスパートが多数を占めたIEC 61508策定時に、化学反応を制御するための自動化、安全計装システムの導入など人の介在を含まない安全関連系がすでに多く実用化されていた。一方、当時機械類の産業分野では相対的に自動化は始まって日が浅く、自動車に至っては、今日でも運転者が運転をオーバーライドするという基本的形態から脱していない。 

b) 安全関連系に人の操作機能を含むか含まないかは、安全関連系への要求事項に大きな影響を与える。IEC 61508では、基本プロセス制御系と安全関連系とを分離することが求められているが、自動車などではそれらを分離することは難しい。しかも、運転者と車の加速機能・減速機能・操舵機能遂行システムとはほぼ一体で基本制御系も構成していて、例えば車間距離警報システムなど安全関連系がそれらの基本制御機能の一部を支援しているに過ぎない場合も多い。このため、安全関連系の安全機能のみを独立させて安全度を評価することが難しい上に、システムが複雑なため全体システムの定量的リスク評価が難しくなる。 

c) プロセスプラントの寿命は30～40年と長く、次世代のプラントは基本から新規に設計・製造される。一方、自動車の新型モデルの設計は、旧型モデルの部分的改造であることが多く、旧型モデルの部品などを多く継承する。旧型モデルで使用した部品の安全性は、妥当性が確認済みと見なせる場合が多い。 

d) 危害の規模は、プロセスプラントでは1回当たりに多数の死傷者を出す可能性があり、損害額も大きい。プロセスプラントの台数は世界的に見ても最大数千程度である。一方、自動車では1回当たりの死傷者数は少ないものの、台数が多いため合計すれば死傷者数と損害規模はプロセスプラントを上回る可能性がある。 

e) 機器の不都合に関するリスクオーナーは、プロセスプラントではプラントオーナー、自動車では一義的に運転手であるが、自動車ではリコールリスクが存在する。リコールリスクのオーナーは自動車の販売者となろう。 

f) IEC 61508 では、安全関連系の安全性能を2種類の要求モードに対してSIL1からSIL4までの4段階で規定しているが、ISO26262では、ASIL Aから ASIL D およびQM の5段階で規定している。 

g) IEC 61508 では、安全関連系はセンサなどの入力端から最終的に安全機能を実行するアクチュエータまでの全体として定義され、弁などの機構部品を対象範囲に含まれる。一方、ISO 26262では、安全関連系のうち、電気・電子技術に関連した部分のみを対象とる。

上記の a) と b) の説明でIEC 61508 がプロセス産業（化学プラントなどの自動化製造工程の設計がベースとなる産業）のエキスパートが中心に作られた規格であることが分かる。

また、プロセスプラントでは人の介在を含まない安全関連系のリスク軽減策が多く実用化されていたことも分かる。

一方で、自動車や医療機器は人による操作機能が含まれるため、基本制御と安全関連制御を分離することが難しい。その部分がしっくりこないため、ISO 26262 は自動車用に機能安全をモディファイしたのだろう。医療機器はプロセスプラントとはさらに性質が異なるため、独自路線で規格策定が進んだ。（IEC 60601-1 や IEC 62304, IEC 62366など）

機能安全は当初、リスクを軽減する能力を持つ安全関連系（装置）にフォーカスが当たっていることが分かる。MITのナンシー・レブソン教授が機能安全を評価していないのは、機能安全がシステムのアーキテクチャの複雑性から発生するリスクにフォーカスを当てていないからだと思う。（『機能安全の意味がわかった(IEC61508とISO26262の最新情報』参照）

思い起こせば2006年に日本で開催されたクリティカルソフトウェアワークショップで、自分がエレベータのアーキテクチャの事例で独立した安全装置の有効性を発表したときに、ゲストとして招待されていたナンシー・レブソン教授に「独立した安全装置など、誰でも思いつく単純な方法だ」と酷評されたことが思い出させる。ナンシー・レブソン教授は放射線治療器の Therac-25 の事故調査によって一躍有名になったのだが、Therac-25 の事故がすぐに収束せず6名者もの犠牲者を出してしまったのは、ソフトウェアの複雑性と追加変更による問題の作り込み、ソフトウェアの特徴を考慮していない安全対策などが原因だった。

独立した安全装置は、プロセスプラント系では人の介在を含まない安全関連系のシステムであり単純系システムのアプローチだったため、ソフトウェアの複雑性から発生するリスクを完全に押さえ込むことはできないという意味での批判だったのだと思う。

また、「安全関連系に人の操作機能を含むか含まないかは、安全関連系への要求事項に大きな影響を与える。」はまさにその通りで、医療機器では人の操作機能は必ずと言ってもいいほど介在するため、ユーザビリティの視点でのリスク分析は必須事項となっている。自動車の場合は、まだ、ユーザーオペレーションが単純であるためユーザビリティに対する要求は存在していない。

それどころか、ASILの判定要素の中でユーザーである運転手のコントローラビリティがASILを軽減する手段として使われいる。医療機器ではオペレーションがソフトウェアによって複雑化されているため、ユーザーの回避動作を考慮してリスクが軽減できると考えることはできない。

ただし、自動車だって今後も操作性が単純なままかどうかはわからない。現に、カーナビゲーションシステムやクルーズコントロールなどハンドル、アクセル、ブレーキ以外のオペレーションも増えてきている。

『機能安全/機械安全規格の基礎とリスクアセスメント―SIL、PL、自動車用SILの評価法』 を読んで改めて思うのは、IEC 61508 や ISO 26262 はソフトウェアの複雑性、ソフトウェアのアーキテクチャの問題にフォーカスを当てたアプローチについては触れられていないということだ。これらは、ソフトウェアのプロセスアプローチや変更管理、構成管理、検証法等などだけでは解決できない問題だと思う。

P.S.

過去の ISO 26262との向き合い方の記事で、ASILをアイテムやエレメントに割り当てるといった記述をしていましたが、名古屋大学の高田先生からのご指摘及び今回紹介した書籍により、それは間違いであり、SIL, ASILは安全関連系の安全性能を等級化した水準であることが分かりました。これは今回の記事で紹介したように、IEC 61508 が基本制御と安全関連制御を明確に分離していたことの名残であると考えています。しかし、基本制御と安全関連制御が明確に分離できないシステムにおいては、潜在危険から推定するリスクのクラス分類と、ソフトウェアを分割したときの各ソフトウェアアイテムのリスク（安全）クラス分類は必ずしも一対一にはなりません。（付加的な機能のシステマティック故障が安全制御に影響を与えることは大いにあり得るという意味）ASILデコンポジッションはシステムのアーキテクチャの構造分離にことを示していたのだと思っていましたが、実際にはそうではなく、リスクを軽減するための安全性能、安全機構の冗長評価のことでした。繰り返しますが、基本機能と安全機能が明確に分離できないシステムにおいては、ソフトウェアアーキテクチャの重要性がクローズアップされます。ASILデコンポジッションが複雑なソフトウェアシステムにおけるアーキテクチャの設計戦略に踏み込んだ話ではなかったということです。この点については、今後掘り下げていきたいと考えています。

ISO 26262との向き合い方 (12) 対訳版を読み始めて思うことあれこれ

ISO 26262-1 第1部：用語集 （日本規格協会から発行されている英和対訳版）を読んでいる。読んでいて思うのは、ISO 26262 は用語の定義の全体数が多く、かつ、専門用語が多いのでソフトウェアエンジニアには難解なことばがあるという点だ。

それと、ISO 26262 全体の構成について感じるのは、ハードウェアの開発プロセスとソフトウェアの開発プロセスをそれぞれ別パートで分けていながら、安全の評価基準であるASILはハード、ソフトを一緒に考えているところに「本当にそれで大丈夫か」と感じる。

ASILを分割する考え方であるASILデコンポジッションについても、十分に独立したエレメントが存在することが前提となっている。ようするに、自動車は独立した部品の組み合わせで構成されているという考え方だ。

しかし、我々は複雑化したソフトウェアをそれぞれコンポーネントとして十分に独立させることができていないことが、様々な問題を起こしていることを知っている。

ハードウェアの独立とソフトウェアの独立の議論は同じレベルで語れないはずなのに、ISO 26262では、ハード、ソフト込みのエレメントがベースになっている。

まあ、それはそれとして今回はISO 26262-1 第1部：用語集の気になる用語のいくつかを話題に取り上げようと思う。

【Anomaly：アノマリー】

例えば、要求、仕様、設計文書、ユーザ文書、標準又は経験をもとにした期待から逸脱している状態。

備考　アノマリーは、レビュー、テスト、分析、まとめ、あるいはコンポーネントや適用可能な文書の仕様といった別の機会に発見される場合がある。

ISO 26262 の対訳版では Anomaly をそのまま「アノマリー」と表現している。

Anomaly を辞書で引くと Longman の英英辞書では

Something that is noticeable because it is different from what is usual:

ウィズダムの英和辞書では

1 異常（なこと）、例外（的なこと）、特異な存在、異例、変則；不合理

とある。医療機器のソフトウェアライフサイクル規格 IEC 62304:2006 の JIS 版 JIS T 2304:2012 では Anomaly は日本語では「異常」としている。

異常（ANOMALY）

要求仕様書，設計文書，規格など，又は既存の認識若しくは経験に基づいて予想した結果を逸脱する状態。異常は，ソフトウェア製品又は該当する文書のレビュー，試験，分析，コンパイル又は使用中に発見されることがあるが，これには限定しない。

この日本ではなじみのない Anomaly：アノマリーということばを、今回 ISO 26262 の対訳版でそのまま「アノマリー」と表現したのは、その本質的な意味を表す適当な日本語が見つからなかったのであろう。

何が日本語では表現できないのかというと、アノマリーは発見された時点では不具合と確定していないというという点だ。Error, Failure, Fault はそれぞれ、問題があるということが分かっている。しかし、Anomaly：アノマリーは、"Something that is noticeable because it is different from what is usual:" だから、いつもとは違う、あるいは期待から逸脱しているだけで、発見された時点で不具合であることが確定している訳ではない。

ここで、Anomaly を「異常」と言ってしまうと、問題がある、瑕疵・欠陥があることを認識しているいうニュアンスが強くなってしまう。

Anomaly が組織が不具合と認めている欠陥なのか、それとも不具合があるかもしれないし、ないかもしれない問題なのかその違いは大きい。欠陥を認める前なのか後なのかが重要なのだ。

ようするにソフトウェアの開発時に問題など山ほど起こる。我々はそれらをBUG：バグと言うわけだが、バグの中には仕様の誤りや勘違いも少なからずあるし、バグだと思って調べたら実はそうではなかったということもある。

もし、ソフトウェアに起因する事故が発生し、訴訟が起きたとき重要なのは、問題点を製造業者側が不具合、欠陥と認識していたかどうかだ。不具合と認識していていたにも関わらずそれを修正せずに放置したことで事故が起こったのならば、その責任は製造業者にある。

現実には開発の工程で発見された問題点は、それが受容できないリスクに繋がるのか、それとも受容できるのかを判定する。受容できる場合は、製造業者はその問題点を修正しない選択しを取ることも許されている。一般の方はそれが不合理だと思うかもしれないが、例えばこういう例を考えて欲しい。保守用のソフトウェアで自己診断の"PASS" というメッセージの最後のSの右側縦1ドットがまれに欠けることがあったとする。装置の診断は問題がないし、PASSからFAILの判定もできる。しかし、どこで誰が縦1ドットを消しているのかが、どうしても分からない。これはソフトウェアのバグであり不具合ではあるが、ユーザーが受容できるリスクと判定できる。この場合、バグは残留しており、どのようなバグであるのか、誰がリスクを重要できると判断したのかを残しておくことで商品をリリースすることができる。（Anomaly がゼロの状態でソフトウェアがリリースされているとは誰も思っていない）

不具合、欠陥を組織が認める前なのか後なのかの識別が重要であることがおわかりいただけたと思う。そう考えると、いつもとは違う、あるいは期待から逸脱している、怪しいが確証はない事柄は現実に存在し、それらが不具合や欠陥であると確定していないことを表現する言葉が必要になる。それがアノマリーだ。

アノマリーに関連して、 inspection：インスペクション、testing:テストと walk-through：ウォークスルー の説明も見てみよう。

インスペクション

アノマリーを検出するため、形式が定められた手続きに従う作業成果物の審査

備考1 インスペクションは検証の一手段である。
備考2 関連するアイテム又はエレメントの動作を通常伴わない点が、テストと異なる。
備考3 通常、検出されたアノマリーは再作業により扱われ、その作業成果物は再度インスペクションされる。
備考4 通常、形式が定められた手続きには前もって定められた手順、チェックリスト（の使用）、調整役（の出席）及び結果のレビューが含まれる。

テスト

指定された要求を満たすことの検証、アノマリーの検出及びふるまいに対する確認を得るための、計画と準備とアイテムまたはエレメントの動作又は実行のプロセス。

ウォークスルー

アノマリーを検出するための、作業成果物の体系的な審査

備考1 ウォークスルーは検証の一手段である。
備考2 関連するアイテム又はエレメントの動作を通常伴わない点がテストと異なる。
備考3 通常、検出されたアノマリーは再作業により扱われ、その作業成果物は再度ウォークスルーされる。

例 ウォークスルー中、開発者は一人以上のアセッサーに対して、段階を追って作業成果物を説明する。この目的は作業成果物に対する共通理解を築き、作業成果物に存在するアノマリーを識別することである。インスペクションとウォークスルーはいずれもピアレビューの一形式であるが、ウォークスルーと比べると、インスペクションの方がやや難しい。

【ISO 26262-2 第2部 機能安全の管理 付属書B(参考) 安全文化評価の例】

ISO 26262-2 第2部 機能安全の管理 付属書Bに 安全文化評価の例が載っている。これは本文には入っておらず、参考なので規格要求ではないが、非常に興味深い内容なので、掲載しておく。

不十分な安全文化を示す例	良い安全文化を示す例
責任がトレースできない。	プロセスが関連する機能安全の決定責任のトレースを保証する。
常に費用及びスケジュールが安全及び品質に優先する。	安全が最も優先順位が高い。
報酬システムが安全及び品質に対してよりも費用及びスケジュールを評価する。	報酬システムが機能安全の効果的な達成を支持し、動機付ける。 報酬システムが、安全及び品質を危険にさらす近道を取る者を罰する。
安全、品質及びそれらの管理を評価する者が、プロセスを実行する責任者に過度に影響される。	プロセスが適切なチェック及びバランスを与える。例えば、組み込まれたプロセス（安全、品質、検証、妥当性確認及びコンフィグレーション管理）の適正な独立性。
安全に対する受動的な態度、例えば －製品開発サイクルの最後のテストへの過度の依存 －フィールドに問題がある場合だけ管理者が動く	安全に対する積極的な態度、例えば －安全及び品質の問題は製品ライフサイクルの初期の段階で発見され、解決されている。
必要なリソースがタイムリーに計画、配置されない。	必要なリソースが配置されている。 技能のあるリソースが割り当てられた活動に相応しい能力をもつ。
“集団思考” レビューグループを作る際に“不正工作”をする。 反対者が追放される、または“チームの者ではない”とレッテルを貼られる。 異議は勤務評定でマイナスに働く。  “少数派の反対者”が“トラブルメーカー”、“チームの者ではない”又は“密告者”といった扱いをされたり、レッテルを貼られる。  関連する従業者が跳ね返りを恐れている。	プロセスが率先して多様性を行使する： －知的な多様性が求められ、価値を与えられすべてのプロセスに組み込まれる。 －多様性に行使に反対するふるまいをやめさせ、罰する。        コミュニケーションの支持及び意志決定のチャネルが存在し、管理者はそれらの行使を推奨する。 －自己開示が推奨される。 －他のだれによる発見の公開も推奨される。 －発見及び解決のプロセスがフィードで継続される。
体系化された継続的な改善のプロセス、学習サイクル又は“教訓”の活用がない。	継続的な改善がすべてのプロセスに組み込まれている。
プロセスが“その場しのぎである”又は暗黙である。	定義され、トレース可能で、管理されたプロセスに以下を含むすべてのレベルで従っている。 －管理 －エンジニアリング －開発インタフェース －検証 －妥当性確認 －機能安全監査 －機能安全アセスメント

これは安全文化について書かれているのだから、安全文化が不十分か、それとも十分かの判断に違和感を覚える部分があれば、それが欧米と日本の意識の違いであると言える。


例えば、「レビューグループを作る際に“不正工作”をする。」「反対者が追放される、または“チームの者ではない”とレッテルを貼られる。」「異議は勤務評定でマイナスに働く。」などは、そこまではないだろうと思う一方で、「製品開発サイクルの最後のテストへの過度の依存」や「フィールドに問題がある場合だけ管理者が動く」などという指摘点は、どこも同じなんだなと感じる。


【安全対策が簡単ではない例】

ISO 26262 とは関係ないが、ソフトウェアに関する安全はソフトウェアの複雑性から脅かされるという例を紹介したいと思う。

6/20 にレンタルサーバーを運営しているファーストサーバにて、大規模なデータ喪失障害が発生た。脆弱性対策のためのメインテナンスプログラムに問題があり、そのプログラムが稼働中のデータのみならずバックアップデータまで削除してしまったことが原因だった。

大規模障害が起こった原因の詳細についてはこちらを読んでいただくとして、なぜ、ソフトウェアのシステマティック故障が起こるのかについて考えたので下記を見て欲しい。システマティック故障がソフトウェアの複雑性に絡んで発生することがよく分かる。

障害の原因3：メンテナンス仕様

システムを含むデータのバックアップは毎朝6時に取得しております。しかしながら、脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。

過去に、脆弱性対策をバックアップシステムにも適用しておかなかったために、ハードウェア障害が発生してバックアップシステムに切り替わると脆弱性対策が行われていない状態になるという問題が発生したとある。今回の大規模障害と比べればリスクレベルは低い問題だ。しかし、リスクは受容できないレベルであると考えられ、脆弱性の対策は本番環境だけでなくバックアップシステムにも同時に実施するように運用が変更された。実は、このリスクコントロール対策自体にリスクがあった。


脆弱性対策のプログラムに問題があると本番環境とバックアップ環境の両方に影響を及ぼすという新たなリスクである。バックアップは本番環境に何か問題があったときのリカバーのための対策であるから、後に発見された相対的に小さなリスクに対するリスクコントロール対策を追加したことによって、もともとあった大きなリスクに対するリスクコントロール対策の効果及び堅牢性を低下させてしまったことに気がつかなかった。


実はリスクコントロール対策を行う際に追加したリスクコントロール対策が新たなリスクを生むことはよくある。よかれと思ってやったことが、逆にシステムを脅かしてしまうことがあるのだ。


だからリスクコントロール対策を追加したり、修正したりするときは、その対策を実行することにより発生する新たなリスクがないかを分析しなければいけない。また、ただ分析すればよい訳ではなく、これまで構築してきた安全対策のアーキテクチャが崩れていないかどうか、リスク対策の効果が弱まっていないかどうかをチェックする必要がある。


ソフトウェアエンジニアは商品やサービスのリリース後に問題が発見されると、すぐにソフトウェアを修正してしまうが、商品リリース後のソフトウェア修正は慎重かつ、何重ものチェックの上で実施されなければいけない。その慎重さのレベルは対象となっているソフトウェアアイテムの重要度の大きさによっても変わる。（変更に対するリスクが受容できることが明確ならばアジャイルでどんどん直すことも可能だが、人の命がかかっているようなソフトウェアはそれではまずいことは明白だ。）


さて、ファーストサーバの大規模障害では、本番環境とバックアップシステムの両方に脆弱性対策を行うという運用の変更を行った結果、脆弱性対策のプログラムのミスによるデータの削除が本番環境のみならずバックアップシステムにも及んでしまった。

脆弱性対策の削除コマンドを消し忘れたというプログラムミス自体はヒューマンエラーだ。
しかし、この大規模障害はよかれと思った実施した追加の対策により、最初に考えられていた安全対策の効果及び堅牢性が弱まってしまった。そこに、ミスが重なり、予想していなかった Hazardous Situation が現実のものとなってしまった。

ISO 26262でも同じことは起きると思う。サプライヤを含めたソフトウェア開発組織がISO 26262 の要求する要求（主にプロセス要求）を満たせたとしても、よかれと思って実施したソフトウェアの変更がソフトウェアシステムの複雑性を助長し、その変更が既存のリスクコントロール対策に悪い影響を与える可能性がある。そして、それまではリスクに対して堅牢であったのに、ソフトウェアを変更したことによって堅牢性が失われ、これまでブロックできていた  Hazardous Situation が現実になり、そこから思いもよらない大規模な障害が発生するという事態もありうる。


そうなることを防ぐためには、ソフトウェアの複雑性の特徴を考慮して、安全対策の評価やコンポーネント、エレメントの分割と独立性の評価が不可欠であると考える。

まだ、規格要求を読み始めたばかりだが、その部分の考慮が足らないと感じる。