医薬品業界における Computerized System のガイドライン

今回は医薬品業界におけるコンピュータシステムのガイドラインの話を書こうと思う。この話は、近い業界である医療機器業界にも関係あるのはもちろんのこと、自動車業界にも参考になるはずだ。

まずは歴史的背景から。1990年台初期に米FDAは英国を中心にEUの大手製薬会社を集中的に査察した。FDAがある地域の同業者を回って査察を敢行することはよくあることだ。

このとき、FDAは複数の医薬品企業に対して Warning Letter を出した。特に指摘が多かったのがコンピュータを使ったシステム（Computerized System）に関するものだった。Warning Letter が発行されると、アメリカへの医薬品の輸出がストップするから、当時欧州の医薬品業界は大騒ぎになったであろうと想像する。

医薬品業界は化学系というイメージが強いと思うだろうが今ではかなりの部分でコンピュータシステムが導入されている。実験段階のデータ分析から、薬の開発、臨床試験、医薬品製造（倉庫管理、原薬工程、製剤工程、包装工程製造）、製造管理システム、品質管理システムと、いたるところにコンピュータシステムが使われている。

これらのシステムが問題なく動いていれば、なんらユーザーリスクは生じないが、何かのソフトウェアの問題により、薬の成分が意図した成分でなくなってしまったら大変なことになる。これが Intended Use からの逸脱のリスクだ。

それ以外にも、コンピュータシステムを悪用して、臨床実験の結果が改ざんされたりしたら、これもユーザーリスクにつながる。

だからこそ、FDAはコンピュータシステムの管理に問題がないかどうかを調べ、問題があればアメリカ国民の安全のために是正を要求する。

欧州の製薬会社は、FDAからの指摘で自分達のコンピュータシステムがキチンと管理されていないことにダメ出しをされてしまった。そして、指摘を受けて医薬品の開発や生産に使っているコンピュータシステムの管理が十分ではなかったことを純粋にまずいと認識した。

また、そもそも、製薬会社はコンピュータやソフトウェアのプロではないから、それほどプライドは傷つかなかったと思うが、アメリカから数多くの指摘を受けたのは苦々しく感じたに違いない。

そこで、欧州の製薬会社、設備、機械メーカーはこれを機に、GAMP Forum を立ち上げて、自分達でコンピュータシステム管理のガイドラインを作ることにした。これが GAMPの始まりだ。

1993年にガイドラインのドラフトができ、その後5回の改訂を経て 2008年に発行されたGAMP5 が現在の最新版である。

もともと、GAMPは民間のガイドラインだったが、その後、FDAのレビューも受けて国際的なコンピュータシステムのバリデーションのガイドラインとなった。そしてその後、日本でもGAMPの内容は、コンピュータ使用医薬品等製造所適正管理ガイドラインに反映された。

ここまでの流れを整理すると

  1. アメリカが先行してコンピュータシステムのあるべき姿をまとめ規制を開始。
  2. アメリカに指摘を受けた欧州がスタンダードを作りブラッシュアップ。
  3. 日本やその他の国々がスタンダードに従うようになる。

ISO 26262 の場合は、アメリカが先行してガイダンスを持っていたわけではないが、アメリカにおける自動車関連の事故に対する訴訟や議会で取り上げられたことが、国際標準の必要性を強くしたという点では、トリガーがアメリカで、熟成させた中心が欧州であるという点はよく似ている。そして、その後出来上がったスタンダードに日本が従うことになることも同じ系譜である。

GAMP5は500ページにも渡る大作であり、次のような構成になっている。

  1. 原則と枠組み
  2. 管理、開発、運用
  3. 実践規範ガイド（Good Practice Guide）
  4. 他の情報（論文、テンプレート例、トレーニング教材）

ISO 26262 と共通するのは1と2の部分だが、ISO 26262 には実践規範ガイドやテンプレート、トレーニング教材はない。そこが、国際規格と業界が主体で作り上げたガイドラインとの違いである。GAMPは医薬品業界が必ずしも自分達の得意分野ではないコンピュータシステムの管理について知恵を絞りながら、自分たちにとって実際に役に立つガイドラインを仕上げていった。そもそも、医薬品会社が自分達でコンピュータシステムを作るわけではないので、GAMPの内容の大部分はコンピュータシステムを供給するサプライヤに対する要求事項である。

この点も ISO 26262 とよく似ていて、コンピュータシステムの開発計画→開発→運用→廃棄のライフサイクルの中で、開発計画と運用、廃棄の部分の責務は製薬会社が、開発の部分の責務はサプライヤが担う（正確にはサプライヤのアウトプットを活用するということ）内容になっている。

ただし、GAMP5は製薬会社と製薬会社へのコンピュータシステムを納入するサプライヤが実際に日々の活動に使えるガイドラインとなっているが、自動車の方は ISO 26262 だけでは GAMP5 と同等にはならない。なぜなら、ISO 26262 には Good Practice Guide や、テンプレートやトレーニング教材は含まれていないからだ。

だから、今後のために自動車業界は医薬品業界がやったように協力して実践規範ガイドやテンプレートやトレーニング教材を作る必要がある。

医薬品業界には PIC/S という国際的な医薬査察協力スキームがあり、EU各国、アメリカを含む現在37ヶ国/39当局がこのスキームに参加し、日本も加盟を検討している。このスキームに乗ると、査察官のトレーニングの場が提供され、共通の査察システムにより医薬品の品質を高く保つことが可能になり、問題が起こればその査察情報が共有される。

業界と規制当局が協調し、医薬品の品質を高めるスキームを作り上げた功績は純粋にすばらしいと感じた。医療機器や自動車業界も業界が協力して主導的に安全や信頼の得るためのスキームを構築する必要があるのだろう。

さて、GAMP5 の基本概念は次の8つである。

  1. リスクベースアプローチ
  2. Quality by Design（設計段階から品質を確保する）
  3. サイエンスベース（科学的な根拠を明確にする）
  4. Good Engineering Practice（サプライヤの活動結果も受け入れる）
  5. 製造システムの重大な側面
  6. ベンダー文書の活用
  7. 継続的なプロセス改善
  8. Subject Matter Expert(SME)

これは医療機器ソフトウェアや自動車のソフトウェアにも共通するところが多々ある。まず、リスクベースアプローチに関しては、1990年代から FDA はその方針を打ち出していて、GAMPもそれを受け継ぐことになった。現在、どの分野においてもリスクベースアプローチが取り入れられている。その理由のひとつは、そうしなければ規制当局が監督しきれないという理由がある。ユーザーリスクの大きいものから見ていかなければ許認可が追いつかないし、リスクの大きさに応じて審査、査察対応することが、各国の国民の安全を効果的に高めることにつながる。（現実世界ではリスクベースアプローチが主流になっている。フォーマルメソッドではない）

2の Quality by Design（設計段階から品質を確保する）とサイエンスベース（科学的な根拠を明確にする）は言わずもがなであるが、とりあえず動くソフトウェアを作ってしまう組織には耳が痛い話だ。

4と6は、サプライヤやベンダーの文書も有効利用するという考え方であり、7の継続的なプロセス改善は日本が発祥のQC活動に通じる。

8のSubject Matter Expert(SME)は、特定分野のエキスパート専門家のことであり、医薬品業界ではコンピュータシステムの設計、管理、評価に関しては、医薬品業界の品質保証担当がすべての責務を負うのではなく、ソフトウェアのことは専門家の意見を聞き、彼らの判断を積極的に使ってコンピュータシステムの品質を保証しようという考え方を取り入れている。<今回の記事のまとめ>

  1. 医薬品業界ではコンピュータシステムの品質を担保するために業界が協力してガイドライン（GAMP）を作った。
  2. そのガイドラインは業界標準から規制当局も含めた国際標準になった。
  3. ガイドラインは規制目的だけでなく、実践のガイド、トレーニング教材も含まれている。
  4. 他の業界も同様に“使える”ガイドラインを作り上げることが、業界、規制当局、ユーザーのために必要である。

100%の安全が確保できないからルンバを作らない？

今回は ISO 26262 の記事ではない。特集記事8回、関連記事3回書いて分かったのは、規格の日本語訳には膨大な時間がかかり、規格をすべて和訳するのはあまりにも効率が悪く、自分自身のモチベーションもなかなか続かないということだ。

これだけ話題になっている国際規格だから、近い将来、きっと自動車系の工業会が和訳を作ってくれるに違いない。全体を正確に把握するには、工業会が作った和訳をじっくり読むのが一番いい。

問題は和訳が出そろった後の話だ。規格適合を目指す技術者は大抵和訳が出ても隅から隅まで読まない。誰かが自分がやるべきことを教えてくれるのを待っている。

そして、組織はしびれを切らし担当部門もしくは担当者を決めて、その担当がエンジニアに指導する。医療機器の世界では自分がその役目を担っている。

ISO 26262に関してここで方針変換しようと思っているのは、ISO 26262 の和訳がリリースされたら、日本のソフトウェアエンジニアが自分達の良さやアドバンテージを消さないように、自動車の安全を確保するためには規格をどのように解釈したらいいか、また、和訳から読み取りにくい規格原文のニュアンスは何かなどをこのブログで解説するということだ。

また、規格のここが分からないとか、ここの部分を知りたいというリクエストがあれば、積極的にそのリクエストに応えていきたい。自分は、自動車業界には何のしがらみもないので、安心して質問や要求を投げてきて欲しい。（現時点でもリクエストがあれはお答えします。）

さて、今回は下記のニュースを掘り下げてみたいと思う。

■日本の家電各社が掃除ロボット「ルンバ」を作れない理由…国内製造業の弱点

日本の家電各社が、米アイロボット社の「ルンバ」に類似した製品を作らない、作れない理由について書いた記事である。（東芝は外部に製造委託して掃除ロボットを販売している。）

アイロボット社の「ルンバ」は確か7万円以上はしたと思うが、結構売れていると聞く。いろいろできないのではないかという心配をよそに、狭い日本の家庭でも賢く掃除してくれるらしい。

サイクロン型掃除機のように日本の家電メーカーが似たような商品を作りそうなのにそうしない理由として次のようなことが書いてある。

それなのに、技術力で世界の家電業界をリードしてきた日本メーカーが、どうしてルンバ発売から10年以上が経過しても同様の製品を製造しないのか。
「技術はある」。パナソニックの担当者はこう強い口調で話しながらも、商品化しない理由について「100%の安全性を確保できない」と説明する。
例えば、掃除ロボットが仏壇にぶつかり、ろうそくが倒れ、火事になる▽階段から落下し、下にいる人にあたる▽よちよち歩きの赤ちゃんの歩行を邪魔し転倒させる−などだという。
家庭で使う家電製品の第一条件は「安全性」だ。一方、日本の製造業は「リスクを極端に嫌う」傾向が強いため、開発の技術力がありながら、獲得できる市場をみすみす逃しているケースも指摘されている。

記事ではこのあと医療機器の例が書かれており、日本では製造物責任を恐れて新規参入しない企業があると言っている。

上記の「技術はあるが、安全を考えると参入できない」という気持ちはよく分かる。それが日本人の顧客の安全を何よりも重要視する気質( Awareness: Worrying about Quality:品質を心配する意識)の表れだと感じる。

ただし、記事が主張しているように、リスクを恐れて市場に参入しないというのも間違っていると思う。ちなみに、記事の中に出てくる「100%の安全性を確保できない」から市場参入しないというくだりは、誤った考え方だ。福島の原発事故が示すように100%の安全性など、この世に存在はしない。何をするにもリスクは必ず存在する。

薬がよい例だ。リスクよりも効用が上回った場合は、リスクコントロール手段を施した上で、リスクよりも効用の方を取る。薬の場合、製薬メーカーは治験等で十分な調査を行い、消費者は服用の注意事項をよく読み、禁忌禁止事項はやらない、医師や薬剤師の指示を守るといったこと要求される。それがリスクコントロール手段だ。

それをやった上で、副作用というリスクよりも薬の効果効能の方を取るのだ。掃除ロボットの場合は、薬や医療機器ではないので、リスクといっても人の生き死にとは直接は関係ない。

しかし、上記のパナソニックに担当者は「火事」や「赤ちゃんの転倒」といったリスクを想定した。こういうところはさすがだと思う。日本の製造業のすごいのは、品質保証担当でなくても、このような目の届きにくいリスクを拾い上げる能力を持っている点だ。その根底にあるのは、日本人の相手を思いやる気持ち、習慣のお陰ではないかと思う。

さて、商品に関係しそうな細々としたリスクを洗い出す能力が高いのはよいのだが、その結果、市場に参入しないという判断は正しいのだろうか。記事は技術力があるのに獲得できる市場をみすみす逃していると書いているが自分はちょっと違った視点を持っている。

というのは、日本のメーカーがやらなくても、韓国のサムスン電子、ＬＧ電子は参入しているのだ。日本は安全、安心の商品を作ることが最も得意な国なのに、そこに手を出さなくてどうするのか、そのままジリ貧の状態に甘んじるのかという気持ちだ。

ようするに、模倣商品が市場に出回って消費者を危険にさらすくらいなら、ブランドの信用がある日本のメーカーが安全でリーズナブルな商品を開発したらどうだということだ。ブランドを傷つける可能性をぬぐいきれないので参入しないという選択は、安全でリーズナブルな商品を望んでいる消費者の期待には応えられないという敗北宣言と同じだ。市場を逃しているのではなく、消費者の期待に応えられていないと考えて欲しい。（前者は金儲けが目的の考え方、後者は社会貢献が目的の考え方）

これからの日本の製造業者は効果効能が高く、かつリスクも大きい商品があったらチャンスと思わないダメだ。過去の栄光を守ろうと考えたら、あっという間にアジアの国々に抜かれる。あのソニーだって、新社長が4本柱の一つとして医療分野に力を入れると言っているではないか。

米アイロボット社に敬意を表して、白旗を揚げて模倣製品は作らないというのも選択肢の一つだとは思うが、安全性が担保できないから市場参入しないというのはなさけない。パナソニックは家電業界でユーザーの安全分析、安全対策、是正改善は相当やってきているだろうから、安全を確保できないから市場参入しないという理由はおかしい。

安全を分析、実現するノウハウは持っているはずなので、市場におけるユーザーからの苦情や故障情報を持っていないというのは理解できる。しかし、そのような情報はルンバのユーザーや家電量販店へのリサーチである程度は収集できるから、できない理由にはならないと思う。

新規参入した分野で事故を起こせば、ブランドに傷が付き主力商品の売り上げに支障がでると考えたのなら、既存商品の分野でジリ貧となる運命を受け入れるしかない。

リスクを伴う商品開発に関わりたくない、命に関わる商品開発はしたくないという話は、医療機器ドメイン外の技術者や、大学生から聞くことがある。そういう時は「リスクから逃れることを考える前に、自分達が作った商品やサービスで人や社会にどんな貢献ができるのかを考えてみて欲しい」と言う。

患者さんの命を助ける、人のためになる、社会に貢献するための仕事に従事できれば、毎日の仕事自体がやりがいにならないか、もっとお客さんに満足してもらう、もっと社会に貢献したいという気持ちにならないか。そのためにまたがんばろうと考えられるようになったらいいと思わないかと問うようにしている。

高い効果効能、高い社会貢献を実現する商品にはユーザーリスクが伴う。しかし、人間はそのリスクを軽減するための知恵をこれまで構築してきた。その先人の知恵を使うことで、できるだけリスクを下げることができる。ただ、100%の安全はないのでそのことは決して忘れてはいけない。

ここまでの考えをまとめると、次のようになる。

【今日のまとめ】

  1. 効果・効能をもたらす商品にはユーザーリスクが伴う。
  2. リスクの低減を実現し、高い技術で効果・効能を実現できれば、それが組織の強みになる。
  3. 100%の安全などあるわけないのだから、リスクから逃げるのではなく、リスクを軽減する技術を追求する。
  4. 日本の製造業の強みは製品開発を通じて潜在的価値（リスクの軽減）と顕在的価値（効果・効能）の両立ができることである。
  5. その特長を活かせないのなら、グローバルマーケットで生き残ることはできない。（機能やコストだけでは勝負はできない。安全や信頼の提供が世界中の顧客の信頼を生む。）

ISO 26262との向き合い方 (8) リスク分析しないでいいの？

今回の記事は リスク分析、リスクアセスメントについての話題である。

※図表はもとブログをご覧ください。

最初に、医療機器ドメインのリスクマネジメントに関する国際規格である ISO 14971:2007
Medical devices ― Application of risk management to medical devices のリスク評価の定義について見て欲しい。

リスクは、危害の発生確率（the probability of occurrence of harm）と、危害の重大度（the consequences of that harm, that is, how severe it might be. ）により評価されるというのが ISO 14971 の考え方である。一般的にも、リスク = 発生確率 × 重大度 などと書かれる。

例えば、ハードウェア部品の故障による障害などでは、発生確率はすなわち部品の故障率となり、その部品が故障したときの被害の大きさが重大度となる。よって、故障率が非常に低い場合のリスクは低いと考える。

気をつけたいのは、リスク評価 = 発生確率 × 重大度 と書いても、リスクの評価は数学的、統計的に計算されるものではないという点だ。

なぜなら、危害の発生確率は部品の故障率のように数値で示すことができないことも多々あり、また、危害の重大度は極めて主観的であり、時代や人々の考え方によって常に変化するパラメータであるからである。

下記のマトリクスを見て欲しい。縦軸には危害の発生確率に相当する半定量的な確率レベルが、横軸に定性的な重大さレベルが表されている。

このマトリクスでは紫の部分が半定量的な確率レベルと定性的な重大さのレベルを評価した結果、そのリスクは受容できないと判断している。薄いブルーの部分は更なるリスク低減を検討すれば受容できるリスク、白い部分は受容できるリスクと判断した例である。

この表に出てくる「しばしば」や「時々」「わずかに」や、「軽微な」「きわどい」「重大な」といった評価指標は極めて主観的な表現であることが分かる。 発生確率が定量化できない、重大さのレベルが定量かできないので、半定量的もしくは定性的に評価しているのだ。その判定基準はその組織が積み重ねてきた事故データや判定者の経験的主観に依存している。
実例でリスクを評価してみる

医療機器で実例を挙げてみよう。心拍は心臓右心房付近にある洞房結節から発生される電気的な刺激の発信がトリガーとなって起動される。この自発のペースメーカの機能に欠陥がある患者さんには、ペースメーカが植え込まれる。

ペースメーカにはさまざまな機能があるが、自発の心拍がたまに欠落するような場合は、ペースメーカは心拍が欠落したときにのみ心臓を刺激する。これをデマンドペーシングと呼ぶ。自発の心拍がまったくない場合は固定レートで心臓を刺激するこれを固定レートペーシングと呼ぶ。


さて、患者さんに植え込んだペースメーカが動かないというリスクを考えて見よう。ペースメーカの停止が起こった場合のリスクの重大さは患者さんの死を引き起こすので破局的だと考えられる。

では確率レベルはどうだろうか。「時々」や「わずかに」ならペースメーカとして使える訳がない。では「起こりそうにない」のか、または「考えられない」なのか。上記のリスク評価のマトリックスであれば、「破局的」な重大さレベルで、確率レベルが「起こりそうにない」なら、そのリスクは受容できない=すなわち、そのペースメーカは受容できないリスクがあるため販売してはならないし、考えられないレベルであれば更なるリスクの低減策が必要となる。

ではつぎに、車の例で高速走行中にブレーキが効かなくなるというリスクについて考えて見よう。危害の結果について予測されるのは、運転手と車に衝突された人の死、及び、車が衝突することによる固定物の価値の喪失などが考えられる。ではその重大度は、発生確率はどうであろうか。人の死の可能性があるのならば重大さのレベルは「重大な」や「破局的」が予想される。

障害の発生確率はハードウェアの場合部品の故障率で予測できると書いたが、ハードウェアであっても設計上のミスや、ソフトウェアのバグによる障害の発生は、その確率を予測することができない。このような故障、欠陥のことを Systematic Failure / Systematic Fault (決定論的故障/欠陥）と呼び、医療機器の世界では今のところ、Systematic Failure の発生確率は1、すなわち発生確率は考えずに、障害の重大さだけでリスクを評価することにしている。

※ISO 26262 では、リスクの評価に Controllability（ドライバや周辺の人々の障害の回避容易性）を考慮している。

もう一つ、リスク評価の例を考えてみたい。それは、「原子炉が制御不能になる」というリスクだ。不幸にも日本は昨年、「原子炉が制御不能になる」というリスクに対して「放射能が拡散し、人体に影響を与える。周辺に人が住めなくなる。」といった危害の重大度を実体験として経験してしまった。

「原子炉が制御不能になる」というリスクの発生確率は福島の原発事故が起こる前は「考えられない」だったかもしれない。しかし、起こってしまった今の評価はどうだろうか。「考えられない」「起こりそうにない」といった評価を日本国民は許さないだろう。

冒頭でリスクの評価は数式では表せないといったのは、このことだ。どんなに統計的な確率が低かったとしても、甚大な被害が発生してしまえば、リスクの評価は変わる。

一般的に時間がたつにつれてリスク評価は厳しい方に傾く。なぜなら、リスクコントロール手段が普及すると、人々はそのリスクコントロール手段を“当たり前に実装されているもの”と認識されるようになるからである。過去に認識されていたリスクは現在ではブロックされていて当然であり、技術の進歩により機器の安全は進化していると考えるのが一般的な消費者の意識だ。機器を使っていて使い勝手の悪さや不具合を見つけると、どうしてこんなことが考慮されていないのかと消費者は不満に思う。しかし、そのレベルでリスク分析をしたら何千、何万というリスクコントロールを行わないといけないという作り手側の視点に立つことはない。問題が起これば、ユーザーにとってはその問題が今一番優先度の高い関心事なのだ。

そのドメインに新規参入する企業や、新人の技術者はユーザーが“当たり前に実装されているもの”の存在やメカニズムを知らないから、危険な製品を作ってしまう可能性がある。皮肉なことに、ユーザーは事故や不具合を体験することで、メーカーのリスクコントロール手段の存在を知ることがよくある。当たり前にできていることは、それが当たり前でなくなったときに、初めてその存在が分かるのだ。

だから、クリティカルな製品を開発する企業は、リスク分析、リスクアセスメント、リスクコントロール手段の設計と実装、検証、妥当性確認を行う義務を負っている。

さて、「原子炉が制御不能になる」のリスク分析に話を戻そう。「原子炉が制御不能になる」のリスク評価は、現実に事故が起こったことで発生確率の評価が高まりリスクは受容できないという判断になった。

この場合、この後どうしたらよいだろうか。リスクコントロール手段の一つとして「原子力発電をしない」という選択肢がある。この対策を取れば、「原子炉が制御不能になる」というリスクからは解放される。現在の日本の状況がまさにこれに当たる。「原子炉が制御不能になる」というリスクの場合、重大さのレベルは破局的から下がることはないので、もしも、どうしても原子力発電を続けるのであれば新たなリスクコントロール手段によって、リスクを受容できるようになるのかどうかを判断しなければならない。

リスクマネジメントは事故が起こる前に未然に事故を防ぐのが重要だが、実際には、事故が起こってしまった後に、再発防止ができるかどうかがカギとなる。それは、完全な安全対策などはなく、また、リスク分析、リスクアセスメントは人々の経験値や主観、思惑に左右されることが多いからである。そして、現実には事故を再発させないという関係者共通の意志がリスクコントロールの進化を後押しするのである。
具体的なリスクを想定しないで部品を作っちゃう人たち

今回、リスク分析、リスクアセスメントを話題にしたのは理由がある。その理由を説明する前に次の2つの ISO 26262 に関連した各企業のプレスリリースを見ていただきたい。

1) 機能安全規格に対応した電子制御ユニット向け車載用マイコンの製品化について
：
車載電子制御ユニットを対象とした機能安全規格「ISO26262」が今年中には発行される見込みです。規格発行後は電子制御ユニットの中核部品であるマイコンに対して、一部の機能が故障しても安全に制御する「フェールセーフ」機能を搭載することが必要となります。
：

2) HEV/EV用モータ制御を効率化する角度センサ（レゾルバセンサ）の特性をプログラマブルに補正できる高性能マイコン「V850E2/PJ4-E」を発売
〜機能安全規格ISO2626２にも対応し、HEV/EV用モータシステムの高い安全性かつ低コスト化に貢献〜
：
今後自動車業界で適応されるISO26262（注2）に対応するため、高度な故障検出技術を搭載しており、モータ制御など高い安全性が求められるシステムに対応できます。
：
また、これら車の普及促進に向けたシステムコスト低減も強く求められると共に、ISO26262が発行され安全要求への対応が求められております。
：

これらのプレスリリースに強い違和感を感じるのは、これらのマイコンメーカーはおそらく自動車の具体的なリスク分析やリスクアセスメントに基づいてマイコンを設計したのではないだろうという点だ。特に「規格発行後はフェイルセーフ機能を搭載することが必要となります」というくだりはひどい。規格が発行されるから安全対策が必要などというのは、本末転倒も甚だしい。ISO 26262 は自動車メーカやサプライヤが自分達が分析、設計した安全対策を国際標準に基づいて説明するためにある。

このブログの特集記事で常に訴えているように、安全の責務を負っていない者は平気でそのような発言をする。医療機器ドメインではそんな売り込みのされ方をしたことはないから、自動車開発にまつわる市場の大きさがそういったセールストークを作り出すのだろう。

さて、これらのプレスリリースの前者は、「一部の機能が故障しても安全に制御するフェールセーフ機能を搭載している」と書いてあり、後者はDual Core Lockstep（デュアルコア・ロックステップ）：ロックステップを実行する２つのプロセッシングユニットの結果を随時比較して故障を検出する故障検出技術を搭載していると書いてある。

リスクを想定せずに安全設計はできない。なぜなら、すべてのリスクに有効なリスクコントロール手段など存在しないからだ。「一部の機能が故障しても安全に制御する」「故障を検出する機能を有する」という文言は一見どんなリスクにも効くように見えるが、ECU側でそれらの機能がリスクを低減するリスクコントロール手段になっていなければ意味がない。マイコンサイドはその機能がリスクを低減させると考えているのだろうが、具体的にどのようなリスクを低減することに効果があるのか分析しているとは思えない。

例えば、「高速走行中にブレーキが効かなくなる」というリスクに対してこれらのマイコンはどのように有効に働くのだろうか。カーブを高速走行中にブレーキアイテムに不具合が発生したことが分かったり、緊急処置としての補助プロセスが起動されたりしている間に車のコントロールが効かなくなってスピンし始めても、上記のようなマイコンの機能は車の制御を立て直すことができるのだろうか。そんなことはECUの設計者に聞いてくれと言うのだろう。リスク分析が行われずに、何にでも効くという部品を作っても意味がない。

ところで、前者のマイコンの場合、下記のように書かれているから、ペースペーカが動かないというリスクには有効かもしれない。
専用の監視回路の導入により、内部状態の故障が即時に検出でき、故障発生箇所を絞り込むことが可能となります。そのため当社のマイコンは、最低限の機能を確保しながら動作を継続する「フェールオペレーショナル」が可能な電子制御システムへの組み込みに適しています。
複雑なプログラムであるデマンドペーシングが何らかの原因で効かなくなったときに、最低限の機能で固定レートのペーシングを続けることができるかもしれない。

しかし、よく考えて見て欲しい。そうであったとしてもペースメーカの電源の供給が絶たれれば、そのリスクコントロール手段はまったく意味をなさなくなる。

この話は福島の原発事故とよく似ている。どんなに考え抜かれたリスクコントロール手段を準備していても、補助電源を用意していても、結局「原子炉が制御不能になる」というリスクを回避することはできなかった。まったく電源を使わない状態でも原子炉を冷やす手段は用意されていたが、オペレーションの問題もあって有効には働かなかった。

今回の記事で言いたいのは、リスク分析やリスクアセスメントをしないで、安全に効果があるなどと言うのはやめなさいということだ。部品の信頼性を高めることはできても、安全はリスクを想定しなければ効果を主張することはできない。リスクを想定しないで、安全をうたうのは間違いだ。

機能安全はそもそも、部品単位での信頼性の向上が、システム全体の安全に貢献するかのように受け取られる傾向がある。

クリティカルな製品を作ってユーザーに対する責務を負う立場になれば分かることだが、安全を確保するためには、さまざまなことに気を配らないと目的は達成できない。

例えば、安全を確保するために十分に検証されたコンパイラを使ったとしよう。それで安全が確保されたのか。そんなはずはない、十分に検証されたコンパイラは決して、誤ったコードをはき出すことはないのか、どんなに複雑な条件であっても決定論的故障は起こさないのか。取り扱い説明書に誤記があって、それを信じて誤った使い方をした場合、それはコンパイラの不具合ではないと言うのか。コンパイラが完璧であったとして、ミドルウェアに問題があったらどうするのか。

コンパイラには関係ない、ユーザビリティに関するリスクは重要ではないのか。電源喪失時のリスクは考慮しないでいいのか。安全を確保するために必要なことを挙げたらきりがない。どんな些細なことも見逃さないように対策を始めたら、時間と工数は無限にかかる。したがって、有限な時間と工数で安全な商品やサービスを提供するためには、リスク分析、リスクアセスメントは欠かせない。

部品やツールの信頼性の検証活動は、システム全体のリスクコントロールのほんの一部でしかない。それだけに注力を注いでも、大元のリスクが大幅に軽減できるとは限らない。商品やシステムに責任を負うものは、それらをひっくるめてユーザーに降りかかるリスクを受容できるレベルまでコントロールしなければいけない。

自分はたまたまソフトウェアエンジニアでありながら、リスク分析、ハザード分析、リスクアセスメント、リスクコントロール手段の設計などを行いながら、商品の安全性と向き合ってきた。

ISO 26262の特集記事は、それらの経験を踏まえて、本当に安全を確保するにはエンジニアは何をやなければいけないのかを書いていきたいと思う。

【ISO 26262-2:2011 Part 2: Management of functional safety】

今回は ISO 26262-2 機能安全のマネジメント 5.2.2 安全ライフサイクルに関する注釈　を読み進んでいる。下記の図の説明となるので、図を手元に置きながら読んでもらった方がよいと思う。

5.2.2 Explanatory remarks on the safety lifecycle
5.2.2 安全ライフサイクルに関する注釈

ISO 26262 specifies requirements with regard to specific phases and subphases of the safety lifecycle, but also includes requirements that apply to several, or all, phases of the safety lifecycle, such as the requirements for the management of functional safety.
ISO26262は、安全ライフサイクルの特定のフェーズとサブフェーズに関しての要求を定めまるが、安全ライフサイクルのフェーズ、機能安全のマネジメントのための要求などのようにいくつかの、またはすべてフェーズに適用される要求も含んでいる。

The key management tasks are to plan, coordinate and track the activities related to functional safety.
キーマネジメントタスクとは、機能安全に関連する活動を計画、調整、追跡することである。

These management tasks apply to all phases of the safety lifecycle.
これらのマネジメントタスクは安全ライフサイクルのすべてのフェーズに適用される。

The requirements for the management of functional safety are given in this part, which distinguishes:

つぎの部分で機能安全のマネジメントのための要求を与える:(部分は識別される)。

  • overall safety management (see this clause);
  • 全体的なセーフティマネジメント(この箇条を見よ)。
  • safety management during the concept phase and the product development (see Clause 6);
  • コンセプトフェーズ間のセーフティマネジメントと製品開発(箇条6を見よ)。
  • safety management after the item's release for production (see Clause 7).
  • 生産(箇条 7を見よ)のためのアイテムのリリースの後のセーフティマネジメント。

The following descriptions explain the definitions of the different phases and subphases of the safety lifecycle, as well as other key concepts:
以下の説明文では異なるフェーズの定義とセーフティライフサイクルのサブフェーズについて他の重要な考えと同様に説明する。:

a) The subphase:
a) サブフェーズ:

item definition
アイテム定義

The initiating task of the safety lifecycle is to develop a description of the item with regard to its functionality, interfaces, environmental conditions, legal requirements, known hazards, etc.
セーフティライフサイクルに関する開始タスクは、機能性、インタフェース、環境条件、法的要求、周知のハザードなどに関してアイテムの説明を作成することである。

The boundary of the item and its interfaces, as well as assumptions concerning other items, elements, systems and components are determined (see ISO 26262-3:2011, Clause 5).
アイテムとそのインタフェースの境界、および他のアイテムに関する仮定、要素、システム、およびコンポーネントは決められている。(ISO26262-3:2011を見よ。箇条 5)。

b) The subphase:initiation of the safety lifecycle
b）サブフェーズ：セーフティライフサイクルの開始

Based on the item definition, the safety lifecycle is initiated by distinguishing between either a new development, or a modification of an existing item.
アイテム定義に基づいて、セーフティライフサイクルは、新規開発か、既存アイテムの変更のどちらであるかを識別することによって開始される。

If an existing item is modified, the results of an impact analysis are used to tailor the safety lifecycle (see ISO 26262-3:2011, Clause 6).
既存アイテムが変更されているなら、インパクト分析の結果は、セーフティライフサイクルをテーラリングするのに使用される。(ISO26262-3:2011を見よ。箇条 6)。

c) The subphase:hazard analysis and risk assessment
c) サブフェーズ：ハザード分析とリスクアセスメント

After the initiation of the safety lifecycle, the hazard analysis and risk assessment is performed as given in ISO 26262-3:2011, Clause 7.

セーフティライフサイクルの開始の後、ハザード分析およびリスクアセスメントが ISO26262-3:2011、箇条7 によって実行される。

First, the hazard analysis and risk assessment estimates the probability of exposure, the controllability and the severity of the hazardous events with regard to the item.

まず最初に、ハザード分析とリスクアセスメントでは、アイテムに関して危険な事象の暴露の確率、コントローラビリティ、および重大度を推定する。

Together, these parameters determine the ASILs of the hazardous events.
これらのパラメータは危険な事象のASILを同時に決定する。

Subsequently, the hazard analysis and risk assessment determines the safety goals for the item, with the safety goals being the top level safety requirements for the item.

次に、ハザード分析とリスクアセスメントは、トップレベルの安全要求であるセーフティゴールとともに、そのアイテムのセーフティターゲットを決定する。

The ASILs determined for the hazardous events are assigned to the corresponding safety goals.
危険な事象のために決定するASILは対応するセーフティゴールに割り当てられる。

During the subsequent phases and subphases, detailed safety requirements are derived from the safety goals.
その後のフェーズとサブフェーズの間、詳細な安全要求がセーフティゴールから派生して得られる。

These safety requirements inherit the ASIL of the corresponding safety goals.
これらの安全要求は対応するセーフティゴールのASILを引き継ぐ。

d) The subphase:functional safety concept
d) サブフェーズ:機能安全コンセプト

Based on the safety goals, a functional safety concept (see ISO 26262-3:2011, Clause 8) is specified considering preliminary architectural assumptions.
セーフティゴールに基づいて、機能安全コンセプト(ISO26262-3:2011、箇条8を見よ)は予備的なアーキテクチャの仮定を考慮して明示される。

The functional safety concept is specified by functional safety requirements that are allocated to the elements of the item.
機能安全コンセプトはアイテムの要素に割り当てられる機能安全要求によって指定される。

The functional safety concept can also include other technologies or interfaces with external measures, provided that the expected behaviours thereof can be validated (see ISO 26262-4:2011, Clause 9).
また、機能安全コンセプトは、妥当性が確認され、予想された振る舞いを提供できるのであれば、外部計測を伴うインタフェースや他の技術を含むことができる。(ISO26262-4:2011を見よ。箇条9)。

The implementation of other technologies is outside the scope of ISO 26262 and the implementation of the external measures is outside the scope of the item development.
ISO26262のスコープの外に他の技術の実装がある。そして、外部計測の実装はアイテム開発のスコープの外側となる。

e) The phase:product development at the system level
e) システムレベルにおける製品開発

After having specified the functional safety concept, the item is developed from the system level perspective, as given in ISO 26262-4.
機能安全コンセプトを明示した後に、アイテムはISO26262-4で与えられるようにシステムレベル見地で開発される。

The system development process is based on the concept of a V-model with the specification of the technical safety requirements, the system architecture, the system design and implementation on the left hand branch and the integration, verification, validation and the functional safety assessment on the right hand branch.
システム開発プロセスはテクニカル安全要求によってVモデルの概念に基づいている。Vモデルの左手の枝にはシステムアーキテクチャ、システム設計、実装が、Vモデルの右側の枝には、結合、検証、バリデーション、および機能安全評価がある。

The hardware-software interface is specified in this phase.
ハードウェア-ソフトウェアインタフェイスはこのフェーズで指定される。

Figure 1 provides an overview of the subphases of the product development at the system level.
図1はシステムレベルで製品開発のサブフェーズに関する概要を提供する。

The product development at the system level incorporates validation tasks for activities occurring within other safety lifecycle phases, including
システムレベルの製品開発は他のセーフティライフサイクルフェーズの中で発生する次のような活動のためのバリデーションタスクを組み入れる。

  • the validation of the aspects of the functional safety concept that are implemented by other technologies;
  • 他の技術で実装される機能安全コンセプトの側面のバリデーション
  • the validation of the assumptions concerning the effectiveness and the performance of external measures;
  • 外部計測の有効性及び性能に関する仮定のバリデーション
  • the validation of the assumptions concerning human response, including controllability and operational tasks.
  • コントローラビリティ及びオペレーションを含む人間の応答に関する仮定のバリデーション

The release for production is the final subphase of the product development and provides the item’s release for series production (see ISO 26262-4:2011, Clause 11).
生産のためのリリースは、製品開発の最終的なサブフェーズであり、連続生産のためのアイテムリリースを提供する。(ISO26262-4:2011を見よ、箇条11)。

f) The phase:product development at the hardware level
f) フェーズ:ハードウェアレベルにおける製品開発

Based on the system design specification, the item is developed from the hardware level perspective (see ISO 26262-5).
システム設計仕様に基づいて、アイテムはハードウェアレベルの見地から開発される。(ISO26262-5を見よ）。

The hardware development process is based on the concept of a V-model with the specification of the hardware requirements and the hardware design and implementation on the left hand branch and the hardware integration and testing on the right hand branch.
ハードウェア開発過程はハードウェア要件の仕様でVモデルの概念に基づいている。左の枝ではハードウェア設計とインプリメンテーションが、右の枝ではハードウェアインテグレーションとテストがある。

Figure 1 provides an overview of the subphases of the product development at the hardware level.
図1はハードウェアレベルで製品開発のサブフェーズに関する概要を提供する。

g) The phase:product development at the software level
g) フェーズ:ソフトウェアレベルにおける製品開発

Based on the system design specification, the item is developed from the software level perspective (see ISO 26262-6).
システム設計仕様に基づいて、アイテムはソフトウェアレベルの見地から開発される(ISO26262-6を見よ)。

The software development process is based on the concept of a V-model with the specification of the software requirements and the software architectural design and implementation on the left hand branch, and the software integration and testing, and the verification of the software requirements on the right hand branch.
ソフトウェア要求の仕様、ソフトウェアアーキテクチャデザイン、およびインプリメンテーションが左手にあって、ソフトウェア統合、テスト、およびソフトウェア要求の検証が右手にあり、ソフトウェア開発プロセスはVモデルの概念に基づいている。

Figure 1 provides an overview of the subphases of the product development at the software level.
図1はソフトウェアレベルで製品開発のサブフェーズに関する概要を提供する。

h) Production planning and operation planning
h) 生産計画と運用計画

The planning for production and operation, and the specification of the associated requirements, starts during the product development at the system level (see ISO 26262-4).
製品開発の間、生産と運用のための計画立案、および関連要求の仕様はシステムレベルで始まる(ISO26262-4を見よ)。

The requirements for production and operation are given in ISO 26262-7:2011, Clauses 5 and 6.
ISO26262-7:2011箇条5と6 で生産と運用のための要求を与える。

i) The phase: production and operation, service and decommissioning
i) フェーズ:生産、運用、サービス、および廃棄

This phase addresses the production processes relevant for the functional safety goals of the item, i.e. the safety-related special characteristics, and the development and management of instructions for the maintenance, repair and decommissioning of the item to ensure functional safety after the item's release for production (see ISO 26262-7:2011, Clauses 5 and 6).
このフェーズは、アイテムの機能安全ゴールに関連した生産プロセスを扱う。すなわち、安全関連の特別な特性、保守や修理、開発、アイテムリリース後の機能安全を確実にするためのアイテムのデコンポジッションのための指示、訓練の開発やマネジメントなど。(ISO26262-7:2011を見よ、箇条5と6)。

j) Controllability
j) コントローラビリティ

In the hazard analysis and risk assessment (see ISO 26262-3:2011, Clause 7), credit can be taken for the ability of the driver, or the other persons at risk, to control hazardous situations.
ハザード分析とリスクアセスメント(ISO26262-3:2011を見よ、箇条7)で、危険な状態をコントロールするためのドライバーや危険に遭遇するその他の人々の技量の信頼度である。

The assumptions regarding the controllability in the hazard analysis and risk assessment and the functional and technical safety concept are validated during the safety validation (see Figure 2 and ISO 26262-4:2011, Clause 9).
ハザード分析とリスクアセスメントにおけるコントローラビリティに関する仮定と機能的でテクニカルなセーフティコンセプトは安全バリデーションの間で妥当性が確認される。(図2と ISO 26262-4:2011を見よ、箇条9)。

NOTE The exposure and the severity are factors that depend on the scenario.
ノート 暴露と重大度は、シナリオに依存する要素である。

The eventual controllability through human intervention is influenced by the design of the item and is therefore evaluated during the validation (see ISO 26262-4:2011, 9.4.3.2).
人間の介入の結果として起こるコントローラビリティは、アイテムのデザインによって影響を受ける。したがって、バリデーションの間、評価される(ISO26262-4: 2011、9.4.3.2を見よ)。

k) External measures
k) 外部手段

The external measures refer to the measures outside the item, as specified in the item definition (see Figure 2 and ISO 26262-3:2011, Clause 5), that reduce or mitigate the risks resulting from the item.
外部手段はアイテム定義で示される(図2とISO 26262-3:2011を見よ、箇条5)アイテムから生じるリスクを低減または緩和するアイテムの外側の手段を示す。

External measures can include not only additional in-vehicle devices such as dynamic stability controllers or run-flat tyres, but also devices external to the vehicle, like crash barriers or tunnel fire-fighting systems.
外部手段はダイナミック安定制御装置やランフラットタイヤなどの追加的な車内のデバイスだけではなく、中央分離帯やトンネル消防システムのように車の外部のデバイスも含むことができる。

The assumptions regarding the external measures in the item definition, the hazard analysis and risk assessment and the functional and technical safety concept are validated during the safety validation (see Figure 2 and ISO 26262-4:2011, Clause 9).
アイテム定義、ハザード分析、およびリスクアセスメントにおける外部手段と機能的でテクニカルな安全コンセプトに関する仮定はセーフティバリデーションの中で妥当性が確認される(図2とISO 26262-4:2011を見よ、箇条9)。

External measures can be considered in the hazard analysis and risk assessment.
ハザード分析とリスクアセスメントで外部手段を考慮できる。

However, if credit is taken from an external measure in the hazard analysis and risk assessment, that external measure cannot be considered as a risk reduction in the functional safety concept.
しかしながら、ハザード分析とリスクアセスメントの中で外部手段から信用を得るなら、その外部手段は機能安全コンセプトの中ではリスク軽減と見なすことはできない。

ISO 26262 also applies to those external measures that are in the scope of ISO 26262.
また、ISO26262はISO26262のスコープのある外部手段として適用される。

l) Other technologies
l) 他の技術

Other technologies, e.g. mechanical and hydraulic technologies, are those different from electrical and/or electronic technologies that are in the scope of ISO 26262.

他の技術(例えば、機械技術、流体技術)はISO 26262のスコープの中にある電気的な、そして/または、電子の技術とは異なる技術である。

These can be considered in the specification of the functional safety concept (see Figure 2 and ISO 26262-3:2011, Clause 8), during the allocation of safety requirements (see ISO 26262-3 and ISO 26262-4), or as an external measure.

これらは、安全要求(ISO26262-3とISO26262-4を見よ)の割り当ての間、または、外部手段において機能安全コンセプト(図2とISO 26262-3:2011を見よ、箇条8)の仕様を考慮することができる。

NOTE If an implementation in another technology is specified as an external measure, then it can be useful to repeat the hazard analysis and risk assessment to consider the associated risk reduction, which could potentially result in a reduced ASIL of a corresponding safety goal.

注意 もしも、他の技術の実装が外部手段によって指定されているのであれば、セーフティゴールに対応する潜在的に減少されたASILによって関連するリスクの軽減を考慮するハザード分析やリスクアセスメントを繰り返すことに役立つ。

ISO 26262との向き合い方 (7) 自動車ソフトの未来予想図

正月休みの間、自動車業界が直面するであろう安全ソフトウェアの問題(=自動車ソフトウェアの未来予想図）について二つのシナリオ考えてみた。まずは、これら未来のシナリオを読んでみていただきたい。

■シナリオ1 電気自動車の時代 の不具合

2020年、電気自動車用の充電プラグは家庭やコンビニエンスストアにも普及が進み、郊外には電気スタンドもよく見かけるようになってきた。充電場所が増えるにつれて、それまで聞いたこともない電気自動車メーカー、ブランドの車も数多く現れてきた。電気自動車の販売価格帯は二極化しており、老舗の自動車メーカーの150万円以上のブランド車と、アジアのメーカーの100万円以下の車に人気が集中している。低価格電気自動車は安いものなら50〜60万円で買えるようになり、都心の若い世代ではこのような低価格電気自動車を個人で購入するのではなく、電気自動車がシェアカーとして用意されているマンションを選ぶようになってきた。

電気自動車の普及の裏で、困っているのは自動車の新規登録を許可している日本の規制当局だ。申請数が多すぎて数をさばききれない。かといって5年前に締結されたTPP協定によって、外国メーカーの自動車の新規登録が遅れると協定違反となって国際司法裁判所に提訴されるようになったから、手続きを遅らせる訳にはいかない。だから手続きは粛々とこなしていかなければならない。職員は増やしたが経験が追いついていないため、細かい見落としはどうしても増えている。

許認可の問題だけでなく、新規参入の自動車メーカーが作った自動車そのものの不具合が原因の事故も確実に増えている。電子制御のブレーキが突然効かなくなる、アクセルが急加速する、モータが急停止するといった、日本の自動車メーカーが起こしたらトップニュースになるような不具合が当たり前のように起こるようになった。電気自動車では部品をサプライヤから買い集めて組み合わせるだけで簡単に完成品ができるようになり、自動車ドメインでの経験をほとんど持っていない企業の電気自動車製造販売の参入が急増したことが原因だ。アセンブリメーカーはできるだけ安く自動車を作ることが使命であるため、もっとも安くECUを供給できるサプライヤからハード、ソフトを買う。自動車業界ではプラットフォームの共通化が進んだことで、どこのECUを買ってきても表面上は問題なく動くようになった。非常にわかりにくいソフトウェアに起因した不具合があることなど気にもせず、新規参入のアセンブリメーカーは安いECUを供給するサプライヤに次々と切り替えるため、これまで発生していなかった問題がECUの切り替えとともに突然起こったりする。

自動車のソフトウェアの作り方がすり合わせから組み合わせに変わり、規格化された共通インタフェースの部品を共通プラットフォームに接続することで基本的な電気自動車の機能が実現できるようになった。しかし、一つ一つの部品を一から作ったことがない、それどころか一つ一つのデバイスの性能限界もよく分かっていないアセンブリメーカーには、突然発生したソフトウェア制御のブレーキの誤動作やアクセルの急加速といった原因がまったく分からないし、何をどうやって調べればよいのか見当もつかない。したがって、このような原因不明の事故を起こした新規参入の自動車メーカーの車は、最近、日本では急速に販売数を減らしている。日本でも自動車雑誌にリコール情報の分析データがワーストランキングと共に掲載されるようになった。一方アジアの国々では、それでも低価格の電気自動車はまだ人気がある。

事故を起こしたメーカーも ISO 26262 適合というフレコミのECUを使っていた。アセンブリメーカー自身もISO 26262 のプロセス認定を受けている。それでも事故が起こるのはシステム全体に対する安全管理ができていなかったからなのだ。日本の自動車メーカーが当然のようにできていた不具合の原因追及や再発防止策の立案、継続的な改善活動が新規参入のアセンブリメーカーにはできない。しかし、だからといってアセンブリメーカーを市場から排除しようとすると非関税障壁だと訴えられてしまう。そうなると日本の消費者は自分の安全を自分で守るしかなくなる。事故情報を分析することで自動車の価格と自分の安全を天秤にかけるしかない。家庭電化製品と同じように消費者はまず、自動車の安全情報のサイトで事故情報と既存ユーザーの評判をじっくり読んでから、販売店に向かうようになった。2020年、自動車は選択を誤ると安心して運転できない恐ろしい乗り物になった。

■シナリオ2 高級車に搭載するインテリジェンス安全機能の落とし穴

その数秒後、交差点に入った瞬間にちょうど青信号になったばかりの左側の道路からきたCが運転する軽自動車に側面衝突した。Bの車のセーフティ機能は働かなかった。

この事故でBとCは大けがをした。もちろんBの信号無視が原因だった。その後自動車会社Aはなぜこの事故が発生したのか原因を突き止めるために、ECUとナビゲーションシステムに記録されていたデータログを徹底的に解析した。

原因は その日のその時間、VICSシステムがメインテナンスのため5時間ほど機能を停止しており、その情報にBが気がついていなかったからだということが分かった。実はナビゲーションシステムの取り扱い説明書にはこのことは注意として書かれており、実際VICSシステムの稼働中アイコンもそのときはナビの画面から消えていた。これまでBはVICSシステムの情報受信のアイコンなど気に留めたことなどなかった。

この件について、自動車会社Aがナビゲーションシステムの供給会社Dに厳しく問いただしたところ「何も間違った情報は送っていない。VICSが稼働中かどうかのステータスは正しく表示しているし、ブレーキシステムにも通信している。取り扱い説明書で表記上の対策もしている、できることはすべてやっているので我が社には過失はないと考えている。」という回答が返ってきた。

自動車会社Aのチーフエンジニアは頭を抱えた。これまでこんなことが起きたことはなかった。ブレーキシステムを担当するサプライヤはその機能と性能を隅々まで把握し、エンドユーザーに対して責任を感じながら完璧な仕事をしてきた。ところが、新しいセーフティ機能を次々に加えていった結果、自動車の安全機能がどんなときにも期待通りに働くのかどうか自信が持てなくなってきた。誰に聞いたら確信が持てるのか分からなくなってきた。それほど、システムは複雑化している。

昔の車作りのチームなら、VICSのサービスが提供されないことのリスクがどんなハザードにつながるのかチーフエンジニアの自分が気がつかなくても、誰かが気がついて対策を取っていた。それが今ではできなくなっている。リスクを分析して一つ一つのハザードに対するリスクコントロールの実装を確認していかないと、安全機能に関する確証が持てない。確実に自動車の作り方は変わってしまった。いや、変えないと安全な自動車を提供できなくなったのだ。事故が起こるたびに何十年もかけて築いてきた信用ががた落ちになる。10年前に導入した ISO 26262 は役に立たない形式的なものだと思っていたが、今初めて真剣に取り組まなければいけないと実感した。

■ この2つのシナリオから考える自動車ソフトウェアの未来予想図

上記の2つのシナリオはあながちありもしない空想ではないと考えている。TPP協定が締結されたら、日本にしかないガラパゴス的な非関税障壁は次々と訴えられる可能性がある。すぐさま国際標準に対応できるほど、日本はしっかりとした基盤を持っていない。言語の問題もあるが、国際標準を教えるよい教材、よいトレーナー、よいコンサルタントが不足しているし、それらに投資するという考え方も組織の中に醸成されていない。

また、欧米のやり方でこれまでの日本製品の品質が実現できるわけではないので、欧米の要求を日本向けにテーラリングしないといけないのに、日本人はそれが大の苦手ときている。

一番目のシナリオは電気自動車の普及にともない部品の組み合わせで自動車ができてしまうという話だった。ブラックボックスの部品の組み合わせで自動車が作られてしまうことで、システム全体としての安全が脅かされるという話は、共通プラットフォーム化、ECUの共通インタフェース化が進めば絶対に増加する。

中身が分からないブラックボックスのソフトウェア部品をハードウェア部品と同じ取り替え可能な部品として使い始めたら不具合は減らない。ISO 26262 への適合を目安にすることはできるが、ISO 26262 の要求に沿って作りましたという ECU ではリスクを回避できない。なぜなら、ISO 26262 はリスク分析の結果から考えたリスクコントロール手段をセーフティマネージャ（自動車メーカー）がサプライヤに要求し、安全を管理することでリスクを回避する。システム全体のリスクを分析しないで、お墨付きがあると差し出された ECU はそもそも想定されたリスクを受容できるまで低減できているという担保がない。どんな事故が起こる可能性があるかを分析しないで、オールマイティなセーフティ機能を実装することはできない。すべてのリスクに効果のあるリスクコントロール手段などない。危ない時に制御を止めなければいけないケースと動かし続けなければならないケースはどちらも存在する。だから、サプライヤだけではリスク分析はできないのだ。人や組織も含めた安全管理やシステム全体のリスク分析抜きに、ソフトウェアをハードウェアと同じように代替えできる部品と考えたら、その時点で安全は脅かされる。そのことにどれだけの自動車メーカーやサプライヤが気づいているかが心配だ。

二番目のシナリオは、安全機能を複雑化させたために起こるディスコミュニケーションの悪影響の結果だ。全体を見通せなくなった時点で古い日本の安全確保の方法論は力を失っていく。しかし、プロセスアプローチだけで安全が確保できるわけではないので、日本のプロジェクト向けの安全へのアプローチを規格をテーラリングしながら考えなければいけない。

このことは、CMMIのレベル5を取った、取らないといった話とは次元が全く違う。CMMI のレベル5を取った組織が、ソフトウェアの不具合を起こしたとしてもクライアントから嫌みを言われるだけだろう。CMMIは営業が仕事を取るための道具にはなっても、プロダクトアウトしたソフトウェアの信頼の証にはならない。

しかし、ISO 26262 への適合は安全や信頼の指標にならなければこの規格ができた意味がない。そうでなければ技術者が苦労して規格に適合するために積み重ねた努力が無駄になる。そして、規格適合が形骸化すれば上記のシナリオのように事故が起きたり人が死んだりするかもしれない。消費者から嫌みを言われて終わるレベルの話ではない。真剣に取り組まなければ人の命に関わる可能性があるのだ。

そういう気持ちを持ってエンジニアは規格適合に取り組んで欲しいと思っている。このことは自動車ドメインのエンジニアだけでなく、リスクを抱えた製品、クリティカルな製品に携わっているすべてのエンジニアに言いたい。2011年3月に日本で発生確率が極めて低いが、発生したときの被害の重大度が極めて大きい事故が起こった。リスクの大きさ = 発生確率 × 被害の重大度 という従来の安全工学の考え方を見直さなければいけないかもしれない。（ISO 26262ではハザードの評価において、発生確率と被害の重大度に加え、回避可能性の要素が考慮されている。）

被害の重大度が大きければ、ppmオーダーでもリスクは大きいと考えなければいけないのではないだろうか。また、発生確率が予測できないソフトウェアの不具合の場合、どうやってリスクを制御すればいいのかソフトウェアエンジニアが真剣に考えなければ、誰が安全な製品を作れるのだろうか。

あんな事故があっただけに、2012年、エンジニアはどうすれば事故の再発を防止できるのか、これから起こるかもしれない事故を未然に防ぐことができるのか、自分達の技術は事故の予防や再発防止のどのように役立つのかをよく考えて、安全という同じ目標、同じ価値観をもって日々の仕事に取り組む義務があると考えている。

■ ISO 26262-1:2011 Part 1: Vocabulary （用語の定義）

ISO 26262-1 Part 1 Vocabulary では 142の用語の定義が記載されている。用語を正しく理解して規格を読み進むことは重要である。この142の用語の定義を邦訳したので参考にして欲しい。なお、この邦訳は突貫で作ったため間違いや用語同士での説明の不一致があるかもしれない。

そのような箇所を見つけられた方は是非連絡をして欲しい。多くの人のチェックを経て完成度を高めていきたいと思う。また、本資料を利用される方は 常にバージョンを確認して欲しい。間違いに気がついたら修正を加えてバージョンを上げていくつもりだからだ。

さて、142の用語を邦訳しながらあることに気がついた。それは、これらの用語はつぎの3種類に分類できるということだ。

【ISO 26262-1 で定義されている用語の分類】

  1. 安全・品質工学、規格適合に関する用語（43語）
  2. ソフトウェア工学に関する用語（30語）
  3. 自動車ドメインまたはISO26262特有の用語（69語）

邦訳の中では「安全・品質工学、規格適合に関する用語」は赤色に、「ソフトウェア工学に関する用語」は青色に「自動車ドメインまたはISO26262特有の用語」は緑色に色分けしている。

分類は主観によるものなので異論もあるかと思うが、カウントしたら1が43語、2が30語、3が69語あった。これが示すことは何か読者の皆さんは分かるだろうか。

それは、ISO 26262 という規格は、安全工学・品質工学または国際規格への適合に関する知識を有する者、ソフトウェア工学の知識を有する者、自動車ドメインに造詣が深いまたはISO 26262 の規格策定に関わった者の3者が互いに協力しないと完全には理解できないということである。

安全工学・品質工学の基礎があり、国際規格や規格適合の監査に慣れている者でも、ソフトウェア工学を深く知るものは少ない。また、ソフトウェア工学、特にプロセス改善の指導を得意とするものは、安全工学の知識を持っている者は少なく、規格適合の監査などの経験も少ないだろう。自動車ドメインの特殊な知識 ECU（電子制御ユニット）の仕組みも詳しくないと思う。一方、自動車ドメインの専門家でソフトウェア技術者の場合、安全工学は専門外だろうし、規格適合の監査は ISO 9001 くらいでしか受けたことがないだろう。（ISO 9001すら取得していない会社もあることだし）

よって、ISO 26262 に本気で取り組もうと思ったら、この3者が一つの目的、一つの目標に向かって協力しなければダメだ。それぞれの専門家が自分の強みを主張して、自分の専門分野に相手を引き込もうとしたり、相手が自分の専門領域のことを知らないことを「そんなことも知らないのか」と心の中で馬鹿にし出したりしたら、バラバラになって空中分解する。ついでに言うと、それまで知らなかったことを新しく知ったことで知ったかぶりをする者が出てきても調和は乱れる。

3者のディスコミュニケーションは相手が認知していない言葉を意識しないで使い始めたときから始まる。自分が知っている言葉を相手が知っているかどうか考えながらしゃべれる人は、主観と客観を自在に操れる人であり、世の中にそれほど多くは存在しない。ほとんどの人は自分が知っている言葉は相手も知っていると思って話をしてしまう。そして、日本人は奥ゆかしいから分からない言葉が出てきたところで、「その言葉の意味が分からないから教えて欲しい」となかなか言わない。

さて、コミュニケーションギャップの可能性を ISO 26262 の用語の例で考えて見よう。例えば、anomaly（異常）、 harm（危害）、 hazard（ハザード）、 severity（重大度）といって何のことだか、ソフトウェア工学や自動車ドメインの専門家はピンとくるだろうか。また、partitioning（パーティショニング）、baseline（ベースライン）、branch coverage（分岐カバレッジ）、 walk-through（ウォークスルー）について、規格適合コンサルタントはその意味を説明できるだろうか。また、ASILデコンンポジション、exposure（暴露）、redundancy（冗長性）について、正確に解説できる者はいるだろうか。

ちなみに、自分は最初の二群はキチンと説明できるが、最後の自動車ドメインや ISO 26262 特有の用語については自信がないところもある。

このように、分からない言葉が出てでて、そのままにしてしまうと人間は思考を停止してしまったり、自分の勝手な思い込みで解釈してしまったり、そもそも自分の専門分野でない、担当分野でないと考えることを放棄してしまったりする傾向がある。

そのような状況が現れ出すと、それは冒頭で紹介したシナリオ1やシナリオ2が始まったことを示す。ISO 26262-1 の用語集が示しているのは、この規格は3つの専門領域を合わせないと規格が目指している目標を達成できないということなのだ。セーフティマネージャが3つの領域を完全に理解することは難しいだろうが、それぞれの領域の担当は他の領域の知識を学習して、より多くのオーバーラップを持つことが求められる。そして、大事なのは安全という共通の目的、安全を確保するというエンドユーザにとっての価値を共通認識とすることだ。

自動車ドメインの場合は、上記の3つの専門領域の区分けとは別に、自動車メーカーとサプライヤという立場があるため、問題はより複雑であり、共通の目的、共通の価値観を持って規格への適合を達成するのはさらに困難を極めると予想される。

自分が考えるうまくいくシナリオは、はやり自動車メーカーにしてもサプライヤにしても、自動車ドメインの技術者が安全工学、品質工学、ソフトウェア工学について学習を重ね、それぞれの専門家からアドバイスをもらいながらも自分達が主導権を取って規格適合を進めていくという流れだ。なぜなら、規格適合を監査する者やプロセスコンサルタントは、なんだかんだ言っても自分達の仕事がエンドユーザーの命に関わっているとは考えていないだろうし、エンドユーザーの命に対してなんら責任もないからだ。しかし、自動車メーカーのエンジニアと、安全に関わるソフトウェア、ハードウェアを納品するサプライヤは違う。自分達には安全に関わる機能・性能に対して責任があると認識して仕事をしているだろう。何か事故が起これば他人からも責められるし、自分自身も責めてしまうのが日本のメーカーとサプライヤのエンジニアだ。その責任の範疇の中にいるのか外にいるのかの差はとてつもなく大きい。中にいる者は人の命を背負っているが、外にいる者はそこまでの責任は感じていない。

別な言い方をすると、そのような責任感が品質の向上に寄与するようなやり方を脱するために作られたのが ISO 26262 なのだが、現実には品質を心配する意識とプロセスアプローチの両方がないと安全は確保出来ないというのが自分の考えだ。ISO 26262 の形骸化が始まったら、安全の確保は危うくなると思っている。

規格適合は役に立たないと考えずに、たましいを入れて取り組くむには、ひとつ見方を変えればよい。ISO 26262 の適合という機会は、自分自身の幅を広げるまたとないチャンスだと考えればよいのだ。自分がブログサイトでこの特集記事を書いているのは、読んでくれる読者がいるからだけれども、それにもまして記事を書くことが自分自身の知識の幅を広げることにつながり、結果的には自分のドメインでも役に立つし、それまで気がついていなかったことがたくさんでてくることが分かっているからだ。

実際、ISO 26262 の用語の定義を邦訳して、医療機器ドメインでの解釈とかなり違うところがあることがわかった。例えば、ISO 26262-1 には validation や software validation に関することばの定義がない。 safety validation ：セーフティゴールが満足され、達成されたことを試験やテストに基づいて保証すること、という簡単な説明しかない。なぜか。おそらく、自動車ドメインではユーザーインタフェースや、ユーザーのオペレーションに起因する不具合や事故がまだ、それほど多くないのだろう。それらが多くなって、ユーザビリティに対する対策の必要性が高まってくると、validation（妥当性確認）の解説はもっと長くなってくると思われる。（いずれくわしく説明をしたいと思う。）

逆に医療機器ドメインでは ASILデコンポジッションのような考え方がまだ確立していない。ハードウェアにしろ、ソフトウェアにしろ安全を確保するためのアーキテクチャに関する研究が進んでいない。

このように専門分野やドメインを超えて知識を深めていくと、今まで気がつかなかったことに気がつき、新しいアイディアが生まれる。そのアイディアが機器の安全につながるのであれば、自分や自分達が作る製品、商品の価値を高めることに貢献する。

そう考えれば、新しい分野を勉強する時間は自分をより高めることに有益であり、決して無駄ではないことが分かる。

2012年の新年を迎えて、まだまだ勉強すべきことは山ほどあると再認識したところである。

ISO 26262との向き合い方 (6) 機能安全のマネジメント2

今週、下記のような記事が Tech-On! に掲載された。（読むには無料のユーザー登録が必要）

【専門記者が振り返る】要件管理とトレーサビリティ、この1年――ISO 26262適合で日本でもツール基盤の導入進む

変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。

要件管理のツールとして「Rational DOORS」、米PTC社の「Integrity」、フランスDassault Systemes社の「Reqtify」が挙げられており、国内のツールとしては経済産業省から約5億円の助成を受け、組み込みソフトウエア開発ツール・ベンダーのキャッツなどが中心となって、「TERAS」というツール基盤を目下、開発中であると書かれている。

※そういえば Google が検索エンジンのスタンダードになりつつあったときに、経済産業省が主導して国産検索エンジンを作ると言っていた『情報大航海プロジェクト』はいったいどうなったのだろう。

自分は、日本では要件管理ツールは日本のソフトウェアプロジェクトにはなじみにくい、ツールの価格（Integrityはサーバー側で200万円、クライアント側ノードロックで1本40万円。）だけの価値、効果を導き出すことは難しいと思っている。

なぜなら要件管理ツールは要求定義→アーキテクチャ設計→実装 というトップダウンの開発に向いており、すでにベースとなるソフトウェアシステムがあって、変更しながらものづくりを進めていくような大量に変更が発生するプロジェクト、また、要求定義を横に置いてまず作り始めてしまうような開発は想定していないからだ。（そうしないことを強制するためにツールの使用を強制するということはあるかもしれないが）

ところが、日本のソフトウェア開発ではこれまでボトムアップで作ってきていて、要求定義が曖昧なままものづくりを進め、ガンガン修正してそれなりの品質のソフトウェアを作ってしまう。

※医療ドメインではUSでAgileをクリティカルソフトウェアに使う場合にどうすれば安全を確保できるかというガイダンスが今作られている。

そのやり方がよいとは言わないが、一つ言えるのは日本ではボトムアップでソフトウェアを作っても、それほどひどい品質にはならない。要求定義をしっかりやって、そこを動かさずに先に進むという開発ができていないのに、なんとかなっているという現状だ。どんなに優れたプロセスやツールが使われている欧米製品よりも、必ずしもそのようなプロセスやツールを使っていない日本製品の方が品質がいいのはなぜなのか、これから先も、そのやり方でこれからも突っ走っていいのかどうかをじっくり考えてから、ISO 26262 を取り入れないと失敗すると思う。

日本では問題が分かったときの修正のスピードが速い。デグレードはゼロとは言えないが、とんでもない見落としは少ない。それは、品質を心配する意識： Awareness: Worrying about Quality の力ではないかと思っている。（これうまくいかず品質に悪影響を与えるケースが増えており、変更の影響を分析、管理しながら変更を実装していく XDDP という取り組みが今話題になっている。）

ユーザー要求はプロジェクトメンバの頭の中にたたき込まれていて、同じメンバが商品や商品群のライフサイクル全般に渡って関わっているので、要求定義を文書化する必要がないのだ。

だから、現場のエンジニアにとって要求分析の結果を文書にすることは「余計なこと」「規格要求のため」「作るのがルールだから」になる。要求管理が本質的な意味で役に立っていない。

これが、例えば製品開発ごとに人がごっそり変わったり、それまで開発経験がまったくないメンバを半分以上投入するようなプロジェクトだったらそうはいかない。トップダウンで粛々と進めていかないとものができてこない。要件管理ツールは、そういうトップダウンの開発にフィットしている。

構成管理や変更管理が日本でも受け入れられているのは、 構成管理や変更管理がボトムアップの開発にも十分に役立つからである。同じように要件管理ツールも普及すると思ったら大間違いだと自分は思っている。（構成管理や変更管理のボトムアップでの組織への浸透については『リコールを起こさないソフトウェアのつくり方』の二章にやり方も含めて詳しく書いた。）

さて、要件管理は製品開発にとって、ユーザーの安全確保にとってなぜ重要なのか。それは、商品の潜在的価値（別な言い方をすれば当たり前品質）に関係がある。

ユーザーは安全は当たり前に確保されていると考えている。商品を使うユーザーはメーカーがキチンと安全設計をしており、多少荒っぽい使い方をしても安全になるように作っていると信じている。特に日本製品には絶大な信頼を寄せている。

余談だが、最近の技術系新人はものづくりを企画立案からリリースまでやりきって他人に提供する経験をしたことがある者が極端に少ない。エンジニアなのに使う側の視点しかなくて、作る側の視点がほとんどない。だから、商品が当たり前にできていること、安全を実現している技術がなんだかまったく分からないし、分かりたいとも思わないし、裏方の技術に感動した経験がない。エンジニアなのに消費する側の気持ちが抜けきれていない。iPad や iPhone のユーザーインタフェースの良さをさかんに強調し、これを取り入れた方がよいと言ったりするが、その裏側にある技術については何にも知らない。このような者たちにはスティーブ・ジョブズの伝記を読んで、iPad や iPhone の誕生の裏側に何があるのか理解し、自分でも同じことができるかどうか考えてみろということにしている。

さて、製品の安全を信じているユーザーに対する保証はなんだろうか。これまでの日本では、それはエンジニアの頭の中の「品質を心配する意識：Awareness: Worrying about Quality」だった。安全を担保している技術は技術者の中にたたき込まれており、組織の中で先輩から後輩へ伝承されてきた。プロジェクトがフラットであるため、問題が起こったときに全員がその問題に対して協力して対処することで、品質に関する意識がプロジェクト全体に醸成された。設計の規範が構築されていくのだ。

誰かに命令されたからではない。エンドユーザーに迷惑をかけたことが技術者として恥じだと思うから、一刻も早く顧客満足を回復したいからプロジェクトが全員で一丸となって対応するのだ。

ところが、前述のように近年商品の当たり前にできていることを支える技術がなんだか分からない技術者が増えてきて、また、ソフトウェアシステムの規模が増大かつ複雑化してくるとユーザー要求や商品の使われ方を熟知しているプロジェクトリーダーであっても、プロジェクトメンバ全員の安全確保の意識やスキルに自信が持てなくなり、そして、商品の安全を確信できなくなってくる。

その状態を回避し、ユーザーの期待（安全は当たり前に確保されているはず）に答えるには、安全に対する要求と、その実現方法、実現の結果（証拠）を常にトレースが取れるようにしておく必要がある。そのトレースのセットがトレーサビリティマトリックスとなる。

要件管理ツールはこのトレーサビリティマトリックスを保持するための助けとなる。

しかし、日本では上記のことがプロジェクトメンバ全員に理解されていなければ、要件管理ツールは必ず形骸化する。要件管理ツールを導入しただけなら、重要な要求も、どうでもいい要求も同じレベルで管理されることになるだろう。そして、日本のプロジェクトではどうでもいいことは、ものすごい勢いで変更をかけるのでツールを使ってもかなりの手間だと感じるに違いない。

だから、要件管理をしっかり実施して、トレーサビリティマトリックスを維持するのなら安全に関わる重要な要件とそうでない要件を分離することが必要になる。要求分析を分析する手法としては品質機能展開（QFD）などがあるから、日科技連でしっかり勉強して、重要な安全に関わる要件と、仕様と検証記録を Excel シートで管理してみて、管理工数が一人あたり 40万円を超えるようなら 要件管理ツールを使ってみればよい。

または、ボトムアップ的な要件管理ツールの使い方なら組込みソフトでも有効な可能性はある。例えば、すでにあるソフトウェアシステムのアーキテクチャを UML で描いて、そのモデルの元となる要求はどんなものかを逆に分析してツールで可視化するというやり方だ。技術者の頭の中にある暗黙のアーキテクチャとユーザー要求を目に見える形にトレースし直して、可視化した後は、明示化した方の要求ともモデルを維持する、これなら現場にも受け入れられる。これなら、スパークスシステムズジャパンの　Enterprise Architectと RaQuest で実現できる。モデルの描画はEnterprise Architectで、要件管理はRaQuestで、そしてこの二つのツールを組み合わせると要件とアーキテクチャの関係を関連づけることができる。二つ合わせても5万円以下だ。

ソフトウェアは見えにくいからツールの効果も数字で表しにくいが、それでもソフトウェア組織を率いる責任者はツール類に投資した資金がどのように組織に貢献しているのかを定期的に検証しなければいけない。末端のエンジニアはそのツールがそこに当たり前に存在しているかのように使っているだろうが、彼らにはそのツールにどれくらいの費用がかかっており、その費用分の効果を出す義務がエンジニアやプロジェクトにはあるのだという意識を植え付けなければいけない。

だから思う。一本50万円とか、100万円する要件管理ツールは、問題が発生したら数百億円規模の損害が発生するような事業、プロジェクトに使う。それは軍事産業や航空宇宙開発、原子力開発などだろう。実際そのようなツールはそういう業界で使われているのであって、自動車業界でペイするのかどうかについては疑問がある。何かあったら、数百億円の損害が出るようなコンポーネントがあるのなら、そのコンポーネントの開発に対して導入して、開発のスタイルをトップダウンの設計に切り替える必要がある。しかし、単純に ISO 26262 という規格に適合するために一本数十万円する要件管理ツールを導入するのなら「気前がいいですね」と自分なら言う。また、形骸化していないかどうか3年間は定期的なチェックをお勧めする。3年たって組織内で習慣化するところまでになれば、大丈夫、形骸化はしない、組織の文化として根付くだろう。

要件管理だけでなく、日本のソフトウェアプロジェクトではたましいの入っていない活動（Activity）は必ず形骸化する。アウトプットドキュメントは「言われたから作っているだけ」「役に立たないがルールだから作っています」という代物になる。

それが積み重なっていくと技術者たちは「組織が、無駄なドキュメントを作らせているから開発が遅れる」と言い出す。サプライヤは「何も現実を分かっていないクライアントが作れと言っているので無駄だと思いつつもしかたなく作っている」という状態になる。そうではない。それは嘘だ。その技術者は無駄ではないドキュメントを作るスキルがない、そのドキュメントを作る意味を理解していないことを他人にせいにしているだけなのだ。

ISO 26262 の導入によって、日本では確実に「組織が無駄なドキュメントを作らせているから開発が遅れる」と不満を漏らす技術者が増大する。この台詞を吐く技術者には二通りあって、ひとつはソフトウェア品質に自信があるのに余計なことをやらされていると考える者、もうひとつはスキルもなくやっつけ仕事で書類の作成をしている者。

前者には、ISO 26262 が達成しようとしているユーザーの安全に対して共通の価値観を持てるように徹底的に議論することで道が開ける。後者はどうしようもない。実際に規格要求の求めに対して、まったくたましいの入っていない、うわべだけ取り繕った書類を見たことがある。彼らは要求者から注意を受けない限りうわべだけの書類作りを繰り返す。そいういう場合は、粛々と是正を要求する。そう、このやり方が欧米流のプロセスアプローチなのだ。たましいの入っていない技術者、プロジェクト、組織に対して、ルールとシステムで安全を確保する方法が欧米流のプロセスアプローチであり、ISO 26262 は基本的にはそのやり方だ。

一方、技術者の品質を心配する意識： Awareness: Worrying about Quality に働きかけ、たましいの入った成果物を作って、それがプロジェクト全体に伝搬し、改善を積み重ねていくのが日本流のやり方だ。

自分が自動車業界の皆さんに聞きたいのは、どっちのやり方で ISO 26262 への適合を進めようとしているのかということだ。

【ISO 26262-2:2011 Part 2: Management of functional safety】

さて、今回は Management of functional safety のOverview of the safety lifecycle を見ていこう。図は前回と同様に、英文をトレースし直したものと日本語にしたものをペアにして PDF にした。

5.2.1 Overview of the safety lifecycle
The ISO 26262 safety lifecycle (see Figure 2) encompasses the principal safety activities during the concept phase, product development, production, operation, service and decommissioning.
ISO 26262 セーフティライフサイクル（図2）は、コンセプトフェーズ、製品開発、生産、運用、保守及び廃棄の間の主要なセーフティアクティビティを包含する。
Planning, coordinating and documenting the safety activities of all phases of the safety lifecycle are key management tasks.
セーフティライフサイクルのすべてのフェーズにおいて、安全活動を計画すること、コーディネートすること、文書化することはキーマネージメントタスクである。

→安全活動の全般において、計画とコーディネイトと文書化が重要といっているということは、すなわち、ISO 26262-6 のソフトウェアレベルでの製品開発だけを切り出して、そこだけの要求を満たそうとしたのでは、セーフティライフサイクルは機能しない、すべてのフェーズにおいてセーフティマネジメントの計画が浸透し、各活動がリンクしていなければ、安全という目的は達成できないということを言っている。このことを分かって活動しているかどうかがとても不安。切り出し始めたら形骸化も始まる。
Figure 2 represents the reference safety lifecycle model.
図2は セーフティライフサイクルのリファレンスモデルを表している。

→この図は是非手元において自分が今やっている活動が全体のどの部分に相当するのか、製品開発のフェーズにいるのなら、コンセプトフェーズの要求を満たしているかどうかをチェックして欲しい。
Tailoring of the safety lifecycle, including iterations of subphases, is allowed.
サブフェーズの反復を含む安全ライフサイクルのテーラリングは容認されている。

→ウォーターフォールモデルのように見えるが、一つ一つの箱または複数の箱を繰り返すようなプロセスにしてもよいということ。セーフティライフサイクルにおいても自組織に合わせてプロセスのテーラリングをした方がよいということだ。概念だけでなく活動の実態に合わせて、テーラリングしたプロセスを可視化しておくのがよいだろう。
NOTE 1 The activities during the concept phase and the product development, and after the release for production are described in detail in ISO 26262-3 (concept phase), ISO 26262-4 (product development at the system level), ISO 26262-5 (product development at the hardware level), ISO 26262-6 (product development at the software level) and ISO 26262-7 (production and operation).
NOTE1 コンセプトフェーズ及び製品開発間のアクティビティ及び、生産のためのリリース後については、ISO 26262-3(コンセプトフェーズ）、ISO 26262-4（システムレベルの製品開発）、ISO 26262-5(ハードウェアレベルの製品開発）、ISO 26262-6(ソフトウェアレベルの製品開発）そして、ISO 26262-7(生産及び運用）に詳しく説明されている。
NOTE 2 Table A.1 provides an overview of the objectives, prerequisites and work products of the particular phases of the management of functional safety.
NOTE2 表A.1 は、機能安全のマネジメントの特定のフェーズの目的、前提条件、及び作業成果物の概要を示している。

→表A.1 は前回の記事『ISO 26262との向き合い方 (5) 機能安全のマネジメント1』にあるのでそれを参照して欲しい。

※今年の ISO 26262 の特集記事はこれで終了になります。また、来年をご期待ください。自動車業界の皆様また、ツールベンダーの方、規格認証機関の方、ご意見、ご質問があれば随時受け付けますので是非お送りください。

ISO 26262との向き合い方 (5) 機能安全のマネジメント1

ISO 26262 に関するアンケートで　「 お金や工数がどれくらいかかるか知りたい。」に5票入っていた。そこで、インターネットでいろいろ調べてみたら、アメリカの KVA という会社が ISO 26262 のトレーニングのオーダーシートを公開しており、そこに金額が書かれているのを見つけた。（KVA のサイトURL http://www.kvausa.com）

↓オーダーシートのURL はこちら
http://www.kvausa.com/sg_userfiles/kVA_ISO26262_Training_Registration_2011_10.pdf

1日目は機能安全マネージメントトレーニングで、2日目、3日目はシステム&ハードウェア実装、4日目がソフトウェア実装となっている。全部合わせると約30万円、一番下の行にある FSCAEとは Functional Safety Certified Automotive Engineer の略で、この会社が独自に設定した認定資格のことのようだ。この認定資格の試験を入れると総額で約37万円となる。

さて、日本のこのブログの読者の多くが、この価格を高いと感じたと思う。しかし、自分はそれほど驚かない。なぜかというと医療機器の世界でもアメリカでトレーニングを受けようとするとこれくらいの金額が要求されるからだ。

ここでよく考えて欲しい。欧米では安全や信頼はルール/責任、システム/ツール で確保するのだ。一方、日本では品質を心配する意識の強さが安全や信頼の実現に貢献している。しつこいようだが今一度『USとJapanの文化の違いと商品品質との関係』の記事を読み返して欲しい。

欧米では組織内のルール/責任に対する力が強いので、このようなトレーニングを受ける者は教育資格を根拠に組織内で責任と権限を持つ。そして資格を持ったものがトレーニングで得た知識と権限を使って、作業者へ指導をする。機能安全の要求実現に関しては資格保有者が上、作業者が下になる。組織で階層構造ができている場合に有効なアプローチだ。セーフティマネジメントのマネージャは規格の要求事項ができていないと判断したときには是正を要求できる権限を組織から与えられているし、是正を要求された方も粛々と実施する。しかし、定時になればきっちり帰る。後ろめたさはない。問題が発生したのはシステムがきちんと回っていなかったからであり、作業者の資質ではない。スキルが足らないのなら、追加のトレーニングを行う義務は組織にある。このような、是正の指摘を自分の失敗や恥じだとは思わない、考えない階層構造の組織において、品質システムはうまく機能する。

だからこそ、責任を任される者はその責任と権限に見合った知識、スキルを持っていないと上と下から「お前は能力がないから辞めろ」とか「あの上司は能力がないから辞めさせてくれ」と言われるし、逆に実績を積むことができればよりサラリーの高い組織に転職することも可能だ。だからこそ、アメリカではトレーニングに参加する者の知識を習得しようとする意気込みや真剣さが半端じゃない。分からないことは決してそのままにして帰らない。日本人がセミナーに参加する態度とは雲泥の差だ。

自分は日本でやられているほとんどのセミナーは受講者が話を聞くだけの一方的なものが多く、できるようになるまで徹底的にやる「トレーニング」ではないと思っている。トレーニングはできるようになるまでやるからこのように高いのだ。トレーニングする側の能力が低ければ客足はすぐに途絶える。それなり価値と知識やスキルを身につけさせられるという自信がなければ、これだけの金額にはできないだろう。

一方で外資系でも無料のセミナーはある。こういう場合は、その裏側にものすごく高いコンサルテーションやツールの購入を勧めるセールスが含まれていると考えた方がよい。ものすごく高いというのは、例えば1日コンサルテーションしてもらうと30万円とか、ライセンス一本あたり100万円のツールのことだ。このような費用が日本の会社の中で認められるかどうかは、組織上位層の人たちが安全や信頼を実現するための規格適合費用としてそれ相当の金（数百万円から数千万円）を支払う決心をしたときだけだ。日本のエンジニアがタダで安全や信頼を実現できている状況では認められるわけがない。

さて、欧米に比べて日本では役職の違いがありながら、特に技術分野ではフラットに近い組織構造になっており、また、マネージャーがマネージメントだけでなくエンジニアリングもやっていたりする。だから、プロジェクト内のマネージャやマネージャに指名されたベテラン技術者一人が上記のようなトレーニングを受けて、プロジェクトメンバーに「これに従え」と指示を出してもうまくいかないと思う。日本のエンジニアは「なぜ」「なんのために」について納得しないと動かない。逆に根拠も理解せずに今までのやり方を変えてしまうようなら非常に危ない。

日本の技術者はこのような縛りがなくても高い品質のハードウェア、ソフトウェアをアウトプットできる非常に珍しい人種だと感じる。たいしてトレーニングに費用をかけなくても高品質の製品を作ることができる。だからこそ、経営者はトレーニングに上記のようなお金がかかることについてなかなか理解を示さないと思う。

実際、日本では ISO 26262 の要求を社内ルールに取り込んでガイドラインを作り、そのガイドライン通りにものづくりをさせることで、形式的に規格要求を満たしたように見せるという作戦をとるだろうと予測する。いい悪いは別にして、説明責任を果たすためには、まずはそうするしかないのだ。欧米のように、一部の精鋭に資格を取らせて、そのリーダーの権限でヒエラルキーの組織構造の中で規格適合を推し進めるというやり方ではなく、関係者全員が一定の組織内ガイダンスにしたがうことで、降りかかってきた危機に対して全員でフラットに乗り切るという方法だ。

このやり方は下手をするとすぐに形骸化する。規格要求を理解せずにアウトプットドキュメントを形式的にそろえることが目的になりやすい。

このブログの特集では欧米流のやり方はうまくいかないということを見越した上で、マネージャもエンジニアもみんな同じ目線でエンドユーザーの安全を確保するために、自分たちが何をし、また、諸外国の人々に自分たちが作った成果物の安全性や信頼性をどのように主張したらよいのかを解説し、活動が形骸化せずに安全という最終目的を達成できることを目指している。

日本の製造業の会社でソフトウェアエンジニア出身の品質保証担当という人にはなかなかお目にかかることがない。電気や機械の出身であったり、純粋に品質畑で上に上がってきた人が多いように感じる。その人たちに、ISO 26262 のソフトウェア開発の要求部分を指導させるには、相当無理がある。だからといって、ソフトウェアQAのような部門、担当を急遽作って勉強させ、権限を与えるのもフラットな組織構造ではうまくいくような気がしない。ソフトウェアの規格適合の部分を外部に丸投げすると、さんざんかき回され、規格の認定を受けているというツールを買わされ、ぐちゃぐちゃになる危険性がある。ルール/責任が明確化されており、システム/ツールを使いこなすのが上手なところでうまくいった方法をそのままテーラリングもせずに日本で実践しようとしても失敗するだけだと思う。

そうならないためには、日本人がアウトプットする成果物の品質がなぜ高く、ルール/責任、システム/ツールを駆使している欧米製品の品質が日本の製品の品質に追いつけていないのはなぜかについて、自分たちの中に答えを持っている必要があると強く思う。その確信がないと、欧米流を受け入れても実質的な安全や信頼は向上しない。

この命題に対する答えのヒントとして言えることが一つあると思う。それは、上記のことはスタンドアロン製品には当てはまるかもしれないが、ネットワーク接続するような製品、複数の機能を組み合わせないと要求を実現できないような製品ではたぶん成り立たないという点だ。

ようするに、特定のエンジニアが商品や商品群全体を見渡すことができ、商品のライフサイクル（開発開始から市場になくなるまで）全体に渡って関わる、責任を持つことができる場合は日本の商品の品質は高いが、他部門や他社のコンポーネントを組み合わせないと商品の重要な機能を動かすことができないようなケースでは、その限りではないということだ。

自動車で言えば、機能と性能が責務分割できていたこれまでは品質を高く維持できてきたが、今後、それらがクロスオーバーしないとユーザーの要求を満たせなくなってくると、それまでのやり方では予測できない不具合に悩まされることになるということだ。そのために、ISO 26262 を使う必要があり、これまでの日本のエンジニアの良さ、高品質を実現できる能力を低下させないようにしながら、ISO 26262 の要求のよいところを吸収していく必要があると思っている。

【ISO 26262-2:2011 Part 2: Management of functional safety】

さて、用語の定義の邦訳はもうしばらくまっていただくとして、今回は ISO 26262-2:2011 Part 2: Management of functional safety の解説に入っていきたいと思う。

以下が　Management of functional safety：機能安全のマネジメントのパートの目次で、「5 セーフティマネジメントの要求」「6 コンセプトフェーズと製品開発間のセーフティマネジメント」「7 製造のためのアイテムリリース後のセーフティマネジメント」が3つの大きな柱となっている。

ISO 26262-2:2011 Part 2: Management of functional safety は、セーフティマネジメント全体に対する要求であり、こういったところはエンジニアには苦手な分野で、品質保証担当や製品開発のプロセスをマネジメントするような人が得意なところだ。

※この後の記事は元のブログサイトをお読みください。（表を掲載しているため）