契約書

システム開発におけるトラブルのうち、多く見受けられるのが、契約書に関するトラブルです。
そもそも、開発自体が先行して進められてしまいがちな業界でもあることから、契約書を締結していないことも多く、トラブルが生じるまでに契約書が作成されないままになってしまっていることがあります。

また、契約書が締結されている場合でも、システム開発に関する契約内容を充実させる場合には、比較的分量の多い内容になるはずですが、できるだけ簡略な契約書の締結のみで開発を進めたいという意向から、曖昧な内容の簡易な契約書が利用されてしまっているケースも見受けられます。
さらに、契約書の内容自体は充実しているように見えても、標準的なひな形から改定しておらず、本来定めておくべき条項が含まれていない場合や、修正すべき条項が修正されないまま締結されてしまうといったことがあり、後日トラブルとなったときの対応に苦慮する場合があります。

契約書にまつわる各種のトラブルを解決に導くためには、契約締結に至る過程を踏まえて、両者の合意内容を推察し、合理的な内容になるように解釈していく必要があります。

仕様書

システム開発においては、ユーザーの要望という形がないものを、具体化して開発対象を決定していかなければなりません。
その過程においては、何を実現するのかを表現して整理した要件定義書や、どのようにそれを実現するか表現した基本設計書（外部設計、詳細設計）などの仕様書が作成されることがあります。
仕様書は、システム開発における開発の対象を明確化して特定するためにも重要な書類といえますが、作成されていれば問題ないわけではありません。

例えば、ユーザーが伝えきれなかった要望は、要件定義書には含まれることがなく、そのままシステムとして開発が進めば、要望に応えた内容が完成することはありません。
また、完成したシステムであったとしても、人が利用する限りは運用次第で、セキュリティの程度や業務効率は変わってしまいます。ベンダーからすれば、十分なシステムを用意した場合でも、運用手順書が用意されていなかったことからユーザーが十分に活用することができないようなケースもあります。

仕様変更

仕様書が作成されている場合であっても、開発の過程において、数多くの修正を加えながら、完成を目指すこともあります。
使用を変更するにあたっても、仕様書自体の修正やその内容をユーザーとベンダーが相互に共有することが重要ですが、ユーザーから口頭で指示された修正内容が反映されていないことや、担当者同士がメールでやりとりしたのみで相互の打ち合わせを記録した議事録などに記載されることなく、仕様書にも反映されないまま放置されるような場合も多くあります。

些細な修正まで、仕様書の変更を繰り返すことが煩雑ではありますが、ユーザーの要望を反映したシステムを正確に完成させるためには、仕様書の内容が明確になっていることが重要であり、仕様変更の範囲が不明瞭であると、トラブルが生じた際には法的に大きな問題としなってしまうことがあります。

手続き

こシステム開発の標準的な契約書においては、責任者の明確化、仕様書の変更や開発進行における会議の頻度、議事録の作成などについて、そのプロセスを明確化する規定を設けることがあります。

例えば、仕様書の作成後、その承認を契約において定められた責任者から得て、仕様書に記名押印を要する旨定めているような場合や、連絡協議会を開催する旨定め、相互の進捗確認やなすべき事項を協議し、議事録を作成する旨定めることもあります。

このように、標準的な契約書の中には、相互の認識の齟齬を避けるために必要なプロセスを明記し、紛争を予防するための規定が用意されていますが、この内容やその重要性が理解されないまま、順守されずに放置されてしまい、トラブルを引き起こしてしまうことがあります。

能力不足

ベンダーには、システム開発の専門家として、プロジェクトマネジメント義務があるといわれます。
プロジェクトマネジメント義務とは、納入期限に開発を完了するために進捗を管理することのほか、これを阻害する要因の発見や分析、ユーザーから提供されるべき情報を整理し要求することなど、完成に向けて必要な業務を整理し、遅延させないために必要な行動をとることを内容としています。

より具体的には、①ベンダー側の進捗状況を正確に把握すること、②ユーザー側への要求事項を整理し、進捗を踏まえて期限を区切ること、③複数の選択肢が存在する場合の比較を行いメリットとデメリットを説明すること、④ユーザーからの疑問点などに答え、問題の解決を支援すること、⑤実現不可能な要望に対しては、説明とともに拒否するなど現実的な完成に向けた進捗管理を行うことなど、状況に応じて様々な行動として求められることになります

非協力的で進捗しない

システム開発が、ユーザーのために行われる以上、その要望や要求、実現したいシステムの理想形などは、ユーザー自身の中にしか存在していません。
システム開発において作成される各種の仕様書において、ユーザーの要望が反映されていない部分を見つけられるのはユーザーだけであり、要望を反映するよう伝えることができるのもユーザーのみといえます。

そのため、システム開発は、プロジェクトマネジメント義務を負担しているベンダーとともに、ユーザーにもそれに対する協力義務があるといわれ、標準的なシステム開発の契約書にはそのことも明記されるようになってきています。

システム開発において、ユーザー自身が決定しなければ開発が進まない場面は多く、また、開発にあたって業務フローや関与する当事者、操作する場所、理想とする反応時間など、ユーザー内にしか存在しない情報が必要になる場面も多くあります。
システム開発については、ベンダーが専門家であるとしても、ユーザーが協力しないことにより進行が遅延するようなケースでは、たとえ完成時期が遅延したとしても、単純に遅延したことのみをもってベンダー側に責任が生じるとは限りません。

検査方法のギャップ

仕様書の作成が望ましいのは開発を進める場面のみではなく、検査（テスト）を行う場面にも共通すると言えます。

例えば、ユーザーとしては、システム化以前の状態よりも、業務が改善されることを期待しつつ、従前できたことができなくなることは嫌忌することがあります。しかしながら、システム化することによって、人の判断や行動で行っていたことから許容されていた融通などは、実現できなくなることがあります。
仕様書において、現状において生じる事象を正確に想定しておくことが重要ではありますが、検査時点において初めてユーザーの期待に即していない部分に直面してしまう、トラブルにつながるおそれがあります。

検査仕様書を相互で確認したうえで、どのようなレベルのシステムが完成すれば契約上の義務を果たしたといえるのかを明確にしておくことで、トラブルを回避することが可能となりますが、そのようなプロセスを経ていない場合には、完成したと判断したベンダー側と、未完成品であると判断するユーザーの対立が生じることにつながります。

処理が遅い

システム開発において、要件定義書や詳細設計などは、ユーザーの要望を実現させるために必要な機能の整理が行われていきます。
ユーザーとしては、システム化により効率的な事務処理などを期待していることから、システムの入力やその反映速度などは、人間が行うよりも早くなることを前提にしていることがあります。

一方で、ベンダーからすると、膨大な量のデータを取り扱うことを前提としたシステムであれば、たとえシステムにより処理するとしても一定の時間を要することが技術的にはやむを得ない場合があったり、処理速度の課題の解決には想定以上のスペックのハードウェアを用意しなければならず、費用が上がってしまうことなどが生じます。

ユーザー側の黙示の期待とそれに対するベンダー側の常識に大きなギャップがある場面でもあることから、トラブルの一因となりやすいのが処理速度に関する課題といえます。

権利処理

システム開発などにおいては、新たに作成するプログラムやオープンソースソフトウェアの利用など、著作権に関わる部分を契約で定めておくことも重要です。
売り切りのシステムであり、今後、再利用する予定のプログラムなども特に生じないのであれば、ベンダーとしては著作権をユーザーへ譲ることで問題ありません。しかしながら、同種のシステム開発を今後継続的に受注する可能性がある場合や、パッケージ化したソフトウェアとして販売する見込みがある場合などには、著作権を譲渡することはできないはずです。

譲渡しない場合には、ユーザーに対しては、その利用許諾を行う必要がありますが、それでユーザー側が満足するのかという課題に直面する可能性があります。

著作権などの権利処理は、契約書において行われることが通常ですが、開発前に契約書が柵瀬されていなかったがゆえに、著作権の処理についてユーザーとベンダーの間で収拾がつかなくなり、トラブルに発展することもあります。

情報漏洩とデータ消失

システムを利用する主な理由が、膨大なデータを取り扱うにあたって、人の処理によるよりも、システムによる方が正確かつ早く処理できることにあるといえます。

現代において、利用価値が高いデータの一つが個人情報であり、システム内のデータベースに個人情報が含まれないことはほとんど考え難いでしょう。
多数の個人情報をビッグデータとすることで価値を見出されている現代においては、個人情報の管理にあたってはセキュリティに関しても一定の要件を備えた安全管理措置をとることが求められるなど、個人情報保護法などによる一定のルールもあります。

反面、システムが備えるべきセキュリティに無頓着であれば、容易に情報が漏えいするシステムにもなり得るということでもあります。セキュリティが破られた時には、データベース内にある多くのデータが一斉に流出するリスクも抱えることも想定しなければならず、被害も大きくなる可能性があります。また、データ化されていることにより、そのコピーを作成することや拡散することも容易であり、被害拡大の要素は複数あり、想定以上に大きなトラブルへの発展もしやすいといえるでしょう。

また、システム内に包括的にデータが保存されていることから、誤った操作などからデータが一斉に消失するようなケースも生じるおそれがあります。そのような場合にバックアップが保存されていれば、復元も可能な場合がありますが、バックアップの保存がなされていない場合やバックアップも併せて消失した場合など、膨大なデータが一斉に消失することも、個人情報の漏えいと同様に想定以上のトラブルとなるおそれがあります。