いろいろな国際規格を見てきたが、商業目的につながることが目に見えているツール種別の推奨やツール使用の条件のような内容を規格の本文に書いているのは、IEC 61508-7(Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures) と、ISO 26262-8 (Supporting processes) だけではないかと思う。
ET2012 で富士設備工業（株）の浅野さんに FAA(アメリカ連邦航空局：Federal Aviation Administration)では、当初、航空機開発を行う際に使用するツール認証を一般的なソフトウェア開発プロセスの判断基準で行っていたが、問題があったので止めたことを教えてもらった。
【The Latest Trends in International Standards Required for Certification 国際スタンダード認証に必要なテストの最新動向 October 5, 2012 Tokyo LDRA資料より引用】
The FAA and Tool “Certification” FAA のツール認証について
• The United States Federal Aviation Administration (FAA) once tried issuing “letters of certification credit” for using “pre-qualified” tools.
かつてFAA (《米》連邦航空局) では、“認定済み” ツールの証明書の発行を試みた。
– The pre-qualified tools were evaluated against a generic set of software development process criteria.
認定済みツールは一般的なソフトウエア開発プロセスの判断基準で評価された。
– The letters of certification credit imposed constraints on the use of the tools to match the generic development process criteria.
それら認定済みの証明書では、一般的なソフトウエア開発プロセスの判断基準に従ってツール
を用いるといった制約を強いた。
• Because the FAA’s software development guidance allows for various development methodologies to satisfy the objectives, it was found that many tool usage scenarios did not meet the constraints on tool use.
FAAのソフトウエア開発ガイダンスではオブジェクティブを満たすうえで、様々な開発方法論を認めている。それゆえ認定上のツール用法の制約に、様々なツール使用のシナリオは合わないことが明らかになった。
【引用終わり】
ストレートには書いていないが「認定済みの証明書があるこのツールを使え」という制約は、実際のツール使用のシナリオに合わない、すなわち本末が転倒していたことを認めている。認証済みのツールを使った方が航空機ソフトウェアシステムの安全や信頼の確保の効果が高いという傾向が見られなかったのだろう。
医薬品や医療機器の世界では、アメリカのFDA が CSV（Computer System Validation）を製造業者に求めている。CSVの目的は、クリティカルな製品を開発、製造する際に、ツールや自動工程で使うソフトウェアの妥当性を評価することである。
簡単に言えば、危ないものを作るのに何らかのソフトウェアを使っているのであれば、それが製品の安全を脅かしていないことを確認して根拠を示せと言っている。
根拠を示さなければいけないのは、製造業者サイドであって、ツールベンダーではない。（ツールベンダーやサプライヤと協力して根拠を示すことはある）
ツールやソフトウェアシステムが使われる場面、用途を知らないツールベンダーがツール認証を掲げるのとは、考え方がまったく違う。
ツールを含むコンピュータシステムのバリデーションを求めているのは、対象となる医薬品や医療機器の安全がコンピュータシステムによって脅かされないかどうかの確認であり、それを示すためには、どんなリスクが存在するのか特定しなければいけない。
どんなリスクがあるのかを知っているのは、ツールやコンピュータシステムを使う側なので、使う側がリスクに対して検証結果の有効性を確認する。一般的なソフトウェア開発プロセスに従って開発されていることを示したツール認証では、リスクを回避できることは証明できない。なぜなら、ツールを認証する際に、ツールを使用する側にどんなリスクがあるのかを想定していないからである。
例えば、モデルや高級言語からコードをジェネレートするツールがあったとしよう。それらのツールがツール認証を持っていたとして、バグが絶対にないかといったらそうではないし、ツール認証はバグがないことを保証している訳ではない。だから、ツール認証だけを安全の根拠にしてクリティカルなモジュールの開発には使えない。
だから、FAA もツール認証を止めたのだろう。（ It was found that many tool usage scenarios did not meet the constraints on tool use. )
じゃあ、ISO 26262-8 の「ソフトウェアツールの使用への信頼」が何を要求しているのか、キチンと読んでみよう。
ISO 26262-8 ソフトウェアツールの使用への信頼
11. ソフトウェアツールの使用への信頼11.1 目的
この節の第一の目的はソフトウェアツールに対する信頼の要求水準を決めるための基準を提供することである。
この節の第二の目的はそのソフトウェアツールが ISO 26262 で要求される活動や、タスクのテーラリングに使用するのが適切であるという証拠を作成するための認定手段を提供することである。（すなわち、ユーザーは ISO 26262 で要求される活動やタスクのためのソフトウェアツールの正しい機能を信頼できる）
11.2 総則
システム、そのソフトウェア又はハードウェアエレメントの開発で使われるソフトウェアツールは、ISO 26262 によって要求される活動とタスクのテーラリングを通じて、安全性ライフサイクルのテーラリングを支援あるいは可能にすることができる。その場合、ソフトウェアツールが効果的に下記の目標を達成できるという信頼が必要である。
a) 誤った出力につながるソフトウェアツールの故障に起因する、開発された製品のシステマティックフォールトのリスクを最小にすること。
b) ISO 26262 によって要求される活動やタスクが、使用されているソフトウェアツールの正しい機能に依存するものであれば、開発プロセスは ISO 26262 に十分適合しうること。
備考："ソフトウェアツール"は、個別に使用されるスタンドアロン・ソフトウェアツールからツール・チェーンに統合された一連のソフトウェアツールまでを含むと考えてよい。
例：そのようなソフトウェアツールは、市販のツール、オープン・ソース・ツール、フリーソフトウェア・ツール、シェアウェア・ツール又はユーザーによって社内で開発されたツールでもかまわない。
上記の状況の下の開発で使用されるソフトウェアツールに対する信頼の要求水準を明らかに決定するために下記のような基準が評価される：
－機能不全のソフトウェアツールとそれにともなう誤った出力が開発中の安全関連アイテム又はエレメントにエラーをもたらす若しくはエラー検出ができないという可能性。
－その出力におけるそのようなエラーを防ぐ若しくは発見できることに対する信頼
防止または発見方策に対する信頼を評価するために、安全関連アイテム又はエレメントの開発プロセスに実装されるソフトウェアツールに対する外部からの方策（例えばガイドライン、テスト、レビュー）だけでなく内部からの方策（例えば監視）も考慮され評価されることができる。
決定されたツール信頼水準により必要と判断されれば、適切な認定方法はこのツール信頼水準とソフトウェアツールを使用して開発されることになっているアイテム又はエレメントに割り当てられるすべての安全要求の最大のASIL両方に適合するために適用される。その必要がなければ、そのような認定方法を適用する必要はない。
というのが総則の内容で、この後、次のような節が続く
11.3 この節への入力
11.3.1 前提条件
11.3.2 追加の支援情報
11.4 要件及び推奨
11.4.1 一般的な要件
11.4.2 あらかじめ定められたツールの信頼水準または認定の妥当性
11.4.3 ソフトウェアツールの評価基準またはその認定に対する遵守性
11.4.4 ソフトウェアツールの使用法の計画
11.4.5 分析によるソフトウェアツールの評価
11.4.6 ソフトウェアツールの認定
11.4.7 使用実績による信頼性の向上
11.4.8 ツール開発プロセスの評価
11.4.9 ソフトウェアツールの妥当性確認
11.4.10 ソフトウェアツール認定の確証レビュー
11.4.9 でソフトウェアツールの妥当性確認(Validation of the software tool)があるが、この内容なら、医療機器の世界ではValidation ではなく、Verificationになる。11.4.6 のソフトウェアツール認定の手法の中に、11.4.9 のソフトウェアツールの妥当性確認が推奨されているのだが、ツールベンダーや第三者認証機関が、そのツールを使う対象の Intended Use を知らないのに、Validation できるはずがない。
できるのは一般的なソフトウェア開発プロセス通りに作ってますよということの証明でしょ。それをクリティカルシステムに使用する際の信頼性の根拠（安全性の根拠でないことに注意）として胸を張られてもなぁと思う。
総則 a) の 「誤った出力につながるソフトウェアツールの故障に起因する、開発された製品のシステマティックフォールトのリスクを最小にすること。」を製品の Intended Use を考慮せずにやろうとしたら、検証は永遠に終わらない。「リスクを最小にする」というところがミソだ。リスクを最小にするということは、リスクは完全にはなくらならないということを示している。
医療機器ドメインでは、このような場合 「リスクコントロール手段によってリスクが受容できるレベルまで下がっていることを確認する(ISO 14971)」 となる。リスクを受容するためにはリスクとリスクを制御するための手段を特定しなければいけないが、システマティックフォールトのリスクと言ってしまったらそれはソフトウェアのバグのことになってしまう。バグの数を最小にせよというのは努力目標にしかならず、目に見える具体的なゴールにはなり得ない。
実際に、バグが一個もないツールなんてあるわけがないし、仮に一個あったとして、それがどんなことに影響するかはツールを作る側には分からない。
かつて、複雑なコンパイルオプションを指定して、特定のC言語のコードを記述すると、期待されないアセンブラが吐き出されるといったコンパイラの不具合通知を見たことがあるが、たいていの場合、そのような特殊な複合条件（例えばメモリ最小化オプションとの組合せ）で製品開発はしていないからセーフであることが多い。しかし、どこかのプロジェクトでそんな使い方をしている可能性はゼロではない。万が一、その不具合に合致した使い方をしていた製品がとても危ないところの制御をするソフトウェアだったら問題だ。
認証には保証を伴う場合もある。例えば日本の場合、医薬品の許認可をするのは国であり厚生労働省である。よって、認可した医薬品に問題があれば、国はその責任を負う。薬害エイズや肝炎訴訟では国が許認可に対する非を認め再発防止と被害者に賠償の責任を負った。だから認証する側も同じ問題を見逃してはいけないので真剣だ。
アメリカもすごい。会計検査院が 「FDA（食品医薬品局）の取り組みがなっていないから、認可した医療機器が問題を起こして国民が不利益を被っている」と平気で指摘する。
FDA が指摘に対してアクションプランとその進捗状況を公開しているので興味のある方は参照されたし。（こちら）
一方、ISO 26262 のツール認証はどうだろうか。ツールを認証した第三者認証機関は、そのツールの不具合が原因で問題が起こったときに、何らかの保証をしてくれるのだろうか。何かしらの責務を負って認証しているのだろうか。
自動車業界はツール認証も含めて、ISO 26262 の取り組みが、製品開発にどのように影響したのか、効果があった点、効果がなかった点、逆に品質向上に足を引っ張った点を今後振り返って情報発信する義務があると思う。
経営層にとっても規格適合に投入した金が、エンドユーザーの価値向上に貢献し、組織の利益にとってプラスに働いたのかどうかをいずれ検証しなくてはいけないだろう。
また、ツール認証をことさら強調するツールベンダーの人には下記のことを聞いてみるとよいだろう。
- 認証によって何が確認されたの？
- 認証によって何が保証されるの？
- ツールのバージョンが上がったら認証やり直すんですか？
- ツールの妥当性確認って何をやったの？
- ツール認証時の審査結果のサマリを見せてもらえる？
