業務を委託するときに契約が必要なのは当然ですが、情報システムの開発では、無形のソフトウェアが取引対象ですし、仕様が変化する特質をもつため、一般の委託契約と比較して、多様な問題点があります。
製品がわかりにくい
通常の製品やサービスと比較して、情報システムは「わかりくい」ものです。
- 単に「売上管理システム」といっても、数万円のパソコン用パッケージもあるし、独自システムを構築するのに数千万円かかることもあります。ＩＴに詳しくない人にとって、その効用の違いを明確に理解するのは、かなり困難です。
- 一般に商品やサービスは、原価から価格を決定するのではなく、それによる効用で価格が決まるのが通常です。ところが、独自に情報システムを構築する取引では、まだこのような価格設定方法は確立していません。それで、価格の妥当性について、発注者と受注者の間での折衝になりますが、受注者はその根拠を示す能力がなく、発注者はそれを評価する能力がない場合もあります。
不確実要因が多い
情報システムの構築では、要件定義から稼働までに多くの工程がありますが、当初の要件定義の段階では不確定な要素が多いのが通常です。
- 発注者が、開発する情報システムの要件を明確に示さなければならないのに、発注者の能力不足や対象業務が複雑なために、適切に示すことができず、不十分な要求仕様のまま、開発契約が締結されることが多くあります。→参照：「要求フェーズでの苦情」
当初の段階で全体の契約をすると、開発途中で新しい要件が追加されたり、要件の変更が生じて、契約した費用、納期、品質（機能）と大きな違いが発生することが多いのです。変更の都度、どちらが負担すべきかを明確にすればよいのですが、発注者と受注者の間で見解が異なることが多くあります。しかも、変更が口頭により行われ、文書化されていないために、証拠がなく、負担をめぐってトラブルが生じることが多いのです。→参照：「２４２３の法則」
- 受注者側の税務基準が変わりました。従来は完成時に一括して収入を計上する「工事完成基準」がとられていましたが、２００９年から、各決算時においてそれまでにかかった費用と売上をその都度計上する「工事進行基準」も認められるようになりました。この基準では工事の進捗度管理が重要になります。このとき受注者と発注者の間で大きな認識の違いがあるのでは困ります。
- システムの構築では、すべてを新規に構築する、ＥＲＰパッケージなど市販のソフトウェアを利用する、既存のモジュールを組み合わせるなど、多様な実現方法がありますが、その選択により、費用、納期、品質に差が生じます。この選択には、受注者の技術や知識に左右されますし、発注者の理解度も影響します。
- 技術進歩が急速です。新しいハードウェアやソフトウェアを想定して開発を行うとき、それらが期待した機能が発揮できないことがトラブルの原因になることもあります。
責任が不明確のことがある
情報システムの構築では、多数の関係者が参加するため、責任の所在があいまいになり、それをめぐるトラブルが発生することがあります。
- 要件定義、コードの設定、入出力画面・帳票のデザイン設計、納入テストなど発注者自身が行う作業があります（参照：「システム開発での利用部門の任務」）が、契約時に何をどの程度まで行うのかが明確になっていないと、その作業の遅延や不適切なことが原因で、プロジェクトに大きな影響を与えることがあります。
- 第三者のハードウェアやソフトウェアが原因の場合、発注者と受注者のどちらが負担するのかが問題になります。
- 情報システムの構築では、ソフトウェア開発、ネットワーク、データベースなど多くのベンダが参画します。それらは互いに複雑に影響しています。発注者が多数のベンダと個別に契約してトラブルが発生したとき、どのベンダが当事者なのかを判別することが困難なことがあります。
- 逆に、システムインテグレータなどに一括契約する場合には、多段階の下請発注が行われることがあります。下請によるトラブルは元請の責任ですが、発注者の機密情報を知られたくない下請がいたのでは発注者として困ります。また、元請の責任だとはいえ、実際に被害を被るのは発注者です。発注者が下請の是非まで承認するかどうかを契約で明示しておく必要があります。
機密情報保護
- 情報システムを実装するときには、受注者が個人情報や機密情報が含まれている実データを取り扱うことがあります。情報システムによっては、その対象や処理方法が機密になるものもあります。そのため、契約に機密保護に関する条項が必要です。特に多段階下請をするときには、末端の作業者にまで、徹底させることが必要です。
著作権帰属をめぐるトラブル
著作権法では、特段の取り決めがない場合は、受注者が作成したプログラムや文書の著作権は受注者に帰属します。しかし、それでは不都合が発生することがあります。→参照：「著作権の帰属」
- 発注者がこのシステムを第三者に販売あるいは譲渡することができなくなります。また、発注者が、その後の利用環境の変化により、改訂を行う必要が生じたときに、受注者に無断で改訂することができなくなるおそれがあります。
- 逆に、契約で著作権を発注者に帰属させると、受注者がその後同じような情報システムを開発するとき、類似したプログラムを作ることができなくなります。現実の開発では、既に受注者がもっている部品を再利用することにより、生産性を向上させています。これができなくなることは、ＩＴの発展を阻害することにもなります。
近年では、情報システムが大規模になり取引金額が大きくなったこと、経営に与える影響が大きく損害額が高額になってきたこと、情報システムが複雑になり責任の所在がわかりにくくなってきたことなどにより、裁判にまで発展することが多くなってきました。
このような事態を回避するためにも、システム開発の契約にあたっては、一般的な契約よりも、慎重な取り組みが必要になります。
多くの契約書には「本契約書に記載なき事項は、契約当事者は双方誠意を持って協議を行う」という条項を入れていますが、その「誠意ある協議」をしても解決できないので、トラブルになるのです。できる限り、「どのようなときには、どちらの責任とする」かを契約書に明記しておくこと、想定外の問題が発生したときには、早期に「誠意ある協議」を実施し、文書化して契約書の改定を行うことが必要です。