「アジャイルなので」は、免罪符にならない

先日、あるSaMDの開発チームとの打ち合わせで、規制対応の話になった。

少し考え込んだあと、エンジニアが苦笑いしながら言った。

「規制は分かっています。でも、うちはアジャイルなので」

私は、すぐには返事ができなかった。

規制を軽く見ているわけではない。

一日でも早く患者に届けたい。早く試し、早く良くしたい。

そんな思いが伝わってきた。

ただ、気になった。

アジャイルであることが、いつの間にか規制対応を考えなくてよい理由になっていないだろうか。

変わることと、説明できないことは違う

アジャイルでは、最初からすべてを決め切らない。

小さく作り、試し、学び、また変える。

それは医療ソフトウェアにとっても大切な考え方だ。

ただし、患者に使われる製品には、何を作り、誰が使い、どんなリスクがあるのかを説明できることが求められる。

以前、開発チームが言った。

「まずリリースして、ユーザーの反応を見ましょう」

すると、臨床側のメンバーが静かに返した。

「それは、もう患者さんに触れる出力です」

部屋が静かになった。

開発側も臨床側も、患者のために考えていた。

違っていたのは、「試す」という言葉の意味だった。

患者に触れる前に試すことと、患者に触れさせてから反応を見ることは違う。

アジャイルだからといって、その境界がなくなるわけではない。

その緑は、何を保証していますか

あるCTOと話していたときのことだ。

「うちはCIが通れば、そのままデプロイしています」

私は聞いた。

「その緑は、何を保証していますか」

返ってきたのは、

「単体テストです」

という答えだった。

もちろん、それは大切だ。

しかし、単体テストが通ることと、製品として安全だと判断できることは同じではない。

コードが意図どおり動くこと。

変更によって製品の振る舞いがどう変わったかを確認すること。

その変化が、リスクに照らして許容できるかを判断すること。

それぞれ、確かめるべきことが違う。

CIの緑は、設定された検証が通ったことを示す。

何を検証し、何を検証していないのか。その意味を理解しておく必要がある。

変更が多いからこそ、何を変え、なぜ変え、何を確認したのかを、その都度残していく。

証拠を申請直前に集めるのではない。

開発している、その日に残す。

それは開発を遅くするためではない。

安心して変更を繰り返すための仕組みだ。

翻訳を、最後にしてはいけない

もう1つ、何度も見てきたことがある。

開発がかなり進んでから、薬事や品質保証が呼ばれる。

「この製品について、どう説明しますか」

そこで初めて、開発の言葉を薬事や品質保証の言葉に置き換えようとする。

問題は、誰かの理解が足りないことではない。

翻訳が最後になっていることだ。

これは、コミュニケーション不足だけの問題ではない。

規制対応を開発プロセスの外側に置いている、組織の設計の問題でもある。

本来は、エンジニア、臨床、薬事、品質保証が、製品の形も決まっていない頃から一緒に考えたい。

何を作るのか。

誰が使うのか。

何を変えてよくて、何を変えるときには立ち止まるのか。

規制対応を開発の最後に足すのではない。

製品を作りながら、必要な問いを共有していく。

それが組織の仕事だと思う。

アジャイルを、言い訳にしない

私は、薬事にも品質保証にも携わってきた。

そして、スタートアップで開発の1日がどれほど重いかも経験してきた。

だから、開発の速さを否定したいわけではない。

患者に早く届けたい。その思いは大切にしたい。

ただし、アジャイルであることは、品質や安全性について説明する責任を軽くするものではない。

むしろ、変化を前提にするからこそ、変更の意味と影響を説明できなければならない。

速く作ることと、説明できること。

その両方を実現するのが、組織の仕事だ。

「うちはアジャイルなので」

その言葉を、規制対応を遠ざける理由にしてはいけない。

問い直すべきなのは、こちらだ。

どうすれば、変わり続けながら、安全に進めるのか。

よろしかったら、こちらもどうぞ。

マガジンの玄関はこちらです

よろしければ、ここから全体の流れをご覧ください。

全体の玄関はこちらです

ほかのテーマやシリーズへの入口を、ここにまとめています。