「医療システムの仕様」が原因で入院患者が死亡、なぜ病院側は要件定義の際に気付けなかったのか……

原因は注意不足……でも、それを補う要件定義はできたはず

　裁判所はこのように述べ、「病院側が十分に注意義務を果たさなかった」と断じました。

　この判決を通り一遍に読めば、患者が死亡した原因を単なる「担当者の不注意」と片付けることもできます。しかし、システム開発者の視点からすると、この事故はシステムの要件定義をより慎重かつ詳細に行っていれば防げていたとも思えます。転床が発生した際、作業の流れの中でベッドサイドだけ先に設定し、センター側は後で設定するといったケースが発生することは容易に想像できたはずです。そして、センターから紐づけを行う際も、アラーム設定が上書きされるという仕様をそのままにしておけば、当然に今回のようなことが起こる危険性があるというのは、素人の私でも想像がつきます。

　つまり、業務の中で様々に発生し得ること、そして、そのときの自分たちの挙動をリアルに想像し、仕様の不都合な点、問題点を十分に洗い出せなかったことが、この悲劇を招いたとも言えるのです。

　たしかに、多忙かつ神経を張り詰め続ける病院勤務の中で、システムの要件という広範かつ詳細な文書を、想像力を働かせて綿密に精査することは本当に大変なことだとは思います。しかし、そうした想像力の欠如が人の命を奪う大きな要因となったのも事実です。病院側としては、システム導入に精通した要員の拡充や育成も含めて、様々な対策が求められるところでしょう。

要件を詰めるときは現場を巻き込め

　今回のような事故を起こさないシステムを作るためには、ユーザー組織内全体の協力が不可欠でしょう。要件定義において、開発担当者がシステムの利用者、たとえば今回の場合は現場の医療従事者たちをできるだけ多く集め、各業務のフローをウォークスルーしながら要件を詰めていくしかありません。そうすれば、システム連携時の不備も現場に導入される前に発覚するでしょう。

「センターからデフォルト値を送れば、ベッドサイドの同期の手間が省けるね」

「いや、それではベッドサイドで行った設定が初期化されてしまう……」

「実際、そんなことが必要な場面はある？」

「いやいや……」

　こんな会話が要件定義の際に交わされていたなら、今回のような事故は防げたかもしれません。皆で車座になり、あーだこーだと言い合う。無論、それとてすべての場面を想定するには不十分かもしれませんが、昨今であれば、AIなども活用しながら要件の精度と網羅性を上げていくことが、今回のような悲劇を招かない一つの方策となるでしょう。