NISHIO Hirokazu[Translate]
議論する価値のある問いを設定したい

デジタル民主主義2030 Slack

Shutaro Aoyama (ぶるーも)
問いの生成について:
あるテーマに関する「課題」と「解決策」が大量にあるときに、そこから議論するべき「問い」を設定したい
議論する価値のある問いを設定したい
たぶん2パターンの問いがありえる
1. 現状はAだが、これをBにするにはどうすればいいだろうか?(howの問い)
今の実装はこっち
2. 現状はAだが、Bになるべきだろうが?(goalの問い)
これもあったほうがよさそう

NISHIO Hirokazu
議論をする価値のある問いに関してはまだあやふやなのでまずはhowの話をする前にもっとかき回してみると:
「2パターン」と言ってるのが焦って絞り込みすぎてる感じがある
「現状はAである」
「現状はAである、これはよくない」
「現状はAである、これはよくない、抜け出すにはどうすればいいか?」
「Bである方が現状より良い」
「Bになるためにはどうすればいいか?」
Bが言語化されてない0個のフェーズ、1個あるフェーズ、複数個あるフェーズがあると思う
直感的には3個くらいで議論をしてから1個に絞るべき

関連
>判断は「very good」「satisfactory」「poor」の3分類で評価。(以下a,b,c)
> 選択肢が3件の場合、2件の場合に比べて (a + b) / c が7.7倍、a / (b + c) が16.7倍であった。

o3
問いを評価する4基準
基準/意味 & チェックポイント/定量化ヒント
Impact 影響度
誰がどれだけ得失を被るかを明文化できるか。
予算・法改正・生活コストなど “数字” を伴う利害が説明できるか?
関係人口 × 想定変化額 ≒ 粗い期待値
Divergence 分岐性
価値観・利害の対立幅。
意見が2峰性以上なら高スコア。
“賛否比率 3:7〜7:3” が最も議論価値が高い。
embedding クラスタ間コサイン距離の平均
Feasibility 実行可能性
結論が行動に落ちる余地。
“権限者が1ステップで試せるか?”
既存制度・技術に近いほど高。
最小実装に必要なリソース数/期間
Timeliness 時機性
締切・窓の有無。
予算要求・条例改正・イベント前後など “時間的プレッシャー” があるか。
残存日数の逆数(近いほど高)

コツ:Impact と Divergence が高く、Feasibility と Timelinessが “ほどほど以上” なら 議論コスパ最良。

感想nishio
複数の問い候補がある時にどれを選ぶか
実行可能性と時機性が低すぎると足切り対象になる
「2030年のデジタル民主主義とは?」は締切が遠すぎるんだな
「デジタル民主主義2030」プロジェクトが「2025年7月の選挙までに有用なツールを作ってリリースするぞ」とタイムスコープを切ったのはうまい手だったということか
実行可能性も「OSSツールを作って公開」という形にしたのはよかった
「政府に台湾のJOIN的なものをやらせる」だとプロジェクトメンバーが実行することではなくなってしまう
影響度は大きい方がいい
実行可能性とトレードオフ
デジタル民主主義2030のSlackだと、こういうことをやっていくことに異論がない人が集まってるから分岐性が低いんだな
プロジェクトの外の、AIをよくわからないと思ったり、漠然と怖がったり、敵視したりしてる人と半々のグループで議論すると面白くなりそう
AI嫌いな人をAIの議論に呼び込むという本質的な難しさがあるw
AIがそういう人間をエミュレートしたらいいんじゃないか
これをやり出すと「そもそも人間が議論する必要はないのでは」になってしまう

o3
フレーム(A→B→How)を使った問いの粒度調整
現状把握 (A: Descriptive)
例:「中野区の空き家率は 9%」
議論目的: ファクト確認・データ共有
適した基準: Impact (規模感を数字で示す)
評価 (A Good/Bad: Evaluative)
例:「空き家率 9% は都市活力を損ねる」
議論目的: “なぜ問題か”の合意形成
適した基準: Divergence (問題視の温度差)
目標設定 (B: Normative/Goal)
例:「5% 未満が望ましい」
議論目的: “あるべき姿”の明文化
適した基準: Impact(達成益)+Divergence(目標幅)
変化経路 (How: Strategic)
例:「所有者不明物件データ連携をどう実装?」
議論目的: 施策アイデアの発散と絞り込み
適した基準: Feasibility + Timeliness

感想nishio
割と無理してフレームワークにしてる感があるね
今回想定しているユースケースでは人々を枠にはめて特定の流れで議論させることはできないと思う

粒度の合わせ方
状況/推奨粒度/典型的失敗
データ不足・論点混沌
①現状把握
いきなり How に飛ぶ
あるあるすぎるnishio
「これをこうしたらいいと思う!」といきなり言い出す人が多すぎる
ソフトウェア開発でもそう
「なぜそれをした方がいいと思うのか」を掘り下げる必要がある
これは場全体に投げかける問いというよりは個々人に対する質問の仕方だな
価値観対立が顕在化
②評価
“みんな問題視してる前提” で話を進める
nishio
(1)の掘り下げをやった結果として「何が良いか、何が悪いか」の価値観に食い違いがあることが明らかになる
「原発が稼働しているのは良くないので即刻廃炉すべき」
"原発が稼働しているのは良くない"が本人の中では暗黙の前提になっているが、それが実は人によって食い違っている
「高い電気代が家計を圧迫するのは良くないので、原発再稼働すべき」
目標が曖昧
③目標設定
施策を列挙するが優先順位が決まらない
実装フェーズ
④変化経路
決定者不在・締切なしで議論が空転
nishio
政策の議論というドメインを考えた時に(3)(4)まで民衆がするのか、(2)の価値観分布の可視化までをやって(3)(4)は政治家に取捨選択を任せるのか、という論点がありそう

"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]