こんにちは、イーソル エンジニアリング本部 Medical課のY.Sです。
イーソルは医療機器や顕微鏡・研究向け製品をはじめとした医療・科学分野のエンジニアリングサービスを提供しており、Medical課は医療系のソフトウェア開発に携わっています。
このブログシリーズでは、イーソルで定期的に開催しているIEC 62304理解のための社内勉強会で得た見識について紹介しています。
前回までは、以下の内容を紹介しました。
- 第1回：IEC 62304とは何か、また規格についての基本的な知識や読み方について
- 第2回：IEC 62304で定義されているソフトウェア安全クラス分類、また医療機器ソフトウェア開発のリスクマネジメントプロセスについて
- 第3回：医療機器ソフトウェア開発のV字モデル
シリーズ最終回となる第4回目では、医療機器ソフトウェア開発の管理プロセス及び開発支援ツールについて取り上げます。
|
目次 |
1. 品質マネジメントシステム
医療機器ソフトウェアの開発を行う上では、ISO 13485（対応するJIS規格：JIS Q13485）で定義されている品質マネジメントシステムに準拠する必要があります。
IEC 62304の範囲から超えてしまうためこのブログでは詳しい言及は避けますが、汎用的な品質マネジメントシステムを定義するISO 9001（対応するJIS規格：JIS Q9001）規格と近い要求事項が定められている個所もあれば、医療機器独自の要求事項が定義されている個所もあります。そのため、ISO 9001に準拠した開発を行っている製造業者であっても注意が必要です。
2. ソフトウェア構成管理プロセス
IEC 62304ではソフトウェア構成管理プロセスが定義されており、クラスA,B,Cどのクラスにおいてもこのプロセスの整備が必要です。
図 1 ソフトウェア構成管理プロセス
事前にソフトウェア構成管理計画を作成する必要があり、計画の中で管理対象のアイテムを明確化し、構成管理のためのアクティビティを定義します。管理対象のアイテムにはソフトウェア開発に使用するツールを含めます。
また、構成管理プロセスを実行する中では、ソフトウェア構成管理アイテムおよびそのバージョンを識別することが求められます。
使用しているSOUP（Software of Unknown Provenance：由来のわからないソフトウェア）についても識別、特定が必要です。
・変更管理
医療機器ソフトウェアのライフサイクルの中で、ソフトウェアの変更が発生することがあります。その中でもソフトウェアの仕様変更、ソフトウェア結合試験及びソフトウェアシステム試験を実施する中での不具合の発見、リリース後の顧客の中での不具合の発見などによる変更では、自由に変更してよいわけではありません。
変更内容を変更要求として文書化し、承認し、それに応じる場合にのみ構成アイテムを変更しなければなりません。
変更を実装する場合、やり直しが必要と判断した全てのアクティビティを実施し、検証します。
ソフトウェアの問題が発生した場合、IEC 62304で定義されているソフトウェア問題解決プロセスに従って運用する必要があります。
3. ソフトウェアのトレーサビリティ
ソフトウェア開発において、プロセスの成果物同士の紐づけをトレーサビリティと言います。トレーサビリティはIEC 62304で適宜必要とされます。
・ソフトウェアリスクマネジメントプロセスでのトレーサビリティ
ソフトウェアリスクマネジメントプロセスで求められる成果物間のトレーサビリティを、以下の図の①～④に示します。
図2 リスクマネジメントプロセスでのトレーサビリティ
JIS T2304:2017「7.3.3 トレーサビリティの文書化」をもとに作成
これらのトレーサビリティは、クラスB、Cのソフトウェアリスクマネジメントプロセスの中で適宜必要とされます。
これらのトレーサビリティにより、全てのリスクに対してリスクコントロール手段が漏れなく計画されているか把握することができます。
ソフトウェアリスクマネジメントプロセス及びその成果物の詳細については、このブログのシリーズの第2回を参照してください。
・ソフトウェア開発プロセスでのトレーサビリティ
ソフトウェア開発プロセスで求められる成果物間のトレーサビリティを、以下の図の①～⑧に示します。
図 3 ソフトウェア開発プロセスでのトレーサビリティ
①～⑥：JIS T2304:2017「5.1.1 ソフトウェア開発計画」をもとに作成
⑦：JIS T2304:2017「5.3.6 ソフトウェアアーキテクチャの検証」をもとに作成
⑧：JIS T2304:2017「5.4.4 詳細設計の検証」をもとに作成
①～⑥のトレーサビリティはクラスA、B、Cのソフトウェア開発計画時に必要となります。（※見やすくするため一部を破線で示していますが違いはありません）
⑦のトレーサビリティはクラスB、Cのソフトウェアアーキテクチャの検証時に必要となります。
⑧のトレーサビリティはクラスCのソフトウェア詳細設計の検証時に必要となります。
これらのトレーサビリティにより、ソフトウェアの要求事項が漏れなく実装されているか把握することができます。
ソフトウェア開発プロセス及びその成果物の詳細については、このブログのシリーズの第3回を参照してください。
・ソフトウェア問題解決プロセスでのトレーサビリティ
このブログではソフトウェア問題解決プロセスの詳細についての言及は割愛しますが、トレーサビリティとして変更要求、問題報告、変更要求の承認、構成状態の記録を紐づける必要があります。
4. ソフトウェア開発支援ツール
医療機器ソフトウェア開発では、定義されたプロセスに則った開発が求められます。
ヒューマンエラーを防ぎ厳密にプロセスを運用できるように、各種支援ツールを使用することが一般的です。
以下より、医療機器ソフトウェア開発で使用されるツールと、その例をご紹介します。
| 分類 | ツール種類 | ツール例 | |
| 管理 | チケット管理ツール | Redmine, Jira | |
| 障害管理ツール | BugZilla, Mantis Bug Tracker, (Redmine, Jira) | ||
| トレーサビリティツール | microTRACER, Contrack | ||
| 開発 | 構成管理 | バージョン管理システム | Git, Subversion |
| Gitホスティングサービス | GitHub, Bitbucket | ||
| クライアントツール | TortoiseSVN, TortoiseGit, SourceTree | ||
| 統合開発環境 | Visual Studio, Eclipse | ||
| UMLツール | Enterprise Architect, astah, PlantUML | ||
| CI/CDツール | Jenkins, Bitbucket pipeline | ||
| 静的解析ツール | Klocwork, Coverity, PGRelief | ||
| テスト | 単体テストツール | C++Test, GoogleTest | |
| テスト管理ツール | TestLink | ||
- チケット管理ツール
チケット駆動開発において使用される進捗管理ツールです。
かんばんでチケットを管理するため、直感的に進捗が把握しやすい特徴があります。 - 障害管理ツール
障害の修正状況をトラッキングすることができます。チケット管理ツールの一部は障害管理ツールとしても使用することが可能です。 - トレーサビリティツール
トレーサビリティは成果物間の紐づけがなされればよいため、汎用的なツールで言えばExcelの表を用いる事も可能ですが、規模の大きなソフトウェアではトレース対象の量が多く、変更時の管理などが煩雑になりがちです。
その場合、トレーサビリティを取るためのツールを使用することを推奨します。使用しているチケット管理ツールや構成管理ツールとの相性もあるため、各社のツールの特徴を比較したうえでトレーサビリティツールを決定します。 - 構成管理
Gitを使用する場合、自力でサーバを立てるよりもホスティングサービスを利用することが一般的です。また、CUIだけでなくGUI上で操作したい場合はクライアントツールの導入も検討します。 - 統合開発環境
ソフトウェア実装時に使用します。ビルド、デバッグのために必要不可欠なツールで、開発対象のOSによって決定されます。 - UMLツール
アーキテクチャ設計時や詳細設計時にUML図を作成したい場合に使用します。 - CI/CDツール
CI/CDとは継続的インテグレーション/継続的デリバリーの略です。ソースコードが更新される毎にビルド、自動テストを行ったり、本番環境相当のパッケージを作成したりして、新しい変更によりソフトウェアのデグレーションが発生していないかチェックすることができます。 - 静的解析ツール
ソフトウェアの合否判定基準は一般に様々なものがあり、そのうち変数初期化の有無などの標準的なものについては、静的解析ツールを使用することによって自動判定を行うことができます。必須ではありませんが、ヒューマンエラーを減らすのに有効です。 - 単体テストツール
CI/CDツールと組み合わせて使用する事が効果的です。 - テスト管理ツール
システム試験で必要です。試験で失敗した場合、問題解決プロセスにより管理したり、その影響範囲を分析したりする必要があるため、どのテストケースが失敗したのかを管理する必要があります。
・開発支援ツールのバリデーション
医療機器ソフトウェア開発では、前述したような各種支援ツールを使用することが一般的ですが、無条件でツールを使用して良いわけではなく、使用する場合はソフトウェアのバリデーションという作業が必要とISO13485で定義されています。
バリデーション（Validation）とは、成果物が仕様通りに作られていることを確認することで、「妥当性確認」と訳されます。
医療機器ソフトウェア開発のみならず、医療機器開発に使用するツールはバリデーションをとる必要があります。
5. 最後に
いかがでしたでしょうか。
このブログのシリーズでは、医療機器ソフトウェアライフサイクルプロセス規格IEC 62304の要点を絞ってご紹介いたしました。
実際に医療機器ソフトウェアの開発を行う上では、ブログにて言及していない、品質マネジメントシステム、ソフトウェア開発計画、ソフトウェア保守プロセス、ソフトウェア問題解決プロセスなどにも則って開発する必要がありますので、IEC 62304及び関連する医療機器リスクマネジメント規格ISO 14971、医療機器品質マネジメントシステム規格ISO 13485などの規格に目を通すことが不可欠です。
このブログはその導入として役立てていただけたら幸いです。
また冒頭でご紹介した通り、イーソルは医療分野のエンジニアリングサービスを提供しており、豊富な実績があります。医療分野のみならず、車載・産業などの幅広い領域における開発実績で身に着けた安全性の高い開発プロセスなどの知見や技術力は、お客様の求めるお客様が目指す高性能で高品質な開発を強力に支援します。
医療分野の製品開発で課題がある、IEC 62304をはじめとした規格に準拠した開発を実施したい、エンジニアリングサービスについて詳しく知りたい、という方はぜひお気軽にイーソルにご相談ください。
Medical課 Y.S
参考：
・JIS T2304 / 医療機器ソフトウェア－ソフトウェアライフサイクルプロセス・JIS Q13485 / 医療機器－品質マネジメントシステム－規制目的のための要求事項
・JIS Q9001 / 品質マネジメントシステム－要求事項
