年末も近づいてきたのでブログ上での自分を振り返ってみようと思う。
ISO 26262 との向き合い方1回目の記事を書き始めたのが、2011年の12月からだからちょうど1年になる。
ブログでは誰かを批判的に書くことはできるだけしないように気をつけているつもりでも、どうしてもこの話題を取り上げると、ISO 26262 で商売をしようとしている者を批判的に書いてしまう。
そういう口調になってしまう理由は、安全な商品を提供しようと努力している日本のエンジニアが自分たちがやってきた良いことを認識できずに、外から言われるがままに欧米で培われたやり方に心酔し、これまでの自分たちのやり方をあっさり方向転換して、結果的にこれまでより商品の価値を低くしてしまう間違いを何とか防ぎたいと思っているからである。（欧米からの思想、方法論もよいところは取り入れ、説明責任を果たすために、本音と建て前をどう使い分けるべきかを考えて欲しい。）
でも、そう言いながら、自分自身がソフトウェアの安全設計に関するコンサルテーションを生業とする可能性は将来あるかもしれない。
万が一そうなったら、自分がさんざん批判的に書いてきた方の立場の側に身を置くことになるかもしれない。そんな状況は自分自身の信条に反するので決してないと思うが、未来の自分の進路を狭めることにつながるので、世渡りの上手な賢者はブログで誰かを批判するとは決してしない。
また、自分は『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事で紹介した「評論家くん」にだけは絶対なりたくないと思っている。常に問題解決キッズでなければいけない、そうなりたいと思っている。
このブログではできるだけ自分自身をエンジニアの当事者として一人称で書くように努めているつもりだ。だからこそ、時にエンジニアにとってプラスにならないと思うと、批判的に書いてしまうことがある。
そういうとき、自分は評論家くんになっていないかと自問自答することがある。評論家的に言うことは簡単だが、じゃあ、クライアントとなるエンジニアを安全設計エンジニアとして自立させ、価値の高い商品をアウトプットできるように育てられるのかと自分に問うたときに、ドメイン違いではなかなか自信は持てない。
また、ISO 26262 で商売をしたい、売り上げを伸ばしたいと考えている組織、営業、コンサルタント、ツールベンダーがクライアントをだまそうと悪意を持って行動しているわけではない。彼らは彼らで自分たちが正しいと思って行動している訳だし、生きていくため、景気がまだよくない中、売り上げを上げたいと必死に努力しているだけなのだ。彼らのサービスを受ける側の当事者でないのなら、その活動を妨害する権利はないようにも思う。
賢明な当事者の技術者は、いろいろな誘い、セールスに対して選択することができる立場にある。正しい判断ができない者は、後に間違いに気がつくか、競争の中で淘汰されるだけなので、余計なお世話を焼かない方がよいとアドバイスしてくれる人もいる。
ブログへのアクセスはきっちり分析しているので、コンサルタントとおぼしき組織から頻繁にアクセスがあることも分かっている。
ということは、エンジニアに向けて情報発信しているつもりが、エンジニアを言いくるめるネタを彼らに提供しているだけではないかと思うこともある。このブログサイトで学習しているのは、エンジニアではなくコンサルタントでは？と思うこともある。
まあ、何はともあれ、読者となっているエンジニアが関わっている商品のエンドユーザに対する価値向上に役立つ記事を書いているはずだと信じて続けていくしかないのだろう。
これ、英語圏ならもっと読者レスポンスがガンガンあるはずなので何とか英語で情報を発信できるようにしたいとういのが将来の目標である。
このブログ、Google Adsense で広告掲示すると利益が出ますよと Google からアドバイスされるのだが、批判的な記事を書いている対象の企業の広告が出ていたりすると、洒落にならないので、その誘惑だけは断ち切るようにしている。
第二次世界大戦の時代を生き抜いた妹尾河童の自伝的小説「少年H」で、戦時中威張っていた学校の教師が、敗戦、民主主義の社会になったとたんに態度を一変させるくだりを読んで、そういう立場が変わって手のひら返すような人間には絶対になりたくないと思う一方で、そういう自分の弱さを認めたり許容できないかっこつけの考え方が人間の幅を狭くしているのだと考えることもある。
単なるブログではあるが、書く方もいろいろ悩みながら書いているのだ。
今年のブログの反省点はこんなところかな。
2012-12-17
工業会主催のホンモノのセミナーが開催されるようです
Google Alarm で 「ISO 26262」とキーワード登録しておくと、いろいろなニュースが引っかかる。
「またかぁ」というものが多いが、これは参加する価値があるセミナーだと思う。
東京：2013 年2 月6 日（水）～8 日（金）3 日間
名古屋：2013 年2 月18 日（月）～ 20 日（水）3 日間
「ISO 26262 規格原文読み込みワークショップ～ISO 26262 の要件を原典で理解できる！」
なぜ、そう思うかというと、主催が（公社）自動車技術会（そのドメインの工業会）で講師が規格の適合を目指す当事者側の方たちだからだ。
テキストが規格の対訳で全部そろえると10万円くらいかかるが、本気で取り組むつもりなら持っていないと話が始まらないのでしようがないだろう。
「またかぁ」というものが多いが、これは参加する価値があるセミナーだと思う。
東京：2013 年2 月6 日（水）～8 日（金）3 日間
名古屋：2013 年2 月18 日（月）～ 20 日（水）3 日間
「ISO 26262 規格原文読み込みワークショップ～ISO 26262 の要件を原典で理解できる！」
なぜ、そう思うかというと、主催が（公社）自動車技術会（そのドメインの工業会）で講師が規格の適合を目指す当事者側の方たちだからだ。
テキストが規格の対訳で全部そろえると10万円くらいかかるが、本気で取り組むつもりなら持っていないと話が始まらないのでしようがないだろう。
2012-12-09
ISO 26262との向き合い方 (19) 事故の再発防止について考える
エンジニアができることやらなければいけないことは、一つは事故が起こらないようにリスクを分析し設計に活かすこと、そしてもう一つは事故が起こってしまったときに再発をしないような仕組みを作ることである。
むろん、規格に適合することが目的ではない。エンジニアには安全を確保するために今よりも前進できるかどうかが問われている。
よって、エンジニアは評論家のように単純に批判を繰り返すだけではいけない。「自分の関わっている製品、システムだったら」という観点で考えなければいけない。
設計 FMEA を実施した例
笹子トンネルの天井崩落事故について、エンジニアが考えなければいけないのは、まずは、FMEA(Failure Mode and Effect Analysis)の視点である。つり金具の老朽化が疑われているようだが、システム（今回の場合はトンネルの天井構造）の構成部品の故障モード（つり金具の脱落もその一つ）が起こったときの次の項目についての分析が必要となる。下記に設計FMEAを実施した例を示す。
【設計FMEAの分析項目例】
- 故障モード（具体的に）
- 故障原因
- 故障の影響：部分的影響
- 最終システムへの影響（天井の崩落）
- 故障検出方法（打音検査→それで正確に分かるのか）
- 故障の重要性（重要度は極めて高いことが分かっている）
- 故障の発生頻度（過去にどれくらい発生したことがあるか）
- 対策案
- 検出難易度
- 致命度ランク（重要度×発生確率×検出難易度）
※設計FMEAの分析項目はこうでなければいけないという決まりはない。形式にとらわれないことが大事である。
【設計 FMEA の分析のしかた】
FTA に見られるトップダウンの安全分析方法に対して、FMEAはボトムアップの解析手法と言われる。FTA が最終的に起こしてはならない事象をトップにおいて分析を始めるのに対し、FMEA では故障モードを左端において解析を進める。
よって、FMEA の使い方としては、市販前の製品の設計段階において故障モードを洗い出し分析、対策し、市販後に起こった障害や事故の故障モードの分析をそれに追加するという使い方をするのが一般的であろう。
[故障モード]
システムの構成部品が故障するときの状況について具体的に記述する。故障モードの前（左側）にシステム全体に対して、どの部分に関する故障であるかを示すための階層を追加することもできる。
例) トンネルシステム→天井部分→接続部
[故障原因]
故障モードが発生する推定原因を記載する。
[故障の影響：部分的影響]
故障が引き起こす部分的な影響、例えば「天井ユニットの脱落」を書く。
[故障の影響：最終システムへの影響]
部分的影響がもたらす最終システムへの影響の可能性を書く。
[故障検出方法]
故障の検出方法を書く。ちなみに「仕業点検」や「目視」という検出方法もあるが、故障の重要性が大きい場合、人間の目に頼る検出方法はお勧めできない。
[故障の重要性]
故障の重要性をシステム利用者が被る危害に焦点を当てて書く。
[故障の発生頻度]
故障の発生頻度を定量的（定量的に計算できない場合は、定性的）に記載する。数値化することが難しい場合のために、目安となる指標（頻繁に起こる、まれ、極めて少ないなど）をあらかじめ準備しておく。
[対策案]
具体的な対策を示す。設計上の対策を行うことがベストであるが、表記上の対策（説明書記載のラベリング）でしか対策できない場合もある。
[検出難易度]
故障モードを検出する難易度を示す。
[致命度ランク]
故障の重要性、発生頻度、検出難易度の3つのパラメータから致命度ランクを計算する。決まりはないため分析対象物やドメインに対して、判定基準をあらかじめ作成し、SOP(Standard Operation Procedure) に記載しておく。
今回のトンネル天井崩落事故の場合、注視すべき点は故障モードが起こす部分的な影響と最終システムへの影響である。つり金具の脱落という天井のユニット（板）に発生する部分影響が連鎖的に周りにユニットの崩落につながっていることを認識した上で再発防止の対策を考える必要がある。
事故が起こると「なんで、こんなことが分からなかったのか」と皆が思う。しかし、事故が起こる前に危険性を指摘すると「今から変えられない」とか「コストがかかる」とか「これまで起こっていなかった」という理由で動かない組織はたくさんある。
そのネガティブな組織判断をサイエンスとエンジニアリングによって突破するのがシステムの安全に対して責任を負うエンジニアの役目であり、それを組織的に支援・管理するのが品質マネジメントシステムである。
今回のような事故の場合、故障検出方法の設計、故障発生頻度、検出難易度の決定が再発防止に大きな影響を与える。実際には打音検査によるボルトの緩み等のチェックが行われているようであるが、人間の感性、感覚に頼る検査方法は本質的なリスクとは異なるヒューマンエラーのリスクを伴う。
FMEA の結果は、表にしなくても見識者ならだいたい思いつくような内容だ。しかし、FMEA を行う意味は、他のリスクと同様にある一定の手順に基づいて、故障によるリスクを分析することにある。
人間の記憶は時間と共に薄れていくものなので、知見を継承するためにも、同じ様式による分析結果を組織が保持することが大事なのだ。
FMEAには市場からのフィードバックとして修理情報や苦情情報などをインプットするため、設計 FMEA はどんどん積み重なっていく。故障モードや想定されるハザードは無限に存在するのでFMEA では追加対策自体が新たな Hazardous Situations を生み出したり、故障モードはハザードが多すぎて、どこの焦点を合わせたらよいかわかりにくくなる傾向を持つ。
そのため、故障の重要度、発生頻度、検出難易度から致命度ランクを計算し、これによって対策に優先順位を決めたり、重大な被害につながる故障に焦点を当てたり FTA を行うことで、対策が多すぎてコストや開発期間が優先になって、安全対策が後回しにならないようにする。
「トンネル内の火災により死傷者が出る」をトップ事象にしたときのFTA図につり金具の老朽化による天井の崩落の事象を追加した例を示す。
トンネル内の火災となる原因は他にもあるはずなので左記はほんの一部の現象を切り取ったに過ぎない。
FTA が FMEA に比べて優れている点は、起こしてはならないトップ事象に対して、想定した事象がどのように影響しているのかを容易に判断できることである。
別な言い方をするとどの事象が一発でトップ事象を引き起こしてしまうのか、また、どんな歯止め、どんなリスクコントロールが失敗するとトップ事象を引き起こしてしまうのかを把握しやすいということだ。
つり金具の脱落が金具の老朽化とボルトの緩みが原因だったとして、それが仮に起こったとしても、打音検査によって見つけることができれば事故を未然に防ぐことができるかもしれない。（FMEAのところでも書いたように打音検査はヒューマンエラーのリスクを含む）
よってつり金具の故障と打音検査の失敗が AND で重なったときにトップ事象に到達してしまう。このように、FTA では着目すべき事象が、他の事象とどのような関係性を持っているのか、どのリスクコントロール手段がトップ事象への到達を押さえているのかを把握するときに有効である。
FMEA によってリスクコントロール手段を次々と追加していった場合、それらのリスクコントロールがどのようにシステムを複雑にしているのか分析するときにも FTA が役に立つ。闇雲にリスクコントロール手段を追加していくと、かえってシステムの安全性を低下させることもあるので注意が必要である。
システム全体としてシンプルなリスクコントロールにより、トップ事象を起こさない(=安全を確保できる）ことを目指す。
左図は、ISO 14971(医療機器－リスクマネジメントの医療機器への適用)のリスクマネジメントプロセスの一部である。
注目して欲しいのは、10 の製造情報及び製造後情報のアウトプットが 5 のリスク分析のインプットにつながっている点である。
ようするにリスクマネジメントのプロセスはフィードバックすることが前提であり、リスク分析、リスク評価、リスクコントロールは製品やシステムが市場にある限り継続し続けなければならないのだ。
そのとき、FMEA や FTA は、リスク分析、リスク評価、リスクコントロール、残留リスクの評価、リスクマネジメント報告に各プロセスで利用することができる。
対象となる商品やシステムを取り巻くリスクは無限に存在する。リスクが無限に存在するからといって、リスク分析やリスクコントロールを永遠に続けることはできない。組織は有限なコストや開発期間のために、リスク分析をどこかで打ち切らざるを得ないのだ。
そのため、組織はできるだけ短期間にリスクを洗い出し、有効な対策を設計に活かす必要がある。それが上手くいけば、それらの対策は商品や組織のアドバンテージとなり、商品の潜在的価値を高めることにつながる。
ただ、残念ながらそのような努力を最大限行ったとしても、事故は起こってしまうし、時代とともにリスクに対する人々の感性は変わっていく。
だからこそ、上記のリスクマネジメントプロセスはフィードバックしなければならないのだ。
| 故障モード | 故障原因 | 故障の影響 | 故障検出方法 | 故障の重要性 | 故障の発生頻度 | 対策案 | 検出難易度 | 致命度ランク | |
| 部分的影響 | 最終システムへの影響 | ||||||||
| つり金具が折れるまたは脱落する。 | つり金具の振動、腐食による老朽化。 | 天井ユニットの脱落。 | 連結している天井ユニットの連鎖的脱落。 | 打音検査等による定期検査。 | 走行中の車両に当たると死に至る可能性がある。 | 全国のトンネルに付き、○○年に○回。 | 異常が発見された場合、一週間以内に補修し、トンネルあたりの修理数が○回を超えたら、○ヶ月以内に恒久対策を講じる。 | 中程度 |
最上 |
【設計 FMEA の分析のしかた】
FTA に見られるトップダウンの安全分析方法に対して、FMEAはボトムアップの解析手法と言われる。FTA が最終的に起こしてはならない事象をトップにおいて分析を始めるのに対し、FMEA では故障モードを左端において解析を進める。
よって、FMEA の使い方としては、市販前の製品の設計段階において故障モードを洗い出し分析、対策し、市販後に起こった障害や事故の故障モードの分析をそれに追加するという使い方をするのが一般的であろう。
[故障モード]
システムの構成部品が故障するときの状況について具体的に記述する。故障モードの前（左側）にシステム全体に対して、どの部分に関する故障であるかを示すための階層を追加することもできる。
例) トンネルシステム→天井部分→接続部
[故障原因]
故障モードが発生する推定原因を記載する。
[故障の影響：部分的影響]
故障が引き起こす部分的な影響、例えば「天井ユニットの脱落」を書く。
[故障の影響：最終システムへの影響]
部分的影響がもたらす最終システムへの影響の可能性を書く。
[故障検出方法]
故障の検出方法を書く。ちなみに「仕業点検」や「目視」という検出方法もあるが、故障の重要性が大きい場合、人間の目に頼る検出方法はお勧めできない。
[故障の重要性]
故障の重要性をシステム利用者が被る危害に焦点を当てて書く。
[故障の発生頻度]
故障の発生頻度を定量的（定量的に計算できない場合は、定性的）に記載する。数値化することが難しい場合のために、目安となる指標（頻繁に起こる、まれ、極めて少ないなど）をあらかじめ準備しておく。
[対策案]
具体的な対策を示す。設計上の対策を行うことがベストであるが、表記上の対策（説明書記載のラベリング）でしか対策できない場合もある。
[検出難易度]
故障モードを検出する難易度を示す。
[致命度ランク]
故障の重要性、発生頻度、検出難易度の3つのパラメータから致命度ランクを計算する。決まりはないため分析対象物やドメインに対して、判定基準をあらかじめ作成し、SOP(Standard Operation Procedure) に記載しておく。
今回のトンネル天井崩落事故の場合、注視すべき点は故障モードが起こす部分的な影響と最終システムへの影響である。つり金具の脱落という天井のユニット（板）に発生する部分影響が連鎖的に周りにユニットの崩落につながっていることを認識した上で再発防止の対策を考える必要がある。
事故が起こると「なんで、こんなことが分からなかったのか」と皆が思う。しかし、事故が起こる前に危険性を指摘すると「今から変えられない」とか「コストがかかる」とか「これまで起こっていなかった」という理由で動かない組織はたくさんある。
そのネガティブな組織判断をサイエンスとエンジニアリングによって突破するのがシステムの安全に対して責任を負うエンジニアの役目であり、それを組織的に支援・管理するのが品質マネジメントシステムである。
今回のような事故の場合、故障検出方法の設計、故障発生頻度、検出難易度の決定が再発防止に大きな影響を与える。実際には打音検査によるボルトの緩み等のチェックが行われているようであるが、人間の感性、感覚に頼る検査方法は本質的なリスクとは異なるヒューマンエラーのリスクを伴う。
FMEA の結果は、表にしなくても見識者ならだいたい思いつくような内容だ。しかし、FMEA を行う意味は、他のリスクと同様にある一定の手順に基づいて、故障によるリスクを分析することにある。
人間の記憶は時間と共に薄れていくものなので、知見を継承するためにも、同じ様式による分析結果を組織が保持することが大事なのだ。
FMEAには市場からのフィードバックとして修理情報や苦情情報などをインプットするため、設計 FMEA はどんどん積み重なっていく。故障モードや想定されるハザードは無限に存在するのでFMEA では追加対策自体が新たな Hazardous Situations を生み出したり、故障モードはハザードが多すぎて、どこの焦点を合わせたらよいかわかりにくくなる傾向を持つ。
そのため、故障の重要度、発生頻度、検出難易度から致命度ランクを計算し、これによって対策に優先順位を決めたり、重大な被害につながる故障に焦点を当てたり 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日の毎日新聞のニュースサイトに『トンネル崩落：中日本高速、米事故後も対応取らず』という記事が掲載された。
これは ISO 9001 （品質マネジメントシステム）のアプローチそのものなので、ISO 9001 を取得している組織はできるはずなのだが、ISO 9001 の認証を取得することが目的になっていると、事故が起こったときに本当にやらなければいけないことができない。（このブログで口を酸っぱくして言っているのは、ISO 26262 も同じで、規格に適合できても、安全を確保する能力が高まらないのであれば意味がないということだ。）
何か問題が起こったときに批判して評論だけするのが「評論家」くんで、Corrective Action をやりきれるのが問題解決キッズである。（人気の記事『問題解決能力（Problem Solving Skill)：自ら考え行動する力』を参照されたし。）
「評論家」くんは、何か事件が起こったときに鬼の首を取ったように生き生きと問題を指摘するが、再発防止にはあまり貢献しない。本来は火消しよりも、防火活動を地道に行っている者を組織は評価するべきだと思う。
修正（correction）はそのときだけの対策であり、是正処置（Corrective Action）は、根本原因を取り除くことで、将来に渡っても同様の問題を起こさない対策である。その違いを十分に認識できていないと、事故は再発してしまう。
事故発生後にその場しのぎの対策を取ってしまうことは根本原因を取り除くことにはならない。
高速道路上のトンネルで笹子トンネルのような天井ユニットを取り除く検討が各地で進められているようだが、それは根本原因の除去になっているだろうか。トンネル上部の天井構造は1960年代の自動車の排ガスを効率的に排出するために設計されたと聞く。現在では、排ガスをクリーンにする技術が進んだためトンネル内の排気はファンで十分なのだそうだ。
そうなると根本原因の除去として必要なのは、時代の変化、環境の変化、構造物の老朽化要因をトンネルのメインテナンス計画にインプットし、リスクが受容できるかを判定するプロセスを追加することだと考える。
12月11日の毎日新聞のニュースサイトに『トンネル崩落：中日本高速、米事故後も対応取らず』という記事が掲載された。
米国の高速道路で０６年に極めて似たトンネルの天井板崩落事故が起き、独立行政法人が０８年に作成した調査文書で事故原因などを国や高速道路各社に伝えていたことが分かった。国や中日本高速道路も事故を把握していたことを認めているが、具体的な対応は取らなかったとみられる。専門家は「緊急点検などの対処をすべきだった」と批判している。事故が起こった後に批判するのは簡単だが、批判と是正処置（Corrective Action）は違う。このケースでは次のようなことをやりきらないと是正処置（Corrective Action）にはつながらないと思う。
- 高速道路の関する“自組織が管理する高速道路”の事故、修理、苦情情報を収集するプロセスを現行プロセスに追加する。
- “日本国内の他組織が管理する高速道路”の情報も含める。
- 関係独立行政法人からの報告書も含める。
- 海外の事故情報も含める（かどうか判断する）。
- これらのデータを品質保証部門が集計、統計的な分析を加えて、定期開催される組織の品質保証委員会に提出する。
- 品質保障委員会にて、これらのデータについてどう判断したのかを記録に残す。
- 上記のプロセス及び手順を SOP （Standard Operation Procedure）に記載し、定期内部監査によって実施されていることを確認する。
これは ISO 9001 （品質マネジメントシステム）のアプローチそのものなので、ISO 9001 を取得している組織はできるはずなのだが、ISO 9001 の認証を取得することが目的になっていると、事故が起こったときに本当にやらなければいけないことができない。（このブログで口を酸っぱくして言っているのは、ISO 26262 も同じで、規格に適合できても、安全を確保する能力が高まらないのであれば意味がないということだ。）
何か問題が起こったときに批判して評論だけするのが「評論家」くんで、Corrective Action をやりきれるのが問題解決キッズである。（人気の記事『問題解決能力（Problem Solving Skill)：自ら考え行動する力』を参照されたし。）
「評論家」くんは、何か事件が起こったときに鬼の首を取ったように生き生きと問題を指摘するが、再発防止にはあまり貢献しない。本来は火消しよりも、防火活動を地道に行っている者を組織は評価するべきだと思う。
前述の FMEA , FTA の結果により、リスクを最小限にするにはどのような構造設計がふさわしいか、ふさわしくないかが分かる。今回のように構造物として簡単に取り替えがきかないのだとしても、保守計画はあるだろう。保守計画プロセスに、例えば過去20年間の事故や事故に至る前の予兆現象をインプットできていれば、そのための予算策定や行動計画が立てられる。事故が起こってからではなく、事故が起こる前に Preventive Action が取れるかどうかが安全エンジニアの力量が問われるところであり、そのためには予兆の検出技術が不可欠となる。
予防処置（Preventive Action）を実施するためには、対象物に対する定期的な検査が不可欠となる。
左図にあるように、定期検査の結果が管理限界に達したときに、事故が起きる前の予防処置を実施する。
破壊するところまで達してしまっては遅いので、管理限界点は過去の統計的なデータに基づいて余裕を持って設定する。
予防処置を確実に実施できるようにするためには、事故に至る前の予兆をいかに予知できるかどうかにかかっていることが分かるだろう。
したがって、この故障の予兆を検出する技術こそが、リスクコントロール手段と並んで安全を確保するを実現する重要な技術であることが分かる。
品質向上施策には Best Practice がいろいろあって、「あれをやった方がいい」「これが有効だ」などと無責任に助言できるが、「安全の確保」はそんなもんじゃない。
特にソフトウェアの場合、やれ「ISO 26262 ではフォーマルメソッドが推奨されている」とか「トレーサビリティアナリシスをやらないとダメだ」などと、言葉の知識がない者に品質向上施策の単語を並べる者がいるが、安全の確保はリスクマネジメントプロセスのフィードバックを繰り返すことによって少しずつ強固になっていくのだ。（安全の領域にも銀の弾丸はないのだ）
そして安全を強固なものにするためには、不具合や事故が起こったときの根本原因の分析と、根本原因を取り除くための対策を講じることが重要になる。
それを繰り返すことによってのみ組織は顧客から信用を得ることができる。
※この記事に書いたことは、医療機器ドメインを含む既存の安全工学に基づいた知見の応用である。自動車ドメインが安全の領域に進んで行くのであれば、規格要求を理解をするだけでなく、他のドメインや自動車ドメインで安全のためにどんな取り組みがなされてきたのかを調べてみるとよいと思う。
破壊するところまで達してしまっては遅いので、管理限界点は過去の統計的なデータに基づいて余裕を持って設定する。
予防処置を確実に実施できるようにするためには、事故に至る前の予兆をいかに予知できるかどうかにかかっていることが分かるだろう。
したがって、この故障の予兆を検出する技術こそが、リスクコントロール手段と並んで安全を確保するを実現する重要な技術であることが分かる。
品質の向上と安全の確保は異なる
商品の安全に対して責任を負った経験がない者は「品質の向上」と「安全の確保」を同義にとらえる傾向がある。品質向上にはここまでという一線がないため、品質向上を商売にしている者にとっては都合がよい。一方、安全には超えてはならない一線が存在する。想定したリスクが受容できない限り商品を市場に出すことはできない。そして、やるべきことをやっても事故が発生してしまったときは、その経験をフィードバックしていく。品質向上施策には 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から見解が出たら、雑音に惑わされずにそれを参考にするのがよいと思う。
登録:
投稿 (Atom)