MNTSQ株式会社というリーガルテックのスタートアップでパラリーガルをやっている者です。

同じ事を言ってる人は無限にいますが、いいことは何度言ってもいいので

本当に似てるから見て、というレポートです。

１．法改正のしくみ（日本法）

法案が国会で可決されると法律となります（憲法59条）が、そこでいう「法律」とは具体的にどういうテキストでしょうか。日本法は「溶け込み方式」という方法を使っています。すなわち、現行法を変更するときは、「改正」という形式によって現行法を書き換えます。

例えば民法を改正したいと思ったときは、「民法（明治二十九年法律第八十九号）の一部を次のように改正する」と宣言してから変更差分をひたすら書きまくるということをします。この変更差分が一本の法律です。Gitでいうところのcommitです。変更元の法律も元は一本の法律であり、何度も改正をされていますが、「民法（明治二十九年法律第八十九号）」とファイル作成時（？）の名称で呼ばれます。変更元のファイルとcommitを両方同じ「法律」と呼んでいるのでわかりにくいのだと思います。

非法学徒にとってこれは当たり前のように思えるかもしれませんが、例えばアメリカ法は「積み重ね方式」という方法を使っているとされています（曖昧な言い方なのは、U.S.C.（United States Code）などで法典化された法律の改正については妥当しないからです）。これは変更差分をひたすら追記する方式で、合衆国憲法の修正条項（Amendments）が好例です。例えば修正18条の禁酒法は修正21条1節によって廃止されていますが、修正18条が成文法から消えるわけではありません。お察しの通り修正が多くなると機能しないので、さっさと法典化した方がいいと思います。

今年の4月1日に施行されたことで話題の新民法で言うと、変更差分として国会で可決された法律はこれ（法務省HP）です。

commit hashが「平成29年法律第44号」（平成29年度国会で制定された44番目の法律）であり、commit messageが「民法の一部を改正する法律」となっております。

大改正なので超長いですが、基本的には「改める」「加える」「削る」の操作によって現行法に修正を加えていることがわかります（体系を変えるときだけ「AをBとする」を利用していますね）。もちろん、これだけを見ても意味不明なので、ありがたいことに新旧対照表も作成されることが一般的ですが、可決される法律はあくまで差分の方なので、新旧対照表自体は法律としての効力を有していません。

Gitのcommitと同様、一本のcommitで複数のファイルを修正することもあります。例えば地方分権一括法と呼ばれる大改正（「地方分権の推進を図るための関係法律の整備等に関する法律」（平成十一年法律第八十七号））では、地方自治法をはじめとして、538件の法律を改正しています。Gitの方のcommitがそうであるように、一つのcommitで大量の変更を行うとreviewerが死んでしまいます。すなわち、国会において十分な審議が行われないまま法律案が通過してしまいます。国民主権のあり方に照らして、法律学においても、一括法案は立法の在り方として問題があることが夙に指摘されています。

２．Gitにするとなにが嬉しいの

以下のことがすごく楽になると思います

（１）コミットログが追える（いつどの部分が改正されたのかを瞬時に確認することができる）
現在改正履歴は国会図書館の日本法令索引で国会の議事録とともに確認することができますが、個々の法改正でどこが変わったのかを見ることができません。他方、現行法は総務省行政管理局が管理しているe-govで確認することができますが、こちらは改正履歴がわかりません。D1-Lawなどのサービスでは確認可能ですが、誰でもアクセスできるものではありません。

（２）個々のcommitがissueとreferenceされることで議論を追いやすくなる

（３）新旧対照表を作らなくてよくなる
これについては法制執務上新旧対照表を自動で作成するアプリケーションを利用しているという話を聞いたことがあります

（４）誰でもPull Requestが出せる
もっとも、法律上、国会議員ですら一定数の賛成がなければ議院に法律案を提出することができない（国会法56条1項）ので、誰でもプルリクを出せることが本当にいいことなのかは議論の余地があります。

（５）Open Governmentの実現
これが一番大きいです。GitHubであればコメントの修正ですら全ての履歴が残るので、法律制定に関するすべての議論のopennessを維持することができます。少なくとも、現在のようなガバガバガバメントを許容する余地は多少なりとも少なくなるのではないでしょうか。

法律界隈の人向けに、GitとGitHubの違いについてはこちらを参照ください。
一言で言うと、Gitはバージョン管理システムの名前、GitHubはGitシステムを利用した具体的なサービスの名前です（最近microsoftに買収されて話題になりました。他にはBitbucket、Backlog、GitLabなどがあります）。

３．取り組み事例

法律をGitにしたいなどという安直なアイデアはもちろん誰もが思い付いているのですが、実際に手を動かしている人は多くありませんでした。

発想は良かったのですが、悲しいかな、法律に詳しくかつGitHubを使える人間は弊社くらいしかいないので、ほとんど更新されずに放置されてしまったようです。

アメリカではさすがオープンガバメント化が進んでおり、ワシントンD.C.の制定法と法典がGitHub上で管理されております。リンク先の原文にはGitHub上のソースコードがauthoritative sourceだと書いてありますが、ほんとかよという感じです。

やれてる

GitHubでリポジトリを公開することの目的については、以下のように述べられています。なるほどですね。

1. Zero Errors - we are developing tools and processes to catch errors before they are published.
2. Up-to-date - The tools will let us update the code in days, rather than months.
3. Machine Readable - we will publish the code in an xml format with consistent, semantic metadata.
4. Easy to Use - we will publish a website where people can easily read and interact with the code.

４．実際上の困難

思うに、言うは易く行うは難しで、実際に実装するとなると、データ構造として処理しやすいファイル形式と可読性の高いファイル形式を両立するのが非常に難しそうです。実際やるとなったらmarkdownでやるんやろなと私も思いますが（別表も扱えるし）、計量的な解析は困難になる気がします。ワシントンD.C.法はxmlを使っていますが、人間にとっての可読性が非常に悪いです。複数のデータ構造で保存するという方法もなくはないですが、法律にSingle Source of Truthがないということがあっていいのでしょうか。また、法制定においては、附則や付帯決議など様々な付随する情報をどう捌くかなどの問題もありそうです。今書いていて思ったのですが、政令や省令も別リポジトリで管理したら参照関係がとてもわかりやすくなるのではないでしょうか（リポジトリ間のreferも可能）。被参照関係なども相互にリンクを貼れるともっとよいですよね（自動化できれば最高ですが）。

他にも考えることは無限にありそうですが、こうした課題を現実に解決するためには、法制実務とエンジニアリングの協働が必要なことははっきりとしていますね。

５．最後に

全然関係ないですが、私がパラリーガルとして所属するMNTSQ株式会社では、こういう話に興味がありそうな人をリーガルからもエンジニアからも募集しています。

www.wantedly.com AIを賢く育てる。リーガルテック・プロダクトを進化させるパラリーガル募集！ by MNTSQ, Ltd.

MNTSQ, Ltd.

募集要項をみる