政治や政策の議論を聞いていて、「結局、それはあなたの感想ですよね？」と感じてしまうことはないでしょうか。
特にエンジニアリングの現場で、KT法（ケプナー・トリゴー）やフィッシュボーン分析といった論理的な問題解決手法を叩き込まれてきた人間からすると、現在の政治が行っている「分析」や「対策」は、あまりに詰めが甘く、デバッグ（不具合修正）の体をなしていないように見えます。
「予測が難しい未来」を語る前に、まず「足元のバグ」をどう特定し、どう修正すべきか。エンジニアの基礎である原因分析ツールの視点から、政治を動かすための具体的なプロセスを提案します。
1. 「状況把握（SA）」：問題を分離し、優先順位をつける
政治の議論では、「景気が悪い」「少子化が深刻だ」といった巨大な塊のまま語られがちです。しかし、エンジニアがトラブル対応をする際、まずは現象を「分離」することから始めます。
- 事柄の分離: 漠然とした不安を、実質賃金の低下、教育コストの上昇、あるいは特定の制度上の不備などに切り分けます。
- 優先順位の評価: 全てを同時には解決できません。「緊急性（いま打つべきか）」「重大性（放置するとどうなるか）」「拡大傾向（影響範囲は広がるか）」の3軸でスコアリングし、リソース（予算・人員）を集中させるべき箇所を可視化します。
2. 「原因分析（PA）」：IS / IS NOT で真因を炙り出す
「分析した」と言いながら、相関関係と因果関係を混同しているケースが散見されます。ここで導入すべきは、KT法の真骨頂である「IS / IS NOT（比較による絞り込み）」です。
例えば、ある子育て支援策が効果を上げていない場合：
- IS（起きている場所）: 都市部の共働き世帯。
- IS NOT（起きていない場所）: 地方の多世代同居世帯。
- 違い（Distinction）: 両者の決定的な違いは何か？（住宅コストか、周囲のサポート体制か）。
このように「問題が起きているケース」と「似ているが起きていないケース」を対比させることで、単なる感想ではない「真因（バグの所在）」を特定できます。フィッシュボーン分析を用いて、制度・経済・インフラ・社会意識といった多角的な要因から、なぜ（Why）を繰り返して深掘りすることも不可欠です。
3. 「意思決定（DA）」：MUST と WANT を分ける
「この政策がベストだ」という主張に説得力がないのは、選択の基準が不透明だからです。
- MUST（必須条件）: 「〇ヶ月以内に執行できる」「事務手数料が〇%以下」といった、絶対に譲れないラインを定義します。
- WANT（希望条件）: 「波及効果が高い」「公平性が保たれる」などの項目に重み付けを行い、複数の案をスコアリングします。
このシートを公開すれば、「なぜその案を選んだのか」というロジックが誰の目にも明らかになります。
4. 「将来問題分析（PPA）」：想定外を仕様に組み込む
予測が難しい時代、最も信頼されるのは「絶対に失敗しない」と豪語する人ではなく、「失敗した時の備えができている人」です。
- 潜在的脅威の特定: 政策を実行した際に起こりうる副作用をあらかじめ洗い出します。
- 予防対策と発生時対策: 脅威を防ぐための「予防策」と、万が一起きてしまった時の「プランB（バックアップ）」を法案に組み込んでおきます。
結論：政治を「感想」から「エンジニアリング」へ
野党の国会議員が政治を動かしたいのであれば、情緒的なスローガンを叫ぶのではなく、「仕様書」と「デバッグ報告書」を持って国会に臨むべきです。
- PA（原因分析）で政府の失策のバグをIS/IS NOTで証明する。
- DA（意思決定）で、客観的な評価基準に基づいた最適解を提示する。
- PPA（将来問題分析）で、リスクを管理し、柔軟な軌道修正を可能にする。
「何が良いのか」という予測が難しいからこそ、我々が培ってきた「間違えたときにすぐ気づき、論理的に直せるシステム」の構築が求められています。政治を論理の土俵に引き戻すこと。それが、実務家としての私たちが政治に求める最低限の「品質基準」です。
コメントを残す