「システム開発契約書」とは、ソフトウェアの開発を委託または受託するときの契約書です。
自分が委託する側なのか、受託する側なのかによって大きく内容が変わってきますが、契約書を作成したり、内容を審査したりする際の重要なポイントとしては、以下のものがあります（本書では基本的に受託者側の立場で解説していますので、ご注意ください）。
なお、システム開発契約の参考書としては、(旧)社団法人日本電子工業振興協会によるモデル契約書を解説した「ソフトウェア開発モデル契約解説書」が秀逸です。大手SI企業では、全SEに配布しているとか。これ一冊でシステム開発契約は万全です（プロジェクトマネジャは必携です）。 |
| Point 1 |
成果物のの知的財産権の帰属はどっち？ |
- システム開発契約書でもっとも重要なのは「権利帰属条項」、つまり知的財産権（著作権、特許権（特許を受ける権利を含みます）等々…）はどっちのものか、です。
| ソフトウェア | アイデア（アルゴリズム） | ---> 特許法で保護 |
| 表現（ソースコード） | ---> 著作権法で保護 |
- ソフトウェアの著作権は、プログラムを実際に作成（プログラミング、コーディング）した者が原始的に取得します。たとえ委託側がそのソフトウェアのコアとなるアイデアを提供したとしても、です。
- したがって、開発を委託する場合は、契約書のなかに著作権（著作財産権）の譲渡をしっかり規定しておくべきです。
なお、契約書のなかに著作権法２７条（翻訳権、翻案権等）、２８条（二次的著作物の利用に関する原著作権者の権利）の権利も譲渡の対象となる旨を明記しておかないと、これらの権利は譲渡されなかったものと推定されることになっている（著作権法６１条２項）ので、要注意です。
また、著作者人格権は一身専属権であり、譲渡することはできませんので、著作者人格権を行使しないという特約をすべきでしょう。
| 著作権は「権利の束」です。 | 著
作
権 | 著作者人格権
名誉権のため譲渡不可 | 公表権 | | 氏名表示権 | | 同一性保持権 | 著作財産権
（狭義の著作権）
財産権のため譲渡可能 | 複製権（つまり「コピーする権利」です） | | 上演権・演奏権 | | 公衆送信権等（サーバにアップロードする権利も含まれます） | | 口述権 | | 展示権 | | 上映権・頒布権（映画の著作物のみ） |
| 貸与権（つまり「レンタルする権利」です） |
| 翻訳権・翻案権等 | ※これらの権利は、譲渡の対象だと契約書のなかに明記しなければ、譲渡されなかったものと推定されるので、注意が必要です。 | 二次的著作物の利用に
関する原著作者の権利 |
- 逆に、開発を受託する場合は、著作権を譲渡するといった契約は絶対避けるべきです。なぜなら、将来他の顧客のために同じようなプログラムをつくる場合、以前の客先に譲渡した（つまり、昔自分が作ったプログラムの）著作権を侵害することになる可能性があるからです（踏んだり蹴ったりですね）。ＣＤ－ＲやＦＤ等の記憶媒体の所有権は移転しても、プログラムの著作権は絶対移転せずに、使用許諾契約を結んだほうが無難です。
- さらに、特許権（特許を受ける権利を含みます）の帰属も、ビジネスモデル特許などの関連で、今日では重要になってきています。ソフトウェアの基礎となるアイデア（アルゴリズム）は著作権では保護されません。注意しましょう。
|
| Point 2 |
請負？それとも委任？ |
- ソフトウェアの開発契約書は、民法上の契約の区分からいうと、「請負」または「委任」契約と考えられます。
| 請負契約 | 仕事や物（プログラム）を完成することが目的。
完成物に対して対価が発生。 | | 委任契約 | 知識や労力といったサービスの提供が目的。
いままでに提供したサービスの割合に応じて対価が発生。 |
- 請負は「仕事や物（プログラム）を完成すること」が契約目的であり、委任は「プログラムを開発するために知識や労力といったサービス（いわゆるコンサルティングサービス）を提供すること」が契約目的となります。
- 請負において対価を得るためには、プログラムを完成して納品しなければなりませんが、委任においてはプログラムが完成しなくても、いままで提供したサービスの割合に応じて報酬の支払いを要求できます。
- 大規模のシステム開発案件の場合、要求定義・外部設計などの「上流過程」を「委任契約」とし、内部設計・プログラミングといった「下流過程」を「請負契約」としたほうがいい場合があります。つまり、フェーズごとに複数の契約に分割する訳です。最近では、コンサルティングファームが上流過程のみを委任契約で受け、ソフトハウスが下流過程を請負契約するケースが増えているようです。
- いままでに開発したことのない大規模のシステムで、ＦＰ法等を駆使しても開発コストの見積もりが困難な場合は、委任型の契約について検討してみましょう。
|
| Point 3 |
秘密保持に関する条項はありますか？ |
 今日のように企業間競争が激化している時代には、秘密の漏洩に注意する必要があります。ノウハウ等が第三者に漏れたりすると、企業の存続にかかわる事態を招きかねません。
|
| Point 4 |
検査（検収）期間は確定期間になってますか？ |
- 委託側によって検査期間が不当に引きのばされた場合、代金の回収が遅れるなど不測の損害をこうむる可能性があります。受託側としては「商品引渡しの後○×日以内に検査を行う」と定めておき、「この期間内に検査結果の報告がなければ、検査に合格したものとみなす」というような特約が必要です。上述したフェーズごとの契約も効果的ですね。
- 逆に委託側としては、検査遅延によって委託側に生じた損害について賠償の責めを負うなどのリスクを負担することになるので、「実施可能な合理的な期間」を設定する必要があります。
|
| Point 5 |
注文主が指示した技術の使用した場合は？ |
- ソフトウェアを開発していくうえで、第三者の著作権や特許権といった知的財産権を使用する（知らないうちに侵害してしまう）こともありえます。
自己の責任において使用した技術ならばしょうがありませんが、注文主が「これを使いなさいっ！」と指定してきた場合、当該知的財産権の使用については請負人が免責される旨の特約が必要です。
|
| Point 6 |
不可抗力免責に関する特約は？ |
 法律上、納期が遅れたときの責任を問われるのは請負人に過失のある場合に限定されます。でも念のため、天災地変などの不可抗力（より具体的に規定したほうがいいでしょう）によって納期を守ることができなくなった場合は、相当期間納期を延長できる旨の特約をしておいたほうがいいでしょう。
|
| Point 7 |
危険負担に関する条項は？ |
- 不可抗力の場合でも、危険はどっちかが負担しなければいけません。受託側としては、引渡しをもって危険負担を委託側に移転させる旨の特約をしておいたほうがいいでしょう。
|
| Point 8 |
瑕疵担保責任に関する特約はありますか？ |
- 瑕疵（つまりバグ）担保責任は無過失責任なので、受託側としては極力保証期間の短縮化（６ヶ月くらい。最悪１年）をはかるべきです。期間満了後は、有償のサポートサービスなどに切り替えたほうがいいでしょう（ビジネス的にも、顧客と今後の繋がりを維持できるためベターです）。
- 販売業者との取引の場合は、「最終ユーザへ販売後○×年」といった期間設定は極力避けるようにしましょう。受託側にとってはきわめて不利です。
- 瑕疵の発生にともなう修補（バグ取り）は、少なくとも修補に要する期間だけ保証期間を延長するにとどめるべきです。
修補後あらためて当初定められた保証期間と同一期間保証義務を負担することは、受託側にとってはきわめて不利です（バグのないシステムはこの世に存在しません...つまり未来永劫にわたって瑕疵担保責任を負わざるを得なくなってしまいます）。気をつけましょう。
- ＯＳやソフトウェアベンダが提供する開発ツール（Visual Basic等々）のバグに起因する瑕疵については、請負人は責任を負わない旨の特約を入れておいた方がベターです。
- さらに「ソフトウェアを納入した後にリリースされたハードウェアやＯＳ上での動作は保証しません」といった特約を加えておいたほうが、より効果的です。
|
| Point 9 |
賠償限度額は設定されていますか？ |
- ソフトウェア開発の場合、製品の特殊性から損害が莫大なものになる危険性があります（たかだか１０万円の給与管理ソフトにバグがあったために、給料を払いすぎて１００万円の損害がでてしまった等々）。受託側としては、「契約金額をもって賠償限度額とする」という特約が絶対必要です。
|
| Point 10 |
一方的な無催告解除は認められていませんか？ |
- 相手の契約違反がはなはだしく、たとえ催告しても約束どおりに実行する可能性がほとんどない場合、催告しなければ契約を解除できないのであれば、解除時期を失するという実際上の不利益が大きくなるので、無催告解除の特約を設けるべきです。
- でも、ソフトウェアの請負開発契約の場合、転売・転用することがたいへんむずかしい（特注ですから）ので、途中で解除されたときの請負人の損失が大きくなる可能性があります。
注文主に途中で解除された場合は、未完成ソフトウェアを納める代わりに、それまでの工数に対する対価の支払う旨の特約をかわすべきでしょう。
|
| Point 11 |
期限の利益喪失条項はありますか？ |
- 相手方が契約違反したり、不渡処分をうけたり、信用状態がきわめて悪化したときは、残金全額をすぐに支払ってもらわなければなりません。
|
| Point 12 |
契約変更条項は同意・協議が条件？ |
- 一方的に相手方に要求仕様等の変更権（ユーザーの潜在的ニーズって、開発の初期段階でははなかなか出てこないもんです）をあたえることは、極力避けるべきです。納期の遅延を招きますから。最低限、同意もしくは協議を条件とするべきです。
|
| Point 13 |
請負代金の増額を請求できる特約はありますか？ |
- 請負契約の場合、見込み違いや材料の値上がり等の可能性があるため、対価の設定が容易ではありません。
「賃金または物価の変動により、請負金額は不適当であると認められるときは、双方協議のうえ請負金額を変更できる」旨規定しておいたほうがいいでしょう。
|
| Point 14 |
下請利用は可能？ |
- 下請けのソフトハウス等を利用する可能性がある場合は、下請先を利用することができる旨の特約（でききれば注文主の承諾なしで…納期直前のヤバイときに注文主に了解なんてとってられません）をしておいたほうがいいです。
- 注文主が下請先を指定している場合は、請負人の責任を軽減する特約が必要です。さらに、この下請先がソフトウェアを開発していくうえで不的確な場合には、変更を請求できるように規定しておくといいです。
|
| Point 15 |
裁判所の合意管轄の特約はありますか？ |
- 相手方の住所地を管轄する裁判所へ訴えるのは多額のコストがかかります。できれば自社の本社所在地を管轄する裁判所にしておいたほうがベターです。
|
| Point 16 |
残存条項はありますか？ |
- 契約期間満了後も一定期間秘密保持義務を負わせる等の残存条項に関する特例も必要です。
|
| Point 17 |
契約書の形式は？ |
- 一般的な契約書は、
| (1) 表題 |
売買契約書、業務委託契約書、等々・・・・ |
| (2) 前文 |
株式会社○×（以下「甲」という。）および株式会社△□（以下「乙」
という。）は・・・・ |
| (3) 本文 |
第１条、第２条、第３条・・・・ |
| (4) 末文 |
本契約締結の証として甲乙記名押印の上各自１通を保有する、等 |
| (5) 作成年月日 |
契約締結日を記載します（忘れずに!!）。 |
(6) 当事者の住所
社名（商号）
代表資格＋代表者氏名
＋押印 |
社名や代表資格（代表取締役）が抜けていると、対会社の契約なのか、対個人の契約なのか分からなくなってしまいます。
また、商業登記簿で代表権者をあらかじめ確認しておきましょう。
できれば署名押印、駄目でも記名押印が必要です。なお、取引相手によっては実印＋印鑑証明での契約締結も検討しましょう。 |
の順で構成されます。
- 誰が読んでも同じ解釈ができるように書かれていますか。小説ではありませんので、行間を読ませる（読まれる）ような書き方はいけません。契約書は後日、裁判上重要な証拠となりうるものであることを肝に銘じましょう。
内容に矛盾がないのであれば、同じような内容を繰り返し書いても、マイナスにはなりません。
- 多少クドくても「甲は乙に対し…」のように主客を明確にしたほうがベターです。契約書はあくまでも、お互いの権利・義務を明確にするためのものだからです。
- 「甲」「乙」で記述すると、途中で甲乙が逆になってしまうことがあります。よくあることですので、気を付けましょう。最近は「甲」「乙」ではなく、「売主」「買主」とか「○○社」「△△社」のように記述している契約書も少なくありません。
- 契約締結日は正確に記載されていますか（しっかりとした契約書であるにもかかわらず、契約締結日や本文中の締め支払の日がブランクになっているケースが結構見受けられます）。日付が虚偽であると文書全体の信頼性を損なってしまう可能性があるので、要注意です。
|
| Point 18 |
最後に「法律用語を間違って使ってませんか？」 |
- 「および」と「ならびに」、「または」と「もしくは」等々…、法律用語を間違って使っていると結構恥ずかしいですよ。「法律用語のキソ」を参考にしてください。
- 第３条が２つあったり、第４条がなかったり・・・条文の番号を正確に付けていますか。
- 誤字脱字にも気を付けてください。契約書は後日、裁判上の重要な証拠書類となるものです。
|
| 以 上 |
＜参考＞
システム開発契約については、各業界団体からモデル契約が発表されていますので、ぜひ参考にしましょう（下記のサイトで参照できます）。
|
取引基本契約
