Select a result to preview

法律はソフトウェアである

#thinking #analogy #democracy #software-architecture #team-topology

「法の基準を定数ではなく関数にすべきだ」——AIエンジニア出身の政治家・安野たかひろ氏（チームみらい）のこの主張を聞いたとき、ソフトウェアエンジニアなら即座に共感するだろう。最低賃金を「年額X円」とハードコードするのではなく「中央値所得のY%」と関数化すれば、法改正なしに社会変化へ追従できる。

だが、この発想を突き詰めると、もっと大きな問いに辿り着く。法体系そのものがソフトウェアとしての性質を持っているなら、ソフトウェアエンジニアリングのプラクティスは民主主義の設計に適用できるのか？ 本記事ではこの思考実験を、エンジニアリングプラクティスとの対応関係を軸に展開する。

法のソフトウェア的性質

法律をコードベースとして眺めてみると、驚くほど多くの対応関係がある。

エンジニアリング 立法・民主主義
コードベース 法体系全体
憲法 インターフェース定義
個別法 実装
判例 パッチ / ホットフィックス
法改正 リファクタリング
法案審議 コードレビュー
矛盾する法律 バグ
CI/CD 法の継続的更新・整合性チェック
モノリス 国会（全分野一括）

法律には依存関係があり、変更が他の法律に波及し、整合性の検証が必要で、時間とともに技術的負債が蓄積する。これはまさに大規模ソフトウェアシステムの特徴そのものである。

そして大規模ソフトウェアが直面する問題は、法制度にもそのまま当てはまる。アジリティの欠如とスケーラビリティの限界だ。

アジリティの問題 —— なぜ法改正は遅いのか

社会はリアルタイムに変化する。テクノロジーの進化、人口構造の変動、国際情勢の変化。しかし、立法プロセスはこの速度についていけない。

法案の提出から成立まで数ヶ月から数年。しかもその法律が「定数」で書かれている限り、社会が変わるたびに改正プロセスを一から回す必要がある。これは、設定値をソースコードにハードコードしているようなものだ。

# ハードコードされた法律（現状）
minimum_wage = 1113  # 円/時

# 関数化された法律（安野氏の提案）
def minimum_wage():
    return median_income() * 0.45

安野氏の「定数を関数にしろ」という提案は、ソフトウェアエンジニアリングで言えば設定値の外部化であり、ビジネスロジックとパラメータの分離である。これは現行制度の枠組み内での最適化として極めて実践的だ。

ただし、関数化しても関数そのものの改訂は必要になる。median_income() * 0.45 の 0.45 はなぜ 0.45 なのか。その根拠となるモデル自体が社会変化で陳腐化すれば、結局フィードバックループを回して関数を更新しなければならない。パラメータ化は有効だが、万能ではない。

「慎重さ」か「変えやすさ」か

法制度が変化に対して保守的であることは、怠慢ではなく不可逆な影響への恐れに根ざしている——という説明がよくなされる。ソフトウェアにおけるDBマイグレーションやデータ削除のように、ロールバックが困難な操作には慎重なプロセスが求められる、と。

しかし、法のフィードバックループは国レベルで回る。カナリアリリース的に「一部の国民にだけ適用する」ことは基本的にできない（特区制度など例外はあるが）。であれば、慎重さで対処するのではなく、変更を前提とした設計で対処する方が合理的ではないか。

ソフトウェア開発が学んだ教訓はこうだ——変更を防ぐのではなく、変更を安全にする。テストを書き、CIを回し、段階的にデプロイする。法律においても、「一度決めたら変えにくい」構造ではなく、「常に更新される前提で設計する」構造の方が、社会の複雑化に対応できるはずだ。

スケーラビリティの問題 —— 国会というモノリス

アジリティの問題に加えて、もう一つの構造的問題がある。国会がモノリスであるということだ。

現在の代議制民主主義は、こういう構造になっている。

国民 → [選挙] → 国会（全分野一括） → [立法] → 全法律
                    ↑
              政党がバンドル化

国民は「政党」というバンドルを選ぶしかなく、個別政策への意思表示は極めて限定的。医療政策はA党に賛成だが経済政策はB党が良い、という選好は表現できない。全議員が全分野の法案に投票するが、全分野を深く理解している議員はいない。これはモノリシックアプリケーションに全エンジニアがコミットするのと同じ構造で、規模が大きくなるほど破綻する。

分割するとしたら、どこで切るか

Team Topologies的に考えると、いくつかの分割戦略がある。

分野で切る（マイクロサービス型）

┌────────────────────────────────────────────┐
│      憲法・基本法プラットフォーム            │
│   （整合性チェック、矛盾検知、原則管理）     │
└────────────────────────────────────────────┘
        ↑          ↑          ↑
   ┌────┴───┐ ┌────┴───┐ ┌────┴───┐
   │ 医療法  │ │ 環境法  │ │ 経済法  │
   │  議会   │ │  議会   │ │  議会   │
   └────────┘ └────────┘ └────────┘

専門分野ごとに議会を設け、それぞれがオーナーシップを持つ。憲法・基本法は「プラットフォームチーム」として整合性チェックと矛盾検知を担う。Domain-Driven DesignにおけるBounded Contextの分割に似ている。

ただし、分野横断の法案をどう扱うかという依存関係管理の問題は残る。環境規制が経済に影響し、経済政策が医療に影響する。マイクロサービスでも同じ問題がある——サービス間の依存関係が爆発すると、分割した意味がなくなる。

変更頻度で切る（レイヤードアーキテクチャ型）

もう一つの切り方は、内容ではなく変更頻度でレイヤーを分けるアプローチだ。

運用層は専門家やデータ駆動に委ね、国民投票は不変層と構造層に限定する。これは安野氏の「関数化」と組み合わせると、運用層の多くを自動調整に任せられる可能性がある。

なお、望ましい法体系の構造から逆算して立法組織を設計すべき、というのはコンウェイの法則の逆適用（逆コンウェイ戦略）にあたる。現在の国会の構造（委員会制度など）は法体系の構造からではなく政治力学から決まっているわけで、ここに構造的なミスマッチがある。

トレードオフの構造

ここまでの議論で、3つの軸が浮かび上がってきた。

graph TD
    A[アジリティ
法改正の速度] --- B[専門性の活用
知識ある人の判断を重視]
    B --- C[正当性の維持
人権・平等の原則]
    C --- A

    style A fill:#e8f4f8,stroke:#2c3e50
    style B fill:#fef9e7,stroke:#2c3e50
    style C fill:#fdedec,stroke:#2c3e50

この3つは互いにトレードオフの関係にある。

アジリティ vs 正当性

法改正を速くするには意思決定プロセスを簡略化したい。しかし、簡略化は民主的なプロセスの省略を意味しうる。行政命令で即座に法を変えられる体制は確かにアジャイルだが、それは独裁と呼ばれる。

専門性の活用 vs 正当性

専門性が高く、汚職のない、貢献意欲の高い人の票に重みがついた方が、より良い決定ができる可能性は高い。これは事実だろう。しかし、ここに制度の根源的な難しさがある。

会社と社会の構造的差異を考えてみよう。

会社：ビジョン + 経済合理性 → 「正しさ」の基準が比較的明確
社会：人権 + 生活保障 + 規範の安心感 → 「正しさ」の基準が多元的

会社では「儲かるか」「プロダクトが良くなるか」という比較的明確な判断基準があるから、的外れな意見を無視しても正当化できる。ビジネスにおいて的外れな意見は無視されるだけだ。しかし民主主義の投票においてはそうはいかない。

なぜか。社会には人権と最低限度の生活保障があり、それらは社会規範が守られることでの安心感につながっている。誰かの意見が無視されて良いということは、その人の人権に関わる。そしてそうでない人にとっても、規範がなければ恐怖を感じて暮らさざるを得ない。「自分の意見が構造的に軽視されるかもしれない」という不安は、社会の安定を根底から揺るがす。

つまり票に傾斜をつけるということは、権威主義的な構造に近づくことであり、汚職も発生しやすくなる。「誰の意見をより重視するか」を決める権力は、それ自体が最大の権力になる。メタレベルの権力が最も腐敗しやすいという構造的問題だ。

アジリティ vs 専門性の活用

分野別議会で専門家がオーナーシップを持てば、意思決定は速くなりうる。しかし専門分野の知識は全国民にはわからないのだから、どうやって代表者を決めるのか。現在の選挙でも複雑な政策の専門性など判断できていないのだから、分野別にしたところで本質的には変わらないかもしれない。

エンジニアリングから得られる示唆

トレードオフ構造を完全に解消することはできないが、エンジニアリングのプラクティスにはいくつかのヒントがある。

チーム責任とポストモーテム文化

意思決定の責任は個人ではなくチーム全体で負うべきだ。これはエンジニアリングチーム運営と同じプラクティスで、個人のblameではなくチームのaccountability。バス係数が1の組織は脆いし、個人に責任を負わせる構造は隠蔽を誘発する。

「誰が悪いか」ではなく「なぜこの決定に至ったか、プロセスに問題はなかったか」を問うポストモーテム文化は、政治にも応用できるはずだ。政治家個人のスキャンダルを追及するのではなく、そのような決定が生まれたプロセス自体を改善する。

内部複雑性の抽象化

制度の複雑さ自体が民主主義的正当性を損なうというパラドックスがある。

「より良い意思決定のために複雑な仕組みを作る」→「複雑すぎて国民が理解できない」→「理解できない仕組みに正当性を感じられない」→「制度への信頼が下がる」

これはソフトウェアの認知負荷問題と同じだ。内部の複雑さを抽象化してシンプルなインターフェースを提供する必要がある。複雑な投票重み付けアルゴリズムが裏で動いていても、国民から見たインターフェースは理解可能でなければならない。

民主主義が満たすべき「インターフェース」

全ての法律を全国民が決める必要は本当にあるのか。守るべきは「一人一票」という形式ではなく、以下のような性質ではないか。

これらが満たされていれば、「全員が全部に投票する」という形式は必ずしも必要ないかもしれない。逆に言えば、現行の民主主義はこれらの性質すら十分に満たせていない面がある。投票はできるが透明性は低く、異議申立ては形骸化し、説明責任は曖昧だ。

結び —— 構造を可視化することの意義

本記事は答えを出すことを目的としていない。民主主義のアーキテクチャを「正しく」設計する方法を提示できるわけではないし、そんなものがあるとも思わない。

しかし、ソフトウェアエンジニアリングのプラクティスとの対応関係を描くことで、問題の構造を可視化することはできる。アジリティ、専門性、正当性のトレードオフ。モノリスの限界。メタ権力の腐敗。認知負荷と抽象化。これらは政治学の言葉では語りにくいが、エンジニアリングの語彙を使えば構造的に捉えることができる。

安野氏の「定数を関数にしろ」は、この構造的理解から生まれた現実的な一手だ。そして同時に、より大きなアーキテクチャ変更——立法プロセスそのものの分割と再設計——の入り口でもある。

ソフトウェアエンジニアが政治を考える価値があるとすれば、それは政策の中身について意見することではなく、意思決定の構造そのものを設計対象として捉える視点を持っていることにあるのだと思う。

関連ノート

抽出された概念

この記事から以下の一般概念をnotesに抽出した。

既存ノート（コンウェイの法則には逆コンウェイ戦略を記載済み、ポストモーテム、認知負荷、抽象化）も参照。