昨年、一部の皆様の熱狂的支持を受けたマンホーラー実態調査、2015 年の今年もやります！　世界最大の位置情報付きマンホール画像サービス「マンホールマップ」の 2015 年分の利用実態を調べました。

以下のデータは Google Analytics を使った 2015/Jan/01 から 2015/Dec/19 までのアクセスデータを元に作成しています。信じられない人がいるかもしれませんが、かなりのビッグデータ解析です。


2015年　マンホールマップ利用概要

マンホールサミットとマンホールナイト、２つの大きなイベントとその直後にアクセス数のスパイクが見られます。ある意味で「想定通り」の利用結果になりました：



なお、１回のセッションで平均 4.65 ページが参照されています。直帰率は 56.77% で、平均セッション時間は4分22秒。つまり「１回見に来た人は、その後4分22秒間滞在して、その間に４～５ページ見てくれる」ようなサイトになっています。ウェブサービスページとしてはなかなかの滞在時間と近隣ページへの誘導が実現できている方だと思っています。


利用者の傾向

グーグルのプロフィール予測に基づいたマンホールマップ利用者の推定年齢はこのようになりました：



↑順位は昨年と変わっていません。意外と（？）若い層がマンホールマップを使っていると見るべきか、マンホールマップを使っている人は（グーグル的に）「若い！」と推測・分類されるような行動プロフィールなのか、その辺りは謎ですが、マンホールマップおよびマンホーラーの将来は明るいと言えます。

次に利用者の性別です：



↑性別に関しても若干男性が多いままで、「合コンが成立するくらいの男女比」になっています。非常にバランスよく推移しています。ただし、出会いの場になっているかどうかは知りません。

既存ユーザーと新規ユーザーとのバランスもいい感じでした：



↑既存ユーザー 41.3% に対して、新規ユーザーが 58.7% 。この差は昨年よりも開きました。新しいユーザーの開拓にも成功し続けていることが分かります。

最後に利用者の趣味・興味分野を見てみましょう：



↑これは先程の推定年齢にも関係しているかもしれませんが、マンホールマップ利用者の趣味・興味分野が比較的アクティブなものになっています。それもあって、実年齢はともかく若いと判断される人の趣味になっているのかもしれません。加えて、マンホーラーの IT 率は相変わらず高いようです。


利用者の国、言語

マンホールマップのアクセスログに残されたユーザーエージェント情報を元に、この一年間でどのような国から利用されているのかを図示しました。１回でもアクセスが記録されていた国には青っぽい色が付けられています：



↑主要国はほぼ含まれているといっても過言ではありません！

実は日本を含めて65ヶ国からのアクセスが記録されていました。国別アクセス数では日本がダントツですが、では２位以下はどのようになっていたのでしょうか？




↑２位はアメリカ（昨年７位）でした。３位は（おそらくクローラーボットなど、ヘッダ情報のないアクセスだったため）国名が取得できないアクセスだったので無視します。昨年２位のロシアは実質３位でした。　なんというか、世界中から参照されていることを実感します。

ということはマンホールマップの国際対応を意識する必要が出てきます。マンホールマップはリリース当初から英語対応されていますが、更なる国際化を急ぐ必要があるのでしょうか？　ではどの言語に対応すべきか、という問題をアクセスログに残された言語設定から見てみると、こんな結果になりました。ロケールの設定方法が統一されていないので少し見にくいかもしれませんが、生データだとこんな感じです：

1	ja-jp	日本・日本語
2	ja	日本語
3	en-us	米国・英語
4	（取得不可）
5	en	英語
6	pt-br	ブラジル・ポルトガル語
7	zh-tw	台湾・中国語
8	ru	ロシア語
9	zh-cn	中国・中国語
10	c	Cロケール（英語）
11	en-gb	英国・英語
12	es	スペイン語
13	de-de	ドイツ・ドイツ語
14	en-au	豪・英語
15	es-es	スペイン・スペイン語
16	fr	フランス語
17	fr-fr	フランス語
18	it-it	イタリア・イタリア語
19	ko-kr	韓国・韓国語
20	sv-se	スウェーデン・スウェーデン語

↑１位と２位は日本語、３位と５位は対応済みの（米）英語、４位は取得できないものだったので無視します。　残りの順位を見ると次はポルトガル語、中国語、ロシア語対応が必要なのでしょうか？　ヤバい、知らない言語ばかりだ・・・


日本国内の市区町村別アクセスランキング

次は日本国内の市区町村別アクセスランキングです：

1	大阪市
2	港区
3	新宿区
4	横浜市
5	名古屋市
6	京都市
7	（東京都）中央区
8	札幌市
9	千代田区
10	千葉市
11	渋谷区
12	さいたま市
13	（取得不可）
14	福岡市
15	世田谷区
16	川崎市
17	神戸市
18	新潟市
19	加古川市
20	相模原市

なんと１位は昨年はベスト１０圏外だった大阪市！　関西マンホールサミットの影響なのでしょうか？今回のデータで、これが個人的に一番驚きました。

なお上記表では２０位まで載せていますが、２１位は私の家がある船橋市でした。家からも結構見ていたつもりだったのですが、２０位にも入ってなかったとは・・・　マンホーラーが東京周辺に集中する傾向が少しずつ崩れて、全国的に広まりつつある感触を感じます。


利用環境

次にマンホーラーの利用環境です。まずはブラウザから。実質的に上位６つまでが順位といえる結果でした：

1	Chrome	30.08%
2	Internet Explorer	28.01%
3	Safari	16.08%
4	Firefox	8.49%
5	モバイルSafari	7.55%
6	モバイルChrome	7.14%
7	（不明）	0.90%
8	Opera	0.87%
9	Edge	0.55%
10	Amazon Silk	0.06%

１位は推奨環境でもある Chrome でした。昨年は（非推奨環境の）Internet Explorer が１位だったのですが、地道な啓蒙活動が実りつつあるとポジティブに解釈させていただきます。とはいえまだ２位。あと Edge も９位に顔を表しています。10位のは知らないな・・・

そして OS 別だとこんな感じです。実質は上４つが順位で、５位以下は１％未満です：

1	Windows	49.26%
2	iOS	21.39%
3	Android	17.61%
4	Macintosh	9.75%
5	（不明）	0.96%
6	Linux	0.90%
7	Nintendo Wii	0.04%
8	Chrome OS	0.02%
9	NTT DoCoMo	0.02%
10	BlackBerry	0.01%

ある意味想像通りで、上位４つは昨年と変わっていません。ただ Linux デスクトップからのアクセスが思っていたよりも少なかった印象です。あとは Wii やドコモのガラケーから使っている人もいるんですね。ちゃんと見れてるのかな・・・

※BlackBerry のアクセスログはたぶん自分です


まとめ

以上の内容から、2015 年のマンホーラーの実態はこのようなものであったと推測されます：

・相変わらず女性に人気があり、新規ユーザーも増え続けている
・「若いですねぇ」とか「そんな歳に見えませんよぉ」と言われているような人がマンホーラー
・マンホーラーは世界中にいるし、日本国内でも東京一極集中から分散しつつある
・マグロが止まったら死ぬように、InternetExplorer を使ってないと死ぬ人がいる


さて、次回のブログでは 2015 年のマンホール蓋別年間アクセスランキングを発表します！ 2015 MVM(Most Variable Manhole) に選ばれるのはあの人気蓋なのか！？それとも昨年のような伏兵が現れるのか！？　そして期待の新人賞の行方は！！？？　　お楽しみに！


（追記 2015/Dec/22）
続きはこちら

タグ ：

manhole

map

manholemap

google

analytics

2015

IBM Bluemix を通じて提供されているコグニティブサービス（認識型人工知能）API の１つに Tradeoff Analytics があります：



この API を理解するにはデモサイトを参照していただくのがいいと思います：
http://tradeoff-analytics-demo.mybluemix.net/

このデモサイトでは「一覧の中で、自分にあったスマホはどれか？」という命題を、その人が重要視するスペックポイントを明確にした上で候補を上げていく、というものです。

スマホはメモリは多い方がいいし、バッテリーは多い方がいいけど、そうすると重量が重くなります。でも重量は気にする人もいればいない人もいます。また価格は安い方がいいに決まっていますが、メモリやバッテリー、重量などの要素と比べて重要度が高いのか低いのか、は人によって異なってきます。　全てを満たすパーフェクトなスマホはそうそう出てこないでしょうから、結局はどの要素を重要視するかでトレードオフを考えることになると思いますが、どの要素を重要視した場合はどのような結果になるか、を判断してくれる、そんな API です。

例えば上記デモサイトを開くと、デフォルトでは以下の様な表が表示されます：



一番上の列がヘッダで、２行目からがスマホの候補リストになっています。表の３列目以降がスペックになっていて、３列目は価格（小さい方がいい）、４列目はRAMメモリ量（多い方がいい）、５列目はスクリーンサイズ（意見が別れるところですが、ここでは大きい方がいい）、６列目はカメラの画素数（多い方がいい）、７列目はメモリ量（多い方がいい）、８列目はバッテリー容量（多い方がいい）、そして９列目は重量（少ない方がいい）となっています。このうちデフォルト状態では価格、スクリーンサイズ、重量の色が緑になっていて、今はこの３点を重要視する人にとってのトレードオフを解析する指定になっています。

もしもこれら以外の点を重要視したい場合は表右下の "View/Edit JSON" と書かれた箇所をクリックして JSON の内容を変更します。例えば「スクリーンサイズは気にしないけど、バッテリー容量は重要！」という場合は以下のように値を変更します。　まずスクリーンサイズは今回意識しなくていいので、JSON 内の columns の中で "key" 値が "screen_size" になっている項目の "is_objective" 値を true から false に変更します。この "is_objective" の値が true のものはトレードオフの考慮に含めて、false のものは含めない、という指定です。なお "goal" 値が "MAX" のものは「（メモリ量など）大きい方がいい」という値、"MIN" のものは「（価格など）小さい方がいい」という値だという指定です：

{
  "key": "screen_size",
  "full_name": "Screen size (inch)",
  "type": "NUMERIC",
  "is_objective": false,
  "goal": "MAX"
},

続いてバッテリー容量はトレードオフに新たに含めたいので、同様にして "key" 値が "battery" になっている項目の "is_objective" 値を false から true に変更します：

{
  "key": "battery",
  "full_name": "Battery (mAh)",
  "type": "NUMERIC",
  "is_objective": true,
  "goal": "MAX"
},

この状態で編集エリア右下の "Back to table" をクリックすると、価格とバッテリー容量と重量の３点が重要視指定された状態の表が表示されるはずです。なお、これら以外でも JSON を変更することで候補スマホの名称や各数値を変更することもできます。全て JSON フォーマットで指定されていることを確認しておいてください：



重要視する項目が決まったら、画面右下の "Analyze Sample Data" と書かれたボタンをクリックして、トレードオフを計算します：



すると画面下に以下のようなグラフが表示されて、指定した３項目でのトレードオフを考えた結果が表示されます。各スマホアイテムがそれぞれの要素を意識した時にどの位置にあるのか、ということが視覚化されています：



例えば、ここでバッテリー項目の下限のスライダーを 1000 から 1500 近くまで移動させると、「バッテリー容量が指定値(1500)以下のものは考慮しない」という指定をしたことになり、画面上部付近にあったいくつかのバッテリー容量の少ないスマホが画面から消えます。これで更に絞込みやすくなります：



・・・と、なんとなく「トレードオフ解析」の意味がお分かりいただけたでしょうか？　IBM Bluemix で用意されているのは、このような解析を行うための（与えられた条件から、上記の結果グラフを書くための）API が用意されている、という点が特徴です。つまり上記デモサイトのようなことを皆さんの作るアプリケーションの中でも実現できるようになる、ということです。

実際にこの API を利用するには、IBM Bluemix で上記の Tradeoff Analytics サービスをランタイムアプリケーションにバインドして資格情報を確認し、利用のための username と password を取得しておく必要があります



ここまで準備できれば API そのものは単純です。取得した username と password を使って Basic 認証を行い、https://gateway.watsonplatform.net/tradeoff-analytics-beta/api/v1/dilemmas に対して、解析させたい JSON（上記の Edit JSON をクリックして編集したもの）をポストするだけです。

成功すると、以下の様な JSON が結果として返ってきます：

{
  "problem": {
    "columns" : [ {
      "key" : "price",
      "format" : "",
        :
        （ポストした JSON の内容）
        :
  },
  "resolution" : {
    "solutions" : [ {
      :
      :
    } ],
    "map" : [ {
      "nodes" : [ {
        "coordinates" : { "x":0.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":1.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":2.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":3.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":4.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":5.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":6.0, "y":0.0 },
        "solution_refs" : [ "5" ]
      }, 
        :
        :
      } ],
      "anchors" : [ {
        "name" : "price",
        "position" : { "x":0.0, "y":0.0 }
      }, {
        "name" : "battery",
        "position" : { "x":4.5, "y":7.8 }
      }, {
        "name" : "weight",
        "position" : { "x":9.0, "y":0.0 }
      } ],
        :
        :
    }
  }
}

結果の JSON の細かい内容は以下のリファレンスを参照していただきたいのですが、大きく３つの箇所を参照することになります。　１つ目は "problem" で、この中にポストした JSON がそのまま記述されているはずです。つまり「この問題に対する実行結果である」ことを示しています。

２つ目は "resolutions" の中の "map" で、ここに散布図を書いた時の各点の座標（x,y）が示されており、またその座標位置に相当するアイテムがあった場合は "solutions_refs" という配列値で示されます。例えば上の例ですと ( 6.0, 0.0 ) の位置に "key" 値が "5" に相当するアイテムがある、ということになります。

最後の３つ目は "resolutions" の中の "anchors" で、これが指定した各トレードオフ要素（この例では価格とバッテリー容量と重量）が散布図上のどの位置にあるかを示しています。


後はこの結果を受け取った側でどのように見せるか、という問題になります。チャート描画の API を使ってもいいし、Canvas を使って自分で記述してもいいと思います。ここから先は開発者やデザイナーの腕の見せ所と言えます。そういう意味ではここのデモサイトはなかなか良くできてますよね。


というわけで、これまでにこのブログで紹介してきたコグニティブサービスとは少し（特に実行方法の面で）毛色が違うサービスと言えます。API 実行時に指定フォーマットの JSON を作る必要があるのが少し面倒ですが、トレードオフを意識する要素と、それらの値は大きい方が嬉しいのか小さい方が嬉しいのかの情報、そしてアイテムの一覧を JSON にしてポストすれば結果が返ってくる、というものです。REST API そのものはシンプルなのでエクセルのような表計算からも実行できると思っています（エクセルだと逆に結果の視覚化が難しいかも・・）。


なお、ここで紹介した Watson Tradeoff Analytics API について、詳しくは API リファレンスを参照してください：
http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/apis/#!/tradeoff-analytics
 

タグ ：

ibm

bluemix

watson

tradeoff

analytics

json

api

最近は少子化の影響で事情が少し違うかもしれませんが、自分が中高生だった頃の１クラスはおよそ40～45人でした。そしてクラスには「班」という制度？があり、クラスの中をいくつかのグループに分けて活動することが多くありました。自分の場合は１つの班に5～7人が割り当てられていたと記憶しています。

班は便利です。例えば掃除などのローテーションを行う単位になったり、ちょっとしたグループディスカッションを行う場合のグループになったりします。 これをあらかじめ決めておくことでグループ分けの時間が必要なくなるので先生としても便利だったと思っています。

が、１つわからなかったのが「何故１クラスは40人前後なのか？」、そして「何故１つの班は5～7人程度で構成するのか？」でした。ずっと疑問に思っていたわけではなく、まあそういうものだったんだろう、、という程度に考えていましたが、改めて考えると統一する理由はあまりないと思ってます。　ましてや１クラスの人数は（学校によって担任の負担が変わらないように、とかの理由で）わからなくもないけど、班の人数を決める必要性がどこにあるのか、別に３人でも４人でもいいと思うし、３人の班や７人の班が混在していてもいいのでは？？　と考えていました。例えば仲のいい５人組とかがいて、その中にもう１人入っていくのはお互い嫌な気分とかにならないのかな・・・と。それでも班の人数を固定する理由があるのか・・・という感じでした。

ところが、これは統計を勉強するようになって気付きました。「理想を言えば１クラスは42～3人、１班は6～7人がいい」のです。適当な数字ではなかった、ということです。


この秘密の鍵は「正規分布」と「標準偏差」にあります。

「正規分布」は「平均値に近いほどそのサンプル数が多くなるような連続した確率の分布」のことです。わかりやすく言えばテストの得点が横軸、その点を取った人の人数が縦軸になるようなグラフを書いた時にこんな感じになるような分布のことです（この例だと平均点は５０点あたりで一番多く、そこから離れるにしたがって人数が減っていくような分布）：


学力テストなどでは、例えば全国模試など充分な数の受験生がいるような試験ではその結果は正規分布になります。精度が少し荒くはなりますが、１つの学校内での模擬試験などでも正規分布として考えることが多いです。

そして「標準偏差」。受験ではよく聞く「偏差値」というキーワードを耳にすると思いますが、「標準偏差」は偏差値と大きな関わりがあります。「標準偏差」は「バラつき度合い」を示すものです。要はグラフの形は上記のようになるけど、平均点付近にかなり固まっているのか、あるいは０点から１００点までそれなりにバラついているのか、という数値の指標になるものです。標準偏差そのものはエクセルを使って簡単に（STDEV関数で）求めることが出来ます。

で、日本の受験で用いられる学力偏差値では標準偏差１を偏差値10とみなし、以下のような関係が成立します：
　・平均点を偏差値50とする
　・平均点よりも標準偏差１つぶん多い点数を偏差値60とする
　・平均点よりも標準偏差２つぶん多い点数を偏差値70とする
　　　：
　・平均点よりも標準偏差１つぶん少ない点数を偏差値40とする
　・平均点よりも標準偏差２つぶん少ない点数を偏差値30とする
　　　：

要は、各個人の得点が平均点と比べて標準偏差いくつ分離れているのか？を数値化したものが偏差値なのです。

そして成績の分布が正規分布だった場合、偏差値にはおおまかに以下の関係が成立します：
　・偏差値60以上は全体の15.6%（6～7人に一人）
　・偏差値70以上は全体の2.275%（43～4人に一人）
　・偏差値80以上は全体の0.135%（約740人に一人）
　　　：
　・偏差値40以下は全体の15.6%（6～7人に一人）
　・偏差値30以下は全体の2.275%（43～4人に一人）
　・偏差値20以下は全体の0.135%（約740人に一人）
　　　：

言い方を変えると、
　・偏差値60以上は班に一人、
　・偏差値70以上はクラスに一人、
　・偏差値40以下は班に一人、
　・偏差値30以下はクラスに一人、
　　　：
と言えるようにするには、１クラスを43～4人、１班を6～7人で構成するのが理想、という表現もできることになります。

さすがに１学年で740人というマンモス校は珍しいと思いますが、２つの学校の同学年を足すとこのくらいになることはあると思います。その場合は「偏差値80以上と、偏差値20以下は２つの学校で一人ずつ」とも言えますね。


これが本当にクラス編成、班分けの理由かどうかはわかりませんし、試験結果は必ずしも正規分布にならないこともあります。でも６～７人のグループや40数名のグループが集められることがあったら、それは統計目的でグルーピングされている可能性もある、のかも。　少なくとも、上記のような統計との関係はあるので。



 

タグ ：

analytics