アジャイル型開発のコンピュータライズドシステムバリデーション(CSV)

2019年12月10日

CSVスペシャリスト 黒豆狸とCSVのなかまたち


こんにちは、自転車好きのCSVスペシャリスト、黒豆狸です。
前回(2019年6月)のコラムではRPAのコンピュータライズドシステムバリデーション(CSV)についてご紹介しましたが、今回はアジャイル型開発のCSVについてご紹介します。

ウォーターフォール型開発の限界

CSV関連の業務をしていると、製薬会社のIT部門の方とお話しさせていただく機会が多くあります。ここ数年よく耳にするのは「RPA・アジャイル型開発・AI」といったキーワードです。※


製薬業界は法規制が厳しく信頼性保証が求められるためか、システム開発に関しては保守的な印象があります。今回とりあげる「アジャイル型開発」も、その名前は知っていても実際にはなかなか取り入れられません。その一因は業界内で広く普及しているCSVの概念が、典型的なウォーターフォールモデルを想定しているためではないでしょうか。


※ちなみに5年くらい前のキーワードは「クラウド化」、そのさらに5年前くらいはASPでした。

 

悩む男性

 

しかし、筆者がCSV担当者として携わったGCP・GVP・GPSPの業務システム開発プロジェクトでは、ここ数年でいよいよウォーターフォール型のCSVアプローチに限界を感じるようになりました。

 

というのも、実際のシステム開発の現場は「見て分かった、触って気が付いた」がとても多く、ベンダーもそのことを当然想定していますので、形式としてはウォーターフォール型開発を取っていても、実際にはプロトタイプを作って実機環境を動かしながらユーザーと仕様を決定していく、いわゆるアジャイル型のような開発プロジェクトが主流となってきたからです。
そのため、既存のCSVアプローチでは対応しきれなくなってきたと感じています。

 

アジャイル型開発は一般的に、短い期間で小さい規模の開発を反復して徐々にシステムを作り上げていく手法と紹介され、ウォーターフォール型開発との違いとしては、開発の途中で機能ごとに動くモノが出てくることや、開発しながらの改善・変更を前提としていることが挙げられます。

では、このような「変更が当たり前」のアジャイル型のシステム開発に、CSV担当者はどのようにアプローチしていけば良いでしょうか。

計画時

ベンダーがわざわざ「〇〇型でやりますよ」とでも言わない限り、ユーザーやCSV担当者は、どのような手法で開発をしようとしているのかはわかりません。またその逆もしかりです。開発が始まってからお互いの想定が違った・・・となってしまうとCSV的には困ります。※


理想をいうならば、プロジェクト開始の段階で、ガッチガチのウォーターフォールで進めるのか、柔軟に要件の取捨選択をしながら仕上げていくアジャイル型開発を進めるのか、ベンダーと相談し、プロジェクト内の共通認識を持っておくと、心の準備がしやすいです。

 

相談している人たち

 

※筆者がCSV担当者として携わった開発プロジェクトの中には、ウォーターフォールを想定して戦略を立てていたら、実際はかなりアジャイル寄りの手法でシステム開発が進み、CSV戦略を立て直さなければならないものがありました。

 

設計~開発

アジャイル型開発といわれてCSVのアプローチでまず心配になるのは、

 ●仕様書はどの段階で出てくるのか・出てきた仕様書はどの段階で承認をするのか
 ●設計時の適格性評価(DQ)をどのように説明するか

ということです。


システムによっては、ベンダーとユーザーが共有できる実機環境でモノを見ながら開発をしていき、出来上がった後に構成定義情報をシステムから出力する、という場合もあります。
既存のCSVアプローチではDQを経てからシステム開発に入るという考え方が定着していますが、上記のような場合は「ベンダーとユーザーが共有できる実機環境でモノを見る」という評価活動をDQと位置づけることができます。

 

では次に、仕様書の扱いはどうするのが良いでしょうか。
完成するまで仕様書は手に入らないとなると、仕様書の入手と承認はだいぶ後、もしかするとユーザー受け入れテスト(UAT)が終わってからになるかもしれません。

 

その場合はもう「仕様書の承認日は開発開始より前でないといけない」というセオリーは潔く諦めて、システム開発計画書かバリデーション計画書に承認日が開発開始より後になることを記載しましょう。※
また、仕様書を受け取った際には環境やUAT実施結果と一致する内容になっているかしっかり確認しましょう。


※計画書に書いておかないと「仕様書の日付がUATより後になっている」と社内監査等で指摘を受ける可能性が高いです。

検証

変更の発生を前提とするアジャイル型開発は、どの段階で検証を行うかが悩ましいところです。前述のとおり細かい単位での開発と確認は都度行うことになりますが、その「都度の確認」をUATとするのか、あるいはある程度まとまった段階でシステム全体でのUATを行うのか、という問題です。

 

システムの性質にもよりますが、例えば入力フォームや帳票についての確認はそれぞれの機能ができあがったタイミングで行う確認作業を検証と位置づける。ワークフロー管理のような機能は関連機能が出そろった段階で業務シナリオに沿ったUATを行う、という切り分け方ができます。

 

変更の発生が当たり前のアジャイル型開発においては、仕様FIXを待つときりがない可能性があります。あらかじめ、このタイミングの実装内容でUATを行うという期限をプロジェクト内で関係者と合意しておく必要があります。

報告

アジャイル型開発では優先度に応じて実装する要件を選択しながら開発が進んでいくため、本番リリース時点では実装しきれなかった要件や解決できなかった問題が残る可能性があります。

 

それらの問題については、業務への影響はないのか、いつ頃対応する予定なのか、残った課題はリリース後どのように管理していくのかをバリデーション報告書に記述します。

 

また、リリース後も残った課題を解決するまで管理を忘れずに行いましょう。※
リリース後速やかに、障害管理・変更管理へ移行できるよう、あらかじめ運用開始後のCSV手順をリリースまでに定めておきます。

 

レポート

 

※ベンダーから問題管理や変更管理の状況が定期的に共有されるのであれば、それを活用するのもありです。

 

さいごに

以上、アジャイル型開発のCSVアプローチについてご紹介しました。
今回はややウォーターフォール型の概念を引きずったアプローチのご紹介となりましたが、非ウォーターフォール型の開発手法が今後さらに普及していけば、CSVアプローチにも脱ウォーターフォールの考え方が求められてきます。その際にはCSVの目的である、適格性を確認した結果を第三者に分かるよう文書化し記録する、ということに立ち返ってよりスマートなCSVアプローチをあらためてご紹介したいと思います。

 

最後までお読みいただきありがとうございました。次号もお楽しみに!

 

 

※記載されている情報は2019年12月時点のものです。


TOP