弁護士が解説 ! システム開発契約で失敗しないためのポイント
法務



システム開発を事業の中心としている企業は多いと思います。
システム開発契約を受注するにあたっては、システム開発契約、開発請負契約、業務委託契約など、その名目は様々ですが、何らかの契約が締結されることが一般的です(便宜上、本稿では「システム開発契約」に統一します。)。

システム開発契約の基本的な内容としては、
① 要件定義を満たす機能を備えたシステムを開発し、
② そのシステムを成果物として納品し、
③ 発注者の検収を経て、
④ 合格した際には開発料・委託料等の名目で対価を受け取る
といったあたりが挙げられるかと思います。

今回は、システム開発を受注する側の視点で、システム開発契約で失敗しないためのポイントを解説します。



要件定義


システム開発の場合、通常、本契約締結前に、開発対象となるシステムの要件定義の作業が行われます。
この要件定義は、システム開発契約における開発作業のスコープを決定するものですので、契約前だからといってさらっと流してしまったりせず、その内容はよく確認し、場合によっては交渉することも大切です。

チェックのポイントとしては、

・開発期間内に完成可能であること
・予定されている契約対価に見合うものであること
・客観的に完成の有無を検証可能であること

といったあたりが挙げられるかと思います。

この要件定義があいまいだと、いざ開発を開始した段階で、契約期間内に完了できないとか、想定以上の工数が発生してしまい追加で対価を請求しないと赤字になる、といった問題につながる可能性があります。


検収条件


システム開発契約では、完成したシステムを納品した後、一定期間、発注者側で検収作業が行われることが一般的です。
その場合、発注者側の検収に合格することで作業完了となります。
検収条件については、「検収期間」と「合格条件」が重要です。
検収期間は、その名のとおり、発注者側で検収に必要な期間として定めるもので、発注者は、その期間が満了するまでに合否を開発側に連絡することになります。

この検収期間ですが、当然、開発されるシステムの複雑さによって長短は変わってくるものの、時折極端に長く設定されている契約を見ることがありますので、要注意です。感覚的なところですが、通常は検収期間として納品から1週間~2週間程度確保することが多く、1か月や2か月となっていると、長いな、という印象を持ちます。

また、下でも述べますが、通常は、検収に合格することが対価の支払条件となりますので、極端に長い検収期間が設定されている場合、それだけ入金が遅くなることを意味します。そのため、会社の資金繰りに影響が出ないよう注意しなければなりません。

合格条件は、検収に合格するための条件を指しますが、これが非常にあいまいで、発注者側が何とでも言えるような(いちゃもんをつけて不合格にしようと思えばできてしまうような)契約が散見されます。

場合によっては、「成果物が、発注者が満足する品質を備える場合には合格とする」などと定められていることがありますが、このようなあいまいな条件で契約を締結してしまうと、開発者としては果たして合格するのか全く見通しが立たないことになりますし、本来不要な修正まで要求されることにもなりかねません。
開発者の立場からすれば、合格条件は客観的に検証可能なように定まっていることが望ましいと言えます。
客観的に検収可能であれば、例えば検収不合格の通知を受けたとしても、開発者において改めて合格条件を満たしているかを検証し、場合によっては不合格の判定が誤っていると反論することが可能になるからです。


対価の支払条件


システム開発の場合、対価の支払条件は、「検収合格後●日以内」とか「検収に合格した日が属する月の翌月末」といったように、検収合格日を基準としていることが多いと思います。

それ自体は大きな問題ではありませんが、例えば検収期間が長く設定されている場合、それだけ入金も遅れることになりますので要注意です。

例えば、検収期間30日、検収合格日の翌月末払いとなっている場合を考えてみると、

・4月10日納品
・5月10日検収合格
・6月30日入金

となりますので、実際に作業した3月~4月分の開発業務の対価が入金されるのは、約3か月後となります。しかも、上記は検収に一発合格した場合を想定していますので、検収に不合格となり、修正作業が発生した場合には入金は更に遅くなります。
このように、システム開発の対価がどういう条件で支払われるのか、実際に入金されるのはいつごろになるのか、は契約締結前によくシミュレーションしておくことをお勧めします。

その上で、会社にとって不都合が大きいようでしたら、例えば検収期間を短くしてもらう、検収合格から支払いまでの期間を短くしてもらう等々の修正を申し入れることになります。

なお、ここでは特に問題としていませんが、もしシステム開発契約が下請法の適用を受ける場合、対価の支払は、(検収合格日ではなく)当初の納品から60日以内であることが必要ですので、ご注意ください。


成果物の権利


開発したシステムは、プログラムの著作物として著作権の対象となる可能性が高いです。そのため、システム開発契約においては、開発されるシステムの権利の帰属を定めることが一般的です。発注者が全ての権利を取得することが多いかと思いますが、時折、開発者が権利を取得し、発注者にライセンスするという建付けの契約もあります。
ここは、開発したシステムを開発者側でも使用する可能性があるのか、といった事情によって変わってきます。

また、仮に発注者が開発されたシステムの権利を取得するとしても、その範囲については注意が必要です。
「システムに関する権利は、全て発注者が取得する」と契約書で定めた場合に、システム開発にあたって開発者が既存の自社プログラムを使ったら(そして開発されたシステムに自社プログラムが一部でも取り込まれているとしたら)どうなるでしょうか。

開発されたシステムに関する権利に含まれるとして、その自社プログラムの権利まで発注者が取得すると解される可能性があります。そうすると、開発者は既存の自社プログラムを、今後他のシステム開発で流用することができなくなってしまします。
したがって、開発したシステムについて発注者に権利を取得させるとしても、どの範囲で取得させるのか、開発者に残すべき権利はないのか、などはよく確認する必要があります。ここは、契約書のワーディングの問題でもありますので、会社の要望が十分に反映された契約文言になっているか、専門家に確認してもらうことも有益です。


まとめ


システム開発は紛争に発展するケースも多いですが、契約書の締結段階でよく注意しておけば予防できた、というケースもそれなりに存在します。

早く受注を決めて開発に着手したいという要望もあるかと思いますが、紛争になってしまえば契約交渉の何十倍というコストが発生してしまいますので、契約締結前に一度立ち止まって、よく内容を確認するようにしましょう。

ご不明な点がございましたら、お気軽にご相談ください。
参照 : SHARES 弁護士 大久保和樹のページ

記事のキーワード*クリックすると関連記事が表示されます

メルマガ登録(毎週水曜配信)

SHARES LABの最新情報に加え、
経営に役立つ法制度の改正時事情報などをお送りします。