自分は、医療機器ドメインの者としてプライベートな立場で下記のコメントを送った。他のドメインの方も、このガイドライン案に真摯に向き合ってコメントがあればコメントをしていただきたいと思う。
なお、信じてもらえないかもしれないが、このパブリック・コメントは自分や自分の所属組織、所属業務ドメインの利益のために書いたのではない。医療機器を使うエンドユーザーや医療機器を作るエンジニアのことを第一に考えて書いた。本ブログを隅々読んでいただいている方には理解していただけると信じている。
※パブリックコメント
パブリックコメント（Public Comment、意見公募手続、意見提出制度）とは、公的な機関が規則あるいは命令などの類のものを制定しようとするときに、広く公に（=パブリック）に、意見・情報・改善案など（=コメント）を求める手続をいう。公的な機関が規則などを定める前に、その影響が及ぶ対象者などの意見を事前に聴取し、その結果を反映させることによって、よりよい行政を目指すものである。通称パブコメ。日本では、意見公募の手続きそのものを指すことばとしても用いられるため、本来の行政が政策、制度等を決定する際に公衆の志見を聞いて、それを考慮しながら最終決定を行う仕観み、における公募に寄せられた意見と区分して、国民、市民など、公衆の意見はおもに「パブリックコメント手続」と呼ばれる。
-----------------------------
ソフトウェア品質説明のための制度ガイドライン（案）～パブリック・コメント募集のお知らせ～
2013年3月29日公開
独立行政法人情報処理推進機構
技術本部 ソフトウェア・エンジニアリング・センター
http://sec.ipa.go.jp/pubcom/20130329.html
-----------------------------
ソフトウェア品質説明のための制度ガイドライン（案） パブリック・コメントを送りますのでご査収ください。
<本パブリックコメントの趣旨>
ソフトウェア品質説明のための制度ガイドライン（案） ではソフトウェア品質を高める、ソフトウェア品質の客観的に説明するための方策、制度を提案している。しかし、ソフトウェア品質を説明することで製品または製品に搭載しているソフトウェア、またはソフトウェアシステムの安全を説明、証明することはできない。本コメントはこのことを主張するものである。
特にクリティカル・セーフティシステムの範疇にある医療用ソフトウェアに関しては、経済産業省より 医療用ソフトウェアに関する研究会-中間報告書が 平成25年3月28日 に発行されているので、これを参照していただきたい。
ソフトウェア品質説明のための制度ガイドライン（案） に欠けており、医療用ソフトウェアの安全確保のために国際社会から必須要求となっているのは、ISO 14971に代表されるリスクマネジメントの考え方である。ソフトウェア品質説明のための制度ガイドライン（案）中にもリスクの評価ということばが現れるが、リスクマネジメントを行う際に、対象となる製品やソフトウェアがユーザー、オペレータ、周辺環境に及ぼすまたは影響を受ける具体的なリスク、危険状態等を想定せずに安全を確保することはできない。ソフトウェア品質の説明で安全が説明、確保できるというのならそれはすべてのリスク、ハザードに有効な銀の弾丸が存在することを主張しているのと同じである。
ソフトウェア品質説明のための制度ガイドライン（案） のスコープ（2. 制度の基本的な考え方）はソフトウェア品質に限定し、スコープから明確に安全（セーフティ）を除外することを提案する。
以上
-----------------------------
-----------------------------
安全について理解を深める
世の中で数学や物理、化学など再現が可能で証明できる定理はたくさんある。一方で、答えが同じにならないこともたくさんある。人間が作るソフトウェアに関することはほとんどがそうだし、安全に関する概念、定義も同様に絶対的なものは存在しない。
そこで、何をもとに安全(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年間燃料の補給が不要で安全性も完璧だという触れ込みで発売されたとする。原子力エンジンの製造メーカーは、異常時には超小型原子炉を停止させる独立した安全装置が付いているので、どんな用途にも安全に使えると宣伝した。
しかし、最初の例示したように、この超小型の原子力エンジンの安全装置は飛行機のリスクコントロールには使えない。安全に原子力エンジンを停止すれば、飛行機が墜落してしまうからである。
飛行機の製造業者はそんなことは百も承知なので、例えば、エンジンを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（医療機器）→医療機器のソフトウェア開発に対する教訓
これらの事故が、安全に貢献する方法論を生み出すきっかけを作った。事故情報をインプットにしないで、リスクコントロール手段を提案するのは間違いだと思っている。
