2012年7月30日月曜日

読書した。&サービス分析に関するメモ書き。

今日は代休だったので、のんびりと過ごしていた。朝は銀行関連の手続きをして、昼は概ね勉強していた。数学ガールのガロア群論を半分ほど読んだ。また、アルケミストを読み始めた。

最近データに触れてばかりいる。モデルを考えるときは数学的な世界に一回潜り込まなければならないが、やはり事業目線で何が本質的に必要なのかを洞察する力というのは大事だということも改めて感じている。頭のトレーニングとして、もし自分が今もサービスを運営していたら何を分析し、何をしていただろうということを風呂に入りながら考えていたので、メモしておく。前提として、

  • 自分たちのサービスのゴールがわかっている

ものとする。

ユーザ行動の分析に関する再考

まずは、ユーザを追いかけよう。自分のページでユーザが何をやっているのかを確かめよう。当時はmixpanelやGoogle Analyticsを使って解析していたが、自分たちだからこその追いかけ方がある。それをアプリケーションの設計段階からできれば組み込んでおくこと。(脊髄反射で組み込んでしまうくらいがちょうどいいと最近は思っている。)

具体的にはアプリケーションログを出力して、その解析を適当な周期で行うことになる。自分たちで解析しよう。ユーザの行動はログでしか追えないと思うくらい、ログを追おう。実際のところ自分たちのDBに入っているユーザのデータとログを組み合わせれば、全てのユーザ行動はつかめる。

チームメンバーに共有する。そしてまた仮説を立てる。

問題はどこを問題とし、課題とし、紐解いていくかだ。まずは鳥瞰して、次に虫の眼で見よう。全体の傾向を掴んで、それをまずはチームに共有しよう。チームに共有したら、気づきが絶対にあるはずだ。それを元に詳細な分析をしていこう。ユーザがどの程度アクティブであるかを知ろう。どの程度というのは時間軸で見れば良い。時間軸で見て、ある傾向があれば次はユーザ属性ごとに見よう。そして、サイトに特化したユーザ属性について、さらに切り分けよう。どういうカテゴリにコンテンツに惹きつけられているユーザが、どういう行動をしているだろうか。何か特徴は無いだろうか。

ユーザ目線からコンテンツを分析することに関する再考

ユーザ行動を追えたら、コンテンツを分析していく。

コンテンツのカテゴリ分けは必要か?

コンテンツの分析は明示的なカテゴリに左右されがちだが、運営側の都合で設けたカテゴリは本質的ではない場合もある。明示的なカテゴリを一旦忘れて分析することも必要になってくるだろう。

カテゴライズされているものについては、まず自分たちで作ったカテゴリが必要であるかどうかを検証しよう。カテゴリというのはユーザに運営側から伝えるメッセージだ。ユーザは勝手にカテゴリ分けされているものをカテゴリとして判断してしまう。でもそれは理にかなった振る舞いになっているだろうか。大いに検証する必要がある。大抵の場合、サービスにはコンテンツが少ないのだ。ただただ、デザイン上の理由で、運営上の理由で、綺麗に見せたいがためにカテゴリ分けするほうがよっぽど損をするときだってあるのだ。

ユーザに基づいたコンテンツのあり方を検討するために

どのユーザが何を見て、どのようなコンテンツについてよく見ているだろう。

ユーザの趣向性が分かったと仮定して、ユーザ行動からコンテンツに加算していく。そのコンテンツは、なぜそのユーザに好かれたのか、反応を示しているのかということについて、仮説を立てよう。それはコンテンツを分析するためのヒントになる。

また、ユーザ自身から発せられたメッセージからヒントを得るのも良い。たとえば、検索。たとえば、コメント。ユーザが自由に行動する場所があって、考えていること、もしくは望んでいることを書いてくれているなら、それを活かさない手は無い。

分析はユーザに見えなくてよい。シンプルに快適に。

ユーザが欲しい物を、とにかく一番に出そう。クールさとパーソナライズの両立は大変だが、ユーザがそのページに来た瞬間にユーザのほしいものを届ければ、ユーザをファンに出来る。「そこにいけば面白いものが待っている」のか、「すぐに便利なものを見つけられる」のか、「安くて良い物が見つかる」のかどれでも良いのだが、ユーザのほしいものをそのサービスでだけ届けてあげる。できれば簡潔に。そうすれば、また来てくれる。

分析した結果は、チームにとっても自分にとっても、さらに有益なものとして返ってくるだろう。


書いてはみたが、一般に定義されている言葉を使わないで平易に説明するのはやはり難しい。こういう考察は良くない。

2012年7月29日日曜日

今日やったこと

今日はRの勉強をしつつ、分布について調べていた。手元で手軽に分布に応じた乱数を発生させられるのは、勉強のためにとても良い。

それと、ちゃんと調べてはいないが、EiganとLAPACKというのを知った。


まったく統計には関係ないが、FuelPHPの2.0のalpha/betaが出ていた。 

明日は休みなので、引き続きRの勉強をする。あとは数学ガールのガロア群論も読み終えたい。

2012年7月24日火曜日

Rのマインドマップ

とてもわかりやすいマインドマップがあったので紹介します。Rに関するマインドマップです。よくまとまってます。

R: A Language and Environment for Statistic... - MindMeister 思考マップ http://www.mindmeister.com/ja/37638437/r

Rの起源となったS言語についてや、Rが成り立っているエコシステムについてわかりやすくまとめられています。知らなかったツール類もまとめて見つけることができました。 

チーム開発について最近思うこと

久々にとあるチームにジョインして、後から入る人間としてプロダクト開発に携わる機会に恵まれました。

今までは自分の作ったシステムに人を受け入れるというケースがほとんどだったので、今こういうフェーズで客観的にチーム開発について考える機会を設けられたことは良いことです。自戒を込めて、振り返ります。



何かをシステムを作るとき、自分で全体像を掴めない状況で開発などできません。設計も出来ません。誰かの権限の中で、部分的に触るのも無理です。「この範囲はあなたの責任でやってください」と言われるのが一番ありがたいし、やりやすいのです。

任せられている範囲内であれば、自分なりにそのプロダクトに則しつつ、少しずつ部分的に担当している範囲を改良していけるものだと思うのです。しかし、どの範囲まで責任をもてば良いのかわからずに、どうして自分が考慮すべき範囲を判断することができるのでしょう。そういう憂慮すべきことが頭の中を支配して、開発の手は止まってしまいます。

なんだか最近はそういう環境に苛まれています。そういう環境でなんとか自分のやるべき範囲を無理やり自己判断して取り組んだ後、何らかの不具合があれば容赦なく責任は降ってくるのです。そんなものは理不尽以外の何物でも無いです。

僕がチーム開発時に望むのは、
  • どの範囲に責任を持つべきか明確であること
  • サンドボックスが提供されていること
  • 「改善」については常に受け入れ可能であること
  • なぜその範囲を開発しなければならないかを知れる、もしくは調べられる環境であること
  • どこまでが取り消し可能で、どこからが取り消し不可能な操作なのかが明確になっていること
ということです。

どこからどこまでを壊していいのか。どの範囲を私は改善すれば良いのか。そしてどこまで改善して良いのか。何を考慮すべきなのか。システムの妥当性を検証するために十分な情報は私に与えられただろうか。そしてこの操作はクリティカルなものなのだろうか。

そういうものを提供するということは、安心して健全な開発をするためには欠かせないものなのだと改めて感じている次第です。

参考:
Joel on Software - http://japanese.joelonsoftware.com

2012年7月16日月曜日

WordPressからBloggerに移行してみました。