コラム：アジャイル開発のアプローチによる臨床試験（特に治験）における課題解決の可能性を考える①
医薬品の有効性を評価するうえで、実際の人に投与して有効性・安全性を評価するプロセスは欠かせない。未承認・適応外の医薬品(医療機器も含む)の製造販売に関して、薬機法上の「承認を得る」ために行われる試験、特にヒトに対して行われる試験を総称して「治験」という。
当然ながら、治験には多くの規制が存在する。その複雑さに起因してか、日本で実施されている大半の試験はスケジュール通りに進まない。「治験」プロジェクトの遅延はそのまま製薬会社のコストとなってのしかかり、ひいては薬価という形で消費者に反映される。
「治験」プロジェクトをスケジュール通りに完遂することは、製薬業界における喫緊の大きな課題である。
治験のプロセスは大体こんな感じである↓。
① 治験実施計画書の作成
・治験の目的、デザイン、適格基準、治療法と用量、治験期間、データ収集方法、安全性と有効性の評価基準なんかを規定する。
② 治験開始届の提出
・作成したプロトコルを規制当局(日本だと、PMDA)に提出し、「治験を実施するための」承認を得る。
③ IRBへの申請と承認
・医療機関の倫理委員会（IRB）に治験実施計画書を提出し、倫理的な評価と承認を受ける。
④ 治験の準備
・治験薬の供給、諸々の準備、チームのトレーニング等を行う。
⑤ 参加者の組み入れ
・適格基準に合致する参加者を治験に組み入れる。
⑥ データ収集
・治験実施計画に従って、参加者からデータを収集する。参加者の安全性も継続的にモニタリングする。
⑦ データ分析:
・治験終了後、収集されたデータを分析して治験薬の有効性や安全性を評価する。
⑧ 総括報告書の作成
・データ分析結果をもとに、治験の総括報告書を作成し、PMDAへ報告書を提出する。
PMDAが有効性を認めたら、晴れて医薬品として承認されることになる。本当はもっと複雑で一部不正確なんだけど、大体こんな感じである。
段階ごとにプロセスを追っていくというのは、ウォーターフォール型のシステム開発モデルに似ている。ウォーターフォール型は常にアジャイル型と比較される、よく言えば伝統的な開発手法にあり、悪く言えば非効率なレガシーでもある。
ウォーターフォール型開発モデルは、ソフトウェア開発における古典的なアプローチの一つである。このモデルは、開発プロセスを一連の直線的で段階的なステップに分けることが特徴である。各ステップは前のステップが完了するまで開始されない。
ウォーターフォールモデルの主な流れはこんな感じ↓。
① 要件定義
・プロジェクトの初期段階で、要件が詳細に文書化され、顧客やステークホルダーと合意される。この段階での決定が後のすべての工程に影響を与える。
② 設計と実装
要件定義が完了すると、システムの設計が行われる。設計では、ソフトウェアのアーキテクチャやコンポーネントが決定される。
その後、実際の開発が行われる。
③ 検証とテスト
開発されたソフトウェアは、要件が満たされているかを確認するためにテストの段階をふむ。この段階で問題が見つかると、前段階に手戻りを行う必要がある。
④ 保守
ソフトウェアがリリースされた後、継続的な保守が行われる。これにはバグの修正や機能の更新が含まれる。
ウォーターフォールモデルの主な利点は、その単純さと明確な構造にある。プロジェクトの進行状況が容易に理解でき(著者注：諸説あり)、文書化が容易である(著者注：本当か？)。しかし、変更に対する柔軟性が低く、新しい要件や変更が発生した場合に対応するのが難しいという欠点もある。
そのため、要件が明確で変更の少ないプロジェクトに適しているが、要件が流動的な場合や迅速な市場対応が求められる場合には適していないとされている。現代のソフトウェア開発では、より柔軟で迅速に対応できるアジャイル型開発モデルが広く採用されている。らしい。
ウォーターフォールモデルでは、プロジェクトの初期段階で全ての要件を詳細に定義する必要がある。要件が不明確または不完全な場合、後の段階で問題が発生し、修正が必要になる可能性がある。これでは、開発スケジュールが遅延するのも必然である。
治験では、「⑤参加者の組み入れ：適格基準に合致する参加者を治験に組み入れる。」が往々にしてうまくいかない。治験が遅延するほとんどのケースにおいて、組み入れが治験プロジェクトにおけるボトルネックになる。この適格基準は治験の「要件」の一部とも言い換えることができる。適格基準が規定されるのは「①治験実施計画書の作成」プロセスであるから、大抵の場合、「①治験実施計画書の作成」プロセスに問題があるといえる。
次回に続く
この記事が気に入ったらサポートをしてみませんか？