システム開発に欠かせない契約の基礎知識まとめ

先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。

僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。

開発の契約体系

｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。
｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。
仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。
- ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。
- 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。
- かといって契約で｢僕らのコンサル案を僕らが実施し成果が出るまでキッチリやります｣ということも可能ではある。
要望と仕様をごっちゃにしないこと。どこまでが仕様でどこからが瑕疵なのかわからなくなる。その線引きを合意書等で抑えておく。

下請法

資本金によって遵守する法律が異なる。委託をする／される側双方要注意。
- 対象となる親事業者が資本金1千万円を超えていれば該当する。
- 親事業者は｢書類の交付・作成・保存義務｣｢支払期日を定める義務｣｢遅延利息支払い義務｣などがあります。
- 下請法に該当する事業者は、発注書に下請法に準拠した項目が網羅されているかが大切。法務は個別契約までチェックできない。
- 参考リンク

契約全体

実は名前は何でもいい。極端な話｢雇用契約書｣と書いてあって中身がシステム開発基本契約の内容なら中身優先。
甲／乙もなんでもいい。俺とお前とかでも法的効力は発揮される。
言葉の定義を前段階で定義しておいたほうがいい。色々会社によってニュアンスが違っているため。
｢提案｣→｢見積｣→｢受注｣→｢PJ開始｣→｢納品｣→｢検収｣→｢請求｣の各々フェーズをキッチリ追えるかどうかが大切。
受領書は各々のフェーズでキッチリもらっておく or 代替のものをちゃんと用意する。オフィシャルに合意が取れていることが重要。
- そうではない場合は｢一定期間をもってその満了をもって承認がみなされたものとする｣という契約にする。
- 何かステータスが変わったら｢メールで証拠を残し、プロジェクト用の冊子に印刷して保管｣する。担当者が辞めた後で揉めることもある。
- メール重要。何かあったらログを掘り起こせるようにしておく。重要なのは事実がどうであるか。
内税/外税をちゃんと明記していないケースが多い。振り込み手数料等も。ちゃんと確認する。
契約書に書いていないことは｢できない｣のではなく｢決まってない｣だけ。勘違いしない。交渉の余地はある。
契約の変更が可能なことと、契約の解約が可能なことは別。解除の条項をよく読んでおくこと。
毒にも薬にもならない条項は触らない。あまり赤入れが入ると心象が悪くなるし、譲れるものとそうでないものの折り合いもつきにくい。
瑕疵担保(なんかやっちゃった場合の無償保証)は商法は半年、民法は一年。検収完了 or 納品完了を基点に瑕疵担保を開始しても良い。前者のほうが良心的な契約。
外資の場合は準拠法をチェックする。アメリカの何とか州とかの法律に準拠させられるケースもある。
何かあったときに使用する裁判所がどこなのかもチェックする。

個人情報とか機密情報

何を持って機密かとか個人かとか、たいてい契約書に盛り込まれている。その定義で話を進めていく。
機密性や秘匿性の高い情報の場合は、再委託(元請から2次請けに流すこと)は基本NG。例外として認めるスタンス。
プライバシーマークをとっている会社が委託側の場合、その基準に準拠する必要があることも。
秘密情報保護の規定が｢永年(期間指定がない)｣になっている場合があるので、基本1年間で個別や例外があればそれに対応する。

第三者ソフト(ベンダー製品やOSS)とか

こういうソフトを使用することを基本契約にちゃんと盛り込んで、委託側の承諾を得る。もちろん、受託側が利用責任を負う。
OSSや製品そのものバグや不具合については受託者が責任を負わないに契約にするのが一般的。
- 現場はそうもいかないけど、契約は契約。
責任負担が増えれば増えるほど、バッファとして(保険に入るとか人を入れる工数見込むとか)金銭を積むしかない。委託側に寄せる。

資料提供・作業場所

資料提供は基本無償で委託側にお願い可能なものとする。複製が可能であることが望ましい。そうでないと仕事にならないことも。
作業場所を指示する権利は委託側はないが、作業場所を提供するからここで仕事してねというのは契約の中に盛り込める。

知財

対象になるのは｢提案書｣｢各種資料(仕様書とか)｣｢ソフトウェア(動作プログラム)｣｢ソースコード｣の大きく４つ。
提案書は受託側、それ以外は委託側が著作権を有する場合が一般的。
- かといって第三者の著作権は第三者のもの。当たり前ですが。
- かといって自分たちのコア技術の著作権をおいそれと渡すわけには行かない。
  - ｢汎用的に利用できる部分は受託側 or 共同｣や｢各種資料(仕様書とか)｣｢ソフトウェア(動作プログラム)｣｢ソースコード｣のうち、委託側のために新規作成したものだけに受託側に著作権を有するやり方がよい。

権利譲渡

契約の譲渡は基本NG。勝手に譲渡させないように盛り込んでおく。
- 契約が移転してしまうと、せっかく契約で定めた権利が引き上げられる恐れがある。

損害賠償

直接損害と間接障害の２つがあり、受託側としては直接損害のみに対応するケースが望ましい。
- 現実に被った損害を対照に対して補償する。逸失利益については対象外とする。
- もちろん契約によっては｢お前の責任で何かやらかしたら賠償額は基本青天井だからな｣と謳うことも可能。
- かといってそんなカネねぇよって場合は｢委託料を限度とする｣とか盛り込んでおく。
通常損害と特別損害という考え方もある。
- 指定されたページまたはファイルは存在しません
納期遅延等をやらかした場合、値引きするか遅延損害金を払うかなどが一般的。
どこまでを求めるかによって話は変わるし、金額が大きく変わる大変グレーな領域なので要チェック。

まとめ

何を決めているものなのか、そして何が決まっていないのかをチェックする。
- 期間や上限がないものは基本青天井になるので要注意。
基本契約で定められたことを何を持って締結としているのかをチェックする。
- 契約締結・変更に必ず書面を発行するケースもあったりする。口約束NGの契約もある。
譲れるものと譲れないものをちゃんと明確にする。
- お互いがお互い有利な方向にしたいのは当たり前。WIN-WINを目指しましょう。
何かプロジェクトが動いたらメール等で証跡を残し紙媒体で管理する。
- 担当者がいなくなってからモメてからでは遅い。
矛盾が発生していないかをチェックする
- 実際に納期遅延の場合は値引受領も遅延損害金も可能な場合があったりする。
- その他関連事項とかに不都合が全部突っ込まれる可能性も
但し書き・箇条書きをチェックする
- 例外事項として盛り込まれているものが大抵あやしぃ。
- 基本的に上限はあるけど、こういう場合はNGなど。
- 箇条書きで書かれていることから漏れがないかをチェックする。
  - 変更は可能だけど解約ができない契約になっているのか、とか。