『多数決を疑う—社会的選択理論とは何か』を読んだ

多数決を疑う――社会的選択理論とは何か (岩波新書)を読みました。議員選挙などのたびに、多数決よりましな方法があるんじゃなかろうかと漠然と思っていたのですが、それについて追究する学問分野が「社会的選択理論」と呼ばれていることすら知らなかったので、大いに蒙を啓かれることとなりました。

本書の内容は既に公にされている書評(毎日新聞読売新聞など)などにお任せします。検索すればほかにもたくさん見つかります。一方で、きっと本書そのものを読まないままにタイトルだけから「民主主義を否定するのかよ」といった短絡的な批判(?)も見つかります。それほど「民主主義イコール多数決」と思い込んでいる者が多いのでしょう。もちろんそうではありません。意見集約の「方法」についての話なのです。

多数決のもとで有権者は、自分の判断のうちごく一部に過ぎない「どの候補者を一番に支持するか」しか表明できない。(略)だから勝つのは「一番」を最も多く集めた候補者である。(略)

多数決の選挙で勝つためには、どの有権者をも取りこぼさないよう細かく配慮するのは不利というわけだ。とにかく一定数の有権者に一番に支持してもらい、(略)

だがこれは政治家や有権者が悪いのではなく、多数決が悪いのではないだろうか。しかし多数決を採用しているのは人間である。多数決を自明視する固定観念が強い。(本書「はじめに」)

本来であれば社会全体をよくするという政策が出てきてそれが支持されそうなところ、現行の「方法」が多数決であることによって、候補者が勝ちにいくために政策・選挙戦術が歪められ、有権者の行動もまたそれに依存する……。何か本末転倒と思わざるを得ません。

多数決ほど、その機能を疑われないまま社会で使われ、しかも結果が重大な影響を及ぼす仕組みは、他にはなかなかない。とりわ議員や首長や議員を選出する選挙で多数決を使うのは、乱暴というより無謀ではなかろうか。(本書「おわりに」)

多数決の最大の(たぶん唯一の)利点は、「単純でわかりやすい」ということだろうと思います。本書で紹介されるボルダルールやコンドルセ式は集計(開票作業)がどうしても煩雑になります。しかしそれは人間の手作業による場合であって、もし電子投票が実施されるようになればまったく問題はありません。電子投票の問題はたぶん信頼性や投票の秘密の確保とかにあるのでしょうが、いずれその方向にいくでしょう。200年ほども前から提案されている方法に、ようやく技術が追いついてきたと言えます。それに合わせて集約方法も“進化”してもいいのではないでしょうか。

ともかく、多数決よりましな方法が存在します。議員選挙のような簡単には動かしにくい制度よりもっと身近なところ—町内会とかサークルとか学校の生徒会とか—からそういったものが普及していってもらいたいものです。

ボルダルール

さて本書では多数決の代替案がいくつか検討された後、その中でも「ボルダルール」が推されています。その理由として

  1. ペア敗者規準とペア勝者弱規準を満たす
  2. さらに棄権防止性を満たす

が挙げられています。さらに「コンドルセ・ヤングの最尤法は統計学的に定義されるゆえ有権者には理解が難しく、広く受け入れられるとは想像しがたい。であればボルダルールのほうが世に導入しやすいだろう。」と述べています。

しかし、これらについて私は素直に首肯できませんでした。

まず(2)についてです。ここで「棄権防止性」とは、有権者があえて棄権することで結果を自分に有利に変えることができない、という意味で説明され、コンドルセ・ヤングの最尤法ではこれを満たさないとのことです。

ボルダルールでは、候補のすべてに順位を付けて投票しなければなりません。ではたとえば最近の都知事選挙を考えてみます。これだけ候補が多いと、大部分の有権者は、もっとも好ましい候補からせいぜい3人ほどと、この人には絶対なってほしくないという候補の2,3人ほどが頭に浮かぶ程度ではないでしょうか。何がなんでもすべての候補を一列に並べなければならない、とすると有権者への負担はとても大きくなり、そんなことならいっそ棄権してしまおうかという気持ちにもなってしまいそうです。棄権で結果を自分の有利にできないから棄権する動機がないという意味の「棄権防止性」はあるのかもしれませんが、「めんどくささ」からの棄権を多く誘発しそうです。もしすべての候補にではなくて「いくつかだけに順位をつければよい」というルールにすると、それはボルダではない「スコアリングルール」になってしまい、(1)を満たさなくなってしまいます。この「めんどくささ」、つまり有権者の高負担というボルダルールの不利な点をどのように克服できるのか、そこまで本書で説明されていればよかったのにと思いました。

シュルツ方式

本書には出てきませんがコンドルセの一種として「シュルツ方式」というものがあります[1]

Wikipedia のページをざっと読んでみたところ、シュルツ方式の投票は、ボルダルールのように候補に順位を付けますが、

  • 複数の候補者に同じ番号を付けてもよい
  • 連続しない番号をつけてもよい。番号の絶対値は重要ではなく、順序のみに着目する
  • いくつかの候補に順位を付けなくてもよい。その場合、順位付けしていない候補を最下位(順位付けしていない候補どうしは同列)とみなす

というものです。コンドルセ式のためペア勝者規準をも満たすようですし、また全部の候補を順位付けせずに部分だけでもよい、とありますから、上に挙げた私のボルダルールに対する疑念も克服されているようです。簡単な比較の日本語記事が『「多数決」以上に民意を反映できる選挙方法とはどのようなものなのか?』にありました(本書の出版より前の記事です)。

Debian Project採決にこの方式を採用しているということを、実は以前から知っていました。しかしこれが多数決などとどのような関係にあるか、考えたことはなかったのです。今回、『多数決を疑う』を読み、あらためて見てみました。英語ですが The Debian Voting System は、Debian での方法に限らず一般的なコンドルセやシュルツの説明としてわかりやすいです。

そこにあるように、Debian 方式は

  • 選択肢に「更に議論する」を追加する
  • デフォルトはこの「更に議論する」とする

という拡張がなされています。一般の投票なら「他に選択肢がない」や「どちらともいえない」などを読み替えることができるでしょう。つまりデフォルト選択肢より上の順位にすれば「好ましい」、下の順位は「好ましくない。嫌だ」という意思表示になります。これはたいへん合理的なルールだと思えます。

この拡張の優れた点は、ただの賛否を問う採決でも(選択肢が「賛成」「反対」の2つしかなければボルダルールも何もただの多数決になってしまう)、選択肢が「賛成」「反対」「更に議論する」の3つになり、コンドルセ式などを適用できることです。もっともこれを「迅速に決定できない」という欠点だとみなすこともできますが、私は、拙速よりははるかにましだと考えます。

多数決を疑う――社会的選択理論とは何か (岩波新書)……と、実は本書を読んだのは数か月前なのですが、何しろ専門でも何でもないので、調べたり考えたりしながらこの辺まで書くのにうんと手間取ってしまいました。このままではいつまでたっても書き上がらないので、ひどく中途半端ですがもうここでこの記事を公開してしまうことにします。

ついでに、私の抱いているもうひとつの疑問も書いておきます。

私の住む市の今年春の市議会議員選挙では、立候補者数は定数をわずかに超えるだけでした。つまり30人ほどが当選し、ほんの3,4人しか落選しません。最適の候補をたったひとつ選ぶ場合にはコンドルセ式やボルダルールが使えそうですが、このような場合にも適用できるのでしょうか。本書からだけではよくわかりませんでした。たとえば「投票方式はこれで決まり?」で言及されている方法などは有用そうなのですが、それと他の方式との比較などが自力ではよくわからない……。

様々なケースにも適用できるベストな方法はどうやらなさそうだ、という感じはうすうすしているのですが、それでも本書で言うように「コンドルセ式よりもボルダルールが優れている」とは思えませんでした。さらにもっと別の方式も同じ土俵に上げて、上述した疑問にも私のような素人にもわかりやすく答えてくれる、続編に相当するものが現れないかなと思っているところです。

  1. WikiPediaの解説はとても参考になりますが日本語版の「シュルツ方式」は翻訳が変なところも多い(2015年9月現在。そう思っているなら直せよと言われそうですが、時間があれば少しづつそうしていきたいと思います。しかし私のような素人よりもっと専門知識のある人たちにやってほしい……)ので、それを参照しながら英語版 Schulze method を見たほうがよさそうです。

Debian 8 の Mailman 2.1.18 に更新したらトラブルが起きた

メーリングリスト(ML)を運用しているサーバー の OS を Debian 7 (Wheezy) から Debian 8 (Jessie) に更新しました。これにより、ML 管理ソフト Mailman のバージョンが 2.1.15 から 2.1.18 になりました。

すると ML の配信に失敗する(ML に宛ててメールを出してもどこにも配信されない。エラーも返ってこない)状態になってしまいました。OS のバージョンアップだったので、関係するソフトウェアの多くが更新されており(たとえば Bind9, Postfix, Python,…)、しばらくどこが原因かわからず途方に暮れていましたが、ようやくエラーログを見つけ出し、それを検索して調べることで解決できました。

結局のところ、この人と同じで、MLの説明などを日本語(EUC-JP)で記述していた箇所を Web の管理画面から書き直すことで、何のことはなく問題は解消しました。

こういうのはだいたい解決してしまった後に見つけるものですが、/usr/share/doc/mailman/NEWS.Debian.gz に、

mailman (1:2.1.16-1exp1) experimental; urgency=low

  This version has changed the encoding of most strings, templates
  and pages to UTF-8 to meet the Debian release goal of full UTF-8
  support in all packages. It also no longer automatically converts
  mails to ISO-8859-1.

  If you have been using any nōn-ASCII strings in places such as
  the mailing list description, these were be stored wrongly in the
  list configuration file (config.pck), so you will need to change
  those (e.g. via the webinterface) again in order to have them be
  displayed correctly.

と書いてありました。

さてメールは配信されるようになったものの、ヘッダーに DKIM-Signature: が残っていて、設定ファイル /etc/mailman/mm_cfg.py に記述していた REMOVE_DKIM_HEADERS が効いていないようです。以前はちゃんと機能していました。

これまた検索してみると、オプション from_is_list と組み合わせないと効かないようで、それと無関係に効かせようとしてもバグがあるようです。上流の新しい版では修正されているので、Mailman/Handlers/CleanseDKIM.py を差し替えました。

その上で、設定ファイルで REMOVE_DKIM_HEADERS = 2 としました。

リモートに置いてある音楽ファイルをローカルPCのスピーカーで鳴らす

以前に「インターネットラジオを FM ラジオで聴く」というのを書きました。少し離れた場所にあるマシンにFMトランスミッターを付け、目の前のPCから操作する(そしてFMラジオで聴く)というものでした。

それから月日は流れ、ハードウェアを入れ換えたり、その際にOSもすっかりインストールし直したりしているうちに、そのリモートのマシンでの音声出力ができない状態になってしまいました。

そこで前回とは逆に「リモートに置いてある音楽ファイルをローカルPCのスピーカーで鳴らす」というのが、今回やりたいことです。目新しいことは何もなく、既に情報がどこかにあったので楽でした。自分のためのメモも兼ねてここに書いておきます。

先にまとめておくと、

  • リモート
    • 音楽ファイルが置いてある
    • Pulseaudio
    • MPD
  • ローカル
    • スピーカーが接続されている
    • Pulseaudio
    • gmpc

という構成になります。

Pulseaudio

ここではリモートもローカルも OS は Debian (これを書いている時点での安定版)です。

まず、ローカルで

sudo apt-get install pulseaudio
と pulseaudio をインストールし、

paplay local-sample.ogg

などとやってちゃんと動いていることを確認します。ところがここで音が出ませんでした。

sudo apt-get install pavucontrol

とやって pavucontrol で、「出力装置」を見ると、ポートが「HDMI」になっていました。ここの環境ではそこにスピーカーはなく、USBポートにサウンドアダプタを挿してその先にスピーカーがある状態です。「設定」で、GF108 High Difinition Audio Controller が HDMI になっているので、これを Off にすると、「出力装置」のポートが「スピーカー」または「デジタル出力(S/PDIF)」になって、音が出るようになりました。

リモートとローカルの Pulseaudio の設定

ローカルの /etc/pulse/default.pa で、

load-module module-native-protocol-tcp auth-ip-acl=192.168.1.0/24

リモートの /etc/pulse/client.conf で、

default-server = 192.168.1.xxx (スピーカーのあるPC)

とします。必要に応じてローカルのポート 4713 を開けます(今回のローカルPCはファイアーウォールを置いていないので特に設定の必要なし)。

テストとして、リモートで

paplay remote-sample.ogg

などとやるとローカルのスピーカーが鳴ります。

MPD

当初の目的は達成されましたが、このままでは不便なので、MPD を使うことにします。これは音楽再生やプレイリスト管理をリモートから行うためのものです。

リモート

まず

sudo apt-get install mpd

でインストールします。/etc/mpd.conf で、music_directory に音楽ファイルの置いてあるディレクトリを設定し、bind_to_address に接続を許すアドレス(今回は(LAN内の)どこからでも接続できるよう “any” としました)を設定します。

出力先の設定は

audio_output {
        type            "pulse"
        name            "My Pulse Output"
#       server          "remote_server"         # optional
#       sink            "remote_server_sink"    # optional
}

とします。ここで mpd を再起動します。

ローカル

ローカルPCには、gmpc をインストールして使います。これは高機能で、細かな設定やプレイリストの管理を行うことができます。ふだんは、再生/ポーズ/停止くらいの操作しか必要ではないので、シンプルな xfce4-mpc-plugin をパネルに置いてこれを使うことにします。

sudo apt-get install gmpc xfce4-mpc-plugin

どちらも、ホストとして MPD を動かしているリモートのマシンを指すように設定します。

KVM に Kernel Samepage Merging (KSM)

いわゆる自宅サーバーの機器を更新し、これを機にソフトも KVM の上に載せてみることにしました。

用途と向きによって仮想サーバーを切り分けます。ホストも複数のゲストも、ぜんぶ Debian で同じバージョンです。ネットの検索によって得た知識でも何とかなります。

当初気づかずに、後から「こういうのがあるのか」と気づいたのが、KSM (Kernel Samepage Merging) でした(解説はたとえば Linux カーネル共有メモリーの徹底調査)。

KVM on Debian Squeeze – My Notes を参考に設定しました。

ホストとゲストの両方で /etc/rc.local を編集し、次を追加します。

echo 1 > /sys/kernel/mm/ksm/run
echo 300 > /sys/kernel/mm/ksm/sleep_millisecs

再起動後、/sys/kernel/mm/KSM/pages_sharing がゼロより大きな値になっていれば、有効になっています。

KSM は使わないほうがいい?

さて、はじめ気づかなかった KSM についての情報に行き当たったのは、とりあえずしばらく動かしていると、ゲストOSが徐々にメモリを食いつぶしていくという現象をどうにかしたいと思って調べてみたからです。 そこで上記のように KSM を有効にしてみたのですが、引き続き検索していると、「KVMで複数VMを起動してVM間の相互作用を減らしたいときに考えること 」という記事を見つけました。
  • メモリはオーバーコミットしない
    • メモリをオーバーコミットするとろくなことがありません。なので要るだけ積みあげます。安いし。
      • 特にゲストOSがlinuxの場合、メモリはあるだけ使おうとする。本来だとキャッシュとしての有効活用になるキャッシュを積極的に使う戦略が、メモリオーバーコミット環境下ではswapを多発させる原因になってしまう

うーむ。これが原因かもしれません。個々のゲストはさほど深刻な負荷があるわけではなし、一方が急に働くことになっても他方はそれほどでもないことがほとんどなので、個々のゲストのメモリ割り当てを、ほぼ実メモリと同じくらい、としていました。すなわち、ゲストに割り当てたメモリを合計すると実メモリの数倍になっていました。しかし、この記述によると

    • メモリは足りてるはずなのでKSMは停止する

確かに KSM はホストに負荷がかかるので、動かさずに済むならそのほうがいいかもしれません。

もうしばらく様子を見ながら(まだ理解できていないことも多いし)、考えたいと思います。

Debian Jessie での git-completion.bash のある場所

git の状態に応じて bash のプロンプトを変更するようにしていたつもりが、ふと気がつくと、Debian の バージョン Jessie (2103年9月現在では testing) の環境では、機能していない。

何しろしょっちゅう使っている訳でもないので、久しぶりだといろいろと状況が変わっていて、以前うまくいっていたものがそうでなくなっていることがある。

Debian Wheezy 以前なら /etc/bash_completion.d/git があったのだが、Debian Jessie の環境ではそのディレクトリを見ると、git はなくなっており、代わりに git-prompt というのになっている。

どういう訳でなくなったのだろう、と検索しているうちに、git: /etc/bash_completion.d/git gone という情報を見つけた。/usr/share/doc/git/NEWS.Debian.gz に説明があり、要は、以前の /etc/bash_completion.d/git/usr/share/bash-completion/completions/git に移動したので、自分の .bashrc でこれを読み込むようにしている場合は変更せよ、ということだった。

どうしよう日本語入力システム (その2)

昔の話をするようになったら歳をとった証拠だ。が、いきがかり上、しばらく昔の話を書いてみよう。

日本語入力システム自分史

UNIX 期

Wnn を使い始めたのは学生だった 1991年頃だ。その前には NEC の PC98 で少しのあいだ ATOK を使っていた。確か「一太郎 Ver.3」だったから、いま調べてみると ATOK6 か ATOK7 だったことになる。

そこに Sun SPARCstation 2 というワークステーションが研究室にやってきて、X Window system で日本語を入力するのに Wnn を使い始めた。確か X11R4 や R5 だったので、これもいま調べてみると、それらに標準添付されていた Wnn 4.1 や Wnn 4.2 を使っていたことになる。その頃にあった別の日本語入力システムの Canna や Sj3 は使ったというより試してみた程度だった。

その後使った HP のワークステーションの HP-UX に VJE だか ATOK だかが付属していたと思うが、このワークステーションはほとんどリモートで使っていたので、日本語入力システムに触れることは滅多になかった (もう当時のバージョンがいくつだかも忘れてしまった)。

Wnn 4.2 の頃はいろいろと情報が出回っていて、辞書を追加したりパラメータを調整することで、標準の状態よりかなり変換精度を上げることができた。

世間で Windows 3.1 や Windows 95 が大流行している頃、私は Sun SPARCclassic を独占してデスクトップで使えるという環境にあったため、その時期を Windows と無縁で過ごした。その後ノート型を含め、いわゆる PC/AT 互換機も使うようになった頃には既に Linux が入手できたため、そこでも Windows を使わずにすんだ。そんな職場を離れたあとも今日に至るまで、トータルで 20 年以上もコンピュータを毎日使っていながら Windows も Mac も常用したことがないという、たぶんかなり珍しい部類の人となった。

Linux-Wnn 期

1997 年、Wnn 6 for Linux/BSD が発売されるとすぐに購入した。UNIX 版はその前に出ていたが普通に買える価格ではなかったし、その頃には Sun SPARCclassic は既にサーバーとして裏にまわり、Debian をインストールした PC をデスクトップで使っていた。

Wnn 6 は、それまでのバージョンがフリーソフトだったのに対し、商用ソフトであった。「Wnnについての基礎知識」のページの中ほど、「*Wnn6 で強化された機能とは」の項にあるように、20万語のシステム辞書、「フレキシブル・インテリジェンス(Flexible Intelligence)機能」により、変換精度は格段によくなった。

2001年、Wnn 7 for Linux/BSD が発売になり、これもすぐに購入した。

ATOK 期

2005年に Wnn 8 が発売になった際には、Wnn 7 で十分満足していたので購入を見送った。UTF-8 への対応というのが大きな変化だったが、その頃はまだ EUC-JP で使い続けていたので、その必要性も感じなかったのだ。その後 2009年に、別の会社から、その時点の ubuntu に対応したという Wnn8 for ubuntu というものが発売されたが、ほぼ1年で販売を止めてしまったようだ。

これらを購入しなかったことを後悔する時がやってきた。2010年頃には、(1) OS のライブラリが新しくなり、依存関係を改変しないとインストールもできなくなってきた。いつか本当に起動しなくなるかもしれない。(2) 最近は UTF-8 でしか動かないアプリケーションがいくつか出てきたが、Wnn 7 (xwnmo) は locale を EUC-JP にしなければならないため、日本語を入力できない。(3) 開発元の情報を見ても、この先、新しいバージョンが出る気配がない。という状況になってしまった。

OSS の Anthy を試してみたものの、あまりの使い勝手の悪さに 1週間ほどで嫌になってしまった。

そこで思い切って ATOK X3 を購入することにした。ATOK X3 は 2007年の製品で、既に時代遅れぎみだが、こちらも次がいつ出るのか(そもそも次はあるのか)見えないので、思い切ることにした。

ATOK X3 が悪いとは言わないが、何しろこちらが Wnn に慣れきっているため、不満に思ってしまう点はいくつかあった。

変換精度が思ったほど高くないと感じるのは、長いあいだ学習させてきた Wnn7 と比較しているからだろうか。それを割り引いても 2001年の製品である Wnn7 のほうが「賢い」ように感じられた。

それに、異体字(いわゆる旧字)を簡単に出せない。Windows 用の新しい ATOK には異体字変換があるようだが、Linux 版 の ATOK X3 にはその機能がない。Wnn7 には標準で「異形字変換辞書」を持っており、いったん仮名から漢字に変換したあと(たとえば「けいざい」→「経済」)、漢字から異形字(「経」→「經」、「済」→「濟」)に変換する、単漢字変換の一種ともいえる機能があった。とりあえず「正字正假名辭書」を追加してしのぐことにしたが、これは単語レベルの辞書なので、登録されていない単語(人名など)で旧字を出したいときにはやはり苦労する。

発売直後から指摘されている不具合が未だ放置されているなど、開発元のやる気のなさも心配だったのだが、前の記事にも書いたように、たった1年ほどで終わりの時が近づいてきたようだ。


結局、20年ほどの日本語入力システム自分史を振り返ってみると、最近1年の ATOK X3 を除いて、なんと19年が Wnn (そのうち10年ほどが Wnn7) というものであった。

この項さらに続く(たぶん)。

どうしよう日本語入力システム (その1)

Debian sid (i386) で、libgtk2.0-0 を 2.24.5-4 にアップデートしたら日本語入力システム ATOK X3 が使えなくなってしまった。2.24.4-3 に戻せば使える。そのあいだのバージョンではどうだかわからないが、いずれにせよ、ほかのアプリケーションとの兼ね合いで libgtk をそのままにしておくわけにもいかないだろうから、ごまかしておけるのも時間の問題だ。

そもそも、それまでずっと使っていた日本語入力システム Wnn7 が、やはりライブラリ (や、日本語文字コード) の問題でうまく動かせなくなり、その代わりにしかたなく ATOK X3 を使い始めたのだった。今度もまた本質的ではないと思われるライブラリの問題で使えなくなるとは非常に残念である。このへんが頻繁にバージョンアップのあるオープンソースと、どうしても対応が緩慢 (この場合、緩慢どころかもう停止してるのだろう) になる商用ソフトの相性の悪いところだ。

選択肢がない

日本語を使う者にとって日本語入力システムは必要不可欠だ。ハードウェアがどうとか OS が何であるかよりもっと人間よりのところにあると言ってもいい。キーボードのHappy Hacking Keyboard のページに、

アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。

いまやパソコンは消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。

[東京大学 和田英一 名誉教授の談話]

という言葉が掲げられているが、この「キーボード」を「日本語入力システム」に置き換えても何ら違和感はない。

それにもかかわらず、Windows 環境下ですら現在では選択の幅がほとんどない。その原因は Windows にバンドルされている MS-IME の寡占につきると思う。しばらく前の Web ブラウザ Internet Explorer 寡占問題と同じだ。このときヨーロッパは 「WindowsとIEの抱き合わせは競争法違反」と異議声明を出した。日本でも MS-IME に対して異議を申し立てるべきだったのだ。それまで多くの日本語入力システムがあって切磋琢磨していたものが、ほとんど姿を消してしまった。

OS のシェアから考えて、Linux 版のみの商用日本語入力システムが開発されるわけもなく、Windows 市場で稼げなければ Linux 版は存在し得ない(もちろん MS-IME の Linux 版が出るわけもないし)。こうして Wnn も Linux 版の ATOK も消えていきつつあるのが現状だ。


長くなってきたので、この項つづく