ここから本文です

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

11/1(水) 7:00配信

@IT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●特性をふまえて「スケジュール」や「開発方針」を検討すべし

 病院相手のプロジェクトは、要件定義の期間が通常の2~3倍かかると覚悟した方がよいし、医師への説明と確認を辛抱強く行うことが必要だ。

 開発方式は「ウオーターフォール」ではなく、部分的に要件を確認しながら小規模な実装を積み上げていく「アジャイル」の方が良かったかもしれない。

 アジャイル開発であれば、業務の都合上、最低限必要な機能から順次リリースできるし、取りあえず基本的な画面を作った上で、それを見ながら追加の要望を取り込むことも効率的に行える。作りかけの画面やリリースした画面を見ながら要望を検討できるので、忙しい時間を割いてくれる医師たちのストレスも軽減できただろう。

 誤解のないように申し上げるが、私は「今回の開発は、スケジュールに余裕を持って、アジャイル開発で行うべきだった」と短絡的に申し上げているわけではない。

 大切なのは、「スケジュール」や「開発方針」を含む「プロジェクト計画」を考えるときは、「ユーザーの体制」「スキル(システムや業務に関する知識)」「関与度」「現場とシステム部門の力関係」「精神状態」などを考慮した上で、「ユーザー組織の都合(システム化の目的や組織としてのデッドラインなど)」と掛け合わせて検討することが必要だということだ。

●そもそも、これはやってもよいプロジェクトだったのか

 ベンダーの多くは、最終的な納期を確認した後、類似システムの開発経験や自身の要員計画などを元にスケジュールを決め、開発するシステムのタイプに応じてアジャイルやウオーターフォールなどの開発方針を決める。しかし、そこにユーザー、特にエンドユーザーの体制や都合を色濃く反映していかないとうまくいかないことが多い。

 以前、生命保険会社のコールセンターシステム構築でプロジェクトマネジャーの役割を担ったときのことだ。要件定義工程はエンドユーザー部門の責任者だけが参加してくれればよいと当初考えていた私は、オペレータースタッフたちをプロジェクトに参加させるべきだと途中で気が付いた。

 オペレーターの参加決定後に確定したスケジュールや開発方式は、当初のものとは似ても似つかないものだった。しかしこれは、現場にしか分からない作業の詳細を理解し、オペレーターに会議に参加してもらう時間を確保するために、どうしても必要な変更だった。

 そのプロジェクトは納期を順守して完了したが、要件の優先順位は当初案とは随分と違ったものになった

 今回の旭川医大のプロジェクトがどのような状態であったのか、門外漢の私には分からない。少なくとも現場の医師の関与を大切に考えた上で、ベンダーがスケジュールや開発方針を検討していれば、惨劇は起こらなかったのではないかと考える。

 そして、そうやって作ったプロジェクト計画にユーザーがどうしても合意しないならば、そんな開発はそもそも請け負うべきではないかもしれない、とも思う。

※「旭川医大の惨劇」解説記事、その3は11月6日に掲載します(編集部)

●細川義洋

政府CIO補佐官。ITプロセスコンサルタント。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員NECソフト(現NECソリューションイノベータ)にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エムにて、システム開発・運用の品質向上を中心に、多くのITベンダーと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行う一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より政府CIO補佐官に抜てきされ、政府系機関システムのアドバイザー業務に携わる

●書籍紹介

本連載が書籍になりました!
成功するシステム開発は裁判に学べ!~契約・要件定義・検収・下請け・著作権・情報漏えいで失敗しないためのハンドブック
細川義洋著 技術評論社 2138円(税込み)
本連載、待望の書籍化。IT訴訟の専門家が難しい判例を分かりやすく読み解き、契約、要件定義、検収から、下請け、著作権、情報漏えいまで、トラブルのポイントやプロジェクト成功への実践ノウハウを丁寧に解説する。

システムを「外注」するときに読む本
細川義洋著 ダイヤモンド社 2138円(税込み)
システム開発に潜む地雷を知り尽くした「トラブル解決請負人」が、大小70以上のトラブルプロジェクトを解決に導いた経験を総動員し、失敗の本質と原因を網羅した7つのストーリーから成功のポイントを導き出す。

最終更新:11/1(水) 7:00
@IT