こんにちは。「リーダブルコード」を先月読破して、感銘を受けた弁護士の人です。
なにに感銘を受けたかというと、「エンジニアが高級言語を効率的にコーディングするための工夫」は、契約という言語をコーディングするために援用できることがとても多いということです。
例えば、リーダブルコードは「関数には空虚な名前（tmpとかretvalとか）でなく、エンティティの実体に即した名前をつけよう！」と提案しています。
これめっちゃわかります！！！なぜなら、契約言語では当事者というクラスの表現のために「甲」「乙」という定義を未だに使います。そして、甲と乙を逆に書いてしまったままReviewを通過することが実際によくあります。オライリーさんには激怒されるでしょう。
しかし、よく考えると高級言語と契約言語が似ているのは当然だと思うようになりました。それは、どちらも「一定のインプットを入れると、必ず一定のアウトプットが返ってくるように設計された独自の言語体系」だからです。 契約言語とは「一定の紛争⇒一定の判決が出るように構造化されたコード」です。処理するのがコンピューターではなく裁判官であるというのが違いでしょう。
調べれば調べるほど、プログラミングの世界でのこれまでの工夫は、契約言語の世界の未来の姿だと思うようになりました。ソフトウェア開発のプロセスになぞらえて、少し書いてみます。
ビジネスモデリング
モデリングの重要性
ソフトウェア開発においては、まず実際の業務をモデリングしますよね。まず業務要件を適切に分解することが重要で、クラスを定義したりER図を作ったりするのはその後です。ここを間違うと、プログラムとして内的整合性が保たれていても、実際には意味のない / 役に立たないものになってしまいます。
契約でも、最もセンスが問われるのがここです！実際の取引を、契約という独自の言語体系にモデリングしていきます。いくら契約のフォーマットが美しくても、実際の取引を反映していなければ、裁判で役に立たずにむしろ有害です。
ノーコード／ ローコードの流れ
そのため、プログラミングでも契約でも「コードを求めているユーザー」と「コーディングできる職人」とのコミュニケーションがとても重要です。
しかし、これが超難しい。契約の世界では、法務部と事業部とのやりとりにめちゃめちゃ時間がかかるのです。日本全体で契約のために消費している時間は、10億時間とも言われます。
そうすると「全部を職人さんがコーディングするのではなく、コードを求めている人でもコーディングできるようにしよう！」という流れが産まれます。いわゆる、ノーコード／ ローコードですね。
「契約のノーコード」は、LegalTechでもアツい分野の一つです。ChatGPTに契約を書かせてみたらどうなるのか…というtweetを当社創業者がしましたが、もし誰もがフェアな契約を瞬時にドラフトできれば、世界中のビジネスはものすごく加速するはずです。
ただ、「CopilotをProduction Codeに使うのはまだ怖い」というくらいの感覚で、NLPのなかでも生成モデルの活用は道半ばという感じです。契約の世界でも、生成モデルよりも検索や推薦アルゴリズムといったもう少し地に足のついた技術活用が進んでいます（後述）。
コーディング
DRY原則
プログラミングでは、汎用化できる部分はライブラリ化され、同じコードは何度も書かないようにすべきという考え方が当然のように受け入れられています（DRY原則）。
さらに、社会全体でも共通化できるレイヤーは、デファクト・スタンダードとなるようなプラットフォームからAPIが提供されています。当社も、SaaSプロダクトを提供するにあたってAWSを利用したり、随所でライブラリを利用することで、エンジニアがプロダクトのために必要な部分にフォーカスできるという便益を享受できています。
弁護士から見ると、これって本当に羨ましいことです……！
なぜなら、契約はその99.9%が過去のものの繰り返しであるにもかかわらず、毎回ゼロからコーディングしているからです。
契約言語には、未だにデファクト・スタンダードが存在しません！年間5億件も契約されてるにもかかわらずです！ クリエイティブコモンズやJ-KISSなど標準化が進んだ領域は、契約全体の0.1%未満です。
そのため、契約をしたい世のビジネスマンは、ライブラリ等を一切使わないフルスクラッチ開発を常に強いられて疲弊しています。ちなみにIDEのサポートもないのでデバッグ作業も重いです。 これは非効率だというのもありますが、めちゃめちゃつまらないことです。法務の人たちはとってもツラいのです。
デファクト・スタンダードと自然言語処理技術
プログラミングの世界では、長い歴史のなかでデファクト・スタンダードを積み上げてきました。 契約言語にも、今ようやくその機運が訪れています。その契機となったのが、実は自然言語処理技術の登場です。契約言語は比較的明確な構造を持っているため、自然言語処理技術との相性がとてもよかったのです。
私たちのようなLegalTechが広く使われていくと、社会全体で「どのような契約条件が標準なのか」がついに可視化されます。これまで弁護士の職人芸頼りであったものが、スタンダードを定量分析できるようになるかもしれません。
また、日本最高の職人＝トップ弁護士によるコードをオープンソース化する取り組みも始まっています。LegalTechは、フェアな契約言語へのAPIを提供するという社会的役割を果たそうとしています。
Review
ソフトウェア開発では、GitHubをはじめとしたバージョン管理システムを中心としたプラットフォームが当然に使われています。これがあまりに便利なので、当社では経営上の意思決定すらGitHubでPull RequestをApproveすることで実施しています。
かたや契約言語は、コードがベタ打ちされたWordファイルをメールに添付してやりとりすることで更新しています。交渉過程で、複数のビジネスマンが異なる修正をしたにもかかわらず、conflictに気づかぬままハンコを押してしまった…ということも起こります。 そもそも裁判では、取引先と最後に合意された契約コードだけでなく、そこに至るまでの更新経緯も参照されます。しかし、誰がなぜどのようにコードを更新したのかという情報は、たいていメールが離散してわからなくなっています。 これを解決するために、昨今のLegalTechは「契約のバージョン管理」に乗り出しています。一つのプラットフォームで契約言語のReview履歴が見れるように、これからようやくなっていくかもしれません。
管理・更新
プログラムは「動いてからが本番」であり、リリース後に改善活動がアジャイルに繰り返されます。ここがSaaSの面白さでもあります。
契約言語であっても、本来は同じです。そもそも契約言語は、裁判官というリソースが超貴重でテストが不可能であるため、ぶっちゃけ間違いが多いです。
また、「契約期間」というEOLもあるのでメンテナンスも必要になります。 他方で、契約言語は「現在有効なコードがなにか」ということすら管理することができていません（！）。これはすごい話で、なぜかというと、最終版のソースコードが紙で管理されているからです。
そのため、LegalTechベンダーは、OCRを提供するだけで喜ばれることもあります。さらに、自然言語処理技術によって契約期間を抽出し、メンテナンスが必要なタイミングでアラートを出すことができるだけでも社会にWOWを与えられます。
終わりに
こうして見ていくだけでも、契約言語はプログラミングの歴史から大いに学ぶべきであると痛感します。 さらに悪いことに、高級言語と契約言語との大きな違いがあります。それは「契約言語は、全国民が完全理解できることがなぜか前提になっている」ことです。ビジネスの世界では、契約言語を通じてしか、他者と関わることができません。
例えば、外部サービスを利用するときには、利用規約に同意する必要があります。あれって、皆さんは本当に読めていますでしょうか？ ぶっちゃけ、現状のものは弁護士である私ですら読む気にならないです。そのくせ「私たちは一切の損害賠償責任を負いません」だとか、明らかにアンフェアな条項がこっそり含まれていたりします。
LegalTechとは、契約言語をモダナイズし、誰でも他社とフェアな協力関係を築けるようなツールに進化させるものだと考えています。契約言語のノーコードと、充実したライブラリ推薦アルゴと、IDEと、GitHubを私はこの世界に送り出したい！（これが言いたかった)
今まさに社会が大きく変化しようとしているところですので、もし興味を持ったエンジニアの皆さまがいれば、是非私とカジュアル面談をさせてください！
※右上にも採用ページへのリンクがあります
