半構造
最初に半構造という言葉について。
半構造というのは、完全には構造化されない構造です。
構造化というのは、事前にデータの形式がどのようになるか決められているような構造です。半構造は、ある程度の構造を事前に決めておき、構造を決めない部分を残すような構造です。
構造化データとしてわかりやすいのはCSVで、各行ごとにデータがあって、カンマで区切られた項目は何番目がどのようなものになるかといったことが事前に完全に決められています。
半構造データとして代表的なのはスキーマなしのXMLで、タグの書式やツリー構造ができることはきまっているけれども、どのようなタグが入るかは決められいません。
一般のテキストデータのように、まったくデータ構造がきまっていないものは無構造ということになります。
Google+の構造
Google+の場合は、ユーザーはいくつかのサークルを持ち、そこに他のユーザーを追加します。
サークルごとに「共有」のストリームがあり、ここにはサークルに追加してあるユーザーが「共有」したもののうち、自分に見る権限があるものがならんでいきます。権限は投稿者が「共有」ごとに「サークル」単位で決めます。「共有」にはテキストや画像、リンク、再共有などいくつかの形式があり、それぞれ決まった表示のされかたをします。
そしてそれぞれの「共有」には「コメント」のリストがあるという構造になっています。コメントには権限の設定もなく、元になった「共有」が表示されるときすべてのコメントも表示されます。(表示が省略されることはあります)
やりとりは、基本的にはここで行われます。
「再共有」もひとつの独立した「共有」となって、もとの「共有」とは別の「コメント」リストをもつというのは面白いところ。
Googe+での投稿はこのように、いまのところ強く構造化されています。
Twitterの構造
Twitterの場合は、ユーザーは、メインのタイムラインがひとつと「リスト」*1のタイムラインを複数もち、それぞれのタイムラインにユーザーをフォローしていきます。基本的にメインも「リスト」もタイムラインの機能としては同様でツイートのリストになります。
これとは独立してメンションのタイムラインがあり、これは自分のIDが含まれたツイートのリストになります。ここに格納されるツイートはタイムラインのフォローとは関係なく、自分のIDが含まれたすべてのユーザーのツイートが表示されます。メンションのタイムラインの内容は、メインのタイムラインにも流れます。
ツイートには返信先のツイートをひとつ「リプライ先」として指定することができます。ひとつのツイートは複数のツイートから「リプライ先」として指定されることがあります。また、未来のツイートを「リプライ先」として指定することはできないので、この「リプライ先」でつながったツイートは全体としてはツリー構造になります。ただ、この構造をツリーとして表示するインタフェースは標準では用意されていません。
「リプライ先」のついた投稿は、リプライ元・リプライ先それぞれのツイートのユーザー両方を含むタイムラインにだけ格納されて表示されます。「リプライ先」がついていなくても、ユーザーIDで始まるツイートは、そのユーザーと投稿者の両方をフォローしているタイムラインのみに表示されます。この仕様によって、タイムライン上で知らない人相手のやりとりが目につくということがなくなります。
ツイートの表示権限はユーザー単位で、プロテクテッドと指定しているユーザーのツイートは、メインタイムラインでフォローしたときに許可を得ると表示されるようになります。またユーザーをブロックすることメンションのタイムラインに入らないようにできます。
ツイートのほかにユーザーはリツイートとして他のユーザーのツイートへのリンクを投稿することができます。リツイートはリツイートしたユーザーをフォローしているメインタイムラインに格納されます。
ユーザーごとにリツイートを表示するかどうか指定することができます。
このように、Twitterの投稿もほぼ構造化されています。「ほぼ」とつくのが半構造です。
また、こうやって並べてみると、TwitterのほうがGoogle+に比べて投稿の構造は複雑であることがわかります。
Twitterの半構造性
ところで、Twitterの半構造性はどこにあるでしょうか。
まずあげられるのが、投稿に付随するデータです。Twitterでは、ツイートとして投稿できるのはテキストデータだけです(位置情報もつけれますが)。画像や動画などのデータは、他のサービスにアップしたもののリンクの形で埋め込むことになります。これをそれぞれのクライアントが解釈して適切に表示します。
そのため、Twitterでは、リンクが140文字におさまれば、なんでも、いくつでもひとつの投稿に添付することができます。ただし、表示は利用しているクライアントで異なります。クライアントで対応していないデータはただのリンクとして表示されます。
そしてもうひとつ、メンションのタイムラインです。このメンションのタイムラインの挙動がTwitterのコミュニケーションの特性を形成しているといえます。
ほとんどの場合は、ひとつのツイートにひとつのIDだけが含まれており、１対１のやりとりに利用されます。
面白いのは、ひとつのツイートに複数のIDが含まれる場合です。複数人でのやりとりに使われるわけですが、ここでさまざまな使い方が見られます。
たとえば、先頭に２人以上のIDをつけて、３人以上でのやりとりを行う場合です。先頭に発言先のIDをつけて、やりとりに参加しているほかのユーザーのIDは後ろにつけるという書き方も見られます。新しくやりとりに加わる人がいれば、その人のIDも付け加えられていきます。このとき、やりとりの内容の対象がしぼられてきた場合、関係ないと思われるユーザーのIDは含まれなくなっていきます。そこで、「ちょっと参加した議論が、論点かわって自分の興味とは外れてきたけどずっとタイムラインに流れ続ける」ということが少なくなります。
ここで、やりとりに参加するユーザーにはフォロー関係がなくてもよく、そのやりとりのための一過性のグループができあがります。
他にも、返信対象のツイート全体をコピーして、ユーザーIDをつけ、自分の返信を付け加えるといった、非公式RTも使われます。この非公式RTを連鎖させると、一連のやりとりがひとつのツイートだけでわかるようになります。ただ、自分がフォローしていない人とのやりとりが見えたり、同じ発言が何度もタイムラインに流れるために、非公式RTを嫌う人もいます。
これらのようにシステムでは用意されていないやりとりの構造が、半構造だといえます。
コミュニケーションを完全に構造化することはできない
現実のコミュニケーションのネットワーク構造を完全に定義することは不可能で、定義を行うときはデフォルメされたものになります。デフォルメした際の差異は、なんらかの方法で解消する必要があります。また、このネットワーク構造は、短い期間であればある程度静的な構造になりますが、もっと長い目でみれば動的に変化していきます。
そのため、現実のコミュニケーションのネットワークを写像するSNSにも、ユーザーによる使い方の余地を残したアドホックな構造が必要になると思われます。
このユーザーによる使い方の余地というのが、半構造になると思います。
もちろん、まずはうまく構造化することが大切ではあります。
次の世代のSNSでは意識的に半構造を盛り込む必要があるかもしれない
Facebook/Google+でのコミュニケーションは基本的には構造化されており、やりとりの話題が遷移していくとコメントのシステムでは無理がでてくることがあります。
Twitterのコミュニケーションの構造には半構造性があり、このおかげで、うまい感じでやりとりが発生してうまい感じでやりとりの参加者が変わっていき、うまい感じで消えていっているように思います。
ただ、Twitterの半構造性は、運用中の改修の中でうまれたもので、最初から狙っていたわけではありません。
新しくGoogle+という大規模SNSが出たばかりではありますが、その次の世代のSNSの設計では、半構造ネットワークや、ユーザーの行動から自動的に生まれるネットワークなど、アドホックさをいかに明示的に盛り込むかということが大事になるかもしれません。
