システム開発の受注から納品までの流れと注意点

m2m

 ユーザー企業がシステム開発を外部のベンダー企業に依頼する場合、契約内容に不備があるとトラブルになり注意が必要です。例えば、要件定義が曖昧な状態で請負契約を締結した場合、途中で要件追加や仕様変更があると、工数が足りなくなり完成できないリスクが増します。それでは、これらを避けるには、どのようなことに注意すべきでしょうか。本稿では、受注から納品までの工程の流れを説明し、契約と著作権に関する事項を中心に注意点を紹介します。

システム開発の受注から納品までの流れ

ユーザー企業は経営戦略に基づき、システム化の企画およびシステム化の計画を立案します。これを受け、システム開発を受注したベンダー企業はシステムの具現化に向け、要件定義を行い、仕様を明確化します。これが、いわゆる超上流の流れです。
 この後は外部・内部システム設計を経てソフトウェア設計として掘り下げ、プログラミングに入ります。テストはテスト仕様書に基づき、単体テスト→結合テスト→総合テスト→システム・運用テストへと進めていきます。無事完成し、要件を満たせば完了し納品です。必要により運用・保守へと入ります。

契約に関する注意点

こうしたシステム開発において契約内容に不備があると、ユーザーとベンダーの間においてトラブル、ひいては訴訟になる可能性があります。したがって以下の点に留意する必要があります。
 システム開発は、準委任契約および請負契約があります。両社の大きな違いは以下の2つです。
 請負契約はベンダー企業に開発の完成責任があるが、準委任契約は完成の義務を負わない。
 開発に欠陥(法的用語で瑕疵担保責任)がある場合、請負契約はベンダー企業に修正に応じる必要があるが、準委任契約はこの義務も負わない。
 このように契約内容が大きく異なりますので、注意が必要です。また請負契約は、仕事の内容が、「丸投げ」という形になるのも注意すべきです。
それでは、請負契約と準委任契約のどちらを採用した方が良いのでしょうか。

契約内容の選定

ベンダー企業に取って仕様が不明確である場合に請負契約を締結することは、工数の読み違いというリスクになりますので注意が必要です。したがって、仕様が不明確な工程は準委任契約、仕様が明確な工程は請負契約とする方が賢明です。
具体的には、前述のシステム開発の受注から納品までの業務フローを踏まえ、工数の読みにくい外部システム設計までの段階では準委任契約とし、工数が読みやすい内部システム設計からソフトウェアテストまでは請負契約とした方がリスクを低減できます。

著作権の帰属

また、納品時の注意点として、開発した成果物の著作権を、ユーザーが独占するのか、ユーザーとベンダーが共有するのかという著作権の帰属に関する問題もあります。
 ユーザーの情報に機密事項が含まれており、ノウハウが流出して他社が使用する恐れがある場合は、ユーザーに全てを帰属すると明記しなければなりません。なお、この場合は秘密保持契約も締結する必要があります。

まとめ

以上、システム開発の受注から納品までの流れを要約し、注意すべき点として、契約と著作権に関する事項を取り上げました。システム開発では、途中で要件追加や仕様変更など様々な問題が発生します。しかし、トラブルが発生しても契約書をしっかり作成しておけば、責任の所在を明確化することができます。
したがって、各工程においてリスクを認識し、契約書に詳細に規定しておきましょう。

参考文献
経済産業省「情報システム信頼性向上のための取引慣行・契約に関する研究会」

▼ 即戦力 システム開発エンジニア を探すなら ▼


日本最大級のITビジネスコミュニティ アサインナビ