システムやソフトウェア、アプリの開発を委託する契約はあらゆる企業で頻繁に行われています。
システム開発には、大企業が何億円もかけて一大プロジェクトとして行うものから、中小企業がスポット的に資源を投入して完成させるものまで、規模も内容も様々です。
そこで今回は、主に中小企業間で行われるシステム開発契約書についてのリーガルチェックポイントを解説します。

システム開発契約書はひな形でも問題ない？

システム開発は工程が多く細かいことから、契約書作成にあたっては、双方が納得できるように仕上げるのは大変と思われる方も多いのではないでしょうか。
そんなとき、ひな形があると便利ですが、ひな形はどの程度信頼できるものなのでしょうか。
結論からいうと、案件ごとにさほど変わらない部分については、ひな形を参考にすることは構いませんし、むしろ時間の節約にもなります。たとえば、再委託の可否、納品時期、品質保証、秘密保持、個人情報などについてです。

その一方で、案件ごとに個性がある部分には、工夫や配慮が必要です。現場にどうフィットさせればよいのか、特に開発対象や検収基準などは個別の契約書ごとにきちんと言語化されているか、ていねいにチェックしておくことが、双方のトラブルを防ぐためにも大切なポイントになります。
それを次に解説していきます。

１　開発対象を明確に定める

システム開発をめぐってもめごとが起こる場合、必ずといっていいほど注目されるのが、「そもそも何を作る約束だったのか」、そして「それはできているのか」ということです。
「何を作る約束だったのか」（＝開発対象）を明確にし、「それができているのか」の判断基準（＝納品検査基準）を明確にしておくことで、多くの紛争を防ぐことができます。

システム開発は、ざっくり以下の流れで進みます。
① 要件定義：何を実現したくて、何を作るのかを定める。
↓
② 仕様書：そのために、具体的にどんな機能を備えるのかを定める。
↓
③ 設計書：それをどうやって作るのかを定める。
↓
④ 開発：それを実際に作る。プログラミング。
↓
⑤ テスト、実装：それを実際に動かしてみる。運用。

家やビルを建てるように、①→⑤を完成まで一回で行うウォーターフォール型と、
このサイクルを小さな塊にして、何度も繰り返しながらゴールに向かうアジャイル型とがあります。

この中で大切なのは①と②で、発注者（ユーザー）と開発者（ベンダ―）の密なコミュニケーションが必要です。

まず①要件定義では、そもそも何を実現したいかを共有することから始めましょう。
案外ここが抜けていて、その結果、
いきなり「こんな感じのシステム作って」にはじまり、
「こんな感じで作りました」と納品した結果、
「いやいや全然わかってないし、使えないじゃん」となり、
「いや、聞いてませんけど。ていうか、やった分払ってください」となって、
「は？払えるわけないでしょ」といってもめることになりがちです。

“そのシステムを使って何を実現したいのか”という、本当のゴールを見える化し共有しておけば、そのような行き違いは起きませんので、ぜひ意識していただきたいです。

次に、②の仕様書でも、ユーザーは専門外だからとベンダー任せにせず、教え・教わりながらの関係のなかで、どんな機能を備え、どんな情報を得て、どんな動きにするのかを協同作業のなかで構築していくようにしましょう。
ベンダー側も、自社が想定している機能や動きを、ユーザーも当然に分かってくれるはずと早合点せず、双方で認識や想定を共有できているか確認しながら進めるようにしましょう。

このように開発対象を明確に定めておくことで、「そもそも何を作る約束だったのか」のところでもめないようにし、そのために、要件定義、仕様書、設計書をできるだけ詳細に作成するようにしましょう。
もちろん、アジャイル型はじめ、開発を進めていくなかで、仕様や機能を決めたり追加変更を行うことも多いので、その場合の新たな合意事項の書面化・記録化、追加費用の有無の取り決め方も定めておきましょう。

２　納品検査の基準を定める

これは１の開発対象とリンクするところであり、またシステム開発独特の事情もあるところです。
システム開発は、イメージをしやすくするために、建物建築に例えられることがよくあります。
何を作りたいか定める
↓
どう作るか定める
↓
実際に作る
という流れは、たしかに建築と同じです。
けれど、建築との大きな違いは、完成引渡し後も、引き続き作業をすることがあるということです。
建築であれば、引渡後も施工業者が作業していたとしたら、「何かやり残したことがあるんだろう」とか「不具合があって直しを入れてるんだね」と言われてしまうでしょう。

しかし、システム開発の場合は、仕様書・設計書に基づいてやるべきことは完了し実装したけれども、なお改善の余地があったり、メンテナンスしながら動かしてみるということはよくあります。軽度なバグは避けられないケースもあります。
なので熱心なベンダーであればあるほど、ユーザーが満足いくまでとことんつきあうこともあります。

そして、ある程度互いの納得がいったところで、「このあたりでいったん作業を終えましょうか。また何かあれば仰ってください」「そうですね。ありがとう」というやりとりで完了になります。

そうやって最後まで信頼関係を保ちながらゴールにたどり着ければよいのですが、これがもめてしまうと大変です。
いつまでやっても「できてないじゃないか。まだまだだ」となったり、「納品期限過ぎてるのにいつまでかかるんだ」などとなってしまうのです。

そうならないためにも、納品検査基準として、仕様書や設計書に照らし合わせてのテスト項目、テスト方法を定めておき、「約束したものができているのか」の判断基準を契約書に盛り込んでおくようにしましょう。
ただ、アジャイル型の場合は、そもそもテスト項目やテスト方法を定められないタイプなので、検査基準を明確にしておく必要の高いユーザーとの取引では、費用がかかってもウォーターフォール型を選択し、テスト項目、テスト方法を定めるのがおすすめです。
システム開発の発注に慣れていない場合は、ドキュメント中心のウォーターフォール型にしておくとトラブルリスクを下げることができるでしょう。

３　契約不適合責任（瑕疵担保責任）について定める

2020年４月から施行された改正民法では、「瑕疵」という用語がなくなり、「契約不適合」（＝契約の内容に適合しないもの）という用語が用いられるようになりました。
改正のポイントは次のとおりです。
①欠陥品だとか、契約で定められた品質を満たさない「契約不適合」品の場合は、修理（履行の追完）、代金の減額、損害賠償、契約解除といったメニューが一定要件のもとで認められる。
②①の責任追及は、「注文者がその不適合を知った時から１年以内に通知」すればよい。

この民法改正について、昨今、“何だか知らないけど大変らしいぞ”と実務をあおるような記事も散見されますが、これはあくまで契約書で何も定めがない場合に適用される規定です。
ですので、契約書において自由に欠陥や不具合についての担保や保証規定を定めておくことで対処ができます。

例えば、１や２で定めた内容を満たしていないものを「契約不適合」と定義するほか、
責任を負う期間は、「知った時から」ではなく、「納品時」とか「検査合格時」から１年とか６か月などと定めることで、ベンダーが負う責任の範囲や期間を明確にしておきましょう。
また、単に責任を負う負わないだけでなく、いつまでが無償対応で、いつからが有償対応なのか、という定め方も検討するとよいでしょう。
そうすることで、双方にとって、引渡後の不具合対応でもめるリスクを減らすメリットがあります。

４　知的財産権の帰属について定める

システム開発に伴って、著作権はじめさまざまな知的財産権が生まれることがあります。
その場合に、どの範囲でどちらが権利を持つのかを定めておくようにしましょう。
ちなみに、うまく折り合いがつかない場合に、安易に共有財産してしまうことがありますが、そうすると、どんな場合でも相手の了解がないと使えないということになり、かえって使い勝手が悪い場合も出てくるので、注意しておくとよいでしょう。

以上のように、システム開発契約書で注意すべきリーガルチェックポイントを整理しました。
システム開発は、ユーザーとベンダーとが、いわば投げる方も受け取る方も声を掛け合いながらキャッチボールをし、一緒にゴールを目指すプロジェクトのようなものでもあります。
ですので、そのための明確なルールブックとなるような契約書にしておきたいです。

システム開発契約でのトラブル事例

実際に私が関わったシステム開発契約に関するトラブル事例を紹介します。
この件は訴訟にまで発展し、何年もかかってようやく代金回収することができましたが、開発対象の決定と納品定義がいかに大事かということの分かる一件でした。

ポータルサイトのシステム開発で起きた契約トラブル

あるシステム会社さんが、「公式サイトをリニューアルしてほしい」という依頼を受けました。ウェブデザインを進めていくうちに、システム会社側は“クライアントからの素材待ち”、クライアント側は“システム会社が進めていると思いこんでいる”、という認識のズレが生じてしまいました。お互いの認識がズレたまま、時間だけが過ぎていった結果、納期が大幅に遅れてしまうことに。

スケジュールは遅れていたものの、一旦これまでの出来高を支払ってもらう（マイルストーン支払いをする）ことで、担当者レベルでは合意が得られました。しかしある日、会議で先方の社長から予定の遅れを指摘され、「出来高で支払うことはできない」という話になってしまいました。

この時点で、当初の納期にはもう到底間に合うような進捗状況ではありません。ですが、先方は「当初の予定通りに仕上げてもらう」との一点張り。そのタイミングで「どこをもって“完成”とするのか」という定義づけをしていなかったことに気付きますが、相手は社長です。断ったらこれまでの代金すらもらえないことを危惧し、ゴールが見えないままで「できるところまでやります」と請け合ってしまいました。

納品定義が曖昧な状態でなんとか進めたものの、
「要求している仕様と違う」「デザインが全然ダメだ」
と一向に終わる気配にならず、当然料金についても言い出せないような苦しい状況が続いてしまいました。

こちらは“納品”したつもりが、“完成”と認められなかったのです。
この件、結局支払いがなされなかったため、訴訟に発展しました。

裁判では、開発状況の検証が行われました。
法廷で画面を共有しながらシステムを操作し、実装した機能と、未実装の機能を確認しあいました。
実装の有無や程度を見極めるのは難しい問題でもあり、このときの裁判官はITやシステムについて決して明るい訳ではありませんでした。そこで、前提知識を正しく持ってもらうために、私は「システム開発とはどのように行われているか」を解説するプレゼンも行いました。
システム開発契約には、「アジャイル型」と「ウォーターフォール型」があることやその違い、今回のシステム開発がどういう要件のものだったのかを分かりやすく解説しました。

また、複数のシステム会社から陳述書を集めて、プロの目線から見ても相手方の支払拒否はおかしいということも伝えました。おかげでシステム開発についての理解を得られ、依頼者も納得のいく代金を回収することができました。

上記事例の問題点と今後の対策

この場合は「アジャイル型」の開発だったためやむを得ないともいえますが、開発対象と納品定義をしていなかったことで、クライアントの要求にずるずると応えざるを得ない状況ができ上がってしまいました。

システム開発では、残念ながらお客様との力関係が露骨に作用するケースが多いです。
アジャイル開発など流動的にシステム開発を進める場合は、「契約書を作っているから安心」ではなく、進捗があるごとに合意をもらっておくなど議事録や報告書をこまめに残しておくことも重要です。

また、報告書に関しても、ただ作って満足ということにせず、クライアントに内容を確認してもらい、「OKです」などの言質を取っておくことも重要です。契約後に発生する仕様変更などは、都度の報告と合意取得を徹底してください。
後日に「要望通りのシステムになっていない」と言われたとしても、上記のやりとりをこまめに残しておくことは、交渉時や訴訟時に有効に働きます。

システム開発の現場でできること

契約で要件定義などをどれだけ細かく定めても、それだけではうまく進むとは限らないのがシステム開発契約の難しさ。狭い業界ということもあり、次の仕事への影響を考えると断れず、顧客の無理難題を飲まざるを得ないケースも私はたくさん見てきました。

そんな場合も、いざというときに主張できる状況は作っておくべきだと私は考えます。
まずはこちらが正しい対応をした、正しい契約書を作った、正しい報連相を行ったという状況を作る。そして、いざというとき有利に主張できる武器を持った上で、強く出るのか要求を受け入れるのか、臨機応変に選択をするよう、顧問先の企業様にはお伝えしています。
このように、いざというときにしっかりと主張できる状態になれるよう、精一杯サポートいたします。
システム開発の契約についてお悩みの会社様は、ぜひ一度ご相談ください。その場合は下記フォームからお問い合わせください。
（2021年11月13日追記更新）

リーガルチェック、契約書作成のご相談フォーム