〜なぜ「良かれと思った政策」が社会のバグを生むのか〜
日本のニュースを見ていると、多くの人がこう感じているはずです。
「なぜ、あれほど時間をかけて議論した政策が、いざ始まると使いにくかったり、期待したほど効果が出なかったりするのだろう？」
もちろん、現実の政治にも検証や改善の仕組みは存在します。実証実験、審議会、政策評価、自治体レベルでの先行実施など、いわば「テスト」に相当するものです。
しかし、それらが形式的になったり、失敗を前提とした改善サイクルとして十分に機能していないケースも少なくありません。 これらは、ソフトウェア開発の世界では「限界が知られている作り方」に近い構造を持っています。 今回は、エンジニアの知恵である「TDD（テスト駆動開発）」という考え方をヒントに、日本社会をどうアップデートできるのかを考えてみます。
目次
- 今の政治は「テスト不足の開発」に近い
- TDD（テスト駆動開発）という発想
- 「Red（失敗）」を受け入れる勇気
- 「従来型政治」と「TDD型政治」の違い
- 「テスト」は誰が書くのか？
- 政治をアップデートする「3つの言葉」
1. 今の政治は「テスト不足の開発」に近い
想像してみてください。
あるIT企業が、数年かけて巨大システムを開発しました。しかし完成するまで十分な検証を行わず、リリース直前になって初めてテストを実施した結果、現場で大量の不具合が発生した――。
現在の政策形成には、これに近い側面があります。
「失敗を認めにくい制度設計」
日本の行政や政治には、失敗を認めにくい構造があります。
一度決まった計画は途中で止めづらく、軌道修正にも大きなコストがかかります。
さらに問題なのは、「失敗したかどうか」を測定する基準そのものが曖昧なケースです。
たとえば、
- 「安心できる社会」
- 「豊かな地域づくり」
- 「活力ある経済」
といった目標は重要ですが、抽象的すぎると検証が困難になります。
エンジニアの言葉で言えば、
「テストケースが曖昧なまま、本番環境へ公開している」
状態に近いのです。
2. TDD（テスト駆動開発）という発想
ここで登場するのが、ソフトウェア開発で使われる手法の一つ、テスト駆動開発（TDD: Test-Driven Development）です。
通常の開発では、「作ってから確認する」という順番を取ります。
しかしTDDでは逆です。
まず最初に、
「何をもって成功とするか」
を定義します。
つまり、「正しく動いている状態」を先にテストとして記述するのです。
TDDは、次の3ステップを高速に回します。
Red（失敗）
まず、「成功条件」を定義する。まだ達成していないため、テストは失敗します。
たとえば：
- 待機児童数を○年以内にゼロへ
- 手続き時間を平均30分以下へ
- 若年失業率を○%改善
など計測可能な形に落とし込む。
Green（成功）
次に、そのテストを通すための最小限の施策を実装する。
重要なのは、「最初から完璧を目指さない」ことです。
小規模な実証実験や限定地域での導入など、リスクを限定しながら改善を試みる。
Refactor（改善）
テストを通過した状態を維持しつつ、制度そのものを改善していく。
たとえば：
- 重複した制度の統合
- 不要な規制の削減
- 手続きのデジタル化
- 補助金構造の整理
などです。
ソフトウェアでいう「動くコードを壊さずに整理する」に近い発想です。
3. 「Red（失敗）」を受け入れる勇気
TDDで象徴的なのは、最初の状態が「Red（失敗）」であることです。
これは非常に重要な思想です。
現在の政治では、政策が期待通りに機能しないと、
- 「誰の責任だ」
- 「税金の無駄だ」
- 「失策だ」
という犯人探しに集中しがちです。
その結果、政治家も官僚も「失敗しないように見せる」方向へ動きます。
すると何が起きるか。
検証不能な曖昧な目標が増えます。
しかしTDDでは、失敗は「改善のためのデータ」です。
テストが失敗したなら、
- コード（政策）を書き換える
- 設計（戦略）を見直す
- テスト条件自体を再検討する
というサイクルを回します。
重要なのは、
「失敗しないこと」ではなく、「失敗を検知できること」です。
ただし、社会はソフトウェアとは違います。
政策の失敗は、人の生活や人生に直接影響します。
そのため、医療・福祉・教育のような領域では、「まず試す」が許されない場合もある。
だからこそ重要なのが、
- 小規模実験
- サンドボックス制度
- ロールバック（巻き戻し）可能性
- 限定導入
4. 「従来型政治」と「TDD型政治」の違い
| 従来型（ウォーターフォール的） | TDD型（テスト駆動的） | |
|---|---|---|
| ゴール設定 | 抽象的スローガン中心 | 計測可能な目標 |
| 失敗の扱い | 責任追及・隠蔽圧力 | 改善データ |
| 修正タイミング | 数年単位で遅い | 小規模に継続改善 |
| 予算 | 先に大規模確保 | 段階的投入 |
| 実装方式 | 全国一律導入 | 限定実験 → 展開 |
| 意思決定 | 上から固定 | フィードバック循環 |
もちろん、現実の政治はソフトウェアほど高速には動けません。
法律改正には時間がかかり、多数の利害調整も必要です。
それでも、
「最初から完璧な制度を作る」より、「改善可能な制度を作る」
方が、複雑な社会には適している可能性があります。
5. 「テスト」は誰が書くのか？
ここで重要な問いが生まれます。
「そもそも、成功条件は誰が決めるのか？」
これまでの政治では、
政治家・官僚・有識者
が「正解」を設計する構造が中心でした。
しかし、複雑化した現代社会では、中央だけで最適解を定義するのは難しくなっています。
そこで必要になるのが、「役割分担」です。
市民：Issue（課題）を提示する
現場で何が困っているのか。
どこに摩擦があるのか。
それを最初に発見できるのは、市民や実務者です。
専門家：Test（測定可能条件）へ翻訳する
「困っている」を、そのままでは政策にできません。
そこで、
- 何を測るのか
- どう測定するのか
- どの期間で評価するのか
を専門家が定義する。
行政・政治：Code（実装）を行う
そのテストをクリアするための制度や予算を設計する。
重要なのは、「何を達成すべきか」と「どう実現するか」を分離することです。
これは民主主義を「統治」から「共同開発」へ近づける発想でもあります。
6. 政治をアップデートする「3つの言葉」
ここまで読んで、「政治をソフトウェア開発のように改善する」というイメージが、少し見えてきたかもしれません。
実際、現代のソフトウェア開発には、
- 問題を整理する仕組み
- 提案を共有する仕組み
- 修正案を公開レビューする仕組み
が存在します。
重要なのは、「完璧な人が上から正解を与える」のではなく、
多くの人が参加しながら、少しずつ改善していく
という考え方です。
その視点で見ると、これからの政治を考えるうえで参考になる言葉が3つあります。
イシュー（Issue）
単なる不満ではなく、「何を解決すべきか」が整理された課題。
「なんとなく不便」ではなく、
・誰が
・どこで
・何に困っていて
・どうなれば改善と言えるのか
まで整理された状態です。
たとえば、
「子育てが大変」ではなく、「〇〇地域で待機児童が何人発生している」
のように、問題が具体化されている。
課題を曖昧な感情のまま扱うのではなく、「改善可能な形」に変換することが重要です。
プルリクエスト（Pull Request）
「私ならこう改善する」という公開提案。
ソフトウェア開発では、誰かが修正・改善を行ったとき、
「この修正を確認してください」
という形でチームへ提案します。
政治に置き換えるなら、
- 市民提案
- 条例案
- 政策提言
- オープンな改善案
に近いイメージです。
重要なのは、「提案」が密室ではなく、公開された状態で議論されることです。
コードレビュー（Code Review）
提案を、感情ではなくロジックとデータで検証する仕組み。
ソフトウェア開発では、どんな優秀なエンジニアでも、一人でコードを本番投入することは基本的にありません。 他者がチェックし、
- バグはないか
- 副作用はないか
- 長期運用できるか
- より良い方法はないか
を確認します。
政治でも本来必要なのは、
「誰が言ったか」ではなく、「その政策は本当に機能するのか」
を検証する視点です。
感情論や支持政党だけでなく、データ・再現性・副作用まで含めて議論する。
それが、「改善可能な政治」に近づくための土台になります。
まとめ：政治を「選ぶ」から「育てる」へ
これまでの政治は、「数年に一度、完成済みパッケージを選ぶ」という性格が強いものでした。
しかしTDD的な発想を導入すれば、
- 社会のバグを見つける
- 課題をIssue化する
- テストを定義する
- 小さく実装する
- 継続的に改善する
という「社会の共同開発」に近い形へ進化できるかもしれません。
もちろん、社会はソフトウェアではありません。
完全なロールバック（巻き戻し）もできず、人間の感情や価値観も絡みます。
それでも、
「失敗を前提に改善する」
という考え方は、複雑化した現代社会において、従来よりも柔軟な統治モデルになり得ます。
もしかすると未来の民主主義は、「誰が正しいか」を競うものではなく、「誰が改善できるか」を競うものになるのかもしれません。
後編（メンバーシップ限定）
しかし、本当に難しいのはここからです。
「改善し続ける社会が必要だ」という話には、多くの人が賛成できます。
問題は、
「その改善サイクルを、実際にどう設計するのか？」
です。
現実の政治には、
- 利害対立
- 情報の非対称性
- 既得権
- 制度疲労
- 官僚制の硬直性
といった、"巨大なレガシーシステム"が存在します。
つまり必要なのは、単なる理想論ではなく、
「社会を継続的デリバリー可能なシステムとして再設計する方法」
です。
後編では、
- Policy as Code（政策のコード化）
- CI/CD（継続的インテグレーション/継続的デリバリー）
- 自動監査システム
- 「国家 = オペレーションシステム」
という考え方などを題材に、「社会をどう実装可能なシステムへ変えるのか」を、技術視点を交えながら具体的に掘り下げます。
