16世紀から17世紀にかけてのイングランドの哲学者であるFrancis Baconは:
人間の知識と力は一致する、というのも、原因を知らなければ、結果を生み出すこともできないからだ。
という言葉を著書"ノヴム・オルガヌム"に残した。
私、斉藤祐也(@cssradar)はすでにご存じの方も多いかもしれないが、情報を収集しニュースを書くための学問であるジャーナリズムを専攻し、巡り巡って現在はフロントエンド開発者をしている。
そんな私にとって情報は何にも増して重要なツールの1つだ。
この記事では前段を踏まえて、私がある特定のグループにのみ展開している、とある"レコメンドAPI"の仕組みについて考察していこうと思う。
なお本記事はFrontrend Advent Calendar 2013の15日目への寄稿です。
このとある"レコメンドAPI"はある特定グループに属するメンバーからの発言にたいして、関連する情報が記載されているURLを提供する。
対象者の発言には質問はもちろん、対象者が読んでいるURLも含まれる。
基本的にはフロントエンド開発に関わるトピックについてがこのAPIの対象範囲となる。
プル型のAPIを基本としているが、稀にプッシュ型のような振る舞いをすることもある。
対象者がAPIにクエリを投げた覚えはないのに、勝手に結果がかえって来たりするようなこともできるので、この後の段で見て行くデータ入力に利用しているツールがクエリ監視ツールとしての機能にも昇華しているようだ。
ちなみにこのAPIが外部公開される予定は現時点では一切ない。
- フィード: Google Readerがサービスを終えてもフィードは情報収集のコアを担う
- Twitter: フィードの代替としてのTwitterという利用もあるが、生々しいオピニオンを得られる希有なメディアとしても見ている
- * Weekly: スターをつける必要があるほどウィークリーで配信されている開発系のメールマガジンからも多くの情報を得られる。(azuさんが運用しているMeta Weeklyを参考にどうぞ)
- ポッドキャスト: 即時性は弱いがオピニオンや開発などの背景などの情報を得られる点で有用
- 動画 / スライド: カンファレンスやスクリーンキャストなど多くの動画、あるいはスライドの情報はケーススタディやあるトピックに対する総括の意味合いが強く欠かすことができないデータとなっている。
上記に加えて、Hacker NewsとEcho JSも巡回先となっている。両者ともバイアスがないように最新順のみを読み込みの対象としている。
データ入力ポイントが多い場合に、1) どの情報を格納するか、2) そしてその情報をいかに少ないステップで格納できるかの2点も重要だ。
-
について抽象的な表現を恐れずに言うとしたらコンテキストを意識しつづけることがポイントだろう。
この、とある"レコメンドAPI"に関していうとそのコンテキストは時期によってフォーカスが変わっていく。この"API"ではフロントエンド開発に関わる情報を限定的に扱っているが、フロントエンド開発というトピックそのものもなかなかどうして広大なエリアを守備範囲としているため、時期に応じて、そのエリアの中でもどの部分を重点的に守るかを少しずつシフトしている。野球について完全な素人なので間違えた表現かも知れないが、打者によって守備の配置を変更するのと似ているかもしれない。 -
に関しては大抵はツールで解決できる問題だ。Evernote(や類似サービス)やブックマークサービスなどがそのツールの筆頭となる。
この"API"ではPinboardを採用した。
ツール選定の際には入力より情報の呼び出しと編集の容易さを優先したほうがいいだろう。
情報を扱う上で注意する点は入力や格納よりもデータをどう取り出すかにある。
本"API"が処理できるタイプのクエリは非常に緩やかなものもあるため、データを格納する際にデータに対して多くの属性を持たせている。
あくまでも一例ではあるがJavaScriptやCSSのような言語属性や、architectureやunit-testのようなトピック属性、情報が誰/どこから発信されたかのような属性がある。
"API"に期待される振る舞いから、それらの属性は単体でも利用できるように、かつ複合してフィルタリングを行えるようにしておく必要がある。web2.0という懐かしい時代の言葉を借りればタグとよばれる概念と近い。
この"API"の強みの1つにデータベースに格納されていない情報を検索してきてくれる点も明記しておこう。
しかし検索から得られる情報にはデータベースにあるような属性が振られていない。そのため検索時にはデータベースの情報から、情報が誰/どこから発せられたかという属性を使ってフィルタをかけている。
2005年にSteve Jobsが米スタンフォード大学の卒業式で行ったスピーチにこんな言葉がある:
将来をあらかじめ見据えて、点と点をつなぎあわせることなどできない。できるのは、後からつなぎ合わせることだ。
データベースに格納されていく情報はあくまでもその"点"に過ぎない。それら"点"をつなぎ合わせやすくするための属性を与えてはいるが、それでもやはり"点"が線を紡ぐのには十分ではない。
そこで"API"の振る舞いとして情報の即時性の優先順位をさげるようにしている。
ジャーナリズムの世界において最重要とされることが多い即時性を犠牲することで賛成/反対意見という情報を加味しやすく、そして、データ格納の段に書いたコンテキストに肉付けすることができるようになる。
例として、Jake Archibaldが2013年6月に書いた"Progressive enhancement is still important"という記事は、Tom Daleが同年9月に書いた"Progressive Enhancement: Zed’s Dead, Baby"に弱い関連性を持っている。弱さは時期的な部分だけで、トピックとしては"Progressive Enhancement"について、前者は改めて重要性を説いていて、後者は反対の視点を説いている。
そしてこのTom Daleの記事は直接的にDan Mallによる"Sigh, JavaScript"プロジェクトと関連し、Dan MallはTom Daleの記事に対して"Progressive Enhancement. Still Alive & Kickin’"で反論を受けた自身のプロジェクトの背景を詳しく語っている。
この"Progressive Enhancement"についての議論の開始点はJake Archibaldではなく、Nicholas Zakasによる"Enough with the JavaScript already!"だろうし、この議論の(少なくとも一旦の)、収束はTom Daleによる、Dan Mallへの返答記事である"Maybe Progressive Enhancement is the Wrong Term"だろう。
このような長期にわたるタイムラインでも情報には関連性がある。
Steve Jobsの発言にある"点"のコンテキストのレベルとは少し違うが、情報を"点"として捉えておくという振る舞い、言い換えれば、過去に戻って関連性を探る振る舞いは"レコメンド API"としての有用性を高める結果になっていると考えている。
最前で書いたフランシス・ベーコンが示す"知識"とは何かを理解するために、もう1つ引用を紹介したい:
情報は知識ではなく、知識は知恵ではない。
SF作家であり、"未来学者"とすら言われることもある、アーサー・C・クラークは上記のような言葉を残している。
情報を求める余りに知識に昇華させるために必要なステップをおろそかにしてはならない。
前段で書いたように"即時性"だけが情報の有用性を高めるわけではない。
仮にこの"API"が情報収集を7日間止めていたとしても、これまでの積み重ねからその7日間の空白を埋めるのにはそれほど時間は掛からないだろう。
この"積み重ね"こそが知識を形成する"何か"の1部だと考えている。
この"API"はまだまだ"情報"を効率的に提供することしかできてはいない。さらなる改善を進め"知識"を提供するためにどんな手立てがあるかを考える余地はまだまだある。
先日、南アフリカで同国初の黒人大統領となり、ノーベル平和賞も受賞したネルソン・マンデラ氏が亡くなった。
氏の冥福を祈ると共に氏の言葉を紹介して本稿を終わりたい:
成功するために大切なのは、どこから始めるのかではなく、どれだけ高く目標を定めるかである。