僕は小さな頃から、人と話すのは好きでした。特に、自分自身と興味関心が近い人と会話する事が非常に楽しく、時間を忘れて話し込んでしまう事もしばしです。

また、中学生の頃にアマチュア無線をやっていたせいか、10代の頃から年齢が何倍も上の人と話す機会も少なくなく、その時の年齢では得難い知見をたくさんいただきました。

しかし、この1年で気づいた事がありました。自分から話を振る事はあっても、人から話を引き出すのはあまりうまくない、と。

■直接の会話ではどうも解決しない

人の話をなぜ引き出せないのか。振り返りますと、僕は話し出すと押しが強く、かつ矢継ぎ早に言葉が出てくるように、はたからは見えるようです。だから、それを上回るペースや、よほど念が体から発せられるような存在感の強い人でない限り、僕には「話は聞いてもらえないだろう」と思われるのです。

最近は、自分の話している事が通じないだろう、というどちらかというと消極的な理由で、あまり話さないようにしています。人の会話は、1割も伝わっていればいいということです。たくさん話したところで自分が想像する程伝わってはいないのです。

しかし、これは自分の話す量を制御するだけであって、相手から話してもらう量が変わる訳ではありません。相手の話を引き出すための手法としては失敗しています。

■プログラム開発を通じて人から話を引き出せる

プログラム開発、そして出来上がったソフトウェアを世に広める行為は、開発者の自己主張であるというのが一般的な見方であります。これは主にWebサービス開発やオープンソースソフトウェア開発に言える事でしょうが、受託開発であっても言われるがままという事はありません。

それと同時に、ソフトウェアを通じて利用者から「意見」「感想」そして「苦情」といったフィードバックが届きます。ソフトウェアはコンピュータやネットワーク上で動く道具ですから、使えばフィードバックが来るのは当然です。

これです、これなら自然と相手から話を引き出せます。これに気づいて以来、僕はプログラムと自分自身の関係を聞かれると「プログラムは世間とのコミュニケーションツール」と捉えるようになりました。

■最近は会話が減った

最近、仕事をしていて会話が減りました。いわゆる上流工程のSEをしているので、要求定義を行う上でのステークホルダーとの会話やプログラマとの情報交換はありますが、それは必要最低限のこと。プログラムを書く仕事はもうありません。ですから、自分でプログラムを書く時間を作らなければなりません(※1)。直近では大学院の講義で出たレポートを仕上げる際や、新しい技術を確認するために書く程度です。

しかし、これでは不足している。4年前のシムエントリのように、自分自身でプログラムを書き、ソフトウェアを世に公開しなければならない。最近、そう考えるようになりました。プログラムを書けば、また広く世間の方々から意見をいただけるようになるのではと思うからです。

■ソフトウェア開発は少人数でいい

多くのソフトウェアは、とりあえず書ける人を山ほど集めて取りかかるより、敏腕のプログラマが数人集まってささっと書いてしまうことがうまくいきます。そのような体験をされた方は少なからずいらっしゃるはずです。

僕もSEという仕事をしておきながらあれなのですが、正直な所、自分を含めて少人数でプログラムを書き、商品をリリースするほうが効率も良く、より世間の役に立てるのではないかと考えています。僕がやる事は、人をまとめたり指示する事ではなく、出来上がるソフトウェアの品質に責任を持つ事だと自覚しています。それなら、尚更コスト上の「オーバーヘッド」である管理だけの仕事というのは、無駄な気がしているのです。

これは、ソフトウェア開発のマネジメントを放棄しているのではありません。要求定義をはじめとしたソフトウェア開発として向かうべき方向を定め、必要な知識を獲得し、最終製品を作り上げる責任は、変わらずに負うのです。ソフトウェアを自分自身も書いていれば、そのソフトウェアに対してより深く理解するでしょうし、また多くの人とコミュニケーションが出来るのではという期待があります。プログラマによって関わる工程の幅が変わる、それだけの事です。

それが、僕の考える「普通の開発」です。

※1 プログラムを書く行為は、筋トレと同じで続けていないと知識が腐っていきます。文法やライブラリは見れば思い出せますが、プログラムを書く時の「型」を忘れて行く事で書けなくなるのです。

■お願い

折角ブログパーツを貼付けていただきましたが、こちらを外していただけますでしょうか。外し忘れられている場合は、2011/09/01より『サービス終了』の旨のメッセージのみを出力する予定です。

登録いただいているブログのURI情報は、サービス終了を持って削除されます。改めて削除申請を行っていただく必要はありません。

■背景

端的に申し上げますと、メンテナンスを行う意欲と時間が確保しづらくなったのが背景です。折角使っていただいている方がいるのですが、放置するのもどうかと考えまして、サービス終了を決断しました。

また、現在は Tospy をはじめとした優秀なソーシャルメディア検索エンジンも登場し、その中に類似度の高いブログを抽出する機能があります。そちらの方がリアルタイム性も高く、かつ性能も上です。私の開発したツールではとても力が及ぶものではありません。

■最後に

本サービスをご利用、および応援いただいたみなさま、どうもありがとうございました。私自身も、自然言語処理の学習の一環としてこのサービスを提供していましたが、教科書だけでは得られない様々な知識を得ることが出来、非常に有意義でした。

また、何らかしらのサービスを開発した際には、どうぞよろしくお願いします。

■資料の補足

最近、グラフィックボードをベクトル型コンピュータのように活用するGPGPUという言葉が聞かれるようになりました。もともとGPUは3D描画を支援するハードウェアとして、主にゲーマーの方々に普及していました。3Dは単純な繰り返しの計算が非常に多いのですが、これは物理演算や類似検索を行う時も同じ。そこで、 CUDA などのAPIの整備とともにGPUを安価なベクトル型計算機として用いることが盛り上がっているようです。

さて、最近のCPUで100Wを超えるTDPになるものはハイエンドのものばかりですが、GPUはミドルレンジも100W台のTDPであり、結構な電力量と発熱量があります。そのため、ただ単にPCI Expressの拡張スロットに挿そうとしても、すんなり行かないことは珍しくありません。

そこで、私が GPGPU のシステムを構築する際にいろいろ悩んだ部分の一部をLTにまとめて、 GPU はどういうものがあって、サーバはどういう構造がある、だからこういう点に気をつけて機材を選んでみてください！という発表をしてみました。 GPGPU を始めてみたいけど、どういったサーバを用意すればいいのだろうとか、 1U/2U サーバでどうやったら GPU は搭載できるのだろうか検討してみたいという方の力になれば幸いです。

ちなみに、大規模かつハイエンドの GPGPU コンピューティングを行う場合はこの資料では対応しきれないもっとディープな話がたくさんあります。例えば、科学計算のクラスタや、レンダーファームの構築を行う場合は、この内容だけでは対応しきれません。その際、設計する方は、データセンターのファシリティからアプリケーションの実装の癖まで、しっかり垂直統合して考えて行くことが求められます。

■頂いたお話

「 GPGPU のプログラミングができるエンジニアはどれくらいいるのか？」。根本的な問題を指摘されてます…。本格的にやろうとするとバッドノウハウがいろいろありなかなか難しいのですが、 NVIDIA のこの2〜3年くらいに出た GPU (GeForce 9800とかで十分)を搭載したマシンで単に CUDA の API を叩く…例えば自然言語処理でよく用いられる TF/IDF を求める計算を行ったりすると、その威力を身近に感じることができるはずです。また、いい例かは悩みますが『Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances ? stacksmashing.net』も GPGPU を要領よく使った例の一つです。

最近の GPU は、ストリームプロセッサ(計算部分)数が安いものでも 100 個程度、ミドルグレードなら 400 個以上あります。単純比較はできませんが、 Core i5 の同時4スレッドなんてのは「屁でもない」パフォーマンスを叩き出します。取り急ぎ始めてみる場合は、外部電源端子接続不要な GeForce の 1万円台のものをポンと買ってきてちょちょいと取り付けるのが一番手軽だと思います。

■勉強会の様子について

今回はライブドアの伊勢さんによる『インフラエンジニアに一言』がメインセッションでした。インフラに関する特殊な技術を解説するという形ではなく、どちらかというとこの20年くらい、伊勢さんの経歴をなぞりながらテクノロジーがどう遷移しているか、おさらいをするようなセッションだったのが印象的です。3Dの話もあったのですが、その際にレンダーファームの話題もあがっており、LTの際にこんなレベルの話をしていいのかとちょっと悩みました（苦笑）。

LTのセッションは8名もの登壇者がおり、僕は1人目立ったのですが、持ち時間5分ギリギリでした。皆さんも5分を目一杯使って、様々なパフォーマンス（あえてプレゼンとは申しません！）を繰り広げられていました。LTはメインセッション登壇に比べてずいぶんと敷居が低いですし、簡単に登壇申し込みできる場合が多いので、皆さんもぜひ挑戦してみてください。5分に凝縮して話すのは、意外に知恵がいりますよ！

あと、いちびりな方へもう一言。100人に名刺交換をするより、1回のLTのほうが、自分の存在を広く伝えやすいです。

■最後に

はじめての参加でしたが、ハートビーツの皆様に大変お世話になりました。また、セッティングおつかれさまです。どうもありがとうございました。

・Togetter – 「hbstudy#18　「インフラエンジニアに一言」　ライブドア 伊勢 幸一さん」
・Togetter – 「hbstudy#18 LT~懇親会」

■ポイント

今回の発表のポイントは2点あり、ひとつは「HA構成が楽に組める」、もうひとつは「中小企業でも業務別に細かくサーバを立てられる」ことです。

先ず一点目のHAですが、 VMware vSphere をお金を出して買う最大のメリットはここではないかと考えています。シングルサーバで仮想化するなら、今回の本発表で長谷川さんが解説されたKVMをはじめとした様々な無償のものが選択できます。 VMware でさえもハイパーバイザーだけなら無償です。ただ、1台で運用していれば、サーバ本体が故障すると全ての仮想サーバも共倒れです。物理サーバ単独で運用しているより被害が大きくなることさえあるかもしれません。そこを、機材を冗長化することで、再起動こそ挟むもののすぐに業務が復帰できるHA構成を全ての仮想サーバに対して施すことができるのは、管理をしている現場の人間にとってこれほど業務的・精神的に楽なものはありません。

そして僕が最も強くつたえたかったことは、二点目の中小企業におけるプライベートクラウドの可能性についてです。これまで仮想化を売り込むベンダーさんは「大量にあるサーバを少数のサーバにまとめられるからTCO削減できてウマー」を中心に提案されていました(例：『日本HP HP ProLiant VMware 仮想化ソリューション – 導入事例』)。では、サーバ台数が少ない中小企業にメリットはないのかという話になるのですが、探しても事例が余りありませんでした。

中小企業は、ITインフラに投資できるコストも制約され、もし投資できても設置場所や電源確保に苦心することが多々あります。中小企業で、立派なサーバルームが確保できるところってあまり無いと思うんです。サーバ台数が少ないと、必然的に1サーバあたりが支える業務の個数も増えて、ひとたび障害が起きると切り分けは面倒だし、回復するまでそのサーバに乗っかっている…それも障害を起こした業務と関係のない業務まで止めなければならなくなることも珍しくありません。

そこで、小さいながらも社内プライベートクラウドを立ち上げることで、シンプルに業務を切り分けて運用を楽にしようというのが、このシステムの特徴になります。

■書いていないけど話したこと

プログラミングと違い、インフラ整備＝投資であります。ですから、導入計画策定は会社のお財布を管理している経理の人と二人三脚です。減価償却、支払サイト、そして計画の妥当性に対する最後の一押し。この「最後の一押し」が無かったら、こうして発表できる状況になっていなかったのかもしれないのです。本計画に協力してくれた経理の先輩(女性)に大変感謝しています。

インフラ仕事は、自分の上長に説明することはもちろんですが、会社全体を巻き込んで物事を進めることなのだということをを忘れてはなりません。特に、中小企業であれば、全員の顔が見える訳ですから。

■頂いたお話

一番大きかったのは、「ディスク11発は大丈夫？」ということです。ディスクの寿命は大体同じ時期に来るのですが、故障すると次々とまとめて落っこちるのじゃないかという。これは、スペアを1個は入れて入るものの、導入時に少し不安には思っていました。可能であれば、わざと数本ある時期に入れ替えてみてはどうか、というお話を頂戴しました。予防保守ってやつですね。

■反省点

本発表である @hasegaw さんのKVMのアーキテクチャの話の後だったので、ネタ的に外してなくてよかったです。発表後にいただいた tweet を見て、良かった、と心から思いました。

今後の改善点は2つ。説明が10分で終わらなかった。そして、あまり笑いが取れなかった。ことでしょうか。

今回は早口でしゃべりすぎました（苦笑）。次は笑いが取れるようにがんばります！

■他の発表の感想・メモ

@hasegaw さん

• AMDとIntelの互換性の問題について
  Xenだと、CPU依存の命令のマスクが可能。VMwareでもできるかも(今度調べます)。こうすれば移行時に動かないってことは回避できる。実はAMDからIntelに動かした時に動かなくてはまったことがあったのです。
• Nehalem 未満ならXen それ以降ならXenでもKVMでも
  VMWareは歴史が長いので、CPUID別に細かく仮想化の制御方法を切り替えていて、それぞれカリカリにチューンしてある。

@kazunori_279 さん

• Google Apps Engine のチャネルAPI … Google waveでできたことを自分の手元でできて面白そう！
• Googleのスケーラビリティが高度に洗練された環境でできるところがポイント。

@toshiak_netmark さん

• 一眼レフデジカメの話は、一家言ありそうな人が周りに一杯いてウケたw もちろん僕も。
• KVM 夏の怪談（トラブル事例）が興味深い。ハードリンクで逃げる方法は覚えておく。

■おまけ

グループライド練習会で何度かお会いしたことがある人に、はじめてヘルメットなしでお会いしました。最初、お互い誰かはっきりわからなかったのは、ちょっとした笑い話。今回も、 @key3 さんつてでこの催しを知って参加しました。そして、初めての参加なのにLTの機会を設けていただいた幹事の @haru860 さんにとても感謝しています。

発表に拍手を送っていただいた皆様、その後の懇親会でご一緒させていただいた皆様、どうもありがとうございました。またよろしくお願いします。

・Togetter – 「BPStudy#38」 – twitterでの当日の模様

■更新が1日2回になりました

これまで、更新は午前2:00からの1日1回のクロールのみでしたが、10月18日(月)より1日2回体制に変更しました。更新時刻は、2:30と16:30となります。クロール完了から類似ブログ計算まで4〜5時間を要しますので、実際に反映されるのはその計算後となります。この点は変更ありません。

これは、クロールおよび計算を行うサーバを自宅サーバから外部のVPSに移設したことによるものです。

今後は、クロール回数の増加、および計算をすべて行わずずリクエストベースで行う形に変更し、より素早く反映できるようにしようかと考えております。気が向いたらやります。

【おまけ】

・なぜ2:30と16:30なのか

まず、グラフをご覧ください。

これは、シムエントリのサーバに蓄積されているブログ記事が更新された時刻のみを抽出したものです。縦軸が記事数、横軸が時刻(時)です。これを見たところ、1〜2時頃に1回目の落ち込み、16〜17時頃に2回目の落ち込みがあります。

1回目を2:30にしているのは、この時間は1:00頃に計算しても結果が出る6時頃は見ていただける方が少なくわざと遅らせて7時頃の反映を狙っていること、そして16:30はちょうど落ち込んだところを狙いつつ21:00頃のピークタイムに反映されている状況を見てもらいやすいようにしたためです。

・VPS移行のメリット

家で使っているマシンよりも最近のVPSのほうがいいマシンであること、そして電気代が下がることであります。

RSSフィードの登録受付も引き続き行っております。下記からどうぞ。

http://se.koemu.com/

■ブログパーツの枠に独自のCSSクラスを定義できるようになりました

これまでは類似記事一覧部分に対して、ユーザ独自のCSSファイルが定義できておりましたが、それを枠を表示するIFRAME部分にも適用を拡大いたしました。より、ご自身のブログに合わせたデザインを適用できるようになります。ぜひお試しください。

適用方法は次の通りです。

<!-- Sim entries -->
<script charset="utf-8" src="http://se.koemu.com/js/sim-entries.js" type="text/javascript"></script>
<script type="text/javascript">writeSimilarList( EntryURI, [CSS URI], [CSS CLASS] );</script>
<!?? / Sim entries ??>

• CSS URI: 類似記事一覧のCSSファイルを定義します。以前から存在したオプションです。
• CSS CLASS: ブログパーツ枠を表示するIFRAMEタグのCSSクラス名を定義します。新オプションです。

気をつけていただきたいのが、”CSS CLASS“で定義するIFRAME部分のクラス名はご自身のブログ側で定義しているCSSが適用されるため、ブログ側のCSSについても編集をお願いいたします。

本機能の実装にあたっては、 @photo_pierre さんにご協力をいただきました。この場を借りて御礼申し上げます。ありがとうございました。

RSSフィードの登録受付も引き続き行っております。下記からどうぞ。
http://se.koemu.com/

■抽出対象エントリを60日以内に絞りました

類似エントリとして抽出される対象の記事を、計算実行日から60日以内に絞りました。これは、あまりに古い記事が出ますと記事の「鮮度」が低く、計算上類似度が高かったとしても価値ある情報として使いづらいのでは、と言う判断からです。

なお、基準となる記事については、RSSフィードにさえ届いていれば60日を過ぎても類似度を計算します。すなわち、2009年10月に書いた記事の類似エントリは直近60日以内に書かれたエントリがピックアップされます。

■広告を除外する仕組みを改善しました

今までも広告フィードを除外する仕組みを導入しておりましたが、最近新しい形式が登場しておりましたのでそれも対象となるようにしました。もし、新しい形式の広告が載ってしまうようでしたら、どのような記事かURIを教えていただけますと助かります。

■追伸

引き続きRSSの登録も受付中です→シムエントリ トップページからどうぞ。

【おまけ】

60日以内と決めるにあたり、現在シムエントリのバッチサーバが蓄えている期間別データ割合を調査してみました。

30日以内 56.3%
45日以内 61.1%
60日以内 64.4%
90日以内 69.1%

上記より、データベースの3分の2程度がカバーできる日を探しまして、結論を60日としました。

パワーポイントは概要のみで、多くをホワイトボードと質疑応答で話を進めましたので、こちらに補足を書きます。

■概要

これまで、インデックスを使った投資を行うにあたっては、取引所などが定義した『業種分類』や、ファンドマネージャをはじめとしたプロフェッショナルの知識・経験・そして勘でインデックスが作成されていました。また、インデックスを作成したとしても、この動きが激しい世界では企業間の関係は刻々と変化します。

そこで、定性的でありつつも企業の特徴を垣間みることができる「有価証券報告書」や「決算短信」を用い、これらを自然言語処理の技術を用いて定量化することで、企業のつながりを分析できるか否かの実験を行いました。企業分析では、あまり例がない方法であります。

■実験手順

実験は、次の手順で行いました。すべてコマンドラインベースで動作しています。プレゼン中は、技術者以外の方にもわかるようベクトルの「なす角」(cosの意味を理解するために必要)についてあわせて解説しています。

1. やのしんさん開発のAPIを通じ、東証1部上場企業の2009年度中間決算短信（以下、短信）PDFをダウンロード。
   このAPIを使うことで、データの取得の自動化が可能になりました。
2. 短信PDFをテキストファイルへ変換。
   その後に本文を解析しやすくするための準備となります。
3. 各企業の短信の本文を分かち書き。
   日本語は英語と違い単語の区切りがないため、専用のツールで単語ごとに「分かち書き」と言う処理が必要になります。
4. 分かち書きした各企業の短信のTF、および全銘柄のIDF、RIDFを算出。
   TF/IDFについては、たつをさんのエントリ『形態素解析と検索APIとTF-IDFでキーワード抽出』が詳しいです。
5. 各企業の短信をすべてつきあわせ、短信間の内容の類似度(cos)を算出。
   実際は7で指定する企業のみ演算すればいいのですが、今回は途中で全cos値を調べたいと思いわざわざすべて計算させました。
6. RIDFを用い、各短信の代表キーワードを算出。
   どんなキーワードがその短信の特徴的な単語で影響を及ぼしやすいものであるのか、わかりやすくするために抽出しました。RIDFについては、当ブログ『【シムエントリ】 代表キーワードによる検索に変わります』をご覧ください。
7. 指定した企業において、cos値が0.5以上の短信を3階層までリンクしていく。
8. リンク結果を図に描画する。

■出力データ（画像へリンク）

このような形で出力しています。紹介している企業はスライドでピックアップしているものです。

• 9501: 東京電?
  
• 7003: 三井造船
• 1868: 三井ホーム
• 7259: アイシン精機
• 4005: 住友化学
• 4689: ヤフー
• 1959: 九電?
• 8165: 千趣会

■プレゼン中いただいたお話

プレゼン中の質疑応答時間、様々なお話を頂戴しました。

・大量保有報告書や第三者割り当てのレポートを活用できないか
これらの報告をする人たちの中に、キープレーヤーがいます。そのキープレーヤーの動向をテキストマイニングで抽出できれば、より客観的に市場の動きを把握できるのでは、とのことでした。

・IFRSのメジャーカスタマー欄を参考にして取引関係をより緻密にとらえられるかもしれない
テキストマイニングばかりではなく、IFRSをはじめとしたほかのデータソースを用いて相関をよりわかりやすく（どういったつながりなのか）していく方法もある、と教えていただきました。

・XBRLとの掛け合わせについて
それぞれのタクソノミをベクトル化して類似度を測ってみたいと言う話をしたところ、リンクや米国での事例について紹介いただきました。

・一見関連性がないつながりは書いている人が一緒か同じ会社かとかがあるかもしれない

ほかにも、いろいろなご意見を頂戴しました。どうもありがとうございました。

■活用したライブラリ・ツール

多くのツールは、Ubuntuのリポジトリからダウンロードできますので、手軽にインストール可能です。

• Sun VirtualBox
• Ubuntu Linux 8.04.3 LTS Server
• Perl 5.8
• mecab + ipadic
  形態素解析…分かち書きのためのツール
• graphviz
  相関図作成ツール
• xpdf (pdftotext)
  PDF関連ツール （今回はテキスト抽出のみ利用）

■参考図書

• Introduction to Information Retrieval
  以前、勉強会でお世話になった教科書です。洋書ですが、情報検索に必要な知識が一通り学べます。
• 情報検索アルゴリズム
  特に検索部分について解説している教科書です。上記IIR本と一緒にどうぞ。
• ゼロから学ぶ線形代数
  特にドキュメント間の類似度を演算する時に利用しています。数学からしばらく離れてしまっていた場合に役立ちます。

■個人的な目的

自然言語処理と、企業分析。それぞれの分野に置いて、非常に長けた能力を持っている人や前線にたって活躍されている方がいらっしゃいます。しかし、両方を兼ね備えて活躍されている方は、あまり見受けません。正直、自分が今から一つの分野で勝負するには、かなりハードでやりきれる自信はありません。

そして、定量的分析が進んでいる企業分析に置いて、定性的データを分析しているというレポートを、私は今まであまり見たことがありませんでした（前回の勉強会で少し出た程度です）。

今回、発表する題材を決めるにあたり、自分が経験してきた自然言語処理と企業分析というあまり近くなかった分野を絡めて発表することで、何か印象を残すことができればと期待していました。それが、自分ならではのものだと思ったからです。誰かが言っていました。一つの専門の人は数多くいるけど、ある程度の能力でも二つ以上の能力を掛け合わせられる人はなかなかいない、と。

■感想

目的が達せられてよかったです。

掛け合わせると言えば聞こえはいいのですが、常識的ではないことでもありましたので勉強会内で受け入れてもらえるのか、発表まで心配でした。それも、XBRL勉強会と言うのにXBRLの話がほとんどないという…。しかし、企業分析と言うもう一つの部分について興味を持っていただくことができ、とても嬉しく思っています。また、企業の分類にテキストマイニングと言う手法があることも皆さんにお伝えできたのではと考えています。

（体調を崩していて新年会に行けなかったことだけが心残りです）

勉強会に参加されていた皆様、どうもありがとうございました！

■Naive Bayesを採用しました

類似記事算出時、これまでシムエントリに登録されているすべての記事同士で突合せを行っていました(詳細は「【シムエントリ】 代表キーワードによる検索に変わります」)。今回、記事同士の突合せの前にNaive Bayesによる仕分けを行うように変更いたしました。

これにより、検索の方法が次の通りに変わります。

1. 最新のRSSフィードを取得する。
2. 形態素解析を行う。
3. Naive Bayes アルゴリズムを利用し、すべての記事に対してカテゴリ分けを行う。
4. カテゴリ内のすべての記事を突合せ、類似記事を探し出す。

Naive Bayes の詳細については、「ナイーブベイズによるテキスト分類体験アプリ – 睡眠不足？！」にてサンプルと共に解説されています。興味がある方はぜひその動きをご覧ください。

■対象記事が増えます

最新のぽぷるのデータを追加し、抽出される記事の母数が増えております。

「ぽぷる」は、河野さんとその協力者の方が作成されたブログホワイトリストです。シムエントリはこのデータを利用させていただいております。いつもありがとうございます。

■類似記事の変化が発生します

上記の変更により、類似記事の抽出結果の傾向が変わります。

また、Naive Bayes で仕分けを行う際に利用している教師データ(仕分けの元となるデータ)は引き続き編集を行っておりますため、この後も変化が起こる事が考えられます。あらかじめご了承ください。

■追伸

引き続きRSSの登録も受付中です→シムエントリ トップページからどうぞ。

【おまけ】

・Naive Bayes 採用の理由

結論から言うと、計算量を減らすためです。今までですと、1万件の記事を探すために 10,000 * ( 10,000 – 1 ) =?99,990,000 回の計算を行う必要がありました。ここで、たとえば最初に数が均等な10個のカテゴリに分けておくと、 1,000 * ( 1,000 – 1 ) * 10 = 9,990,000 回 となり、約1桁分の計算量を減らせます。その仕分けに、 Naive Bayes が役立ちました(Complement Naive Bayes というのもあります)。しかし、そう簡単に行かない事もわかりました。

・教師データ

Naive Bayers を利用し始めましたが、教師データの選定と分量がうまい事いっておりません。現状ですと、カテゴリを分けるときにグループごとの件数に大きなむらが出てしまっており、先の理屈ほど計算量を落とせていません。このあたり、試行錯誤し続ける必要がありそうです。

ところでtsudaるとは

tsudaる。twitterユーザではおなじみとなった、twitterを通じた実況投稿の通称を指します。これは、ジャーナリストの津田大介氏がシンポジウムの取材を通して発言を実況中継している状況から、その名が付いたようです。

このtsudaる、意外に難しいようです。津田氏はジャーナリストと言うこともあり、書きなれている事や、登壇している人からは距離が離れいることから、状況を淡々と伝えられていらっしゃいます。しかし、その場の「役者」である人や、ほかの人がやると、どうもうまくいかないみたいです。少なくても、うまく行っている状況を見た事がない。

その中に現れたスポーツ実況

スポーツの実況と言えば、古くはAMラジオ、現在ならテレビが定番です。テレビなら、観戦に出向かずとも、その状況を音と画で体感する事ができます。

そんな中、twitterでスポーツの実況をする人が出てきたのです。@tour_sanspoIINA 氏です。

シンポジウムのような「発言」をまとめて投稿する事さえ難しいこの状況下、言葉になっていない”見た状況”を伝えていくという、さらに難しい題材に挑戦したジャーナリストが現れたのです。

AMラジオの厳しさと一体感の再来

AMラジオというと、野球の実況中継と、パーソナリティが独自の世界を展開する番組が主な放送内容であり、今もその流れは変わりません。僕の親の世代は、夜な夜なラジオにかじりついて放送を聴いたとか聴かなかったとか。

twitterで実況をすることは、この二つが合わさった状況…いや、それ以上に難しい状況であると想像されます。

まず、スポーツの実況自体の難しさ。AMの野球中継では、ピッチャーの息遣いや、バッターの気合の乗り方など、見えないものをいかに見えるように伝えるか、アナウンサーの力量が問われます。そして、夜な夜なの番組では、リスナーとパーソナリティとの交流が、番組を盛り上げます。

その2つが、同時に行われるのです。

実況は、話すことよりも難しいのではと想像します。声のトーンも伝わらなければ、そもそもキーボードを打つのが早くないと伝える事さえできません。小説など、ある程度まとまった時間の中で言葉を操る人はこれまでもいましたが、ほんの数秒でそれをこなさなければならない状況を僕は知りません。そして、「交流」です。@? を使った名指しで話しかけられるという、リポートしている本人の今の状況なんて正直関係ない状態で、次々とメッセージが交わされます。そして、答えている。ラジオならディレクターさんがお便りを仕分けてくれるだろうけど、twitterはそれさえもジャーナリスト本人がやらないといけない。

一人で実況できる…けど、その一人に多大なポテンシャルが要求されるのです。

実は僕自身よくわかっていない

いろいろ書いてきましたが、僕自身、目の前で繰り広げられた事を飲み込めていません。これが何を意味していて、そしてこれから何が起きるのか。

ただ、一杯引っ掛けてツールをドンちゃん騒ぎして観戦していた中で、何か新しいことが動いているんだな、という事を感じました。そう、それは車の中でAMラジオをながら聞きするように、コンピュータの仕事をしながらtwitterの実況中継を見ることが普通になりつつある感覚です。

だが、変化はおそらくそういうものなのである。
変化は、つねに人々の目の見えないところで始まっている。
そして、その変化に人々が気づいたとき、すでに次の変化が音もなく足もとに忍び寄っている。
そっと、誰にも気づかれないうちに……

杉山隆男 「メディアの興亡」 下巻 第六部 離陸 P.402

僕らの目の前に、あらゆるものがやってきます。そして、意識的・無意識に関わらず、自分自身でも発信しています。その状況を、僕ら一人一人が感じ、理解を深めていくことが大切なのではないでしょうか。

第4ステージが終わり、あわやランス・アームストロング選手がマイヨ・ジョーヌかとTwitter上では大騒ぎになっております。

そんな中、日本人や日本語でTour情報をTwitterで発信されている方がいらっしゃいます。
ちょっと取りまとめてみましたのでご紹介します。

■選手
@Fumybeppu 別府史之選手 (スキルシマノ所属)

■プレス
@tour_sanspoIINA Sanspo.com & IINAlab … 最も選手に近い日本語tweet
@348 Sascha Boeckle氏 … J SPORTS 実況担当 & インタビュー翻訳
@osamukurimura 栗村 修氏…J SPORTS解説担当 & シマノレーシング所属

■その他
#TdF Tour de France タグ (全言語混載)
英語の情報は「Tour de France 2009: Tour de Twitter」が詳しいです。

あー、僕が7月7日までに調べた時点ではまだまだ少ないですが、ほかに情報をお持ちの方、ぜひ @koemu まで教えてください。加筆します。

Twitterはまずは100人フォローから。今月は観戦ツールとしてどんどん楽しんじゃいましょう。

※更新履歴
7/16 @osamukurimura氏追加

■CSSが指定できるようになりました

本日 2009年3月4日より、シムエントリのエントリ一覧にご自身で定義したCSSをセットできるようにしました。この機能追加により、ブログのテンプレートにあわせた配色を設定することができるようになります。どうぞお試しください。

定義方法は次のとおりです。

<!-- Sim entries -->
<script charset="utf-8" src="http://se.koemu.com/js/sim-entries.js" type="text/javascript"></script>
<script type="text/javascript">writeSimilarList( EntryURI, [CSS URI] );</script>
<!?? / Sim entries ??>

簡単に言うと、writeSimilarListにオプショナルの引数を1つ追加した形になります。
なお、現在シムエントリが利用しているCSSは “http://se.koemu.com/css/simentries.css” になります。

もし、クラス名をこのように指定してほしいなどのご希望がありましたら、コメントいただけましたら幸いです。内容をかんがみまして、できる範囲で改善していきます。

■描画領域を広くしました

Macなど、一部環境で3つ目のエントリの表示がかける問題がありましたので、高さを広めました。
あわせて、シムエントリのデフォルトCSSで適用するフォントを「メイリオ」に変更しています。Windowsの方でメイリオをインストールされている方は、フォントが変わっています。

以上2点は使っている方からいただいたアドバイスを元に組み込みました。どうもありがとうございました。

RSSフィードの登録受付も引き続き行っております。下記からどうぞ。
http://se.koemu.com/

※追伸
IIR輪講 シーズン1 が終わったので、勉強したネタをそろそろ入れ込んでみたいなと思います。主に計算量を減らす方向に持っていくつもりです。

※追伸2
汎用性の高いデフォルトCSS、募集します。採用者の方にはビールを1杯ごちそうします。もしよろしければ作っていただけるとうれしいです。

まとめも兼ねまして、前クォーターに続き2008年最後のクォーターで最もよく読まれた記事をピックアップしてみました。

1. [↑] 寝台特急 はやぶさで東京へ戻ってみた 16.9%
2. [↓] 自転車通勤 クロスバイクで本格スタート！ 15.1%
3. [↓] 一日修理工房 … DELL 2400Cを直す 14.1%
4. [↑] サイクルコンピュータをつけた！＆いろいろ 9.5%
5. [↑] あゝ哀れ 寝台特急はやぶさ 廃止に 5.9%
6. [↓] 自転車 1ヶ月点検‐ワイヤーは伸びる 1.9%
7. [↑] ママチャリのブレーキがボロボロになっていた！ 1.9%
8. [新] ママチャリパワーアップ計画‐まずは手軽に 1.5%
9. [↓] イヤフォンまた断線‐今度はSHUREを買う 1.5%
10. [新] イトーヨーカ堂で流れるあの曲は…？ 1.1%

こんな結果になりました。

ブログ全体のアクセスのトレンドを見たところ、10月ころからアクセス数が徐々に減り、現在はピーク時に比べて30%ほどUUが減ってしまっていることがわかりましたorz… 減りが顕著なのが自転車関連。いろいろ考えてみましたが、これはおそらく『気温』のせいかと思います。寒い中、自転車に乗る人は少ないですものね。

来年も、大量に記事を書くわけではありませんが、じっくりとブログを書いていこうと思います。

本年も当ブログをご愛顧いただきありがとうございました。

■1KB以上のエントリのみを関連記事として表示します

類似記事一覧に表示するエントリを、1KB以上のデータを持つエントリにいたします。
また、1KB未満のエントリは類似記事を表示することはできますが、他のブログの類似記事としては表示されなくなります。
これは、シムエントリが「代表キーワード」を用いて記事を検索している特性上、記事の本文が短い≒用いられる単語が少ない記事が優先して表示されやすい背景があったためです。
※DBを調べたところ、10%程度のエントリが1KB以下のエントリでした。これは、本文引用形式のRSS記事も含みます。

■記事の保存期間を15日に引き延ばします

7月6日より、記事の保存期間を7日設けることで更新が早いブログでも記事が残るようにしておりました。これを、本日より30日に引き延ばします。
これにより、更新が早い(1日1記事以上の)ブログを運営されている方は、以前より記事が残りやすい状況になります。

■記事取得時間が1時間繰り上がります

記事取得の時間を3:00から2:00に1時間繰り上げます。

RSSフィードの登録受付も引き続き行っております。下記からどうぞ。
http://se.koemu.com/

現在、サーバの負荷が高まっており、サーバ運用会社よりページ・サービスへのアクセスが一時的に制限されております。制限時にアクセスしますと “Error 503″ や “混雑中” などと表示されています。

ご利用、ご覧いただいている皆様にはご迷惑をおかけしており、大変恐縮です。

現在、対策を検討しておりますので、結論が出るまでしばらくお待ち下さい。

※追伸 制限中はブログの管理画面も制限されており、お知らせが遅くなりました。

それでは、順位と％です。Google Analyticsのデータをベースに集計しています。

1. [↑] 自転車通勤 クロスバイクで本格スタート！ 21.6%
2. [↓] 一日修理工房 … DELL 2400Cを直す 18.1%
3. [↓] 寝台特急 はやぶさで東京へ戻ってみた 17.6%
4. [新] 自転車 1ヶ月点検‐ワイヤーは伸びる 2.7%
5. [新] Cyber Space Curryboys を食す！ 1.7%
6. [→] イヤフォンまた断線‐今度はSHUREを買う 1.6%
7. [新] あゝ哀れ 寝台特急はやぶさ 廃止に 1.6%
8. [新] サイクルコンピュータをつけた！＆いろいろ 1.6%
9. [↓] エンジンオイル上抜きの技 1.2%
10. [新] ママチャリのブレーキがボロボロになっていた！ 1.2%

いやはや、前回の予想通り『自転車通勤 クロスバイクで本格スタート！』がトップになりました。8月以降もアクセスが伸び続けているページでして、9月にはいってからはそのペースをさらに加速させています。きっと、自転車で走るには最高の季節がやってきたからでしょう。

続いて強いのが『一日修理工房 … DELL 2400Cを直す』です。この機種について、9月末に報道やDELLから次の発表がありました。

■デル、デスクトップPC「Dimension 2400c／4600c」14万台の電源に不具合の可能性 – ITmedia +D PC USER
■Dimension 2400c/4600cをご愛用のお客様へご案内 – デル サポートニュース

簡単に言うと、「火を噴く可能性がある」という問題だそうです。しかし、火を噴くに至る以前の問題で苦情がネットにあふれています。私のブログで、最もコメントが付いているのがこの記事でして、ご他聞にもれず苦情の嵐。
このPCは実家でまだ現役ですので、ちょっとどうしようかと悩んでおります。

あと、ランクインしていてちょっとびっくりしたのが『Cyber Space Curryboys を食す！』。皆さん、カレー食べてますか?

:-p

しっかし、ランキングを見ていると、このブログは『車輪が付いているもののネタばかり』ということが、よくわかります。
この傾向は、この後も変わらないことでしょう?♪

■RSS広告系のエントリを表示しないようにしました
RSSフィードの中に広告が含まれているものがありますが、これを結果に表示しないようにしました。
今回の対応では、
・タイトルの行頭に「PR:」とつくもの
・タイトル内に「スポンサーサイト」とつくもの
の2つが対象となります。今後も対象のものを増やしていく予定です。
もし「これが対象になっていない！」というものがございましたら、コメント欄で指摘いただけますと助かります。

■同じサイトを2回以上表示しないようにしました
記事の関連性があっても、同じサイト(ブログ)が2つ以上列挙されることがありました。
理屈としては間違っていないのですが、「新しいブログを見つけるきっかけ」としてのブログパーツの魅力が少し減ってしまうのではないかと思い、同じサイトを2回以上表示しないようにしました。
そのため、ブログパーツに表示されるサイトは、3つとも違うブログが表示されることになります。

RSSフィードの登録、およびパーツの貼り付けも引き続き行っております。下記からどうぞ。
http://se.koemu.com/

2008年8月12日 8:45 以降に更新された類似記事データより、類似記事がどの記事も1件より多く表示できない状態となっております。
現在、プログラムを修正し、類似度の再計算を行っております。再計算が完了し次第、正常に戻る予定でございます。

ご利用いただいている皆様にはご迷惑をおかけし、恐縮です。

2008年8月13日 1:00
2008年8月11日のデータに戻して、最大3件表示できるように仮復旧しました。再計算は継続して進めており、こちらが完了し次第完全復旧となります。

2008年8月13日 4:00
問題は解消し、現在は正常に稼働しております。

それでは、順位と％です。Google Analyticsのデータをベースに集計しています。

1. 一日修理工房 … DELL 2400Cを直す 32.6%
2. 寝台特急 はやぶさで東京へ戻ってみた 18.4%
3. F905iを買ったっす … 素直な進化に拍手 4.7%
4. 自転車通勤 クロスバイクで本格スタート！ 3.3%
5. ブログを記事で結ぶブログパーツ『シムエントリ』をリリース 1.9%
6. イヤフォンまた断線‐今度はSHUREを買う 1.5%
7. KIMBER 4VSと言うスピーカーケーブルを買う 1.3%
8. エンジンオイル上抜きの技 1.2%
9. 車はローンで買うべきか 一括で買うべきか 0.9%
10. VOLVO C70に試乗してきました 0.9%

目立ってアクセスがあるのが、トップの『一日修理工房 … DELL 2400Cを直す』。リンクをたどっている人と検索エンジンからの到達が半分半分くらいで、なかなか太い導線が確保できているのがわかります。その背景に、このDELL 2400Cは壊れやすく、かつユーザーが多いということが伺えます。しっかし、壊れやすいなんてひどいよなぁ…

4番目の『自転車通勤 クロスバイクで本格スタート！』は、ページを書いてからぐんぐんアクセス数が増えています。ここ3ヶ月に絞ると3番に位置していることもわかっています。会社の女の子に聞くところによると、最近はお笑い芸人さんでも自転車好きな人がいるくらい、自転車の熱が徐々に上がっているとのことです。今後に期待。

上記のランキングからはっきりわかることは、「レポート系のコンテンツはアクセスを伸ばしやすい」ということでしょうか。
日々の出来事をはじめとした日記チックな内容は、どちらかというと常連読者の方々にお伝えする感じになるということが、改めてよくわかりました。

■TFの値にlogを取るように
本日より、記事中の単語毎の語数(出現頻度)(＝TF)と他の値を組み合わせて計算する際、TFの値にlogを取るようにしました。
これにより、類似記事の検索結果が変化いたします。
今までは類似記事を検索する際、単語の数が著しく多いとその多くなった単語に引きずられて検索結果が出る傾向がありました。今回、TFにlogを取るよう になると、単語の数が多さに極端に引きずられないようになり、より興味が深まる記事が探し出しやすくなると期待しております。
※例えば、TF*IDFの計算結果が変化します。

■7日以内に投稿された記事はRSSフィードが途切れた後も対象に
本日から、計算する日から数えて7日以内に投稿された記事については、1度取得するとその後にRSSフィードから外れても類似記事が表示できるようになります。
これまでは、RSSフィードに含まれている記事のみを検索対象としておりました。しかし、1日に数記事以上投稿されるようなとても活発なブログですと、日の浅い記事であってもあっという間に検索対象から外れてしまうという問題がありました。そこで、上記の機能改善を行うことで、できる限り多く、そして鮮度の高い情報がピックアップされやすくなります。
本日2008年7月6日から記事の蓄積を開始していますので、実際にこの機能が最大限の効果を発揮するのは今度の土曜日になります。記事を書き換えた場合は、次回RSS取得時に書き換えた内容が含まれたときに限り、更新されます。
なお、蓄積日数については、システム負荷を鑑みて今後延長も検討しております。

RSSフィードの登録、およびパーツの貼り付けも引き続き行っております。下記からどうぞ。
http://se.koemu.com/

新: 1日1回 AM 3:00 (この時間からRSSの取得を開始します)
旧: 1日4回 6時間毎

理由としまして、自宅で類似エントリの計算を行っているサーバの「電気代」にあります。
前年同月比で電気代が2倍(※1)となっており、家計的に無視できない状況となっております。

そのため、計算終了後はサーバの電源を止め、電気代の高騰を抑える処置をとることといたしました。
個人的な都合で誠に勝手ではございますが、ご理解のほどなにとぞよろしくお願いいたします。

※追伸
資金に余裕が出てきたら、専用サーバでも借りて計算機・回線に余裕を持って今まで以上のサービスを提供できたらと考えています。

※1
電気代が一番少なくなる春、昨年の電気代は3,000円弱でした。しかし、今月は約6,000円となり、サーバ1台が家1軒分の電気を食べていることになります。ちなみに、サーバのCPUはPentium4 521 (2.8GHz)が入っています。

2008年4月14日 2:10 以降に更新された記事につきまして、反映が遅れております。
先ほど、復旧作業を行いまして、2008年4月17日 2:10より更新を再開しております。本日の朝までには正常な更新速度に戻る予定です。

ご利用いただいている皆様にはご迷惑をおかけし、恐縮です。

2008/04/18 問題は解消し、現在は正常に稼働しております。

まずは、こちらのPDFファイルをご覧下さい。
■ニュースリリース： 記事に「関連した話題」でブログを結ぶブログパーツ『シムエントリ』を開発

プレスリリースは、大きく分けて6つの項目に分かれます。
1. タイトル
2. 書き出し
3. 特徴紹介(製品紹介)
4. 開発背景
(必要に応じて)技術解説
5. 開発者紹介
6. 連絡先

プレスリリースを読むのは、送ったメディアの記者と、その先にいるメディアの読者です。
この前提と、先回まとめた3つのポイント『先進性』『独創性』『社会貢献性』を基に、実際に記事を書いてみましょう。

■1. タイトル
「ニュースリリース」であること、そして「どんな製品がリリースされた」か、記者の方に伝えます。
メールで送るばかりでなく、FAXなどの紙の状態で渡ることも考慮しつつ、バシッとタイトルを決めます。

■2. 書き出し
このプレスリリースの要旨となると考えてください。ここが勝負！

私…
(中略)
…「関連した話題」が存在する別の記事にリンクすることができるサービスとなっております。

「誰」が「いつ」「どのような」製品をリリースしたかを端的にまとめ、写真をつけます。
ポイントは写真。必ず1点つけましょう。文だけでなく写真で見えたほうが、記者もイメージをつけてもらいやすいでしょ？それに、この写真が実際に記事へ引用されることもあります(実際にITmedia Newsで引用されました』)。
今回の例は個人のため名前のみですが、会社の場合は『○×株式会社 (代表取締役 ○× △□)』と書くようにします。
あと、製品紹介ページのアドレスを書くのをお忘れなく。

■3. 特徴紹介(製品紹介)
開発した商品が、どのような機能を持ち合わせているかをまとめます。『社会貢献性』の部分が中心になります。

■スタートは簡単
・ブログのRSSフ… (以下略)

このとき、単なる機能一覧にならないようにすることが大切です。この機能を使うことで、製品を使いそうな人へどんなメリットがもたらされるのかを抑えます。
ただ、多くの機能が載っている製品は注意。多くを伝えても、もたらされるメリットの焦点がぼけてしまうと結局どんな製品なのかわかりづらくなります。その場合は利用者を想定して『どこを推すのか』を絞ったほうが安全です。
また、必要に応じてリリース日や利用できる環境(どの携帯の機種で動くか、など)を明記します。

■4. 開発背景
どういう想いをもって開発したかを書きます。『独創性』が表現できる部分です。

現在、日本のブログは「アルファブロガー」…
(中略)
…陰に隠れつつも良質な記事を執筆しているブロガーの方にもチャンスを作りたい。そのような気持ちから当サービスを開発するに至りました。

記者に、ちょっとしたドラマを想像してもらえるようなものならよいのではないでしょうか。勢い余って、あまり長くならないように。

■(必要に応じて)技術解説
先進的な技術や、聞き慣れない特殊そうな技があれば、簡単に解説します。『先進性』押し出します！

『シムエントリ』では、次の技術を…
(中略)
…■関連性の計算 (類似度の計算)
「ベクトル空間モデル」を採用しています。
これは、…(以下略)

ドン引きされない程度の難しいことが書いてあると、ちょっとした製品の価値の高さやありがたみ(?)を醸し出せるかもしれません。
今回は「ベクトル空間モデル」がそれに当たります。専門家が見ればなんてことはないのですが、それ以外の人には「なんかすごそう」というイメージを与えることができた、かも知れません(『[N] ブログを記事単位で結ぶ「シムエントリ」』とか)。
エンジニアにはこの考え方は抵抗があるかもしれませんが、あくまで「インパクト」を与えることが重要であることを忘れないで下さい。エンジニアが技術をわかりやすく語ると、エンジニアではない人はとても親身に聞いてくれるのです。もし、とことん語りたいときは、自身の製品サイトに書いたほうがよいです。

■5. 開発者紹介
会社の場合は、会社概要をまとめます。最低でも…
・会社名
・創業年月
・資本金
・事業内容 (ヒットしたサービスがあれば特に推す)
・公式サイト アドレス
くらいはまとめましょう。
個人の場合は、どういう人が作ったのかイメージできるような自己紹介にしてみてはいかがでしょうか。ブログがあればブログのアドレスも書いておきましょう。

■6. 連絡先
記者の目に特に留まった場合、連絡が来ることがあります。
会社の場合、必ず担当者の部署・氏名を明記の上、存在するすべての窓口の連絡先を書きます。
個人の場合は、日中は別の仕事をしている人も少なくないと思いますので、通常使うメールアドレスと日中連絡がつく連絡先を書いておくことになるかと思います。
では、実際連絡が来たときは……また別のノウハウが必要になりますが、話が逸れてしまうので今回は割愛します。

■その他
自社や他社の商標名が出た場合は、その旨を記載したほうが間違いありません。

いかがでしたでしょうか。
フォーマット自体は、とっても簡単です。
全部まとめると、たいてい1?3ページになります。
多くのプレスリリースを読む記者の状況を察して、多すぎない分量にするのがよいかと思います。
ただ、実際に書くと「まとめる力」を要求され、ちょっと大変です。未だに僕も慣れません。

アプリを作るエンジニアの皆さん、自分で開発した製品・サービスをより多くの人に使ってもらえるよう、リリースのタスクにぜひ『プレスリリース送付』を入れてみてください。
ひょっとしたら、今まで考えがつかなかった速度で、広まっていくかもしれませんよ。

ご参考になれば幸いです。

※追伸
おかしな部分がありましたらぜひご指摘下さい。特に、広報担当者の方のご意見がいただけると幸いです。

これが、オリジナルビデオクリップを収集するのにとっても面白い。

さて、クリップの際は通常の方法だと画面にURIをコピペしないといけないのですが、どうもめんどくさい。
ということで、ブックマークレット、作りました。

この動画をListPodへ追加する

はてなのIDをはじめとしたOpenIDの類を持っていれば、特別なユーザ登録は不要ですぐに始められます。ホントすぐ。
バシバシ追加してマイベストを作っちゃいましょう。
僕のリストは『ListPod – koemuさんのホーム』へどうぞ。

さて。ちょっとした要望を。
・マイリストにピックアップされているサムネールから動画へリンクしてほしい
→どうしてもクリックしたくなる。というか、した。
・登録完了後になにをすればいいかわかりにくい。
→はてブのように元動画に戻るのもよし、リストに戻るのもよし。僕はリストに戻ってほしいと思っています。

個人的にこういうのが好きなので、よりよい物になるよう期待しています！

次のコードを、テンプレート内の表示したい部分へ貼り付けてください。

<a href="javascript:location.href='http://del.icio.us/post?v=4; url='+encodeURIComponent('<?php the_permalink() ?>')+'; title='+encodeURIComponent('<?php the_title(); ?>');" target="_blank">
<img src="[画像の保存先DIR]/delicious.gif" width="12" height="12" alt="このエントリを del.icio.us に追加" title="このエントリを del.icio.us に追加" style="border: none;" /></a>
<a href="http://del.icio.us/url/<?php print md5( get_permalink() ) ?>" target="_blank"><img src="http://del.icio.us/feeds/img/savedcount/<?php print md5( get_permalink() ) ?>" style="border: none;" ></a>


※画像ファイルは別途アップロードして、パスを書き直してください。

貼り付けた結果が、記事右下の状態です。
とっても簡単ですのでお試しあれ。

■参考
[Z]ZAPAブロ?グ2.0: del.icio.usのブックマーク数表示に対応させました

エンジニアをしていれば、新しいもの(製品・サービスなど)を生み出すために日々取り組みます。
そして、出来上がると多くの人にその存在を伝えていくことになります。その手法として、古典的でありながら今でも大きな効果を期待できるのが、プレスリリース。ネット系ならITmediaやCNET、ネットに留まらないものなら全国紙(読売・毎日・朝日・日経)などがあります。
しかし、個人でやっているとプレスリリースを書いてくれる人なんて頼れそうもないし、会社でも小さい会社だと広報担当者がいないこともあり、似たような境遇だと思います。

そんな状況でも、いかにして自分の作ったものをプレスリリースを通じて世に報せていくか。僕がとった流れをご紹介します。

■心構え

エンジニアは、誰よりも作った製品のことを知っています。作った人にしか言えない、想いがあります。
これは、どんな広報担当者でも勝ち得ないアドバンテージです。

■3つのポイントを抑えろ

さて、その想いを論理的に整理していきます。
いかにして自分が作ったものの価値・メリットを、『誰へ』『どのように』出せるかという形式でまとめて行きます。
・先進性
→人があっと驚く、先進的な技術・仕組みを使ったものはありますか？
・独創性
→技術としてはありふれているかもしれないけど、誰も考えなかった切り口を捕らえていたりしますか？
・社会貢献性
→これは外せません。特に、どんな人にメリットがありますか？その対象が明確で、多ければよりよいです。

どんなプレスリリースでも『社会貢献性』だけは外せません。自分以外の人に価値が認められるものでなければ、掲載されることはまずないからです。プラス、独創性や先進性を訴えられるものがあれば漏れなくピックアップしましょう。プレスリリース、ひいては物の価値をより高めてくれます。

■どのメディアに出すのか

今から書くプレスリリースを、どのメディア(媒体)に出すかを絞ります。
メディア…、ネット系のニュースサイト、全国紙、雑誌と、読む人がまちまちです。言い換えれば、そのメディアにあったプレスリリースを書けなければ、せっかくのものの価値が伝えきれなくなってしまうのです。
ですので、慣れないうちは掲載してもらうメディアをネット系メディアへ絞ってしまうと書きやすくなると思います。いつも読まれているでしょうから読者層も想像しやすいですし、何よりどんなポイントを一番読み込むのか、ご自身が一番知っているはずです。
また、全国紙に載ればいいと考えたくなりますが、みんな同じことを考えていますから極めてハードルが高いです(※1)。その競争をかいくぐれるものであれば、全国紙にチャレンジするのもありです。全国紙掲載の威力はどんな広告よりも費用対効果が高いのです。
あと、たいていのメディアにはプレスリリース送付先が書いてありますから(※2)、ちゃんと抑えておきましょう。

大まかな理屈はここまでです。

■出ているプレスリリースを読み込もう
理屈はなんとなくわかっても、イメージがわかない。
そんなときは、現在ニュースサイトに掲載されている新製品情報と、そのプレスリリース原文をセットで読み込むことをお勧めします。プレスリリースの原文は、たいていその会社のホームページの「プレスリリース」や「お知らせ」欄に掲載されています。
特に、大企業の広報担当者が書かれている内容は、製品の価値を伝えるのがうまいのでお勧めです！僕はSONYのプレスリリースをよく読んでいます。

次回『後編：フォーマットを固めよう』では、実際に僕がシムエントリのリリース時に書いたプレスリリースを元に、内容の固め方のお話を進めてみようと思います。

※1
広報担当者の方の中には、全国紙の有力記者さんとバックボーンをしっかり持っている方がいます。そういう人たちもいることを肝に銘じてチャレンジしてください。

※2
プレスリリース一括送付サービスや、プレスリリース掲載サイトなどもあります。
お金が使えるのなら、このようなサービスを利用されるの一手かもしれません。

■いつから？
今晩の更新から適用します。

■どう変わるの？
これからは、ブログ内の上位10単語を「代表キーワード」と定義し、これを元に類似度が高いブログを検索するようにします。
今までは、ブログ内に含まれている全単語を使って、類似度が高い記事を探していました。しかし、この方法ですと長文の記事があると検索に多くの時間がかかるようになり、結果として更新が遅れてしまうという問題が発生していました。そこで、利用するキーワードを重要なものに絞って検索することで、計算速度を高める手法を採り入れました。

■精度は低くならないの？
類似記事の検索結果が変動することがあります。
現在私自身が確認している中では、大幅に結果が変動しておらず、精度は担保できていると考えています。
しかし、なにを以って「精度」を判断するかが難しいので、正直お話ししづらい部分ではあります。お気づきの点がございましたら、ご連絡いただけましたら幸いです。調整の際に参考にしてまいります。

■注意
・cos値の下限閾値を撤廃します
cos値の閾値を 0 < cos < 1 の範囲に変更します。これは、全単語を突き合せなくなったために完全なcos値ではなくなったためによるものです。
・APIを利用されている方へ
単語の照合を最大10個に絞ったため、APIで出力されるcos値が大幅に変わります。
APIを使われている方は、閾値などの見直しをお願いいたします。

■細かい話
各エントリの代表キーワードの算出方法は、TF*RIDF値の上位10番に入った単語を対象としています。
今回用いたRIDF(残差IDF 『情報検索アルゴリズム』P.43参照)は、IDFでは単に多くのエントリで取り上げられている＝重要度が低い、という認識が起きる時のギャップを埋める手法です。
たとえば、IDFのみで代表キーワードを抽出しようとすると、よく使われるが大切な言葉(たとえば地名や商品名など)のウェイトまで低くなってしまうのです。これを、ポアソン分布(サイコロの出目の確率を数えるときなどに使う近似値算出方法)で算出した頻度とIDFとの差を出すことで、大切な言葉をよりピックアップしやすくしています。

精度および速度の向上につきましては、今後も検討を重ねてまいります。

どうぞよろしくお願いします。

■追伸
引き続きRSSの登録も受付中です→シムエントリ トップページからどうぞ

今回のパネラーの方々は…
・美谷さん（世界を巡るFool on the web）
・湯川さん（湯川鶴章のIT潮流）
・小野さん（小野和俊のブログ）
・秋元さん（秋元@サイボウズラボ・プログラマー・ブログ）
の4名です。皆さん、ビジネスの専門がそれぞれ違うので様々な視点でお話が伺えるものと期待して足を運びました。

さて、自分の脳みその整理もかねて、今回もブログにまとめてみました。
恐らく、多くの方がセッションとパネルディスカッションの内容に触れられると思いますので、今回は僕がパネラーの皆さんに質問した内容を中心にお届けします。

■セッション 湯川さん ‐ 人柄をどこで見る！？
お話の中に、お会いする人は「ブログを書いている人に限る」というのがありました。
そこで「ブログの中からどの点を重視してご覧になられますか？」と、たずねてみました。
その答えは、『誠実さ』が伝わってくるか。
湯川さんは記者という仕事柄でしょうか、様々な方とお会いするそうです。しかし、会う時間は限られているため、どんな人か前もってわかる人に絞りたいとのことでした。この流れで動画人JAPANができた、という逸話も披露されていらっしゃいました。

ここでポイントが、いかにして『ブログで自分自身を伝えるか』です。
実は、最近お会いした人が事前に僕のブログを見られていたのですが、一言「あなたが何者かよくわからない」(※1)と言われてしまい、ちょっとショックでした。
これは自分自身を表現するメディアであるブログを使いきれていないという、大変な問題だと考えています。
早速、自分のブログを再点検しているところです(※2)。皆さんも、点検されてみてはいかがでしょうか？

■パネルディスカッション ‐ スタイルの確立
今回登壇されているパネラーの皆様は、ブログのスタイルをそれぞれ確立されていらっしゃいます。
ただ、多くの方はブログに限らず自分のスタイル確立に悩まれているはず。そこのところ、ズバッと質問してみました。

・小野さん
ブログが大きくなるきっかけは、とあるアルファブックマーカーにブックマークされたことだったそうです。
「ようやく」半年前に自分のスタイルが固まってきたとお話されていたのですが、その間までの混沌とした状況をリアリティあふれるトークでお聞かせいただきました。
それまでは牧歌的(『小野和俊のブログ:はてブと初めて接触した時の気持ち』をご覧ください)だったブログが、突如としてメジャーになってしまった。特に、多くの人が読んでいる中で、今まで書いていた『個人的な話』を書いていいものなのだろうか、悩まれたそうです。
そんな中、試行錯誤(※3)されながらも、みんなが楽しめるものも書きつつ、個人的に発信したいことも織り交ぜて書いてもいいんだ、と言うことを見つけられたとのことです。

・湯川さん
記者という職業柄、文が公に触れることは気にならないとのことです。
アクセス数も特に気にせず、始めたときと変わらずにされているとのお話です。
ブログを始められる以前から、スタイルが確立されていらっしゃったのかもしれませんね。

・美谷さん
美谷さんも、小野さんと同じきっかけだったそうです！
当時、会社でインターネットに関することを書かれていたそうなのですが、その中の1つの記事(AdSenseのことだそうです)がこれまた同じアルファブックマーカーによるブックマークがきっかけで、多くの読者がつくようになったそうです。
役に立つ記事がハブになる人の目に留まると、ブログ全体の価値も一気に増大するようです。

・秋元さん
日本に需要があるけど存在しない情報を発信されていたことから、検索エンジンから来る読者が多かったそうです。
その積み重ねが、現在の読者数になっているとのことです。

さて、話をまとめますと、集客効果が如実に現れるのは大きく2つのチャネルがあることがわかりました。
『はてなブックマーク』 ‐ ハブとなる人が一気に広める
『検索エンジン』 ‐ 需給のバランスが悪いところに入る
しかし、この効果を享受するには、多くの人が『読んでみたい！』と思える記事を書けるかどうかが基底にあることを忘れてはなりません。

■今日のパネラー ここがすごい！
最後に、パネラーの皆様のブログを見て、僕なりに『ここを見習ってみよう』と考えた部分をピックアップしてみました。

・美谷さん
見やすい、読みやすいブログです。
以前『『俺ブ』にちょっと参戦』でピックアップさせていただいたことがあるのですが、解説もわかりやすくいつも参考にしています。それを、視覚でさらに理解を深めていく、という流れになっています。

・湯川さん
どっしり構えていらっしゃる姿がとても印象的でした。
ブログでも、その雰囲気がとても伝わってきます。安定した方の表現って、見ているこちら側も安らぎますよね！

・小野さん
今日のプレゼンもそうですが、表形式でわかりやすくまとめていらっしゃるのがとても印象的です。
最大の効果は、どのようなことも『話が一般化できる』ことでしょうか。だから、多くの人に伝えやすいんだなと考えました。
また、RPGの話などを織り交ぜながら、ちょっと硬くなりそうな表現をやわらかくされているところも印象的です。

・秋元さん
英語が話せる力がどれほど世界を広げられるのか、体現されていらっしゃるなと感じました。
また、どうしても英語の情報を敬遠しがちな日本人のポイントを、しっかり抑えていらっしゃいます。みんながやらない/できないけど多くの人がやってもらいたいことができる力は、とても貴重です。

■最後に
前回に引き続き、ブログに限らずビジネス全般に活用できる貴重なお話を賜りました。
『普段の延長線上に自分の理想がある』点が揺るがないのはもちろんのこと、「試行錯誤」から逃げずにしっかり向き合う大切さを改めて感じる機会になりました。
向かう先は同じなのですけど、その途中経過をいかに乗り切るか。そこで、先人の智恵を活用しない手はありません。

パネラーの皆さん、そしてご一緒させていただいた皆さん、どうもありがとうございました！

※1
特に、どんなビジネスを経験されているか、わからないといわれていました。
趣味などの話は自分の個性を表現するために大切な情報なのですが、それ以上に「型通り」のプロフィールなどの公の自分を十分伝える必要性を感じました。

※2
手始めに、プロフィールページを全部書き換え、右メニューからリンクするようにしました。

※3
全員の方が、リファラ(ブログのリンク元)をチェックされていらっしゃいました。
僕も、自分への反応を調べる、古典的ではありますが最も情報量が濃い反応として毎日しっかり確認しています。
そうそう、最近使い出したのですが『Track Feed』というツール、リファラの抽出に特化されていて便利です。

■RSSフィードが終わっても代替情報を表示します
今までは、RSSフィードが終わってしまった記事については空欄になっておりましたが、「これだと寂しい！」というお話を伺っておりました。
そこで、RSSフィードが終わった記事については、ブログ全体からある1記事の類似度が高いものをピックアップして表示するようにいたしました。実際の仕組みは、メニューバー用ブログパーツと同じです。
このモードで動いているときは「興味が近い別のブログを探してみよう」という表示に切り替わります(通常は「この記事に近いブログはこちら」です)。

■幅狭バージョン登場
シムエントリのブログパーツに、幅狭バージョンが登場しました。
今までのブログパーツは、情報量が多く幅も広いため、一部のテンプレートを利用していると具合が悪いことがあるとご連絡をいただいておりました。
そんな方にお勧めいたします。

幅が360ピクセル 固定で表示されます。
貼り付け方は今までと同じ、『標準ブログパーツ』と同じ方法で貼り付けてください。
———————
<!-- Sim entries -->
<script charset="utf-8" src="http://se.koemu.com/js/sim-entries.js" type="text/javascript"></script>
<script type="text/javascript">writeSmallSimilarList( '記事のアドレス' );</script>
<!–– / Sim entries ––>
———————
※メソッド名が writeSimilarList → writeSmallSimilarList になっています
※ブログ別の貼り方は『ブログパーツの貼り付け方』をご覧ください

動作も、幅と表示される情報量を除いて、標準ブログパーツと同じです。

どうぞお試しください。

■追伸
引き続きRSSの登録も受付中です→シムエントリ トップページからどうぞ

■計算速度改善
計算速度の改善ですが、現在も引き続き増大していることから抜本的に方法を変えることを検討しています。
手法としては、現在有力なのが『代表キーワード抽出』による方法です。
これは、元エントリより代表(中心)となるキーワードをいくつかピックアップし、これから内容が近いエントリを探し出してくる、という方法です。
キーワード検索自体はすでに転置インデックスによる最適化が済んでいますので、高速化はやりやすいと考えております。
また、代表キーワードの抽出方法はいくつか存在するため、速度・精度共々バランスがよいものを採用できるよう現在試験中です。

■記事保持期間の設定
RSSフィードから対象外となっても、一定期間保持する機能を検討中です。
これは、上記の計算速度の改善で目処が立ち次第、順次対応する予定です。

■ブログパーツ
・幅狭タイプ(250px)の設定
・検索対象外となった場合の代替表示
について、検討中です。幅狭タイプは情報量を削って幅を狭めるだけになると思います。
代替表示については、メニューバー形式のブログパーツと同じしようにしようと考えています。

計算速度の改善については、3月末までに対応できるよう進めています。

途中経過のお知らせでした。

【おまけ】
『この記事はシムエントリの解析対象になっているのか？』ということを調べやすくするためのブックマークレットです。
個別の記事を開いた後、このブックマークレットを使ってみてください。
■シムエントリのデータを確認
(といっても、JSONのAPIを直接叩いて中身を見るだけです。)