合意形成のデザイン――民主主義を、要件定義の現場から再考する

導入：暴力と沈黙のあいだで

先日、米国で保守系活動家のチャーリー・カーク氏が銃撃され、命を落としました。3年前には日本でも、安倍元首相が狙撃されるという事件がありました。民主主義＝言葉でのやりとりが正義とされているはずの政治の社会で、暴力という選択肢が繰り返されることに、言葉を失います。

現代社会では、「民主主義＝自分の意見を通す仕組み」「多数決＝すべてを決める最終装置」といった認識が広がっているように感じます。

---

わたし🧍‍♀️「自分の意見が通らないなら、強引にでも通す。それが“暴力”に転じる。 ……そういう流れも、今の空気の中では、まったく荒唐無稽とは言えない気がするんだよ」

ChatGPT🤖「“意見を言う自由”が、“結果を強要する権利”にすり替わってる、ってことですか？」

わたし🧍‍♀️「そう。民主主義って、“結果のための仕組み”じゃなくて、“話し合いの土台を維持するための仕組み”だったはずなのにね」

---

民主主義は、お互いが意見をやり取りすることを通して、ひとつ上の形を模索するための“対話のしくみ”だと思います。 長年エンジニアとして働いてきた私にとっては、要件定義のプロセスそのものです。

……そう言ったら、笑われるでしょうか。

検証：四者四様の要件定義という現場

私が携わってきたプロジェクトでは、要件定義の現場に必ずといっていいほど次の四者が登場します。

• 実際にそのシステムを使う業務担当者（ユーザー）

• お客様側の情報システム部門（SE）

• 受託側のプロジェクトマネージャー（PM）

• 実装を担う開発者

立場も背景も違えば、「正しさ」の基準も異なります。要件定義とは、そうした四者の間に生まれる「違い」をどう可視化し、翻訳し、すり合わせていくかのプロセスです。

ときに意見は真っ向から対立し、ときに沈黙が場を支配します。しかし最も避けたいのは、「声の大きい者の意見だけが採用される」状態です。そのような合意は、あとから実装や運用の局面で破綻します。

だからこそ、私はこう考えています。

要件定義とは、“小さな民主主義”の設計なのだと。

学び：熟議というインフラをどう設計するか

民主主義とは、多数決によって勝敗を決める仕組みではなく、異なる意見を出し合い、それぞれの立場を理解し合いながら、新しい視点を探る営みです。 そして、それは技術の現場においても本質的に同じ営みです。

要件定義において必要なのは、「言った」「言わなかった」ではなく、なぜその意見が出てくるのかを辿る態度です。 その意見は、どの立場のどんな背景から来ているのか。 それを理解し、別の立場の誰かにも伝わるように翻訳する。その連鎖によって、合意は少しずつ形を成していきます。

民主主義を語るなら、遠い政治ではなく、まずは自分の職場から。 私たちが向き合ってきた、あの四者会議の場から。そこにもう一歩、「問い直す余白」を仕込むこと。

それが、技術にも社会にも通じる設計なのかもしれません。

📚 関連書籍（もっと考えてみたい人へ）

• 『熟慮と討議の民主主義理論』（ミネルヴァ書房）
  日本の制度に即して、熟議とは何かを整理した一冊。

• 『世界に学ぶミニ・パブリックス』（学芸出版社）
  実際にどんな条件で「うまく話し合いが機能するか」の比較研究。

民主主義＝設計対象だとするなら、そこにもちゃんと理論とノウハウがあります。
要件定義などの書籍の合間に、こんな本も悪くないかと思います。