Web2.0の本質はデータマイニングにあり

レコメンドエンジンの話を知りたくて、「集合知プログラミング」という本を買ってみた。
内容はいわゆるデータマイニング。
全て読めてないけど、すごく面白かったので、考えていることをメモ書き。
＃後でロジカルに書く。

【1】僕が「集合知プログラミング」を読んで思ったことは「Web2.0の本質はデータマイニングにあり」。

【元ネタ1】
プログラマーに最適なデータマイニングの教科書 『集合知プログラミング』 - 図書館情報学を学ぶ

集合知プログラミングが凄すぎる件について - プログラマになりたい

オープンソースのレコメンドエンジン　Taste - プログラマになりたい

オープンソースのレコメンドエンジン　Taste

Web2.0の成功例としては、Amazonの関連商品、iTunesのお勧め曲表示、はてなブックマーク、GoogleのpageLankによる検索エンジンなどがあげられるだろう。

これらの本質は、データマイニングにある。
売れた商品データ、売れた音楽データ、ネット上にあるリンク情報など、大量に溜まったトランザクションデータから、関連性のある情報を吸い取り、ユーザーに提示する手法。

この手法が面白いのは、一つは、プログラミングとマーケティングが直結すること。
もう一つは、プログラミングのアルゴリズムが面白いこと。

前者は、優れたプログラミング技術があれば、経営層や営業マンが気付かないマーケティング情報を数値で出力できること。
よく言われる例は「紙おむつとビールが良く売れる」というもの。
この手法が進むと、昔から言われていたエキスパートシステム、エージェント、人工知能につながるだろう。
今まで特別な人しかできないと思われていた高度なマネジメント手法を、誰でも手軽に使える可能性が広がるかもしれない。

後者は、大量のトランザクションデータを解析するには、それなりの数学的知識やコンピュータ科学を必要とすること。

いわゆるレコメンドエンジンのアルゴリズムは殆どは、協調フィルタリングと呼ばれるものだろう。
僕が理解している内容では、例えば、ユーザーIDとユーザーが購入した商品IDのハッシュマップをリストで保持し、複数のユーザのリストを並べて、色んな観点(アルゴリズム)で類似性を導き出すというもの。

このレコメンドエンジンのアーキテクチャは例えば、バッチ処理で売上データTblから類似性のある情報を計算して、フロント側にある画面からHTTP経由で、XML化された関連する商品データを取得するものが多いだろうと思う。
つまり、バッチ処理とWebサービスを組み合わせるやり方がレコメンドエンジンの殆どの実装方法と言えるだろうと思う。

このアーキテクチャにする理由は、一つは、大量の売上データを解析するのは時間がかかるため、バッチ処理の方が向いていること。
更に、Webサービス経由で関連商品情報を取得できるインターフェイスならば、他サブシステムからもHTTP経由で簡単にXMLを取得できるから。

でも、本来はバッチ処理ではなく、リアルタイムに計算できるようにしたい。
今はコンピュータ資源がいくらでもあるから、大規模分散計算のアルゴリズムMapReduceをフルに使えば、より質の高い情報をもっと速く提供できるのではないか？

技術的に面白いのは、リストで比較して類似性を計算する手法は、関数型言語と相性がいいこと。
HaskellとかScalaで実装できないのか？

オープンソースのレコメンドエンジンとしては、Tasteとかあるらしい。

【2】僕がデータマイニングを一番使いたい場面は、プロジェクト管理やSW工学だ。

【元ネタ2】
[Think IT] 第1回：エンピリカルソフトウェア工学を学ぶ前に (1/3)

森崎修司の「どうやってはかるの？」 エンピリカルとは : ITmedia オルタナティブ・ブログ

エンピリカルソフトウェア工学とは、エンピリカル：ソフトウェア工学への実証的アプローチ - nobusueの日記にもあるように、「"experimental"と"experienced"を合成したものだそうです。文字通り、「事実に基づくソフトウェア工学の構築」を目指したもので、ソフトウェア開発に対して科学的にアプローチしようという試みです」。

チケット駆動開発の仕掛けはBTS(バグ管理システム)にある。
データマイニングを使って、BTSに溜まった情報から、プロジェクトの進捗やシステムの品質に関するメトリクスを出力し、管理者が意思決定する情報として使いたいのだ。

丁度、経営者が毎月の売上データ、四半期ごとの決算書を予定・実績で比較検討した後に意思決定するように、チケット駆動開発のインフラであるBTSから出力された情報をプロジェクトのリスク管理として使いたい。
データマイニングの仕掛けは、協調フィルタリングではないだろうが、その発想は応用できるはずだ。

Redmineならば、サマリの画面で、トラッカー(チケットの種類)・担当者・バージョン(イテレーション又はマイルストーン)・カテゴリ(コンポーネント)などの観点でチケットのステータスを自動集計して表示する機能がある。
更に、ガントチャートやカレンダーをリアルタイムに出力できるし、そして、月別にバージョンで実績工数をクロス集計する機能もある。
これらの機能を使えば、プロジェクトの作業進捗やすぐに分かるし、そこからリスクを嗅ぎ取り、是正対策を取ることもできる。

statSVNというツールを使えば、Subversionリポジトリから、コミット日や開発者毎のLOCやコミット回数などを集計してくれる。
この結果から、システムのLOCがどのように増大しているか、開発者の貢献度は？などが分かる。

又、テスト管理ツールTestLinkを使えば、溜まったテスト実績から、テスト進捗や、バグの数からテスト工程の品質が分かる。
要件カバレッジの機能もあるから例えば、この要件はバグが多いので注意しよう、などの対策を取ることができる。

これらの手法をもっとお手軽に一つのパッケージとして提供できないか？

「集合知プログラミング」の本では、たくさんの例とたくさんのアルゴリズムがPythonで説明されている。
JavaやRubyに慣れている人ならば問題なく読めるのではないだろうか？
この本の読書会は開かれていないのかな？