当サイトを快適にご利用いただくには、ブラウザでJavaScriptを有効にしてください。弁護士が教えるベンチャー必読法律講座06【知っておくと得する契約書TIPS7選】2017/09/03これまで2回にわたって契約書に関するポイントを解説しました。弁護士が教えるベンチャー必読法律講座05【ベンチャーが大企業から契約書案を提示されたときに必ずチェックすべき5つのポイント(2)】そこで書ききれなかったポイントについて、今回は「知っておくと得する契約書TIPS7選」として紹介します。大企業から「これは雛形だから変更できません」と言われたら。大企業の担当者が契約書案を提示してくるときのマジックワードは「これは雛形ですので」です。その際にはだいたいWordなどの修正可能な形式ではなく、PDFファイルで送って来ます。「雛形」という表現や、PDFというファイル形式に込められている意味は「修正出来ないんですよ。このままサインして貰わないと困ります。」ということですが、そこでへこたれてはいけません。雛形の契約書案は先方の会社が定型的に使用しているものなので、提示された契約書そのものを変更して貰うのは、少なくとも相手の担当者レベルでは不可能なことがほとんど。そのような場合は「雛形の契約書はそのまま締結して、個別の条件については別途覚書を締結する。」という方法を提案するとうまくいくことがあります。「覚書」という文書のタイトルに先方が理由なき安心感を覚えるせいでしょうか、私の経験でも、多数の成功例があります(もちろん「覚書」も「契約書」と同じ効力を持ちます。この方法をとるときには1つ気をつけなければならないことがあります。それは「覚書と雛形が矛盾した場合は覚書に書いてあることが優先する」という一文を必ず覚書に入れておくこと。それをしないと、双方に矛盾する内容が記載されている場合にどちらが適用されるのかがわからなくなり,せっかく勝ち取った個別の条件を覚書に記載した意味が失われてしまうからです。契約書の案はどちらが作った方が良いのかこの点に関する結論は「自社にとって重要な契約であればあるほどベンチャー側で契約書案を作成して提示すべき」です。理由はあるのですが、私が重要だと考える理由はただ1つ。ベンチャー側で契約書案を作成して提示すべきただ1つの理由ベンチャー側で契約書案を作成すべき最大の理由は「契約書案を作成することで、契約締結交渉の主導権を握れる。皆さんのイメージでは、契約締結交渉は、「双方で十分交渉をして条件が確定した後に、その確定した条件を文章に落とし込んでいく」というものかもしれません。実際には、条件が完全に確定する前に、どちらかが契約書案(契約書の叩き台)を作成して提示し、その叩き台をベースに交渉して条件を確定していくことが多いのです。交渉のスタートとなる契約書案をこちらが作ることで、こちらの考えを元にした叩き台ができ、それを元に交渉をすることで、こちらが優位に立てることが多いのです。提案した契約書案がそのまま通ることはほとんどありません。相手が希望する条項が付け加わったり、こちらの希望する条項が削られたりしますが、それでも叩き台に含まれていた内容が全く跡形もなくなるということはほとんどありません。したがって、契約書案をどちらが作成するかという時点から、主導権争いは始まっているのです。重要な契約書であればあるほど、「あ、とりあえず叩き台をこっちで作成しておきますよ~」と軽く伝えて、必ずこちらで契約書案を作成しましょう。先方担当者が、先に契約書案を作成することの重要性をわかっていなければ、手間が省けたと喜んでこちらに任せてくれるでしょうし、逆に「いや、こちらで作ります」とかたくなに言い張る担当者がいれば「こいつはわかっているな」と判断して間違いありません。いってもコストが・・・・もちろん、すべての契約書案をベンチャー側で作成するのにはコスト的に不可能でしょうから、会社にとって重要な契約に絞ってそのようにすれば十分です。リーガルコストはかかりますが、重要な契約について、ベンチャー側にすこしでも有利な条件で締結できるのであれば、必ず元は取れます。ベンチャーが大企業と締結する契約の種類は大きく分けて2つベンチャーが大企業と締結する契約の種類は実に様々です。サル契約など多種多様です。何かの成果物を制作して納品するパターン(成果物納品型)の2つに分けられます(もちろん、両方の性質がある契約もあります)。実は、このうち1の「何かの作業・業務を受託するパターン(業務委託型)」でよく起こるトラブルがあります。「受託した業務を完了した」「していない」のトラブルそれは、「受託した業務を完了した」「していない」のトラブル。サル契約などが典型例です。マーケティング等業務全般に対する指導を行う」としか書いていない契約書をよく見かけます。いう曖昧な契約書では「委託した業務を完了していないからお金は支払いませんよ」というトラブルが起きても全く不思議ではありませんし、トラブルの時に泣き寝入りせざるを得ないのはたいてい受託側です。ベンチャーの場合「受託側」が多いでしょうから、この手のトラブルをどう避けるかは必ず知っておくことが必要です。ちなみに、2の成果物納品型は、完成した成果物を納品すれば一応は業務が終了します。「どこまでやったら業務を終了したことになるのか」という問題、つまり業務内容が不明確という問題はあまり起こりません(もちろん納品した成果物に欠陥があるかないかというトラブルはあるのですが)。▼トラブルを避けるコツ2つこのような委託型の契約でのトラブルを出来るだけ避けるためのコツが2つあります。1つ目は「委託業務の内容を出来るだけ定量的に定める」ということです。サル業務なら月●回、1回●時間以上、あるいはリサーチ業務ならリサーチ対象やリサーチ回数などの最低限の数字を明確に定めるとよいです。1つ、私のこれまでの経験から特に効果的だった方法があります。それは「業務委託型の契約でも、できるだけ成果物納品型に近い形にする」というものです。業務委託型でも、「何か成果物を作成して納品すること」を業務にするのです。サル契約であれば、「コンサル実施」のみを業務とするのではなく、「コンサル実施+コンサル結果をまとめた報告書の作成」を業務にするということです。この報告書にはどのような項目をどの程度のボリュームで記載するのかということまで契約書レベルで確定させるのです(報告書の書式を契約書に「別紙」として添付して「別紙様式の報告書を作成・提出する」とできれば、受託側にとってベストです)。することで、「受託した業務を完了した」「していない」という業務委託型特有のトラブルをかなり減らすことが出来ます。長期間にわたる業務を遂行する契約を結ぶことが多いと思います。そのような契約の問題点は2つです。途中で研究開発が失敗した際に一切支払いを受けられなくなるリスクがあるこのような問題点は、「報酬の貰い方」を工夫することで解決できます。基本的な方法は、「業務を段階化して、各段階で報酬を支払って貰う」というものです。プログラミング、テスト、納品等)に応じて、完成するたびに報酬を支払って貰うというものです。1つのパターンは「定額払い+各段階での成功報酬の組み合わせ方式にする」というものです。最低限の定額報酬を支払って貰いつつ、各段階における「成果」を定義しておき、当該成果が達成できた際には成功報酬を支払って貰うという方式で、ベンチャー側のリスクを相当軽減することが出来ます。このように「報酬の貰い方」を工夫することで、資金繰りに余裕をもって業務に取り組むことが出来ますので、成果も出やすいのではないかと思います。契約締結交渉ではそこら辺も強調しつつ、合理的な条件を勝ち取りましょう。契約書がないまま業務を開始せざるを得ない場合この長い記事を読んでいる皆さんは、契約書の重要性をいやというほどわかっているはずですが、ベンチャーの場合どうしても弱い立場なので、時には、相手から急かされて契約書がないまま業務を進めざるを得ない場合があります。ひどい場合には、業務提供と平行して契約交渉を行い、業務が全て完了した「後」に、契約書がようやく完成する、というパターンもあります。このように「契約書がないまま業務を開始せざるを得ない場合」には、メールでやりとりをしたり、あるいは打ち合わせ直後に議事録を作成して送付したりするなど、なるべくやりとりを文書化・記録化するようにしてください。メールのやりとりや議事録の送付だけで即、そのような合意があったということにはなりませんが(とくに日本の裁判所は「契約書」という形式を非常に重視し、「契約書」に記載されていない条項は合意が成立していないとみなす傾向が強いです)、すくなくともトラブルになった際の手がかりにはなります。議事録の作成・送付という一見地味で日常的な作業の積み重ねが、その後のトラブル発生の際に大きな力を発揮するところを、私たちはこれまで数多く見てきました。相手から提示された契約書案を見て「あれ?この場合のことが書かれていないが、実際にはどうなるんだろう」「なんでこれが書かれていないんだろう」と気づくことができれば、たいしたものです。その疑問、ストレートに相手にぶつけない方がいいかもしれません。契約と法律の関係で知っておくべき2つのことまず、契約と法律の関係について、以下の2つは押さえてください。法律に書いてあることでも、契約で法律とは別の約束をすれば原則として契約の方が優先する。契約に定めていないことがある場合には、自動的に法律に従うことになる。ソフトウェア開発契約において納品物に欠陥があった場合に受託者側が負う責任として瑕疵担保責任という責任があります。民法では「納品後1年間」受託者が瑕疵担保責任を負うことになっていますが、当事者間の契約で「納品後2年間」とすれば2年間になりますし「瑕疵担保責任は負担しない」と約束すれば責任は発生しないことになります。2については、同じソフトウェア開発契約における瑕疵担保責任のケースでいうと、契約書上何も瑕疵担保責任について定めておかなければ(まあ、そういうことはほとんどありませんが)、その点に関しては民法が適用され、「納品後1年間」受託者が責任を負うことになる、ということです。経営者向けのセミナーなどをすると、1を知っている人はかなりいるのですが、2を知っている人はあまりいません。契約で定めていないことは法律にしたがうでは、この2、つまり「契約に定めていないことがある場合には、自動的に法律に従うことになる。」から導かれることは何か。それは契約書に書かれていないことには法律が適用されるが、それが自社にとって不都合ではないときは放っておく。「ソフトウェア開発の委託を受けたが、開発したソフトウェアの著作権の帰属に関する条項が契約書上見当たらない。契約で定められていない以上、著作権の帰属については、著作権法という法律が適用されます。著作権法上は著作物の「創作者」に自動的に著作権が発生することになっています。したがって、ソフトウェア開発者側としては、あえて著作権の帰属について契約書に記載しなくても全く構いません。相手に「あれ、この契約書にはどちらに著作権が帰属するか書いていませんよ?」なんてお人好しに指摘する必要はありません。「あ、そうか、ありがとう。こっちがお金払うんだからこっちに権利は全部あると言うことでいいよね」と言われるのが関の山です。どれも同じ意味なのでしょうか?」あるいは「「覚書」だから契約書と違って軽くサインしても大丈夫ですよね?」という質問があります。「覚書」だからといって軽い気持ちでサインしないこと、です。これは是非覚えておいてください。大企業から「これは雛形だから変更できません」と言われたらどう対応したらよいか」で書いたように、こちらの要求事項はあえて「覚書」という形式にして提案し、相手の心理的ハードルを下げてあげることもあります(で、実はけっこうこの作戦は効果あるんですよね。この記事を読んだ皆さんは、そのようなことを言われてもくれぐれも勘違いしないようにしてください。大企業から「これは雛形だから変更できません」と言われたら、雛形+覚書の形式で合意した条件を契約内容に盛り込む。契約書の案は、重要な契約書ほど自社で作成し、契約締結交渉の主導権を握る。「業務完了した」「していない」の揉め事を避けるためには、まずは業務内容を定量的に定め、かつ委託業務型から成果物納品型に契約の内容を変える。長期間にわたる契約で資金繰りに困らないためには、報酬の貰い方を工夫する。契約書がないまま業務を開始せざるを得ない場合には、メールや議事録の送付など、やりとりや決まったことをなるべく書面の形で残すようにする。書いてあるべきことが契約書に書いてない場合には、法律が適用されるため、それが自社に不利益でなければ黙っておく。2019/08/26CtoCサービスに激震。reserved.お問い合わせ・ご。