IEC 62304 ソフトウェアのライフサイクル

「ソフトウェアは動けばいい。仕様書やテスト記録は、後からまとめて作ればいい」ーー組み込み開発の現場で、今も耳にする言葉である。だが、医療機器ソフトウェアのライフサイクルプロセスを定めるIEC 62304（IEC 62304:2006＋A1:2015）は、こうした後づけを前提とした開発とは相いれない。

IEC 62304が求めるのは、ソフトウェアを場当たり的に開発するのではなく、開発から保守までを一つのライフサイクルとして計画的に回すことである。要求を定め、設計し、実装し、検証する。リリース後も、問題解決・変更管理・構成管理を続ける。そしてその全体を、文書と記録で裏づける。

特徴的なのは、ソフトウェアシステムを安全上の影響に応じてソフトウェア安全クラスA・B・Cに分けることだ。ソフトウェアが危険状態に寄与しない場合、または寄与しても、ソフトウェアシステム外部のリスクコントロール手段を考慮した後のリスクが許容可能である場合はクラスAとなる。許容できないリスクが残り、起こり得る危害が重篤でない傷害である場合はクラスB、死亡または重篤な傷害である場合はクラスCとなる。クラスに応じて、適用される開発・文書化・検証の要求事項が異なる。

つまりクラス判定は、ソフトウェアの故障だけを切り離して行うものではない。そのソフトウェアが危険状態にどう寄与し、結果としてどのような危害が生じ得るかを、リスクマネジメントの中で評価する。ソフトウェアシステムの外側に置かれたリスクコントロール手段も、判断材料に入る。

だからクラス判定は、IEC 62304単独ではなく、医療機器のリスクマネジメント規格であるISO 14971と結びつけて理解する必要がある。ここで、IECとISOの関係も整理しておきたい。IECは主として電気・電子および関連技術分野、ISOはその他を含む幅広い分野の国際標準化を担っている。

ただし両者の領域は完全に二分されているわけではなく、共同で策定される規格もある。IEC 62304は、医療機器ソフトウェアのライフサイクルプロセスを定めたIEC規格である。初心者が最も戸惑うのは、62304を読んでも「どう作ればいいか」がそのまま書かれていないことである。

規格は、要求分析・設計・検証・変更管理といった実施すべきプロセスやタスク、作成し維持すべき成果物を、かなりの程度まで規定している。だが、どのツールを使い、どの粒度でテストし、どんな様式で記録を残すかという実施方法の細部までは、一律に指定しない。

ここを「規格が不親切だ」と嘆く人がいるが、逆である。製品の特性、リスク、開発体制、使用技術に応じて合理的な方法を各社が定めよ、というのが規格の思想なのだ。細部を決めるのは規格ではなく、あなた自身である。

この自覚がないと、他社の手順書を丸写しして、自社の実態と乖離した、継続的に運用できない手順を抱え込むことになる。規格要求を満たす具体的な方法は、自社の品質マネジメントシステムの中で定義しなければならない。クラス分けにも、初心者が陥りやすい誤解がある。

「このソフトウェアは単純だからクラスAだろう」と、機能の複雑さやコード量でクラスを決めてしまうことだ。単純な計算しか行わないソフトウェアでも、その結果が薬剤の投与量に影響するなら、誤った値がもたらす危害を慎重に評価しなければならない。ただし、投与量に関わるという理由だけでクラスが自動的に決まるわけでもない。

ここでもクラスを左右するのは、ソフトウェアの規模や複雑さではない。ソフトウェアが危険状態にどう寄与するか、外部のリスクコントロール手段を考慮した後のリスクが許容可能か、そして起こり得る危害がどれほど重大かである。この見立てを誤れば、本来適用すべき開発・検証要求に適用漏れが生じる。

もう一つ重要なのは、ソフトウェアがリリース後も変わり続ける製品だという点である。バグ修正、セキュリティ対応、使用環境への適応、機能追加が前提であり、62304が保守・問題解決・変更管理・構成管理を重視するのはそのためだ。一度リリースすれば長く変更されない従来型の製品と同じ感覚のままでは、最初のアップデートでつまずく。変更によって新たなリスクが生じないか、既存機能に影響しないか、どこまで再検証が要るかーーそれを継続的に判断する仕組みがいる。

ソフトウェアの品質とは、書き上げた瞬間に決まるものではない。変更を重ねる過程で、安全性と意図した性能を保ち続けること、それ自体が品質なのである。

補足：もう一歩踏み込むなら

ソフトウェアシステムとソフトウェアアイテム：まずソフトウェアシステムにソフトウェア安全クラスを割り当てる。システムをソフトウェアアイテムに分解した場合、各アイテムは原則としてシステムのクラスを引き継ぐが、文書化された根拠があれば、一部のアイテムに異なるクラスを割り当てることができる。その場合、必要に応じて異なるクラスのアイテム間の分離をアーキテクチャ上確保し、検証する必要がある。

これにより、安全上の影響に応じた開発・検証活動を適用できる。外部のリスクコントロール手段：ハードウェアの安全機構、独立した監視機能、使用者による確認手順など、ソフトウェアシステムの外部にあるリスクコントロール手段を考慮して安全クラスを判定する。ただし、その手段の実装と有効性を適切に確認し、リスクマネジメントファイルで裏づける必要がある。

特に「使用者による確認手順」を採用する場合は、手順が存在するだけでは足りず、意図したリスク低減効果を合理的に説明できることが求められる。SOUP（Software of Unknown Provenance）：一般に入手可能で、医療機器への組込みを目的として開発されたものではないソフトウェア、または以前に開発されたものの、開発プロセスの十分な記録を利用できないソフトウェアアイテムを指す。OSSや市販ライブラリが該当することもあるが、OSSや市販品であることだけで自動的にSOUPになるわけではない。

適用される要求に従い、その用途、機能・性能、必要な動作環境、既知の不具合などを特定・評価し、関連するリスクを管理する必要がある。SBOMとの関係：SOUP管理で整備した構成情報は、脆弱性管理やSBOM作成の基礎にもなり得る。ただし、SOUPリストとSBOMは目的も対象範囲も同一ではなく、SBOMに関する要求はIEC 62304とは別のサイバーセキュリティ規制・規格も踏まえて確認する必要がある。

この分野の解説動画