自分は Twitter や Facebook などのソーシャルメディアが好きではないが、これらが発明した良いアイデアには目を向けたほうが良いと最近は心を改めた。

Twitter の良さ: 文章は可能なら短い方が良いと示したこと。そして短い文章を映えさせるためにコンテンツ本体以外の装飾を取り払ったこと。

Twitter 以前は、文章は長い方がエラかった。これは単純化しすぎた主張だが、長い文章を書いたり読んだりする方が偉い風潮は少なくとも一部にはあった。今やオンラインでそういう立場を取る人はマイノリティになった。これは Twitter だけの功績ではないかもしれないけれど、果たした役割は大きいと思う。

長い文章はしばしば読むよりも書くほうがラクなので、短い文章は書き手の負担が大きい。コンテンツが希少な時代は書き手に権威があったので長文を書き散らすことができたが、コンテンツ過剰な現代は書き手がエラそうにせずがんばって短い文章を書くのは正しい。

ブログなど Twitter 以前のメディアで短い文章が輝くのは難しかった。それはタイトルやら広告やらコメントやらメタデータやら、コンテンツのまわりの装飾が邪魔だったからだと思う。Twitter はそれを取り払い、かつ複数の tweet をタイムラインという単位にパッケージすることで一つ一つの短い文章を読む敷居を下げた。

短さの強制やコンテンツの混合には明らかな欠点もある。けれど短さの価値をシステムやデザインの力で示したのは偉い。

Facebook の良さ: 子供の写真を家族や友達にシェアする簡単な方法を作ったこと。

Twitter と違って自分は Facebook にサービス特有の良さを見出していない。でも数あるソーシャルメディアの中でちゃんと人を集めて動き続けたのはエラかった。知り合いのオンライン至上主義者の中には子供写真のシェアを毛嫌いする人もいるし、行き過ぎを嘆く人もいる。けれど自分はそこにしか FB の価値を感じていない。

GitHub の良さ。

GitHub は "ソーシャル・コーディング" によってオープンソースの敷居を下げ人気を博したが、ソーシャル部分の行き過ぎによる弊害は出始めているし、ソーシャルメディアと同じく問題への反発は少しずつ目立ち始めるだろう。

がそれはさておき GitHub にはソーシャルとは直接関係ないコードホスティングやバグトラッカーとしての出来の良さもあり、その美点は讃えたい。

ひとつめはコードブラウザ上で README.md を index.html として表示するようにしたこと。これによってソフトウェア開発における documentation の問題の半分くらいは解決したんじゃないか。

２つめは issue tracker や commit message で Markdown を使えるようにしたこと。バグレポートはともかく issue tracker でタスク管理をしようと思うと計画なり設計なりを書き出して議論したくなるが、GitHub でない世界すなわち職場ではいちいち Google Docs とかに書く羽目になる。

Issue にしろ comit log にしろ README にしろ、主題の近くに文書を置ける効能は大きい。Github 独自の Markdown 拡張にある checkbox などを見るにつけ、Living document としてのこうしたテキスト群の力をわかってるなと感心する。

ある製品の発明したアイデアを製品自体から切り離して考えると、そうした製品の外でもアイデアを再現できるかもしれない。自分の fragments は Twitter のもつ短文的な良さをブログに持ってこれないかという試みだし、仕事でもディレクトリ単位で README を書いたり bug tracker の文章部分を詳しく書いたり書き換えてアップデートしたり GitHub ぽく振る舞うことで Google Docs への依存を減らそうとしている。こういう「移植作業」は滑稽だけれど、なにも無いよりは良い。