【要約】
はじめに
僕の専門は今でも「特許」であるが、スタートアップにジョインしてからは契約に触れる機会が激増した。
特許を見ない日はあっても、契約を見ない日はない。
これは至って自然なことである。
スタートアップには技術アセットがないのであるから、業務委託契約や雇用契約まで含めて考えると、契約を起点として技術開発が進む。
そのため、知財家が契約を見ることのROIが大企業のそれよりも大きくなり易い。
不慣れな契約業務を通して気付いたのは、「契約はプログラムである」ということ。
ここで言う「プログラム」とは、いわゆるソフトウェアエンジニアが作るコード(コンピュータプログラム)の意味ではない。
本記事では、解像度が粗いことは承知の上で、僕の現時点仮説「契約≒プログラム」の導出を試みた。
前提
「契約」とは何か
そもそも、「契約」とは何なのだろうか。
まずは、法務の総本山「法務省」の定義を見てみよう。
ここからキーワードを抜き出すと、次のようになる。
相手方に考えを伝え、それを「約束」というステータスに昇華させる。
法務省の解説に照らすと、「契約する」という行為は、このように理解できる。
「プログラム」とは何か?
「プログラム」と言うと一般には「コンピュータプログラム」を想起させるが、僕は、「プログラム」を「読者を意のままに行動させるための言葉」だと考えている。
デジタル大辞泉の定義からキーワードを拾ってみると、以下のようなワードが目につく。
計画や予定
演目・曲目・番組・番組表
計算や仕事の手順を…書いたもの
何れも、プログラムをインストールされた対象物(人間やコンピュータ)は、プログラムに沿って振る舞う。
つまり、「プログラム」とは、「対象物を意のままに行動させるために、対象物が理解可能にコンパイルした言語」と言える。
契約≒プログラム
契約がプログラムたる所以
(観点1)期待
「契約」を締結した両当事者は「契約に記載された義務の実行により、契約目的の達成」を期待する。
これはまるで、「ソースコード」を実装したら、「ソースコードの実行」がなされ、その結果として、ソースコードによって実現されるアプリケーションが期待通りの出力を出すことが期待されるのと酷似している。
(観点2)言語
事業担当者やエンジニアに聞くと、「契約書を見ると吐き気がする」と答える人が少なくない(これは、特許書類でも同様の傾向がある)。これは、文法を知らない専門的な言語(リーガル言語)で記述されているからであろう。
僕はコーディングの経験がほぼないので、例えば、エンジニアが書いたコードを見ると吐き気がする(コードを読むのは好きなんだけど)。これは、文法を知らないプログラミング言語で記述されているからだ。
そう考えると、特殊な文法で表現された構造化言語的という点では、両者は共通していると言える。
(観点3)進め方
契約書を作るときは、いきなり書き始めるのではなく、契約目的(例えば、事業計画)のヒアリングが重要である。
ソースコードを書くときは、アプリケーションによって実現したい機能を明確にするための要件定義書を作ることが重要であるはずだ。
つまり、契約書を作ることよりも、契約目的に照らして契約を設計することの方が重要である。
LLMの普及によりコードの生成は自動化が進んだが、「そのプログラムによって実現したいこと」の設計は、引き続き、人間がやることになるだろう。
これは、契約書レビューにLLMを用いたとしても人間が果たす役割が残ることと同様である。
事業に契約をインストールする
事業は、事業計画を立案するところから始まる。
この事業計画はさながら、事業の要件定義書のようなものだ。
であるならば、事業に関わる契約は、事業計画という要件定義書に沿ってリーガル言語で記述されたソースコードである。
契約締結とは、事業というOS(ビジネスモデルというアーキテクチャの土台)に契約というソースコードをインストールすることと同義である。
契約がプログラムであるならば、契約書を作成するときに心がけるべきことは何か
契約審査業務(契約書を作成する業務)では、「我が社の事業担当者は、どのような手順で事業を成長させたいのか」を常に意識する必要がある。
一般的に自社に有利な条件(例えば、自社に知財が帰属するという条件)であっても、その有利な条件が事業計画に織り込まれていない場合(例えば、他社と知財を共有することにより事業を成長させる計画である場合)には、悪い契約(要件定義書に沿っていない契約)になる。
逆に、契約書の作成中に「自社に不利な条件」に気づいたときにやるべきことは、「自社に不利な条件です」という警告よりもむしろ、「事業計画という要件定義書にバグがある」という警告であり、「自社に有利な条件に書き換えることで、事業計画はこう変わる」という提案であろう。
契約をコンパイルする
上記のとおり、契約は事業担当者が理解困難なリーガル言語で書かれている。
したがって、事業に契約を実装するためには、事業の実行者である事業担当者が実行可能なオブジェクトコードに変換する必要がある。
この変換は、契約担当者が担うことになる。
つまり、契約担当者は、契約をコーディングするだけでなく、契約のコンパイラにもなる。
契約目的を達成するために、契約書を作成した後も、事業担当者が契約どおりに行動できるように、ありとあらゆる方向で事業担当者を支援(コンパイル)することが契約担当者の重要なミッションである。
契約締結後に事業担当者の意図と契約とが一致しないこと(バグ)を発見したら、バグを取るためのパッチ(覚書)を当てることも契約担当者の仕事である。
日本人プログラマーの始祖
上記のとおり、プログラムの定義を「読者を意のままに行動させるための言葉」だとするならば、契約以外にも以下のものがプログラムに含まれる。
テレビ番組表
学芸会の演目表
楽譜
演奏者は作曲家の意のままに演奏する。
ギターの楽譜では「コード」という表現が使われる。
法規
自然法則
これはとあるエンジニアからの受け売りなのだが、このように整理すると、日本人プログラマーの始祖として、聖徳太子を挙げることができる。
彼は、日本社会(OS)に、十七条の憲法(アプリケーション)を実装することで、国民(ユーザ)に秩序(価値)を提供した。
まとめ
スタートアップにジョインして契約の仕事に携わった当所は、戸惑いが多かった(今でも不慣れな法律が出てくると戸惑うのだが)。
しかし、戸惑ってばかりではスタートアップの成長に貢献することはできない。
そこで、自分の専門であるソフトウェア特許の明細書と同じ思考回路を開放してみた。
すると、戸惑いが減ったのだ。
契約書の文言がフローチャートに脳内変換されるようになってきた。
フローチャートにできるのなら、契約はプログラムであるとみなせる。
ビジネスモデル発明の明細書を書くことと、事業計画の契約書を作成することとは本質的に同じものであると気づいた。
例えば、SaaSサービスの利用規約の作成は、ソフトウェア明細書の作成とかなり近い感覚を覚えたことがある。
まるで発明をしているかのようだ。
参考「十七条の憲法(原文及び現代語訳)