それでも最善を尽くす、それがベンダーの仕事だ――「旭川医大の惨劇」解説その3：「訴えてやる！」の前に読む IT訴訟 徹底解説（49）（1/3 ページ）

ユーザーが出し続けた1000を超える追加要件にベンダーが対応仕切れずプロジェクトが破綻した「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」。病院という「特殊な」ユーザー相手に、ベンダーはどうすべきだったのか――細川義洋氏による同事件のポイント解説、第3弾は「特殊なユーザー」のプロジェクトを成功に導くための方法と考え方を指南する。

[ITプロセスコンサルタント 細川義洋，＠IT]

連載目次

「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」解説

01　追加要件を実装しなければ、このシステムは使いません――「旭川医大の惨劇」解説その1

02　私は忙しいんです。システム開発に協力できる時間なんてありません――「旭川医大の惨劇」解説その2

　旭川医科大学（以降、旭川医大）で発生した、システム開発のトラブルに関する訴訟。事件の概要は、「ユーザー（旭川医大）が電子カルテを中心とした医療システムの導入を企図し、ベンダー（NTT東日本）に開発を依頼したが、現場の医師からの要件追加、変更がいつまでたっても収束せず、スケジュールが遅れに遅れた揚げ句に破綻してしまった」というものだ。

　短期集中解説シリーズ、第1回は事件の概要と高等裁判所判決のポイントとなった「ベンダーのプロジェクト管理義務」について、第2回は「プロジェクトの体制」と「開発方針」はどうあるべだったのかを解説した。

　今回は、病院のような「特殊なユーザー」のプロジェクトを成功に導くための方法と考え方を、実例を交えて指南する。

　事件の流れを把握するために、今回も判決文を再掲する。

札幌高等裁判所 2017年8月31日判決から

旭川医科大学は、2008年8月に、電子カルテを中核とする病院情報管理システムの刷新を企画し、NTT東日本に開発を依頼した。

しかし、プロジェクトの開始直後から、現場の医師たちによる追加要件が相次ぎ、プロジェクトが混乱した。NTT東日本は、1000近くに上る追加項目のうち、625項目を受け入れた上で、仕様を凍結（もうこれ以上要件の追加、変更は行わないことで合意すること）し、納期も延長することになった。

ところが、仕様凍結後も現場医師らの要望は止まず、さらに171項目の追加項目が寄せられ、NTT東日本は、このうちの136件の項目を受け入れたが、開発はさらに遅延し、結局、旭川医大が期日通りにシステムを納品しなかったことを理由に、契約解除を通告した。

これについてNTT東日本は、「プロジェクトの失敗は旭川医大が要件の追加、変更を繰り返したことが原因だ」と損害賠償を求めたが、旭川医大は「NTT東日本が納期を守らず、テスト段階での品質も悪かった」と反論し裁判になった。

　「ユーザーがいつまでたっても要件の追加、変更を止めてくれない」のは、どのシステム開発プロジェクトでも起こり得る事象である。ベンダーの永遠の悩みといってよいほどだ。ただ多くの場合は、「仕様凍結」という手順を踏めば、ユーザーも少しはおとなしくなってくれるものだ。しかし本事件は、そうはいかなかったようだ。

　両者が仕様凍結に合意した後も、ユーザーから170項目を超える要望が発生し、ベンダーもこのうち135件の実施を約束している。これではとても当初の納期を守ることなどできない。

この機能も追加してもらえませんかね。え、仕様凍結？　いやいや、そこを何とか