多数派意見にすがるヘタレが引き起こすバックラッシュっつか炎上に対抗する ― 2007年01月10日 11時34分27秒
前者はケーススタディ、後者はシステムによってある程度防衛できるし、するべきでは、という提案のお話。
救世主的な頭のいい発言が状況を塗り替えることはあるかも。
まず前者について。問いかけに対するおいらの回答は、場合によって可能か不可能かは変わるだろうし、その難易度も変わるだろうし、それができる人もいればできない人もいるだろうという曖昧なもの。例に挙げられていたゲド戦記のケースは、おいら的にはそれほど難しいケースでもないと思う。実際、それなりに大手のサイトでいまいち擁護になってないけどそれなりに肯定的な意見を述べる記事も書かれているし。いや、これ、作品そのものを評価する声じゃないだろう、って突っ込みもありそうだけど、二者択一で論争になって少数派意見で防衛戦を強いられるようなケースでは結構重要な切り口だと思う。よーするに、状況を観察した上で「○○だから仕方がない」 (今回のケースだと「吾朗ちゃんだから仕方がない) 的な譲歩と、「多くの××な人たちが色眼鏡で見ているんでは」 (リンク先記事中でもリストアップされているアレです) 的な勢力批判が、一方的な意見を喰い止める力となりうる場合もあるってこと。
逆に、8月の亀田×ランダエタ戦に対する一方的な評価を喰い止めるのは難しいようにも思う。何より各社マスコミが先だって煽ったという経緯も去ることならが、「仕方ない」で割り切れるような要素も見当たらないし、「色眼鏡で…」と言おうにも、むしろ色眼鏡で見てたのは審判員なんじゃねーの? って感じだったし。何より「いつもどおりの KO 劇」を期待して観に行ったと言う多くのファンであるはずの観客達のほとんどがリポーターの質問に対して「つまんない試合だった」「煮え切らない試合だった」と口をそろえて吐き捨てる映像がワイドショーに流されては、ボクシングなんて全然わかんないじーさんばーさんお孫さんもさすがに「感動した!亀田選手これからも応援してま~す♥」とは言いにくいだろうみたいな。
ただそれでも、ダウンをとっても 2 ポイントの差にしかならない (だっけ) ことや、亀田選手による積極的な攻撃手数が評価された可能性など、「判定勝ちの根拠」についてはある程度説明的な論議も交わされていて (参考)、「納得はいかないけど判定基準としては間違ってはいないのかも」とか、「亀田×ランダエタ戦だけがレアケースってワケではなくて、ボクシング界全体において潜在的に取り沙汰されるべき問題点なのでは?」といったような中立的な意見が成り立つような素地は残っていたように思う。
どっちにしろ、議論が成熟するまでにはどうしても時間がかかるってのはあるし、そういっている間にも、不当な炎上の被害にあうブログユーザーは今日もどこかで悲鳴を上げていらっさるワケで (多分)、そうした問題に対して上記のようなことが関係していること、そして上記でおいらが書いたようなことが、この問題に対して、多くの場合、何の解決にもならないであろうことは確かだと思う (だったら書くなよw)。
炎上をシステム的に予防する
↑なにげに五・七・五w
で、後者の話題になるわけですが、本音を言えば、コメント欄へのカキコミに対しては、一切の制限を加えたくなかったりする。何故なら、それが有意義な議論をも抑制してしまう可能性も、ないとは思えないからだ。特にうちみたいな弱小ブログサイトの場合、これとかこれとかみたいな有意義な議論はありえなかったかもしれない (特に、「通りすがり」さんからのツッコミにも有益なものはいくつかあったが、これが書き込まれなくなってしまう可能性は極めて高くなる)。もちろん、いいとこ取りというわけにもなかなか行かないだろうから、サイトの成長に応じ、盛況具合に応じてルールを変えていくようにすればいいのだろうとは思うけれども、その為には、その (システム的な) ルールをブログユーザーが選択できるようになっていることが一番の必須要件になってくるんじゃないかと、おいらは思う。
つまり、リンク先記事にあったような提案は、それぞれ一定の効用はあるとは思うけれども、例えば Windows Live Spaces のブログみたいな、登録ユーザー (この場合だと Microsoft Passport 会員) 以外の人間にコメント欄を開放することができないようなシステムではマズいと思う (あそこはトラックバック受付すら開放されていなかったように思う。つくづく深刻)。必要なのは囲い込むことではなくて、あくまで段階を設けること。土足で上がりこむ客がやたらと増えて五月蝿くなってきたから、敷居を設けて座敷の席や個室を用意し、「靴を脱いでお上がりください」とすることでワンクッション置く、ということ。始めっから靴を脱いでる客だけを相手に商売したって、そういう客が増えてきちゃったら結局は状況は変わらない。今、mixi で何が起こっているのか、その状況を正視すれば、おいらの言いたいことも分かってくれるんじゃないかと思う。
2ちゃんねるやはてなブックマークが、より下層の客のいい受け皿になっている可能性も指摘しておこうと思う。ブログのコメント欄に直接書き込むのが億劫な人が、この辺のシステムを利用していると言うケースも少なくないように思う。逆にいえば陰口 (だと書いてる当人だけが思っているような行為←記録が残る以上いつかは本人にも見られちゃうわけだが) の為の格好のプラットフォームになっていると言うことも出来るわけで、賛否両論ではあると思うが。
提案されている機能に関するコメント
- 登録ユーザーのみ許可する機能
たとえばはてなならはてなユーザーのみが書き込み可能としてしまうこと。突発的な炎上への対策としては確かに有効だと思う。但しはてなみたいにブログ以外のサービスもやっていて、とりあえずアカウントを取るだけなら無料、というサイトだと、捨てハンドルユーザーが増えて炎上が起こりうる素地が醸成されていってしまう可能性はあると思う。恒久的な対策としては弱いかもしれない。
ブログユーザーごとに、登録ユーザーを設定できるような機能があれば確実なんだけどね。コメントを書き込みたいユーザーが、まずブログ主にその意思を何らかの方法で伝える。で、ブログ主が許可をおろすと、そのユーザーが登録されて、書き込みが可能になる。もしもそのユーザーがコメント欄を荒らすようなことがあったら、ブログ主が自身の判断で登録抹消できる。みたいな。
判別方法はパスワード認証でもいいし、IP とかでもいいと思う。メールアドレスを登録させてしっぽを掴むような形を取れば更に敷居は高くなる。
- コメント承認機能
これはブログを外から見る人にしてみれば炎上は起こっていなさそうに見えるかもしれないけど、突撃隊が 2ちゃんねるとかで基地を作っている場合、ブログ主は発火したコメントの嵐の処理に追われることになるわけで、特に炎上がブログ主に与える精神的打撃っていう側面を見るにつけ、あんまり解決になっていないような気がする。もちろん、電凸基地が存在しないようなケースであれば、火事場の野次馬は発生しなくなるわけで、その場合には炎上の可能性は確かに低く抑えられるが。
とにかく、書き込まれたコメントをブログ主がいちいちチェックして承認、ってのは、個人的にはめんどくさくて取り入れたくないソリューションだなぁとか思ってしまう。
追加提案をいくつか。
一つは既に書いちゃいましたが、
- ブログ主によるコメント書き込みユーザー登録制システム
ブログ主に申請して登録してもらう方式。ユーザー登録申請をブログ主が処理しなきゃならなくなるので面倒くさいと言うのはあるが (即時登録にしてしまうという手もあるが、そのかわり敷居は低くなる←つか、captcha とかと併用しないとスクリプトで大量登録されちゃうかも)、コメントの書き手をブログ主が管理できるという利点はある。
mixi のコミュニティに近い、のかしら? (知らんけど)
- IP 開示機能、もしくはコメント主 ID 表示機能
これは炎上に対して真っ向戦う意思のあるブログ主向け。あるいは炎上ではなくて吹聴を試みる匿名の粘着を対処する機能としても有効。よーするに、多数派意見と思われていた書き込みが、一人無いし数名の人間による連続書き込みであることを証明してしまえば、議論の方向性をひっくり返してしまう可能性もあるよという提案。その為には、最初っから IP を開示してしまうんではなくて、ここぞというときに、開示したい IP だけを開示してしまう「後の先トラップ方式」の方がより攻撃的だと思う。IP ではなくてホスト名を表示して、それが特定の企業のホスト名だったりした日にゃあ…w
もちろん、ばれれば proxy で回避されちゃう危険性もあるわけですが。つか、多くの炎上するケースに対する対処にはなーんもなっとらんがなw
- 同一 IP からの連続書き込みを制限する
実際、スラッシュドットジャパンは Anonymous Coward による同一 IP からの書き込みを 30 分よりも短い間隔ではできないように制限し、一定の成果を上げている。登録ユーザーは制限しない、などの段階を設けるのも有効かもしれない。
ブログ主のスタンスに応じた対策を
炎上を被害だと見てしまう人もいれば、良くも悪くも反響であると行為的に見る人もいる。炎上に怯えたくない、とか、炎上への対処は面倒くさい、などと考える人もいれば、炎上してしまった中からであっても、有益なコメントは吸い上げたい、と考える人もいる。おいらの提案のうちのいくつかは、後者のようなタイプの人向けの提案でもあったりする。様々なニーズがあるので、それらのニーズに応じた選択が用意されるのが、もっとも望ましいのではないかと思う。
まぁ、あんまりカスタマイズが自由すぎても、使うほうは戸惑っちゃうだけかもしれないけどね。
注釈ポップアッププラグインのテスト ― 2007年01月10日 19時18分27秒
動くかにゃ?動いたにゃ!!
注釈ポップアッププラグインを作ってみますた。 ― 2007年01月10日 20時15分02秒
こんな感じで動作します
ここをクリックしてみませう。
こんな感じで、その場で注釈を表示できます。
注釈を閉じるには、この注釈をクリックします。
使い方
- annopop.js ファイルをダウンロードし、あなたが管理する Web スペースに upload する。アップロードした annopop.js ファイルの URI をメモしておくこと。
- 注釈ポップアッププラグインを使用したいページのどこかに、以下の HTML を追加してください。
<script type="text/javascript" src="(1.でメモしたURI)"></script>
<head>
要素の中で記述するのがベストですが、基本的にはどこでも構いません。ブログなどであれば、フリースタイルのブログ部品として記述しても ok です (このブログではそうしてます)。なお、本ブログのように、本文テキストが固定幅でレイアウトされているような場合、annopop_view_rect
変数のプロパティを変更することによって、注釈の窓が表示される領域を制限することができます。その場合は、以下のような記述を更に書き加えてあげてください (HTML 4.01 の場合)。<script type="text/javascript"><!-- annopop_view_rect.left = 0; annopop_view_rect.right = 560; //--></script>
もちろん、XHTML の場合はコメントタグ<!--
~-->
の代わりに、<![CDATA[
~]]>
を使うようにしましょう。 - 実際に注釈を挿入するには、以下のように記述します。
<a href="javascript: void(0);" id="annopop-(任意のID名)">注釈を入れたいテキスト</a> <span id="(任意のID名)">注釈の内容</span>
- 注釈を入れたいテキストは、アンカータグ
<a>
で挟みます。href
属性には必ず
javascript: void(0);
と記述し、クリックしてもどっかのページに飛んでいかないようにしておきます。そして、id
属性には、任意の ID 名に接頭子annopop-
を付けた名前を記述します。 - 注釈の内容を挟むタグは何でも ok です (実際、このページの最初に示した例では
<div>
タグを使っています)。id
属性には、a. で指定した任意の ID 名 (接頭子annopop-
を取り除いた名前) を記述します。
- 注釈を入れたいテキストは、アンカータグ
注意事項
http://daiyokujo.harapeko.jp/annopop/annopop.js
を直接リンクするのは、なるべく避けてください。まさかとは思いますが、サーバーに負担がかかる可能性がありますので。なお、この URL は予告無く変更または削除する場合があります。<body>
要素のOnLoad
属性に何か書いている場合、動作がおかしくなるかもしれません。window.onload
に何か別のハンドラを設定している場合、既に登録済みのハンドラも合わせて実行するようにしてありますが、本プラグインが先に実行された場合にはこの限りではありません。つか、それ以前にその辺の動作は未テストです (^_^; 。- Internet Explorer 6.0 では、
position: fixed;
が使えない為、表示がイマイチです (これは今後何らかの形で修正するかも)。 - Internet Explorer 7.0 では (6.0 もかな?)、
line-height
スタイルに十分な余裕がない場合、アンカーの下線が表示されないかもしれません (アンカーのスタイルは annopop.js ファイル内にて設定しています。ソースの冒頭に出てくる変数設定がそれです。状況やお好みに合わせて適宜カスタマイズしてください)。
メモ
Javascript のクロージャに関して、こちらのサイトの記事が参考になりますた。
annopop_view_rect
変数を追加しました。説明も追記しておきますた。
ちょくちょく修正加えてます。annopop.js
ファイルの冒頭のコメント部分にバージョン番号 (vX.Y.Z
みたいなやつ) を入れました。最新のものかどうかご確認願います。現在 v1.0.1
です。
v1.0.2
- 重複読み込みされても安全に動作するように修正しました。
annopop_view_rect.left
に 0 以外の値を指定しても、ウィンドウの左端が基準になってしまうバグを修正しました。
アクセシビリティに配慮した v2.0 をリリースしますた。
C10K問題 ― 2007年01月10日 23時40分15秒
- Web2.0の先にあるC10K問題 (@IT)
Ajax で Comet やるとプロセス ID が足りなくなったりするよ、というお話。サクラインターネットみたいな共有連鯖サービスなんかだったりすると個人サイトレベルでも頻発することになるかもね。Cometd でもいいけど、なんかうまい回避方法ってないのかしら。。。?
最近のコメント