法律、Gitで管理したら楽やん

そういう話題がなされているという事を耳にしたような気がします。もしかしたら幻聴かもしれないけど。

いや、幻聴じゃなかった！

note.com

下にある怪文書を書いた後に発見したんですけど、実務家の方が法律のGit導入を本格的に検討されています。

すっきりと脳内に落とし込めるように分かりやすい説明がなされた記事でマジで感動したので、こちらを読んでいただけると僕が言いたいことは全部載ってると思います。

という事で、僕の提案は結果的に「する必要が無かったｗｗ」という結論なんですけど、 せっかく書いたので稚拙な怪文書ですが素人の独り言だと思ってご笑覧ください。

...という事で今回は日本の法律をGitで管理したらどうなるのかという点を法律何も分からんずな僕がテキトーに検討していきたいと思います。

専門家の鉞が怖いので誰の目にも留まらないことを祈って...

さわり

法律は人々の様々な利害関係を調整して、秩序を形成していく必要があるため、どうしても長く、分量も多くなってしまいますね。六法をお持ちの方ならよくご存じだと思うし、法曹を目指す方は毎日「重っっっっっっっっっも」って言いながら通学しているだろうと思います。あれはもはや弁当箱です。

しかし約20年ほど前、革命が起きました。

「え、今の時代だったらパソコンで閲覧できるじゃん。」

そうなんです。今の時代、eGovの法令検索を使えば重たい六法を持ち運ばなくてもスマホやパソコンを使って日本の法令に気軽に触れることが出来ます。

elaws.e-gov.go.jp

ちょっとした条文の確認程度だったらeGovの法令検索を使えると非常に便利ですね。

でも、待てよ...法律って適宜改正されるよな...

という事は改正前と改正後の条文を参照しておかないとどういった点で変更が行われたかがうまく掴めない...

学習する際に条文を参照する場合、法改正前後を比較して「何故改正前の法律では問題があり、修正を行う事でどういった問題が解決できるか。」「改正法でもまだ修正が必要な部分があるのではないか」等を検討する事があります。 改正法案の施行（実際に適用される）が今年ならば是非とも前後を把握したいと思う方も多いでしょう。

そのような方は現状、eGovを複数のタブで開いて確認していきます。

ほうほう、ここが変わるのか...ほうほう...

いや、会社法関連改正施行多いてっ！タブ埋もれてしまうやん！

法改正が多ければ多いほど参照が大変になってしまうのは紙でもパソコンでも同じです。 そもそも日本の法律は基本OO法という一体系でまとまっているため、紙幅の都合上親切な六法でも1つ前の法律ぐらいにしか遡れません。

じゃあ、あきらめるのか....

いや、おれたちにはGitがある！

Gitとは分散型バージョン管理システムです。主にソフトウェア開発やプロジェクト管理でコードの変更履歴を管理するツールです。 リポジトリ（情報の塊）を共有、正確に保存、競合しないように管理、変更点を明確に示せるといった機能を有しているため、多くの開発者に利用されています。

え、「法律の話なのにプログラムの世界から変なものを持ってくるな、殺すぞ？」

...証拠資料として発言の記録を残させていただきます❤

というのは冗談で、

実はソフトウェア開発と日本の法律のシステムは広い目で見ると共通する部分があります。

共通点と相違点を以下に少しだけ挙げてみました。

共通点

厳格なルールや形式の元製作される。

ソフトウェア開発と法律制度は、それぞれ自身のルールや形式が厳格に定まっています。

ソフトウェア開発においてはコーディングをする際に言語や環境による厳格な制約がありますね。一文字間違えたらコンパイルエラーが出たり、誤った記述をすると適切に動いてくれません。

また、要件定義を定めるなどして明確な方向性を定め、それを適える形でコーディング、デザイニングをし、厳格なチェックの元リリース、保守がなされます。

法律も同様です。法律も厳格なルールや既定の元制定していきます。

立法趣旨（法律を作った趣旨）に適い、その法律が制定されることによって憲法上保護される権利を誰も不法に侵されることなく、しかし秩序を形成して権利を保護することは怠らないという制約を意識しながら慎重に制定していきます。

また、法律要件（if）と法律効果(then)が形式的な物であるか、意図した範囲を逸脱して法が適用されることが無いか、有効な解釈の余地があるか等をふまえながら制作していきます。

そのため、ソフトウェア開発でも立法行為（法律を作る行為）でもトリッキーな取り決めは許されず、目的に適うようにある程度のルールや形式、型に則って制定します。

...似てる

変更管理が必要

ソフトウェアでも法律の分野でも、変更管理は非常に重要です。

ソフトウェア開発ではバージョン管理が要になってきます。バージョンが違えば中に書いてあるコードや動作する内容が完全に違っていることもあり、皆がどのバージョンを使っているかを把握するのは非常に重要な行為です。

法律制度のバージョン管理は法改正や裁判例がそれぞれの変更を管理します。

日本は法改正の制度を採用しているので、対象となる法律がガバっと入れ替えられます。削られたり、消去されたり、つけ足されたり、修正されたりした法律が改正法として以前に合った部分に当てはまる形です。

例えばどうでしょう。

令和五年の今、裁判官が急に昭和53年の改正前法を基に審判してきたらびっくりしますよね。 法律の変更が適用されたら、国民全員がそのバージョンを使う事によって法秩序が維持されることになります。

え、法律はともかく、裁判例は関係ないんじゃないの？と思う方もいらっしゃると思いますが裁判例は法律を解釈する上で非常に重要な役割を持っています。

日本の法律は裁判官の裁量の余地を持たせるために抽象的、あるいは簡潔に書かれている条文が存在します。

これを基に裁判官が事実関係や証拠、その他の考慮要素を以て慎重に審査するのですが、100人の裁判官が100の意見を出したら、秩序なんてありませんよね。また、裁判官の裁量に偏り過ぎると、公平な審理が保証されません。

そのため、過去に裁判官が下した考え方を、後に同じ事案で審理する裁判官が黙示的に拘束を受けるという「判例拘束制」という形式が採られる場合があります。 余程おかしな判決趣旨で、私がこれを修正させて頂こう。とならない限りは、過去に出た判例（裁判事例）を基に審理を行います。

従って、特定のバージョンの裁判事例が管理されることも非常に重要です。

...似てる！

相違点

変更が適用される速度の違い

ソフトウェアの変更はセキュリティインシデントや障害対応、バッチ修正のたまに比較的迅速に行われることがあります。

少しでも早くバグや問題を解決し、より良い機能改善を行う事が求められ、比較的短時間の間に冷静に検討をし、修正を行う事が求められる場合があります。

また、素敵な機能改善や新たなニーズに応えるべく、比較的頻繁に修正、バージョンアップが行われます。場合によってはラグビーのトライのように試みては砕けを繰り返し完成形に持っていくこともあるでしょう。

法律の場合、現行法が問題だと指摘されたり判決が出たとしても、「さあ、ここ修正するか。」という気軽な雰囲気で改正できるものではありません。国民の共通のルールであるため、気軽に修正すれば誰かが笑って誰かが泣きを見るという現状が単純にシフトするだけになってしまえば不毛です。

また、どういった面で問題が起こったのかを慎重に検討し、行政の分野で改善を図ったり、他の法律も併せて審理する必要が出てくる可能性も少なくはないです。

そのため、特別法（ＯＯＯＯ対策法、コロナＯＯ法）のように臨機応変に修正を加えられる法律を除き、一般法に当たる法律の改正は狂う程に慎重に検討を重ねて改善を図ることになります。 具体的な手続きの説明は割愛させていただきますが、違憲と判断された法律が修正されるのは本当に時間がかかっています。

...似てないかも

専門性と普遍性の両立度

どの分野でも専門的な知識が必要ですが、ソフトウェア開発はコーディングに限らず様々な分野で専門的な知識が必要になってきます。

しかし、仮に利用者がコードを読めなかったり、インフラの構造を把握していなかったとしても、誰でも望めばサービスを利用できる形を想像していく能力が求められることがあります。

専門性と普遍性が乖離していても、コンシューマーが使える形に置き換えてサービスを提供することで開発したプロダクトを提供する事が出来ます。

一方で、法律の場合国民の権利義務を規定するものである以上、難しい言葉で書かれていたとしてもソースコードである法律文書というものを理解したことを前提として利用してもらう必要があります。

そのため専門性と普遍性の乖離は許されず、ある一定の距離は保ち続けなければならないという点で専門性を発揮する場所が異なる点があります。

...ちょっと似てないかも？

ほんへ

やっぱり、素人感覚で法律とプロジェクト開発を比較してみたら、そこそこ似通ってる部分があるじゃないか。という考えに至ったので、相違点をふまえて早速法律の世界にGitを持ち込んだらどうなるのかを想像してみます。

例えば僕の手続法の学の足りなさをカバーするために 「ここは蛙の国、日本の法制度に非常に似た制度を有しており、法律をGit（Github）で管理することにしました」

という事にします。

このような条文があったとします。

199条　蛙くんは他の蛙くんを殺してしまった場合5年以上刑務所に入らないといけない

200条　蛙くんはお父さんやお母さん、おじいちゃんのような血のつながった「上の世代」の蛙を殺してしまった場合、100年以上刑務所に入らないといけない

※このような条文は存在しません。

この法律が審理されるような事件が発生して、色々審理した結果最高裁判所の裁判官はこういいました。

「同じ蛙なのに、血のつながった上の世代の蛙を殺したら罪が重くなるっておかしいよねぇ。この法律（200条）は違憲です。」

という事で、違憲確定、もう200条は使えません。

さあ、改正しなくては！

①まずは、法律を審議する蛙達が自身のブランチで改正案のコミットを出します。

200条　消去

これでよし。

②次に国会でプルリクの元ネタを出してよいか話し合います。議長「よし、出そう。」

③という事でリファレンスを送信。

④すると蛙の手作業で色々審査されます。 「これで大丈夫か」「ここはまずいんじゃないか...」「これはいいかもしれない」

⑤なんやかんやでこの法律でいこう！っていう事になりました。

⑥という事でプルリクエストを送信！

⑦本案審議で慎重に話し合われます。よし、これでいこう！

⑧マージ！

コミットログ
199　199条　蛙くんは他の蛙くんを殺してしまった場合5年以上刑務所に入らないといけない
-200　200条　蛙くんはお父さんやお母さん、おじいちゃんのような血のつながった「上の世代」の蛙を殺してしまった場合、100年以上刑務所に入らないといけない
+200　200条　削除

⑨リリースノートに明記

すごいテキトーになっちゃったんですけど、こんな感じです。Githubの場合はリファレンス、プルリクとマージが同じ場所で行われたりするんですけど、実際の立法過程では法令が定める規定により一定数の賛成者によって承認されなければならない点や、審議の回数がGithub多い点等で制約があります。

実際にGit（Github）を法律の編集に使ってみて、どうでしょうか。 手続き的な部分を除けば行けそうな感じがしなくもないですよね。

上記のようにGithubやGitを使う事によって得られるメリットやデメリットを検討してみましょう。

コミットからマージまで全部残る

これ強い。議員がいとして残そうとしなくても、話し合った内容や修正案、最終的にどこを買えたのかが全部記録として残ります。

そのため、恣意的に立法趣旨を隠して利害関係を調整したり、望みもしなかったような法律の適用がなされることを割けることが出来るわけです。

また、Github上に記録が残るために、国民と立法者の情報の肩よりが問題視されている現状をディスクロージャー（情報公開）という形で修正できる点も期待できます。

一方で議員のすべての言動や政治活動が記録に残ってしまう面は逆に課題でもあります。

透明性が確実に担保されている分、国民に不満を言われないように当たり障りのない立法政策へと傾倒してしまったり、自由な議員活動を間接的に制約してしまう可能性がある点で課題は残ります。

審議がバーチャル化される

当然のごとく電子上で法案を審議するため、リモートワークの形が採用できます。専門家や国民に接触できる機会が増加し、比較的自由な勤務形態が採用できるのでより良い法案整備を行う事が出来るようになるかもしれません。

ただし、こちらも法律を熟知したり、議員としてキャリアを積むためにはどうしても年月を要する事が多いのが現実で、これを言ってしまえばおしまいなんですけども、電子化を容易に受け入れてくれるかという点に関しては懸念される部分だと思います。

しめ

...というような事を色々考えていると、あながち法律、Gitで管理できるんじゃない？と思う節も存在するように思えます。

実務的な部分でどこまで実現できるかは予測不可能ではありますが、非常に夢のある制度だと思います。

今回はここで終わろうと思ったんですけど、もし本格的にGitで管理する体制を採用するならどこまで出来るかという点をもう少し妄想してみたいと思います。

CIツールを駆使して条文のコンフリクトを管理

CIツールを利用して厳格なフォーマットの管理と整合性を確保すれば、法案審議を内容審査だけに絞り込める可能性があるのではないかという考えです。

変更の自動テスト

CIツールを使用して、法的文書への変更が一定の基準を満たしているかを確認します。関連する条文に影響が出ていないか、要式が正確か（文言審査は技術的には難しいかもしれない）等を自動でテストし、コンフリクトや誤りを事前に指摘します。

変更のトラッキング

誰がどの変更を行ったのか、変更箇所がどのように影響を与えたのかを追跡するように設計します。特定の変更をトラッキングするようにすれば文書の歴史と変更の経緯が把握しやすくなります。

コラボレーション、統合支援

法的文書の変更が複数の関係者によって行われる場合、CIツールを使用して変更の統合と整合性を維持できます。これにより提出前の統合を楽にしようという試みです。

具体的な実装方法は考えておりませんが、冷静に考えてそのまんま実現するのは現時点では不可能です。しかしながらこれに近い事をやろうと思えばできるので、少しづつ改善していく形になると思います。

条文のコミット歴参照用のUI

今回は立法行為まで全てGitに落とし込もうという話で進めていたのですが、現状Gitを使える人間で法律に精通されている方は少ないように見受けられます。

そのため、編纂の段階まで強制的にGitを持ち込めば、ただでさえ慣れるまで操作が難しい点をふまえるとかえって業務が停滞してしまう可能性のほうが残念ながら高いと思います。

現状、Git管理にすることによって喜ばしいと考えられる点は条文のコミット別参照と立法趣旨の透明化という部分が強いと思うので、まずは既存の法律をGit形式で参照できるようにしていくのが最善のように思えます。

以上のような感じで何が言いたいのかあいまいになってしまった感じですが、法律をGitで管理するメリットは大いにあり、導入しようと思えば技術的には可能ではないかと思います。

どちらも専門的な知識が必要な分野なので、いい感じにコミュニティーが相互で形成されて、情報交換を交えてスペシャリストでありながらジェネラリズムを有し、どちらの分野にも理解が示せる環境が出来れば素晴らしいと思います。