クリスマス暇過ぎて腐女子人気作品の探索的データ解析を行うしかなかった



はじめに

クリスマスはいつものように全く予定無かったあんちべです、こんばんは！
皆様はクリスマスをお楽しみになられましたでしょうか？
「今yesと答えた奴ら全員地獄に堕ちろ」ってサンタさんにお願いしておいたからな。


さて、世間のリア充様がクリスマスで浮かれまくりやがっていらっしゃる中、
やること無さ過ぎていつものようにpixivで腐女子向け作品を眺めていたところ、
ありがたいことに寂しさを感じる暇もない勢いでどんどん作品が投稿されていました。
ハッピーですね！


…………？


クリスマスの真っ只中に腐女子絵を投稿している…だと！？
クリスマスと言えば皆さんお楽しみのはずでは？
いや、クリスマスの夜にむしろ投稿数が増加しているような気が…？
という疑惑を抱いたので、実際データを色々眺めてみましょう。

データの説明

データはpixivから下記タイトルで検索した結果を12/26の午前中時点で
各々1万件弱(タイトルによって多少件数異なります)取得したものです。
今回分析するのは次の10タイトルです。
そっちの方面でも大変人気なタイトルですね。

  1. Free!
  2. TIGER&BUNNY
  3. うたの☆プリンスさまっ♪
  4. テニスの王子様
  5. ハイキュー
  6. ヘタリア
  7. 銀魂
  8. 黒子のバスケ
  9. 弱虫ペダル
  10. 戦国BASARA

pixivでは主だった指標として
閲覧数、評価回数、総合点の3つを取得することが可能です。
閲覧数はその絵を見た回数*1、
評価回数は閲覧者がその絵に対して10点満点で点数を付けた回数*2、
総合点は各閲覧者の評価点の合計です。
その他、各作品に付与したタグ情報も取得出来ます。
なお、pixivからの具体的なデータ取得方法は以前書いた進撃の巨人のアレをご参照ください。

これらのタイトル選択は腐った方々から下記のようなご協力を頂きました。
誠に有難うございます。*3*4
f:id:AntiBayesian:20131228210208j:plain
f:id:AntiBayesian:20131228210220j:plain

時系列分析

期間は12/1～12/25、各タイトルの投稿数を日次で並べたもの。
セルの色が赤ければ赤い程そのタイトル内で
その日の投稿数は多いということを表している。
まずは黙ってこの結果を見てくれたまえ。

f:id:AntiBayesian:20131229013957j:plain

クリスマスイブ・クリスマス当日、半分以上のタイトルが真っ赤ですよ！
何やってんだ皆さん*5！！！
折角のクリスマスを作品投稿に費やしていいのですか*6？？？
特にタイバニ、クリスマス当日なんて
平均値の2倍以上というか3倍近い投稿枚数ですよ！！！

それはそれとして、今回は皆さんにも頑張って分析して頂きたいと思います。



上のようなツールを用意しました*7。
横軸が日付、縦軸が投稿枚数の折れ線グラフです。

使い方
  1. 右側のタイトル名をクリックすると線を消したり出したりできます
  2. グラフをマウスでドラッグするとその期間をズームアップ出来ます
  3. ズームアップ後、"Reset zoom"ってボタンが表示されるので押すとズームリセットします

以上。
ごちゃっとして見辛いと思いますので、適宜操作して良い感じにしてください。
データは11/1～12/25まで表示する設定になっています。
注意点として、上限1万件弱でデータ取ってきているため、黒子のバスケとヘタリアは
あまりにも投稿数多すぎて遡り取得が出来ず、
11月頭付近では一部データ欠損しています。
欠損している時点は-1という数値を埋めています。
これをグリグリやってなんかしてください。
実際実務でもこういうのを用いて時系列で相関してるっぽいタイトル群を見つけたり、
見る期間を変えながら他タイトルと比較したりしています。
これで何か面白い振る舞い見つけたらぜひ教えて下さい！

単語頻度

登場したタグの頻度をカウントしてみましょう。
こういう作品のタグを頻度毎にカウントすると人気キャラやカップリング、
あるいは作品を特徴づけるようなキーワードが拾えます。
具体的な手順ややり方、スクリプトは再度進撃の巨人のアレをご参照ください。
さて集計結果は…
f:id:AntiBayesian:20131228221930j:plain
どの作品にも「腐向け」タグが入っています。
しかも弱虫ペダルとハイキューに至っては
並み居るキャラを押しのけて1位が「腐向け」。
同じく、どの作品にも入っているタグがもう一つ…そう、「R-18」です。
特にタイバニなんてアレですよ、
1位が兎虎なのは鉄板カップリングだからまだ見て見ぬふりをするとして
2位が「腐向け」で3位が「R-18」ですよ、完全に特定目的ですよ。
っていうかやっぱりキャラ名じゃなくてカップリングが
最上位なのは見て見ぬふりできないよ！
どうなってるんだよタイバニ勢！
嘘だと言ってよ、バーニィ！


まぁ最後のが言いたかっただけなので次に進みましょう。

探索的データ解析って何？

進撃の巨人を読んだことない人がデータだけでキャラを推測してみる - あんちべ！
では「キャラを推測する」という明確なタスクを設けましたが、
今回はデータを様々な切り口で眺めまわすことによって
「どんなことがわかるかな？」とデータドリブンで分析を進めていきます。

基本的に、分析をする前に何らかの目的や仮説を設定しなくてはなりません。
無意味にデータを並べ立てても何も得るものはありません。
皆さんも単に数値やグラフが羅列されているだけの資料を見て
「で、何がわかったの？何が言いたかったの？」
となった経験は無いでしょうか？

しかし、分析者に分析対象となる分野の前提知識が無い場合や
そもそも分析対象内の変化が激しい場合、
また、その分野が一般には知られていない場合など、
適切な目的や仮説を設定すること自体が困難なケースもあります。
そのようなケースでは、「適切な目的や仮説を獲得する」という目的で
データを様々な切り口で眺めて探索するのも一つの手です。
このようなアプローチを統計学の世界の言葉で「探索的データ解析」と呼びます。

まぁようするに状況よくわかんねー時はひたすらデータを色々舐め回すことによって
なんか面白そうなこと見つけるべという話ですよ！！
ついでに、「データを様々な切り口で検証しまくること」を
統計学の世界の言葉で「データの尋問」と呼んだりします。
分析する際、「さーて、今からデータを尋問するかー」
と声に出して言えばテンション上がって
「最高にハイッってヤツだ！！」
状態になれるので是非口にしましょう！
ラブリーデータ！！！
データさえあれば恋人や友達はいなくとも人生は楽しい！！！
さぁpixivで（特に腐女子からの）人気の高い作品に
探索的データ解析を試みて楽しみましょう！！！

データを尋問してみる

データの尋問の最初の一歩はデータの特徴や性質を把握することです。
そのためには様々なデータを集計したり可視化したりします。
まず12/1～12/25の期間で各タイトルのUU（ユニークユーザ、延べ投稿者数）と投稿枚数を集計してみます。
f:id:AntiBayesian:20131228224846j:plain*8
次にタイトルごとの投稿数トップ3ユーザの投稿枚数と、
期間内に10枚以上投稿したユーザ数を見てみましょう。
f:id:AntiBayesian:20131228225511j:plain*9
f:id:AntiBayesian:20131228225044j:plain*10


黒子のバスケ、圧倒的なUUと投稿枚数ですね。
また、テニスの王子様の投稿数トップ3の投稿枚数の多さと
ヘタリアの10枚以上投稿者数の多さ。
一か月弱という短い期間でこれほどの人数がこれほどの枚数投稿してるとは驚きです。
一日一枚以上投稿している計算になる方が何人かいらっしゃいます。
（深い愛を感じますね…。）

今度は総合点・閲覧数・評価回数各々の中央値と
評価率(総評価回数を総閲覧数で割った値)を見てみましょう。
中央値とはデータをソート（昇順でも降順でも良い）し、
その中央に位置する値の事です。
中央値は平均値と異なり飛び抜けて大きい値や小さい値に
左右されないという性質を持っています。
この性質を頑健性といい、探索的データ解析を行う段階では
データの分布形状が不明だったり極端な値が存在するケースも多々あるため、
この性質を重視します。
今回実際データを見てみたところ、
時々飛び抜けて大きい値が存在していたため中央値を利用します。

f:id:AntiBayesian:20131229024928j:plain*11

TIGER&BUNNY、弱虫ペダル、ヘタリアが非常に総合得点高いという結果です。
また、ヘタリアは他と比べて評価率が高いようです。
と言いますか、これだけの人気タイトルでも
評価率5%を切っているのが大半なんですね。
閲覧者の皆さんはこの評価率についていかがお考えでしょうか。

さて、今度は各指標の標準偏差を見てみます。
標準偏差は「どれくらいばらつきがあるか」を示す値で、
これが大きければ大きい程ばらつきが大きい、つまりピンキリであることを示します。
f:id:AntiBayesian:20131228233513j:plain
黒子のバスケが総合点、評価回数とも最もばらつきが大きく、
閲覧数も2位につけています。
UU・投稿枚数も多いのでばらつきが大きいのも妥当な話です。
逆にヘタリアがUU・投稿枚数では2位につけているにもかかわらず、
標準偏差で見ると総合点と評価回数で6位、閲覧数では7位というのも、
先程の総合点の中央値や評価率が高いことを組み合わせると中々面白いです。

これまでご覧頂いた中央値や標準偏差は
「要約統計量」というデータ全体を単一の値に要約するものです。
データ全体を見るのではなく値を一つ見るだけで済むため楽ですし、
比較する際大変便利ですが、様々な情報を削ぎ落としてしまいます。
ではデータ全体を見ればいいかというと、
10タイトル各々1万件弱、約10万件のデータがあるため、
人間が記憶・把握できる量の限界を遥かに超えています。
人間が把握できる範囲でもっとデータを詳細に見るため、
データを適切な範囲で区切り、
その範囲内に収まるデータがどの程度の個数あるかを見ることで
データの分布状況を確認します。
可視化する場合はヒストグラムや箱ひげ図を使うと良いでしょう。
今回は全作品をまとめた総得点の分布を元に、
グラフが山形になるような範囲*12で下記のように区切った
総得点のヒストグラムを見てみましょう。
f:id:AntiBayesian:20131229011441j:plain*13*14
これを見ると中々面白いことが色々わかります。
戦国BASARAは総合点0のレンジの比率が他よりかなり小さいようです。
TIGER&BUNNY、弱虫ペダル、Free!は1000点以上の作品が10%以上あります。
Free!は中央値的には上位に入りませんでしたが、
このようにヒストグラムで見ると結構高得点作品もあることが分かりますね。
黒子のバスケの1万点オーバー作品が1%なのは相当凄まじいですね。
100枚に1枚は1万点オーバー…。


さて、これらの集計結果から色々なことが判明しました。
判明したことを捨て置いては意味がありません、活用しましょう。
ここでは「どのタイトルを推薦するか」について考えてみます。
様々なアプローチがありますが、ここではペルソナ法と呼ばれる
「何らかのペルソナ（ある分野/層における典型的なユーザ）を想定し、
　そのペルソナごとに分析結果を活用するシナリオを策定」
というアプローチをやってみましょう。
まず閲覧者というペルソナを用意します。
閲覧者のペルソナの最大欲求が「高評価な作品を見たい」
であると想定したとしましょう。
その場合、

  1. 1万オーバーの作品が特に多い黒子のバスケ
  2. 3000オーバーの作品が全体の5%以上を占めるFree!、TIGER&BUNNY

を薦めるなどが考えられます。
また、今度は投稿者のペルソナで考えてみましょう。
投稿者のペルソナの最大欲求が「高評価を得やすいタイトル」
であると想定したとしましょう。

  1. 閲覧数の多い弱虫ペダル
  2. 評価率が高いヘタリア

を薦めることが考えられます*15。

終わりに

統計分析 is 楽しい！
仮説検証系アプローチも良いけど、
特にデータ尋問して新しい何かを見出す探索的データ解析はとびきり楽しい！

昨今、市場変化が激しかったりそもそも新規開拓な市場だったりして、
仮説検証の前に仮説生成をしないといけないというケースもよくあります。
そういう場合は探索的データ解析の出番ですね。
市場の多様化に伴い、今後ますます未知の分野を
切り開いていく機会が皆さんにも訪れることでしょう。
私は腐女子受けする作品を殆ど知らないため、
まさに探索的アプローチを取るしかないという状況でした。
自分の良く知ってる分野と全然知らない分野両方を分析してみると
同じアプローチでは全然通用しないという事が分かります。
意識して自分の知らない分野を分析してみるの、大変面白いですよ。
精度の良い分類やレコメンド、複雑な検定を行うのも素晴らしいことですが、
探索的データ解析のような探索的アプローチを用いて
新市場を切り開いていく事例がもっと増えると良いなーと思います。
未踏を舐ろう！！

最近データを公開して下さる様々な企業や機関の尽力のお陰で、
割と簡単に色んなデータが取得出来るようになってきました。
例えば下記のAPIリンク集辿ると
皆さんの興味を引くデータが取得できるかもしれません。
http://www.find-job.net/startup/api-2013

楽しそうなのでやってみちゃいましょう！！
ではでは長文読んでいただきお疲れ様でした。

追記

f:id:AntiBayesian:20131229171934j:plain
ふむふむ、なるほど。
次回はブクマ数も考慮して分析しないとですね！
評価人数と総合点は仰る通り強い相関があり、
散布図描くとほぼ一直線にならぶのですが、
閲覧数と評価数はで散布図描くと近似曲線から大きく外れます。
つまり、評価率が作品によって異なります。特にヘタリアが顕著ですね。
なので評価人数だけではなく、評価率も見ようかという感じです。

ブクマ機能ですが、実際私自身使ってないので指標としてどう振る舞うかは
ちょっと分析してみないとわからないというのが本音です。
ただ、「100users入り」などブクマ数を考慮したタグを頻繁に見かけます。
pixivでは総合点の順に作品をソートする機能は有料であるため、
「***user入り」タグを辿ることによって高評価作品を探す、
という使い方をしていることも考えられるのではないでしょうか。
もし「ブクマ機能はこういう感じで使うんだよ」というの
ご存知の方いらっしゃったらお教え願いたいです。

ちなみに、pixivのプレミアム会員は月額525円で
素敵な機能が使えるようになります。
こういう素晴らしいサービスが赤字続きになって
存続出来なくなると大変悲しいので、
余裕のある方は是非プレミアム会員になって
いろんな機能を使いまくりましょう！*16
http://www.pixiv.net/premium.php

追記の追記





ご解説ありがとうございます！！！


参考文献

あまあまくろにくる　【2013年冬】コミケカタログカップリング調査１０作品まとめ
http://tarte41.hatenablog.com/entry/20131215/1387305779
BL専門用語の基礎知識『腐女子用語辞典』
http://zatugakaarika.blog.fc2.com/blog-entry-2829.html

スペシャルサンクス

  • pixiv
  • @hathiko8
  • @suruli
  • @reona396

f:id:AntiBayesian:20131229024240j:plain
f:id:AntiBayesian:20131229025502j:plain

*1:1ユーザ1日1回だけカウントされます。F5アタックしても数増えません

*2:ある絵に評価与えられるのは1ユーザ1日1回だけです

*3:進撃の巨人は腐女子的にも人気タイトルでしたが、以前やったので今回は無しということで…

*4:なお、取得する際にダーティーなものは分析対象外にしています。例えば16列目に総合点が入っている筈なのですが、時々明らかに点数以外の物（何らかのタグや文字列など）が入っていたりします。

*5:自分の事は棚に上げつつ

*6:自分の事は棚に上げつつ

*7:表示されない場合はお手数ですがブラウザ更新お願いします

*8:※UU降順ソート

*9:※一位の投稿枚数降順ソート

*10:※人数降順ソート

*11:※総合点降順ソート

*12:他には等分になるよう区切る方法もあります

*13:※総合点が0点のものは未評価のため0点になっているものを含みます。

*14:※図上が比率表示、図下が個数表示です。 　比率表示する場合、 　1．データサイズが小さすぎて僅かな件数差が大きく反映される 　2．各データのデータサイズが大きく異なる 　などのケースが存在するため、個数表示も添えて下さい

*15:ぶっちゃけここで挙げた推薦はあくまでも例えのための例えで、 実際は好みのタイトルは殆どの場合事前に決まっており 特に投稿者の場合推薦に従って投稿するなんてまず無いとは思います。 「AとBどっちを描こうかな？」と迷っている時であれば多少効果あるかもしれませんが

*16:というステマをしておいたのでpixiv様、毎回ネタにさせて頂いておりますが許して下さいませm(_ _)m

SQLite + Pythonユーザ定義関数組込で進捗ダメじゃないですになりました

概要

これまで「Hiveからデータ取得・簡単な加工→Pythonで加工・分析」
という流れで作業していたのですが、
Hive→SQLite→Pythonという流れにしたところ進捗が改善されたので、
SQLiteの簡単な使い方とPythonによるSQLユーザ定義関数の組込方法
についてメモを残しておきます。
特にユーザ定義関数の組込を自由に出来ると、
分析する際、相当楽になるということに気付きました。


SQLite挟むことで何がどう改善されたの？

Hiveはデカいデータをゴリゴリ取ってくる分には
SQLちょっと書くだけで済むので大変便利ですが、
初動遅いためちょこちょこ小さいデータを何度も取ろうとするとストレス溜まります。
そのため、これまではある程度のデータをまとめてHiveで落としてきて
Pythonで加工してから分析するという流れを取っていました。
ただ加工するために似たようなコード何度も書くのだるいし、
上手いこと書かないと結構処理に時間かかってしまうのでだるい、
ダブルダルくて進捗ダメでした。
そこで、Hiveから取ってきたデータを一旦SQLiteに入れてしまいさえすれば
1. 抽出・加工がSQLだけで出来る、
2. しかも結構高速*1
なので進捗ダメじゃないですになりました。
MySQLでええやんって言われたらまぁそりゃそうなんですが、
SQLiteはお手軽なので可愛い、可愛いは正義。
SQLiteは下記からバイナリ一つ落としてくるだけで利用出来ます。
面倒な環境設定などは必要無しなので手っ取り早くRDBMS使いたいって時に特に良い。
http://www.sqlite.org/download.html

SQLiteの簡単な使い方
sqlite3 test.db --test.dbという名前でDBファイルを生成。SQLiteはこのDBファイルにテーブル情報全部入ってて、これを渡すだけでデータまるごと渡せる、便利
.separator , --ファイルセパレータを,に設定
.import test.csv test_table --test.csvファイルをtest_tableに取り込み
-- なんとこの三行で下準備終わり

.mode csv --CSV形式で出力するという設定
.output output.csv --クエリの結果をoutput.csvに出力するという設定
select * from test_table; --このクエリの結果がoutput.csvに吐かれる
.output stdout --出力先を標準出力に戻す
PythonでSQLite用にユーザ定義関数を組み込む
# 実はこの記事なんて読む必要無くて下記参照すれば出来る
# https://python-doc-ja.readthedocs.org/en/latest/library/sqlite3.html
# 今回はSQLiteには標準搭載されていないmedianを組み込んでみる
import sqlite3
import numpy #科学計算用ライブラリ。様々な統計関数が用意されているのでSQLに組み込むと大変便利

class Median:
    def __init__(self):
        self.values = []
    def step(self, value):
        self.values.append(value)
    def finalize(self):
        return numpy.median(self.values)

con = sqlite3.connect("test.db", isolation_level=None)
con.create_aggregate("median", 1, Median)

c = con.cursor()
query = "select median(hoge) from test_table"
c.execute(query)
l = []
for row in c:
    print row
感想

とても簡単。
と思いきやmedian組み込むのに結構四苦八苦した。
始めはSQLだけでやろうとしたり
numpy使わず自前でmedian相当のコード書いてたりしたけど、
データサイズが8GBくらいになったら糞遅かったり途中で落ちたりしてかなり困ってた。
自前実装にそこまで拘る必要無い*2かなと思って
numpy.median使った瞬間データが10GBオーバーでも全然軽快に捌いてくれた*3

ユーザ定義関数自由に組み込めると何がハッピーかって、
Pythonは統計/機械学習のライブラリが充実しているため、
そのライブラリの関数をSQLに組み込みさえすれば
クエリ打つだけで分析が出来るようになるってことです。
しかも弊社では社内の一般ユーザ（＝非エンジニア）向けにデータを自由に取り出せるよう
クエリを打つ口を作っています。
そのクエリを打つシステムにコイツを組み込めば、
各ユーザに分析環境構築して貰う必要無く、
クエリ打つだけで誰でも統計手法が適用可能になるのでハッピー。
ありがとうSQLite、numpy！
お陰様で進捗ダメじゃないです！

*1:※個人の感想でありベンチは取っていないため妄想の可能性があります

*2:かどうかはちょっと微妙で、普通作業用サーバにnumpy入ってないと思われるので、出来る限りSQLだけとかPython標準関数だけとかで終わらせたかったって思いもある

*3:※個人の感想でありベンチは取っていないため妄想の可能性があります

面白いデータは転がりまくってるけど転がってるままなので誰か助けてくれろ

転職して丁度2年がたちました。

現在はWebベンチャーで統計屋しています。大変楽しい毎日です。
なぜ楽しいかというと勿論リスプを書いているからというのも大きなる理由の一つです*1。
このエントリでは何が楽しいのか近況交えてつらつらまとまりなく書いてます。
あと現職の解決しがたい不満についても書いています。
糞長くなってしまったので要約すると
「今糞面白いけど超えられない壁あるので誰か助けて」
です。


現職面白い理由5個。

1．データが面白い*2

私は経済学科・数理統計の研究室出身で、応用先としてコミュニケーション活性化を目的とした
行動経済学やテキストマイニングをやっていました。
そういう背景があるため、学生時代いつか壮大な社会実験をやりたいと思ってたけど、
それには大変なお金がかかったり大がかりなシステムを構築しないといけなかったりで断念した。
ですが今はSNSやソーシャルゲームや広告のデータを自由に扱えるため、
毎日放っておいても社会実験用のデータ入ってくるような状況。
面白データ見てたらお金が貰える仕事、完全に未来感ある。

ゲームのデータの面白さの一例を挙げると、文字/画像情報しかないSNSと違い、MMOでは空間データも取得できます。
これを見ていると凄い面白いのが、親密な相手には近い位置に立って会話し、
初対面の相手では遠い位置で会話をしているという事実。
現実でも似たようなものですね。
そのデータから親密な人同士の距離がどの範囲かを知る事が出来ます。
さらに、親密な人がいるプレーヤーは継続して遊んでくれるプレーヤーになるというデータも得られました
これもまぁ実感的な話ですね。
それらのデータから生まれたのが、あるエリアの広場に椅子を置くというアイデアです。
だだっ広いエリアで目立つように置かれた椅子。ゲーム内と言えども座りたくなりますよね。
そして椅子と椅子との距離を「親密な人同士が会話する距離」に設定しました。
広場の端と端にいれば、中々会話は始まりません。
しかしごく近い位置にいるとどうでしょう？
例えば会社によくある喫煙室のような狭い部屋で顔を突き合わせていると、
相手を無視するのも気まずいので、会話が発生しやすくなります。
すると、普段は全然絡みの無い全く違う部署の方と会話が弾んで意外な情報を得たり友好関係を結んだりすることがあります。
物理的な近さは思いの外親密度に繋がります。
無理やり近くにプレーヤーを配置するわけにはいかないため、
自発的にかつ必然的に近づいて話しかけやすい環境を整えました。

面白いデータと統計学を用い、
椅子を近い距離に配置して会話を発生しやすくするというアイデアを生むこと、
アイデアを実践すべく、親近感を覚えつつパーソナルスペースを侵害しない距離がどの程度なのか掴むこと、
椅子を設置することで実際に会話が誘発出来たか厳密に検証すること、
これらを実現することが出来ます。
特に最後の検証については、
(1) 会話が誘発できたかどうかをどのような指標を用いて評価するか、
(2) 会話を誘発することによって継続率へ実際に貢献したと言えるような根拠があるのか
など難しい問題もありました。ここについては後でちょっと語ります。

MMOはさらに身振り手振り表情、会話の内容だけではなく「会話の間」まで含めたデータ取れるため、
もう凄まじく面白いです。

数人人程度の社会実験に参加したことはありますが、データの収集が本当に大変でした。
カメラを四方八方に用意するのも非現実的で
（資金的にも設置的にも難しいし、カメラに囲まれた状態で普通の人は平常の行動しない）
人の表情見ても、笑ってるのか口空けてぼうっとしてるだけなのかの判別も難しいです。
また、観察してみると人間の行動は実に無駄な動きが多く、
重要な実験反応なのか単に頬が痒くて掻いたのかの判別も難しいです。
ひたすら動画を見て、被験者の瞬きの回数をカウントするとか、もう、もうほんまあかん、
何回カウントしなおしても、わいはがさつやから回数が一致せえへんねん、ほんまあかん、あかんねや！
インターネット最高！Webシステム最高！自動化最高！データ最高！

2．インフラや開発チームが整ってる

このビッグデータ時代、統計やるにもやれ並列分散処理システムのHadoopやら
色んなサーバからデータを滞りなく取ってくるシステムのfluentdやら、
とにかく色々システム関連の事もやらないといけません。
毎日TB級のデータが飛んでくるため、Excelでしこしこ手作業で集計なんてしてられません。
しかし私は統計がやりたいのであってHadoopのチューニングだとか安定運用だとかはとてつもなく不得手だし、
どう考えてもそれらを私にやらせるのコスパ悪いです。私の好きな経済学用語は比較優位*3です。
しかしビッグデータは扱いたい！
統計学的に正しいサンプリングするの結構骨のある作業なので、悉皆調査してしまいたい！
そんなわがままを叶えるべく、弊社は専門のインフラ部隊が存在するため、
私は何も考えることなくHiveというHadoopから簡単にデータ取ってこれるシステムに
「こういうデータ欲しいから、下さい！！」
ってクエリぶっこむとなんか良い感じにして出してくれる、すげー楽。
やったー、ポケベルを常に胸に入れていつ鳴るか怯えるような生活しなくていい！！
ありがとうインフラ部隊、ありがとうインフラ部隊！！

また、日々様々なKPIを把握したいのですが、
基本的なデータの集計や可視化は完全に定型処理なので、
一々手作業するのはダルイです、昭和かよって感じです。
なのでBIツールが欲しいです。
昼に出社したら、売上とかアクティブなユーザー数とかどのアイテムがどの程度売れたのかとか、
はたまた課金額レンジ毎の平均レベル差はどうなってるんだろうかとか、
そういうレポートが全自動で用意されてて
ブラウザからBIツール見たら全て把握できると昭和感が無くなります。
しかしBIツール作るとなると、サーバサイドもフロントエンドも作りこまねばなりません。
だるい…。
のでそこらへんの開発もやってくれるチームがあるととてつもなく便利です。
私はひたすら「こういう分析がしたいからこういうデータからこういう指標作ってくれ」
ってぐだぐだ注文を投げまくってたらなんか良い感じのBIツールが出来てた。凄い。
けど私の注文はまだ止まらない、Excelを開いたりキーボードを叩いたりすることなく、
全てマウスポチポチしてるだけで、いや、アニメーションとかで見るべき指標とか勝手に切り替わってくれ、
寝転んでるだけで重要情報が流れ込むようにしてくれって願ってる。
その期待に応えてくれるチームがある。大感謝である。
が、ここも後で言いたいことがある。

3．上司がやばい

転職して一番想像と違っててやばかったのが上司がやばいことで、今の上司が本当にヤバい。
上司は元プロデューサーで、完全にシステムや統計のことはわからない。
わからないので無茶な注文をすることもたまにある。
そんな時どうするか？
あんちべ「それ統計の原理的に無理です」
上司「お前が無理だと言うなら無理なんだろう、やめた」
で話が終わる。
マジで！？
やりたいことがあれば
あんちべ「こういうことやるべきだと思うんでやりたいです」
上司「お前がやりたいんならやる価値あるんだろ、やってみろ」
で話が終わる。
マジで！？
まぁ一言で言うと上司物分かり良過ぎ、裁量権与えてくれ過ぎ。二言になった。
そして何より大抵の依頼がすげー冴えてる。
私はなんだかんだ言ってゲーマーだったり広告マンだったりではないので、
根本からゲーマーの心に響く施策のアイデアなどを生み出したりすることは出来てない。
強いファシリテーション能力とアイデア、
両方を持ちつつそれでいワンマンにならないって中々出来ない。
データが面白いとかインフラ部隊が強いというのは入社前から知ってたけど、
さて上司がどうなるかは完全に未知数だったので、そこだけが懸念というか運任せだった。
ここまで上司に恵まれるとは想定外。
上司への依頼も大体通る、一点除いて。
これも後で話す。

4．フィードバックが得られる

分析するじゃん、施策出すじゃん、やるじゃん。
「受けました、売上アップです！！」
「全然受けなかった…売り上げダウンだ…」
どっちでもすぐに、そして明確なフィードバックが返ってくる。
これくっそ面白い。
これは研究室にいたら体験できなかったことだ。
統計学が金になるのやばい。

5．自分で何でもできる

これは人によると思うけど、私はデータの設計から何から自分でしたい。
「こういうデータがあれば分析できるのに～」とか言いたくない。
転職する時、受託じゃなくて自社サービス持ってる企業に対象を絞った。
んで今はデータの設計から分析から何から何までできる。
統計の父と呼ばれる超有名な統計学者フィッシャーの言葉で
「実験が終わってしまった後で統計学者に相談をするのは、検死解剖をどのように行なえばよいかを尋ねるようなもの」
というのがあります。
よーするに、
「なんか降ってきたデータをあれこれかき回してお便利ツール叩いてぽんっとなんとか値とか出す」
というのは統計屋の仕事ではないってことです、それはツールのオペレータさんです。
どのような目的で
どのようなデータを設計・収集し
どのような定義と評価指標で
どのような分析手法を用いて
どのように結果を相手に渡すか？
それら全部適切に設計・実践して初めて統計屋だという話です。
私は統計学に対し、溢れない才能の限りを尽くして真摯に学び適切に活用したいと思います。
データの整備から分析まで全部やります、全部だ。
うちはチーム体制を取ってはいるので、分業するのはいい。
しかしチームとして全部賄わなければならない、必ずだ。



長くなってきたので疲れた、日付も変わってしまった。
最後に言いたいことがあります。
うち来て一緒に働きませんか？
上の方で書いてた不満、それはもう突き詰めると単純に人手不足の一言に尽きます。
BIツール、さっき書いたようにまだまだ拡充したい。
だからエンジニアに来てほしい。インフラもフロントエンドもミドルウェアも全然足りない。
また、弊社はサービスいっぱいあるのに分析担当者が少なすぎる、マジ全然いねぇ！
そのため分析するサービスを本当に売れ筋の奴だけとか新規立ち上げの時だけとかに絞らざるを得ない。
無念だ、手つかずのデータが転がってる、コレ活用しないの統計に携わる者として本当に悪だ。
料理人が食材を腐らせたまま放置させてるようなもんだ。
情報には鮮度がある、腐らせてはいけない
だから統計学や機械学習、自然言語処理出来る人に来てほしい。
さらに、分析結果だけじゃ施策に落とし込めない。
私は正直アイデアマンじゃないし、ゲームや広告のことは全然知らない、
ユーザの心に刺さるアイデアなんて出せない。
だからプランナーにも来てほしい。
っていうか全体的に人が足りない、全然足りない。
優秀な学生さんの採用活動などに携わったり中途採用の面談したりしてるけど、
もう足りないの目に完全に見えてる。



具体的にやりたいけどやれないことを一つ挙げたい。
私はテキストマイニングやら自然言語処理やらにも片足突っ込んできたけど、
そんな程度じゃ全く歯が立たない問題がある。
談話解析だ。
MMOは空間・時系列データを取れる。ハッピーだ、取れるのは素晴らしいことだ。
会話データはハッピーの産物だ、
プレーヤーの飽き具合やら熱中要因やらそのプレーヤーの関心のあることなど色々含まれてる。
会話するには相手が必要だ、私は時々壁に向かって話すけどね。
で、メールの場合は誰と誰がいつどのターンで話しているか明確だ。
だけど、MMOは全くそうじゃない。
広い空間に沢山の人がいて、皆吹き出しのようなものにテキストを表示している。
twitterみたいに誰宛かを示すような@マークは無い。
一体誰と誰が話しているのかなっかなか分からないんだ！
MMOをやればわかるけれど、単に同時刻同じ場所に居れば会話参加者かと言えば全くそうではない。
かといって、一言も発しない人が会話に混ざってないかどうかというとそうとも言い切れない。
聞き役に徹していることもある。
また、会話参加者は自由に増えたり減ったりする。
となりの会話グループと混ざったり離れたりもする。
会話じゃなくて独り言をつぶやきあってる人がたまたま近くにいる場合もある。
会話じゃなくて野次を飛ばしてる場合もある。
っていうかそもそも会話参加者の定義とは何だ？
正直に言おう、今はクリアに「これは会話のデータだ！」とわかるものだけしか分析してない！
上手いこと空間/時間/テキスト内容のデータから誰と誰がどの程度会話しているかなどが知れないものか？
色々試したけど、ずっとこいつにぶつかってうーんうーんと唸ってる。
私の付け焼刃の自然言語処理スキルでは太刀打ちできそうにない。
リアルでの社会実験はそもそも参加者数が少なかったし、誰か一人が話せばまぁ普通他の人は聞く側に回る。
というか実験参加者全員が普通会話参加者になるからこんな苦労は無かった。
さぁ、こいつをどうしてくれようか？今のところ手が無い。




というわけで本当にぐだぐだ書いたけど、誰か一緒に働きませんか。
前例のない規模での社会実験してみませんか。
毎日面白おかしいです。
twitterやリアルで私の言動知ってる人ならわかると思いますが、
私が許容される程度なのでそうとう無茶の利く会社です。
ここで弊社の良い所をばんばん挙げてアッピールとかすればいいと思うけど、
まぁそういうのは人によって受け取り方それぞれだし私がそんなん言っても信用されないだろう。
そもそも私がここに入社した理由はデータが面白そうだったからであって
「社員みんな仲良しで充実した業務内容です！」とかに惹かれたわけでは全くない。
っていうかそんなの正直どうでもいい。
で、実際データが面白いことに関しては保証します、これだけは信用して欲しい、
私の統計に費やした決して短くない年月に賭けて誓います。
助けてくれ、やりたいこといっぱいあるんだけどやるだけのリソースが無いんだ、一緒にやって下さい。


あと何で急にこんな一緒に働こうぜとか言い出したかというと、
採用活動ひと段落したけどやっぱ全然人が足りねーじゃんという感じで青ざめた、プラス、
人事・上司に「何人か採用して下さいって言ったら通ります？」って聞いたら「全然通る」って話になったからだ。
人手が足りないのわかってる＋採用OKと言われた、じゃありくる～てぃんぐするしかない。

ちなみにりくるーてぃんぐするしかないと言っておきながら、
色々事情があって氏名/所属先を一般公開することは出来ない
（本当に申し訳ないけど、九州から東京までメンヘラさんに特攻された経験があるので…）。
勤務地は研究するなら基本渋谷、あとはエンジニアの方でしたら大阪とか九州とか。
こんな文章ですが、もし興味を持って頂けたなら、
twitter: @antibayesianまでご連絡ください。
氏名や個人情報は不要で、どういうことがやりたくてどういうスキルがあるか教えて頂けるとスムーズです。
あと経歴とか研究業績とか
ご連絡頂けたら社名と事業内容について説明させて頂きます。

これで上手いこといい人採用できたら人事は私に何かくれるべきだとも思う。
まぁとにかく不甲斐無い思いでいっぱいだけど、楽しくやってるよ。
もしよかったら一緒に働いてくれる人がいてくれるとハッピーだなって思ってる。
博士大歓迎！！博士じゃない人はみんなD進しよう！

こんな長文読んでくれてサンクス、機会あれば飯行きましょう。



追伸
https://twitter.com/todesking/status/407550502629437440
リスプ


追記
「連絡したいけど何を伝えればいいのかわからない」とのご意見頂きましたので追記しました。
何やりたいか、どういうスキルをお持ちかの2点をお伝え頂けましたら、
弊社の概要と頂いた興味関心にマッチする業務内容があればそれをご紹介させて頂きたいと思います。
よろしくお願いします！


■追伸
大変申し訳ありませんが2014/02/11時点で一旦採用活動終了（新卒対応せにゃ）致します。
拝承

*1:https://twitter.com/todesking/status/407552404616249344

*2:統計屋にとって一番重要、私の主な転職理由

*3:ググれ

まどか☆マギカ　叛逆の物語　ネタバレ

一行で分かるネタバレ

ワルプルギスはほむらで、ほむらがワルプルギス化したのはまどかを人間に戻すためだった。
以上。

詳細

　TV版で、魔法少女が魔女化するのを防ぐために己の身を犠牲にして神となり円環の理を形成したまどか。しかしTV版では具体的に円環の理、神とは一体何なのかの説明はなかった。円環の理は魔力を使い果たした魔法少女を魔女化させないような救済措置とだけ説明されたが、その具体的な仕組みとは？そもそも、インキュベーターがなぜ魔女化させてたかというと、魔女に至る際発生する莫大なエネルギーを求めてのモノだ。つまり、魔法少女には莫大なエネルギーが秘められている。だが円環の理ではその莫大なエネルギーがどうなるのか、その説明が隠されている。
　神とは、自分が思うがままに動く箱庭を作る存在に過ぎなかった。箱庭を作るために魔女化エネルギーを利用する必要があった。まどかの箱庭宇宙では、まどかの愛する人達が完全に幸せな世界を形成していた。そして箱庭以外の世界、つまり現実世界は完全に荒廃してた。ここでTV版の最後でほむらが荒廃した街を一人魔獣を倒しながら歩く姿に繋がる。戦いながらほむらは魔獣がどこから何のために発生しているのかの謎を探っていた。探索を進めるうちに魔獣が発生する要因がとあるエリアだと突き止めるほむら。そのエリアには存在しないはずの魔女の姿が。お察しの通り、エリアとはまどかの箱庭で、魔女はまどかである。魔獣はまどかの箱庭世界での魔力を使い果たした魔法少女のなれの果て。確かに箱庭内では魔女は存在しないが、現実は単に魔女が魔獣になっただけだ。箱庭内で魔力を使い果たしたさやかは魔獣として箱庭の外に出た。魔獣さやかとの戦いの中で魔獣、そして魔女の正体に気付くほむら。ほむらは箱庭の中のほむらにこっそりと暗号を送り、ついに箱庭内のほむらに自分が居る世界は箱庭であることを認めさせることに成功した。
　箱庭内のほむらは箱庭内の過去に飛び、箱庭内のまだ魔法少女化していないまどかに事態を説明する。「この幸せな箱庭を出て、現実世界で人間としてまどかは生き続けて欲しい」しかし、真実を知ったまどかは発狂し、現実世界のほむらは崩壊しそうな魔女まどかに襲われる。ほむら＝幸せな箱庭を潰す存在＝ワルプルギスと認識することによって歪んだ自我を取り戻した魔女まどか、現実世界のほむらと連絡が取れなくなった箱庭世界のほむらはワルプルギスが世界そのものを破壊しようとするのを止めざるを得ない。箱庭世界のほむらは「現実世界のほむら＝箱庭内のワルプルギス」と戦う。

そしてTV版エンドへ。そしてこの物語は終わり無く繰り返す。

そう、「円環」の理の真実とは…



この文章は映画見終わった後20分くらいかけて即興で書いたモノであり、内容は勿論嘘です。
私は本編をほぼ忘れてて（詳細）、映画の内容を理解出来なかったので、断片的なキーワードだけ拾って再構成した結果です。後本気でネタバレ見たければこちらを見て下さい　

Clojure/kuromojiでテキストマイニング入門　～形態素解析からワードカウントまで～

[テキストマイニング]

Clojureでテキストマイニングをしたい！という方がTLにいらっしゃったので、
Clojureという言語とkuromojiという形態素解析器を用いたテキストマイニング入門の記事を書きます。
この記事の通り手を動かすと、様々なテキスト、例えばアンケートの自由記述やブログ、twitterなどの文章に形態素解析を掛け、ワードカウントと呼ばれる、ある単語が何回出現しているのかを解析する手法を使えるようになります。これを利用し、出現単語を頻度順に並べてランキングを作るなどして、その文書の特徴を明らかにするなどが出来るようになります。
ある程度コンピュータを使えることは求めますが、プログラミングの前提知識はさほど求めていません。そのため、所々天下りなところ（ここはとりあえずこうやってください！と説明無しの記述）もありますが、ご容赦ください。


形態素解析とは？


　形態素解析とは、1.文を形態素という意味の最小単位に分割し、2.各形態素を原型に復元し、3.各形態素に品詞を付与する処理です。
形態素とは何かを議論しだすと専門的になりますので、「文章を単語に分割する処理」だとざっくり認識して頂ければこの記事読むには十分です。
　原型復元とは、語形変化・活用している語を原型に復元する処理です。
これもまた説明しだすと大変長くなるため、例えばワードカウントする際、「食べる」が何回出たか知りたいけれど、文章中には「食べる」以外にも「食べた」「食べない」などが出現するのでそれらを「食べる」にまとめてカウントしたいなどという時に使います。
要件によっては原型復元を行わないケースもあります*1。
　品詞付与を行うことによって、文章から名詞だけを取り出したり形容詞だけを取り出したりなどが可能です。大抵の日本語の文章では、品詞を絞り込みせずにワードカウントを行うと助詞などが上位を占めることが殆どです。分析の目的にもよりますが、基本的に対象とする品詞は絞った方が良いでしょう。


kuromojiとは？


形態素解析をするためのツールです。形態素解析器と呼ばれます。
本来であれば、形態素解析を行うには形態素解析器だけではなく、形態素解析器が文をどのようにして形態素に分割するか・品詞を割り当てるかなどの情報源である専用の辞書を用意しなければならないのですが、kuromojiは基本的にはオールインワンパッケージで、kuromoji一つあれば形態素解析が出来るという、初心者にはとても優しいツールです。


clojureとは？


神の言語です(ｷﾘｯ。説明しだすと意味不明に長くなるので割愛します。神の言語だと認識すれば十分です。
incanterとは？

神の言語Clojure製の統計解析ライブラリです(ｷﾘｯ。本稿ではグラフ描くときにちょこっとだけ用います。


準備 -環境設定-


Clojureを使うにはleiningenというビルドツールを用いるととっても簡単に環境構築が出来ます。
Macでのleiningenインストール手順を書きます。
1. ターミナルを開いて brew install leiningen と入力。
2. おしまい

はい！！

Mac以外の環境は下記をご覧ください。
windows版：http://antibayesian.hateblo.jp/entry/20120122/1327236946
ubuntu版：http://antibayesian.hateblo.jp/entries/2011/07/30
sublime textでClojureを書く：http://antibayesian.hateblo.jp/entry/20130501/1367406979


インストール出来たら、ターミナルで lein new kuromoji と入力すると、kuromojiというフォルダが生成され、
その中に色々環境が自動で良い感じに設定されています。
そのフォルダの中にproject.cljというファイルがありますので、それを次のように丸ごと上書きして下さい

(defproject kuromoji "0.1.0-SNAPSHOT"
  :description "kuromoji test"
  :url "http://example.com/FIXME"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.5.1"]
                 [incanter "1.5.1"]
                 [org.atilika.kuromoji/kuromoji "0.7.7"]]
  :repositories [["Atilika Open Source repository"
                  "http://www.atilika.org/nexus/content/repositories/atilika"]]
  )

他はどうでもいいですが、dependenciesとrepositoriesと書かれたところだけは弄らないで下さい。
完全に天下りで申し訳ないですが、こうやるとkuromojiやincanterが自動でインストールされるので、とりあえず今はこういうお作法だと思ってスルーしてください。
project.cljを書き換えたら、そのフォルダ内でlein replと打つと、dependenciesに書かれたファイルがインストールされて、準備万端になります。

形態素解析に挑戦！


　環境構築が終わったら、そろそろプログラムを書いてみましょう。
先程ターミナルでlein replとやったので、Clojureプログラミングが出来る状態になっていると思います。今利用可能な状態になっているREPLとは、コマンド打ったら即座にそのコマンドの結果を返してくれるものて、対話的環境と呼ばれています。REPLが動くかどうかちょっと次のテストをしてみましょう。もしここで何かエラーが発生していれば、leiningenかproject.cljの設定が何かおかしい可能性があります。
　おかしかったら、大抵の方は多分見てもわからないと思いますので、twitterなどで「なんかエラー吐いて辛いんだけど！」と騒ぐと、Lisperという人種はわらわら寄ってきて必要以上の熱心さで解決しようとしてくれるので、どんどん騒ぐと良いと思います。

;clojure環境整ってるのかのテスト

;kuromojiを使えるよう準備する処理
(ns intro-kuromoji.tokenizer
  (:import [org.atilika.kuromoji Token Tokenizer]))
;incanterを使えるよう準備する処理
(use '(incanter core stats charts io))

(+ 1 2 3 4 5 6 7 8 9 10)
;>55と表示されます。+を何個も書かなくて良くて便利ですね

(* (+ 1 2) (+ 3 4))
>21と表示されます。先に中の括弧の中身が計算され、徐々に外の括弧の処理に移ります。ここではまず中の括弧(+ 1 2)が3になり、(+ 3 4)が7になり、結果、(* 3 7)で21となるわけです
(view (bar-chart ["a" "b" "c"] [10 20 30]))
;棒グラフが表示されます。このように簡単にデータを可視化することが出来ます


;ファイル入出力
;ファイル書き出し
(spit "c:\\lein\\坊ちゃん.txt" "親譲の無鉄砲で小供の時から損ばかりしている。小学校に居る時分学校の二階から飛び降りて一週間ほど腰を抜ぬかした事がある")
;ファイル読み込み
(slurp "c:\\lein\\坊ちゃん.txt")
;>親譲の無鉄砲で小供の時から損ばかりしている。小学校に居る時分学校の二階から飛び降りて一週間ほど腰を抜ぬかした事がある
;と出力される。このように、ファイルの書き出しも読み込みも1行で簡単です

ちゃんと動いてるようでしたら、いよいよREPLに次のプログラムをコピペして下さい。

;kuromojiを使えるよう準備する処理
(ns intro-kuromoji.tokenizer
  (:import [org.atilika.kuromoji Token Tokenizer]))
;incanterを使えるよう準備する処理
(use '(incanter core stats charts io))

;形態素解析するための関数を定義。今後、この関数を呼び出して文を入れるだけで形態素解析出る！
(defn morphological-analysis-sentence ;関数名
  [sentence] ;引数。形態素解析の対象となる文を受け取り、sentenceという名前を付けてあとで使いまわせるようにしている
  (let [^Tokenizer tokenizer (.build (Tokenizer/builder))] ;kuromojiのトークナイザ（形態素解析機能）をtokenizerという名前で呼び出せるようにする
    (doseq [^Token token (.tokenize tokenizer sentence)] ;文をkuromojiで形態素解析し、出てきた形態素と品詞などの情報を、一つ一つ取り出す
      (println (str (.getSurfaceForm token) "\t" (.getAllFeatures token)))))) ;取り出した原型復元済みの形態素と品詞などの情報を画面に表示する

;形態素解析テスト
(morphological-analysis-sentence "黒い大きな瞳の男の娘")

;出力結果。このように出たら成功！
>黒い    形容詞,自立,*,*,形容詞・アウオ段,基本形,黒い,クロイ,クロイ
>大きな  連体詞,*,*,*,*,*,大きな,オオキナ,オーキナ
>瞳      名詞,一般,*,*,*,*,瞳,ヒトミ,ヒトミ
>の      助詞,連体化,*,*,*,*,の,ノ,ノ
>男      名詞,一般,*,*,*,*,男,オトコ,オトコ
>の      助詞,連体化,*,*,*,*,の,ノ,ノ
>娘      名詞,一般,*,*,*,*,娘,ムスメ,ムスメ
>nil

と、このように形態素解析が出来ました！
「黒い大きな瞳の男の娘」を好きなように変えて、形態素解析がうまくいくかどうか確認してみてください

基本的な形態素解析が出来たので、今度は名詞だけに絞って取り出してみましょう。

;名詞だけ抽出版
(require '[clojure.string :as str]) ;文字列処理の便利機能を使えるように呼び出し
(defn noun? [parts] (= "名詞" parts)) ;名詞かどうかをチェックする関数を作成
(def not-nil? (complement nil?)) ;後述するフィルタ用の処理

(defn morphological-analysis-sentence
  [sentence]
  (let [^Tokenizer tokenizer (.build (Tokenizer/builder))]
   (filter not-nil? ;値をフィルターかけて通ったものだけ抽出するという処理。ここではnilではないものだけを通す
    (for [^Token token (.tokenize tokenizer sentence)]
      (if (some noun? (str/split (.getPartOfSpeech token) #",")) ;ある形態素に付与されている複数の品詞情報の中に「名詞」が含まれているかチェック。含まれていたら形態素を渡し、含まれていなければnilという空っぽなものを渡して「名詞が入ってなかったよ」と示す
        (.getSurfaceForm token))))))
(morphological-analysis-sentence "僕はウナギだし象は鼻が長い")

;出力結果
>("僕" "ウナギ" "象" "鼻")

うまいこと名詞だけを抽出することが出来ました。
これを利用してワードカウントしましょう！

ワードカウント


　青空文庫から坊ちゃんのテキストを取得して一部分を切り出したものに坊ちゃん.txtとでも名前を付けて適当なフォルダに保存して下さい。
ここではc:\leinフォルダに坊ちゃん.txtという名前で保存したとします。
次のプログラムをコピペして下さい。

(defn morphological-analysis-file
  [file]
  (let [^Tokenizer tokenizer (.build (Tokenizer/builder))]
   (filter not-nil?
    (for [^Token token (.tokenize tokenizer (slurp file))] ;環境動作テストでも紹介したslurpというファイルを読みだす関数を使っています
      (if (some noun? (str/split (.getPartOfSpeech token) #",")) 
        (.getSurfaceForm token))))))

(def natume (morphological-analysis-file "c:\\lein\\坊ちゃん.txt"));後でもこの結果を使いまわす為、結果にnatumeという名前を付けて持っておく
;>("親譲り" "無鉄砲" "供" "時" "損" "小学校" "時分" "学校" "二" "階" "一" "週間" "腰" "事" ...なんかたくさん

ファイルからの形態素解析が成功しました。
次に形態素をカウントして、頻度順に並べます。

;ほぼ引用させて頂きました https://github.com/thanthese/count-word-frequencies/blob/master/count-words.clj
(defn word-count [words]
 (reduce (fn [words word] (assoc words word (inc (get words word 0)))) ;ちょっと難しい処理なので、こうやれば頻度順に並び替え出来るんだなーってアレがそれですよ。
  {}
  words))

(def wc_result (reverse (sort-by second (word-count natume))));ワードカウントした結果を頻度で昇順に並び替えたあとに逆順にして（つまり大きい順にして）、wc_resultという名前をつけて持っておく
(def top10 (take 10 wc_result)) ;全ワードの中から頻度大きい順に10個取得して、それにtop10と名前を付けて持っておく
(view (bar-chart (keys top10) (vals top10))) ;棒グラフで頻度ランキングトップ10の語を描画
(save (bar-chart (keys top10) (vals top10)) "c:\\lein\\natume.png" :width 600) ;png形式で保存。横幅600ピクセルという指定を入れている

;ついでにzipの法則（n番目に多く現れる単語は、1番多く現れる単語のn分の1の確率で現れる）が成立しているか確認してみる
(def top100 (take 100 wc_result)) ;全ワードの中から頻度大きい順に10個取得して、それにtop10と名前を付けて持っておく
(save (bar-chart (keys top100) (vals top100)) "c:\\lein\\natume_zip.png" :width 600)

保存した画像は以下のようになります*2。
f:id:AntiBayesian:20130910230500p:plain
f:id:AntiBayesian:20130910230512j:plain

というわけで、Clojureを使うととっても簡単に形態素解析やワードカウントが出来ました！
是非皆さんもやってみてください。
ご自分のtweetやブログ記事などでワードカウントを掛けて見れば、自分がどんなことについて多く呟いているのかなどがわかって面白いと思います。
最後に私の鍵垢のツイートのワードカウント結果を表示して終わりたいと思います
f:id:AntiBayesian:20130910230525p:plain



追記。
kuromojiで良く使うメソッド一覧です。
getAllFeatures、getAllFeaturesArray:トークンの全情報（品詞と読みと原型）を返します。後者は配列でくれます。
getBaseForm:原型復元済みの形態素を返します
getPartOfSpeech:品詞を返します
getSurfaceForm:分かち書きした結果です。つまり原型復元してない状態です
getReading:読みを返します
isKnown、isUnknown:辞書に登録されているか否かを返します。本稿では説明しませんでしたが、実用する場合は辞書整備必要です

*1:特定の活用形がどの程度発生するか知りたいときなど。例えば飲食店の評判がネガティブかポジティブかをテキストマイニングで明らかにしようとする時、未然形「～ない」を否定的表現と捉え、「食べる」と「食べない」、「またあの店に行く」と「またあの店に行かない」を分けて、前者をポジティブ、後者をネガティブ表現としてカウントするなど

*2:アップしてから気付いたけど「の」が名詞に来てるの、なぜだ…