システム開発の契約書はここに注意！

先日、古くからの友人に相談を受けました。
その内容は「システム開発の契約を結ばなければならないのだけれども、自分は素人だからどんな点を注意してみればいいのか分からないので教えてほしい。」と言うものでした。

確かに、何度か経験すればどこを注意すべきかは分かるのですが、ユーザ側の立場にいる方は、システム開発の契約を結ぶことは少ない、もしくはしたことがない方が多数でしょうから、高額な契約書を取り交わすのは不安だと思います。

という事で今回は、システム開発の契約締結時に注意するポイント7選をご紹介いたします。

• システム開発の契約に不安を感じている方
• システム開発の契約で失敗したくない方

そんな方がこの投稿をご覧頂きますとシステム開発の契約書の注意点についてご理解頂けますのでぜひ最後までご覧ください！

本説明は法律に則った契約書類を作ることを目的としていません。契約書としての体裁は法務部門、顧問弁護士さんにご相談ください。
この投稿は、契約をする際の留意点の説明を目的としています。

このコラムの内容は動画で公開しています。
「システム開発の契約書はここに注意！」Youtube版はこちらをご覧ください。


契約書は、開発を発注する側が作ることもあるでしょうが、慣れない場合、開発をする側が用意した契約書に基づき契約することが多いでしょう。
その場合、どこを注意しておかなければならないかを説明します。

①契約の種類

システム開発の契約では、請負契約と準委任契約が主なものです。まず、ここを知らないと大変なことになります。とても重要なところですので、必ずご理解ください。

請負契約は依頼したシステムの完成が約束されます。
準委任契約は完成を約束するものではないです。

大切なところなので、繰り返しますが、準委任契約は完成を約束しません。

これは民法において定義されているものであり、準委任契約の目的は、相手方の自由な判断を信頼して業務の遂行を任せることで、業務の完成自体は目的とされていません。 そのため、相手方が業務を遂行さえすれば、業務の完成義務は負わないのです。

だとすると、システムを発注する側からしたら「それなら当然請負契約しかない。」と思われるでしょうが、システムを開発する側は請負契約はできればしたくないのです。その理由を説明します。

システム開発は、開発をする側の都合だけでプロジェクトを進められません。もし「発注者がシステムを発注したら、開発完了まで待つだけ」なら良いのですが、システム開発は発注者と開発者の共同作業です。

発注者は、開発に必要な情報を用意したり、両者で一緒にシステムの仕様を決めたり、納品されたシステムのテストをしたりと、プロジェクト進行において発注者が担う作業が多々あります。

詳細はまた後日投稿しますが、簡単に言うと発注者の責任の作業が遅れると、開発者の作業の停滞、開発作業のやり直しに直結するのです。作業の停滞、やり直しはダイレクトにスケジュール、開発者の人件費に影響します。

つまり、開発者は自分たちの努力が届かないところにコスト上昇リスクを抱えているということです。

慣れた間柄ならまだしも、初めて契約する相手なら、なおさら発注者がどのようなスピード感、正確性をもって対応してくれるのかがわかりません。

システム開発者としては、発注者の責任によるスケジュール遅延・仕様変更は見積もりをし直す、と言う契約もありますが、「発注者の責任で遅延している・仕様変更になった」ことを証明しなければならないので、その手間もかなりのものになります。また、発注者も仕様変更を簡単に認めたくもありません。

それであるならば、「最初から委任契約にした方がリスクを取らずに済む」と言うのが開発者の論理であり、それがリアルです。

しかし、一方で発注者としてみれば、準委任契約だと予算のブレ幅も大きく、予算を立てにくいこともあります。そのため、折衷案として、要件定義は準委任契約、その後の設計開発は業務委託となることも少なくありません。

発注者、受注者のお互いの立場を尊重することを忘れず、請負契約は依頼したシステムの完成が約束されるけれど、準委任契約は完成を約束するものではないということを理解しておいてください。

②契約金額の支払い方

システム開発会社の企業体力と見積金額の大きさにもよりますが、請負契約なら主に次の3つの支払方法があります。

• 完成後に一括で支払う
• 着手時と完成後に支払う
• 工程ごとに分割して支払う

目安としては2、3ヶ月以内の開発なら、完成後一括支払い。
半年を超えるなら着手時と完成後、あるいは工程ごとに分割となるでしょう。
ちなみに、着手金は10％～50％と幅広く、ケースバイケースのようです。

初めて契約する相手なら、お互いがリスクを負っています。
開発者からみれば、

• 開発を終えて、支払いをしてくれるのだろうか
• 後から機能修正が多発して、それを終えなければ支払いはしないと言われ、支払いが伸び伸びにならないだろうか

発注者からみれば、

• 品質の高いシステムが作れるのか
• 着手金を払った後に逃げられないか
• 最後まで責任を持って対応できるのか

というリスクがあるわけです。

実際のところ、相手に対するリスクだけではなく、開発者が小さな企業で潤沢なキャッシュがなければ、早めにお金を頂きたいというのはリアルな話しです。

発注者としてはこのようなリスクを軽減するためにも、しっかりと開発の依頼先を吟味することが大切です。この点については、以前「システム開発で後悔しない！開発パートナー評価の秘訣！」という投稿をしていますので、ご覧頂いていない方はぜひご覧ください。

③工程別の契約

先に説明した契約の種類、契約金額の支払い方に関係するのですが、互いのリスクを軽減するための契約方法として、システム開発工程別に契約を結ぶという方法があります。

この場合、まずは要件定義で準委任契約、設計開発で業務委託、受け入れテストで準委任契約をするなど工程を分けて契約します。この方法は、互いのリスクを軽減するには妥当な考えです。

要件定義は発注者が要件を決定するための時間が伸びやすい、設計・開発は、開発者が設計・開発を行う際に問題が発生しやすいなど、作業の主体となる側がリスクを負う考えとするのは公平であると言っていいでしょう。

④成果物

システム開発の成果物には次のようなものがあります。

契約書に記載されてない成果物は、開発者に作成しませんと言われても文句は言えません。開発者としても、先にお話しした成果物を全て作るのは手間がかかるので、できれば少しでも減らしておきたいというのが本音。それがリアルです。

成果物でご紹介した中でもソースコードがなければシステムは動きませんから、そこを拒む理由はないのですが、設計書はできれば作りたくない筆頭の成果物です。なぜ開発者が設計書を作りたくないと考えるのでしょうか？

その理由は、最新化するのに手間がかかるからです。
システム開発は、設計書を作成し、その設計書に基づいてプログラムを作成します。しかし、プログラムの作成中、あるいは作成し終えてから設計の考慮漏れや不備が発生するとします。その場合、手直しはプログラムが優先されます。なぜなら、設計書が更新されていなくてもシステムは動きますが、プログラムが更新されていなければシステムは動かないからです。
　
設計者とプログラマを別の人が担当しているならばまだしも兼務の場合も少なくありません。そうすると、とりわけスケジュールがタイトな状態だと設計書の修正は後回しで、プログラム開発優先になります。これが1つや2つならばいいですが、そこそこの数が出てくると、後で設計書を直すのは時間がかかる作業で、面倒だと考えてしまうのが開発者の心の叫びなのです。

そんな事情もあって、設計書の修正が漏れており、プログラムと仕様の不一致が生じていることはよくある話です。こうなると悪循環となり「設計書はどうせ最新化されてないだろうから、ソースコードを見た方がいい。」「どうせ設計書を見ないなら設計書を最新化するのは無意味。」となってくるのです。

理想的には先にあげた成果物は全て契約に盛り込みたいです。しかし、「そうすると開発金額が許容範囲を超えるので、少しでも抑えたい」という場合であっても、要件定義書、機能設計書、データベース設計書、ソースコードは必須としてください。

⑤著作権

発注者としては、自社がお金を出して開発するのだから、その著作権は自社にあるべきと考えることでしょう。しかし、著作権は、その成果物を作成した人・組織に帰属する権利です。契約書に何も記載がなければ、システムを開発した側に著作権がありますので、支払と同時に著作権は譲渡される、あるいは発注者が自由に成果物を利用、改変できる権利を有するよう契約書に必ず記載してください。

⑥検収方法と検収期間

商品を注文して届いたら、確かに注文した商品・数量であり、破損などしていないことを確認するのと同様に、システム開発においても、注文した通り、つまり要件通り・仕様通りにできているか、契約書に書かれている納品物が納品されているか確認することを検収と言います。

仕様通りにできていることの確認は受入テストで確認しますが、スケジュールに受入テストが明記されておらず、検収とまぜこぜになっている場合もありますので、注意が必要です。
ここは検収期間に大きく関係します。
　
システムの開発規模に依存はしますが、受入テストのスケジュールが取られているならば、後は成果物のチェックなので、検収期間は1週間となっていても大丈夫かもしれません。
しかし、もし受入テストの期間が設定されていない場合、1週間以内にシステムの動作確認と成果物の確認の両方は困難でしょう。それは2週間でも難しいかもしれません。

「常識的に考えれば、受入テストは別の期間があり、検収は成果物チェックくらいだよね。」と思い込んではいけません。十分な検収期間があることを確認してください。

⑦保守責任

こちらについても、過去の投稿でも書きましたが、保守をしない会社もあります。
開発時点の契約で、金額を決めておくかどうかは別としても、開発者は保守作業を行うことも盛り込み、開発完了後もお付き合い頂くことを約束しておくのです。

まとめ

システム開発契約書を締結する際に注意すべき7点について解説しましたが、契約書に関する注意点に加えて、さらに注意すべきことがありますので、付け加えておきます。

それは、契約の締結前に開発を始めないということです。
これもリアルではよくあることです。

しっかりと余裕をもった開発スケジュールならいいのですが、サービス開始を告知してあるとか、その他重要な業務に合わせてシステムを稼働させなければならないなど、何があっても後ろをずらせないということがよくあります。

そうすると、「契約書は後付けで作るので、開発を始めましょう」と開発者から提案されることがあります。それが、後々問題になることがあるのです。

例えば、著作権をどうするかを決めないまま開発に入り、後付けの契約書作成の場面で、開発者が頑なに「著作権は渡しません。修正は当社でなければできません。」と言い切られたらどうでしょう？その会社が良ければ良いものの、「開発を始めたら色々問題があることが発覚したから、完成後は別の会社に委託したい」と考えても著作権が開発者にあるならば、そうはいかなくなるのです。

あるいは、着手金として、半額を当月末まで払ってくれないとこれ以上進めませんと言われて、支払わざるを得ない状況になるかもしれません。
契約書締結前に開発を開始してしまうことで、色々なリスクを負うことになります。

そもそも、問題なく開発が完了すれば、契約書をかざして争うことをしなくても済むのですが、保険をしっかり掛けるのと同様、契約書を締結した上で開発を開始しましょう。

そして、最後は法律の専門家へ内容の確認を依頼してください。