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

そのシステム要件が必要か否か、テストでは検出できない

　情報システムとは、「システム」という名のとおり様々なオブジェクトが連携しながら動作し、結果を出していくものです。システムの持つ機能、プログラム、サブシステム、データ、対象業務とそれを使う人々……。そうしたものが複雑に絡み合いながら、連携して結果を出していきます。それらが上手くつながらなかったり、各動作の時間がずれていたりすれば、システムは意図したとおりに働かず不正な結果を導きだします。

　こうした問題を検証するのが、システム開発における結合テストや総合テスト、あるいは業務テスト、運用テストといったプロセスになります。プログラム単体では正常に動作していても、それを他とつなげた際、インタフェースや処理タイミングが不正でエラーとなってしまうなどといった現象を抽出し、修正するのがこうしたテストの役割となります。

　ところが、こうしたテストを何度実施しても、問題を検出できないケースがあります。それは、そもそもの要件として「連携を想定して定義されていない」場合です。

　たとえば在庫管理を行うシステムで、商品の在庫数が規定を下回ったらアラームが出るよう、「在庫数を数える機能」と「閾値で監視する機能」が連携していたとします。この監視がシステム内で実施されるタイミングが、毎日夕方5時だけに設定されていたとしましょう。すると、それまでの間に行われた出荷により一時的に在庫が規定を下回っても、最終的に5時までに一定数の入庫があれば、アラームは出ません。

　もっとも、その場合、そもそもアラームが必要かどうかは業務の在り方や事情によります。「とにかく夕方の時点で数が足りていればよい」という業務なら、アラームは出さなくてよいでしょう。しかし、「一時的でも数を下回ってしまうと緊急出荷に対応できない」という業務なら、アラームは逐一出す必要があります。

　ただし、一つ間違いないことは、これらは「テストで検出すべき不具合ではない」ということです。どちらを選択するにせよ、“要件”として定義すべき事項です。在庫管理機能と監視機能をどう連携させるのが業務として正しいか、テストで正しいか否かを検出することはできないため、開発の際にきちんと定義しなければなりません。

　今回紹介するのは、こうしたシステムの機能間連携を業務目線で定義できておらず、その結果、人の命を奪う事態が発生してしまった医療システムを巡る裁判です。まずは事件の概要からご覧ください。