この話は今後を見据えた今の思考をまとめたものに過ぎない。

チャットについて

チャットにかける思い

チャット。

今の人にはあまり馴染みがないかもしれないが、インターネット黎明期のメインコンテンツがチャットだった。 ちなみに、もう少し前から見ると「掲示板」のほうがメインであり、ネットニューズを含めてポスト型のコミュニケーションから、パソコン通信時代を経てチャットのほうが追い越していく形だった。

私がはじめて経験した「画面の向こうの世界」は、the Internet上でのチャットだった。 1992年のことである。

私はあまり人と接さない子供だった。 幼少期は比較的コミュニティの濃い空間にいたが、「なじまない」という気持ちはとても強かった。

1992年に私が呼ばれたとき、私の扱いは「子供」ではなかった。ひとりのハッカーとして呼ばれたのだ。 技術的には未熟もいいところであったから、実際に対等なものであったのか、正直なところ今や私は覚えていない。10年くらい前までは結構はっきりと記憶していたと思うのだが、今や仲間たちの顔も名前も思い出せない。 そもそも、私の脳はそうしたことを思い出せるようにできていない。

そして、そのときのことは私にとって「衝撃な体験ではあった」のだが、あまり私を私たらしめる要素ではない。 それは、幼い頃のプログラミング体験が今の私には何も活きていないということと同じだ。

どちらかといえば、2000年に自宅でインターネットができるようになったとき――そしてチャット全盛期でもある――ようやく私の言葉が受け止められるという歓びに打ち震えたことこそが原体験となっている。 やがては結局、想いを共有できる者などいないという事実にぶち当たるわけだけども、少なくともそれまでのように言葉を尽くす意味もないということはなくなった。

結果、私はチャットにのめり込んだ。 real worldでの生活においては価値観を共有可能なコミュニティに巡り合わなかったということもあって、チャットは同時に私にとって貴重な出会いの場でもあった。 今私は誰とも触れ合わず暮らしているが、チャットがなければ昔もあまり変わらなかっただろう。そして、そうであればそれは今とは意味が全く異なる。

そのチャットも、コモディティ化によって崩壊する。 残されたのは、極めて限られた層だけが利己的に振る舞う場所としてのチャットだ。

復権はないのか、ずっと模索してきた

観測を続けていれば、インターネットの変化はよくわかる。 そして、人々が――特に若い人が――ネットに対して既知のコミュニティ以外を求めなくなってゆくこと、そして一方的なコミュニケーションのドッヂボールと化していくことは、痛いほど感じられた。

疑問はつきない。

人は本質的にコミュニケーションを求めるものなのではないのか

誰もが自分が暮らす狭い世界であてがわれる関係性だけで満足しているのか

――世の中誰もがリア充なのか?

もっともっと多くの人とめぐりあい、気の合う者、分かち合える者をみつけ、たくさんの言葉を交わしたいとは思わないのか?

少なくとも私は真のマイノリティだから、インターネットがなければ分かち合える言葉を持つことはない。 例えば、「持てる技術の限りを弄ぶ求道者」も、「知識と関心で世界の観測を望む者」も、「自己属性の有利ではなく均衡を望む者」も、普通に暮らしていては出会うことができない。 そう多く浮かぶわけではないが、今の知己の面々は実際、かけがえのないものだと私は認識している。

人は会話を望まないのか、チャットは人にとって夢のようなツールではないのか。 その想いはずっとあった。

現実は厳しい

チャットに限らないのだが、コミュニケーション系のコンテンツというのは非常に難しい。

一番の理由は「参加者の量に依存するから」である。 開始時は0にならざるを得ないので、コンテンツ価値がない状態からしかスタートできない。 そして、人の集め方を間違うと取り返しがつかない。 TwitterとLINEがどれほど腐っていても容易にはやめられない理由でもある。

技術的にも結構難しい。幅がひろすぎる上に、マッシヴコンテンツの対策というのは、経験しないことにはわからない。 Twitterは秒間25000ほどのツイートをさばくという。今では減少しているそうだが、携帯電話キャリアのあけおめメールのさばき方も並大抵ではないだろう。 IIJは甲子園野球の中継をホストしているが、550Gbpsを配信しているという。

Twitter以上の活発さを目指すのであれば技術的ハードルも高いなんてもんじゃない。

普通のHTMLチャットソフトの再実装(元ソフトウェアはTeaChat)からはじまり、このPerl5(オブジェクト指向), PHP5, Ruby 1.8, MySQLバージョン、sqliteバージョン、GDBMバージョン、ファイルシステムツリーバージョンと幅を広げ、 さらに独自実装ではNode.jsバージョン、Ruby emバージョン、事前静的生成バージョン(リードは静的HTMLで、送信によってHTMLを更新してしまう)が誕生し、EventMachine以外にもZeroMQを使ったもの、Rindaを使ったものなどとにかく色々と試した。 ZeroMQバージョンとRindaバージョンはウェブではないバージョンも登場した。

今に至るまで納得できる実装は登場していない。 作っている間に世の中の要件が変わりすぎるからだ。 「始めればついてくる」という確信があればとりあえず動くものを作っただろうが、そちらに関しては全くのノーアイディアだったから、それすらもしなかった。

例えば、成瀬さんは「チャットにログインがあるべきではない」と考えている。 一方私は「チャットに対してアクティブな状態にすることで「会話しよう」という明確な意思を形成できる」と考えている。 最高のチャット体験とはなにか、追い求めるほどに難しい。

いや、チャットコンテンツの主体は人だから、そのあたりはどうでもいいとも言える。 だが、「使ってもらえるチャット」である必要があるのだ。 だから「使い始める動機」を与える必要がある。

究極のUXを求めて

現状の仕様

RindaとZeroMQを中心とした複合的な技術になっている。フロントエンドはWebSocket+EventMachine(em-websocket)である。 繋ぎっぱなしなので、恐らくあまり大きな負荷には耐えられない。

データは極力クライアントサイドによって処理するという仕様であり、クライアントサイドJavaScriptに大いに依存している。

概念としてはログインがなく、「チャンネルの購読」という方式になっている。 channel subscribeするとチャンネルに対する更新を受け取ることができる。 チャンネルは無軌道に作成できるわけではない。

表示はoverall timelineとchannelの2種類。 過去ログ機能はなく、あくまでアクティブ中のメッセージが読めるだけ。

この表示はクライアントサイドのフィルタになっていて、channelを選択すると当該チャンネル以外のメッセージが非表示になる。

発言を行う場合、表示がchannelであれば単純にメッセージウィンドウを出して発言するだけ。 overall timelineの場合はメッセージウィンドウを開くときにチャンネルを選択する。

アカウントとログインは、アカウント認証時にeメールを必須とし、以降はログインのたびにeメールに書かれたPINを入力する。 パスワードはなく、eメールアカウントで管理することになる。

これとは別にトラディショナルなHTMLウェブチャットもある。 トラディショナルと言いながら実装は普通ではなく、

  • CGIによって動作するRubyスクリプト
  • 表示はiframe上の静的なウェブページ
  • チャットページはmetaタグによる自動リロード
  • チャットポップアップキー、またはチャットウィンドウアイコンによって発言用のウィンドウをポップアップする。これは親フレーム側(静的HTML)に属している
  • 同ウィンドウの送信先はチャットCGI
  • チャットCGIはデータベース(GDBM)を更新すると共にHTMLを書き換える

という仕様である。

実はあんまりよくない

Twitterとチャットの中間というか、まぁマストドンに近い感覚になっているのだけど、もっと単純なほうが使いやすい、と感じてしまう。

チャットUIのベストのあり方、というのは難しいが、PCではテーブル型(発言者と発言の横並び)、スマホでは定義リスト型(発言者の下にインデントして発言)が見やすいように思う。 さらにいえば、定義リスト型で長さによって横に並べるか下に置くかを動的にするのがベスト、かもしれない。

UIデザインに関しては色々と検討しているが、少なくともLINEのものは「悪くはないが、最善ではない」というところにある。 大人数の場合は追いにくくなるので、もっとエレメントを詰めて表示したい。

恐らくデザイン的にはDiscordのチャットが素晴らしい。

しかし、いずれにしても単純な連続的会話ストリームであるほうがよく、つまりはDiscordやSlack、あるいはIRCのような会話が望ましい。 結局のところ、TwitterのようなSNS形式が会話の環境として望ましいわけではない。それは、TwitterのDMがTwitterのUIとは別の形式を持っていることからも明らかだろう。

もうひとつの問題が、「ライフの長いチャンネルは淀む」ということだ。 チャンネルに支配的な発言者がいるとそのチャンネルは腐敗していく。これはYouTubeのチャット欄などでも発生する事情で、常連が支配的に振る舞うと、結局チャット全体が支配されてしまう。 だから、チャットチャンネルのライフはある程度短いほうが良い。だから、固定的なチャンネルというのは良いものでもない。

結果的には、Twitterがチャットの進化系であるという意見を元にTwitter的なやり方を取り入れて(もっと言えば、IRCや2ちゃんねるなどの「流行った手法」の踏襲)みたものの、結果としては「昔のチャットのほうがよかった」という結論に至ってしまう。

それはある意味当然で、昔のチャットというのは、他のことが手がつかないとしても会話に集中できる環境づくりが意識されていた。 対して、近年のLINEのようなコミュニケーションツールは昔のケータイメールの延長線上、つまり「メッセージを残す」性質のものになっている。 だからチャットでは通常あまり重要ではないタイムスタンプや既読マークが重要になるし、会話のフローを一覧しやすいようにもなっていない。

結局のところチャットとして望ましい仕様というのは非常に古典的なものだという結論に到達してしまうのだ。

UI部分

実は1:1とパーティチャットにおける望ましいUIというのは全然違う。

1:1だとDiscordのUIは相当に理想に近いところにある。 PC版だと他のサーバーや他のダイレクトメッセージを開いたり、通話をかけたりといった操作系がわかりやすく配置されている。 改行が可能であることは良いこととは言い難いが、そのためにMarkdownを用いた修飾が可能であることは利用の幅を広げてくれる。ただ、純粋に「チャット」であるならばそのあたりは抑制的なほうがいいだろう。

スマホ版だとメッセージ表示の余地が大きく、LINEと比べてすっきりしていて見やすい。 欲をいえば上部にあるアイコンやメニューなどは左右スワイプで出したい。

横長でもメッセージ幅を広げてくれるため見やすい。アイコン表示も見やすく、アイコンの存在がメッセージ表示領域を圧迫していない。 PC版ではページ外に、モバイル版ではチャットウィンドウ上にタイピング中のインジケータを出す。 これはSkypeあたりがやり始めたことだったような気がする。

スマートフォンならXabberも悪くないと思うのだが、これだとLINEやTelegramとほぼ一緒。

DiscordのUIは洗練された良いものだが、古典的なメッセンジャーUIであるPidginを見ても別に悪くないと感じる。 会話が盛り上がってくれば表示に改善できる余地がある点も気にならない。

それどころか、古典的なHTMLチャットですら割とアリだ。 現代のコンピュータと回線だと速度的にも速くなって非常に実用的。

パーティチャットの場合は大量のメッセージが流れることになるため、より一覧性が高く、スクロール時に見失いにくいデザインが望まれる。 インスタントメッセンジャーアプリの中ではKopeteが非常に不満な安定性ではある(よく落ちるし、接続もなかなか確立できず、メッセージの受動的受け取りができない。さらにいえば、コンタクトリストがどんどん増える)のだが、UIは最高に望ましい。 邪魔にならないアイコンと、コンパクトな表示が優れている。ただ、名前とメッセージの間が空きすぎていて、Discordよりも間延びしているのが残念。とはいえ、PC向けのパーティチャットの基本的な最も良いUIがこの方向であることは間違いない。

加えていうなら、「色分けしたい」というのはある。 ここでは「自分とそれ以外」でヘッダー部分の色が変わるのだが、メッセージ色なり、名前色なりといった部分がユーザーごとに違うようにして、アイコンや名前を確認しなくても誰が発言したかわかるようにすることと、自身の発言だけ背景色をつけることで明確にすることだ。

スマホ版でも基本的な方向性には変わりないが、チャットウィンドウ以外の「なにも表示しない」のがいいのではないだろうか。 1:1では常に自分は発言する状態にあるが、パーティチャットの場合その瞬間に発言しようとしていない人というのが多い。 だから発言用のウィンドウも非表示。チャットウィンドウだけ。参加者一覧とメニューアイコンを左から右へのスワイプで、発言を右から左へのスワイプで出す、というのはどうだろうか。 もしくは小さな発言用アイコンをフロートさせてもいいのだけど。

スマホで発言ウィンドウ(というよりもソフトウェアキーボード)を出した状態での表示領域の小ささはいかんともしがたい。 発言ウィンドウ表示は1行に抑えるとして、それでもチャットの表示は少ないので、発言ウィンドウを開いている間は表示更新はしないのがよかろう。

チャット体験部分

チャットの体験としては、「ライフの短く、固定性のないチャンネルだが、匿名ではない」が良さそうだ。

現存するものとしてはランダムマッチングのものがあるが、さすがにこれはライフが短すぎる。 また、よりライフの短い人と非常にマッチングしやすくS/N比が実際以上に悪化してしまう。

このことを考えると、

  • チャンネルは自由に立てられるが
  • チャンネルのカテゴリは大枠で制限されており
  • 検索によって発見する
  • チャンネルは接続が0になるか、一定時間以上誰も発言しないとクローズする

あたりが良いのではないかと思う。

ただし、これだと部屋の作成がまともにできないので、作成後一定時間はライフを維持できるようにするか、作成後joinされるまではある程度の時間待ち受け状態であり続けられる(検索対象になる)という形で良いかと思う。

これにroom limitを加え(固定値でもいいし、5から20などの範囲で設定できても良い)、limitを迎えたチャンネルは検索対象にならないようにする。joinできなくするかは要検討。恐らくjoinできなくする必要はない。

これで交流はある程度流動的になるし、どうしても固まる人たちはむしろ固まってくれたほうが良い。

kickは与えず、チャンネルマスターも設定しない。 それをすると「開設者がチャンネルマスターとして支配的に振る舞う」という事態が発生するからだ。

ユーザー関連機能は厳し目にしないとひどいことになってしまう。

厳格なユーザー認証(恐らくSMSが良い)を必要とし、ユーザーに対してはプロフィール機能を用意する。 このプロフィール機能は記入は任意であり、主にはチャットユーザーがそのチャッターに関する情報を確認するためのものである。 実は、「はとこみ」設計時はこの機能を中核として考えており、「ユーザーがあり、コミュニケーションを取る」ような形であったが、それと比べると抑制的である。

チャンネルに関してカテゴリ違いや禁止事項への抵触に対する対応はかなり厳しく行う。 一方、「通報」に関する対応は、「通報件数が多いから」のような対応はしない。

どちらかというと「ブロック」を上手に使う方向で考えている。 このあたりはYouTubeチャットと同じか。

運営リソースはかなり必要になりそうだ。

そして、これはLINEオープンチャットのように、無数の人が最初からいる前提である。

LINEオープンチャットがユートピアとなりえない理由

時代を変革するかと思われたLINEオープンチャットだが、致命的な問題が見つかったので、そこまでのことではないと判断することができた。

その致命的な問題が、「過剰な連絡先交換の拒絶」である。

現在、社会的な理由でリスクを避けるためにも、また制度的(法的)な理由でもそのようにしたいということはわからないではない。 だが、これは致命的なミスである。

このような扱いは、結局のところ「匿名で荒れる」という状況を作り出すことになる。 その場での発言が全てなので「別に何言ったってこの場のことだし」となるし、結果2ちゃんねるやニコニコ動画のコメントのように非常に品位の低い一方的な言葉の投げつけが行われることになる。 そんな環境ではまともな会話が成り立つことは極めて少なくなるし、生産的な場になりようがない。

交流の場たらしめるには匿名にしてはならないのだ。 それは、ずっとチャットを含めコミュニケーションをずっと眺めてきて強く感じることだ。

そして、匿名にすること、ここが「他のコミュニケーションとは違う」という扱いをすることによって「画面の向こうに人がいる」という基本的なことを意識しなくなる。 だから何をしてもいいという理屈を振り回すようになり、人を傷つけることに対して抵抗をなくしてしまう。 必要なことは匿名化ではなく、「on your risk」を明確にすることだ。

連絡先を交換することも、あなたのリスクにおいて、それが結果どうなったとしても他者に責任を求めることはできないし、してはならないということを承知の上で自身で選択すればよい。 自身の振る舞いには常に責任があるということを明確にしないと、ただただ悪意と攻撃ばかりが増幅していく。

LINEオープンチャットは実際に蓋をあけてみれば、あらゆる点に対して思慮が足りなかった。 チャットの運営はとても大変なものであり、それは文化足り得るからこそ慎重さも必要となる。

確かに、LINEでチャットをはじめれば多くの人が利用するだろう。 だが、それが意味するところ、それをすることで実現できることを十分に測らなかった、そう感じる。

もちろん、これはある種イデオロギーの対立である。 私が正しいと信じるものに賛成はすまい。 でもだからこそ、それは私が求めるユートピアではないと、そう感じるのだ。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください