GoogleChartsがおもしろい!(ScatterChart編)※サンプルプログラムあり

GoogleChartsの第2弾、今回はScatterChartを触ってみました。

ScatterChart
https://developers.google.com/chart/interactive/docs/gallery/scatterchart

こちらは主に散布図を作成するものです。実は以前にJavaScriptで相関関数を算出したときに使っていました。(JavaScriptで相関関数の算出

既に使用経験がありますし、だんだん慣れてきましたし、ちょっとGISっぽく画像上にデータをプロットしてみました。以下の画像ではラグビーのフィールド上にデータをプロットしています。(サンプルはコチラ

ScatterChartには背景画像を設定する機能がどうもなかったようで、フィールド上へのデータプロットは次の手順で実現しました。

① divを配置してstyle-backgroundを任意の画像にする
② ScatterChartでデータプロットする
③ このときbackgroundColorをtransparent(透明)に設定

ただ座標の調節が難しいですね、そもそもラグビーの10mラインは中央から10mなのに対して、22mラインはエンドラインから22mだったりしますし。

 

今日はここまで

ブロックチェーンの特徴・メリット・デメリット②

前回、ブロックチェーンについて記事を書きましたが、その後に「パブリックブロックチェーンとプライベートブロックチェーンは別物として考える必要がある」と述べている鋭い記事を発見しました。

参考:https://imoz.jp/note/blockchain.html

私が前回記載したブロックチェーンの特徴・メリット・デメリットはパブリックブロックチェーンのことでした。というわけで今日はプライベートブロックチェーンとの違いに着目します。

パブリックブロックチェーンとプライベートブロックチェーン

<呼び方の定義>

以下3つは呼び方が異なるだけで同じものと考えます
・パブリックブロックチェーン
・オープンブロックチェーン
・パーミッションレスブロックチェーン

同様に、以下3つも呼び方が異なるだけで同じものと考えます
・プライベートブロックチェーン
・クローズドブロックチェーン
・パーミッションドブロックチェーン

 

この記事ではパブリックブロックチェーンプライベートブロックチェーンの2つの呼び方に統一しますね。

う~ん、、、なんかこう見ると、プライベートブロックチェーンはせっかくのブロックチェーンのメリットを潰して中央集権型に戻っているような気が・・・・

プライベートブロックチェーンのメリット

基本的に中央集権型と変わらないですね。中央集権型が機能分散を進めていって、仲介を務める存在が1つから2つ、2つから3つに増えていったらほぼプライベートブロックチェーンになるようなものです。

異なる点は取引履歴が延々と残っている点と、冒頭記載した参考リンク先にも記載されている通り合意形成に至る仕組みが簡単なことくらいかと。

近い将来にイノベーションを起こすとしたらパブリックブロックチェーンでしょうね。私も実際に扱うとしたらパブリックブロックチェーンの方がわくわくします。報酬を設定して採掘者を募る仕組みが必要なので企業様にとっては活用に踏み出しにくいでしょうけど。

GoogleChartsがおもしろい!(GeoChart編)※サンプルプログラムあり

GoogleChartsの第2弾、今回はGeoChartです!

GeoChart
https://developers.google.com/chart/interactive/docs/gallery/geochart

こちらは地図上にデータを可視化するものです。下図は試しに歴代高校ラグビー優勝回数を都道府県別に表示したものです。(偏ってるな~)

参考:http://www.mbs.jp/rugby_common/history/

 

GoogleMAPのおかげで既に各国の地図や都市名が組み込まれているため、「JAPAN」や「京都」を指定すればそれだけで地図が表示&都市の位置にデータがプロットされました。

サンプルはコチラ

さすがに都道府県の境界までは反映されず、優勝回数に応じた色で都道府県を塗りつぶそうとしたら失敗しました。(サンプルページを見る限りでは国境には対応しているみたいですね。)

 

ほんと手軽に動きますね、コレ・・・(驚

ブロックチェーンの特徴・メリット・デメリット

こんばんは、ロードローラーです。本日はブロックチェーンについて調べてみました。ビットコインがキラーコンテンツのため、ブロックチェーンとビットコインをイコールで捉えている方もいらっしゃいますが、ビットコインはサービス、ブロックチェーンは仕組みです。

ブロックチェーンの詳細な仕組みは置いといて、「で、けっきょくブロックチェーンって何ができるの?」ということをまとめてみました。

ブロックチェーンの特徴 ~分散台帳によって中央機関をなくす~

私はブロックチェーンを分散処理にもかかわらずセキュリティ担保できる仕組みだと解釈してます。

そもそも、目の前にいる相手と取引(例:ビットコイン送金)するときに、わざわざ中央機関に仲介手数料を取られるのは何故か?それは全取引の監視者である中央機関がいなくてはセキュリティ担保が難しいからです。しかし人間とは知恵を凝らすもので、セキュリティ担保は必要だけど仲介料も取られたくない、なにかいい手はないものかと考えました。そこで生まれた中央機関がいなくても全員で協力し合ってセキュリティ担保する仕組みがブロックチェーンだと解釈しています。

ブロックチェーンの1番の特徴は分散台帳によって中央機関を必要としないことです。これには様々なメリットがあるので、正しく理解しておきたいですね。

ブロックチェーンのメリット

<コスト>
現状は個人間の取引でも中央機関が仲介手数料を取る。この仲介手数料が分散台帳の仕組みによって無くなる、または安くなるということである。安くなるというのは、中央機関に仲介手数料を支払うよりも、ブロックチェーンに参加している採掘者へ報酬を支払う方が安くつくという意味である。

また、手数料のような運用面のコスト低下と別途で、システム構築の初期コスト低減というメリットもある。つまりゴツい中央集権サーバを用意しなくてもシステム構築できるということだ。これらは全く別種類のメリットなので気を付けてほしい。

<信頼性>
従来は中央機関が落ちればシステムはそのままダウンという状態だった。しかしブロックチェーンでは全員で力を合わせてシステムを回しているという状況なので、どこか数か所が落ちたところでシステム継続には何ら影響がない。

<セキュリティ
(これは詳細な仕組みの説明が必要かもしれないが)、ブロックチェーンへの参加者全員で取引記録を監視しているためセキュリティ(消去・改ざん防止)に優れている。

<監視範囲が広がる>
これは個人的な見解だが、中央機関の目が届く範囲しか監視できなかった従来と比べて、参加者全員で監視するため目の届く範囲が広がると思っている。機密性は低くとも匿名性は高いので(※後述)、個々人の細かな行為にまで監視の目が届き、保証可能な範囲が広がる可能性がある。

ブロックチェーンのデメリット

<低いパフォーマンス>
速度が遅い。これは参加者全員でコンセンサスを取りながら進めるためである。ビットコインではブロックチェーンによって取引記録が安全に記録されるのに平均10分かかるとされていた。

<オンラインでしか動かない>
取引自体は不可能ではないが、取引が実行されたことをブロードキャスト等で参加者に通知、取引内容を含んだブロックの生成、チェーンに追加といった一連処理はオンラインでしか動かず、オフラインでは不可。

<ストレージの圧迫>
今誰が何を持っているかという現状態ではなく、今までどんな取引がされてきたのかという履歴を保存するため、管理するデータ量が膨大となる。

<機密性が低い>
ブロックチェーンでは参加者全員で取引を監視するため取引内容が暗号化されず平文のままである。暗号化してしまうと取引内容が確認できず正しいかどうかジャッジできないからだ。

ただし匿名化はされているという点に注意していただきたい。例えばビットコインにおいては取引内容は平文だが、取引者は公開カギによって匿名化されている。「どこかで送金取引があったみたいだけど誰から誰になのかは不明」という状態だ。

ダイヤモンド取引の透明化

Everledger社はブロックチェーンを利用してダイヤモンドの採掘から消費者に届くまでの過程・認定書・取引履歴などを全て記録して「ダイヤモンド取引の透明化」を実現しようとしています。

たしかに採掘・加工・輸送・販売・転売などの全取引を追跡して1箇所で管理できる中央機関の存在は考えにくいので、ブロックチェーンの良き活用例だと思います。

 

さて、これからはどのような分野で活用・発展していくのでしょうか、楽しみですね。

負けたというのになぜ君は死ぬ寸前まで悔しがってないのかな?

どうも、ロードローラーです。「どうも」という言葉は非常に不思議なもので、挨拶シーンにも御礼シーンにも用いられますね。実際にそのような意図がある言葉ではないので「どうも」という言葉はなるべく使うなと教育する人もいるとか。

さてさて、今回は普段の意識高い系とはうってかわって雑記です。たまにはこんな話題もよいかと。

「負けたというのになぜ君は死ぬ寸前まで悔しがってないのかな?」

このセリフ、知ってますか?

これは少年ジャンプで連載されていた「暗殺教室」に登場する浅野學峯のセリフです。別に私自身、暗殺教室という作品の大ファンというわけではありませんが、このセリフは強烈に印象に残っています。このセリフの前後で浅野理事長が伝えていることは、

  • 「もしも次も負けたら・・・」、再び負ける恐怖との戦い、敗北から学ぶとはそういう事だ
  • だが、多くの者は口先だけで大して学ばず敗北を忘れる

過激な表現に感じる人もいるかもしれませんが、私はすごく賛同なんですよね。昔から勝負事(主にスポーツ)をずっとやってきた人間なので「勝ち」「負け」という言葉に敏感なのかもしれません。

アメリカなどではスポーツでもなんでも勝負事は勝者にスポットを当てます。しかし、日本は反対で敗者にスポットを当てる習慣があります。もちろん、負けたことが今までの努力を全否定することはできないと理解していますが、「この悔しさを活かして次回こそは」という言葉を使うときは、相応の重みが必要なのだろうなと考えてしまいます。

以上、ただの雑記でした

ダイナミックプライシング 4パターンの価格決定の考え方

こんばんは、ロードローラーです。最近、ダイナミックプライシングについて話を聞く機会がありました。平たく言うとダイナミックプライシングとは「モノを売る人が価格決定したり、途中変更したりすること」です。

私が興味を持ったのは、どう価格決定するか?どう途中調整するか?という思考が代表的4パターンにまとめられるということでした。「そんなのCase By Case で臨機応変じゃないの!?」と最初は思いましたが、本質的には数パターンに分類できるのは面白いですね。

以下に講演で紹介されていた代表パターンをまとめました。

Demand Driven Pricing

事前調査で最適な価格を算出しようという発想。
顧客の嗜好(しこう)、競合他社の状況、自社の状況といった市場情報の分析に基づいて価格決定する。必要なデータを集めきれる保証もなければ、調査にリソースも必要であるため、手間や負担が大きい。大企業向けの手法と言われている。

Derivative Follower Pricing

とりえず売ってみてから最適価格を探すという発想。
実験的に価格を増減させてながら販売して、利益を最大化できる価格を探索する。この考え方の背後には、市場情報の網羅は困難なので試さないと分からないという潔さがある。

Penetration Pricing

導入が安い代わりに時間をかけてトータルで儲けようという発想。
低価格によって顧客を引き付け、スイッチングコスト高くすることで顧客を囲い込み、継続的に収益を得る。

携帯電話や格安Simがそうですね。2年間使う条件(囲い込み)で、初期費用がゼロ円みたいなキャンペーンもよくやってましたし。

SkimmingPricing

高くてもイイモノは売れるという強気な発想。
最初に高価格を付けることで初期に利益を上げて、価格を徐々に下げていくことで低い価格で購入する顧客も引き付ける。「今すぐ欲しい」と思わせる魅力・技術力・革新性が求められる。

一番に思いついたのはゲームソフトですね。WiiやDSも時間がたてばどんどん安くなりましたし。でも、ああいうものは発売と同時に欲しいので、やはり強気な価格設定でも勝負できる製品魅力があってこそですね。

 

う~ん、最初2件の例はなんでしょう・・・?だいたいの製品はどちらかには該当しているのでしょうけども。。。値段が変わらないものと言えばカップ麺やお菓子みたいな食品系でしょうかね。ならば値段がころころ変わるのは例えば牛丼とか?(あれはコロコロ変化する外的要因に沿って最適判断をしているだけで、探索する意図で価格変更しているわけではない可能性もありますが。)

価格決定と価格調節という行為はいずれも目的が儲けるためなので、利益最大化に向かってパラメータ(価格、需要、etc…)を調節すると考えたらアプローチはもっともっと山のようにある気もします。実際、まだまだ発見されていない戦略があるのかもしれませんね。

本日はここまで

シーズ起点の技術開発

こんばんは、ロードローラーです。今回のテーマは技術開発の進め方です。(ここでの技術開発とは「技術を市場の顕在的・潜在的ニーズに結び付けること。」と定義します。)

事業起案や製品企画の進め方を調べると「まずは顧客が本当に求めているものを見極める」といったニーズ起点手法がたくさん出ます。

ポピュラーな手法だし、理にかなった進め方ですが、そうだとしても技術屋さんはそれぞれにポリシーを持った担当技術があるわけなので、シーズ起点手法で進めざる得ない場面もあります。

例えば上司に「その技術は何の役に立つの?」と問われたときなど(´・ω・`)クヤシー

「それを考えるのは●●の仕事だろ!」と反論したくなる方も多いと思いますが、それで争っても仕方ないのでグッとこらえて、シーズ起点の進め方を考えましょう。技術を扱いつつ事業案まで見据えていたらスペシャリストとして成熟度が上がると思いませんか?

というわけでシーズ起点の進め方を考えました。

ポイントは技術とニーズの抽象度を揃えながら徐々に具体化していくことです。

例えば、手持ちの技術が「防犯カメラ画像から人物の入退室数をカウントする」の場合、既に洗練(具体化)済みなのでピッタリとマッチするニーズは見つけにくいです。そこでひとまず「画像から通過を検知する。」といったくらいまで抽象化します。

これにより「防犯カメラを使う。」「対象は人物。」「機能はカウント。」といった先入観が抜けて、抽象度が上がっただけニーズ調査しやすくなります

例えば「立ち入り禁止エリアへの侵入を警告するシステムなんてどうだろう?」または「人ではなく車は検出可能か?一方通過エリアへの自動車の侵入を警告するなんてどうだろう?」などとニーズ調査の方向性が出しやすいですね。

ヒアリングの結果、侵入警告システムの需要があったとします。ただし、複数人が同時に来ても検出可能であることが必須だと判明したとします。このようにニーズ調査が進んだら再度技術を突き詰めます。「入退室カウントができるくらいだから侵入検知も可能だろう。ただ、複数人同時はできるだろうか?」と検証するわけですね。実現するまでの技術的な壁を乗り越えられればそれが競争優位性になります。技術屋さんの腕の見せ所ですね。

で、技術が突き詰められれば再びニーズ調査に戻ります。今回は技術を突き詰めた成果として「複数人同時の侵入検知は可能。ただし、カメラで上方から撮影する必要あり。」という成果が出たと仮定します。このように技術的制約ができるとニーズ調査の方向性がさらに定められてきます。「その制約条件でもokか?」「マズいとしたら何が問題か?」「屋内の顧客にターゲットを絞るか?」とニーズ調査を実施して、このようなサイクルを繰り返して徐々に事業案を具体化していきます。

どうでしょうか?あわててpptで一生懸命事業案を書いても、1発でクリティカルヒットすることは稀です。このような進め方がストレスなく無駄も少ないと私は考えます。

研究開発と技術開発と商品開発の違い

こんばんは、ロードローラーです。今日は日頃の疑問を解消したく、チクチクと調べごとをしていました。

ここ1年ずっと気になっていたのが次の言葉の意味。

 ■研究開発(Research and development)←わかる
 ■技術開発(Technical development)  ←わからない
 ■商品開発(Product development)     ←わかる

コレはけっこう人によって認識が異なるところではないでしょうか。

組織のように人がたくさん集まる場所では、同じ単語を各人が異なる意味で使ってしまうと混乱が生じます。そうなると納得感がないまま、最後には一番声のデカい人の意見が正とされる乱暴な多数決が生じます。

というわけで、正しいか否かよりも、まずは相手の言葉の定義を正確に伝えられるように整理してみました。

 ■研究開発:調査・研究・検証により優位性ある技術を得る。
 ■技術開発:技術を市場の顕在的・潜在的ニーズに結び付ける。
 ■商品開発:具体的な商品・サービスを作る。

この分類でいくと技術開発で作るものって事業案なわけで、『技術』って名前につくけどppt作る仕事が多いのも納得感あるなー(棒読み

Javascriptで相関係数の算出

こんばんは、ロードローラーです。京都はすっかり熱くなりましたね。

さて、ここ最近はGoogleChartsでデータ可視化を色々と試してました。ついでにJavascriptで基本的なデータ分析が出来ればいいなぁと思い立ちました。

詳細な分析は専用ソフトを使ってくれればいいんですが、データ可視化ついでにせめて相関係数くらい提示できれば、なんとなく因果関係がありそうな分布に数値エビデンスを加えられるからです。

というわけで早速実装。①温度と②湿度を2次元にプロットして相関係数を算出しています。2次元散布図ということでScatter Chartを利用しました。

Scatter Chart
https://developers.google.com/chart/interactive/docs/gallery/scatterchart

サンプルはコチラで動作させられます

が・・・、あれ?

温度と湿度って基本的に負相関だと思ってたんですが正相関になってますね、しかも0.95とかなり強烈な。。。。おそらく屋外の環境ではなく、室内の人工的に調整された環境のデータだからですね。加湿機能付きヒーターによって温湿度が同時上昇したとか。

今日はここまで、それではごきげんよう♪

GoogleChartsがおもしろい!(LineChart編)※サンプルプログラムあり

便利で無料で手軽に動作するGoogleCharts。IoTで収集したデータをとりあえず可視化したいという需要が増しているので活用機会は多々あります。

今回は「LineCharts」を動かします。

GoogleCharts
https://developers.google.com/chart/interactive/docs/gallery

LineCharts
https://developers.google.com/chart/interactive/docs/gallery/linechart

自室の温湿度を可視化しました。屋外と異なって変動が小さいですね。
実際にコチラで動作させられます。

 

手順としては下記のとおり

  1. GoogleCharts使用開始のおまじない
  2. データTableの定義
  3. データ読み込み(今回はajaxによるhttp通信でjsonファイルを取得。)
  4. 取得したデータを加工しながら格納
  5. 可視化実行

 

ちなみにソースコード貼り付けには以下を利用。WordPressにペタッと貼れるかと思ったらプラグインやらマークアップ対策やら案外手間でした。
http://tomari.org/main/java/html-mojihenkan.html