なぜユーザーはITも業務も詳しくないベンダーへ発注するのか

世の中にITシステムの開発案件は星の数ほどありますが、これほど数が多いと、「なぜこのようなことになってしまったのか」と唖然としてしまう案件も中にはあります。なかでも、発注した自分たち自身がシステムの要件を理解していなかったというケースは、比較的悲惨な結果に陥りやすいですね。

以下は経産省のモデルケースで取り上げられていた事例です。

【トラブル内容】
本件の自治体（ユーザー）では、水道料金収納システムを地元のITベンダに全面的に任せていた。同システムのリニューアルにあたって、同自治体が主導権を握って進めて、費用も低減することとした。まず、同自治体の関連団体であるサービス会社（委託者）に発注し、委託者が受託者に開発を委託することになった。

ところが、委託者には、IT技術の専門家も水道課の業務に詳しい者もいなかった上、受託者は他県の企業で同自治体関係の開発は初めてであったため、仕様策定が難航した。自治体は、水道課担当職員を会議に出席させるなどしたが、意思疎通が十分にできなかった。結局、開発されたシステムには不具合が多く、納期を6カ月延期しても完成に至らなかった。

【ユーザー委託を受けた業者（委託者）の主張】
委託者はシステム開発に必要な仕様を明確にしなかったし、窓口端末の閲覧、借用もできなかった。情報提供も不十分だった。

【受託した業者（ベンダー）の主張】
開発期限を6カ月延長したのに、システムが完成しなかった。

このケースは現在係争中であり、まだ判決は出ていません。しかし、状況内容から得られる示唆はあります。

本件はオープンソースの地理情報システム用ソフトウェアをベースに、水道料金収受システムを開発する計画であったそうです。そのため、ユーザーは、このソフトウェアに詳しいという点を評価してベンダーを選定しました。

選定されたベンダーは他県自治体での実績はあるものの、この自治体のシステムは初めてであり、ユーザー側からの積極的な情報提供が必要であることは当初から分かっていたことでしたが、そのための体制をユーザー側が構築できませんでした。加えて、ユーザが長年にわたって使っていた水道料金収受の従来システムに仕様書は存在せず、ユーザの担当者は利用方法のみを知っているにすぎなかったとのこと。

このような情報不足がある上に、自治体自体がシステム開発に不慣れであれば、「プロジェクト全体を統括するコンサルタントを導入する方法もあり得た」というのが有識者の見解ですが、そのような施策は採られていませんでした。

全体の雰囲気からすると、特許庁のシステム開発頓挫の話に似ていますね。実際、ITシステムを単なるツールと割り切っている組織は官公庁・自治体には多く、職員もシステムの仕組みに興味はありませんから、構築ベンダーの好き勝手になっているという状況が割と見受けられます。

こうした組織では、システム更改に伴うシステム要件の洗い出しが難航する傾向にあります。それだけで済めばまだマシ。今回のケースや前述の特許庁のような、業務要件さえ明確ではなかったということもしばしばあり、これではベンダーはリスクへの備え（コンティンジェンシー）を積み増すばかりです。

その結果が不透明で割高なサービス契約に行き着くことは想像に難くありません。事実、そうした組織との折衝に慣れているNTTデータ社は、データ・通信・サービス契約というどんぶり勘定契約で官公庁・自治体のITシステムを支えています。

ベンダーに対する正当な見積りを要求するには、まずユーザー自身が正当な自己責任を果たすことが肝要です。「ITのことはITベンダーに任せておいて、ユーザーは業務に集中すればよい」との意見を主張するユーザーもいますが、自システムの仕様が不明瞭であること自体、業務が明確になっていないも同然ではないでしょうか。

ユーザ「メインシステムが更改したからサブシステムは無償改修しろ、イヤなら改修費用を代わりに払え」 ベンダ「！？」

以前のエントリーで、モンスターペアレントならぬ、モンスターユーザーの話を取り上げましたが、他にもユーザーとベンダーのいさかいに関するエピソードはたくさんあります。興味深い事例は経産省がモデルケースとして取り上げられているので、そこから一例を紹介しましょう。

【トラブル内容】
問題となったのは会計処理システムで、システムはメインパッケージと、ユーザ向けにカスタマイズされたサブシステムに分かれていた。メインパッケージは、被告ベンダとは別のZ社が使用許諾権を有し、サブシステムは被告ベンダが有していた。ユーザは、Z社と被告ベンダとそれぞれ使用許諾契約を結んだ。Z社がメインパッケージの2000年問題対応の無償バージョンアップを行ったため、バージョンアップに伴うサブシステムの補修が必要となった。被告ベンダは補修対応費用として1400万円の見積もりを提出したが、ユーザが支払いをしないと主張したため、見積もりを撤回し補修に応じなかった。ユーザが被告ベンダに補修作業費用相当額として1400万円を請求した。

【ユーザーの主張】
ユーザと被告ベンダ間の使用許諾契約は、全体として統合された会計処理システムを構築する義務を負っており、メインパッケージのバージョンアップにあわせてサブシステムを補修する義務を負っている。さらに、保守契約が成立しており、被告ベンダは補修する義務を負っていた。

さて問題です。このユーザーの主張は裁判所に認められたでしょうか？

答えはNOです。裁判所は、ユーザはメインパッケージについてZ社と別途契約を締結していることなどから、被告ベンダは会計処理システム全体について責任を負うということはないと判示し、変更後のメインパッケージにサブシステムを適用させる義務はないとしました。

そもそも、保守契約については、ユーザと被告ベンダ間に結ばれていなかったそうです。いくらなんでも無茶苦茶だな、と思ってしまいますよね。ユーザー企業は、この状態でよくも裁判を起こそうと考えたものだと思ってしまいます。

しかし、もしこのトラブルの内容が、「ユーザーの無知に付け込んで不当な工数費用を請求していた」という事情に基づいていたなら、ユーザーの主張は部分的に認められていた可能性がありますし、非難されるべきはベンダー側ということになります。

つまり、このケースから得られる示唆は、開発契約の際に、被告ベンダの業務範囲（パッケージ側のバージョンアップ作業に対応するサブシステム側の補修作業を行う責任（＝システム全体についての責任）を負うか）や費用負担（補修作業を行う場合の費用（有償／無償）の扱い）などを明確にしておくべきであった、ということです。

あなたがシステム開発契約に携わるときには、くれぐれもシステム稼働後の保守フェーズにおける責任分界だけは最初にハッキリさせておくことをお勧めします。