今国会で多数の法案にミスが見つかり、物議を醸している。誤りがあったのは、法案23本、条約1本。発覚のきっかけとなったデジタル改革関連法案では、45カ所ものミスがあったという。
法案は中核をなす案文のほか、理由・要項・新旧対照表・参照条文の参考資料で成り立っており、「5点セット」と呼ばれる。このうち、とくに参考資料で誤字やインデントの間違いなどの不備が見つかっている状況だ。
問題はなぜ起きたのか。法制執務を担当する官僚たちの気のゆるみ、コロナによる読み合わせ機会の減少、人繰り、法案作成に使われるワープロソフト…挙げられる理由はさまざまで、現在、省庁横断のプロジェクトチームによって再発防止策が検討されている。
この問題を「起こるべくして起こった」と捉える人々もいる。ふだんはプログラマーとしてデータ分析基盤の開発をしている芝尾幸一郎さんもその1人だ。
芝尾さんは、プログラマーが著作権法上の罪に問われたWinny事件を機に同法を読み、条項の複雑さに驚いた。法律のネットワークを分野ごとに可視化する「可視化法学」というプロジェクトを2016年に始めたのは、それがきっかけだったという。
現在は大学院時代の同級生・永嶋敏之さん、岡澤理奈さんとともに活動中だ。
法律の関係を可視化してきたプログラマーは、今回の法案ミス問題がなぜ起きたと考えているのか。IT分野の知見で再発は防げるのか。芝尾さんに聞いた。（ライター・松本香織）
●特定の法律分野はスパゲティプログラム化している
――今回の法案ミス問題をどうご覧になっていますか？
芝尾幸一郎さん（以下、芝尾）：私には法制の実務経験がありません。にもかかわらず法案ミスを語るのは、プロ野球で監督の差配に対して野球ファンのおっちゃんが好き勝手言うようなものだと思います。しかし、これまでプログラマーとして働いてきた経験からすると、「ものごとが複雑になるとミスが起きやすい」と言えます。
――今回問題になったデジタル改革関連法案は、60以上もの法律を束ねたものだといいます。多くの法律を参照している法案の場合、ミスが起きる可能性が高いのでしょうか？
芝尾：はい。私は法律の参照構造をプログラムで抽出して可視化する「可視化法学」というプロジェクトを主宰しています。実際に可視化した法律の分野を2つお見せしながら、ミスが起きやすくなる理由を説明しましょう。
「河川」と「社会保険」という別分野の可視化例（図1）
左が「河川」分野の法律、右が「社会保険」分野の法律を可視化したネットワークです（図1参照）。点がそれぞれの法律で、線が参照の関係です。色はそれぞれの法律がどの分野に属するかを表しています。さまざまな分野の法律から参照される法律ほどカラフルで、点と法律名が大きくなります。
まず、「河川」分野の可視化例を見てみましょう。同分野では河川法がさまざまな法律に参照されており、この法律を念頭において法制執務にあたればよいとわかります。一方、右の「社会保険」分野では、国民年金・健康保険・厚生年金・国民健康保険など、さまざまな法律との関係を考えねばならず、そのぶん複雑です。
プログラミングでは、さまざまな要素が絡み合い、ミスが起きやすくなったプログラムを「スパゲティプログラム（コード）」と呼びます。つまり、特定の法律分野はスパゲティプログラム化しているのです。複雑な部分に注意を奪われれば、当然凡ミスが増えますよね。今回の法案ミス問題を知って、それは不備も生じるだろうと思いました。
――法律の複雑さについては、ドワンゴ創業者の川上量生さんが以前、異なるアプローチで検証していましたね。
芝尾：そうですね。川上さんはプログラムの複雑度を測る「循環的複雑度」で、商法と著作権法の構造を確かめたそうなんです。すると、商法では11、著作権法では103という数値が出た。循環的複雑度が75以上になると、98％の確率でバグが混入するといいます。つまり、商法はシンプルな構造でミスが起きにくく、著作権法は複雑な構造でミスが起きやすいわけですね。
――こうした複雑さをIT分野ではどのように解決しているのでしょうか？
芝尾：複雑さにどう立ち向かうかは、プログラマーにとって大きな問題です。たとえばベンチャー企業が発表したプロダクトが思いがけずヒットし、利用者は増える、機能はどんどん追加する……で走り続けたとしますね。すると、プログラムが複雑になり、ちょっと触るとバグが誘発されるようになります。そこで開発の現場では、全体を見直したり、使わない機能は消したりして、よりサービスに適した形に作り直すんですね。これを「リファクタリング」と呼びます。
法律では、特例が残って増え続けたりすると、分野全体で見たときに複雑になってしまいます。でも、これをリファクタリングするのは、とても難しいですよね。政治家も陳情する人も「ルールを増やそう」という方向にはいくけれど、「ルールを削ろう」と言う人は少ないですから。無理にシンプルにしようとすると、今度は見捨てられる人が出てくる可能性があり、バランスが難しいですね。
プログラムと法律を重ねて語るのには限界があります。けれど、法律は法律でリファクタリングのやり方を考えてもいいかもしれないとは思います。
●人間はミスをする生き物、仕組みで防ぐことを考えるべし
――今回の法案ミスをめぐっては「法制執務にあたる官僚の気のゆるみだ」とも言われています。
芝尾：あまり根性論にはしたくないですよね。人間はミスをする生き物ですから。どちらかというと、「仕組みで防ぐ」という考え方のほうがいいと思います。
――それは、どういうことでしょうか？
芝尾：専用のツールを作るなどしてミスが起きにくい仕組みを作ればいいと思います。今回の法案ミスでは、ワープロソフト「一太郎」が問題だとして、農水省が使用を禁止したという「誤報」も出回りました。しかし、そもそも既存のワープロソフトが法令を作成するうえで最も適したツールなのだろうかとの疑問がわきます。法制執務に適したツールを作ったほうがいいかもしれません。
――たとえばどんなものを？
芝尾：法案5点セットの一つに「新旧対照表」がありますよね。同表では、改正案と現行法が上下に分けて記載されています。これを法案作成者が作るとき、どうしているのか気になります。上下二段に条文をコピペし、改正予定の箇所以外は削除、インデントや改行は一つずつ入れる……という細々した作業をしているのかなと。言うまでもなく、自動で新旧対照表の雛型が作れるツールがあれば、間違いもないし、楽ですよね。
新旧対照表の例（図2）
その際、書きたい条項と似た条項を引っ張ってくる機能があれば便利です。聞いたところによると、法制執務では、一般にも公開されている「e-LAWS」という法律データベースから似た条項を探し、コピペすることがあるらしいんですね。たとえばガス系の分野の条項を書いていたとして、健康分野と電気分野ならば後者のほうがより適切な条項である可能性が高いわけです。e-LAWSの検索結果を見たとき、似た分野の条項がどれかすぐわかり、並べ替えができたらいいだろうなと思います。
レイアウトも気になる問題です。プログラミングでは、見た目のデザインと中身の構造を分離して考えます。法律で重要なのは中身のはずで、見た目に関する部分は、機械に任せたほうがいいと思うんですよ。人間の認知資源は限られているけれど、やるべき部分を小さくすれば、そのぶんミスも減ります。今回の法案ミスでは、条項の字下げが違っていたという問題があったようですが、ツールがあれば防げた問題ではないかと思います。
加えて、間違いが起きたとき、注意を促すような機能があればいいですね。過去に起きたミスの蓄積や法律分野の傾向から、間違っている可能性の高い部分は文字色を変えたりできると思うんですよ。ガスの法案に健康保険で使われる用語が入っていれば、おかしいから注意を表示するような。
私は法案ミスの問題とはまったく別に、法制執務がデジタル化でもっと楽にならないか、1年ほど前から世界経済フォーラム第四次産業革命日本センターの方と議論をしています。現在は法制執務の経験がある方に、実際の業務内容はどのようなもので、どのような作業に時間をとられているかをヒアリングしている最中です。
●ITの支援ツールを導入して「終わり」にしないで
――法律関連では、あまりツールが整備されていないのでしょうか？
芝尾：海外の事例ですが、EUでは「LEOS」というオープンソースの法制執務アプリが提供されています。先ほど言ったようなデザインと構造の分離ができるだけでなく、法案にレビューやコメントが付けられたり、バージョン管理できたりします。日本では、契約書に関してはインデントの乱れや表記揺れ、条番号や参照番号のずれなどを自動で検出して補正するツールやAIを使ってレビューするサービスを提供している会社があります。
――プログラマーがふだん仕事で使っているツールには、ミスを防ぐ仕組みがある？
芝尾：はい。プログラマーは基本的に「ミスは発生するもの」と考えています。ですから、ミスを防ぐ仕組みをアップデートし続けています。プログラムを書くときに使う統合開発環境（IDE）では、記述の補完やタイプミスの検出が自動でできるものが多いです。Gitのようなバージョン管理ツールも整備されており、何か起きたとしても前の状態にすぐ戻せます。
プログラマーのために作られた統合開発環境（IDE）の例。上述した機能のほか、プログラムを自動で見やすく色分けする機能などが搭載されている（図3）
プログラムのバージョン管理ができるサービスでは、どこに変更が加わったか、ビジュアルで確認できるものも多い。上はGitHubの例（図4）
――法制執務の改善に活かせそうなITの知見はありますか？
芝尾：改善にあたっては、まず「計測」が大切だと思います。プログラマーには自分が書いた処理のスピードを計測する「プロファイリング」という文化があります。たとえばデータベースからデータを引っ張ってくるのに何ミリ秒（1ミリ秒=1000分の1秒）かかったなど、まず計測しておいてから効率化をする。「推測するな、計測せよ」。だから、自分たちのタスク管理でも同じことをするんですね。
官僚は忙しいとよく言われます。しかし、具体的に何に時間がかかっているかは一般に知られていません。どのタスクにどれくらい時間がかかっているか、その作業の中で人手による繰り返し作業はどれくらいおこなわれているか、まずはタスクの整理をしてみるといいかもしれません。
その際、プログラマーが仕事の様子を背後で見ていて、自動化や効率化ができそうなタスクを見つける手法が有効です。これは総務や財務といった部署の困りごとを解決する際、ときどき使われる手法です。
法制執務そのものの効率化や自動化ツールの作成を担当する専門のプログラマー集団を作るのもいいですね。mixiには「たんぽぽグループ」という凄腕プログラマー集団がいて、プロダクトの開発ではなく、開発全体や開発基盤そのもののパフォーマンス改善を担当しているそうです。
――再発防止のために結成された省庁横断のプロジェクトチームでは現在、デジタル技術の活用を視野に入れているともいいます。
芝尾：ITの支援ツールを導入するのはいいと思います。でも「入れました、はい終わり」では厳しいですね。法制執務のデジタル支援に関して、誰も正解を知らないから、1回やっただけでは結果が出ないと思うんです。実際に試してみて、何度も作り直していくしかありません。ずっと改善し続ける視点を持つことが大切ではないかと思います。
私は法律の専門家ではなく、今回お話ししたのも「プログラマーだったらこうするだろうな」という素朴なアイディアにすぎません。専門家からすれば「そんなのわかっているよ」という話もあろうかと思います。ただ、法制執務に携わる方々に何かのかたちで役に立つならばうれしいです。
・可視化法学のツイッター
https://twitter.com/lawvis
・可視化法学のウェブサイト
https://www.lawvis.info/
