株式会社イーコンプライアンス

【IEC-62304対応】

ソフトウェア開発規程・手順書ひな形

本邦において、医療機器プログラム（医療機器に搭載されるソフトウェアまたは単体プログラム）は、JIS T 2304（IEC 62304）「医療機器ソフトウェア ‐ ソフトウェアライフサイクルプロセス」に従って設計開発しなければなりません。
IEC 62304は「医療機器ソフトウェア」の開発と保守に関するプロセスを規定しています。
米国FDAにおいても、2008年7月にRecognized Consensus Standardと認定されています。

日本以外でも、欧州・北米・中国などにおいて、医療機器申請時にIEC 62304に基づくソフトウェア開発の証拠が必要です。
つまり、IEC 62304に従って「医療機器ソフトウェア」を開発しなければ、国内外においてソフトウェアを搭載した医療機器（単体プログラムを含む）を販売することができません。

しかしながら、 IEC 62304は非常に難解です。具体的に、どのような対応をとればよいのでしょうか。

一般にIEC 62304のようなプロセス規格は各社によってまちまちの解釈が行われ、手順書の 内容が大きく異なってしまいます。
・IEC 62304を読んでも、対応すべき内容や方法が分からない。
・IEC 62304を読んでも、どこまでやるべきなのかの範囲が分からない。
・IEC 62304の詳細の内容が、不明なまま文書構築を行っている。
などといった疑問点が多く寄せられます。

本「IEC 62304対応規程・手順書ひな形」を導入いただくことによってIEC 62304に準拠したQMSを効率的・効果的に作成することができます。

なお、単体プログラム（SaMD：Software as a Medical Device）の開発手順書はこちらをご参照ください。

ソフトウェア開発手順書から参照されている各文書（下位文書）のひな形の販売も行っております。詳細はこちら
また、イーコンプライアンスでは医療機器ソフトウェアQMS構築コンサルテーションを行っております。詳細はこちら

様式一覧
ご注文いただきますと、以下の様式を電子メールにて Wordファイル形式で納品いたします。
・ SW-QMS-A1 ソフトウェア開発規程
・ SW-QMS-B1 ソフトウェア開発手順書

ソフトウェア開発手順書から参照されている各文書（下位文書）のひな形の販売も行っております。詳細はこちら

目次

ソフトウェア開発規程

1.　目的
2.　適用範囲
3.　用語の定義
4.　ソフトウェア設計開発の原則
5.　一般
　5.1　品質システム
　5.2　リスクマネジメント
　5.3　ユーザビリティエンジニアリング
　5.4　ソフトウェア安全性クラス分類
　5.5　レガシーソフトウェア
　　　5.5.1　レガシーソフトウェアのリスクマネジメント活動
　　　5.5.2　ギャップ分析
　　　5.5.3　レガシーソフトウェアの使用の論拠
6.　ソフトウェア開発プロセス
　6.1　ソフトウェア開発計画
　　　6.1.1　ソフトウェア開発計画（クラスA、B、C）
　　　6.1.2　ソフトウェア開発計画の継続更新（クラスA、B、C）
　　　6.1.3　ソフトウェア開発計画におけるシステム設計及びシステム開発の引用
　　　6.1.4　ソフトウェア開発規格、方法及びツールの計画（クラスC）
　　　6.1.5　ソフトウェア結合及び結合試験計画（クラスB、C）
　　　6.1.6　ソフトウェア検証計画（クラスA、B、C）
　　　6.1.7　ソフトウェアリスクマネジメント計画（クラスA、B、C）
　　　6.1.8　文書化計画（クラスA、B、C）
　　　6.1.9　ソフトウェア構成管理計画（クラスA、B、C）
　　　6.1.10 管理が必要な支援アイテム（クラスB、C）
　　　6.1.11 検証前のソフトウェア構成アイテムのコントロール （クラスB、C）
　　　6.1.12 既知のソフトウェア欠陥の特定及び回避（クラスB、C）
　6.2　ソフトウェア要求事項分析
　　　6.2.1　システム要求事項からのソフトウェア要求事項の定義及び文書化 （クラスA、B、C）
　　　6.2.2　ソフトウェア要求事項の内容（クラスA、B、C）
　　　6.2.3　リスクコントロール手段のソフトウェア要求事項への包含 （クラスB、C）
　　　6.2.4　医療機器のリスク分析の再評価（クラスA、B、C）
　　　6.2.5　要求事項の更新（クラスA、B、C）
　　　6.2.6　ソフトウェア要求事項の検証（クラスA、B、C）
　6.3　ソフトウェアアーキテクチャの設計
　　　6.3.1　ソフトウェア要求事項のアーキテクチャへの変更（クラスB、C）
　　　6.3.2　ソフトウェアアイテムのインタフェース用アーキテクチャの開発 （クラスB、C）
　　　6.3.3　SOUPアイテムの機能及び性能要求事項の指定（クラスB、C）
　　　6.3.4　SOUPアイテムが要求するシステムハードウェア及びシステム ソフトウェアの指定（クラスB、C）
　　　6.3.5　リスクコントロールに必要な分離の特定（クラスC）
　　　6.3.6　ソフトウェアアーキテクチャの検証（クラスB、C）
　6.4　ソフトウェア詳細設計
　　　6.4.1　ソフトウェアのソフトウェアユニットへの分解（クラスB、C）
　　　6.4.2　ソフトウェアユニットごとの詳細設計の開発（クラスC）
　　　6.4.3　インタフェース用詳細設計の開発（クラスC）
　　　6.4.4　詳細設計の検証（クラスC）
　6.5　ソフトウェアユニットの実装
　　　6.5.1　各ソフトウェアユニットの実装（クラスA、B、C）
　　　6.5.2　ソフトウェアユニット検証プロセスの確立（クラスB、C）
　　　6.5.3　ソフトウェアユニットの合否判定基準（クラスB、C）
　　　6.5.4　追加のソフトウェアユニット合否判定基準（クラスC）
　　　6.5.5　ソフトウェアユニットの検証（クラスB、C）
　6.6　ソフトウェア結合及び結合試験
　　　6.6.1　ソフトウェアユニットの結合（クラスB、C）
　　　6.6.2　ソフトウェア結合の検証（クラスB、C）
　　　6.6.3　ソフトウェア結合試験（クラスB、C）
　　　6.6.4　ソフトウェア結合試験の内容（クラスB、C）
　　　6.6.5　ソフトウェア結合試験手順の評価（クラスB、C）
　　　6.6.6　回帰テストの実施（クラスB、C）
　　　6.6.7　結合試験記録の内容（クラスB、C）
　　　6.6.8　ソフトウェア問題解決プロセスの使用（クラスB、C）
　6.7　ソフトウェアシステム試験
　　　6.7.1　ソフトウェア要求事項についての試験の確立（クラスA、B、C）
　　　6.7.2　ソフトウェア問題解決プロセスの使用（クラスA、B、C）
　　　6.7.3　変更後の再試験（クラスA、B、C）
　　　6.7.4　ソフトウェアシステム試験の評価（クラスA、B、C）
　　　6.7.5　ソフトウェアシステム試験記録の内容（クラスA、B、C）
　6.8　システムレベルで使用するためのソフトウェアリリース
　　　6.8.1　ソフトウェア検証の完了確認（クラスA、B、C）
　　　6.8.2　既知の残留異常の文書化（クラスA、B、C）
　　　6.8.3　既知の残留異常の評価（クラスB、C）
　　　6.8.4　リリースするバージョンの文書化（クラスA、B、C）
　　　6.8.5　リリースするソフトウェアの作成方法の文書化（クラスB、C）
　　　6.8.6　アクティビティ及びタスクの完了確認（クラスB、C）
　　　6.8.7　ソフトウェアのアーカイブ（クラスA、B、C）
　　　6.8.8　ソフトウェアリリースの信頼性の確保（クラスA、B、C）
7.　ソフトウェア保守プロセス
　7.1　ソフトウェア保守計画の確立（クラスA、B、C）
　7.2　問題及び修正の分析
　　　7.2.1　フィードバックの文書化及び評価
　　　7.2.2　ソフトウェア問題解決プロセスの使用（クラスA、B、C）
　　　7.2.3　変更要求の分析（クラスA、B、C）
　　　7.2.4　変更要求の承認（クラスA、B、C）
　　　7.2.5　ユーザ及び規制当局への通知（クラスA、B、C）
　7.3　修正の実装
　　　7.3.1　確立したプロセスを使用した修正の実装（クラスA、B、C）
　　　7.3.2　修正ソフトウェアシステムの再リリース（クラスA、B、C）
8.　ソフトウェアリスクマネジメントプロセス
　8.1　危険状態を引き起こすソフトウェアの分析
　　　8.1.1　危険状態の一因となるソフトウェアアイテムの特定 （クラスB、C）
　　　8.1.2　危険状態の一因となるソフトウェアアイテムの潜在的原因 （クラスB、C）
　　　8.1.3　公開されたSOUP異常リストの評価（クラスB、C）
　　　8.1.4　潜在的原因の文書化（クラスB、C）
　8.2　リスクコントロール手段
　　　8.2.1　リスクコントロール手段の選択（クラスB、C）
　　　8.2.2　ソフトウェアに実装するリスクコントロール手段（クラスB、C）
　8.3　リスクコントロール手段の検証
　　　8.3.1　リスクコントロール手段の実施の検証（クラスB、C）
　　　8.3.2　トレーサビリティの文書化
　8.4　ソフトウェア変更のリスクマネジメント
　　　8.4.1　医療機器ソフトウェアの安全性に関わる変更の分析 （クラスA、B、C）
　　　8.4.2　ソフトウェア変更が既存のリスクコントロール手段に与える 影響の分析（クラスB、C）
　　　8.4.3　分析に基づくリスクマネジメントアクティビティの実行 （クラスB、C）
9.　ソフトウェア構成管理プロセス
　9.1　構成識別
　　　9.1.1　構成アイテム識別手段の確立（クラスA、B、C）
　　　9.1.2　SOUPの特定（クラスA、B、C）
　　　9.1.3　システム構成文書の特定（クラスA、B、C）
　9.2　変更管理
　　　9.2.1　変更要求の承認（クラスA、B、C）
　　　9.2.2　変更の実装（クラスA、B、C）
　　　9.2.3　変更の検証（クラスA、B、C）
　　　9.2.4　変更のトレーサビリティを実現する手段の提示 （クラスA、B、C）
　9.3　構成状態の記録（クラスA、B、C）
10. ソフトウェア問題解決プロセス
　10.1 問題報告の作成（クラスA、B、C）
　10.2 問題の調査（クラスA、B、C）　
　10.3 関係者への周知（クラスA、B、C）
　10.4 変更管理プロセスの使用（クラスA、B、C）
　10.5 記録の保持（クラスA、B、C）
　10.6 問題の傾向分析
　10.7 ソフトウェア問題解決の検証（クラスA、B、C）
　10.8 試験文書の内容（クラスA、B、C）
11.　引用規格
12.　参考
13.　付則

---

ソフトウェア開発手順書

1. 目的
2. 適用範囲
3. 用語の定義
4. 役割と責任
5. 設計開発ステージとソフトウェア開発プロセスの対応
6. 成果物
7. ソフトウェア開発プロセス
　7.1 システム要求仕様書・システムアーキテクチャ設計書の作成（クラスA、B、C）
　　　7.1.1 プロセスのインプットおよびアウトプット
　　　7.1.2 システム要求仕様書・システムアーキテクチャ設計書、製品開発計画書の作成
　7.2 ソフトウェア開発計画
　　　7.2.1 プロセスのインプットおよびアウトプット
　　　7.2.2 ソフトウェア開発計画書の作成
　　　7.2.3 ソフトウェア検証計画書の作成
　　　7.2.4 リスクマネジメント計画書の作成
　　　7.2.5 ソフトウェア文書管理計画書の作成
　　　7.2.6 ソフトウェア構成管理計画書の作成
　　　7.2.7 ソフトウェア結合および結合試験計画書（クラスB、C）
　7.3 ソフトウェア要求分析
　　　7.3.1 プロセスのインプットおよびアウトプット
　　　7.3.2 システム要求事項の具体化、リスク分析、ユーザビリティエンジニアリング評価の実施
　　　7.3.3 ソフトウェア要求仕様書（SRS）執筆準備
　　　7.3.4 ソフトウェア要求分析シート
　　　7.3.5 ソフトウェア要求仕様書（SRS）の作成
　　　7.3.6 ソフトウェア開発計画書の更新
　　　7.3.7 ソフトウェアリスク分析の再評価
　　　7.3.8 ソフトウェア要求分析フェーズチェックリスト
　　　7.3.9 要求事項の更新
　　　7.3.10 ソフトウェア要求事項の検証
　7.4 ソフトウェアアーキテクチャ設計
　　　7.4.1 プロセスのインプットおよびアウトプット
　　　7.4.2 ソフトウェアアーキテクチャ設計書の作成（クラスB、C）
　　　7.4.3 ソフトウェアアーキテクチャの検証（クラスB、C）
　7.5 ソフトウェア詳細設計（クラスB、C）
　　　7.5.1 プロセスのインプットおよびアウトプット
　　　7.5.2 ソフトウェア詳細設計書
　　　7.5.3 詳細設計の検証（クラスC）
　7.6 ソフトウェアユニットの実装
　　　7.6.1 プロセスのインプットおよびアウトプット
　　　7.6.2 ソフトウェアユニットの実装
　7.7 ソフトウェアユニットテスト（クラスB、C）
　　　7.7.1 プロセスのインプットおよびアウトプット
　　　7.7.2 ソフトウェアユニットテスト仕様書
　　　7.7.3 ソフトウェアユニットテスト記録
　　　7.7.4 ソフトウェアユニットテスト報告書
　7.8 ソフトウェア結合および結合試験（クラスB、C）
　　　7.8.1 プロセスのインプットおよびアウトプット
　　　7.8.2 ソフトウェアユニットの結合（クラスB、C）
　　　7.8.3 ソフトウェア結合試験計画書（クラスB、C）
　　　7.8.4 ソフトウェア結合試験仕様書（クラスB、C）
　　　7.8.5 ソフトウェア結合試験スクリプト（クラスB、C）
　　　7.8.6 ソフトウェア結合試験の実施及び記録（クラスB、C）
　　　7.8.7 回帰テスト（クラスB、C）
　　　7.8.8 ソフトウェア結合試験報告書（クラスB、C）
　7.9 ソフトウェアシステム試験
　　　7.9.1 プロセスのインプットおよびアウトプット
　　　7.9.2 ソフトウェアシステム試験計画書
　　　7.9.3 ソフトウェアシステム試験仕様書
　　　7.9.4 ソフトウェアシステム試験スクリプト
　　　7.9.5 ソフトウェアシステム試験記録
　　　7.9.6 変更後の再試験
　　　7.9.7 ソフトウェアシステム試験報告書
　7.10 トレーサビリティ管理
　　　7.10.1 トレーサビリティマトリックスの記入要領
　　　7.10.2 トレーサビリティマトリックスの作成及び更新
　7.11 リリース
　　　7.11.1 プロセスのインプットおよびアウトプット
　　　7.11.2 ソフトウェア検証の完了確認
　　　7.11.3 既知の残留異常の文書化
　　　7.11.4 既知の残留異常の評価（クラスB、C）
　　　7.11.5 リリースするバージョンの文書化
　　　7.11.6 リリースするソフトウェアの作成方法の文書化
　　　7.11.7 ソフトウェアプロジェクト終結報告書
　　　7.11.8 ソフトウェアプロジェクト終結チェックリスト（クラスB、C）
　　　7.11.9 ソフトウェアリリースの信頼性の確保
　　　7.11.10 ソフトウェアリリースノート
　　　7.11.11 ソフトウェアのアーカイブ
8. ソフトウェア問題管理
　8.1 プロセスの開始基準、インプット、終了基準およびアウトプット
　8.2 手順
　　　8.2.1 計画
　　　8.2.2 実行
　　　8.2.3 問題の傾向分析
　　　8.2.4 ソフトウェア問題解決の検証
9. ソフトウェア変更管理
　9.1 プロセスの開始基準、インプット、終了基準およびアウトプット
　9.2 手順
　　　9.2.1 計画
　　　9.2.2 実行
10. ソフトウェア保守計画
　10.1 プロセスのインプットおよびアウトプット
　10.2 ソフトウェア保守計画書
11. 参考
12. 付則

入金確認後（クレジットカードの場合は決済完了後）に、電子メールにてWordファイル形式で納品いたします。

ご送付後の返品はできません。
内容に関するご質問等は受け付けます。

銀行振り込みを選択された場合は、ご請求書を（.pdf）にて別途送付しますので、貴社お支払い規定（例：翌月末までにお振込み）に従い、お振込みをお願いいたします。
恐れ入りますが、振り込み手数料はご負担くださいますようお願いいたします。
また、事前に会員登録をしていただきますと、ポイントを蓄積していただくことができ、貯まったポイントをセミナーや書籍のご購入にご使用いただけます。
会員でない方はこちらから会員登録を行ってください。

本ご注文に関しては、株式会社イーコンプレスが担当させていただきます。
個人情報等に関しましては、手順書ご購入目的に限り、当社から株式会社イーコンプレスへ転送させていただきます。

お見積書や領収書が必要な場合もお申し付けください。
複数文書を一括してご購入される場合は、合計金額に応じて割引をさせて頂きます。
詳しくはお問合せ下さい。

当社コンサルテーションや商品へのご要望・ご質問・お問合せはこちら