2005年06月23日
プログラミングと契約書起案の類似点
プログラムも書いていて、でもってビジネス判断なんかもやっている友人に、契約書の解説をしていたら、「契約書って僕には言葉遊びにみえる。プログラミングみたいだね」と言われて、「全くその通り！」と思った。
ただ、私はすっごく重要な１点だけが違うと思っている。それは実行者。
プログラムはコンピュータが実行する。だから、曖昧な点や分からない点があるとすぐにエラーを出す。だからすぐに間違いに気づける。（時々自分が変に間違っててエラーも出ないで動いちゃうときもありますけど…）
契約書は人間が実行する。曖昧な点や分からない点はうまく咀嚼して処理をする。だから、変な文書でも通ってしまうことがある。
でも、目指すところは同じ。コンピュータ／会社に「何をして欲しいか」「それにはどういう条件に従わなくてはいけないか」「何をしては駄目か」そう一連の手続きや決まり事を定めるためのもの。
例えば、「契約書語の理解のために」からルールを引用してみると、
一般的用途以外で使用する語句や人によって解釈分かれる可能性がある上に何度も登場する語句は必ず定義する。
cf.「小会社」「製品」などなど。
契約書では、何度も出てくる語句はそのたびに詳細に書くと契約書が長くなるし、一カ所直したときに、他の箇所も必ず直すことを覚えているとは限らなくてメンテナンス性がとても悪いから、最初に「○○とは＿＿＿＿で＿＿＿＿で＿＿＿＿な××をいう」という定義をするのが一般的です。
日本語では短い契約書も多いので、そのときは「＿＿＿な××（以下「××」という）」などと短く本文中に定義を書いたりします。
この定義っていう行為が必要な理由は、きっと、オブジェクト指向でプログラミングするべき理由と似ているはず。
（オブジェクト指向プログラミングが求められる理由には、計算機自体の特性なんかも関係ある気がするので、それは省く。人間はどちらかというと、逐一書いてあるほうが読みやすいですよね…）
定義していない語句は使わない。
cf.目的が書いていないのに「本目的」、定義がない「本成果」など。
定義ってつまりは、同じ処理を繰り返し書くことを省くためにもうけられるクラスやインスタンスと同じことだと思うので、「作っていないクラスやインスタンス」は使わない、ってことでプログラミングでは至極当たり前で「そんなことしたら、コンパイルしたときにエラーが出るよね！」ってことだと思うんです。
定義しないときは、必ずその都度明確にする。
cf.「小会社（ここで小会社とは～」
クラスやインスタンスを作らなかったら、そのたびにコピペして、同じコードを書いてあげなきゃいけないんですよ。って、当たり前ですね。
主語や述語を明確にする。
誰が何の義務を負って、何の権利があるのかはっきりしないとビジネスにならないので。
プログラミングは各関数が、それぞれどういった形態で使用可能か、どういう引数をとれるかがきちんと決まっているので、きちんとした引数を書いてあげないとエラーが返ってきます。当たり前です。
でも、人間は主語のない文書や目的語のない文書でも平気で締結して実行しちゃうんですよね。特に日本語だと。そして、将来「この主語はＡ社と読めますよね、普通」「いや読もうと思えばB社とも読めます。むしろあえて書いていないところからすると、B社とも読もうとする意図があったと考えられる」とよく分からない問題が勃発。
意味や意図の分からない相手方修正案、相手方ひな形の中の文書は受け入れない。
何したらいいか分からなかったら、プログラムは動かなくてハングアップしてくれたり、その前のコンパイル段階でエラーを返してくれたりするからすぐ分かっていいですね。
また、IT業界で見聞きすることなどは法務にもあてはまったりします。
どんどん新しい言語を覚えなくてはいけない！
法律は次から次へ出来るんですよ。新しい局面に対応するために。どんどん新しい言語を覚えなくては行けません。
複数の言語（や機種）で動くプログラムを作るのは困難
異なる法律をいくつもカバーする契約書を作るのってかなり難しいです…。各国リーガルに聞かないと分からないの。
移植は大変なときがある
資本主義の国同士の企業で使っていた契約を、共産主義の国へも使えるように改変しようとするとかなり大変です。土地が借りるのは可能だけど、所有は国家だけが可能だったりするんです。
前の人の作ったアルゴリズムは色々検討して、長いソースが短くなっているから参考になる
長々と書くべきところをどう短く書くかや、自分が新しく書いたことが必要なことを網羅しているかどうかは不安なものですが、何十年も続いて来た契約書があると、「ま、いま想定できるリスクはここに入ってるんだろう」と、そこは安心して使用できるものです。
大人数でプロジェクトやる場合、ルールをはっきりしていないと出来たプログラムの共有がたいへん
同じプロジェクトを別の側面から切り取った二つの契約書を分担して書くと、○○さんの書いた契約書と××さんの書いた契約書が矛盾してた！ってことになりがちです。
だから、情報共有や打ち合わせが欠かせないのですが、とっても工数がかかる…。
まあ、仕事の悩みは同じってことなのかもしれません。
投稿者 michy : 2005年06月23日 21:08 :
法務っぽい
| 
関連しているかもしれないエントリ：
印紙税のかからない主な場合座右の書としたい本
「契約書をみろ！」「いや、ソースを読め！」
メールは証拠が残るから便利
契約書語の理解のために
トラックバック
この記事のトラックバックURL:http://michys.com/michy-mt/mt-tb.cgi/2948
ratio - rational - irrational:「EBNF立法論」
法律の条文が「ソースコード」として美しくないことについて。
