00:06
6月27日、火曜日ですね。
僕は朝9時33分になりました。
今日も暑くなりそうですね。
まあなんか、天気的には曇ってるんですけど、東京の方はですね、
気温と湿度ともにちょっと高くてですね、
むしゅめしした暑苦しい日がなんか今日も行われそうだなって感じですね。
はい、まあでも今日も頑張っていきましょう。ありがとうございます。
ひめみのkeethことくわはるです。
では、本日も朝から始めていきたいと思います。
で、本日はですけども、
モンテスキュー株式会社さんという、いわゆる法律というか、
あの契約書周りですね、の煩わしさだったり、難しさとか、
そういう穴みたいなところがあるんですけど、
そこをなんか突破できるような、というか、
まあ簡単にかつ安心・安全に契約を迎えることができるようにするためのサービスをやられている会社さんがあるんですね。
そこの代表の方ですかね、これは。
が、読まれたリーダブルコードですね、についてのブログがあって、
なんか面白そうだったので、これちょっと読んでいこうかなと思っております。
で、今日のブログの筆者の方ですけど、
モンテスキュー株式会社のCEO、創立者の方ですけど、創業者の方なんですけど、
この方自体も現在現役の弁護士をされているというか、
本当に頭いいんでしょうねってすごく感じました。
以前お話しさせていただいたこともあるんですけど、
まあやっぱり代表の方だけあって、頭の回転は早いし、ものすごい知識量で、
やっぱすごいなって、好き並みの言葉ですけど。
では、その方がリーダブルコードという書籍を読んだ感想とかが
ブログに書かれたので、それを読んでいこうと思っています。
はい、では行きますか。
えっと、しちゅーせんさんですね。
おはようございます。ご参加いただきありがとうございます。
本日も今からダラダラーと読んでいこうかなと思っています。
はい、もしリーダブルコードを弁護士が読んだら、というブログになります。
このブログ自体は去年の12月27日に出版されているものですね。
はい、では行きましょう。
こんにちは。リーダブルコードを先月読破して感銘を受けた弁護士の人です。
何に感銘を受けたかというと、
エンジニアが高級言語を効率的にコーディングするための工夫というのは、
契約という言語をコーディングするために延用できるということが多い、
というふうに感じたんだなということですね。
なるほど。
例えばリーダブルコードには、関数には空虚な名前、
テンプとかリビールとかではなく、
エンティティの実態に即した名前を付けようというふうに提案をしています。
これがすごくわかります。
なぜなら、契約言語では、
当事者というクラスの表現のために、
こうとかおつという言葉をいまだに使います。
そしてこうとおつを逆に書いてしまったままレビューを通過することも実際によくあるらしいですね。
で、オライリーさんには激怒されるでしょう。
まあ、そうなんですね。こう、おつって人文字で全然違う言葉なんですけど、
すごくわかりづらいというか、
しかも人文字なので、
まあ、ミスる可能性って多いにはありますよね。
でもそのまま通ってしまうことも本当によくあるらしいので、
結構大変ですね、これって思いますね。
また、こう、おつってずっと使っていくと、
契約書、ずっとしたら十何章、二十章とか言ってくると、
03:00
こうがどっちだっけ、おつがどっちだっけって絶対になるんですよね。
いや、ならない人はすごいと思います。
で、まあ、しかしよく考えると、
高級言語と契約言語が似ているのは当然だと思うようになりました。
それは、どちらも一定のインプットを入れると、
必ず一定のアウトプットが返ってくるように、
設計された独自の言語体系だからになります。
契約言語とは、一定の紛争が、
一定の判決が出るように構造化されたコードになりますと。
処理するのがコンピューターではなく、
裁判官であるというのが違いでしょうと。
まあ、それ以外は特にないようですね。
例えば、ソフトウェアでボタン、インプットをクリックですね。
したときに、まあ、高級言語が処理をして、
コンピューターが解釈をして、
画面にアウトプットとして何かを表示すると。
契約書の場合は、インプットとして紛争とか事件が起きて、
契約言語があって、裁判官が解釈をして、
で、判決が出ると。
フローとか手続き的なものが本当に一緒なんだなってところですね。
で、調べれば調べるほど、
プログラミングの世界でのこれまでの工夫っていうのは、
契約言語の世界の未来の姿だというふうに思うようになりましたと。
ソフトウェア開発のプロセスになぞられて、
ちょっと少し書いてみたいと思います。
まず、ビジネスモデリングからですね。
モデリングの重要性ってところなんですけど、
ソフトウェアの開発においては、
まず実際の業務をモデリングしますよねと。
で、業務要件を適切に分解することで、
クラスを定義したり、ER図を作ったりするのはその後になります。
ここを間違うと、
プログラムとして内的整合性っていうのが保たれていたとしても、
実際には意味のない、もしくは役に立たないものになってしまいます。
契約でも最もセンスが問われるのはここになります。
実際の取引を契約という独自の言語体系にモデリングしていきます。
いくら契約のフォーマットが美しかったとしても、
実際の取引を反映していなければ裁判で役に立たずに、
むしろ有害になりますと。
続いてコーディングですけど、
ノーコード、ローコードの流れってことですね。
そのため、プログラミングでも契約でも、
コードを求めているユーザーとコーディングできる職人との
コミュニケーションがとても重要になりますと。
しかしこれが超難しい。
契約の世界では、
公務部と実業部とのやり取りにめちゃめちゃ時間がかかるんです。
日本全体で契約のために消費している時間は
10億時間とも言われています。
あ、そうなの。
10億時間、年間で。
いろんな契約というところがありますけど、
それを合計すると10億時間も契約のために
時間を消費しているんですね。
ここをシステムで早くすれば、
すごい時間の削減になって、それは価値的ですね。
例えばシステム開発でクライアントがカラムを1列追加してと、
カラムを1列追加しておくクライアントが言える時点で
割とIT知識ありそうですけど、そこは置いといて。
画面上こういうのが1つ欲しいので、
結果的にデータベースにカラム1行追加して
というようなオーダーが来たとします。
SIRとしては、実際に追加開発に
どれくらい時間かかりますみたいな
コミュニケーションをするという感じですね。
契約書の場合は、事業部の方が
例えばNDAを1つ作ってみたいなことを投げるんですけど、
そのNDA1個作るのに
ホーム部としてはガッツリ作るので
06:00
2週間ぐらい作成作業がかかるよみたいな
という感じですね。
そんな風な時間がかかっていると。
それは途中途中でしかも
細かくやり取りもしなきゃいけないからということですよね。
そうすると、全部を職人さんがコーディングするのではなくて
コードを求めている人でもコーディングできるにしようと
そういう流れが生まれます。
いわゆるノーコード、ローコードですね。
契約のノーコードは
リーガルテックでも厚い分野の1つになります。
リーガルテックというのは名前通りですね。
法律とか法務関係周りのテクノロジーの話です。
ChatGPTに契約を書かせてみたらどうなるのか
というツイートを当社、創業者が一応しましたけど
もし誰もがフェアな契約を瞬時にドラフトできれば
世界中のビジネスはものすごく加速するはずです。
ただ、コパイロットをプロダクションコードに使うのは
まだ怖いくらいの感覚で
NLPの中でも生成モデルの活用というのは
まだ道半ばみたいなところです。
契約の世界でも生成モデルよりも
検索や推薦アルゴリズムといった
もう少し地に足のついた技術活用が進んでいます。
こちらについては講述します。
次にコーディングの話ですが
ドライ原則から入るそうですね。
プログラミングでは汎用化できる部分はライブラリ化され
同じコードは何度も書かないようにすべきだ
という考え方が当然のように受けられています。
これがドライ原則です。
さらに社会全体でも共通化できるレイヤーは
デファクトスタンダードとなるようなプラットフォームから
APIが提供されています。
当社もSaaSプロダクトを提供するにあたって
AWSを利用したり随所でライブラリを活用したりすることで
エンジニアがプロダクトのために必要な部分に
フォーカスできるという便益を享受できております。
弁護士から見るとこれは本当に羨ましいことです。
なぜなら契約はその99.9%が
過去のものの繰り返しであるにもかかわらず
毎回ゼロからコーディングしているからです。
これはそうなんですね。
固有性が高い部分、そして共通性の高い部分、
本来なら共通性が高く
妥協しやすいはずの箇所が争点になるとか
そういうことが本当にしょっちゅう起きるらしいですね。
契約言語には未だにデファクトスタンダードが存在しません。
年間5億件も契約されているにもかかわらずです。
日本全体か世界全体かわからないですけど
年間5億件も契約というものが結ばれているんですね。
クリエイティブコモンズやJKISSなどの標準化というものが
進んだ領域は契約全体の0.1%未満になります。
そのため契約をしたい世のビジネスマンは
ライブラリ等を一切使わず
フルスクラッチ開発を常に強いられて疲弊しています。
ちなみにIDEのサポートもないのでデバッグ作業もつらい。
非効率だというのもありますけど
めちゃめちゃつまらないことですよね。
ホームの人たちはとってもつらいんですよ。
こんな環境下でコーディングをしているという捉え方をすると
僕だって絶対嫌ですね。
ライブラリ一切ないし、フルスクラッチで0ベースで毎回開発しなきゃいけないし
IDEもサポートないし。
こんな環境で絶対開発したくないですね。
デファクトスタンダードと自然言語処理技術のところに行きます。
プログラミングの世界では
09:02
長い歴史の中で
デファクトスタンダードを積み上げてきました。
契約言語にもようやくその機運が訪れています。
その契機となったのが自然言語処理技術の登場になります。
契約言語というのは
比較的明確な構造を持っているため
自然言語処理技術との相性が良かったんですね。
例えば構造解析だったり、省を解析だったり
文書分類だったり、パッセージ分類だったり
みたいなところがあるんですけど、結構構造的には単純になるんですね。
私たちのようなリーガルテックが
広く使われていくと社会全体でどのような契約条件が
標準なのかというのが可視化されます。
これまで弁護士の職人経済であったものが
スタンダードを定量分析できるようになるかもしれません。
でもそれは良い話ですね。
また日本最高の職人イコールトップ弁護士による
コードをオープンソース化する取り組みも始まっています。
リーガルテックというのは
フェアな契約言語へのAPIを提供するという社会的役割を
果たそうと仕様しております。
ソフトウェア開発では
GitHubをはじめとしたバージョン管理システムを中心とした
プラットフォームが当然に使われています。
当然に使われていてほしいですね。
使われていないところもまだまだあると思います。
これがあまりにも便利なので、当社では経営上の意思決定すら
GitHubでプロリクエストをアプローブすることで実施しています。
すごいですね。
いろんな使い方があるけどそういうことをするんですね。
プロリクの配置とリモートワーク、出社日の考え方を反映
というプロリクが出ていて、レビュアに
社員の人たちがひたすらバーッとレビューしたりアプローブしたりしています。
プロリクの説明にもちゃんと
一周が立てられていて、レビューの程度とか
どういうところをレビューしてくださいみたいなところまで細かく書いています。
アサインを伝えたい場合はちゃんと記載してくれと。
不要な場合はこのセクションを削除してくれと。
内容としてはちゃんとレビューを依頼したい人は全員
ちゃんとプロリクのディスクリプションにも書いてください。
すごいですね。そんな意思決定をGitHubでやられて
なかなか面白いですね。
コードを書くと言ってもほとんど多分日本語なんでしょうけど
法律家の方々のコーディングといわゆるドキュメント、テキストになると思います。
型や契約言語というのは
コードがベタ打ちされたワードファイルをメールに添付して
やり取りすることで更新しています。
交渉過程で複数のビジネスマンが異なる修正をしたにも関わらず
反抗してしまったみたいなことも本当に起こります。
そもそも裁判では取引先と最後に合意された契約コードだけではなく
そこに至るまでの更新経緯も参照されます。
しかし誰が、なぜ、どのように
コードを更新したかみたいな情報は
大抵メールが離散してわからなくなっています。
これを解決するために昨今のリーガルテックは
契約のバージョン管理に乗り出しています。
一つのプラットフォームで契約言語のレビュー履歴が見れるように
これから余裕になっていくのかもしれません。
そういうことを考えるとGit管理するのはめちゃくちゃ適切ですよね。
12:01
まさにあの世代管理、バージョン管理のツールですからね。
GitとGitHubっていうのは。
どこを誰がいつ更新したかっていうのをちゃんとコミットハッシュが発行されて
タイムスタンプも発行されるのでね。
これ本当にいい話ですね。考えると契約書をGitHubで管理する
さすがにその法律的なものというか
どこまでプライベートでどこまでインターネットに載せていいのか
みたいな話は別であると思いますけど最近でもあれですよね。
契約って同級サインだったりクラウドサービスがいっぱい
オンラインのサースサービスがいっぱいあったりするので
最近の契約書周りはインターネット上に載っかっても別に問題ないのかもしれないですね。
もちろんタブでやるんだったら
オーガニゼーションを発行してプライベートリポジトリでやるのは
多分その通りだと思いますけど。
契約書ってちゃんとそういうなぜ更新されたか
その更新の理由とか誰がっていうところも結構重要なんですね。
それとまさしくGitHubとGitっていうのが相性いいかもしれないです。
続いて今のがレビューの話でした。
次は管理と更新の話ですね。
プログラムっていうのは動いてからが本番であり
リリース後に改善活動がアジャイルに繰り返されます。
ここがSaaSの面白さでもあります。
契約言語であっても本来同じです。そもそも契約言語は
裁判官というリソースが超貴重で
テストが不可能であるためぶっちゃけ間違いが多いんですよ。
契約機関というEOLもあるので
メンテナンスも必要になりますと。他方で契約言語は
現在有効なコードが何かということすら
管理できておりませんと。これはすごい話で
なぜかというと最終版のソースコードが
紙で管理されているからです。
仕方ないですよ。いまだにだって紙で発行して
割印とかちゃんと印鑑補正みたいなところいまだに起きてますから。
そのためリーガルテックベンダーは
OCRを提供するだけで喜ばれることもありますと。
本当じゃまだまだ
リーガルテックでレガシー環境なんですね。
さらに自然言語処理技術によって
契約機関を抽出しメンテナンスが必要なタイミングで
アラートを出すことができるだけでも社会にワウというもの
驚きを与えることができますと。
この辺IT技術をどんどん使っていきたいという話ですね。
最後もう終わりにというところですね。
こうして見ていくだけでも契約言語
っていうのはプログラミングの歴史から大いに学ぶべきだ
という風に痛感しております。
さらに悪いことに高級言語と契約言語との大きな違いがあります。
それは契約言語は全国民が完全
理解できることがなぜか前提になっていることです。
ビジネスの世界では契約言語を通じてしか他社とか
変わることができません。
結局契約に乗っかって僕らはお客さんとかと
やり取りしたりしていますからね。
契約言語は全国民が完全理解できることが前提になっている
というけど多分無理だと思います。
書かれている言葉はほとんど知らないワードがたくさん出てきたりするし
毎回毎回それを調べて本当に理解したかなんて
わからないですからね。
本当だから契約書とかはちゃんと読み合わせをして
ちゃんとわからないことは全部疑問を投げかけて
15:02
結ぶっていうのが本当は正しいんですけど
そこまでやってたら本当に時間が足りないんですよ。
こういうところにちゃんとフォーカスをしたのがモンテスキューさんなんですよね。
とても時間を生み出すところで素晴らしいなと思います。
例えば外部サービスを利用するときには
利用規約に同意する必要がありますけど
あれって皆さん本当に読めていますでしょうか。
現状のものは弁護士である私ですら読む気にならない。
そのくせ私たちは一切の損害賠償責任を負いません。
明らかにアンフェアな情報がこっそり含まれていたりします。
だから読まなきゃいけない。
でも弁護士ですら読む気にならないという辛いお話ですね。
利用規約ごめんなさい。
普通にアプリとかサービスレベルだったら読んでないんですよね。
恥ずかしい話なんですけど。
しかも自分の資材、お金を使うようなサービスであればあるほど
本当はちゃんと読んだほうがいいんですよね。
これはもう本当わかってるんですけど。
すいません。
誰でも他者とフェアな協力関係を築けるような
ツールに進化させるものと思っております。
契約言語の濃厚度と充実したライブラリー推薦アルゴリズムと
あとIDEとGitHubというのを
私はこの世界に送り出したい。
効率関係、リーガルテックの世界に
IDE、アルゴリズム、GitHubみたいな
充実したライブラリーをどんどん推進していきたいというところですね。
今まさに社会が大きく変化しようとしているところですので
もし興味を持ったエンジニアの皆様がいれば
ぜひ私とカジュラ面談させてください。
このブログの中でも右上に採用ページが減ったり
いるんですけどね。
もし興味があればぜひカジュラ面談を受けていただければと思います。
エンジニアの少ない会社さんでもありまして
今からどんどんエンジニアの採用を増やして
ビジネスの拡張とか推進をどんどんやろうとしている会社さんですので
受けてみていただければと思います。
Ruby会議もスポンサードしていたような感じで
本当に技術に明るいというか肯定的な会社さんですので
興味があれば受けてみていただければと思います。
はい、いかがだったですかね。
契約って年間10億時間も使われているんですね。
こうやって読んでいくとそれはその通りだよねって感じました。
めちゃくちゃレガシーですし、本当にちゃんとお互いに
相互がないようにとか、契約条文、項目1個1個に対して
認識の相互がないですかっていうのをやり取りしながら書いていく。
共通部分とか本当はあるはずなのにそれを全部ゼロベースで
また1から1個1個書く。フルスクラッチでやる。
それは遅いわけですよ。というので、ここをちゃんと技術で解決しよう
っていうめちゃめちゃ熱いお話をされているので
本当なんですかね。目に見えないけどめちゃくちゃ
社会貢献がでかいプロダクトを作られているところなので
興味があったらお話聞いてみてください。
じゃあ今日の朝方はここで終了していきたいなと思います。
今日の参加者はしゅーせんさんとごとうさんと
相変わらず見えてないですけどすーさんですね。
ご参加いただきありがとうございました。
後でこの記事シェアしますので興味があれば読んでみてください。
じゃあ火曜日ですね。今日も一日頑張っていけたらなと思います。
18:01
それでは終了したいと思います。お疲れ様でした。
