誰か知る松柏後凋の心

たれかしる しょうはくこうちょうのこころ

国循着任直後に直面した課題(電子カルテ導入作業)②~「多くの入札参加者を募るために」作られた仕様書がもたらした災いとは~

前回のブログでは,私が国循に着任直後,電子カルテ仕様書を見て,その記載の乏しさに驚いたということを書きました。国循では,情報システムを管理する立場にある者が,「多くの入札参加者を募るために」,本来,明確にすべき要件の記載を削ってしまうことに同意していたのです。

今回は,情報システム更新において,記載の乏しい仕様書がなぜ良くなかったのか,すなわち,そのような仕様書で入札に臨むと,最終的にどのような災いが起こったのか,について,当時の国循の電子カルテの例を引きつつ書いてみたいと思います。記載が乏しい,という表現にもいろいろなとらえ方があるかと思いますが,今回は,詳細度が足りない(=細かなところをきちんと書いていない)仕様書に焦点を当てて論じます。

  • なお,この記事は,国循サザン事件に関連する事項について言及するものではありません。同事件では,情報システムの更新ではなく,情報システムの運用・保守を対象とすることと(調達対象が大きく異なる),予算規模や背景事情など,ここで論じるものと別の要因が多くあるため同一の視点から論じることはできまません。

私は,詳細度が足りない仕様書には,3つの弊害があると考えます。

  1. ベンダ(システム導入を担当する企業)に「やらない言い訳」を与える
  2. 入札において現行ベンダに有利な状況を生む
  3. 現場でのシステム運用に悪影響を及ぼす

1.ベンダに「やらない言い訳」を与える

これは,教科書に書いてあるような一般的なことです。つまり,ベンダは,

仕様書に書いてない(契約の範囲外な)ので,やりません。

と言うことができる,ということです。ぼんやりとは仕様書に書いてあったとしても,解釈の違いと言われてしまえば,突き詰めれば,詳しく書かなかった発注者側の負けです。

国循の電子カルテでいえば,ベンダが「仕様書にないのでやりません」という場面はありませんでしたが,開発が間に合わないものはどんどん後ろに送られ,最終的には実現しなかった機能も多くありました。

2.入札において現行ベンダに有利な状況を生む

そもそも,「多くの入札参加者を募るために」わざわざ曖昧な仕様書をつくれば,本当に公平な入札が実現するのでしょうか。実際には,曖昧な仕様書は,現行ベンダの圧倒的有利な状況を生み出します

前項で述べたとおり,本来,仕様書に書かれていない項目(機能・業務)は,ベンダにとって「契約外であり,提供する必要のない」ものであるはずです。しかし,ベンダは,

仕様書になくても,現状において存在し,実際に使われている機能(あるいは実際に行われている業務)については提供しなければならない

と考えるものです。なぜなら,そのようにしないかぎり現場の運用ができず,結局,情報システムの導入が「失敗」に終わるからです。

したがって,新たに参入するベンダは,「システム更新(=現行ベンダが存在する)」という状況において,「曖昧な仕様書」が提示されると,

現行ベンダしか知らない,仕様書に含まれていない余分な作業が発生する

と判断し,そのコスト(コンティンジェンシー*1)を応札価格に上乗せする必要に迫られます。

しっかりとしたリスク管理を行う企業では,これを受注リスクと捉えて大きなコストを見積ることになるでしょう。当然,応札価格は高くなり,落札の確率は低くなります。場合によっては,参加を取りやめることもあるでしょう。

一方,現行ベンダは,ほぼコンティンジェンシーを考慮せず入札に臨むことができますから,圧倒的に有利です。

現場の運用をよく知っている現行ベンダが,ある程度,入札で有利になることは当然のことです。これはどのような入札方式を取ったとしても変えようがありません。しかし,仕様が曖昧であると,現行ベンダ以外のベンダにとって,取るべきリスクの大きさがわからない,すなわち,それをコストとして定量的に把握できないことが大きな問題です。入札を考える企業にとってみれば,そのコストが明確になり,かつ将来回収できると見込まれるようであれば,利幅を小さくしてでも入札にチャレンジすることができますが,そのコストの多寡が不明であれば,まともな企業が参加するとはとても思えません。

「公平性を担保する」つもりで,本来,国循が必要とする機能を削り,または機能の説明を尽くしていない仕様書を準備し,その結果として,圧倒的に現行ベンダの有利な状況を作り出し,かえって競争性を失わせたという事実は非難されるべき問題です。

3.現場でのシステム運用に悪影響を及ぼす

システムの仕様書作成の過程において最も重要な作業は,現場の医療従事者から得た意見をもとに,現場で真に必要な機能を,その運用方法を含めて明確にすることです。この作業によって,カスタマイズされている(=国循の特別仕様としてシステムが改修されている)が実は不要な機能や,新たにカスタマイズが必要な機能が明確になり,さらに,システムリリース後に,現場スタッフがその機能をどのように活用するのかも明確になります。

本来,システム更新の仕様書においては,このようなカスタマイズ部分こそが,もっとも詳しく記述されるべきですが,国循の電子カルテ仕様書においてはその内容が十分に読み取れるものではありませんでした。また,仕様書作成の過程において,現場と具体的なシステム運用が話し合われていたのかが疑問に思われました

その結果,電子カルテシステムのリリース後になって,私はユーザから

こんなはずではなかった

こんなシステムは使えない

自分たちがヒアリングで伝えたことはなんだったのか

というクレームを多く受けることとなりました。

当然,現場からのすべての意見をシステムに反映させるとなると費用がかかりすぎるので,そのようにできるわけではありません。しかし,本来であれば,現場との打ち合わせのなかで,システム運用をある程度確定したうえで,実装可能な機能は仕様書として残すといった丁寧な対応をすべきものです。この対応の結果として,残された仕様書

  • システム運用に関する管理側と現場との合意事項

の証しとなるのです。

ところが,本件の仕様書は,現場とどのような合意があったのかが読み取れないものでした。とくに,電子カルテ導入により新しく追加される「注射の指示」「注射実施入力」の機能については,仕様書作成段階ではまったく現場とすりあわせができていませんでした。その結果,2012年1月のシステムリリース直後に,注射関連の機能が現場で運用できないものであることが判明し,この機能を使用停止し,紙運用に戻さざるをえませんでした。その後,何度もNECや現場のスタッフと打ち合わせを重ねるなどして,最終的にはこれらの機能をリリースすることができましたが,それが実現したのは,システムをリプレースしてから2年以上経ってからのことでした。

実は,このようなずさんな仕様書が原因となって,システム運用に問題を来した例は注射関連機能にとどまりません*2。この原因は,仕様書作成段階で,

  • 現場と十分に詰めておくべきことを怠ったこと
  • 協議内容を曖昧なままにした仕様書しか残さなかったこと

が最大の原因であろうと思いました。

国循官製談合事件,いわゆる国循サザン事件について知りたい方は,こちらのサイトをごらんください。↓

*1:Cost Contingency

*2:ここでは割愛します