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

もう一度言う。ベンダーには「プロジェクト管理義務」がある

　前回も書いた通り、この事件は他のIT紛争でもよく見られる「ベンダーのプロジェクト管理義務」が争点になった。

　ユーザーがいつまでも要件を取りまとめ切れず、プロジェクトに破綻の危機があるとき、ベンダーはその危険をユーザーに説明し、場合によっては要件の拒絶や追加見積もりを行ったり、スケジュールの見直しをユーザーに提言したりしなければならない。これが「ベンダーのプロジェクト管理義務」だ。

　通常、要件の取りまとめはユーザーの責任である。しかし、取りまとめの遅延がプロジェクトにどれほどの悪影響を及ぼすのかを本当に理解しているのはベンダーであり、彼らには素人であるユーザーが要件をしかるべき時期までに取りまとめるように「管理する」義務があるという考え方だ。

　この裁判でも、「ベンダー（NTT東日本）がプロジェクト管理義務を果たしたのか」が争点になった。実際、非常に微妙な判断だったらしく、第一審の地裁は「ベンダーがプロジェクト管理義務を十分に果たしていない」として「責任の8割がNTT東日本にある」との判断をした。

　しかし第二審（高裁）は、「NTT東日本は、ユーザーの要件追加が止まないことについて度々警告を発し、いったんは仕様凍結まで行っていることでプロジェクト管理義務を果たしている」とし、「プロジェクト失敗の責任は全てユーザーにある」と判断した。

　裁判所が正反対の判断を出したことから考えても、ベンダーのプロジェクト管理義務は判断が難しく、ベンダーはどこまでやるべきなのか明確なコンセンサス（あるいは常識）は存在しないように思われる。

　この事件は、ベンダーに有利な判決が出た。しかし、本連載で何度となく書いてきたように、裁判に勝ったからといって、ベンダーが手放しで喜ぶわけにはいかない。システム開発はあくまでユーザーの望むものを作り、それが業務に資することを目的に行うものである。プロジェクトが破綻した時点で、ユーザーはもちろん、ベンダーにとっても“負け”なのだ。

　では、何がいけなかったのだろうか。ベンダーは何ができたのだろうか。

“病院”というユーザーの特性

　まず、この事件の「ユーザーの特性」について考えてみよう。

　エンドユーザーである医師たちからの要望が仕様凍結後も収束しなかったという点から、このプロジェクトは初期の段階で「医師たちが十分に関与しなかった」ことがうかがえる。

　医師の代表者がプロジェクト計画承認や仕様凍結の判断に加わっていれば、その後、野放図に現場から出てくる要望をコントロールできたし、そうさせるのがベンダーのプロジェクト管理義務でもある。恐らくベンダーもプロジェクト開始当初に、そうした代表者の役割を、医師の中心人物、もしくは病院のシステム部門代表者に望んだことだろう。

　しかし実際には、医師もシステム部門の代表者も、そうした役割を十分に果たしてはくれなかった。

　しかしそれは、彼らが怠慢だったわけではないと思われる。

　私は以前、ある大学病院のプロジェクトでコンサルタントとしてヒアリングを行ったことがある。そこで分かったのは、医師という職業は本当に多忙で、週に何日も家に帰れないことも珍しくないということだ。システム開発に割ける時間などほとんどないのが実情だ。旭川医大も同じような状況であったろうと想像する。

　病院のシステム部門代表者は、医師たちに協力を命じるほど立場が強いわけではなくた医師に代わって要件を定義できるほど医療に精通しているわけでもない。

　病院は、要件の取りまとめに時間がかかるユーザーなのだ。