「契約書を読むのはデバッグ作業」元エンジニアの弁護士に聞く、自分の身を守る項目チェックの方法

フリーランスが企業と仕事をするうえで、必ずやらなければならないこと。そのひとつが「契約」です。

契約書に目を通し、その内容を理解して、異議があれば交渉する……。これが、とても大事な行為であることはわかります。やらなければならないのはわかるんですが……どうにも、契約書の内容が頭に入って来ないんです。読んでいるうちに、どちらが甲でどちらが乙なのか、分からなくなってしまう人も多いでしょう。

2021年3月、経済産業省にて「フリーランスとして安心して働ける環境を整備するためのガイドライン」が策定され、企業はフリーランスと仕事をする際はきちんと書面を交わすことが推奨されることになりました。となれば、フリーランスワーカーはこれまで以上に、しっかり契約書に向き合わねばならないはず。

しかし、どうして契約書ってあんなに難しいのでしょう？　契約書が苦手な人でも、最低限チェックしなければいけない箇所はどこなのでしょうか？　モノリス法律事務所 代表弁護士の河瀬季さんに「契約書のキホン」を聞きました。

契約書チェックは「デバッグ」。あとで揉めやすい4つのポイントとは

――契約書を読むのって、どうにも苦手なんです。大事なことが書いてあるのはわかるんですが……「この辺を見ておけば大丈夫」みたいな、楽して契約書をチェックする方法はありませんか？

河瀬さん：難しいですね……。結局、読むしかないんですよね。

――やっぱり読むしかないですか……。

河瀬さん：いくら読みにくいとはいえ、契約書は日本語で書いてありますから。プログラム言語よりも読み解きやすいと思いますよ。そもそも契約書のチェックって、プログラムのデバッグみたいなものなんです。

▲ 弁護士になる以前はITエンジニアとしての経歴をお持ちの河瀬さん。ちなみに、高IQ団体「JAPAN MENSA」の会員でもある（写真提供：モノリス法律事務所）

――デバッグ？　法律とはだいぶ離れた言葉のような気がしますが。

河瀬さん：プログラムは、基本的に「人間から言われた通りのこと」しかしませんよね。もし人間にとって想定外の動きをすると、それは「バグ」として扱われます。

例えば「ボールが壁に当たったら跳ね返る」というプログラムを書いたはずなのに、ボールが薄い壁をすり抜けてしまったとします。でも、これに「想定外だ！」と思っているのは人間だけで、プログラム的には、あくまでも「言われた通り」のことをしているだけのはずなんです。

――そうですね。本来は「壁が薄くても大丈夫なように」と、作る側が事前に想定してプログラミングしないといけないわけですから。

河瀬さん：つまり、想定外のことが起こるのは、本来必要なアルゴリズムが不足しているから。契約書を読む場合も同じで、いかに「想定外」をつぶすかがポイントになります。「こういうパターンもあるよね」「このケースが起きたときはどうする？」と考えるのは、エンジニアの皆さんは得意でしょう？

――なるほど、書いてある内容だけでなく、「どういう状況がカバーできていないのか」も気にしないといけないと。では、「最低限これは書かれているかチェックしたほうがいい」という項目はありますか？

河瀬さん：基本となるのは「業務の具体的内容」「報酬が発生する条件」「成果物の権利」「損害賠償の範囲」あたりでしょうか。だいたいこの4つで揉めますね。

――「業務の具体的内容」で揉めるのは、なんとなく想像できますね。「報酬が発生する条件」というのは、「何が完成したらお金を払うか」みたいなことですか？

河瀬さん：それもあるんですが、もうひとつ注意すべきなのは「報酬が発生する条件」と「報酬の支払日」は別の概念であることなんです。

例えば、Webサイトを作る仕事があったとします。報酬が発生するのは「成果物を納品した段階」で、支払いは「Webサイトの公開後」と契約書で定めたとする。この場合、納品は期日通りにできたのに、納品先の都合でサイトの公開が遅れてしまったら……？

――サイトが公開されるまで、指をくわえて入金を待っていないといけない……！

河瀬さん：「何をしていくらもらうのか」。そして、「その報酬は“いつ”もらえるのか」。しっかり確認しておきたいですね。

――次の「成果物の権利」は著作権やライセンスの話ですよね。これってどう決めるのが一般的なんでしょうか？ 違いがよく分かっていなくて……。

河瀬さん：これは不動産に例えるのがわかりやすいかもしれませんね。大家さんとしてアパートの所有権を持つのが「著作権」で、アパートの部屋をどう貸し出し、使ってもらうか「ライセンス」なんですね。

こう考えると「部屋を月額払いで貸し出す」「アパートを丸ごと譲渡する」「一定の条件で部屋を無料で使ってもらう」など、ライセンスの扱いにさまざまなパターンがあるのが分かると思います。

――なるほど。「部屋を貸すつもりだったのに、アパートを丸ごと取られてしまった」みたいな時に揉めるわけですね。

河瀬さん：その通りです。著作権という本体と、それに付随するライセンスをどう動かすかという話なんですね。どのパターンにするかはビジネスによるので、ケースバイケースです。珍しいケースでは「ライセンスは相手に渡すけど、著作権は自分に残してもらう」ということもありますしね。

▲ 「契約書とデバッグ」については、河瀬さんが書いたモノリス法律事務所の法務記事から

――よくわかりました。最後は「損害賠償の範囲」です。これはつまり、「大きなトラブルが起きたときに、フリーランス側がどれだけ責任を負うのか」という話ですね。

河瀬さん：ここで必ずチェックしたいのが、「損害賠償の上限額」です。これが定められていないと、青天井で賠償金を支払うことになると思っておいたほうがいいです。エンジニアだと、それなりの金額が動くシステムに関わる可能性があるので注意が必要ですね。

また、逸失利益を支払うことになっていないかも確認しましょう。これは「あなたのせいでローンチが1週間遅れた。1週間で稼げるはずだったお金を払ってほしい」という話ですね。ただ「ローンチの遅延」については「定めた期日通りに成果物を納品できていない」わけなので、そもそも契約違反の問題になってしまうのですが……。

契約書だけでなく、トラブル時は日々の議事録も強い味方に

――それにしても、なぜ契約書ってあんなに難しい書き方なんでしょうか……。もう少し分かりやすい書き方の書類があってもいいと思うんですが。

河瀬さん：契約書というと、多くの人が「甲と乙」で書かれたものや役所の書類のようなものを想像すると思うんですが、本来、契約書は形式が決まっていないんです。どんな体裁でも大丈夫なんですよ。メールやチャットのような自然言語で書かれたものでも、双方の合意があれば契約の書面として認められますし。

――そうなんですか!?

河瀬さん：もちろん、ショートメッセンジャーやビジネスチャットは後から送信取り消しや編集もできるので。ツールによっては届いた段階でスクリーンショットを控えるなどする必要があります。

――それが、なにかあったときの証拠になるんですね。

河瀬さん：ただ、メールやチャットは口語で書かれたものなので、どうしても曖昧さは残ってしまいます。Zoomで著作権の相談をしたあとに、Slackで「すいません、さっきのアレはやっぱり無理です」と書かれても、「アレ」が何を指すのかはっきりしませんよね。

――確かに。その場で話が通じても、あとから「あれは違う意味だった」となるかもしれませんしね。

河瀬さん：もう少し書面らしいものだと、「3条書面」というものがあります。親事業者が下請事業者に交付しなければならない書面のことで、下請法3条に定められているものです。

書面に書くべきことは決まっていて、下記の12項目あります。言い換えれば、下請法ではこの12個を「契約において重要なポイント」だと考えているわけです。

▲3条書面については上記の通り。各項目の後半（“＝”以降）は編集時に追記した「要するに、こういうこと」

――ばっちりまとまっていますね。もうこれで十分な気がしてきました。

河瀬さん：大筋はこれでも良いのですが、3条書面には先ほどの「損害賠償の範囲」などは含まれていないんです。詳細なルールについては、契約書で別途定める必要があります。

――やっぱり、最終的には契約書は重要なんですね……。

河瀬さん：契約書はやっぱり強いですよ。契約書に書いてることを後から覆すのは相当難しいですから。

ただ、これは「契約書がないとどうしようもない」という意味ではありません。契約書がない場合でも、他になんらかの書面があれば、戦う方法があるよということなんです。

――しかし、業種によっては案件における作業内容が流動的なケースもありますよね。案件のスタート時に契約書を作り、お互いの合意を取っても、仕事が進むにつれて業務内容や目標とする成果物が変わっていく……ということもありませんか？

河瀬さん：あります。そもそもエンジニアの場合、契約時に細かな要件が決まっていないこともよくありますよね。なので、スタート時の契約書だけで全てをカバーしようとするよりは、日々の議事録を残していくことを意識すべきでしょう。契約書に書かれていないケースが起きたら、その都度、内容をテキストに残し、合意を取る……という感じで。

▲契約書の内容をベースにしつつ、例外が発生した場合はその都度双方で話し合いの場を設ける。合意をとった内容は議事録にまとめて、お互いが確認できる場所にシェアするまでが一連の作業となる

――契約書の内容をベースにしつつ、細かい議事録を残して、合意の内容をアップデートしていくイメージでしょうか。

河瀬さん：これは、打合せなどで決まったことを議事録にまとめて、相手に「こういう理解で大丈夫ですよね？」と釘を刺すだけで十分です。理解が違っていれば修正依頼が来るでしょうし、特にレスが来なくても、記録を取ることに価値がありますから。

合意を積み重ねて、不明瞭な部分を固めていく。その過程を議事録として記録に残すことが、フリーランスにとって自衛になると思います。

――その結果もしトラブルが起きたら、契約書の内容と議事録などを追って、「最終的に、どのような内容で両者の合意がなされていたのか」を確認するわけですね。

河瀬さん：事務所として契約関係の相談を受けたときも、双方で取り交わされた契約書とどのようなコミュニケーションが行われたのかを確認します。最終的にどのような合意がなされていたのか、メールはもちろん、Slackや、場合によってはLINEをチェックするときもありますよ。

「わからない場合は聞く」「不都合な契約内容は交渉する」が基本

――フリーランスといえば、2021年3月に「フリーランスとして安心して働ける環境を整備するためのガイドライン」が経済産業省で策定されました。このガイドラインによって、どんなことが変わるのでしょうか？

河瀬さん：正直なところ、このガイドラインは仕事のやり方などを変えるものではないんです。フリーランスが働くうえで、どういう場合に下請法や独占禁止法が適用されるのかを、明確にしたものなんですね。

フリーランスの方々は、法律に詳しい方ばかりではありません。本当は違法な行為でも、事業社から「これは普通のことだから」と押し切られてしまうこともあるでしょう。ガイドラインをしっかり読めば、押し切られそうになっても「これは違法なんだ」と判断しやすくなると思います。

▲経済産業省WEBサイトより「『フリーランスとして安心して働ける環境を整備するためのガイドライン」（案）に対するパブリックコメントの結果及び同ガイドラインを取りまとめました」。同ページ「関連資料」内にはガイドラインの内容がまとめられており、受注側・発注側どちらであっても一度目を通してみてみては

――全フリーランスが読んでおくべきガイドラインですね……。

河瀬さん：あとガイドラインでは「発注業者は事業の規模にかかわらず、フリーランスに対して3条書面を出すこと」が推奨されています。正式な契約書でなくてもいいから、きちんと条件を明確にした書面を取り交わしましょう、という考え方になってきていますね。

――フリーランスが書面を見るときは、3条書面に書かれるべき12項目と、「業務の具体的内容」「報酬が発生する条件」「成果物の権利」「損害賠償の範囲」の４つがチェックポイントになりますか？

河瀬さん：基本的にはその理解で良いと思います。それでもわからないことや、書面にまとまった内容に気になることがあれば、しっかり先方に聞くようにしてください。

ただ、口頭で合意したつもりで契約書にサインしても、合意した内容と違うことが契約書に書いてあったら、契約書のほうが強いです。そう考えると、やっぱり契約書はある程度自分で目を通せたほうがいいですね。

――やはり合意の内容はきちんと把握していないといけない、ということですね。話の流れで報酬が発生しない作業を頼まれたりするケースもあると聞きますし……。

河瀬さん：そうなったらもう、契約書ではなく、ネゴシエーションの領域になりますね。「分かりました」と合意して飲み込むか、「これだけ業務が増えたから報酬を上乗せしてほしい」と交渉するか、どちらかになると思います。

――なるほど。確かに、発注主から提示された契約内容に納得がいかない場合でも「契約内容を調整できないか、交渉してみる」こともできますから。ネゴシエーションも、常に選択肢に入れておかないといけないですね。

河瀬さん：下請法はフリーランスを守ろうとしてくれる存在です。でも、フリーランスが相手の言うことに合意してしまえば、その合意のほうが強くなります。最終的には、自分の身は自分で守るしかありません。

別の言い方をすれば、フリーランスはそうしたリスクを負っているぶんだけ、会社勤めよりも自由度が高く、高収入になりやい仕事です。会社勤めかフリーランスかを選ぶは人それぞれですし、そのメリットとデメリットは今後も変わらないかなと思います。

――だからこそ、フリーランスは自衛が必要ということですね。本日はありがとうございました。契約書も頑張って読めるようになりたいと思います……！

文＝井上マサキ／図版とイラスト＝藤田倫央／編集＝伊藤 駿（ノオト）