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

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

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

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

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

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

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

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

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

以上、ただの雑記でした

ダイナミックプライシング 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

あなたを家電に例えると?の対策を考えてみる

就職活動でよく聞かれる「あなたを家電に例えると?」という質問。この質問自体になんの意図があるかはさておき、ネタだしに苦労している人は多いのではなかろうか。

私は残念ながら(?)就職活動中に「あなたを家電に例えると?」と質問されることはなかった。もし、尋ねられたらなんて答えただろうか・・・

というわけで、ちょっと興味がわいたのでどんなものがあるのか調べてみた。よくあるパターンは以下のあたり

  • ルンバ:自ら考えて行動するから
  • パソコン:時代の変化に合わせてバージョンアップしていくから
  • 冷蔵庫:いつもクールだから

自分でもネタだししてみた

  • 体温計:ちょっとした変化に気付く心配りができるから
  • 活動量計:目標に向かって1歩ずつ努力を積み重ねていくから
  • 体重計:現実と向き合い自らを律するから

ええやん(・ω・)ドヤッ

他には

  • BIG MUFF:周囲の人々に元気とエネルギーを与えるから

とかどうよ?

Googleの検索結果で自サイトが「ページがモバイルフレンドリーではありません。」と表示される

自分のサイトを立ち上げて、運用を開始して、Google検索で表示されだすと「いよいよか~」とワクワクしだしますね。が、妙な表示が1つ。

ページがモバイル フレンドリーではありません。・・・ エッ?(゚Д゚≡゚Д゚)エッ?

「ページがモバイル フレンドリーではありません。」の意図

どうやらGoogle方針としてモバイル対応を進めていて、それができてないサイトの所有者には「モバイル対応しろ!」という警告を発するようです。

しかも、モバイルフレンドリー対応は必須ではないものの、応済みサイトの方が優先的に検索結果にあがるという仕組みのようです。たしかにGoogleからすれば検索上にモバイル対応していないサイトばかり列挙するとユーザ利便性が損なわれますので、各サイトにモバイル対応を呼びかけ、モバイルフレンドリーのサイトから優先的に表示させたいという考えは納得ですね。

対応方法と警告文の消し方

検索結果一覧に表示されたページがモバイル フレンドリーではありません。をクリックします。

自分のサイトURLを入力します。するとモバイルフレンドリーかどうかの診断が実行されます。

診断結果が出てOKだったら「GOOGLEに送信」をします。NG項目があった場合は頑張って対応してください(丸投げ)。

診断結果は保存もできます。
https://search.google.com/search-console/mobile-friendly?id=ujaXbIA2HBu6xpbjirIldA

では

 

<続報>

上記の対応から数日後、無事に「ページがモバイルフレンドリーではありません。」の表示が消えました

メデタシ>∩(・ω・)∩<メデタシ

クラウドと機械学習

こんにちはロードローラーです。今日はクラウドと機械学習について書きます。先週にJAPAN IT WEEK 2017春@東京ビッグサイトが開催され、クラウド関連の出展ブースでは機械学習がトレンドだと言われ新聞記事にもなっていました。

実際のところ、IoTサービスによってデバイスからクラウドにデータ送信できるし、DWHサービスによってデータをクラウドに蓄積できるので、「だったら分析もそのままクラウドですればいいじゃん」というのは必然的な流れですね。

AmazonのAWS、GoogleのGCP、MicrosoftのAzure、IBMのBluemix、みんなやはり機械学習プラットフォームをクラウドで提供しており、他のIoTやDWHと連携させてクラウド完結できる仕組みを提供しています。

で、ここで私が気になったのは、各社が提供する機械学習プラットフォームにて、自分でかき集めたデータを使ってモデル選定とパラメータ調節を繰り返し、「学習済みモデル」をクラウド上に構築した場合に著作権や特許がどうなるのかです。

Business lawyerさんを引用すると、

学習済みモデルは、通常、関数、行列またはパラメータ等の形式で自動的に出力されますので、それ自体は創作性または発明性が否定されることもあり、著作権法または特許権法による保護の対象とすることが難しい場合が多いと思われます。
https://business.bengo4.com/category5/article153

とのこと。こうなると「事業のキモとなる認識器(学習済みモデル)が特許保護を受けていない状態で他社様のクラウド上にあるのってなんかイヤじゃない??」と私は考えてしまうわけです。

あと、もっとシンプルな突っ込み所としては、深層学習を突き詰めて利用すればするほど、環境構築においてCUDAやCaffeのバージョンも細かく指定したくなるだろうから「手軽で簡単に深層学習を開始できますよ!」ってコンセプトはいかがなものかと。。。

ひょっとして、そもそも玄人ではなく初心者をターゲットにしていて、いずれクラウド離れされても構わないのでとにかく深層学習のプレイヤーを増やすことが目的なのだろうか(ありえる)。

個人的には「深層学習なんてみんな自分で好きなように環境構築したいに決まってるでしょ!」という潔いスタンスで、GPU搭載サーバのレンタルをするだけというさくらインターネット株式会社様のような取り組みが好みです。環境構築は1から自分でしないといけません。なんというかさすが関西企業!そこにシビれるアコがれるぅ!!と思ってしまいました。

IoTで絶え間なく入ってくる新しいデータによって、毎日どんどん認識器を賢く更新していきたいという場合はやっぱりクラウドが向いてるんでしょうね。どこかでリビジョンを切って、いずれは認識器をコンポに落とし込みたいといった開発途中段階の場合は悩む点がありそうです。

今日はここまで。

変化点検出ChangeFinderのインストール&動かしてみた①

こんばんは、ロードローラーです。

今日は変化点検出を試したので紹介します。

IoTでデータを取得できる場面は広がりました。特に多いのが正常/異常を検出したいといった取り組みですが、いずれも「What is 異常?」を定義できずに悩んでいるようです。

そんな状況で私が注目したのが変化点検出のChangeFinder。これは「具体的にはわからないけど何かしら変化があった。」という瞬間を検出をする処理です。閾値処理のように高周波な変化やノイズに反応しにくく、傾向の変化を捉えるので、サンプルデータを入手しにくく定義困難な異常の検出に向いています。

 

インストール方法

私が実行した環境はUbuntu14.04です。以下を実行すればOKです。

が、しかし、これだけでは動かないこともあります。だいたいこのあたりを追加すれば動きます。(うろ覚えでスイマセン。。。)

 

サンプルソースと実行結果

ガウス分布で疑似的にデータを作り出してChangeFinderするサンプルがよく公開されてます。ソースと実行結果は以下の通り。

赤色がデータ値、青色がChangeFinder結果。データ値(赤色)の高周波な変動には反応せず、元となるガウス分布が変化しときにChangeFinder(青色)が反応しているのがわかります。こういった「そもそものデータ発生源の傾向変化」は単純な閾値処理では検出できません。

 

手持ちのデータに適用してみた

これだけじゃ面白くないので適当に採取したデータにChangeFinderを実行してみました。csvファイルを読み込んで実行するようにpythonプログラムを少々変更しています。

対象データは、とある楽曲演奏時のdB値を加工したものです。イントロ⇒メロ⇒サビといった雰囲気の変化を「やかましさの傾向変化」でキャッチできないかなという実験です。

う~ん、微妙。。。07:00:00と22:00:00にサビで盛り上がる場面がくるのですが、捉えられているといえば捉えられてる・・・か??

ここから先はChangeFinderの3パラメータ調節が必要そうですね。このあたりはまた次回に調べてみます。

それではまた