webdesignStatioひとまず完成

webdesignStatioへのリンク前回取りあえずプロトタイプを作って晒したwebdesignStatioが、当初描いていたモノが一通り形になったので、これまでの経緯(努力?)を記す。

2ヶ月間稼働させてみた所感
検索対象のタグの種類を増やしたこと、また、収集間隔を3時間から徐々に1時間→30分→最終的に10分間隔まで縮めたことにより、(勝手に)ベンチマークにしている、同種のサイトと同じくらいの収集量に近づいてきた。単純にブログ単位でRSSフィードを購読していたら、決して見つけられないようなブログ記事などに出会うこともできた。
しかし、こういう多種多量のデータを取り扱う仕組みは、動かしてみないと気付かないことが多く、実際多くの気付きが得られた。

  • ページ内容とは全く無関係のタグを付けている(スパムに近い)ソーシャルブックマークにより、アフィリエイトやドロップシッピング、果てにはエロサイトまでが収集されてしまっている
  • 情報を得るためのニュース記事やTIPSではなく、「きれいに作られた」だけの企業サイトやキャンペーンサイトを、ブックマークするという使い方が混じっている
  • ウェブ制作に関わる記事じゃなく、ウェブ制作会社のサイトが混じる。
  • はてブと同じ内容になってしまうと「はてブ読んだ方が早いやん」ってなっちゃうのだが、他のブックマークサイト(特にYahoo、Buzzurlあたり)には結構ノイズが多い

で、その対策として最終的にベイジアンフィルタ(Wikipedia)に落ち着いたのだが、それが「モノになる」までの軌跡がこちら。

  • 収集し記事について、私が「読みたい」か「読みたくない」か全くの主観のみでひたすら分類
  • それらの記事をYahoo!ディベロッパーネットワーク日本語形態素解析にかけて、単語レベルにまで落とし込んで分類
  • さらに迷惑メールの判定に使われるベイジアンフィルタリングのアルゴリズムに分類結果を流し込んで学習させる
  • 気に入った学習結果が得られるまで上記を繰り返し。

その結果、収集総数約8,000ページ、学習ページ1,000ページ、分類キーワード数15,000種にまで膨れ上がってきたあたりで、ようやく納得のいくものになってきた。最後の1ヶ月間は、ひたすらこの学習を繰り返してばかりだった。もうあと組み込むとしたら再学習の手間を軽減させるくらいかな。「重複したりノイズが混じるRSSを読みたくない」というなんともアマノジャクな動機で始めたのに、よくもまぁここまで私のモチベーションが枯れなかったものだ。

要はこれ、何がしたいのかと言うと
当初の趣旨どおり、このサイトは、今でも私自身のための情報収集を目的にすることに全く変わりはない。いや、はっきり言って「みんなの声を取り入れた、みんなのためのサイト」なんかにするつもりは毛頭ない。むしろ「私の趣味趣向」を学習したエージェントが「半自動的」に情報をかき集めてくることに意味が見いだせるものだと思っている。

実は、私自身インターネットを使う時間が長くなるにつれ、「情報に溺れている/踊らされている」感覚がずっと付きまとって、インターネットでの情報収集にモヤモヤしたものを感じていた。ところが、twitterやtumblrで出てきた「follow」という枠組みを知って、このモヤモヤ感が少し整理ができた気がした。

ウェブデザイン関連のブログを書いていらっしゃる方たちは、海外サイトを翻訳されてらっしゃる方が多いのだが、それこそものすごい数の情報を、それぞれのブロガーさんの視点で「選別して」記事にされてらっしゃる。すると、過去の記事の履歴や閲覧体験から、読者が「この人が選ぶニュースなら『チェックしておこう』もしくは『(ネガティブな見方だけれど)時間の無駄にならない』」という、発信者と読者との間での暗黙的な信頼関係が成り立った上に、すんごい数の購読者がいらっしゃる。
つまり、私達を取り巻く情報が多すぎるため、「何を探してきたか」ではなく「誰の目線で探してきたか」という観点から収集する情報を絞り込むことが、今のインターネットでは非常に有用なんだと思い始めている。

ウェブ制作に関するいわゆるTips系の記事だけに限ると、今ではようやく量も速さも個人的には十分満足がいくレベルになってきているし、私自身最近はここからしか情報収集していない。
どなたかが海外サイトの翻訳記事をアップする前に元サイトが収集されてきたりしてるし、日本語のまとめ記事はまとめ記事としてもちろん収集できてる。ブロガーさんの「ブログ書いた」とツイートを発見して30分後にはきちんとこちらでも捕捉できているのを確認して、ひとりニヤニヤするのを毎日続けてきたんやから^^

今まで通り、こいつはいきなりテストでTLが埋まるほどツイートしたりもするし、まだまだ学習されてない予期せぬカテゴリの記事が載っかってくる事もある。私のためだけのツールだけど、一応bit.lyでクリックされた記事の数はモニタしてるし、もしかしたら誰かの役に立ててるかも知れないとも思うので、頑張ってしばらくこいつに私の関心を教え続けていこうと思う。

Posted in 当サイトについて | コメントは受け付けていません。

IT CIRCUS 2010 IN OSAKA に参加してきた

2月17日に大阪で行われた「IT CIRCUS 2010 IN OSAKA」に参加してきた。

講演の詳細は上記リンク先から参照いただくとして、お話を伺って考えたことや感じたことを、少々長くなるが書き留める。

今回のセミナーを通じて何より一番強く感じたのは「なんか、ウェブ制作現場の潮流って、ソフトウェア開発の歴史を辿っているような気がする」ということ。せっかくなので、ソフトウェア開発現場が歩んできた道をウェブ制作現場へ照らし合わせてみたうえで、「今後ウェブデザイナーとして求められるもの」を考えてみたい。

ウェブ制作の歴史は、いわゆる「ウェブ制作会社」が会社として成り立つようになってから、まーせーぜー10年程度だ。
少し前までは、制作担当は、なんでも「ウェブデザイナー」と呼ばれる職種にひとくくりにされ、分業のスタイルも整ってはいなかったが、最近ようやく、コーダーやディレクターなどと呼ばれる、いわゆるシステム開発における、プログラマーやプロジェクトマネージャーに相当する職種が浸透してきている。

実際の制作スタイルを見てみると、森川さんの発表内容にもあったとおりウェブの「標準化」と呼ばれる統一された仕様が求められるようになって、5年ほどたとうか。つまり、以前までは「一人のスーパープレイヤー」さえ居れば金になる時代(「一発芸」と表現されていたもの)だった。そういったスタイルが、徐々に苦しくなってくるのは、制作に必要な要素が徐々に体系化されてきたことでもある。

つまり、仕様が標準化されれば、分業ができる。分業ができれば、個々が専門化する。個々が専門化してくると、それぞれ職種に名前が付く(私達はおそらくイマココ)。という流れの中にあることを押さえておきたい。

んで、この流れにのり、専門家の技量水準評価のために、品質評価リストや公的資格が生まれたりする。そうなれば、顧客の要求も「○○を満たせる人材」「○○の条件をクリアするサイト」といったスキルレベルを明確に要求してくるようになる(スキル・品質の数値化、定量化)。
さらに、分業化が進むと、プロセス(いわゆる仕事の進め方)を標準化しよう、統一しようという話題が持ち上がる。一人のスーパープレイヤーの仕事では発生しえなかった、コミュニケーション・ロスが、分業では当然ボトルネックとなってくる。プロセスが標準化されてくると、それぞれ個々のタスクでの「成果物」もおのずと決まってくる。そうして、ひとまずは、案件の計画から制作完了・リリースまでの一連のタスクリストが、制作者間で共通認識として出来上がる。このあたりのプロセス体系は、PMBOKあたりが標準になっていてウェブディレクションに取り入れているところも多い。

ただし、従来のシステム開発で使われるウォーターフォール・モデルではない。既に「市場の変化のスピードの早さ」をまさにフロントエンドで感じざるをえないウェブ制作においては、PDCAサイクルを工程に組み込んだ、スパイラル・モデルとして制作工程ができつつある。(ISO13407のHCDプロセスもそう。)

別に取り立てて特別に言うことではないし、知っている人からすれば「当たり前」のことなのだろうが、近年のソフトウェア開発の歴史は「市場の変化のスピードの早さ」との闘いである、と言っても過言じゃない。ウェブ制作現場においても、きっと同じ道を歩むことになる。

「市場の変化のスピードの早さ」とは、即ち「仕様変更」の回数が増え頻繁になることである。顧客自身が市場変化を捉えきれず、工程途中で仕様が変わることがどうしても増えてくる。「前工程において、合意を得たものだ」と強く断れば良い?
ふふふ、そうも言えないケースだってあるんだから。もう、何なら「あらゆるものは、フィックスなんてしない」という考えでも良いくらいである。だってそのためのサイクルプロセスなのだから。

では、具体的にウェブ制作として、この静かに忍び寄る避けられない脅威に対してどう身を守るべきか。
他にもあるかも知れないが、私が思うのは「制作物の構造化」である。テンプレート、コンポーネント、ライブラリ、フレームワーク...要は、呼び方はナンだって構わない。つまり、再利用できるものとそうでないものを可能な限り切り分けて、「変更が発生した場合の作業量を最小にする」ことに留意し、またその努力をすべきである、ということである。

実は、プログラム言語において、過去の偉人達が作り上げてきた、関数、構造体、オブジェクト指向などの概念は全て、作ったものを「再利用」しやすく「変更発生時の影響を最小限に食い止める(変更作業量を最小にする)」ためのものである。
同じ話で、スクリプト言語にOOPが必要なのはもちろん、グラフィックソフトでレイヤーが分かれているのも思想は同じ、てかそもそも、HTMLとCSSが分離して策定されたのも、想定される変更頻度が異なる「テキスト」と「スタイル」を可能な限り分離することで、修正時のソースレベルにおけるインパクトを小さくするためのものである。

積極的にフレームワークやライブラリなどを利用するとともに、何らかの設計の際に、少しこんなことを意識することをお勧めしたい。
「今、私が作っているモノは、絶対に後になって変わる。もしくは(私でない)誰かが変える。その時のために何をすべきか。」という意識がカギである。

IT CIRCUS 2010 IN OSAKA

Posted in 雑感 | コメントは受け付けていません。

オメデッタ・アリガッタ

昨晩ふと思いついて、PHP-twitterAPIの勉強がてら、オメデッタと、 アリガッタを作ってみた。
オメデッタ・アリガッタ

twitter上で誰かから誰かへの「おめでとう」と「ありがとう」を検索するだけのものなのだが、どうせ実用性は全く意識してないので、せっかくならポジティブで、見てるだけでなんかハッピーな気持ちになれるものがいいなぁ、と。

せっかくなら、このみんなのポジティブなメッセージかプロフィールアイコンを使って、何かが「作り上げられていく」ようなものをFLASHで見せるとか、
集めた情報をさらに「発信」して、感謝やお祝いの気持ちを増幅いくようなものとか、楽しそうだな。

ほとんど何もしてないけど一応工夫したところなどを。

  • 本文中のに出現する @(ユーザー) の記述が1つだけのものに限定して、「誰かから誰か(1:1)」のメッセージに絞る。(多重RTされたものを排除)
  • 質の高いおめでとう/ありがとう(?)に限定するため、「遅くなりましたが...」というコンテキストを排除するため「遅」の字が入ったメッセージは諦める。
  • おめでとう版とありがとう版をセットで見せて、より「ほっこり感(何それ)」を求める

眺めてたら「教えてくれてありがとう」的な小さなものから、結婚・出産などの大きな「おめでとう」まで垣間見れて、(誰だか知らないんだけど)なんだか微笑ましい。気が向いたらまた手を加えてみようかな。

Posted in 未分類 | コメントは受け付けていません。