※1 危険、リスクは思いもよらないところに潜んでいるので、自分が作ったソフトウェアが危険にはまったく関係ないと思っていても、思わぬ事故が起こることはよくある。安全ソフトウェアを目指す仕事をしていると、どんなリスクがあるが臭いで分かるようになる。
そして今では、安全とは何かについての考えが深まっていない人々に対して、どうすれば安全の概念についての考えを深めることができるのかを伝えることが自分の責務だと考えるようになった。
Microsoft の社員の肩書きで Evangelist（エバンジェリスト：伝道者）というのを見たことがあるだろう。上に書いた役目は Journalist とか、Consultant ではなく、Evangelist が一番ぴったりくるかもしれないと思っている。
宗教じゃないから伝道という言葉はあまり好きではないが、人間はコンピュータのように常に論理的とは限らないから、熱意を持って伝えないと伝わらない。自然科学ではない、ソフトウェアに対する考え方は、説明ではなく伝道でないと伝わらないことを Microsoft はよく分かっているから、その道のエキスパートに Evangelist を名乗らせているのだと思う。（洗脳者のような胡散臭い感じもするが・・・）
安全について理解を深める
世の中で数学や物理、化学など再現が可能で証明できる定理はたくさんある。一方で、答えが同じにならないこともたくさんある。人間が作るソフトウェアに関することはほとんどがそうだし、安全に関する概念、定義も同様に絶対的なものは存在しない。そこで、何をもとに安全(Safety）を説明すべきかずっと考えていた。実は、ISOやIECの国際規格でさえ、定義に矛盾や背反が存在する。
業務ドメインの違いによって対立軸がある場合もある。例えば、IEC 61508 に代表される機能安全のグループと ISO 14971 や IEC 60601-1, IEC 62304 といった医療機器関係の国際規格には考え方の違いがある。
安全(Safety）に対する概念は機能安全系の規格と医療機器系の規格では差異があるかもしれないということだ。（詳細に比較、検証したことはない） 国際規格を検討しているグループは、常に規格間の概念の差異や用語の定義の相違を是正すべく、努力を続けている。国際規格は一度決めたら終わりではない。常に生きているのだ。逆に言えば、国際標準でさえ、統一されていない考え方、主張も現実にはあるということである。
そういう現状があるから、医療機器系の安全(Safety）の概念をごり押しするような伝道では、自動車、鉄道、航空宇宙等のドメインの方達に受け入れてもらえないであろうと思っている。
そこで、考えたのが ISO/IEC Guide 51:1999 Safety aspects — Guidelines for their inclusion in standards (JIS Z 8051:2004 安全側面-規格への導入指針) を使って説明する方法だ。
ISO/IEC Guide 51 は、規格に安全に関する規定を導入する際に参照され、機械、電気、医療、科学など幅広い分野で作成される安全規格に適用されるガイドラインである。
だから、ISO/IEC Guide 51 は言わば、機械、電気、医療、科学に関する国際規格の上位に位置するガイドラインだ。そして、日本には、ISO/IEC Guide 51 の解説者として著名な明治大学の向殿政男先生がいる。向殿先生が監修されている『安全設計の基本概念』には、ISO/IEC Guide 51 のことが非常に丁寧に分かりやすく説明されている。
自分はこの本を引用しながら、ISO/IEC Guide 51が定義する安全の概念について、ここに記そうと思う。
安全の定義とは
下記の文章は記事の執筆を依頼されたあるガイドラインにために書いた原稿の一部で、安全の定義について説明した文章なのでまずは読んでみて欲しい。安全（セーフティ）とは、〔ISO/IEC GUIDE 51:1999〕によれば，『受容できないリスクがないこと』と定義される。すなわち、安全（セーフティ）は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。
安全はリスクを経由して定義され、リスクはその時代、社会の情勢、環境によっても変化するため安全の尺度を一定にすることはできず、絶対的な安全を定義することはできない。そのため、製品、プロセスまたはサービスは相対的に安全であるとしか言えない。
安全は、リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは、使用者の利便性、目的適合性，費用対効果、並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって、許容可能なリスクは常に見直す必要がある。
技術及び知識の両面の開発が進み，製品，プロセスまたはサービスの使用と両立して、最小リスクを達成できるような改善が経済的に実現可能になったときは、特に見直しが必要である。安全（セーフティ）は『受容できないリスクがないこと』だから、リスクを想定しなければ、また、リスクを想定できなければ、安全を確保することはできない。安全に関して伝道したいことの中で最も重要なことがこれだ。
「具体的なリスクを想定しないでソフトウェア品質やソフトウェアの信頼性について語る人」「具体的なリスクを想定しないで、実装すると効果がある対策、方法論があるという人」「具体的なリスクを想定しないで、開発に採用すると効果があるツールであると主張する人」がいる。
これらの人達は安全（セーフティ）について語っているのではない。安全（セーフティ）を実現するためのリスクコントロール手段を説明しているのではない。
ソフトウェアの品質の向上施策・信頼性向上について語っているのだ。Quality（品質） や Dependability（信頼性）, Reliability（信頼性）の話であって、Safety（安全）の話ではない。
ISO/IEC Guide 51より、安全性と信頼性の違いについての記述を引用する。
信頼性は機器で言えば、故障せずにその機能を正常に保つことを目標にするものであり、一方、安全性は人間に危害が及ばないように機器が機能し、使用することができることを目標としている。
もちろん、故障しないで本来機能を発揮することにより安全性を確保することが望ましいが、故障しても安全性を確保する設計が安全設計では望まれる。これにより信頼性と安全性は異なる概念であることが分かる。
また、すべてのリスクに対して有効に働くリスク低減手段は存在せず、個々の製品、プロセスまたはサービスに対してリスクアセスメントを行った上でリスク低減策を設計しなければ安全は確保できない。製品、プロセスまたはサービスに対する品質向上施策は信頼性向上には効果があっても安全性向上にも効果があるとは限らない。これは品質が高いことと安全であることは同位ではなく、品質の概念と安全の概念の間にも異なる観点が存在することを意味している。
なお、『ソフトウェア品質知識体系ガイド―SQuBOK Guide』には、品質についての定義がいくつも紹介されている。品質を価値と考え、安全は価値の一つであると定義すれば、安全は品質に包含されるのかもしれない。しかし、品質は概念が広すぎて、品質向上施策の御旗が何でもありのように安易に使われてしまう危険性を感じる。
抽象を尊び、具体を卑下する人たちをたまに見かけることがあるが（「そんな具体的な話しかできないのかよ」とか「○○理論も知らないのか」という目をされるとき）、それは間違いだ。抽象化はより多くの具体を取り扱うための手段であって、目的は具体の解決の中にある。具体に踏み込まず抽象のレイヤーで議論を終始している者は「おお、何か難しいことばを使って説明している」と一見カッコ良く見えるが、社会に貢献するためには具体の中にある問題を解決していかなければ意味がない。
この記事を読んでおられる読者は「抽象だろうと、具体だろうと、信頼性を目指しても、安全性を目指しても、結果的にやることは同じだろう」と思われているかもしれないが、それは違う。その違いを伝えるのが伝道師の役目だ。
分かりやすい例で言えば、鉄道では何かあったとときは列車、電車を止める制御をすれば安全を確保できる。（登山鉄道とか崩れかけた鉄橋の上といった危険状態ではその限りではないかもしれない） しかし、飛行機が空を飛んでいるときのリスクコントロール手段は飛行機を停止させることではない。飛行中に何か異常があった場合は、緊急着陸するまで飛行機を飛ばし続けなければいけない。鉄道のように止めてはいけない。同じ、輸送手段であっても、リスクや危険状態（Hazardous Situation）によって、リスクコントロール手段（Risk Control Measure)は異なるのだ。
例えば、車のエンジンサイズまで、容量を小さくした超小型の原子力エンジンが発明されたとする。（現実の世界では原子力空母の中に原子炉がある）
爆発すれば被害は甚大だが、20年間燃料の補給が不要で安全性も完璧だという触れ込みで発売されたとする。原子力エンジンの製造メーカーは、異常時には超小型原子炉を停止させる独立した安全装置が付いているので、どんな用途にも安全に使えると宣伝した。
※この話は、ISO 26262 に対応していると主張する CPU や、コンパイラ、ツールをセールスしている会社のメタファーだ。
しかし、最初の例示したように、この超小型の原子力エンジンの安全装置は飛行機のリスクコントロールには使えない。安全に原子力エンジンを停止すれば、飛行機が墜落してしまうからである。
飛行機の製造業者はそんなことは百も承知なので、例えば、エンジンを2機積むなどしてリスクをコントロールするだろう。（現実にもそうだ）
伝道師が強調したいのは、安全は最終製品に対するリスクを想定できるもののみが達成できるのであり、ソフトウェアの Quality（品質）やDependability（信頼性）, Reliability（信頼性）のみを語る人には、安全は達成できないということである。(エンドユーザにとってどんなリスクが有りうるかを想定していないから、対応策がリスクを受容するに十分かどうか判断できない。すべてのリスクに対応できると言うならそれは銀の弾丸だ。)
だから、ISO/IEC GUIDE 51:1999 では安全を『受容できないリスクがないこと』と定義したのだ。設計者や機器のオペレータができるのは「リスクを許容可能なレベルまで低減させる」ことだけだ。リスクをゼロにすることはできないし、できると考えてはいけない。福島の原子力発電所の事故の経験がそれを裏付けている。
そして、、ISO/IEC GUIDE 51:1999 には「許容可能なリスクは、使用者の利便性、目的適合性，費用対効果、並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって、許容可能なリスクは常に見直す必要がある。 」と書かれている。
この常に見直しをする必要があるというところが重要なポイントである。下記の図を見て欲しい。これは、ISO/IEC GUIDE 51:1999 に掲載されているリスクアセスメント及びリスク低減の反復プロセスの図である。
 |
| リスクアセスメント及びリスク低減の反復プロセス |
なぜか。リスクはその時代、社会の情勢、環境によって変化するからである。
だから、これで完璧と思ってもそのリスクコントロール手段は時代や社会、環境の変化によって更新しなければいけないかもしれない。
アクティブ・セーフティとして代表的なABS（アンチ・ロックブレーキ・システム）も、ほとんどすべての車に装備されてしまったら、ユーザはさらなる対策を求める。
だから、リスクアセスメントとリスク低減はその市場で商品を売り続ける限り、ずっと繰り返さなければならない。
だから、安全が求められる商品は価格は高い。潜在的な価値を維持するためにコストがかかるからだ。そのコストを削ろうとすると、安全の実現に暗雲が立ち込める。(放射線治療器の Therac-25 の事故の例がそれに相当する。経済的利益を優先させた会社の判断が事故を生むトリガーになった。セーフウェアを参照のこと。)
そして、価格が高い=高利益だと思っても、セーフティ・クリティカルな商品を扱う市場への新規参入が簡単ではない。なぜなら、新規参入企業は「リスクアセスメント及びリスク低減の反復プロセス」を反復したことがないからだ。
簡単に言えば、安全に関するノウハウがない（フィードバックすべき市場情報=多くは製品の不具合情報）ので、このプロセスを回せない。
だから、各製品群ごとに安全に関する国際規格が存在する。機器の安全に関する国際規格は、リスクアセスメント及びリスク低減の反復プロセスを回したことがない企業が、いきなりもの作りをして危険な製品を作らないためのハードルであり、保険である。
逆に言えば、その商品群において、要求された安全規格をクリアすれば最低限の安全を確保できる可能性は高い。（規格を作っている人達は機器の使用環境とリスクを十分に想定しているのに、規格には危険状態：Hazardous Situation のことはあまり書いておらず、リスクコントロール手段しか書いていない点は問題だと思っている。）
ところが、ソフトウェアが絡むとそう簡単ではない。これをやれば安全という銀の弾丸のようなリスクコントロール手段はない。（最近の ISO 26262 絡みのセールスを見ていると、かつての『人月の神話』を別の形で繰り返しているように思える）
しかし、何もしないで放っておく訳にはいかないので、ソフトウェア開発プロセスによるアプローチを定義することになる。これは現在のところ、どの業務ドメインでも同じようだ。開発プロセスを管理することでしか、ソフトウェアの品質は管理できないというのが、ソフトウェア品質論の定説となっている。（『ソフトウェア品質論の歴史的推移』を参照されたし）
そこで、ソフトウェアに関する安全規格が作られると、プロセスアプローチの面が強調され、リスクアセスメントやリスクコントロールの重要性が飛んでしまう傾向を感じる。（医療機器ドメインは今はそうはなっていないが常に危険にさらされている。）
そして、業務ドメインに依存しない ソフトウェアに共通の ISO/IEC 25000. System and software product Quality. Requirements and Evaluation (SQuaRE） のような規格や、CMMI(Capability Maturity Model Integration) が、安全(Safety）にも有効だと語る者が現れる。（正確にはすべてのソフトウェア開発に有効だという主張）
業務ドメインに依存しない商品、ツール、方法論が存在すれば、セールスが楽で、売り上げ向上が見込めるためみんなその路線に乗ってくる。
しかし、安全ソフトウェアの伝道師はここで釘をささなければいけない。それは、Quality（品質）やDependability（信頼性）, Reliability（信頼性）のことを言っているのであって、Safety（安全）とは異なると。
安全を確保するためには、リスクアセスメント（ハザードの特定、リスクの見積もり、リスクの評価）とリスク対策を繰り返し行わなければいけない。一度では終わらないし、ずっと続けなければいけない。
だから、言いたいのは、Quality（品質）やDependability（信頼性）, Reliability（信頼性）向上の方法論を知っている人、組織、研究者は、安全が必要な製品を開発している企業とタッグを組んで、「リスクアセスメント及びリスク低減の反復プロセス」が効果的にまわるように助けてあげて欲しい。
それは、泥臭く、効率が悪く、面倒くさいかもしれないが、それをしないと製品の安全は向上しない。そして、かつての日本ではそんなアプローチが盛んに行われてきたと聞く。詳しくはしらないが、品質機能展開は製造業者の問題解決と共に発展してきたと思うし、QCサークルだってそうだろう。
いつから日本のエンジニアは、銀の弾丸を買うこと（=方法論を一方的に受け入れる）しかしなくなってしまったのだろうか。
それと、日本の企業はソフトウェア絡みの事故情報を自分達だけで抱えて秘密にしておくなと言いたい。出せるものは出して、その情報を他の業界や研究者と共有し、再発防止策を提案していかないからいけないのだと思う。
安全対策の技術を向上させるために絶対に必要なのは、事故の詳細な情報だ。これは歴史が証明している。
- スペースシャトルチャレンジャーの事故分析（宇宙）→ロケット開発に対する教訓
- ミニッツロケットの安定化（軍事）→FTAの発明
- ピントの事故（自動車）→FMEAの普及
- Therac-25（医療機器）→医療機器のソフトウェア開発に対する教訓
自慢しいだと思われるかもしれないが、これは、過去に起きたソフトウェアが絡んだ医療機器のリコール情報を分析し、医療機器のソフトウェア開発プロセスの規格である IEC 62304 のどのアクティビティ、タスクが事故の再発防止の効果があるかを分析した Industrial Paper だ。
自動車だって同じことができると思う。ソフトウェア絡みの自動車の事故に対して、ISO 26262 を適用したら事故は防げたのか、どのプロセス、アクティビティが有効なのかを分析してみて欲しい。
自分は、ISO 26262 の中で、Part 8: Supporting processes（支援プロセス）の「ソフトウェア・ツールの使用への信頼」のところが最も役に立たないと思っている。なぜなら、これまで述べてきたように、ツールに対する信頼は、具体的なリスクを想定していないので何のリスク低減に有効なのかが分からないからだ。すべてのリスク低減に効くという論理は銀の弾丸と同じであることは説明するまでもないであろう。
例えば、下記は2005年にアナウンスされたあるメジャーな会社のCPUのコンパイラの不具合通知である。（cpuが特定できないように所々伏せている）
2.3 配列要素への代入式の注意事項「if文の前とthen節内で、同じ配列への代入文が存在するとき、その配列の値 が正しく代入されない場合があります。」などと、とんでもないことが平然と書かれているが、現実にこういう連絡はたまにある。正直に連絡してくれているから逆に信頼が持てる。お客に知らせないでしらばっくれることだって可能なのだ。不具合情報の連絡は保守契約の中に条件が書いてあるはずだが、日本の会社は保守契約書に書いてあるかどうかよりも、現実に対応しているかどうかの方を重視している。
if文の前とthen節内で、同じ配列への代入文が存在するとき、その配列の値
が正しく代入されない場合があります。
発生条件: 以下のすべての条件を満たす場合に発生します。
1. cpu=○○ または、△△
オプションを選択している
2. optimize=1オプションを選択している
3. 繰り返し文の中に選択文(else節のないif文)がある
4. if文の前と(3)のthen節に同じ配列要素への代入式がある
5. if文の前の代入式の右辺を"式1"、if文内then節の代入式の右辺を"式2"
として、式1、式2の型が異なっている
6. 5.の式1と式2は、以下のいずれかを満たしている
-式1が式2の型で表せる範囲外の値をとることがある
-式2が式1の型で表せる範囲外の値をとることがある
例:
-------------------------------------------------------
#define MAX 10
int A[MAX];
int x, y, z;
char sc0, sc1, sc2;
test(){
int i;
for(i = 0; i < MAX; i++){
A[i] = x + y; /* 発生条件4, 5および 6 */
/* if(z)がFALSEになるときに配列A[i]にx+yの値が
正しく代入されない */
if(z){ /* 発生条件3 */
A[i] = sc0; /* 発生条件4, 5および 6 */
}
x++;
y++;
sc0++;
}
}
-------------------------------------------------------
回避策:
以下のいずれかの方法で回避してください。
(a) optimize=0オプションを選択する。
(b) then節にnop()組み込み関数を入れる。
発生例の回避例
-------------------------------------------------------
#include
. . . . . . . . . . . . . . . . . . . . . . . .
if(z){
nop(); //組み込み関数の追加
A[i] = sc0;
}
-------------------------------------------------------
(c) else節を用意し、nop()組み込み関数を入れる。
発生例の回避例
-------------------------------------------------------
#include
. . . . . . . . . . . . . . . . . . . . . . . .
if(z){
A[i] = sc0;
} else{
nop(); /* 組み込み関数の追加 */
}
-------------------------------------------------------
(d) 式1とif文の間にnop()組み込み関数を入れる
-------------------------------------------------------
#include
. . . . . . . . . . . . . . . . . . . . . . . .
A[i] = x + y;
nop(); /* 組み込み関数の追加 */
if(z){
A[i] = sc0;
}
-------------------------------------------------------
この不具合情報をよく見ると、最適化オプションを選択したときのみ発生するとある。そういう危険性があることは勘で分かっているため、製品開発では最適化オプションはオンには絶対にしない。だから、このコンパイラの不具合情報が来たときも、自分達の開発では「セーフ」だった。
仮に最適化オプションをオンにしていたとしても、こんな複雑な条件に合致することはないだろう。ただ、絶対にそういうプログラムを書かないという保証はないし、安全クラスが高いソフトウェアアイテムで起こったらとんでもない話だ。
すでにリリースしてしまった製品のソフトウェアで落ちてきた売り上げを少しでもアップするためにソフトウェアを追加、変更して欲しいという要求がセールス部門から上がってきたとする。でも、古い製品でROMの領域がほとんどない。「じゃあ、コンパイラのサイズ最適化のオプションをONにするか」などというシチュエーションがあっても不思議ではない。
そのとき、経験を積んだプロジェクトリーダーはその要求を断固拒否するか、コンパイルオブションをONにしないで何とかする方法を考える。こういうオペレーションをISO 26262はプロセスで要求できるのか？と言いたい。
エンジニアはこの3Eで危険を抑えているのではないか。
【安全を実現するには3Eが必要】
- Experience（経験）
- Education（教育）
- Enthusiasm（熱中、熱意、情熱、こだわり）
あったら困るが、見つけることは極めて難しい。それが、現実のソフトウェアの不具合だ。だから、そのようなソフトウェアの不具合を一律に抑えようとするのは賢いやり方ではないと思う。勘や経験、実績も総動員して防がなければいけないが、一番有効なのはリスクアセスメントとリスクコントロールである。
この例を提示した理由は、コンパイラの不具合は発生したとしても、ものすごく複雑な条件で起こるということを示したかったからである。
普通に使っていて、期待しないコードが吐き出されるようなコンパイラを、クリティカルな製品に使うはずがない。どのコンパイラを使うかどうかの判断で、一番確からしいのは使用実績だ。ようするに信用である。ただ、信用だけでは判断できないのが、大規模・複雑化した現代のソフトウェアなのだ。普通の使い方をして問題が起こるようなソフトウェアを平気で出すような会社は日本ではほとんどないと思っている。
だから、何か危険な爆弾が潜在していたとしても、上記のようなものすごく複雑な条件で不具合は発生する。そういう不具合が発生する可能性があるのかないのかは、何で判断するべきか。
それは、対象物の検証結果、テスト結果で見るべきだろう。間違っても、認証のあるなしのようなお墨付きで判断してはいけない。ようするに、どんなテストケースで、どんな判定結果でテストを行ったのか、どんな異常状態を想定してテストを行ったのか、要求仕様に対してどれくらいのカバレッジでテストをしたのかで判断することが大事だ。
このことは、TechVillage に『クリティカル・システムに使う市販ソフトウェアの検証方法』というタイトルで記事を掲載しているので、そちらを読んいただきたい。
ISO 26262-8 Supporting processes（支援プロセス）「ソフトウェア・ツールの使用への信頼」では、ちっとも安心できないというのが自分の意見だ。なぜなら、検査対象によって何を検証すべきかを求めていないからである。つまり、そのツールが使われる場面の具体的なリスクを想定しなくても、パスできる要求だから安全には使えないと思っている。
上記のような、非常に分かりにくい不具合を事前に見つけることはとても難しいと予想する。この報告書群は一度キチンと精査したいと思っているが、規格や方法論を使うことが目的になっていないだろうか。自分にはこれらの報告書を読んでも、執筆者達のソフトウェアが絡む自動車の事故を減らしたいという熱意がまったく感じられない。
報告群の随所で「方法論を適切に使用している」ことで目的（説明責任）が果たせているというくだりを見かける。それは方法論を使うことが目的なのであって、エンドユーザーの利益、エンドユーザーの安全が目的になっていない。規格を使うこと、方法論を使うことが目的なのだ。「こんだけ難解な規格を使いこなしているぞ」「こんなに難しい方法論を使っているぞ」ということを一所懸命主張している。「難しい問題を解くことができました、すごいでしょ。」と言っているように見える。それって、社会に対して何を貢献しているのだろう。
ちなみに、報告の中には具体的な事例が載ってるものもある。しかし、事例が例示されていても、すでに安全を確保できているシステム、制御方法を対象とする規格や方法論で分析し直したようにしか見えない。現在、発生している事故、未来に発生する危険性があるリスクを未然に防ぎたいという目標があるだろうか。
自動車事故を減らすための取り組み
TBSラジオ、森本毅郎 スタンバイ！で東京大学名誉教授の月尾嘉男先生が話されていたのは自動車事故によりなくなる人は世界中で年間150万人でそのほとんどが自動車の整備不良なのではなく、運転者の不注意などという事実だ。日本では、交通事故による死亡者数は減少しており、2009年からは5000人を切っている。だから、問題の多くは日本の外で起こっているのだ。
この数字を突きつけられると、ブリクラッシュ・ブレーキシステム への自分の後ろ向きの発言は変えていかなければならないと感じる。年間、150万人の自動車事故による死亡者を減少させる取り組みには意味がある。それは目指すべき目的となる。
このブログでも取り上げた、制動制御が複雑化したことによる予期せぬ動作に対する責任は運転手ではなく、自動車メーカに問われるようになる。その責任の所在、責任の取り方についての議論は、制御システムの開発、改善とは別の次元で進めなければいけない。
そして、制動制御の複雑化が、基本性能、基本機能に悪影響を与えないようにする責任は技術者にある。ソフトウェアの複雑化による Systematic failure のリスクよりも、年間150万人の死亡事故を減少させる社会的な意義の方が大きい。
ただ、だからといって何も考えずに既存のソフトウェアに新しい機能を付け足すアプローチを取ってよい訳ではないので、どうすれば想定したリスクを受容しながら、リスクコントロール手段としてのソフトウェアアーキテクチャを崩すことなく、新しく追加した意図した使用(Intended Use)を達成できるのかを考えないといけない。
USのネバダ州では無人運転車にライセンスを付与できることにした。Googleが第一号を取得し、Google Map用に無人運転車がすでに50万キロ走り、無事故であるという。
技術革新は表の面は華々しいが、当たり前に問題が起こらないようにする努力は裏でやり続けないといけない。
技術革新は表の面は華々しいが、当たり前に問題が起こらないようにする努力は裏でやり続けないといけない。
ソフトウェアに関するリスクコントロール手段に関して足らないのは、複雑性に対応するための方法論だと思う。ヒントは下記の表にあるはずなので、有効な方法を考えて、現実の製品に適用し、本当に事故が減るのかどうか、リスクアセスメント及びリスク低減の反復プロセスを繰り返す。これが自動車業界が行うべきことではないか。
対象
|
内容の例
|
何を”
（保護対象）
|
人の健康，身体，命
|
人の心の安定，安心
|
|
金銭，財産
|
|
機械，システム，プロセス，ネットワーク
|
|
情報，データ，品質
|
|
“何から”
（安全を脅かす原因，脅威）
|
機器のハードウェアの故障・劣化，ソフトウェアのバグ
|
地震，雷，台風
|
|
ヒューマンエラー，設計ミス，誤解など，機械を取り扱う人間側の過誤
|
|
破壊，ハッカー（厳密にはクラッカー），テロ，なりすまし，盗聴，などの人間の悪意のある行動
|
|
設計以外の負荷，通信の輻輳などの過負荷
|
|
大規模化，複雑化，ブラックボックス化などによる複雑性
|
|
時代（年代ギャップ，バージョンアップによるギャップ），文化（異文化ギャップ），などに起因するコミュニケーション不足
|
|
環境変化（景気の変化，社会の変化，時代の変化など）
|
|
“何により”
（対策）
|
高信頼性部品等を使用することで機械そのものを故障しないように作る。（フォールトアボイダンスと呼ばれる技術）
|
ソフトにバグが入り込まないように，設計に誤りが入り込まないように作る。（人間の設計ミスを少なくする技術）
|
|
冗長技術を利用する。（フォールトトレランスと呼ばれる技術）
部品や設備を二重化，三重化することで，一つが駄目になっても他のもので補う構造を採用する。（空間冗長）
何回か繰り返したり，やり直したりすることで正しいことを確認する。（時間冗長）
誤っても訂正可能なように情報を付加しておく。（情報冗長）
|
|
設計の段階から安全を考慮する。
危険の安全を最初からないように作る。（本質安全設計）
機械が故障しても安全なように配慮して設計する。（フェールセーフ設計）
人現が間違えても安全なように配慮して設計する。（エラープルーフ設計）
テストや保全が容易なように設計する。（テスト容易化，保全容易化設計）
監視機構，チェック機構等の機構を導入する。
事故が起きたときに被害が広がらないように設計する。
|
|
人間の注意により安全を確保する。（注意・訓練，マネジメント，組織，管理等による方法）
|
|
制度により安全を確保する。（法規制，標準化，認証制度，保証制，保険制度等による方法
|
ISO 26262 も リスク低減の反復プロセスの中で、規格が求めている要求事項のどれが有効に働いたのかを検証し、有効に働いたところを強化し、働かなかったところを削除していくことが必要だと思う。
ボーイング787に搭載したリチウムイオン電池の発火事故の原因が現在調査されている。一説には、飛行機の振動が当初の設計時の想定を超えるものであったと聞く。リチウムイオン電池はそもそも高エネルギーを蓄えることができ危険性が高いといわれていたが、安全設計、安全装置を施すことで、大きな問題を押さえ込んできた。しかし、想定を超える環境下での使用があったのかもしれない。
ハードウェアの問題は、リスク低減のプロセスを回し、安全対策を積み重ねることで、安全の成熟度を増すことが可能だ。しかし、ソフトウェアで問題が起こるたびに、安全対策と称して追加、変更を繰り返すのはきわめて危険だ。
ソフトウェアの複雑性は非常にわかりにくい不具合を作り込んでしまう危険があるからだ。だから、ソフトウェア搭載機器の安全を保つためには、ソフトウェアによるリスクコントロールの設計技術と、安全を考慮したソフトウェアシステムのアーキテクチャ設計が崩れていないことを監視し続けることが大事である。
ここで記事にした内容に具体的なリスクアセスメント、リスクコントロール手段の方法論の解説をプラスして SESSAMEの 1Day セミナーに仕上げ、6月に東京で実施することを計画している。（SESSAME へ企画提案済み）
安全ソフトウェアのエバンジェリストとしての役目を果たしていきたいと思う。（東京だけでなく）
0 件のコメント:
コメントを投稿