Twitter、また協力サービスへの締め付けを強化か、OpenTween などの投稿制限
もはや絶望しかない．
サードパーティー製クライアント（Whalebird）の製作者として，正直呆れ果てて絶望としか言えない．
また，GFeedLine，Tween，夜フクロウ，HootSuiteを愛用している，利用者としても，呆れることしかできない．
俺はtwitterというサービスが大好きだ．
だけれど，最近のtwitter社は大嫌いだ．
twitterというサービスの基本理念は，非常に心地よいものだった．
それに対して，twitter社は，利益の拡大，広告の拡大という戦略を打ち出し，本来あった基本理念を次々と潰している．
サードパーティ製クライアントの話も，そもそもtwitterが初期にあれだけ流行っていたのは，クライアントの力を借りていた部分がかなり大きかった，という話は元記事でも触れられているのでここでは深く触れない．
今日はそれのついでに，最近twitterについて思っていたことの話をする．
最近嫌いなのは「不在中のできごと」というアレ
最近，Web版のtwitterに入ると，「不在中のできごと」というのがツイートの最上部に表示されている．
内部のアルゴリズムについては不明だが，これは俺がtwitterを見ていなかったときの誰かのツイートをサジェストしてくれている．
こんな機能はいらない．
というか，これはtwitterというサービスにとって邪魔でしかない．
フロー情報とストック情報
twitterは，当初短文投稿サービスという位置づけで売り出していた．
twitterが画期的だったのは，過去のツイートが参照できなくなるという仕様だった．
twitterは過去3000件を超えるツイートが取得できなかった．
これが技術的な限界だったのか，それとも仕様によるものだったのかは，俺は知らない．
ただし，使う人にとっては，これがtwitterの使い方として定着した．
即ち，流れてくる情報にのみ気を使い，過去の情報については触れない．
そういう意味で，twitterはことごとくフロー情報にのみ注目している．
地震などがいい例で，地震が発生するとまっさきにtwitterで検知できる．
みんなが地震のことをつぶやいていて，すぐに震源地情報まで発覚する．
だけれど，じゃぁ一ヶ月前に起こった地震の情報をtwitterで検索しようと思うと，それは至難の業だ．
というか，やろうとする人もいないと思う．
フロー情報を循環させる仕組み
それだけでは，情報はただ流れていくだけで，情報の間に優位付がなされない．
そこでRTというものが登場する．
RTは，面白いと思った発言を，自分のタイムラインに載せることができる．
これにより，フロー情報として一度流れ去ってしまったものを，再びフロー情報として流し直すことができる．
これがうまく機能していれば，ストック情報は必要なくなる．
twitterというサービスにとって，重要な情報は，RTされてひたすらフローの循環を繰り返す．
情報がストックとなることがない．
twitterにおいて，Fav以外の機能はほとんどフロー情報を扱うものでしかない．
これが俺にはtwitterの基本理念として，心地いいものに感じる．
そういうフローの中にいるからこそ，この世界のコミュ障ヒキコモリどもがここまで活性化するんじゃないか．
明らかにフロー情報でないものをフロー情報と一緒に出すな
RTという文化，Userstreamの開放，そういったtwitterの流れはひたすらフロー情報を循環させることを目的としてきたように思う．
「バルスに耐える」というような逸話も，あんなつぶやきに意味などない．ストックする必要があるものなど何一つない．
単に，瞬間的なフローの増大に耐えるプライドの戦いに見えた．
それに対して，「不在中のできごと」とは何事か．
Facebook気取りなのか．
フロー情報の一番上に，ストック情報を流すとはどういう神経をしているのか．
ストック情報的な機能というだけの話ではない，それらを混ぜあわせて表示しているところに，プライドはないのかと問いたい．
はっきり言って，ゴミが付随しているようにしか感じられなかった．
ストックの必要性と外部化
従来より，twitterはその基本理念と思えるフローの循環化には熱心に取り組んでいたと思う．
反面，Fav以外のストック方法を持たなかった．
twitterを流れるフロー情報のストック化は，ひたすら外部のサービスに任されていた．
twilogなどが代表的だ．
もちろん，それがtwitter社が巻き取れる利益と捉えているのかもしれない．
でも，だとするなら別のものとしてやれば良い．
サービスの基本理念を曲げてまでやるものなどない．
あくまでtwitterというサービスはフロー情報にこそ価値を置いて欲しかった．
そもそもストックする必要がある情報はtwitterには少ない．
もちろん有益な情報も流れてくるのだが，たいていは別のソースによってWeb上に存在するものが多い．
だからこそ，ストックは外部化する程度で事足りていた．
これはおそらく車の両輪で，フローしか扱わないからこそ，それに見合ったしょうもないつぶやきが多く，それによってユーザーが多く面白いフローができている．
これを無理やりストック化しようとしても，しょうもないつぶやきがストックされるだけで，ストックを必要とする人にとっては無意味だ．
そしてフローを必要とする人にとっては，ストック化されることによりフローがつまらなくなっていく．
作らないという選択
前々からいろいろなところで見聞きしていて，すごく重要だと思うことがある．
俺がWebサービスを作るのを趣味でやっていたり，仕事でやっているからWebサービスに話を限定させてもらうが……
「これはやらない」
ということを決めることは非常に重要なことなんだ．
サービスの基本理念に背くような追加機能は，たとえそれで一時的にユーザーが喜びそうな予感がしても，作ってはいけない．
せっかくtwitterというサービスが，フローという新しい情報の流し方を提示していたのに，その理念に真っ向から反対するような機能は，（便利と思うユーザーがいたとしても）作るべきではなかった．
それによってtwitterというものが壊れることに気づいていないのか．
だったらFacebook見ればいいじゃん．
だったらTumblr見ればいいじゃん．
しばしば，エンジニアとしてはこういうものを考えないといけない．
twitterの「不在中のできごと」にしたって，中身のアルゴリズムを実装しようと思ったら相当エキサイティングだ．
いろいろな方法が考えられるし，試行錯誤のやりがいがあるのは，非常に同感する．
エンジニアリングとしてかなり面白い課題なのは理解する．
だけど，それはサービスに載せるべきものなのかは，たとえエンジニアであっても考える必要がある．と思う．
ましてやユーザーにもエンジニアが多く，会社もエンジニアが主体になることが多いWeb系の会社なら，なおさらだ．
エンジニアが考えなければ，誰が考えるというのか.
