IT導入・システム開発を終わらせたいが、契約上の終わりがないので終われない

IT導入・システム開発において、依頼すれば終わりが必ずあると思われますが、終わらないといことが稀にあります。

終わらないということは完成してない、ということですので、完成によって得られるはずの利益が得られないということになります。

そればかりでなく、依頼した金額がどうなるか怪しくなってくることもあります。依頼したにも関わらず、また完成に至るまでの道筋の中でそれ相応の労力をかけてきたにも関わらず、終わらないどころか、発注金額も回収できない、ということもあり得るということです。

完成に近づいている段階においても、契約面での問題で、トラブルになってしまうことがあります。
そもそも終わりとは何なのか、支払いについての取り決め等、はっきりしておらず、後から揉めてしまうことがあります。

IT導入・システム開発にてＳＥＳ契約であれば完成しなくてもよいか

ＳＥＳ契約というものがＩＴ業界ではあります。

ＳＥやプログラマが客先に常駐し、特に完成物を定義していなくても、期間と単金で契約し、その都度発生する業務をこなす、という契約となっています。
いわゆる法律上は準委任になりますが、ＩＴ業界においてはよくＳＥＳ契約という言葉が使われます。

小売店チェーンにてＰＯＳシステムの改修をベンダーに依頼しました。ベンダーにおいては、システム全体像を把握しきれていないため、ＳＥＳ契約にしてほしいとのことでしたが、発注側企業においては、準委任は予算上認められない、とのことで請負にさせてほしいと逆に要望が出て、結果的には請負で契約することとなりました。

システムの改修は進み、最終確認段階である受入テスト段階になりました。

小売店チェーンの担当者がテストを実施してみると、様々な不具合が発生しました。今回の改修箇所だけでなく、周辺機能とのやりとりをテストしていく中で、不具合が多く検出されました。

発注側としては、不具合が出ているため検収できないとし、不具合対処が完了するまでは契約範囲であると主張しました。

受注側のベンダーのほうは、もともとＳＥＳ契約を要望しており、形式上請負にした、ということを主張しましたが、契約が結果的に請負になっていることから、発注側としては請負としての完成責任を果たすことを要求しました。

受注側のベンダーとしては、改修範囲以外の仕様に影響する部分でもあるため、自分に責任はないと主張し、結果、プロジェクトが一旦停止となりました。
結果としては、発注側企業は追加費用を払うこととなりました。
契約上が請負だったとしても、見積方法がＳＥＳベースとなっており、実質はＳＥＳであると認められたことになります。

この結果はもっともであり、発注側がやや強引だったかもしれません。しかし、実務現場ではよく起こりうることです。

もう少し仕様が明確になってから請負で発注する、といったことをやっておくことで、完成しなかったり、余計な費用がかかったりといったことを回避できるでしょう。

IT導入・システム開発において完成を明確にすることの重要さ

IT導入・システム開発が完成している、していない、で当事者間で揉め事が起きることができるだけ避けたいです。したがって要件定義を明確にする、ということが非常に重要です。実現すべき機能の要件以外にも非機能要件と呼ばれるものがありますが、できる限り明確にし、完成基準としたいところです。

製造業で工場間の進捗把握をするシステムを企画し、ITベンダーに依頼し構築することとしました。
工場間でリアルに状況を把握することで、各工場での生産量の調整もリアルにできるということを狙ったものです。

このシステム開発プロジェクトは機能的な確認は完了し、最終段階での運用テストを行っていました。すると、問題が発覚しました。

処理性能が低く、期待する運用に耐えられないというものでした。
ほぼ完成していたため、処理性能の問題は大きな問題となりました。

受注側のベンダーとしては、システムは完成していると主張しました。しかし、発注側企業においては、性能が出ていない以上、完成はしていないということで、主張がかみ合わず、プロジェクトが頓挫しました。

この争いは結果としては、発注側の主張が通りました。

非機能要件として処理性能が明確になっていなかったものの、実現したいシステムは明確であること、またITベンダーはプロとして実現方法を問題発覚時点で提示できるはずだということでした。

このケースにおいては、受注側はプロだから、ということで片付いていましたが、本来完成基準が明確になった契約をすべきです。

IT導入において、完成していないので支払いを遅らせたが、実際は終わっていた

製造業にて基幹システムの導入を検討し、ITベンダーに依頼することとなりました。

ITベンダーがパッケージソフト導入を提案し、それに乗っかる形で、この製造業のIT導入プロジェクトはスタートしました。

プロジェクトを進めていく中で、テスト段階で様々な業務運用上の不具合が発見されました。
発注側としては、不具合であるため、改修を受注側ベンダーに求めました。しかし、ベンダーは契約範囲ではない、ということで追加改修は実施しませんでした。

発注側は、追加改修はもともと発注している範囲であると主張し、これまでのプロジェクト費用の支払いを拒否し遅延させました。

発注側と受注側は双方主張がかみ合わず、プロジェクトは一旦頓挫しました。

当然請負発注したものが完成していないのであれば、支払う必要もないし、完成と言える段階まで進めてもらわないといけません。しかしこの場合はどうだったのでしょうか。

結果としては、受注側のベンダー主張が正しいということなりました。

契約においてパッケージを導入することになっていました。本来実施しておけばよかったパッケージソフトと業務とのフィット＆ギャップがなされておらず、ギャップについて改修するのか、業務を変えるのかが不明確ではあったものの、パッケージの業務をベースとして導入することを合意する議事録が残っていました。

これにより、追加改修は契約の範囲ではない、という解釈となり、費用が支払われないのは問題となりました。

まとめ

IT導入・システム開発は契約にて開始し、契約にて終わるというのが通常ではありますが、契約が不明確であったり、契約はしているが実態がその通りになっていなかったりして、普通に終わることができないという問題が起き得ます。

契約は何をもって完了とするかを明確にすべきです。そのために不明確点があるのであれば、要件定義をまずは行い、実行契約に移すというほうがよいでしょう。

ＳＥＳといった準委任で対応するというやり方もありますが、契約上何も遺恨を残さないものではありません。そこにいた（であろう）時間にて精算します、というのですから、まさに完成基準はありません。
発注側からすると、不利に思えます。しかし、法律上もそのあたりは加味されており、善管注意義務というものがあります。受注側はプロとして受注しているわけですから、それ相応の管理がなされて当然であるということです。

しかし、その管理というものもあいまいと言えばあいまいです。処理性能がでるような設計といった専門的な作業において、管理できているかどうかの判断が難しくなるケースもあるでしょう。

そこでさらに要求レベルを上げるには、準委任であっても成果物を課すことも可能です。契約上それ相応の成果物を求めることで、作業が完成しないことのリスクを回避することができます。

契約という基本的な行為ではありますが、準備を入念に行うことでリスクを軽減・回避することができるでしょう。