定形外業務も自主的に調べるのがベンダーの努めです：「訴えてやる！」の前に読む IT訴訟 徹底解説（14）（1/2 ページ）

連載目次

　IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。前回と前々回は、「ユーザーのシステム導入担当者に、自社の業務に関する知識がなかったために発生した紛争」について解説した。自社の業務プロセスや経理の勘定項目について、ほとんど知識がないユーザーを相手に要件定義を行わざるを得なかったベンダーの苦労はいかばかりだったか、と同情に堪えない。

　このように業務知識の不足によってシステム開発が失敗する例は少なくない。私が裁判所で目にする紛争の半数以上が、こうした知識不足が原因と言ってもよいくらいだ。

　ただし、前回までの例のような「ユーザーの知識不足」によるトラブルは少数であり、大多数のトラブルは、ベンダーの知識不足によって起こっている。

　門外漢のITエンジニアが、ごく短期間に詰め込んだ業務知識で、満足のいくシステムを作ることは、至難の業だ。実際、検収時やリリース後に、ユーザーから「これでは使えない」とクレームを受ける例が本当に多い。

　それでも紙に書かれていて、誰もが理解できる業務プロセスについてであれば、ベンダーも反省のしようがある。しかし、ユーザーから提示された資料のどこを見てもそのような業務手順が書かれていない「定型外処理」への対応不足が原因となるものが、かなりある。

　今回はその典型例を基に解説しよう。まずは、判例から見ていただきたい。

定型外業務に関する裁判の例

　筆者は長年システムエンジニアとしてソフトウエアの開発に携わってきたが、オペレーターにサーバー上のデータベースを直接操作させることは、通常はないのではないだろうか。読者も同じような疑問を持つと思う。

　なぜなら、専門家ではないオペレーターに直接データを触らせるのは危険だからだ。また、排他制御の問題もある。この判例のソフトウエアのような処理は「常識外」であり、要件定義や設計を担当したベンダーのエンジニアがその必要性に気付かなかったとしても、正直致し方ないことと考えられる。

　ましてや本件の場合、契約内容に「遠隔操作機能」なるものは記載されていなかった。業界の人間ではないエンジニアが、これを要件として定義するのは至難の業と言ってよいだろう。

　筆者は本連載や著書などで、「要件定義はシステム化の目的を考慮して……」とか、「業務プロセスとその改善点を理解して……」といったベンダーに必要な心掛けを何度も述べてきた。しかし現実はもっと過酷だ。上記の心掛け程度では、本判例の事故は防げなかっただろう。

　確かにソフトウエアはユーザーの業務に耐えないものかもしれない。しかし「ベンダーにできることには、限りがあるのではないか」というのが、筆者の正直な感想だ。