法令改正、「改め文」をなくし、バージョン管理で市民と協働を

立法爆発と法律のオープン化
　第4回　協働ツールで、立法をより民主的に

株式会社 富士通総研　経済研究所
主席研究員　榎並 利博

　前回は、オープンガバメントとソーシャルコーディングの考え方に基づくオープンコーディングの基本理念と原則について提案を行った。また、現行の法律にオープンコーディング規約を適用した、具体的な試行例も提示した。これで、オープンガバメントの「透明性」と「参加」についてはある程度のイメージを得られたが、3つめの「協働」については不十分だと指摘を受けることだろう。
　本稿ではこの連載の最終回として、立法過程におけるITを活用した「協働」の可能性について取り上げたい。「協働」の方法については法律に留まるものではなく、国民と行政が協働して文書を扱う場合など、公的な分野において広く有効なものとなるだろう。

法改正の現状と総務省のe-LAWS

　オープンコーディングの基本理念の3番目である協働について、前回の原稿で「法律の立法過程における協働について、すべての人々や機械が協働できるよう、パブリックコメントとその回答だけでなく、条文の修正提案について議論できるよう、環境を整備しなければならない」と提示した。さらに、オープンコーディングの原則の⑤として「法令文書の制定・改正について、国民が参加できる協働立法作業環境を提供すること」を掲げた。本稿では、この協働をどのように実現していくかについて考えてみたい。
　新しい法律を制定する場合、内閣提出法案では通常有識者から構成される検討委員会が設置され、要綱や大綱をまとめて所管の省庁が法案の作成に入る。要綱案や大綱案が公表され、国民の意見を求めることもあるが、一般的には新しい法案の条文作成そのものに国民が参加することは難しいだろう。もう少し現実的に、すでに運用されている法律の改正について、改正の主旨に従って国民が協働して条文の修正・追加・削除などの議論をしていくことについて考えていくことにする。
　まず、現状の法改正について確認するが、第2回で紹介したように内閣法制局では法令審査支援システムを稼働させている。このシステムは法令（案）を施行日ごとに管理できるとともに、改め文を改正対象法令に溶け込ませ、法令名称・法令番号、条項号などの表記ミス等のチェックも行っている。
　一方、総務省行政管理局では、法制関係の事務を自動化するe-LAWSというシステムを開発中である。開発のきっかけは、残業をなくして女性が働けるよう、法制執務業務を効率化すべきというワークライフバランスの要請だったという。現在開発途上にあり、2016年10月の本格運用を目指している。

　e-LAWSの概要を図表1に示す。法令データベースから改正対象法令を特定し、新旧対照表形式（新旧とも同じ内容）でダウンロードする。そして改正箇所に傍線を引き、新の部分に改正内容を入力して、新旧対照表を作成する。その新旧対照表を改め文作成補助システムにアップロードして、自動的に改め文を作成するというものである。
　e-LAWSはここまでの機能であるが、この後に改め文を内閣法制局の法令審査支援システムに送り込む。法令審査支援システムは、改め文の形式チェックや溶け込みチェック等を行い、溶け込み後の新条文を作成する。そして新旧対照表とチェックするという、いわばe-LAWSと法令審査支援システムが相互にチェックし、法令文書の誤りを検出する仕組みとなっている。しかし、やはり完全な自動化はできず、表形式などの処理の課題を残しているという。
　このように法改正の作業を効率化するためのIT活用に取組んでいるものの、あくまでも政府内部での効率化が目的であり、法改正のプロセス自体を一般国民に開放しようという方向性までは持っていない。

ソーシャルコーディングとバージョン管理システム

　第3回ではプログラム開発を民主化したと評価されている「ソーシャルコーディング」の考え方について触れたが、それについてもう少し掘り下げてみよう。ソフトウェアの開発においてはコードの修正が宿命とも言え、バグの修正だけでなく、機能追加によるコードの修正やソフト環境の変更によるコードの修正などもたびたび発生する。複数のプログラマが同じモジュールを修正することもあり、少人数のプロジェクトであれば相互のコミュニケーションで調整できるが、大規模な開発になるとライブラリアンを配置して、ライブラリの管理やモジュールの払出し管理などを行わなければならない。

　オープンソースの世界では、世界中の誰もがソースコードを開発して公開するだけでなく、誰もが自由に変更することができる。そこにおける相互の変更の整合性を自動的にコントロールするソフトがバージョン管理システムである。このシステムは、ソースコードのバージョン管理だけでなく、誰もが自由にソースコードを改変でき、さらにオリジナル開発者と改変するプログラマがコミュニケーションできる機能も持っている。バージョン管理システムはいくつかあるが、図表2に示すように最近では集中型システムであるCVS (Concurrent Versions System)やSubversionから、分散型システムのGitへと主流が変わりつつある。集中型システムは、アクセス集中によるサーバー接続不可や、サーバーの故障等によるサービス一斉停止などが起きた場合に、不都合が大きいからだという。
　Gitについて簡単に解説しておこう。Gitとは、プログラムや文書といった資産に対して、「誰が」、「いつ」、「何を変更したか」といった情報を記録し、過去のある時点の状態を復元したり、変更内容の差分を表示できるシステムである。もともとLinuxの開発時にLinuxのソースコードを効果的に管理するために開発された、比較的新しいバージョン管理システムである。Linuxの開発では非常に多くのプログラムファイルを扱うため、正確かつ高速にファイルの変更履歴管理が行えるよう工夫されている。そして、Gitの仕組みを利用して、世界中の人々が自分の作品(プログラムコードやデザインデータ等)を保存、公開することができるようにしたWebサービスの名称がGitHubである。GitHub社が運営しており、個人・企業問わず無料で利用できる代わりに、登録した資産については全て公開される。ただし、有料サービスを選択すれば、限定されたユーザだけで、プライベートに資産を管理することができる。
　一般的に、法律の条文や会社の規程など、変更を加えながら長期間利用する文書の変更履歴を管理しようとすると、簡単な方法として「ファイル名で管理」する。変更する前にファイルをコピーし、ファイル名に日付や変更者の名前等を付け、いつ、誰が変更したファイルであるかをわかるようにしておく。しかしこの方法では、ファイル名の付与規則を組織で共有し順守しなければならない。また、変更箇所を確認するためには、変更前のファイルを探し、変更後のファイルと目視で比較しなければならず、大きな労力がかかると同時に、誤りの発生も多くなる。さらに、組織内で複数名が同時に変更を行う場合、先に変更した人の変更内容が消える（上書きされてしまう）というリスクも発生する。バージョン管理システムは、このような問題解決のために開発された電子ファイルの変更履歴管理システムといえる。バージョン管理システムの代表的な機能としては、最新原本の取得、原本への変更の反映、最新原本の維持と変更履歴の管理、変更作業における競合の解決、誤った変更の修復がある。

Git/GitHubによる文書の変更と協働の可能性

　このGit/GitHubを使って文書の変更作業を行い、協働の可能性を探ってみよう。もともとバージョン管理システムはプログラマが利用するツールであり、コマンドベースでコントロールするものであった。しかし、最近ではGUI(Graphical User Interface)ツールが出現し、コマンドを使わなくても画面上の操作で使えるようになっている。代表的なものとして、Tortoise Git、Git for Windows、GitHub for Windowsがある。

　基本的な操作を図表3で示す。最新の原本は、リモートリポジトリという共有書棚で管理されている。これを変更する場合、原本と同じものを自分専用書棚であるローカルリポジトリに複写（クローン）する。Aさんはこのローカルリポジトリを使って文書の変更を行うが、変更の作業中においてはローカルリポジトリの写本は変更されない。変更完了（コミット）を宣言して、ローカルリポジトリの写本の内容が変更される。
　ローカルリポジトリにおいて変更作業がすべて完了したら、その内容をリモートリポジトリへ反映（プッシュ）することができる。このとき、すでにBさんがリモートリポジトリの原本を変更していると「競合」が発生し、その状況を解決しなければ反映することができない。
　これが簡単な操作の仕組みだが、GitHubになるとGitHubのWebサイトに変更グループごとのリモートリポジトリが設置され、もっと大規模な組織による変更作業が可能となる。図表４はWord文書を変更した時の表示(Tortoise GitがWordの文書比較機能を呼び出して表示)であるが、右上の枠内には旧文書が表示され、右下の枠内には新文書が表示され、中央に比較した結果が表示される。表形式であっても、どの部分が変更されたかが明確に示される。
　このようにツールの有効性は確認できたが、課題も明らかとなってきた。まず、GUIツールが提供されているとはいえ、一般人には各操作の概念理解が難しく、使いづらいことがあげられる。また、操作中にエラーなどが発生した場合、GitHubに詳しい管理者が必要となる。Windows Pluginを使うことでWord、Excel、Powerpointなどのファイルも扱うことができるが、変更がファイル単位になるため部分的な修正でも競合が発生してしまう。TEXTファイルを使えばそのような問題は解消できるが、法令文書には表形式も含まれるため、さらなる機能の向上が望まれる。
　さらに、Git/GitHubの特徴として、Linux開発用のため大規模なプログラマ集団の管理や多層管理が可能となっており、修正ミスが発生しても拡大させずに復元できるといった豊富な機能を持っている。そのため、使いこなすには管理者も利用者もかなりのスキルを必要とする。つまり、一般的な使い方をするためには、管理者が機能を絞り込み、運用ルールを決めたうえで使わせる必要がある。
　このように、バージョン管理システムはプログラマ用ツールから汎用ツールへ進化中であるといえ、まだまだ課題が残っている。しかし、バージョン管理システムの機能をそぎ落とし、一般的な概念で文書が扱えるツールを開発すれば、一般人でも十分使いこなすことができるだろう。法令文書の条文だけでなく、計画書やガイドラインの変更など、公共分野における協働作業環境として、大きな可能性を持っている。

おわりに

　日本においても、GitHubを公開用ツールとして使う事例がでてきている。米国においても、オープンデータ、研究用データ、アルゴリズム、技術的解決策、RFI(Request for Information)などの様々な分野に適用されつつある。
　文書やデータなど、デジタルな資源をオープンに互恵の精神で使うというソーシャルコーディングの考え方は、オープンソースのプログラムに限らず、公的部門のデジタル資源にも広がっていくだろう。新たなツールを用いて、デジタルな公共資源をより多くの人々が共有できるようになれば、我々の世界を現在よりもより民主的な世界へと進化させていくことができる。
　一方で、日本の電子政府の現状を見る限り、立法を含めまだまだ「紙文化」から脱却できていない。法改正は改め文と新旧対照表で行われるが、機能的には新旧対照表だけで十分である。改め文を使っているのは、新旧対照表だと紙が膨大な量になるという理由からだ。紙では膨大な量でも、電子データならばメモリチップに入る。実は、苦労して改め文を作る必要はないのである。
　それだけではない。法令提供データベースは実質的に原本の役割を果たしているが、法的には原本とみなされず、曖昧な状態に置かれたままだ。法令文書の書式変更、横書きや西暦の採用もいつになるかわからない。このような状況のままで、我が国は民主的な国家であるといえるのだろうか。ITという技術の進展は、国のあり方自体を問うまでになっている。