契約書は人間を動かすプログラムだ

スマホの購入、アプリのインストール、住宅の賃貸などなどの際に、
利用規約やら契約やら、やたらと長い文章に合意させられますよね。

どこに重要なことが書いているのか、パッとみてわかる人はほとんどいないと思いますし、
「よくわからないけれど、騙されはしないだろう」
と楽観して承諾している人が大半でしょう。僕もその一人です。

なんで契約ってわかりにくいんでしょう？？

最近、仕事で契約書のドラフトを作る業務があり、
久しぶりに契約書を準備しました。

僕の勤め先では契約書のフォーマットがあるのですが、
「この仕事の場合はこの条文を入れる」などの説明はあるものの、
いまいち全体像がわからないまま作っちゃってます。

そして法務からレビューを受けて修正され、
相手先からも修正要望が入り、それらを調整したらようやく締結です。

面倒な理由の一つとして、契約書って一つの条文だけを読んでも、それだけで意味がわかるようになってないことが挙げられます。

例えば、「Aの場合はBとする」と書かれた条文があるかと思えば、別の条文で、
「第⚪︎条(さっきの条文)に関わらず、Cの場合は、Aの場合であってもDとする。」
といった例外条件があったり、
他の場所で定義された言葉がそのまま使われていたり、
一つの条文で言っていることが全てじゃないのがやっかいです。

また、第二の理由として、「もし取引先が破綻したら、、、」などの、
万が一の場合に備えた条項をどこまで必要なのか、という問題があります。
「相手が破綻した場合」などを書いて、相手の心証が悪くなることもあるでしょうし、
かといって、何も書かないのもリスクになるので、判断が難しいです。

面倒なことには変わりないのですが、
「契約書は人間を動かすプログラム」だと気付いて、
プログラミングは面倒だもんなぁ、と納得しました。

コンピュータを動かすためのソースコードが書かれるように、
人間を動かすためのソースコードとして、契約書が書かれているイメージです。

契約書がコンピュータ言語に似ている点は大きく3つです。 

①言葉(変数)を一度定義して、その言葉を使うことで、言葉の定義変更に柔軟に対応できる点
よく第2条あたりで、言葉の定義欄があって、その言葉で条文が書かれていきますよね。また、条文内で言葉を定義して、別の条文で、定義した条文番号を示して引用する形式もたまに見ます。

プログラミングで、"var i as integer; i = 10" なんて定義してから使うのと同じだなと思います。

②通常運用時だけでなく、エラーが起きた場合のことを多く記載する点

プログラミングでは、通常想定されている動作からハズレた場合にエラーを出すため、
ある程度エラーが起きそうな場面を想定して、「その場合にはこうする」
といったプログラムを書きます。

契約書でも同じように、異常な事態が生じた場合の対応が一定程度書かれています。
リスクが高い状態が想定されるなら、その場合の対応を記載するのは当然でしょう。 

書いていないと、万が一その状態となった際に、被害が広がる一方になります。

③具体的に、いつ誰が何をどのようにやるか、指示が明確な点

契約書には、甲乙の主語が最初に定義されて、
「甲が●●した場合、乙はxxをする。」
など、主語と動詞が明確に対応している文章が多いです。

また、お金のやりとりが発生する場合には、振込先、振込期日、金額の決め方など、
契約上細かく定義されているのが通常です。

契約に書かれた指示に従って、将来人間が動くことになります。

プログラムによってコンピュータを動かすように、
契約書によって、特定の人間を動かすことで、仕事が回るのです。

契約書を締結しなきゃ、例えばある仕事をしたとしても、
その仕事に対する料金が振り込まれなかったりすることがありえます。
口約束も契約ですが、言った言わないの証明が困難ですし、
現代では「契約書」による取引が一般化しています。

音声保存での契約でも良いんじゃないか？とも思うのですが、
やはり、紙の文章のほうが、網羅的に、異常事態が生じた場合の定義ができますし、
口約束は言い間違いも生じやすいので、紙の契約が勝るのでしょう。

特にB2Bの仕事の場合ですが、契約書は契約相手を動かすためのプログラムなので、
面倒臭がらずにちゃんと作りましょう。
というお話でした。

それではまた。