私は忙しいんです。システム開発に協力できる時間なんてありません――「旭川医大の惨劇」解説その2：「訴えてやる！」の前に読む IT訴訟 徹底解説（48）（1/3 ページ）

ユーザーが出し続けた1000を超える追加要件にベンダーが対応仕切れずプロジェクトが破綻した「旭川医大vs.NTT東日本 病院情報管理システム導入頓挫事件」。悪いのは100％ユーザーなのか、ベンダーはどうすればよかったのか――細川義洋氏による同事件のポイント解説、第2弾は「体制」と「開発方針」について考察する。

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

連載目次

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

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

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

03　それでも最善を尽くす、それがベンダーの仕事だ――「旭川医大の惨劇」解説その3

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

　前回は、事件の概要を説明し、高等裁判所判決のポイントとなった「ベンダーのプロジェクト管理義務」について、解説した。今回は「プロジェクトの体制」と「開発方針」について考察する。

　事件の流れを把握するために、判決文を再掲しよう。

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

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

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

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

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

仕様？　その話は後にしてくれないかな。今から手術なんでね。