なぜ「このシステムは使えない」は納品直前に噴き出すのか——旭川医科大学事件が示した本当の敗因

非常にしばしば結構しょっちゅういつもあるのが、「これ使えない、ちょっと直して」という追加要求だ。

「画面に項目を入れるだけ」とか「帳票の見た目を少し変えるだけ」など、「ちょっとした修正」は、いつでも、いつまでも発生する。一つ一つは小さく見えるかもしれないが、データの持ち方から考え直す必要があったり、集計ロジックに手が入ることだってある。

そして、「お客様」のために良かれと思って対応していくうちに、そんな「ちょっと」がボディブローのように効いてくる。変更管理が追いつかなくなり品質に影響が出たり、追加コストが当初見積もりを上回る。最悪の場合、スケジュールに間に合わなくなる。

「ちょっと」でも、積もればプロジェクトは破綻する。その最悪の例が、札幌高裁判決2017年の旭川医科大学事件（判例）だろう。ユーザ側は、旭川医科大学で、ベンダ側はNTT東日本などになる。

3行でまとめる。

• 病院情報管理システムの導入にあたり、既存パッケージをベースに開発を進めた
• 契約後、仕様変更が噴出したため、ユーザ・ベンダ合意の下、スケジュールの見直しと要件の再整理、仕様凍結を行った
• その後も追加要望が止まらず、現行システムのマスタ抽出をめぐってプロジェクトが頓挫し、訴訟となった

それぞれの主張をまとめると、こうなる。

ベンダ側の主張

• 前提は、パッケージをベースに、一部をカスタマイズするもの
• しかしユーザ側は、契約後に大量の追加要望を出してきた
• 追加の多くは開発対象外であり、対応すれば納期に間に合わない
• ユーザの要望に応じて、追加の625項目を受け入れる代わりに、スケジュール変更と仕様凍結合意を取り付けた
• それにもかかわらず、さらに171項目、追加要望を出してきた
• 現行システムのマスタ抽出や、現行システムの情報提供も不十分だった
• そのため、プロジェクトが頓挫した

つまり、追加要望のリスクを警告し、受け入れる範囲を決め、仕様凍結まで合意した。それを破ってプロジェクトを止めたのは、ユーザの責任だという主張だ。

ユーザ側の主張

• 仕様凍結後の171項目は、開発対象外の追加要望ではない
• それらは、未確定だった画面・帳票・操作性の確認や、不具合の指摘だ
• それらは、業務に適合させるために、当然必要なカスタマイズだ
• その対応を拒否したため、ベンダは完成義務を果たしていない

まとめると、仕様凍結の時点で、画面や帳票で確定していないものがあり、業務に適合していないものは不具合のため、修正するのは当然だという主張だ。

要件の追加 vs. 業務不適合

両者の主張を煮詰めると、「これは要件の追加である」vs.「いいえ、業務に合わないので不具合だ」という構造だ。請求額はユーザは19億円、ベンダは22億円という巨額の訴訟だが、この応酬は非常にしばしばしょっちゅうよくある。

通常なら、最初から詳細を細かく決められないため、「画面イメージ」「帳票イメージ」といった形で合意する。そしてプロジェクトが進み、実際に画面や帳票が確認できる時点―――テストや検収の段階で、現場から「使えないから、ちょっと直して」という声が出てくる。

モックやプロトタイプで触ってもらうという対策もあるが、全ての画面や帳票を試作するわけではない。その結果、プロジェクトの終盤のときに、「業務不適合による不具合」という理由で変更を強要される。

ユーザからすると「これくらい直してよ！」だし、ベンダにとっては「今さら言ってくるな」になる。だが、「このままだと使えない」というセリフの効果は抜群で、泣く泣く対応するのが常だった。

しかし、ものには限度というものがある。

裁判所は、ユーザ側の主張を退ける。

ベンダ側は、専門部会の場においても、「追加要望の多くは仕様外のもの」「対応するのは難しく」「（開始日に）間に合わなくなる」と明確に警告を発していた。

さらに、「このままだと業務に適合しない」というユーザの要望に適合させるため、625項目の要望追加とスケジュール変更、仕様凍結を行った。

裁判所はこれを、「新たな機能の開発要望はもちろん、画面や帳票、操作性に関わるものも含め、一切の追加開発要望を出さないとの合意」に相当すると見なしている。

そして、仕様凍結した6486項目のうち、未完了なのは1項目のみで、それもユーザの協力が得られず保留したことによる。システムは、ほぼ完成していたと裁判所は認定している。

これに加えて、マスタ抽出義務を怠ったこと、現行システム情報を十分に提供しなかったこと等を重視して、ユーザの協力義務違反と判断し、ユーザ請求を棄却、ベンダ請求を14億円の範囲で認めることになる。

おそらく、ユーザ側は「全部が決まってないなら、不具合の指摘として後から修正できる」なんて、本気で信じてる訳でもなかろう。訴訟になった以上、171項目を「追加要望」としてしまうと、敗色濃厚となってしまう。だから「不具合の指摘」と位置付けざるを得なかったと考える。客観的に見ると苦しいが、訴訟では持てるカードで戦うしかないのだから。

後になって「使えない」と言われる理由

この事件を「ユーザが仕様凍結を破った」とだけ読むと、教訓を取り逃がす。問題は、なぜ仕様凍結後に、これほど大量の「使えない」が噴き出したのかである。

別に、ユーザ側も意地悪で言っているわけではない。「このままだと使えないシステムになる」という危機感があり、現場からの強い要望があったため、不具合という言い方になっていると考える。

ただ、なぜその強い要望が、後になって噴出したのか

前段として、スケジュールが必達ではなかったという事情がある。ユーザ側は、仮に運用開始日が当初予定から変更されても、「現行システムの使用を継続すれば足りることであって、開発対象を絞ってまで本件システムの運用開始を早めなければならない事情はなかった」と主張している。これは本音に近いだろう。

むしろ、納期を守るために要件を削る方にリスクを感じていたと推察される。総合病院の情報システムだから、現場の医師、看護師、薬剤師、専門技師、会計事務という、様々な立場の人々が利用する。現場の人にとって使えないものを入れたら、単なる効率低下では収まらず、医療サービスの安全性の低下ひいては人命にまで関わるかもしれない。

だから、多少遅れても現行システムを使えば済むし、むしろ変なものを入れて現場が混乱することを避けたい、と考えた可能性がある。

さらに、仕様検討に関わったメンバー選定にも問題がある。この紛争の根本的な原因として、判決では以下のように認定されている。

• 現行システムに固執する現場の医師らの要望を十分に反映させないまま要求仕様書等を取りまとめて本件契約を締結した
• その後、現場の医師らの追加開発要望を抑えるための努力を放棄した
• 仕様凍結の意味について、現場の医師らには、そのような認識が必ずしも浸透していなかった

ここからは私の推測だが、仕様検討の段階で、現場の意見を集約して要件にまとめあげる仕組みが不十分だったのではなかろうか。

仕様検討の場では、大量のドキュメントを広げ、皆で巨大なディスプレイを見ながら、「現行システムはどうなっているか」「新システムは何が必要か」を検討・取捨選択する必要がある。

会議の拘束時間もあるだろうし、確認すべきドキュメントも多岐にわたる。病院の現場だから、ただでさえ多忙だ。そんな中で、ドキュメントを読み込み、会議に参加し、要件を提示することなど、至難の業だろう。

「使えるか」を判断できる現場の人は、要件定義の段階から参加してもらう必要がある。ただし、名前だけ参加者に入れて通常業務の片手間でレビューを頼んでも機能しない。曜日や時間帯を決めて、「現場の人がレビューアーが入っていること」を前提とした会議体にするといった工夫が必要だ。

そうした考慮をしないまま「仕様凍結」して突き進んだ結果だといえる。

現場からの「使えない」という声そのものは正しい場合が多い。だが、これは魔法の言葉ではない。重要なのは、その声が届くタイミングとコントロールだ。仕様凍結後もその声を活かすなら、リリースを刻むなどの変更管理が必要になる。次に「使えない」を耳にしたときは、14億円の判決を思い出そう。