ユーザーからシステムの開発を依頼され、厳しい納期の中着手したのに突然システムが不要になったと言われたり、契約もなかったと言われたりするトラブルがあります。
プロジェクトのスタート時に実施するキックオフミーティングの議事録にユーザーの捺印がある事案の過去の判例では、ユーザー側の責任者が出席していなかったことや有償の作業だという認識がユーザー側になかったことで、契約の成立は否定されました。
このようにトラブルが発生しないためにも、契約は書面に残すことが重要になると言えるでしょう。

口約束で契約は成立しない？

民法では口約束でも契約は成立するとされていますが、契約書がなければもし裁判になった時に契約成立は認められないケースが多々あります。
しかし民法には契約締結上の過失という理論があり、契約締結がされていなかったとしても締結されることを期待させて裏切った場合、その期待を保護しようという理論が存在します。
そのため契約締結前に受注側が何らかの準備作業を行うのであれば、双方が契約締結は確実ではなく、作業も無償であることを認識しておく必要があります。

受注側のプロジェクトマネジメントは義務

システム開発会社にプロジェクトに対するマネジメント能力が不足していれば、そのプロジェクトはなかなか進みません。
過去の判例でも受注側のプロジェクトマネジメント義務の存在を認めるなど、極めて重要な項目になると考えられます。

ユーザー側は仕様を決定する必要がある

反対にユーザー側はシステムがわからないから、全てをシステム開発会社に任せれば良いと思うかもしれません。
しかしユーザー側にも仕様を決定する義務がありますので、どのようなシステムを作って何を実現させたいかという方針や戦略、仕様を決めることが必要です。
しかし実際は仕様を決める作業が困難という可能性もありますので、システム開発会社側は適切な仕様を決定できるように促しながら教育していくことになるでしょう。

開発漏れか仕様の追加かによるトラブル

ユーザーから希望した仕様でない、もしくはバグの修正など、様々な要望が出ることがあります。
しかしそれは開発漏れによるものなのか、それとも仕様が追加されたのかの判断でトラブルになることがあります。
そのため開発対象や仕様の定めを文書にしておくことが必要です。過去の判例でも契約時の仕様書をもとにして開発範囲を判断したケースがあります。

契約内容などは必ず文書化しておくこと

システムの開発上で起きるトラブルは様々で、先に述べたケースはほんの一例です。トラブルを防ぐためにも、実態に合わせた契約書の作成、さらに仕様についても文書にしておくが必要です。