自分は医療機器ドメインのソフトウェアエンジニアとしてのキャリアが24年である。そして、約20年前、自分がソフトウェアを担当した製品が、FDA（アメリカ 食品医薬品局）の定期査察で査察の対象となり、Warning Letter を受け、約1年間アメリカ向けの出荷が停止された。
その当時、一人で製品のソフトウェアを作っており、システム全体を完全に把握できていたし、ソフトウェアの検証についても我流ではあったが自信があった。実際、その製品でソフトウェアの問題はほとんど起こらなかった。（唯一、たった1ビットの設定ミスでソフトウェアを改変したことがあったので完璧ではなかった）
1990年頃、すでに、FDA は医療機器や医療機器に搭載されているソフトウェアに対して V&V (Validation & Verification）を客観的な証拠によって示すことを要求していた。
自分は個人のファイルとして検証記録を持っていたが、それは組織的な品質マネジメントの一環として実施したものではなかった。すなわち、「自分はキチンとやっていたが、組織的な品質システムとして実施されたものではない」という状態だった。
それだけの問題ではなかったが、組織的にFDAが要求している品質システムが実施できていないという理由で Warning Letter が発行され、その後、是正できたことを示すための取り組みを苦労しながら実施し、確認の監査をパスした。
その当時、自分は「なぜ、それがダメなのか」「担当製品の検証の証拠があるのになぜ認めてくれないのか」まったく分からなかった。
その後、FDAが公開している要求を読み進むうちに、その理由が分かった。個人が自分の考えで実施している検証は品質マネジメントに基づいたものではないローカルルールで行われものであるため認められないのだ。
おそらくこの認識のギャップは、国民性にも大きく関係している。プロジェクトへの人の出入りが多い欧米の企業では、個人的なアクティビティで支えられている信頼や安全は非常に危ういものに写る。製品のライフサイクル全て、また、製品群のライフサイクルのほとんどに同じ技術者が関わるような日本の開発スタイル、品質保証の概念とは状況が異なる。
だからこそ、しっかりやっているはずだった自分の製品への Warning Letter は青天の霹靂だった。ただ、このことは自分の技術者人生の中で大きな分岐点となった。世界標準のやり方でないと通じないことがあることに気がついた。この頃から品質マネジメントシステムとは何か、日本人が品質を作り出すやり方とは何が違うのかについて考え続けている。
この出来事ををきっかけにして、アメリカや国際標準が求める品質マネジメントシステムやソフトウェアの安全設計、品質管理について約20年間取り組んでいる。
自分は品質保証部門出身ではない。いくつかの製品開発の実績を経て、技術者から支援者になった。製品担当、エンジニアの視点と品質保証や規格適合を求める側の視点も持っている。
だから、自動車ドメインで ISO 26262 の適用に関して、現場のソフトウェアエンジニアがこれから苦しむことがどんなことか分かる。実際に医療機器のドメインで20年前に経験済みだから、自動車系のエンジニアがこれからどのようにして階段を上っていかなければいけないのかが見える。
ここ数年で多くの自動車系技術者が青天の霹靂を実感することが分かっている。そして、そのショックが「した方が良い」と書かれていることを「しなければならない」と判断させてしまうことも分かっている。ISO 9001:1997 や CMMI の取得を目指したときのことを思い出して欲しい。規格要求を神のお告げのようにふれ回る者が必ず出てくる。
ISO 26262 は誰のために、何のために作られたのか。それは、自動車を利用するものの安全のためだ。これからの技術者の努力が、いかに大変であろうと自動車の安全に貢献するものであればよい。しかし、自動車メーカーやサプライヤのエンジニアが外乱光で利用者の安全という目標を見失ってしまうのは忍びない。
幸い、医療機器ドメインは市場もそれほど大きくなかったせいか、これまで、そういった外乱光はなかった。アメリカ人は我が道を行くが、基本的にフェアーな精神を持つ。よって、FDAの査察は非常に厳しいがそれで儲けようという考えはない。あくまでもアメリカ国民の安全を確保するために厳しくチェックをする。
そのコンセプトに自分は共感を持っている。あくまでも目的は利用者の安全であり、そのためにやるべきことを要求する。要求とは異なる手段であっても、利用者の安全が確保できる代替え手段があるのならばそれは認められる。
こういった国際標準に対する考え方が分かっていないと、振り回されたあげくに、利用者の安全をかえって脅かすハードウェア、ソフトウェアができてしまう。自分は門外漢かもしれないが、そのことをを非常に恐れているし、技術者、特に日本のソフトウェアエンジニアも規格に適合したら前よりも危ういソフトウェアになってしまったなどという結果は決して望んでいないと思う。
こんな背景から、自分はドメイン違いでありながら、 ISO 26262 に関する記事を書いている。
もしも、このブログの読者がさらなる情報を引き出したいと思うのであれば、このテーマに関する記事を続けていこうと思っている。ブログの右上にアンケートがあるので12/9 までに投票してもらい、反応が多ければ、このテーマの記事を続けたいと思う。
【ISO 26262 の取り組み方 その1】
前置きが長くなってしまったのだが、記事一回につき、一つ以上のトピックスを書いていきたい。まずは、その1 「国際規格の読み方」。
国際規格を読む場合、注目して欲しいのは規格番号の後ろに付いている年号である。ISO 26262 の場合、2011年に発行されたので、ISO 26262-1:2011といったように表現される。
なぜ、年号に注目すべきかというと、規格は必ず改変されるという目で見て欲しいからである。時にISO 26262 は新規に制定された規格だから、運用していくうちに問題点がどんどんでてくる。この場合、規格の利用者はその問題点を国際委員に告げて、よりよくしていけばよい。
日本人の多くは国際規格は天から振ってくると思っている。実際にはそうではない。国際規格は各国で意見を出し合って、よりよい方向に修正していくものなのだ。日本人は奥ゆかしいから、文句をなかなか言わないが、おかしいと思うこと、修正した方がよいと思うことはキチンと主張しないと自分達が損するだけだ。
では誰に言えばいいのか。それは各業界には工業会があり、工業会から必ず ISO Technical Committee に代表を出しているはずだから、工業会の代表に問題点を伝え、工業会に参加していないのなら今からでも参加すればよい。自組織に工業会の代表がいるにもかかわらず、その人が情報を発信しない、もしくはその人へ情報を伝達しない技術者がたくさんいる。それでは国際規格を自分達に使いやすいように変えることはできない。まずは、交渉のテーブルに乗る必要がある。
さて、ISO 26262 に取り組むにあたって最初にするべきこと、それは規格を読むことだ。最初に自動車メーカーとサプライヤのエンジニアに警告しておきたいのは、規格を読まずにコンサルタントなど外部の者から知識や支援を一方的に受けては絶対にいけないということだ。
例えば、ISO 26262-6:2011 Part 6: Product development at the software で
Methods for the verification of software unit design and implementation のセクションの表9に
Control flow analysis と Data flow analysis が ASIL C と D について ++ となっている。
++ の意味は“++” indicates that the method is highly recommended for the identified ASIL;だ。
highly recommend は強く推奨されるだから、日本語に変換すると、「ASIL C と D のソフトウェアユニット設計では、コントロールフロー分析、データフロー分析をすることを強く推奨する」という要求になる。
8.4.5 The software unit design and implementation shall be verified in accordance with ISO 26262-8:2011 Clause 9, and by applying the verification methods listed in Table 9, to demonstrate:
※26262-8:2011 Clause 9 のタイトルは"Verification" で具体的に関係ありそうなのは 9.4.3 Verification execution and evaluation と思われる。
とあるので、表9 に示された検証メソッドを使って ISO 26262-8:2011 箇条9 への一致を示せと言っているが、考えてみて欲しい。電気的安全性に関する要件、例えば「患者漏れ電流が AC/DC 0.01mA 以下」ならば、テストによって確実に合格か不合格かを判定できる。ところが、ソフトウェアの場合、「コントロールフロー分析、データフロー分析をすること」と、利用者の安全は直接は結び付かないし、「コントロールフロー分析、データフロー分析」ができているのかどうかどうか、目的に対して効果を発揮できているかどうかを証明するのも難しい。ようするにに自分達が目的の達成のために有効であることを確信した上で、実施しましょうというのが本質的な要求のはずだ。
※医療機器ドメインでの歴史的経験から考えると、できているかどうか客観的に判定できないことを規格要求にしてしまっているところに ISO 26262 の未熟さを感じる。こういう場合は方法論ではなく、Activity （どのような活動が必要か）を要求してその活動に対するエビデンスがあるかないかをまずチェックし、その次に段階で活動の妥当性(=目的への貢献度）をヒアリングするような仕組みの方がよいと思う。方法論を推奨してしまったら、その方法論が絶対に必要だという話しが一人歩きするのは目に見えている。
これを規格原文の NOTE を含むディテールを読まずに、また規格を適合する側のスタンスが固まっていないうちに外部の者から話しだけ聞くと「自動車のソフトウェアユニット設計では、コントロールフロー分析、データフロー分析をしなければいけない、しないと規格が通りませんよ」となる。人間は、潜在的にそうして欲しいと思うと、表現をより大きくして聞いている者の気を引こうとするからそうなるのだ。
自分ならこう言う。
ISO 26262 では ASIL C と D のソフトウェアユニット設計において、コントロールフロー分析、データフロー分析をすることを強く推奨しています。なぜ、それが必要だと主張しているのか分かりますか。まず、この○○のソフトウェアユニットの ASIL を C と D にしている根拠を説明してください。そのユニットがユーザーに及ぼす危険はどのように回避されるのか、意図しないようなシステマティックフェイラーが起こらないためにどんな分析、設計、検証をしているのか教えてください。
そこで、十分に納得のいく説明ができるるのなら、コントロールフロー分析、データフロー分析以外の手段を使っていたとしても、外部の人間に聞かれたら、それを堂々と説明するように言う。全く何のことかわからないという反応を示したら、方法論ではなく規格のコンセプトや背景をプロジェクトメンバ全員に対してレクチャーする。そのトレーニングから始めなければ手段が目的になる。
手段が目的になってはいけない。目的を達成できるのなら手段は重要ではない。規格が手段を例示しているのは、何をすればいいのか分からない、これから何をすればいいのかの指針が欲しい者にサジェスチョンを与えているのだ。だから、highly recommend と表現しているのだ。highly recommend を「絶対にやらないといけないと規格に書いている」という者は驚くほどたくさんいる。彼らの中には悪気がなく、大事なことを教えて上げようと親切心でそういう者もいる。そう、彼は規格適合を自分の力でやりきった経験がないから、簡単に表現を強くしてしまう。しかし、自分はそれを現場でやりきることがどれだけたいへんかを知っているから、軽々しく highly recommend を「絶対にやらないといけない」などとは決して言わない。
したがって、規格適合を目指しているメーカーとサプライヤのエンジニアは必ず、規格の原文を読み、誰かから「規格要求だから○○をやれ」と言われたら、規格のどこの要求のことを言っているのかを聞く習慣を付けるべきだ。そして、その方法が利用者の安全にどのように貢献するのかを必ず考える。そこに確信が見いだせないのに実践しても意味がない。利用者の安全に貢献するという確信があってこそ、その方法論は生きてくるし、実際にそうなる。エンジニア側の確信なしにコントロールフロー分析、データフロー分析をやって、利用者の安全につながるわけがない。形式的に規格適合を示すことに貢献するだけだ。
ISO 26262 のような国際規格は、多くの場合工業会が和訳して対訳版を日本規格協会が発売する。最近は PDF 版と 紙のどちらかを選択して買うことができる。現時点で ISO 26262 は邦訳版ができていないようで、英文のものしか売られていない。（ちなみに ISO の本家からも買うと 円高差益の御利益に預かれるのに、日本からアクセスしていることが分かると 日本規格協会から買いなさいと怒られる。）
さて、ISO 26262 は下記のようにパート分けされており、それぞれ単独で発行販売されている。FDAがガイダンスを無料で公開しているのに対して ISO 規格はしっかりお金を取る。下記の各パートは日本規格協会で買うとそれぞれ一万円くらいするが、適合を目指すのであれば買うしかない。
ちなみに、自動車系のソフトウェアサプライヤーなら、まずは、Part1, 2, 3, 6 を読んで欲しい。工業会の邦訳を待たずに、英語版を買って組織内で持ち回りで訳しながら勉強会をするとよい。邦訳しながら読むと詳細に理解できる。
ISO 26262-1:2011 Road vehicles -- Functional safety --
- ISO 26262-1:2011 Part 1: Vocabulary
- ISO 26262-2:2011 Part 2: Management of functional safety
- ISO 26262-3:2011 Part 3: Concept phase
- ISO 26262-4:2011 Part 4: Product development at the system level
- ISO 26262-5:2011 Part 5: Product development at the hardware
- ISO 26262-6:2011 Part 6: Product development at the software
- ISO 26262-7:2011 Part 7: Production and operation
- ISO 26262-8:2011 Part 8: Supporting processes
- ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses
※この記事をここまで読んでくれた方はこの後『ISO 26262との向き合い方 (21) 安全について理解を深める』を是非続けて読んでいただきたい。そうすれば、筆者がなぜ、この規格にこだわっているのかの本質が分かると思います。
0 件のコメント:
コメントを投稿