要件通りに作っても、ITベンダが裁判で負けることについて

これで裁判負けるなら、ITベンダーなんてやっとられん、そこまで言うなら、ユーザーさん、自分で全部作ってくださいな。。。そんなことを言いたくなるようなIT裁判が広島地方裁判所でありました。詳しくは、連載「訴えてやるの前に読む、IT訴訟徹底解説」の記事を読んで頂きたいのですが。。。

簡単に申し上げるなら、自社の基幹システム構築をITベンダーに頼んだら、出来上がってきたシステムは、使い勝手が悪い。でも、それって実はユーザー側が要件として定義していなかったという問題です。

問題となったシステムは、廃棄物の収集処理業者つまり、ゴミ屋さんの売上や請求を管理するシステムなのですが、とりあえずベンダーが作り上げて、納品したところ、以下のような不満がユーザーから噴出したってことです。

・操作者がある項目に入力する作業コードを検索する際、画面に6件しか表示しない。実際の作業コードは数百件以上と膨大にあり、目的のコードを見つけるまでに50回程度画面を切り替えなければならず、実用的ではない。

・顧客企業に対して自動振替での入金を請求する際、このシステムの請求では「口座振替一覧表」を表示する仕様となっているが、画面には相手方口座の名義人、口座番号、銀行支店名などを表示するだけで、振替金額、振替日などの情報が含まれないので、実質的に取引銀行に対し口座振替を依頼することができない。

それはまあ、こういう問題があれば、システムは使いにくいでしょう。私だってきっと文句を言うと思います。ただ、ベンダーはユーザーの作成した要件定義書に従って、開発を行いました。前述したような要件なんてものは、定義書のどこにも書かれていなかったのです。

ベンダーは、そもそも、この廃棄物処理業者の仕事のことは知りませんから、ユーザーに言われたことはきちんとやるけど、言われてなければやらないわけです。なので、上に挙げたような不具合も、ベンダーは、それが問題になるのかどうかも分からなかった。とにかく要件に従ってモノは作りましたという状態だったわけです。

ところがユーザーとしては、システムが使い物にならない、こんなシステムを作ったベンダーは許せん！ということで裁判になりました。

さて、この裁判、どっちが勝ったのか、それは連載記事の方で読んで頂くこととして、ここでは、その判断のポイントとなったことだけお話しておきます。

この裁判のポイントは、ずばり、契約書に書かれていた「契約の目的」です。技術者の方は普段、あまり見ないかもしれませんが、IT開発であっても契約書には、この契約を結ぶ目的というモノが書かれています。そしてIT裁判の場合、ベンダーが作ったものが、「目的」に合致しているか、資するものかということがしばしば問題になります。

つまり、システムの要件は、この目的に合致したものである必要があり、逆に要件に書かれていないことでも、目的を達成する為に必要な機能や性能は実現されなければならない、という考えです。

んなん、書かれてもいないもん、しらんがな！とベンダーさんなら思うでしょう。でもユーザーから見ると、システムの要件を漏れなく全て書ききるなんて無理！こちらは素人なんだし、それはベンダーさんが業務の勉強もして提案してよ、プロなんでしょ？となります。

さて、この裁判、どちらに転んだでしょうか。まあ、どちらが勝ったにせよ、ベンダーが契約の目的を知りませんと考えていると、こういう裁判になってしまうんだということだけは覚えておいて良いかもしれませんね。

「訴えてやるの前に読む、IT訴訟徹底解説　第88回　私が決めた要件通りにシステムを作ってもらいましたが、使えないので訴えます」より

　第
ユーザー企業がこのシステムを導入する目的として契約書などに記述したのは、「顧客サービスの強化と営業活動支援資料の迅速な作成と分析、売掛請求の迅速な請求書の発行と請求および記帳の合理化、経営管理資料の迅速な作成と分析」などである。前述の2つの問題を見ると、「2」は直接的に、「1」も間接的に、請求の迅速化、合理化という目的に逆行する仕様である。　無論、これらはシステムのバグではない。　詳細な仕様が、現実の業務や目的とズレていたのである。つまり要件定義の不備に他ならない。通常であれば、このような不備は要件定義の主体であるユーザー企業の責である。しかし、前述した通り、このプロジェクトではベンダーが要件定義をサポートしている。

　「システムの操作者というものは、画面を50回も切り替えないものです。条件検索を入れるなどして一発で必要コードを見つけられるようにしましょう」「銀行に自動振替を依頼するなら、これでは情報が足りません」といったアドバイスが専門家として必要だったということだろう。ユーザー企業の主張も、おおよそそうしたものだったと考えられる。

この裁判所の判断はかなり思い切ったものではないかと思う。前述した通り、システムの要件定義は通常、ユーザーが責任を持って行うものであり、このプロジェクトにおいてもベンダーは「サポートするのみ」と決まっていた。

結局のところ、契約の目的も、システムを利用する人間のスキルや業務の流れや悩みも、一番よく知っているのはユーザー企業自身のはずだ。裁判所のいう専門技術的見地など持ち合わせていなくても、この程度の要件を定めることはユーザーだけで十分にできたのではないかというのが正直な感想ではある。

　だが、裁判所の判断は上記の通りだ。「専門技術的見地」とは、導入したシステムを使ったら、操作者がどのように困り、生産性を落とすのかまで考慮する、という一種の想像力も含まれると考えた方がいいのかもしれない。

今回の裁判は、「ベンダーの専門性」というものが、ベンダーが考えるよりも広く捉えられる可能性があることを示しているように思う。ここでいう専門性とは、特に要件定義をサポートするような場合は、プログラムやサーバ、ネットワークのことだけでなく、システムの使い勝手や、それを使った業務の流れをイメージできることでもある。そして、そうして実現した業務の姿が、その先にある「契約の目的」の達成に資するものであるのか、そうした物差しもベンダーは持っていなければいけない。

　例えるならば、家を建てるとき、施主が1階の部屋を広くしたいから階段の傾斜をきつくしようと言い出しても、建築家は「そんなに急な階段を作ったら、年をとったときに困りますよ」と進言して思いとどまらせる。そんなことが専門家には必要だということではあるまいか。

　随分と専門性を広く捉えているように思われるかもしれないし、私の中にも、そうした思いはある。ただ、翻って考えてみると、今後のITエンジニアにはそうしたスキルこそが必要となるのかもしれない。

クラウドコンピューティングの流行やいわゆるローコードツールやRPA（Robotic Process Automation）などの普及が進むと、ITエンジニアが専門性を発揮する場が徐々に少なくなってくる。ベンダーがモノづくりをしなくても、ユーザー自身が自分の望むシステムを作れてしまう時代が、徐々にではあるがやってきている。

　そうしたときにベンダーは、細かいモノづくりよりも自分たちが得意とする業務ソフトウェアやサービスを武器に、ユーザーの業務を変えることをミッションとすることが多くなってくるだろう。単なるシステムづくりではなく、DX（デジタルトランスフォーメーション）を実現するための技術者としてこれからの時代を生き抜く、そのように頭を切り替えることが必須かもしれない。

　そうしたとき、この判決が求めるような、ユーザーの目的を理解し、それを達成する業務の姿をイメージした上で要件を定義していく高度なスキルは、私にとっても読者の皆さんにとっても、とても重要な武器になるだろう。