▼▼▼▼▼▼▼▼
チャンネル登録はこちら

システム開発の技法

実際にシステム開発を行う場合には下に示した技法のほかにも, いくつもの技法があり、どれを使わなけれならないということはありません。

担当者が状況に応じて適切と思われる技法を使用することで差し支えありまん。

�@ウォーターフォールモデル
最も基本的なシステム開発技法です。ウォーターフォールとは滝の意味で、 滝が上流から下流へ決して逆流することなく流れるように 「外部設計」、 「内部設計」、 「プログラム設計」 といった全てのステップを順番に、 そのステップを完全に終了させてから次のステップへと移行していく技法です。 適切な管理が行われれば非常に有効な技法です しかし, ユーザーの要求事項の理解に誤りがあった場合や要求の変化に柔軟に対応することは困難です。

�Aプロトタイプモデル
ウォーターフォールモデルの欠点である利用者の要求事項の誤解や変化に対応するために考えられたシステム開発技法です。.当初から完全なシステムを作成するのではなく、プロトタイプと呼ばれる簡単な見本を作成しユーザーを交えて要求仕様を確認しながら、システム開発を進めていく技法です。これにより, ユーザー要求とのギャップを適切に埋めることができます。しかしながら, ユーザーによっては次から次へと要求が変化したり , 追加されたりするため, いつになってもシステムが完成しなくなる危険性があります。また, システム全体としての統一性が損なわれる可能性があることにも注意する必要があります。

�Bスパイラルモデル
ウォーターフォールモデルとプロトタイプモデルの両方を取り入れた技法です。システム全体をいくつかの部分に分割し、 必要に応じてプロトタイプを作成しながらその部分を完成させては、 次の部分に移行するという技法です。最初に全体の核となる部分を作成するという意味で, ウォーターフォールモデルの発展系であり、次第にシステム規模が大きくなっていきます。

また, プログラム開発を行っていく段階でのプログラムテストの技法としては次のようなものが知られています。

�@トップダウンテスト
上位モジュールから下位モジュールへ順次にテストを行うもので、 下位モジュールはスタブと呼ばれる未完成部分をシミュレートする仮モジュールにより代替されます。

�Aボトムアップテスト
下位モジュールから上位モジュールへ順次にテストを行うもので、 上位モジュールはドライバと呼ばれる未完成部分をシミュレートする仮モジュールにより代替されます。

�B一斉テスト
一挙に最終プログラムをテストするもので, 誤り 個所の発見が難しいことがしばしばあります。

システムバリデーション

答申 GCP ではシステムに関してのバリデーションが求められています。

しかしながら, 答申GCP だけではなく関連がありそうな資料を探索しても、 具体的にパリデーションとしては何をしなければならないのかを記載してある資料というものは少ないです。

日本では, 厚生労働省により 1992 年2月21 日に策定されたGMP (Good Manufacturing Practice) 関連の 「コンピュータ使用医薬品等製造所適正管理ガイドライン」, および1993 年1月11日に策定された 「コンピュータ使用医薬品等製造所査察マニュアル」 が参考にされることが多いです。

そして, 1993 年に厚生省薬務局監視指導課の監修で「コンピュータ適正管理マニュアル] が発行されています。

このガイドラインの対象としては医薬品 GMP と原薬 GMP の適用される製造所または作業所などがありますが, この中で, ガイドラインに基づく査察の個別事項として次のような項目が挙げられており, 臨床試験データを取り扱うシステムでも充分に参考とすることができると思われます。

�@開発検討段階
�Aシステム検討段階
�Bプログラム設計段階
�Cシステムテスト段階
�D設置・運用テスト段階
�Eその他

運用管理総則としては、

�@ハードウェアの操作
�A保守点検管理の実施
�B事故発生時の対応
�Cセキュリティ管理の実施
�D自己点検の実施
�E文書および記録の保存管理

一方, FDA から 1999 年4月に公開された Guidance for Industry Computerized Systems Used in Clinical Trials」を参考にすることもできます。

さらに2002 年 1月 11 日には General Principles of Software Validation; Final Guidance Industry and FDA Staff (産業界と FDA職員のためのソフトウェアバリデーションに関する一般原則) も公開されています。

このガイドラインではその対象について、医療機器の部品の一部、あるいは付属品として用いられるソフトウェアそれ自体が医療機器であるソフトウェア、医療機器の製造に用いられるソフトウェア、医療機器の製造での品質システムに実装されているソフトウェア、と規定しており 医療機器に関するソフトウェアだけが対象となっていると思われがちです。

しかし、この記載の直後に 「一般的なソフトウェアバリデーションに関する原則と考えられるものに基づいたものであり、 このためいかなるソフトウェアにも適用することができる」と記載されているため, 臨床試験データ管理システムにも充分に適用することができるものと思われます。

この書類の中で, FDA はソフトウェアバリデーションを 「ソフトウェア仕様がユーザー要求と意図する用途に従っていること、 およびソフトウェアにより実施される特別の要求が一貫して実現されていることを, 検査と客観的な証拠の提供により確認すること」であるとしています。

そして, システム設計が重要なソフトウェア開発の一部であること、 ソフトウェアはハードウェアとは異なりハードウェアよりも高度に精密な検査と管理が必要であること,包括的なソフトウェアバリデーションプロセスの確立は以降のリリースでの確認コスト減少により長期的なコストの削減に役立つこと, 複数の設計確認を行うことが重要なことを説明しています。

さらに, ソフトウェアバリデーションの原則として次のような事項を挙げています。

�@ソフトウェアの要求仕様が文書化されていること
�Aソフトウェアテストは必要な活動ではあるが, ほとんどの場合単体でのソフトウェアテストではソフトウェアが意図した用途に適しているということを確認するには不十分であること
�Bソフトウェアバリデーションの準備は非常に初期に始めるべきであり、 バリデーションされていたという最終的な結論はライフサイクルを通じて計画した成果が得られたという証拠に基づくこと
�Cソフトウェアバリテーションはソフトウェアライフサイクルを通じて実施されるものであること
�Dソフトウェアバリデーションプロセスは定義され、 計画に基づいて管理されること
�Eソフトウェアバリテーションプロセスは手順に則って実施されること
�Fソフトウェアが変更された時はいつでも, 単独の変更に対することだけではなくソフトウェアシステム全体に対する範囲と影響を確認できるようにバリデーションが実施されるべきこと
�Gバリデーションは組1織の大きさやリソースによるのではなく、 ソフトウェアの複雑性と安全性のリスクに基づくものであるべきこと
�Hバリデーション活動は"独立した確認"という基本的な品質保証の精神に基づくものであること
�Iソフトウェアバリデーションに関する原則の導入は実際のアプリケーションごとに異なること

その上で、 ソフトウェアのライフサイクルの例として次のようなステップが示されています。

�@品質設計
�Aシステム要求定義
�B詳細ソフトウェア要求仕様作成
�Cソフトウェア設計仕様
�D組み立てあるいはコーディング
�Eテスト
�F導入
�Gオペレーションとサポート
�H保守
�I廃棄

そして, ベリフィケーション, テスト, そのほかの活動はこれらの各ステップにおいてソフトウェアバリデーションを補佐するものであるとされています。

つまり、 システムバリデーションは単に仕様を定めて機能テストを行うだけではなく, 実際の運用やユーザー教育なども含めて考えられるべきものであり, 持続的にシステムが正しく機能することを保証できるようになっていなけばならないと考えるべきだということです。

なお, 市販されているソフトウェアを使用する場合でも, ベンダーが保持している開発とバリデーション文書に対する監査などを検討する必要があります。

ただし, Windows のような極めて広く流通しているソフトウェアについては, この監査の対象外として構いませんが、バグ情報などを適宜, 確認して運用・管理を行わなければなりません。

システム開発には状況に応じた適切な技法の選択が重要であり、代表的な技法としてウォーターフォールモデル、プロトタイプモデル、スパイラルモデルが挙げられます。ウォーターフォールモデルは外部設計、内部設計、プログラム設計といった各ステップを順次完了させて進める基本的な技法であり、適切に管理されれば非常に有効です。しかし、ユーザーの要求事項に誤解がある場合や要求の変更に柔軟に対応することが難しいという欠点があります。一方、プロトタイプモデルはウォーターフォールモデルの欠点を補うために考案された技法で、初めから完全なシステムを作成するのではなく、簡易的な見本となるプロトタイプを作成し、ユーザーと連携しながら要求仕様を確認しつつ進めることが特徴です。この手法によりユーザーの要求とシステムの仕様とのギャップを埋めることが可能ですが、ユーザーが頻繁に要求を変更したり追加したりすることでシステムがなかなか完成しないリスクや、システム全体の統一性が損なわれる可能性もあります。スパイラルモデルはウォーターフォールモデルとプロトタイプモデルを組み合わせた技法で、システム全体をいくつかの部分に分割し、それぞれの部分をプロトタイプを活用して開発しながら完成させるという手法です。このモデルでは、最初にシステムの核となる部分を作成し、それを基に次第に規模を拡大していくため、全体としての完成度を高めながら進められます。さらに、プログラム開発におけるテスト技法としてはトップダウンテスト、ボトムアップテスト、一斉テストがあり、それぞれに特徴があります。トップダウンテストは上位モジュールから下位モジュールへ順次テストを行い、未完成の下位モジュールはスタブと呼ばれる仮モジュールで代替します。一方、ボトムアップテストは下位モジュールから上位モジュールへ順次テストを行い、未完成の上位モジュールはドライバと呼ばれる仮モジュールで代替します。一斉テストはシステム全体を一括してテストする方法で、効率的ですがエラー箇所の特定が難しい場合があります。次に、システム開発においてバリデーションも非常に重要なプロセスです。バリデーションとはシステムやソフトウェアがユーザーの要求仕様や意図した用途に適合していることを確認する活動であり、特に臨床試験データを取り扱うシステムにおいては厳密な検証が求められます。日本においては厚生労働省が策定したガイドラインや査察マニュアルが参考とされており、医薬品製造所の適正管理に基づいた査察項目が挙げられています。これには開発検討段階、システム検討段階、プログラム設計段階、システムテスト段階、設置・運用テスト段階などが含まれ、さらにハードウェア操作、保守点検、事故対応、セキュリティ管理、文書管理などが運用管理総則として求められます。海外ではFDAが公開した「Guidance for Industry Computerized Systems Used in Clinical Trials」や「General Principles of Software Validation」が参考となり、これらのガイドラインではソフトウェア仕様がユーザー要求に適合していることや、包括的なバリデーションプロセスの確立が強調されています。具体的には、ソフトウェア要求仕様の文書化、単体テストの限界の認識、ライフサイクル全体でのバリデーション実施、プロセスの定義と管理、変更時の影響範囲確認、リスクに基づくバリデーション計画の実施、独立した確認の必要性などが挙げられています。さらに、ソフトウェアのライフサイクル例として品質設計、システム要求定義、詳細仕様作成、設計仕様作成、コーディング、テスト、導入、運用、保守、廃棄までのプロセスが示され、それぞれの段階でバリデーションが補完的な役割を果たします。これらのガイドラインに基づくソフトウェアバリデーションは、システムの運用やユーザー教育も含めて考慮する必要があり、継続的にシステムが正しく機能することを保証するものでなければなりません。市販ソフトウェアを使用する場合でも、ベンダーのバリデーション文書やバグ情報を適切に確認し、運用管理を行うことが求められます。このように、システム開発には技法選択から運用管理まで、多岐にわたる検討事項と実践が必要であり、それらを適切に統合することで初めて信頼性の高いシステムが実現されます。