医療PMのプロジェクト管理手法。ウォーターフォールとアジャイルの使い分け

「うちはアジャイルでやってるんで、ドキュメントは後回しでいいですよね」——SaMDのスプリントレビューで、開発リーダーからこう言われたことがあります。

結論を先に言うと、医療DXのPMにとってウォーターフォールとアジャイルは「どちらが正しいか」で選ぶものではなく、規制対象の性質によって配分を変える技術だと考えています。SaMD開発は設計履行文書（DHF）の追跡性要件があるためウォーターフォール的な骨格が事実上必須になりますし、電子カルテ標準化や治験DXの現場は逆に短サイクルの検証を求めます。個人的には、この二つを同じプロジェクトの中でどう配合するかが、医療PMの実務スキルの核だと感じています。

1. 医療PMの現場で起きる「手法のねじれ」

「アジャイルでいきましょう」と言われた次の会議で、監査で提出する設計履行文書がまだ空白だと知った、という笑えない実話があります。僕が以前関わっていたSaMD（プログラム医療機器）のクラスII相当の案件では、開発チームがスクラムを導入した直後にスプリントの成果物とDHFの更新が噛み合わなくなり、内部監査の指摘で二週間分の作業を巻き戻すことになりました。開発チームからすれば「動くものを早く作る」という正しい判断だったのですが、薬事側から見ると「どのスプリントでどの要求仕様が確定し、どのリスク分析が更新されたか」の追跡が取れていない状態は、そのまま承認審査のつまずきに直結します。

医療DXのPMをやっていると、こうした「手法のねじれ」に何度も遭遇します。開発チームはアジャイルの効率を体感しているし、事業側はスピード感を求める。でも規制側の要求は、変更のたびに文書と根拠を紐づけることを前提にしています。個人的には、この二つの要求は矛盾しているのではなく、レイヤーが違うだけだと考えています。どのレイヤーにどちらの手法を当てるかを設計するのが、医療PMの実務そのものだと感じています。この記事では、SaMD開発・電子カルテ標準化・治験DXという3つの現場を例に、ウォーターフォールとアジャイルをどう配合すればいいかを、僕の体感値をベースに整理してみます。

2. SaMD開発が構造的にウォーターフォールへ寄る理由

IEC62304（医療機器ソフトウェアライフサイクルプロセス）やISO14971（リスクマネジメント）が要求するトレーサビリティは、要求仕様書・設計仕様書・検証記録・妥当性確認記録が一直線に紐づいていることを前提にしています。変更管理のたびに影響範囲分析が必要で、これはアジャイルの「短サイクルで頻繁に変更する」性質と本質的に相性が悪い面があります。PMDAの承認審査でも、開発プロセスの記録が一貫したストーリーになっているかが確認されますから、純粋なスクラムでバックログの優先順位を頻繁に入れ替えると、ドキュメント更新が後追いになり、その整合作業がPMの負荷として跳ね返ってきます。

個人的な体感では、クラスII相当のSaMD案件だと、要求仕様が固まるまでに全体スケジュールの3〜4割程度を設計フェーズに使うことが多いです（あくまで僕の経験に基づく目安値で、案件の規模やクラス分類によって前後します）。この設計フェーズを短縮しようとすると、後工程の検証・妥当性確認でつじつま合わせの作業が発生し、結果的にトータルの期間は延びてしまう、というのが僕の観測です。医療PMの役割は、ここで「早く作りたい」という開発チームの気持ちを否定するのではなく、どこまでを固定してから実装に入るべきかを、規制要件を根拠に説明することだと考えています。

3. 電子カルテ標準化・治験DXがアジャイルを求める理由

相互運用性の実装（HL7 FHIRやSS-MIX2に準拠した連携など）は、複数ベンダーの実装差異が想定通りに動くかどうかを早期に確認しないと、後工程で連鎖的な手戻りが起きやすくなります。現場の医師・看護師のワークフローへの適合も、実際に触ってもらうユーザーテストを繰り返さないと確定できません。治験DXのEDCやRBMも同様で、モニタリング担当者やCRCの使い勝手のフィードバックを早く反映したほうが、結果的に品質が上がるというのが僕の実感です。

以前、電子カルテ標準化のプロジェクトで、最初にウォーターフォール的に全ベンダーの仕様をすり合わせてから実装に入ろうとしたことがあります。仕様確定までに半年近くかかり、その間に現場のニーズが少しずつ変化していて、実装が終わった頃には「これじゃない」という声が上がってしまいました。この経験から、相互運用性のうち「仕様の骨格」はウォーターフォール的に固定する一方、現場適合の部分は短サイクルの検証を挟んだほうがいいと考えるようになりました。ウォーターフォールで最後にまとめて検証すると、現場に合わないシステムが仕上がってから発覚するリスクが高い、というのが個人的な結論です。

4. 実務のハイブリッド設計：Water-Scrum-Fallの組み方

実務でよく使われる考え方に「Water-Scrum-Fall」というものがあります。要求定義とリスク分析はウォーターフォール的に固める（Water）、実装はスプリントで進める（Scrum）、検証・妥当性確認と申請文書化は再びゲート型に戻す（Fall）という3層構造です。PMの役割は、各層の境界をどこに置くかを最初に決め、スプリントの中でも変更が起きたら必ずトレーサビリティマトリクスに反映するチェックポイントを設けることだと考えています。

僕が過去に関わったプロジェクトでは、スプリントレビューの中に薬事担当者を毎回同席させ、その場でDHFへの反映が必要な変更かどうかを判定するルールを作りました。最初は「毎回同席するのは負荷が高い」という声もあったのですが、2週間ごとにDHFの断面をスナップショットとして残すようにしたところ、監査対応の作業が最終盤にまとめて発生することがなくなり、結果的にチーム全体の負荷は下がったという実感があります。個人的には、この「境界を最初に決め、定期的にスナップショットを取る」という2点が、ハイブリッド運用を機能させる要だと考えています。

5. ケース比較：3つの現場でどう手法を変えるか

SaMD開発・電子カルテ標準化・治験DXでは、求められる文書と推奨される手法配分が異なります。以下は僕の経験を踏まえた目安の比較です。

この表を見て分かるのは、どの現場にも「固定すべき骨格」と「反復して確かめるべき部分」の両方が存在するということです。医療PMの実務は、どちらか一方に統一するのではなく、案件ごとにこの境界線をどこに引くかを判断する仕事だと、個人的には整理しています。

6. 今日からできる実務アクションと、よくある失敗

手法の配合を考えるうえで、今日から始められる実務アクションを僕の経験からいくつか挙げてみます。

1. プロジェクト開始時に、規制上必ず固定しなければならない項目（DHFの構成要素、連携仕様の骨格など）を洗い出し、「ここはウォーターフォール」と最初に線を引く。
2. スプリントを導入する部分については、2週間前後のサイクルごとに規制文書のスナップショットを取るルールを、開発チームと合意しておく。
3. ステークホルダー（薬事担当・現場医療従事者・ベンダー）に対して、「どこがゲートで、どこがスプリントか」を初回のキックオフで共有し、後から手法をめぐる対立が起きないようにする。

一方で、よくある失敗もあります。ひとつは、開発チームの熱意に押されて全工程をアジャイルにしてしまい、後半で規制文書の整合作業が山積みになるケースです。もうひとつは逆に、規制対応を過度に重視してすべてをウォーターフォールにしてしまい、現場のニーズ変化に追いつけずリリース後に大きな手直しが発生するケースです。どちらも、僕が実際に近い状況を目にしたことがあります。対処法としては、案件のキックオフ段階で「なぜこの部分はウォーターフォールで、この部分はアジャイルなのか」を根拠つきで説明できるようにしておくことだと考えています。根拠が説明できれば、後から手法の変更を求められたときにも、感覚論ではなく規制要件やリスクの大小を軸に議論ができます。

(結論)

医療PMにとってのウォーターフォールとアジャイルは、料理でいえば「土台の出汁」と「仕上げの調味」のような関係だと、個人的には感じています。出汁（骨格）がぶれていると、いくら仕上げを丁寧にやっても全体の味が定まりません。逆に出汁だけに時間をかけすぎると、料理として出すタイミングを逃してしまいます。SaMD開発は出汁の比率が高く、電子カルテ標準化や治験DXの現場は仕上げの調整に時間をかけたほうがいい、というのが僕の体感値です。どちらの手法が優れているかではなく、案件の規制対象に応じて配分を変える技術を持つことが、医療PMとしての専門性のひとつだと考えています。

皆さんいかがでしたでしょうか。手法選定に悩んだときは、まず「規制上絶対に固定しなければならない部分はどこか」を洗い出すところから始めてみてください。では今日もがんばりましょう。