Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 1/241: 1 2 3 4 5 6 7 8 9 »

ネットの(技術)情報の思わぬ島宇宙化から、知的に真摯に生きる事や、そのように生きやすくする手助けの事を考えた - Nov 13, 2018

自分にとって非常に興味深く感じる事例に遭遇したので、Twitterだけでなくこちらにも記録しておきます。

事の発端は、「topコマンドの日本語の検索結果がデタラメばかりだった。原典にあたらず間違いを拡散している人が多い」という趣旨のツイートを見かけた事でした。

自分も過去にシス管系女子の本編でtopの簡単な説明を書いていたので、これは他人事ではありません。 「もしかして嘘を書いていたか?!」と真っ青になって、詳しくお話を伺ってみました。 その結果分かったのは、自分の心配は杞憂だった(自分が書いた解説の範囲についての話ではなかった)という事と、その人は不幸にも検索キーワードの選び方のせいで誤った情報の海に飲まれてしまった、「検索の仕方」によってネットの技術情報が島宇宙化している、という事でした。

(島宇宙化というのは元々は、宮台真司氏が「社会全体で共通の価値観という物が薄れ、同じ価値観を持つ者同士で小さな社会を作っている様子」を指していった言葉だそうです。自分はその言葉が登場した原典を読んでいませんが、物理的な距離によって隔てられた小集団ごとの社会があるだけだったのが、マスメディア等によって大きな社会が形成され、しかし価値観の多様化により再び小集団に分かれていっている、という事から出てきた表現なのかなあと思っています。)

 

その方は当初、topコマンドの出力において「Swap:」と書かれている行の右端にある「cached」という情報の表す意味を調べようとされていたそうです。(※後述しますが、topのバージョンや実装によってはこの情報が表示されていない場合もあります) 
(スクリーンショット:topの「cached」)

検索結果の上位から見て行かれた所、こちらの記事キャッシュしているスワップ量 ような説明の仕方をしているページが上位を占めていたそうです。「スワップのキャッシュとはどういう事だ? 仮想メモリのスワップ領域をわざわざキャッシュする意味などあるのか?」と不思議に思って調べた結果、検索結果の下位の方に出てきていたページの説明の方が正しかったと分かり、それで冒頭の「topコマンドの日本語の検索結果がデタラメばかり」という趣旨のツイートに至ったとのことでした。

 

その真偽を確かめるためには、まず正しい意味を知らなくては始まりません。自分はそもそもそういう情報が表示されているという事自体把握していなかった(自分が使う機能の事しか把握してない)ので、まずは一次情報ということでman topから見てみましたが、そこにはこう書かれていました。

2c. MEMORY Usage
  (中略)
  Line 1 reflects physical memory, classified as:
      total, used, free and buffers

  Line 2 reflects mostly virtual memory, classified as:
      total, used, free and cached (which is physical memory)

単に「cached」としか書かれておらず、その意味までは分かりません。こうなるともうお手上げなのでWeb検索に頼るしかないのですが、先の「日本語の情報はあてにならない」という情報が頭にあったため、「top cached」というキーワードで検索し、日本語ではなく英語の情報をメインに調べてみる事にしました。すると、Stackoverflow的なQ&Aサイトの以下の記事が見つかりました。

これによると、topコマンドのmanには説明がないものの、freeコマンドのmanには説明があるとのこと。リンク先には、「cached」の説明は Memory used by the page cache and slabs (Cached and SReclaimable in /proc/meminfo) と書かれています。直訳すると「ページキャッシュとスラブ」ということですが、そもそもそれらの言葉の意味が分からないのでさらに調べていくと、以下のように分かりました。

  • 「ページキャッシュ」は、平たく言えばいわゆるファイルキャッシュの事。ディスク上のファイルの読み書きは低速なので、最近読み書きしたファイルのデータはまずメモリ上に置いておいて処理を高速化するための物。
  • 「スラブ」は、SLABアロケータというメモリ管理の仕組み用に確保された領域の事。「SReclaimable」は、SLAB用の領域のうち再利用が可能な部分の事。

簡単にまとめると、どちらも「メモリが空いているなら、せっかくだから処理効率向上のために使おう」という意図で確保されているものの、実際にメモリ領域の確保が必要なアプリが出てきたら場所を明け渡すという性質の物なので、実質的には空きメモリ領域と見なせるという事らしいです。という事で、自分の調べた範囲では「ディスクI/Oのためのページキャッシュ(ファイルキャッシュ)と、SLABアロケータ用に確保されたメモリ領域の合計」というのが「topのcached」の意味と言えそうでした。

ここまで分かった段階で、それでは日本語の解説が本当にデタラメだらけなのかどうかを確認してみよう!と意気込んで「top cached」の検索結果の上位の日本語のページから見始めたのですが、どうも様子がおかしいです。 というのも、ページによっていくつか端折られている部分はあるものの、いずれのページも大筋では上記の調査結果とだいたい同じような説明をしているように見えるのです。 単純に「これはファイルI/O用のキャッシュだ」と書かれている物は確かに不正確ではありますが、メモリのサイズ全体から言うとSLABキャッシュの領域はそれほど大きな物ではないそうなので、まるっきりデタラメと言うほどの物でもないように思われます。 これは一体どういう事なのでしょうか?

 

種明かしをすると、その人の見ていた検索結果と自分の見ていた検索結果では、その顔ぶれが全く異なっていたのでした。

というのも、先のツイートをされた方は、「cached」が「Swap:」の行にあるからということで「top swap cached」のようなキーワードで検索されていたそうなのです。それを聞いて試しに自分でそのように検索してみると、確かに前述のような「スワップのキャッシュ」といった説明をしているページが上位にゴロゴロ出てきました。(14日追記:だた、自分の場合この検索語句でもまだ正しい情報が上位に出てきやすかったので、もしかしたらパーソナライズド検索の影響もあるのかもしれません。)

検索キーワードとして「swap」を1つ加えるだけで僕の調べ方ではなかなか到達できなかった間違った説明に辿り着く事ができる。言い換えると、「swap」というキーワードを1つ加えるだけで急に正しい情報が出てこなくなり、間違った説明にしか辿り着けなくなる。何故こんな事が起こるのでしょうか?

 

これは恥ずかしながら自分自身も今回調べていて初めてちゃんと把握した事なのですが、topのメモリ関連の情報は「1行目」と「2行目」の2つの括りで分けられているのではなく、実際には以下の画像のように、1行目左が「物理メモリ」、2行目左が「スワップ領域」、そして右が「バッファやキャッシュ」という具合に3つの括りで分けられているのでした。 (画像:Raspbianでのtopの実行結果のうち、メモリの情報を3つのグループに分けて示した様子)

実際、topのバージョンや実装によっては「buffer」と「cached」が「buff/cache」と一括りにまとめられている場合もあります。 Ubuntuでtopを実行した時の結果もそのようになっており、自分は普段はそれしか見ていなかったので、「cached」と言われてもピンと来なかったのでした。 (画像:Ubuntuでのtopの実行結果。bufferの代わりにbuff/cacheという項目があり、cachedの代わりにavailという項目がある)

この事を知らないまま、「Swap:の行にあるからスワップに関係する物なのだろう」と誤解してしまう人がいるという事が、実はすべての元凶なのです。

 

つまり、今回の事態が生まれた背景には、こういう事が起こっているのだと考えられます。

  1. 誰かがtopの解説を書こうとして、一次資料をあたらないまま、「Swap」の行に「cached」があるからということで「スワップのキャッシュ、なんだろう」と解釈して、いいかげんな理解で嘘の説明を書く
  2. 「Swap」の行に「cached」があるからということで、それらのキーワードで検索する人が現れる。
  3. 検索エンジンは「検索語句として与えられたキーワード同士が文章の中に近い位置で出現している記事ほど、探そうとしている物に当てはまる確率が高い」という想定で作られている(※これを「共起」と言い、全文検索エンジンで広く使われている基本的な検索アルゴリズムの一つとなっています)ため、1の記事を検索結果の上位に出す。
  4. 3の結果を見た人が、その説明を鵜呑みにする
  5. 4の人の中から同様の説明(「Swapとcachedに強い関連性がある」という内容の記事)を書いて拡散する人が現れ始める。
  6. そのようにして書かれた記事が検索エンジンのクローラーによって収集され、「Swapとcachedに強い関連性がある書き方をしている記事」の絶対数・拡散度合いが増えていく。
  7. 「top swap cached」のようなキーワードで検索する人が、1や5の記事に誘導されやすくなっていく。

同じ情報(正しい説明)を求めて検索しているのに、与えるキーワードの違い、それも余計なキーワードが一つあるかないかでここまで検索結果に差が出るというのは、考えてみるとそら恐ろしい事です。 自分自身、よく分からない分野の事を調べる時に、上位に出た検索結果を鵜呑みにしてしまう事が無いとは言えません。 そのような知的に怠慢な態度と、共起に基づく検索アルゴリズムの相乗効果によって(14日追記:もしかしたら、それに加えて「その人が普段見ている記事の傾向に合わせて検索結果を調整する」というパーソナライズド検索という仕組みも相まって)、デマが拡散されてしまうし、同時に、そのデマが正されにくくなっていってしまう。そうして余計にデマが拡散されるという悪循環が生じる。 ……という事の好例と言えるでしょう。

自分が知らない事・正しいか間違っているか判断できない事を検索するとき、一つの検索結果だけをあてにしないで複数の検索結果を比較するというのは基礎的な情報リテラシーだと思いますが、それだけでなく、キーワードの組み合わせを色々変えて試してみる事も大事だという事が、今回の事例からは言えると思います。

 

また、この事例は同時に、topのユーザーインターフェースが誤解を招きやすい物である(あった)という事も示しています。 topが「cached」の情報を「Swap」の行に置いた上で、これらに直接の関係が無いという事を視覚的に分かりやすく示さなかったせいで、「Swap」と「cached」に強い関連性があると誤解してしまう人が大勢現れてしまった、という事実を無視するべきではないと僕は思います。

ユーザーインターフェースの設計では一般的に、「誤解を招かないように、過ちを犯しにくいようにする」という事が非常に重要とされます。 しかし、開発者向けのツールやサーバーの管理運用に使用するツールのように、使う人自身もある程度その事に詳しい事が想定される場面では、「詳しい人にとっての使いやすさ」や「作りやすさ」、あるいは「なるべく多くの情報を詰め込む事」の方が優先されてしまい、誤解を招かないUIという視点がおざなりにされやすい印象が僕にはあります。 そのようにして作られた「良くないUI」が原因でこのような状況が生まれてしまう事を考えると、専門家向けのツールだからといってUIをおざなりにするのはいかがなものかと僕は思います。

実際の世の中に目を向けてみても、良くできたプロ向けの道具は、「人が使う以上はヒューマンエラーは絶対に発生する、それは訓練では防ぎきれないものだ」という事を前提にして、誤解や早とちりによるトラブルを防ぐように設計されています。 他のレバーと間違えて操作してしまわないように、飛行機の着陸脚を出すための操作レバーはタイヤを模した飾りが付けられているというのも、その有名な例です。

 

ところで、topの「cached」の正しい意味を調べるにあたって僕は、検索結果をタブで開き、気になるキーワードがあればそれをさらに検索して……と芋蔓式に辿りながら最終的に50ほどのタブを開いて、それぞれを行き来して内容を比較しながら正解を探っていました。 
(画像:この事を調べている最中の、僕が常用しているFirefoxの「ツリー型タブ」サイドバーの様子。)

これは自分がFirefoxでツリー型タブを使っていたからできた事だと思います。 仮にツリー型タブを使っていなければ、検索結果を2~3個辿った時点でもう脳の記憶要領の限界を超えてしまい、一度開いたページを無駄に何度も開いたり、まだ見ていなかったページを見落としたりして、「もうこれは自分の手には負えない……」とさじを投げ、掘り下げての調査を放棄してしまっていたでしょう。 それどころか、誤った情報を鵜呑みにして拡散する側に回っていたかも知れません。

優秀な人なら、調べた情報を頭の中にどんどん入れていって脳内で処理するだけで「正解」に辿り着けるのだと思います。
残念ながら僕はそれほど短期記憶力も良くなければ頭の回転も速くないため、自分の脳だけを頼りに調査を進める事は困難です。 そういう一種のハンディキャップを補い、人並みの調査能力を手に入れるためには、僕にはこのようなツールの手助けが必要なのです。 (Google Chromeでタブが増えすぎて「盛り塩」状態になっていた人も多いと聞きますが、僕にはその状態でまともに使える気がしません……)

しかし、これは光明でもあります。
ハンディキャップは技術で補える。それまでは「自分には無理だ……」と諦めていた知的な行動も、ツールの手助けがあればできる。
生まれつき頭の出来が良い人だけの特権であった「複数の情報を比較して、掘り下げて調べて、正しい情報を探し当てる」という知的な行動が可能となる。
自分の能力不足で知的怠惰に陥らずに済むようになり、その結果、より良く生きられるようになる
目が悪ければ眼鏡をかけるように、記憶力が悪いなら「画面の中に全部出しておいて、記憶しなくて済むようになるツール」を使えばよいのです。

「技術は不可能を可能にし、人を幸せにする物だ」という事を、僕はこのような事を通じて日々実感しています。 だからこそ、自分にそのような生き方を可能としてくれたITという物に今なお強い思い入れを持ち、真摯に向き合いたいと考え、自分もそういう光明をもたらす側になりたいと思えているのかも知れません。

WebExtensionsのコンテキストメニューの新常識 on Firefox 64 - Nov 06, 2018

Here is the English version of this article.

朗報があります。2016年6月にWebExtensionsへ一本化の方針が示された時に出した要望であるBug 1280347 - Add ability to provide custom HTML elements working as alias of existing Firefox UI items, especially tabsが、最近ようやく解決されました。

何故これが朗報なのでしょうか? アドオンのXULからWebExtensionsへの移行の話をおさらいしてみましょう。

続きを表示する ...

WebExtensionsベースのアドオンが他のアドオンと連携するにはどうするのが良いか? - Nov 06, 2018

Here is the English version of this article. 7月に英語で書いた物の日本語版です。Qiitaにもクロスポストしています

ツリー型タブXULからWebExtensionsに移植した時の話で、アドオン同士の連携が取りづらくなる事への懸念について書きました。この点について現時点での知見をまとめておきます。

続きを表示する ...

WebExtensionsでのタブの複数選択APIのつかいかた - Nov 01, 2018

Tokyo WebExtensions Meetup #3で、標題の通りの発表をしました。スライドはQiitaにありますが、こちらにもクロスポストしておきます。

タブの「選択」状態とは?

タブの複数選択機能が入った事で「選択」という言葉が多義的になってしまったので、まずその点を整理します。 WebExtensions APIにおいては、「選択」という言葉で表されうる状態に以下の2つがあります。

  • アクティブ なタブの事
    • active tab というのがWebExtensions APIの語彙上の言い方
    • current tab という言い方も古くからある
    • foreground tab という言い方もある(background tabとの対比)
  • 選択複数選択) 状態にあるタブの事
    • highlighted tab というのがWebExtensions APIの語彙上の言い方
    • multiselected tab という言い方もされる

「selected tab」という表現は紛らわしいので、このエントリでは使いません。

Firefox本体に入ったタブの複数選択機能

Firefox 63でabout:configbrowser.tabs.multiselecttrueにすると試せます。Chromeでも同じ操作ができます。

  • タブの上でShift/Ctrl(Command)-クリックでタブを選択できます。
    • 選択されたタブは、上に青い線(Linux版ではシステムカラーに依存する。UbuntuのAmbientテーマではオレンジ色)が出る。
      (スクリーンショット)
  • タブが選択されていると、コンテキストメニューほか一部の機能が「選択中のタブすべてについてそれをする」ようになります。 (スクリーンショット:メニューのラベルが「Tab*s*」になっている)
    • まだ一部の機能はそのようになっていない。Firefox 64で一通りの機能がすべてタブの複数選択に対応するという事だと予想される。

アドオンからの2つの利用局面

WebExtensionsベースのアドオンにとっては、このタブの複数選択機能に対して2つの関わり方があります。

  • 選択されたタブに何かする
    • タブを処理対象にした便利な機能を提供するアドオンの場合
  • タブを選択する
    • タブを管理する、タブバーの代替となるアドオンの場合

それぞれ順番に紹介します。 なお、基本的にはChromeの拡張機能でも同様のAPIが使えます。

続きを表示する ...

Various "custom context menu" usages in Firefox 64 - Oct 26, 2018

As I described at the previous article, you can provide more useful and usable context menu for your addon on Firefox 64 and later, if it is focused to control tabs or bookmarks. The previous article described basics of new APIs, but it looked too complex because there are various usecases. So this article aims to describe how to provide context menu simply for different cases:

  1. Extra context menu items for custom commands, when your addon has no sidebar/popup panel
  2. Extra context menu items for custom commands, grouped under a submenu with a custom label
  3. Context menu dedicated to custom commands on your sidebar/popup panel, and expose them as a submenu on other situations
  4. Context menu dedicated to custom commands only on your sidebar/popup panel
  5. Context menu dedicated to custom commands on your sidebar/popup panel, and expose them as a submenu on other situations, with a custom label
  6. Imitated context menu compatible to Firefox's one on tabs or bookmarks, only on your sidebar/popup panel

All following examples assume that your addon named "Bucket" provides ability to send tabs to an online bucket, like the "Pocket".

続きを表示する ...

An improvement of WebExtensions on Firefox 64 about implicit collaboration of addons - Oct 14, 2018

このエントリの日本語版はこちらから読めます。

(Note that this article describes about an improvement on Firefox 64, and Firefox ESR60 is out of target.)

Good news! An old feature proposal filed at the time Mozilla announced that XUL become deprecated and WebExtensions become the next main line has became fixed: Bug 1280347 - Add ability to provide custom HTML elements working as alias of existing Firefox UI items, especially tabs.

Why it is a news for me? Let's look around the short history of addon migration from XUL to WebExtensions.

続きを表示する ...

シス管系女子とハイヒール - Aug 24, 2018

彼氏と東京旅行をするので沢山歩くことを想定しスニーカーで行ったら、ヒールを履いてほしかった彼氏がブーブー…そこで彼女の取った行動とは?という話題がバズってたのと近いタイミングでみんとちゃんの靴をイメージした靴を作ったので、シス管系女子作中でのヒールの話を書きます。

(みんとちゃんがよく履いている靴の設定画)

みんとちゃんは作中で何種類かの靴を履いていますが、一番登場回数が多いであろうこの靴は、ウェッジソールでヒール部分は6~7cmの高さがあるだろうという想定です。モチーフにした靴はパンプス風のスニーカーで、みんとちゃんの靴もそれに倣っている(踵の所にプルストラップが付いているのはそのせい)のですが、絵の質感が完全にパンプスのそれになってしまっているので、再現靴として改めて作った物はウェッジソールのパンプスをベースにしています。

(再現靴の写真)

これは実用ではなく完全にコスプレ・撮影用と割り切っていて、ヒールの高さは11cmあります。ただしつま先側(フォーム)も4cmある厚底なので、踵がつま先よりどれだけ高くなるかという点で言えば実質ヒール高は7cmです。

(再現サンダルの写真)

こちらは上記の靴に次いで登場回数の多いサンダルの再現ですが、これもウェッジソールでヒールは7cmほどです。元々のモチーフになっていたサンダル(手放してしまった)も確か同じくらいだったと思います。

設定上は、みんとちゃんは脚が綺麗に見える靴が好きなのでヒールの高い靴を好んで履いており、ただしある程度安定感があって歩きやすい事からウェッジソールを選んでいる、という事にしています。

実際の所は、元々自分はハイヒールの形はピンヒールやチャンキーヒールくらいしか知らなくて、というかそういう様々な分類がある事すらも知らなかったのですが、妻がかつて普段履いていた靴が「かわいいデザインの、ヒールが高めの、でも歩きやすい(本人談)ウェッジソールのスニーカー」で、「そんなのがあるんだ!」「かわいいのに歩きやすいなんて一挙両得じゃないか!」「見た目のかわいさと実用性って排他じゃないんだ!」と強く衝撃を受けた事から、自分の中で「実用性を諦めない、したたかな『カワイイ』の象徴」として刷り込まれているという部分が大きいのだと思います。

一方の大野先輩については特にこういったこだわりは設定しておらず、それこそテンプレ的な「オシャレなOLが日常的にはいていそうなイメージの、4cmくらいのヒールのパンプス」をはいてもらっているつもりの事が多いです(それより高いヒールに見える絵は単なる作画崩壊です……)。

(大野先輩の靴)

4cmは一般的にはぎりぎりローヒールに分類される高さだと聞いたので、まあこんなもんじゃないのかなあ、みたいな。

とはいえ、彼女らはメタな発言をしがちなので、先輩ももしかしたら「今日はシス管系女子の連載回の撮影があるからちょっとヒールのある靴でオシャレしていこう」と考えてこの靴を履いてきているだけで、普段はもっと低いヒールのぺたんこ靴や普通のスニーカーを履いているのかもしれませんね。

バズッた話題の方では女性が男性からハイヒールを強制される事への恨み辛みが多く語られていますが、シス管系女子の作中世界に関しては、少なくとも服装規定でそうなっているとか、周囲からの圧力があってというようなことは無いです。


ところで、冒頭の靴とサンダルで丸一日写真撮影をこなしたモデルさんは翌日激しい筋肉痛に襲われたそうだという事をここにご報告しておきます。普段からこれを履いて過ごしているみんとちゃんは相当足腰が鍛えられているのでしょう……

What's the best way to collaborate an WebExtension-based addon with others? - Jul 28, 2018

このエントリの日本語版はこちらから読めます。

When I migrated my addon Tree Style Tab from XUL to WebExtensions, I wrote some concerns about communication between addons. Let's share my knowledge around the topic.

続きを表示する ...

Tech系Podcast「しがないラジオ」ゲスト出演しました - Jul 03, 2018

「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」略して「しがないラジオ」というネットラジオ(Podcast)があり、マンガでわかるGit等で知られる湊川さんが出演されていたことで僕はその存在を知った(というか「Tech系Podcast」という物の存在自体この時知った)のですが、その後「インフラガール」で知られるナツヨさんも出演されたと知って、(マンガのペン入れなどの言語野を使わない)作業の時にBGM代わりに聞くようになり、いいなあ自分もこういう所に出てみたいなあと思いながらチラチラと感想ツイートを繰り返すなどの小賢しい消極的アピールを続けていた所に、シス管系女子3の発売というタイミングが重なりまして、「それで今日は何かお知らせがあるということで?」「はい、実は最近こういう本を出しまして……」みたいな定番のアレをやるなら今しかないと思って「出たい!」と自己申告し、押しかけでゲスト出演させていただきました。

自分はFirefoxやThunderbirdの法人サポートを業務でやっていますが、エンドユーザーからの問い合わせを直接受けるのではなく、SIerの方やBtoB/BtoC企業のシステム管理部門の社内SEの方がエンドユーザーから受けた問い合わせのエスカレーション先として回答する立場で、Podcastのタイトルからすると脱出を図られる方の分野に近しい所にいると言えます。IT業界への就職や転職を考えている方でSIerかウェブ系かという二者択一で考える人は結構多い印象がありますが、その二者択一に含まれない選択肢もあるんですよ、そんなにキラキラしてないIT業界でも命を磨り減らさずに自分にできる事で生きていく例はあるんですよ、という事を前半では話してみたつもりです。

(Show Noteの注記にあるとおり、クリアコードの立ち上げ時のメンバーは、Podcast中で言っている「3人」ではなく「4人」です。よりにもよって社長をカウントし忘れておりました。直前のタイミングで実施した社内ミーティング(社長欠席)の様子を思い浮かべながら話していたので……事前に準備していない話題をふられると弱いという事が露呈していますね。)

後半では、OSSにコントリビュートするってそんな難しい事じゃないし、やると得られる物がいろいろありますよ、OSS Gateに来て挑戦してみてね、という話や、シス管系女子を制作する時に心がけている事、分かりやすく説明するためのコツやその逆の「べからず」について、あと、自分が(技術のコミュニティ等で)老害にならないためにはどういう事に気をつけたらいいんだろうね、というような事を話しています。とりとめのない話を思いつくままにしているようで、それらの話題が根底では繋がっている、という事が最後まで聞くと明らかになる構成に図らずもなっていて、結構面白い話になっているのではないかと思います。

パーソナリティのgamiさんとzuckeyさんは僕より10歳くらい若くて、過去の出演者陣の中でも僕(35)は最高齢一歩手前なのだそうです。クリアコードは全員合わせても10人しかいないという零細なので特に「昇進」のような概念が無く、「上司」然として部下を率いるような立場になった事が無いので、いつまでも下っ端気分で若いつもりでいてしまいがちなのですが、こうしてはっきり数字で見えてしまうとドキッとしますね。自分が26とかの頃を思うと、10歳とか離れてる上の人は「大先輩のおじさん」みたいな感覚で、緊張して思うように喋れなかったものです。後編では「老害にならないためには」みたいな話をしていますが、いつまでも若いつもりでコミュニティに居座り続けて(経験の差から)俺TUEEEEEして悦に浸るというのもまた老害の別の形ではあると思うので、重々気をつけねばいけないという思いを新たにしました……

 

自分の声を聞く事はあまりないので、終始「ドュフフフフwwww」みたいな感じだったらどうしようと戦々恐々としていたのですが、いい録音機材で録っていただいたお陰なのか、音質調整が巧みなのか、そこまで赤面する事も無く安心して「いやーいい事言ってるなあこの人。誰だ。あっ僕だ」と新鮮な気持ちで聞き返す事ができました。パーソナリティのお二人にうまく誘導していただいた事もあり、終始気持ちよく喋らせていただいて、気付けば朝の集合から4時間近く喋り通しでした。調子に乗ってマウンティングじみた俺TUEEEEE話をペラペラ喋るという、これはこれでまた老害っぽさがものすごい事になっていないか心配だったりもしますが、楽しい時間を過ごさせていただき、自分は大いに満足しております。改めて、この機会を頂きありがとうございます。

凍結されても迷惑行為をやめない人にできる事はあるのか問題 - Jun 30, 2018

この事件に関する報道を見ていた感じでは、限りなく通り魔に近いような物だったという印象だった。迷惑行為を繰り返す→通報される→通報されて凍結とかBANとかの対応を取られる→またアカウントを作り直す→迷惑行為を繰り返す……という事をしていた人が、通報・凍結の頻度が上がって追いつめられてストレスを募らせて、そんな時にまた煽られて、たまたま手の届く距離に来た人がいたから暴発した、という。だから、Hagex氏が公然と通報を煽らなければ良かった、みたいに言う人もいるけど、「人生がうまく行ってる人を見て妬む」みたいなのだってあるわけで、「不用意な発言をしないように気をつけましょう」なんてのは何の役にも立たないアドバイスなんすよね。

 

それはそうと、東洋経済オンラインの記事は「加害者を追いつめすぎるな」という論調だけど、かといって「迷惑行為をさせるがままにして、他のユーザーは彼の迷惑行為の被害を我慢しなければいけない」というわけにもいかないじゃないすか。ごく少数の迷惑なユーザーのせいで、一般ユーザーが離れてしまっては元も子もないし。

AbemaTIMESの動画では、よく炎上する事で知られるウーマンラッシュアワー村本氏が「昔は罵倒してくる人をブロックしてたが、ブロックされた人が逆上して余計に罵倒してきていた。今はミュートするようになって、相手はその事を知らずにずっと罵倒し続けているから、自分は快適で相手もスッキリしてWin-Win」みたいなことを発言していて(うろ覚えです。詳細は違ったかも)、やっぱり、こういう迷惑行為からフツーの人を守る鍵になるのは「ブロックよりミュート」という考え方だと思うんすよね。

自分がブロックされる側になる事があんまり無いからか、多くの人が気付いてないんじゃないかと思うけど、ブロックって「拒絶・否定した」というメッセージを相手に対して表明する行為なんすよ。普通に生活してて、明確に拒絶の意思を表明される事ってそうそう無いじゃないすか。これは多分断られるだろうなあ、断られても仕方ないよなあ、みたいな心構えができてる時ならともかく、前触れも無しに拒絶されたらイラッとする人多いと思うんすよ(僕はそうです)。それまでニコニコしてた人が、NOを伝えた瞬間に逆上するってよくある光景じゃないすか。「自分は相手から否定された」という事をわざわざ相手に知らしめる事は、リスクなんすよね。

もちろん、やっちゃいけない事をした人に「それはやっちゃいけない事だ」と指摘して、行為を改めさせる事は大事です。でも、言ったからってやめる人ばかりじゃないし。むしろ、自分の中で反省する準備ができてない人は、何を言われても頑なになるだけで、反省なんかできるはずが無いし、行為だって改めないし、余計に攻撃的になる事だってあるわけじゃないすか(こういった話は、実際に刑務所等で犯罪者の更生に関わった人が書いた「反省させると犯罪者になります」という本が面白いのでオススメです)。行動を改めも反省もしない人に対して、「あんたはブロックされたよ」「あんたはBANされたよ」とわざわざ伝える事に意義なんて無いわけですよ。

「ミュート」の面白い所は、ここがデジタルというかネットというか非物理的なサービスの面白い所なんだけど、見る人ごとに違う物を見せる機能だという点なんですよね。ミュートしてる人からは、ミュートされた人がいないかのように見える。ミュートされた人からは、自分がミュートされているとは分からない、今まで通りの物が見えている。なので、僕はこう思ったのです。迷惑行為で通報された荒らしユーザーは、サービスを使用する権利を全面的に剥奪される代わりに、単に隔離されて、自分以外の全員からミュートされるようになってたらいいんじゃないのか? と。そうすれば、迷惑行為をはたらく人は今までと変わらずに迷惑行為(と主観的には感じられる行為)をしてスッキリできるし、他の人は迷惑行為から守られるし、Win-Win。もっと言えば、サービス運営者も「迷惑な人」一人分のPVを失わないで済むのでWin-Win-Winかもしれない。

ただ、相手の反応なんかお構いなしに暴れ回る人ならそれでいいんだけど、反応される事が自分の快楽ループに組み込まれてる人だと、「無視するんじゃねー!!」と逆上してしまいかねないという問題は残る。これをどう解決すればいいか。

スラドのように、他人からの評価がマイナスの人は「デフォルトでは見えない」「わざわざ見ようと思って見る物好きは見れる」というシステムになっていれば、何かしらの反応はある状態を維持できるかもしれない。でも、本人を逆上させないためには「自分の評価がマイナスという事を本人に知らせない」事が大事と考えると(スラドはそうはなっていない)、荒らしを自ら覗きたがるような意地の悪い物好きだもの、「あんた評価マイナスで見えなくなってるよ」とわざわざ告げ口しかねない。告げ口は無粋、黙って観察せよ、というスタンスの「ウォッチャー紳士」ばかりではない。だから「人に見させる」のはやっぱりリスクだと思う。

それで考えたんすけど、ここはひとつ、今流行りの機械学習でもって「荒らしがされたい反応だけを返す人」を演じるbotも用意して、「一般ユーザーが見てる世界」と「荒らし本人(達)と、それに反応するbotだけの世界」とを用意してみるというのはどうでしょうか。実際、自身が隔離されているという事を本人が認知できるという点を除けば、GTAタイタンフォールといったオンラインゲームにはそれに近い仕組み(違反者とNPCだけがいる、「負け犬サーバー」とか「チータープール」と呼ばれる物)があるそうだし。専用ワールドを維持するコストはかかるけど、Twitterやはてブのように人の悪意が増幅・拡散されやすい仕組みのSNSでは、人の命がかかってるんだから、社会に対する義務を果たすための必要経費として容認してもよいのでは? なんて思っちゃって。

……という事を考えてはみたんですが、自分で言っててすごいディストピア感ありますね。だって、何も言われずに隔離されて、その事に本人で気付けないって、自分で行動を改める機会を奪われるという事だもの。ある意味非常に冷酷で残酷な措置だ。主観的には幸せかもしれないけど、客観的には哀れですよね。というか、そういう物が既に実用化されていて、自分自身も既にそういう世界に隔離されてるんじゃなかろうか? と思うと、背筋が薄ら寒くなってくる。

 

もっと生産的に考えると、単に荒らしがされたい反応だけを返すbotにするんじゃなくて、カウンセラーのように振る舞うbotにするというやり方もあるかもしれませんね。つい最近、カウンセラーにも当たり外れがある(誰もが人間的にできたカウンセラーばかりでなく、未熟で技能的にも不適格な落第カウンセラーもいる)という話を見かけたけど、botだったら「自身の感情」に流されずにカウンセラー役を淡々と勤め上げられるでしょうから。どうでしょう。まだまだSFの世界の話すぎますかね?

Page 1/241: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき