月１０００万売り上げる本屋さん、どうすれば作れる？

というお題。すかさず、

客単価平均１０００円としたら、１万人、
２０００円としたら、５０００人、
５０００人だと、１日当たり約１７０人（＊３０日＝５１００人）
お店が１０時間開いているとして、１時間当たり１７人が購入するということは・・・

・・・購入するには、それ以上の人がお店に来なきゃいけなくて、
お店に来るためには、それ以上の人が、店の前を通過しないといけないよね。

・・・駅前ならできるだろうけど・・・


・・・と思ったら、先生から「そのはじめの発想が悪い。というか、まちがっている。
もっと違う分析をしてみ」といわれて・・・


・・・やっと気付いた！販売チャネルで分けるんだ！

---

　上記のように、
　　売上＝客数Ｘ客単価で、
　　　　客数を挙げる方策、
　　　　客単価をあげるための品ぞろえ、
　　　　客が、より高い商品を購入する雰囲気作り
　・・って考えてしまうけど、
　それって、リアル店舗が、前提にあるよね。

　販売チャネルで考えた場合、

・通販する
・リアル店舗で客に来てもらい、その場で買ってもらう
　リアル店舗で客に注文してもらう
　出版をプロデュースして、その本を販売する
などなど、いろいろあり得る。

通販というと、Ａｍａｚｏｎを考えてしまう。
Amazonの最大の欠点は、商品を決めないと注文できないこと。
ピッキングしている人のお勧め本とかはないのだ・・・この市場は狙える。
　いわた書店の　１万円選書　http://iwatasyoten.my.coocan.jp/form2.htmlがこれにあたる。

出版プロデュースっていうと難しそうだけど、電子書籍の自費出版であれば、
そんなにお金はかからない。それをリアル店舗に置くという手もあるけど、
さらに、上の通販なんかとからめて、なにか読みたい人に、自費出版のディープ
な本を送ったりして、感想を求め、さらにその感想から、みんながどんな本を
よみたいか、アピールする。

そんなこんなで、電子書籍の自費出版の作家と、読者との間をつなぐイベント
を行えば（ジュンク堂のトークイベント例みたいなの）
あ～なんだ、喫茶併設、貸しスペースも併設できるかな？

そんなこんなで、月１０００万、行きそうですね・・・

---

あ～、リアル店舗から考える癖がついてるな・・・
発想が、貧困でした・・

IoT時代のデータ基盤への要件を聞いてきた！

Developers Summit 2016 Summerにいってきた！

次は

IoT時代のデータ基盤への要件

をメモメモ

---

・巷で話題のＩｏＴ
　ビッグデータ：賞味期限切れ
　昨年あたりから盛り上がってきた
　ＩｏＴ
　　一般的な認識
　　　ありとあらゆる機械、デバイスがインターネット上で繋がる
　　　データ量が爆発

・RoboBoss
　IoTを異なる視点から見る
　　インテリジェントで自立型なデバイス、機械が急増する
　　デバイスがＩＴに何かを要求

　機械が労務管理の一翼をになう
　機械の人間化
　単なるデバイス接続ではなく高度なシステム連携が必要

・ＩｏＴのチャレンジ
　データの読み取りスピード（レイテンシー）
　単位時間当たりのデータ処理量（スループット）
　デバイスの多様性への対応
　データの多様性（構造データ、非構造データ）
　リアルタイムアクション（アラート、自動調節、自動カイゼンなど）

・ＩｏＴソリューションの課題
　単一のテクノロジーがない
　ＩＴアーキテクトは複雑な統合という問題に直面する
　専門性や技術は高価で不足
　確立されていない

・先進のＩｏＴソリューションの不可欠な要素
　　多機能
　　多段階
　　多パターン

・ＩｏＴの重要なポイント
　オープンインターオペラビリティ
　５つの正しいこと　５Ｒ
　　　正しいデータ
　　　正しい量
　　　正しい人に
　　　正しい時間に
　　　正しいアクション（正しい状況の理解が前提）
　人以上に、この原則必要

　個別につないでいく

　連携の基盤をつなぐ

　連携基盤要件（５Ｒ）を満たすために
　起こっていることを理解、判断することが重要
　　プロセスの可視化
　　理解、判断するために必要なもの
　　　知識（外部から）
　　　経験（内部で）
　データマネジメントの重要性
　　　データプラットフォーム

・アクティブ・アナリティクス
　　ＤＷＨ的な分析とリアルタイム分析を組み合わせて業務カイゼン
　　業務システム
　　　回想的分析
　　　リアルタイム分析＝確認必要

・データ分析の種類
　　Prescriptive Analysis
　　　課題に対する対処法を示唆

・インターシステムズのIoTソリューション
　ＩｏＴデバイス
　データ変換
　ビジネスプロセスオーケストレーション
　データベースエンジン

・低レイテンシー
　大量のデータをすばやく取り込む
　　ヨーロッパ宇宙局のＧＡＩＡプロジェクト
　　　１０億個　１日で（６０テラバイト）
　　→半日でＯＫ

・高スケーラビリティ（高スループット）
　大量ユーザーを収容する
　　退役軍人向け医療システムネットワーク
　カイザーパーマネンテ

・マルチモデル・データプラットフォーム
　柔軟なスキーマモデル
　　　ＸＭＬ
　　　ＪＳＯＮ
　データモデルの違いによる新たなサイロの発生
　　マルチモデル

・メンテナンスフリー・データプラットフォーム
　再構成、インデックス再構築不要
　スキーマ進化への柔軟な対応
　まばらなデータ（汎用的なものは、効率悪い）

・アクティブアナリティクス（リアルタイム）
　　トランザクショナル・ビットマップ・テクノロジー
　　トランザクショナル・ビットスライス・テクノロジー

・非構造データの取り組み
　iKnowテクノロジー
　　ドメイン辞書の力を借りることなく、コンテキストに基づく正確な情報
　　意味を得やすい

・事例
　　タクシー車載データ
　　オブタラート疲労管理ソリューション
　　船舶の全ての機器を制御

・パートナーズヘルスケア
　　生体医療機器データ利用
　　ＩｏＴアプリケーション

・安全運転支援システム（現在開発中）
　DeepSee アクティブアナリティクス機能

・自社紹介
　ヘルスケアＩＴ　プライベート企業

・まとめ
　データ取り込みのレイテンシー
　スループット
　オープンインターオペラビリティ
　アクティブアナリティクス
　マルチモデル
　画期的自然言語処理

IoTはゲートウェイをつかって、近距離はＩＰ以外、遠距離は３Ｇ等を使うのが主流？

Developers Summit 2016 Summerに行ってきた！
次は、

IoT時代のデータ分析と活用の実際
講師：クリエーションライン

をメモメモ

---

・自己紹介
　BlueMixのApacheSparkで異常なデータを・・・という記事書いた

・会社紹介

１．課題の定義

　ビジネス的な観点・技術的な視点

・ビジネス的な観点
　センサーが必要な業界
　ＩｏＴと聞いて想起するもの
　　スマートメーター
　　農業
　　自動車
　　ＲＦＩＤ
　　マッシュアップ：地理・ソーシャル

　現時点においてセンサー必要
　　Ｍ２Ｍの焼き直し
　　　製造業：モーターの稼動限界
　　　ヘルスケア：心拍・・・
　　　エネルギー：発電
　　　自動車、飛行機：ナビ、ＯＢＤ２

　生活
　　ケータイ、エアコン、テレビ・・・
　　　ホームオートメーション

　クレーンの操作をWiFiで
　IoTが訴求する新しい価値とは？

　オートメーションとして実現されている例
　　一般消費財：ドラレコ
　　企業向け：ＢＥＭＳ、トナー切れ
　→ＩｏＴはＭ２Ｍの焼き直し

・ＩｏＴとＭ２Ｍの違い
　Ｍ２Ｍ：あるドメインに限られている
　　ＩｏＴは広げたもの
　大量のセンサーを扱うビジネスモデル
　群れとしてあつかう

　　製造業；機械間
　　ヘルスケア：遠隔医療
　　エネルギー：デマンドレスポンス
　　自動車：群体制御

　→実装可能か？

・ＩｏＴ的なビジネス観点とは
　ソーシャルゲームと似ている
　スモールスタート：小さく始める・企画の数が多い・ヒット確率低い
　　ヒットするとスケールアウトできるようにしておく
　目論見書：収支計算　ＯＰＥＸ（月々）ＣＡＰＥＸ（初期投資）
　チームなどの組織的手当てが必要かも

・技術的な観点
　あらゆるレイヤーで規格・実装が乱立
　　接点信号、リレー、ＵＳＢ→ＲＳ２３２→ZigBee,EnOcean,Wifi,BLE
　　ドアの開閉、センサーどう置く？
　ＧＷ
　　ハードウェア：おもちゃみたいなもん
　　サンプルプログラム→カスタマイズできる？
　　下級のもの：開発言語Ｃ　今ライトウェイト

　Ｄ２Ｃ（デバイス２クラウド）
　　ＭＱＴＴ　ＡＭＱＰ　ＨＴＴＰ
　　→実装はいっぱい

　クラウドないデータプロセッサ、ストレージ
　　さまざま

・１、２年のスパン
　センサーがＩＰをしゃべることはなさそう
　ＧＷデバイスとお話しするのが主流
　クラウド集中制御は
　　ＡＷＳ　デバイスシャドウ
　　ＧＷをはさんでいるので、直接見えない
　Ｌチカからやろうぜ！・・・その後は？
　　実装できるものと、規格の間
　悪い意味での職人芸→いまどきのことやっているのに・・・

　結果的にロックインは出ます
　クラウドに方言ある。現在、ニュートラリティはない

・技術的な観点・いくつか補足
　センサーと認識
　Raspberry Pi
　ちがうことば
　ＧＷ
　　ＡＷＳ　ＩｏＴでわかることばに
　３Ｇ
　ＡＷＳ
　　ＡＷＳでわかるのはＧＷ

・余談：ＩＰＶ６がいつか解決するという幻想
　　コントロールできない
　　ＩＰアドレスが着くことと、デバイスコントロールできることは無関係
　移動しながら通信→ＩＰアドレスは変わっている：
　ＩＰＶ６はいつメジャーに？
　　ＩＰＶ４の上位互換ではない
　　　　→ＩＰＶ４にいるところ全部にＩＰＶ６：こない

　ストリームデータへの対応
　　ＩｏＴがメジャーになってから
　　よくある課題；
　　　　過去一時間にインターチェンジを通過した車の台数は？
　　　　次の一時間予測
　　ウィンドウという概念

　スキーマレスデータへの対応
　　個々のデータの型の違い

２．要素技術
　ＯＳＩ　７レイヤ
　　Ethernet/IP/TCPはやってくれる。
　　その上の例や
　３Ｇ，４Ｇ．ZigBee,EnOcean/BLE
　　近距離：ZigBee,EnOcean/BLE
　　遠距離：３Ｇ，４Ｇ
　のつかいわけ

　ＡＭＱＰ／ＭＱＴＴ／ＨＴＴＰ
　　ＭＱＴＴおおい？
　　ＨＴＴＰはなんでもあり。おれおれ実装→あえておれおれ実装もあり？
　　　　ＨＴＴＰ：プロキシから外に出るとき

　ストリームデータプロセッサ
　　Ｓｐａｒｋ。Ｓｔｏｒｍ

　　いっかいためる：ＯＬＡＰ
　　Ｓｔｒｅａｍ：ＯＬＴＰに入れる前に処理
　
　ストレージ
　　ＮｏＳＱＬ

　可視化
　　ベストケースがないkibana
　　てづくり

・まとめ
　外だしできるところは

デザインパターン
　おおむねパターン化

分析
　stream分析：フレームワークに依存
　ホッピングウィンドウ
　Spark2.0：楽になった

開発手法：割愛
　ウォーターフォールは時間かかる
　トライ＆エラー、
　かならずＰｏＣ
　　チームのレベルが低いと、破綻する