まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:analytics

普段は IBM Bluemix の関連で IBM Watson の API を紹介する機会があります(このブログでも何度か扱っています)。これらの多くは Watson Cognitive と呼ばれる言語や画像などを対象にした認識/分類を行うタイプのエンジンです。

一方で、Cognitive 以外の Watson もあります。その1つが Watson Analytics と呼ばれるもので、これは「データ分析」を目的としたエンジンです。現在では API というよりも、クラウド上のツールとしてその機能が提供されています:

http://www.ibm.com/software/jp/cmp/watsonanalytics/
2017020100


この Watson Analytics ツールは、誰でも申し込みから 30 日間は無料で使うことができます。というわけで自分も申し込んで、どんなものなのかを試しに使ってみました。

まず上記ページの「無料トライアルを試す」から申し込みを行います。しばらくすると以下のようなメールが送られてくるので、「ログインする」をクリックして、申込み時に指定したメールアドレスとパスワードで Watson Analytics サービスにログインしてください:
2017020201


Watson Analytics サービスにログインした直後はこのような画面になります:
2017020201



さて、今回このサービスを試用するにあたって、どんなデータで何を試すかを考えました。そこまでアナリティクスに詳しいわけでもなく、そこまで詳しい人を対象に紹介するつもりもないので、自分の守備範囲の中で試すことにします。 というわけで、以前にこのブログで紹介したことと同様のことを Watson Analytics サービスで挑戦してみることにします:

dashDB の R Studio を使ってデータの相関関係を調べる
http://dotnsf.blog.jp/archives/1047597688.html


ここで紹介しているのはセンサーとみなしたラズベリーパイから3種類(CPU 温度、CPU 負荷率、サインカーブを描く値)のデータを1秒おきに取り出したものです(取得済み)。そしてこの3つのデータの相関関係有無を調べてみることにします。同ブログエントリ内でも紹介されていますが、取得済みのデータは CSV で公開しているので、同じものをそのまま使うことにします。ここからダウンロードしておいてください:
https://raw.githubusercontent.com/dotnsf/RPDATA/master/RPDATA.csv


なお、この CSV ファイルをそのままエクセルで開くと、最初の方はこんな感じになります。1行目はヘッダでデータは2行目以降。B列が CPUTEMP(CPU温度)、C列がCPULOAD(CPU負荷率)、そしてD列がSINE(サインカーブを描く値)になっています。A列のIDはユニーク文字列ですが、今回は使いません:

2017020211


ちなみに CPUTEMP と CPULOAD を折れ線グラフにするとこんな感じ。途中でわざと負荷をかけたので、山が1つ出来ていることが見てとれます:

2017020212


一方、同じ期間中の CPULOAD と SINE とを比較したのがこちら。SINE は CPU の負荷とは無関係に、一定のリズムでサインカーブを描いていることがわかると思います:
2017020213


ここまで見た上で意識していただきたいのは以下のことです:
・ CPUTEMP が上がると CPULOAD も上がり、CPUTEMP が下がると CPULOAD も下がる
・ SINE にはそういった相関関係が CPUTEMP にも CPULOAD にもない
・ いまグラフの形を見たからそういうことに気付くことができた
・ また CPUTEMP は CPU 温度で CPULOAD は CPU 負荷率だった。つまりどちらも CPU に関連するセンサー値だった。そこまで理解した上でこの数値やグラフを見ているから、これらには関係があるように推測できた


つまり、人間の目でグラフの形を見比べた上で、なんとなく「形が似ている」と気づけたわけです。また「同じ CPU に関する値だったと分かっていたから、それらには関係があるだろう、と推測できた、ということです。

では同じことを目で判断せずに、加えて事前に同じ CPU の情報であることを知らない Watson が、数値データの羅列を与えただけで気付くことができるでしょうか? ということを今回の調査テーマとしてみることにします。


改めて、この CSV ファイルを Watson Analytics にロードします。新規データとして追加するので "+ New data" と書かれた箇所をクリックします:
2017020201


Watson Analytics には標準でサンプルデータが用意されているのでそれを使うことも出来る上、Box や OneDrive、Twitter などのソーシャルサービスから条件を指定してデータを取り出すことも可能になっています。今回は手元にある CSV ファイルを元にデータを生成したいので、"Local file" タブを選択します:
2017020202


このような画面になったら「Browse」をクリックして、先程ダウンロードした RPDATA.csv ファイルを指定します:
2017020203


こんな感じの画面になって RPDATA.csv ファイルがアップロード候補に加えられている状態になりました。このまま「Import」をクリックしてアップロードします:
2017020204


元の画面に戻りますが、いまアップロードした RPDATA.csv が分析データとして追加されていることが分かります。この画面では "Processing..." と表示されています。これはアップロードは完了しているのですが、分析するための処理を行っている途中であることを意味しています。このままもうしばらく待ちます:
2017020205


下図のような状態になると分析処理も完了したことになります。このアイコンをクリックして、実際の分析結果を確認してみます:
2017020206


(RPDATA に対して)どんな分析をするのか、という選択画面が表示されます。上述したように、今回は値の相関関係を調べたいので、"What drives SINE?"(何が SINE に影響しているのか?)を選びます。SINE との影響だけを調べたいわけではないのですが、この "SINE" の部分を切り替えて調べることができるので、今回はこの観点で各種データの影響要素を調べることにします:
2017020207


"What drives SINE?" をクリックすると、しばらく画面構成の処理で時間がかかるのですが、ロードが完了するとこのような画面になるはずです。結論として、"SINE" に関しては "No key drivers were found."(特に影響要素は存在しない)と表示されています。まあ答をわかっている立場からすると当然の結果なのですが、解析結果としても同じ結論になっていることが分かります:
2017020208


もともとの目的にもよるのですが、例えばこのセンサーモジュールの故障やエラー、利用不可になる予防保全をしたい場合などは CPU 利用率があまり高くない状態をキープしていてほしいものです。センサーが PC などと直結していれば、その PC からセンサーの CPU 状態を把握できることもありますが、そうでないケースも珍しくありません。そうなると「センサーの CPU 状態を直接モニタリングする」ことは簡単ではないことになります。これをどうにかできないでしょうか?

では今度はこの "SINE" を "CPULOAD(CPU 負荷率)" に変更して、CPULOAD に影響を与えている要素があるかどうかを調べてみましょう。画面左下の "SINE" と書かれた箇所をクリックし、"CPULOAD" を選択します:
2017020209


同様にして少し処理時間で待つことになりますが、画面のロードが完了するとこんな結果になりました。"CPULOAD" は "CPUTEMP" の影響を受けている、という解析結果が表示されています!
2017020210


もともとは CPU 負荷率の状態をなんとか調べることができないか、という課題があったわけですが、今回の結果によって、このセンサーモジュールでは CPU 温度と CPU 負荷率との間に相関関係があることが統計的にもわかったことになります。そして CPU の温度は直接外部から測定することもできるものなので、CPU の温度を測定していれば、CPU の負荷が高くなっているのかどうかを判断することができる、という可能性がでてきたことになるわけです!


くどいようですが、我々のように事前にグラフの形を見比べたわけではなく、またこれらがどちらも CPU に関する値である、という情報が事前に与えられたわけでもない中での自動解析結果であることを考慮すると、「ここまで簡単に分かっちゃうのか・・」という印象でした。

今回のデータは ID を除けば3種類しかなく、人間の目や脳でもわかりやすいものでした。ただこれが数10種類ものデータを含むもので、その中から存在するかどうかもわからない相関関係を見つけ出すというのはなかなか大変なんだろうなあ・・・と思うのですが、このツールはその作業負担を大幅に軽減できるものだと思います。


というわけで、このような IBM Watson Analytics サービスが無料で試せるというのはなかなかすごいのではないかと思っています。皆様も興味があれば是非試していただいて、手元にある数値データを使って簡単に解析できるという体験をしていただきたいです。



今年もマンホーラー実態調査の結果発表の季節がやってまいりました! 2016/Jan/01 から 2016/Dec/19 までのマンホールマップと連携した Google Analytics とアクセスログ、そして実データを使って、2016 年のマンホーラー(注 マンホールが好きな人)の実態と傾向を浮き彫りにする、というビッグデータ解析企画です。ちなみに昨年と一昨年の結果はこちらから参照ください:
 2014 マンホーラー実態調査
 2015 マンホーラー実態調査


2016 マンホールマップ利用動向

2016122002

1回のセッションでの平均ページ数は 4.69、直帰率は 53.53% 、平均セッション時間は 4 分 43 秒でした。昨年は 4.65 と 56.77%、4分22秒だったので全ての数字が改善の方向で推移しています。昨年と比較して、マンホールマップを訪れたユーザーが、より多くのページに移動して長く楽しんでいただいている、ということになります。直帰率 50% 切りも視野に入ってきました。

なお、アクセス数は非公開ですが、昨年比で倍近いページビュー数があった、ということを報告しておきます。


利用者の国、言語

今年は 62 の国/地域からマンホールマップをご利用いただきました(昨年は 65):
2016122012


国別のアクセス数1位はダントツで日本ですが、2位以下は毎年変化しています。さて 2016 年はというと・・・
2016122003


2位は UK(イギリス)からのアクセスでした。なんでだろう?ポンド安でみんな旅行してた?3位アメリカ、4位ロシアあたりは上位の常連国です。 今年目立って高かったのは8位イラク、11位タイ、14位ミャンマーあたりでしょうか。水道関係者やインフラ整備で派遣されている皆様がこれらの国々で活躍されている姿が目に浮かんできます。。



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

では日本国内の市区町村別ではどのようなランキングだったかを調べてみました:
2016122004


見やすいように日本語で表にして、昨年からの順位推移を含めてみました:
1大阪市
2横浜市
3加古川市
4港区
5新宿区
6名古屋市
7(取得不可) -
8さいたま市
9札幌市
10市川市
11(東京都)中央区
12京都市
13新潟市
14千葉市
15福岡市
16世田谷区
17渋谷区
18神戸市
19船橋市
20江東区


アクセス記録一位は大阪市の2連覇。関西マンホールサミットの影響なのでしょうか?そしていわゆる「大都市」が軒並みランクを下げる中で加古川市や船橋市、市川市といった衛星都市が順位を挙げています。マンホール界では地方分権が進んでいるようです。


利用環境

利用しているブラウザ環境を同様の表にまとめてみるとこんな感じです:
1Chrome34.26%
2Internet Explorer23.34%
3Safari17.13%
4モバイル Safari11.47%
5Edge6.18%
6FireFox4.20%
7モバイル Chrome2.74%
8(クローラーボット)0.24% -
9Opera 0.17%
10Mozilla 互換0.09%


1位は推奨環境でもある PC の Chrome、非推奨環境と明確に言っているにも関わらず2位が IE、3位は Safari、ここまでは昨年と同順位です。変わったのはその下でモバイル Safari が伸びているのは iPhone 利用者が増えていることを意味しています(逆にモバイル Chrome が落ちているので Android 利用者は減っている)。このあたりはグローバルスタンダードを逆行しています(苦笑)。また昨年は 0.55% だった Edge が FireFox を抜いている点も見逃せません。。

なお、10位の "Mozilla 互換" というのは、ネットテレビだったり、ゲーム機だったりが考えられます。まだまだ少ないのですが、いずれこういう環境も増えていくのでしょうか?テレビだと画面が広くて便利そうではありますよね。



まとめ

以上の内容から 2016 年のマンホーラーの実態は以下のようなものであったと推測されます:
・イギリスが EU から分離して、ポンド安に笑いが止まらない人がいる
・マンホーラーは昨年以上に世界中に広まっている。そして日本では地方分権が進んでいる
・マンホーラーは iPhone 派
・大阪熱い!
・Internet Explorer は不滅



さて、次回のブログでは 2016 年マンホールマップ蓋別アクセスランキングを発表します。2016年の MVM(Most Variable Manhole) の行方は!? やなぽんさん、3連覇なるか!? お楽しみに。


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

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


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

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


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


利用者の傾向

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


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

次に利用者の性別です:
2015122003


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

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


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

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


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


利用者の国、言語

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


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

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

2015122006


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

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

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


↑1位と2位は日本語、3位と5位は対応済みの(米)英語、4位は取得できないものだったので無視します。 残りの順位を見ると次はポルトガル語、中国語、ロシア語対応が必要なのでしょうか? ヤバい、知らない言語ばかりだ・・・


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

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

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


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

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


利用環境

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

1Chrome30.08%
2Internet Explorer28.01%
3Safari16.08%
4Firefox8.49%
5モバイルSafari7.55%
6モバイルChrome7.14%
7(不明)0.90%
8Opera0.87%
9Edge0.55%
10Amazon Silk0.06%


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

そして OS 別だとこんな感じです。実質は上4つが順位で、5位以下は1%未満です:

1Windows49.26%
2iOS21.39%
3Android17.61%
4Macintosh9.75%
5(不明)0.96%
6Linux0.90%
7Nintendo Wii0.04%
8Chrome OS0.02%
9NTT DoCoMo0.02%
10BlackBerry0.01%


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

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


まとめ

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

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



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


(追記 2015/Dec/22)
続きはこちら


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


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

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

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

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


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

もしもこれら以外の点を重要視したい場合は表右下の "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" をクリックすると、価格とバッテリー容量と重量の3点が重要視指定された状態の表が表示されるはずです。なお、これら以外でも JSON を変更することで候補スマホの名称や各数値を変更することもできます。全て JSON フォーマットで指定されていることを確認しておいてください:
2015051802


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


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


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


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

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


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

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

最後の3つ目は "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
 

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

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

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

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


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

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

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

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

で、日本の受験で用いられる学力偏差値では標準偏差1を偏差値10とみなし、以下のような関係が成立します:
 ・平均点を偏差値50とする
 ・平均点よりも標準偏差1つぶん多い点数を偏差値60とする
 ・平均点よりも標準偏差2つぶん多い点数を偏差値70とする
   :
 ・平均点よりも標準偏差1つぶん少ない点数を偏差値40とする
 ・平均点よりも標準偏差2つぶん少ない点数を偏差値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以下はクラスに一人、
   :
言えるようにするには、1クラスを43~4人、1班を6~7人で構成するのが理想、という表現もできることになります。

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


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



 

このページのトップヘ