ＩｏＴでは、ゲートウェイを使う場合と３Ｇで直接送る場合と２通りあると思う

ＩｏＴで、どのようなネットワークを組むかについて

IoTはゲートウェイをつかって、近距離はＩＰ以外、遠距離は３Ｇ等を使うのが主流？
http://blog.goo.ne.jp/xmldtp/e/3ab671b71f3b3bec520314ca1423816f

という話と、


さくらのIoTはUART,I2C,SPIからＬＴＥ，３ＧでサーバーへREST APIで外部へ
http://blog.goo.ne.jp/xmldtp/e/d05f37c4e9b0b65a14b4f57e19789efc


の２つの話を書いているけど、どっちなんだ・・・

っていうと、使い分けがあると思う

ポイントは
・３Ｇにするためのチップは、そこそこの値段する
・近距離通信を市街でやって、いけるのか？
の２点だと思う

---

■センサーの場所がまとまっていて・固定で確実にデータを送りたいならば、まずは有線を考える

無線は、「確実」とはいえない。切れることもあるし、
場合によってはノイズや干渉を起こす可能性もある。
なので、確実に送りたい場合は、有線で送れないかどうかを
まずは検討する。

■センサーの場所が固定で、広範囲でなければ、ＧＷをおくことを考える

　有線では無理な場合、センサーの場所が固定ないしは多少動く程度であれば
近距離の範囲はZigBee,BLE,920特小などで、通信し、いったんＧＷに集約し、
ＧＷでインターネットに変換して、サーバーに送りこむ。

　このとき、ＧＷからサーバーへの送信は、まずは有線で送ることを
考えて、だめなら、WiFi,３Ｇの通信を考える

・なぜ、３Ｇで直接送らないか
　３Ｇの通信モジュールが高いから。そこそこするよ・・・

・なぜＷｉＦｉで直接送らないか
　送ってもよい。センサー数が少ない、あるいはセンサーをいくつか
　まとめられるなら。

　ただ、ＷｉＦｉは、帯域が広く、端末数に限界がある。
　２．４Ｇ、５Ｇの両方を使っても、ある程度までどまり・・・かなと
いう気がする。
　BlueToothも限度がある（BLEとBlueToothはちがう。BLEは制限ない）

　ということで、百個以上のデータを処理したい場合は、WiFiは使えないかも

・なぜＧＷを使って、インターネットにするのか
　扱いやすいから
　まず、近距離は、上記の理由から、ZigBee,BLE,920特小などがいい。
　しかし、サーバーは、インターネットで統一したほうがいい。
　そうなると、ＧＷで変換することになる。
　ＧＷで変換した場合、当然有線でサーバーに送ることを考えるが
　これができない場合は３Ｇにする。なぜ、３Ｇかは後述

■センサーの場所が移動する、広範囲の距離なら３Ｇ等

　３Ｇの場合、ケータイ、スマホとおなじなので、まずまず、
距離は遠くまでとどく。移動しても大丈夫。なので、移動する場合や
ＧＷからサーバーまでが遠距離の時は３Ｇモジュールを使う。

---

　ただし、これは現在の判断。
　３Ｇモジュールとパケット代が安くなれば、
　センサーから直接３Ｇモジュールでサーバーに送ることも考えられる。

ドキドキ！ＩｏＴソリューション

っていうと、ドキドキワクワクのドキドキと
おもうかもしれないけど、そうじゃない

７月２９日、Developers Summit 2016 Summerにいってきた！

シリーズ最後は

ドキドキ！ＩｏＴソリューションに聞く快速マルチデバイス開発基礎講座

をメモメモ

---

・自己紹介
・エンバカデロ・テクノロジーズについて
　ボーランド＋＋
　delphi　進化続けている

ドキドキ！Internet of Things
・IoT
　デバイス＋データ
　　ＡＰＩ
　新しいデータインプット方式
　付加価値の創造

・ＩｏＴのビジネスチャンス
　付加価値の創造に必要な新規開発
　利用シーンの多様化
　チャンスも顧客もノンストップ

　新規工数のかかりそうなところをすばやく開発できれば

・ドキドキ！IoT
　心拍数
　ビジュアル開発ですばやく

・でも
　アプリ作成　ＲＡＤ　Studio

・でも２
　ＲＡＤ　サーバー（中間サーバー）

待ったなし！ビーコンソリューション
・Beaconを使ったソリューション
　ナビゲーション・集客・解析
　可用性が高い

・Beacon利用における課題
　位置の割り出し、精度
　なぜむずかしい
　　Ｂｅａｃｏｎ　識別ＩＤと強度を発振しているだけ
　　受け手が自分で計算する：距離しか分からない（方向？）
　　　→３つくらい受信するとわかる

・ビーコンプロトタイピング　デモ
　設置箇所
　パス
　設定したが、コードは書いていない

・マルチデバイス開発
　モバイルプラットフォーム；アップデートごとにデスマーチ

　　Rad studio
　　Delphi
　　Fire UIマルチデバイスデザイナ
　　FireMonkeyフレームワーク→抽象化
　　生成されるコードはネイティブ

　メンテナンスを含めたトータル工数の圧縮

　宣伝　ビーコン勉強会見てね

・まとめ
　ＩｏＴ＆快速開発
　ビーコン
　マルチデバイス開発
　

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

というお題。すかさず、

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

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

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


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


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

---

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

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

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

通販というと、Ａｍａｚｏｎを考えてしまう。
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：楽になった

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

モバイル用Webフレームワーク最前線というかJavascript最前線

Developer Summit 2016 Summerに行ってきた！
のつづき。

次は

モバイル用Webフレームワーク最前線
講師：アシアル

をメモメモ

---

・会社紹介
・自己紹介

・全世界に対する開発者向け調査
　どういったテクノロジを使っているか
　モバイル
　　ＨＴＭＬ５
　　XXScript
　　Java
　　C
　　C#
　クラウド
　　Java

・Ｊａｖａｓｃｒｉｐｔはコミュニティが発展している言語に
　８５％→５年前は５６％
　ＰＨＰのシェアはあまり変わっていない

・その結果
　さまざまなフレームワーク
　０Ｄａｙｓ：新しいフレームワークが出てくる

・JQuery AngularJS その他
　　ダントツトップJQuery
　　３分の１ Angular JS　
　　そのつぎ　cordova
　JQueryはかなり前から

・Google トレンド
　　JQueryは下降トレンド
　　Angular
　　Node.js

　　Backboneは安定的
　　Reactは伸びている

・Ｊａｖａｓｃｒｉｐｔの進化
　いつになったらとまるのか？→とまることはない
　Javascriptの進化 Webkit→blink:web標準
　TypeScript
　ES2016来年には2017
　HTML5.1勧告

　Node.js：サーバーサイド
　　ブラウザに依存しない

・ブラウザ言語から、ユニバーサル言語へ
　　クライアントサイドJavascript

　　　ＢＡＢＥＬ，トランスパイラー
　　サーバーサイドJavascript
　　　Express,Meteor
　→Universal Javascript

・ＪＳフレームワークの潮流
　　JQueryなど
　　　クロスブラウザ対応
　　AngularJS、Bootstrapなど
　　　プログラムの構造化
　　　バインディング
　　　ＳＰＡ（シングルページアプリケーション）
　　→バインディングのための処理の負荷が高く、パフォーマンスが犠牲
　　React,Angular2
　　　モジュラー化・コンポーネント指向
　　　仮想ＤＯＭ

・仮想ＤＯＭ＋コンポーネント
　　コンポーネントを作れる
　　レンダリングするときに、divタグとかに変える
　　→コンポーネントを定義していく

・差分だけを更新する
　　レンダリングスピードの向上
　　　サーバーサイドレンダリング
　　　ＡＪＡＸ：ＤＯＭをいじくる
　　　React：変えなければいけないＤＯＭを知っている：そこだけＵＰＤＡＴＥ

・今後のトレンドは仮想ＤＯＭ
　ＲＩＯＴ.js
　Ｖｕｅ.js（バージョン２で対応）
　ＭＶＣに変わるステートマネジメント手法も登場
　　Ｒｅｄｕｘ，Ｆｌｕｘ、Ｍｏｂｘ
　　モデル・コントローラーの考え方変わる

・ますます混乱する・・ＪＳ

・一方、モバイルＷｅｂも進化
　　十分に高速で大容量な端末スペック
　　WebViewの自動更新でフラグメンテーション回避
　　Progressive Web apps
　　　サービスワーカー（バックグラウンド）
　　　プッシュ通知を組み合わせ
　　→ネイティブあぷりのようなＵＸ

・モバイルで使うＪａｖａｓｃｒｉｐｔ
　Ｗｅｂアプリ
　ハイブリッドアプリ
　　cordova,React Native

・cordovaとReact Native
　　　レンダリング
　　　　Cordova WebView:基本はHTML5
　　　　React Native：React Native用のＵＩ
　　　プラットフォーム
　　　　Cordova:くろづプラットフォーム
　　　　React Native：対応すれば・・

・モバイル開発の課題
　　フレームワーク選定
　　ＵＩ実装
　　ツール・デプロイ・デリバリー

・モバイルＵＩの実装は難しい
　ネイティブと同じルック＆フィール
　　フラットデザインとAndroid Material Design
　　アニメーション効果
　モバイルならではのコンポーネント
　　スワイプ操作
　クロスプラットフォーム

・ＵＩ回月に必要なもの
　　iosとAndroidのデザイン
　　自動的にプラットフォームを認識
　　組合せらられる
　　パフォーマンス
　　無料で使える
　→OnsenUI

・完全なクロスプラットフォーム

・ツールデプロイデリバリー
　Ｍｏｎａｃａクラウド
　アプリ作成までワンストップ
　　→日本で最も普及しているCordova開発環境のひとつ

・はじめよい
　８月２６日　モバイルアプリ開発ソリューションセミナー

IoTの予算、PoCで５００万くらいまで？

Developper summit 2016 Summerにいってきた。

まずは、
すべてがつながるＩｏＴ時代の共創のあり方
講師：ウフル

をメモメモ

---

・ポケモンＧｏ　場所をつなぐ

・自己紹介
　モバイルクラウド→IoT

・ウフル；自由という意味
　テクノロジーと自由な発想で未来を作る
　設立１０年だが、１年で１００人増えた
　クラウドインテグレーター
　これまでは７０％ＳＦＤＣ：マーケティングクラウド

・すべてがつながるＩｏＴ時代とは
　モノのインターネット？

　　　モノ（センサー）　データ　プロセス　ヒト

　データ活用できていない

・事例：三菱重工　風力発電の状態をＩｏＴでつないでモニタリング
　　機械学習：予測モデル
　サトーＨＤが構築中のプリンタ遠隔管理ＳＯＳ（Sato Online Service)を支援
　　絶対にとめないことに価値がある
　デジタル化＝つながって境目がなくなっていくこと
　　社内と社外
　　広告とコンテンツ
　　上司と部下
　　企業と個人
　　自社と他社
　　コンシューマーと法人
　　リアルとバーチャル
　　男性と女性とＬＧＢＴ
　　人間とロボット
　　ハードとソフト
　Convergence/Connect the Un-connected
　コンバージェンスが起こる前には、崩壊が起こる

・デジタル時代には業界の境目がなくなり、ＩＴビジネスは流動的に
　　ビジネスモデルで融合
　　プラットフォームで融合
　　データで融合
　→デジタルオーシャン

・ＩｏＴビジネス推進・検討・協業上の課題
　　儲かるビジネスモデルがわからない
　　１社で実現できない。どこと組めばよいかわからない
　　物売りは出来るが、サービスは。。。
・従来型の開発やシステムの考え方がＩｏＴのシステムのポイント
　　従来
　　　　集中
　　ＩｏＴ
　　　　分散
　　　　予測できない
　　　　非構造的、欠損有り
　　　　構成の見直し
　→いままでの考え方では無理がある

・ＰｏＣ（ぽっく：コンセプト検証）から商用化
　ＰｏＣの実施（予算：～５００万円）
　　目的があいまいなことが課題

　評価と事業計画立案（予算：ゼロ）
　　効果検証が課題

　全社プロジェクト化（予算：数千万円～）
　　体制構築が課題
　　ステークホルダーの多さ
　　全社プラットフォーム化が課題

・ＩｏＴの悩み事：実際に起こるデータロギング環境のとらぶる
　　数百拠点からばらばらにデータがアップロード
　　ワイヤレス通信
　　クラウド側へワイヤレス通信
　　　ノイジーな環境
　　デバイスからデータ収集
　　　通信負荷

・ＩｏＴ実現の上で必要となるアーキテクチャ
　クラウド
　　　業界別サービス・コンテンツ
　　　業務別アプリケーション
　　　プラットフォーム
　　　ネットワーク
　オンプレミス
　　　エッジコンピューティング・ゲートウェイ
　　　ＬＡＮ
　　　デバイス・センサー
　　セキュリティ

・米国ＩＩＣ(Ｉｎｄｕｓｔｒｉａｌ　Ｉｎｔｅｒｎｅｔ　Ｃｏｎｓｏｒｔｉｕｍ）
　米インダストリアルインターネットコンソーシアム
　　標準化団体ではなく産業界のＩｏＴ事例確率のために設立
　　ＩＩＣの推進方法論
　　　実現意識を持っている企業群がユースケース(testbet)を実現する事に注力
　　つながるのか？インターネットは？
　　　ローカルで繋がるモデル→オーバーレイするネットワーク

　大企業とベンチャーが器具用と業界の垣根を越えてコラボレーション
　　　大企業、ベンチャー、ＩＴ，ＯＴ
　Ｉ３

　実現したいことが明確
　　アイデアを速くまとめる
　　オープンイノベーション

・すべてがつながる時代の共創のありかた
　ＩｏＴじつげんのためのウフルの考え　
　　ＤｅＣＩＤＥ
　　　Ｄｅｃｉｄｅ
　　　Ｃｏｌｌａｂｏｒａｔｉｏｎ
　　　Ｉｎｎｏｖａｔｉｏｎ
　　　Ｄｒｅａｍ
　　　ＥｃｏＳｙｓｔｅｍ

・ウフルのＩｏＴへの取り組みはプロデュース／コラボレーション型
　　どこからでも取り入れて、どのパートでも切り出して提供可能

・コラボレーションの形：ＩｏＴパートナーコミュニティ
　　実ビジネス構築を推進
　　共同運営体制
　　プラットフォームフリー
　　スピーディーに検討推進できる
　　７つのワーキンググループ
　→温度間が合っていること

・ウフル自体も続々と様々な企業と

・ウフルの新オフィスにおける共創
　　つなぐことを重視
　　　　共創カフェ
　　　　共創空間と協創本部（＝バックオフィス＝総務部）

・つながる時代のキーワード「コラボレーション」と「イノベーション」

　例１：昨日セミナー
　ＩｏＴへの取り組み。まずは商用車管理から。テレマティクスセミナー
　例２：来週こんなセミナー
　　ウフル・ＡＢＥＪＡ・ソラコム→懇親会の場で

・さいごに
　５つの共創のポイント
　（１）様々なもの事の境目を意識しない
　　つないで問題を解決する

　（２）自分だけ、自社だけで取り組まない、
　　他者・他社と一緒にすすめる

　（３）競合となる企業であっても競争するのではなく、
　　共創する

　（４）小さな課題からスケールして、大きな社会課題を
　　解決することをねらう

　（５）生産性を向上するのではなく、新しいこと、
　　イノベーションを狙う

・１１月に山崎宇宙飛行士と講演（ＩＴコーディネーター協会）　

Deep Learning Frameworkまとめ

有名どころのフレームワークがまとまっているので、メモメモ

こんなにあった！ Deep Learning Frameworkまとめ
https://bita.jp/dml/dl_matome

ポケモンＧｏの検索も、自動化する時代に・・・

いや～、自動化も、ここまで来ているのですね・・

ポケモンを検索するのに
Pokevision(https://pokevision.com/)（いま、繋がらない？）や
P-GO SEARCH（https://pmap.kuku.lu/）
を使うのは、もはや当たり前、最近は、AmazonにＥＣサイトたてて、自動化する時代なの？

ポケモンGOで自分の近くにポケモンが出現したらSlackに通知する
https://blog.animereview.jp/pokemon-go-to-slack/

NECのAIブランドWISEって、富士通のZinraiみたいなもん？

NECからAIおまとめブランドWiseっていうのが出たらしい

NEC、AI（人工知能）技術ブランド「NEC the WISE」を策定
http://jpn.nec.com/press/201607/20160719_01.html


これって、富士通のZinrai

当社が培ったAI技術を「Human Centric AI Zinrai」として体系化
http://pr.fujitsu.com/jp/news/2015/11/2.html


みたいなもん？

IoT案件は２つの前提を入れると、Web案件に変化（難易度低下）する件

って、あまり知られていない？ひょとして？

---

まず、IoT案件は、以下のように思われているので、難しいと感じてしまう。

・センサーからの出力はシリアル（UART,I2C,SPI）→無線（ZigBee,Wi-Sun,Wifi,BLE)
・センサー入力から、アクチュエーター・表示系が、双方向で通信する

この案件を、そのまま処理しようとすると、たしかに難しくなってしまい、
Webの世界にならない。

---

しかし、ここに２つの前提をいれる

（１）ゲートウェイ（GW)を利用する。またはWiFiにする

　XBee（開発会社Digi)等、多くの会社は、無線通信データをインターネット上に流せる
　ゲートウェイを持っていて、さらにデータ加工できる場合もある。

　この場合、データをHTTPプロトコルに変更し、Webサーバーを叩くようにしてしまえば、
　Webサーバーで処理できる。

　または、もともとWiFiで、HTTPでアクセスしてWebサーバーを叩くようにする。


（２）画面表示やアクチュエーターのデータ獲得は、一定間隔おきにする

　　●センサーデータは、センサー→サーバーの一方向しかない。
　　　（サーバーからセンサーにコントロール信号を送る場合は考えられるが、
　　　センサーは一定期間ごとに送信するので、その返事にコントロール信号を
　　　載せても良い。そうすれば、一方向になる。そこまで考えなくても、ふつう一方向）
　　　この方向は、センサー→GWからWebサーバーを叩くことで実現できる

　　●表示画面やアクチュエーターは、サーバーからデータをもらうことになる。
　　　なので、双方向といっているが、これは、もし、１秒なり、ある一定ごとに
　　　聞くことが許されるのならば、一定間隔ごとに、タイマー（HTMLの場合は
　　　　meta http-equiv=" refresh " ）をかけて、サーバーにきく形にすれば、
　　　画面→Webサーバーを叩くという結果になる


（１）（２）の前提を入れると、すべての通信は、最終的にWebサーバーを叩くという
通信の流れに出来るわけで、そうすると、Web案件になってしまう。

---

つまり、２つの前提

　　（１）GWを使うか、WiFiにするかして、すべて通信はHTTP（HTTPS）
　　（２）表示画面、アクチュエーターは定期的にサーバーに確認するのでOK

があれば、IoT案件ってのは、Webと同じ開発手法で開発できて、
それってPHP＋JSでできるから、簡単なお話になるのだ・・・

要するにApache NiFiって、TalendみたいなETLなの？

話きいて、そんな風に感じた。
その「話」とは、７月２７日に行われた

Apache NiFi 勉強会 ～データフローの自動化～
講師：Hortonworksのかたがた

その内容をメモメモ

---

■会場提供のご案内　IDCフロンティア
・親会社 yahoo
・IoTのとりくみ
　ツール・ド・東北支援IoT　ハッカソンやります
　今週金曜日説明会。ぜひきて！
　８月１９日発表会
　復興支援
　connpassに記載してある。

■そのデータフロー Wifiで楽にしてあげましょう
・自己紹介

・HDF Apache NiFiとは
　DataFlowの概略図：簡単、明確？→実際は複雑
　シェルスクリプト書いてマネジメント：コストかさむ
　　→スキーマ変わった！とか
　Apache NiFi　
　　ＥＴＬでもあるし、
　　ストリーム処理につよいし
　　Ｗｅｂブラウザから実行できる、

・ＨＤＰとＨＤＦ
　　ＨＤＰ：Hadoopエコシステムをまとめたもの
　　　→ビッグデータ、データレイク
　　ＨＤＦ：データを取ってくる位置づけ
　　　→データレイクの手前、IoTデータを取りに行く

・統合されたプロセスと制御

・実績のある運用有効性

・国家安全保障局（ＮＳＡ）が開発したＮｉＦｉ
　→エンタープライズにマッチ

・リアルタイムデータロジスティックスの統合的かつインタラクティブな制御

何かと便利そうなので、まずは使ってみよう！
・インストール方法
　Ａｐａｃｈｅ　ＮｉＦｉ単体でも（Ｊａｖａのアプリケーション）
　ＨＤＰとセットで
　Ｄｏｃｋｅｒイメージもあるので
　Ａｐａｃｈｅ　ＮｉＦｉソースからビルド

・起動：
　ダウンロードして、展開
　bin のなかにシェルがある起動すると
　8080ポートにアクセスすると使える
　設定はconfの中

・ＨＤＦインストール方法：ＨＤＦとセットでお試ししたい方向け
　ＨＤＦのバージョンとNiFiのバージョンは別
　NiFi 今0.7　この夏1.0

・起動すると：真っ白なキャンバス

簡単チュートリアル
・Ｓｔｅｐ１：データを集める
　プロセッサーをドラック
　Get
　どっかからデータとって来る
　出力とつなぐ
　再生をクリック

・ここがポイント
　データフロー、フローファイル（流れるデータ）
　フローファイル：コンテントとアトリビュート
　プロセッサー：フローファイルを何かする
　プロセッサーに名前が付けられる
　終端になるプロセッサー：オートターミネート

・Ｓｔｅｐ２：データを加工する
　ばらす：sprit text
　　　大きく分割→１行ごとに
　extract text
　入ってきた　加工　メタデータ
　→アトリビュートをリッチにしていく

　ここがポイント

・Ｓｔｅｐ３：データを分類する
　るーとおんあとりびゅーと
　他システムのスキーマ：キャッチすると検知しやすい
　$ $フローファイルのアトリビュート
　データフローを作った後に
　足りなくなったらバッファリング

・例
　put slack

・データ来歴；時間をさかのぼって

・今回しゃべった内容

---

■Apache NiFiと他プロダクトのつなぎ方
・自己紹介

１連携手段
　おおきく２つ
・外部データストアの利用
・Input Outputポートを使用

・外部データストアを使用
　データストアを解して他プロダクトと連携
　ＮｉＦｉ，連携先にコンポーネントが必要
　利点
　　並列化で容易にスケール
　欠点
　　管理プロセス増大

・Input Outputポートを使用
　ＨＴＴＰ
　ヘッダー部に存在
　複数のＰｏｒｔを管理可能
　Site to Siteクライアント
　　任意のJavaプロセスが直接通信
　　公開されている
　　　Flinks,Apex
　　クラスタ？、ロードバランサ？？

・Flinkとの接続サンプル

---

■IoTアプリケーションで利用するApache NiFi
　Hadoop Summit Tokyo　１０月２６日、２７日

・ＨＤＦ　ＨＤＰ
・ＩｏＴ　and ＮｉＦｉ
　ＩｏＴ？
　What we can do with IoT 自動車
　・商用自動車
　　利用率、燃費最適化、故障予知（プリディクティブメンテナンス）
　　ドライバーのスコアリング
　　たくさんのデータソース　天気、車の管理情報なども
　　ＩｏＴデータでコネクティッドカーのデータをさらに豊富に
　　事例：プログレス（個人的自動車保険　ＯＢＤ）
　What we can do with IoT 農業事業者
　　水をまいたり、ドローン
　What we can do with IoT 通信事業者
　　基地局の最適化：利用率の監視
　　セルフオプティマイジング
　　セルタワーの管理
　　ＣＤＲ，
　ＩｏＴアプリケーションはデータソースが様々
　　　データの種類、
　　　データの流速、
　　　データのあて先
・Ｄｅｍｏ
　ＩｏＴ　ＭＴＡ　サブウェイ　ＩｏＴ　アプリケーション
　　ＮｉＦｉ
　　　ストリーム
　　　　getHTTP（一定時間でＨＴＴＰを取りに行く）
　　　　ラムダアーキテクチャ
　　　バッチ取り込み
　　　　駅の位置情報など　getHTTP
　　　　スタティックなストレージ
　　どこまでＮｉＦｉでやるかが設計のしどころ

・まとめ
　データソースが多種多様
　システムアーキテクチャ：データソースとデータ処理
　　それってfluentdでよくね？どっちもあり！

「ポケモンGOは早くて1週間で飽きる」 ？

という意見があるみたい

「ポケモンGOは早くて1週間で飽きる」 的確な指摘に、プレイヤーから納得の声
http://buzzmag.jp/archives/74513


だいじょうぶ、そのあとは、「パチモンでGO」ってなるから（＾＾；）

【悲報】ワイ、ずっとパチモンGOをやっていたｗｗｗｗｗｗｗｗｗｗｗｗｗ
http://blog.livedoor.jp/chihhylove/archives/9312396.html


P.S

ポケモンGOプラス 9月に発売延期 準備に遅れ生じる
http://news.goo.ne.jp/article/sponichi/trend/sponichi-spngoo-20160727-0128.html

いやいや、今ではなく、一旦下火になったときにまた出そうという
魂胆でしょう・・・（＾＾；）

「納品のない受託開発」の話を聞いてきた

７月２６日、要求開発アライアンスの

　夏は開発スタイルを再考する！

にいってきた。その内容をメモメモ
（表題の話は、後半）

---

■ビジネスまで最短距離のモデリングを考える
　～中規模以上のシステム構築で効果を上げるために～

・今日話したいこと
　俊敏な開発が求められている
　　→アジャイルに行く？行かない
　　→ウォーターフォール？評判悪い
　　→アジャイルとウォーターフォールは対立関係にある？
　　→準備段階でのモデリング、顧客フィードバック指向

・ウォーターフォールＶＳアジャイル
　それぞれの至高のメッセージは何か
　ウォーターフォール
　　大勢の人がアツ間得られる前に準備を済ませるほうが経済的！
　アジャイル開発
　　顧客（市場・ユーザー）からのフィードバックを最速で取り入れなさい！

・開発手法の４証言
　　　　　　　　　　　　　　　　　　システム規模
　　　　　　　　　　　　　　　大　　　　　　　　　　　　小

顧客からの　　　ＹＥＳ　　　　？　　　　　　　　　アジャイル開発
じんぞくな
フィード　　　　ＮＯ　　　ウォーターフォール　　　なんでもＯＫ
バック

？：探すべきは、ここの解

・メガプロジェクトって知ってますか
　プラント建設の工程：ウォーターフォール
　ＦＥＬ（フロントエンドローディング）　IPA
　インダストリアルメガプロジェクト
　テストを取らないと、次の工程にいけない

　ＦＥＬ
　　ゲート１：ビジネスケース
　　ゲート２：スコープ
　　ゲート３：実行開始できるか

　背景にあるコストの考え方
　　　リスクや不確実性：下降していく
　　　変更リスク　　　：上昇していく

　アジャイル開発との対比
　　　ＸＰの場合
　　　　一定の条件がある場合、変更コストはフラットに近い
　　　　　変化を受け入れよ→程度問題？

　大規模化に伴い、変更コストは加速度的上昇する

　最適解は、２つの極端の中間に
　つまり、どんなプロジェクトにも適切な準備＞０が必要である

・もっと準備のことを語ろう
　準備のことを語るのは恥ずかしくない
　準備こそ、語り、継承されるべき
　実装を急ぐことが経済性に優れている、キャッシュフロー上好ましいという議論は誤り
　　コストが大きければ負のキャッシュフローが生まれる

　準備の例
　　エンタープライズアジャイル手法における準備
　　　ＲＵＰ
　　　ＤＡＤ　でぃしぷりんどあじゃいるでりばりー
　　　SAFe
　　政府ＩＴ調達における「準備」

　ＲＵＰ／ＵＰ（統一プロセス）
　　　要求分析、アーキテクチャ、ベースライン設計
　　　方向付け：要求分析・要件定義　要件：ビジネス要件
　　　推敲：アーキテクチャ、ベースライン設計

　ディシプリンド・アジャイル　２．Ｘ　Scott W.Ambler/Mark Lines
　方向づけ　構築　移行

　推敲がないのは、固定的に考えてほしくないから
　コンテキストに合わせてプロセスモデルを選択してほしい
　SAFe（Scaled Agile Framework)

　一回は離陸させないと・・

　政府ＩＴ調達における「準備」
　　要求分析
　　アーキテクチャ・ベースライン設計

　要件定義からＲＦＰをつくってしまうのは・・・

・何を準備するのか
　準備の定番は要件定義
　　　要件のＦＩＸを待ていたら仕事がなくなる
　　　開発環境の変化：要件と並行・先行してアプリに適したやりかた
　　　クラウドネイティブな開発やPaaSへの期待
　準備の中心はＷＨＡＴからＨＯＷに移り始めている
　　ＨＯＷ：ベンダーロックイン？→ＯＳＳで問題をクリア

・ＨｏＷの準備≒（広い意味の）プラットフォーム選定・構築
　　アーキテクチャベースライン
　　各種設定・オプション選択
　　モデリングツール
　　　ＵＭＬ
　　　ＥＸＣＥＬ
　　　ＤＢ
　　　要求定義言語
　要求（メタ）モデル
　要求・実装変換手法
　初期要求モデル（機能・非機能）
　創意と信頼の土壌

・アーキテクチャベースラインとは何か
　ある種のメタモデル

・機能とシステム要素との関係を洗い出す

・要求実装変換手順
　工程を作る

　ＨｏＷを上流化：つなぎを明確化

・どうすれば仕様の不連続点を回避できるのか

・プラットフォームに制約された要求モデリング
　顧客価値モデル
　実装価値モデル

・ショッピングサイトの例
・ますます重要になるＩＴアーキテクトというロール
　資質としては
　　知識
　　責任感
　　人や組織に働きかける

---

■ソフトウェア受託開発の変化と未来
　新しいビジネスモデル・ワークスタイル・マネジメント

・自己紹介

・戦術としてのアジャイル、アジャイルのための戦略
　環境の中でアジャイルに取り組む
　　→目標・現場・戦術・意識的
　アジャイルになるように環境を作る
　　→結果・経営・戦略・無意識
　Don't just do Agile Be Agile

・アジャイル開発と受託開発
　なぜ、アジャイル開発は失敗するのか
　　ウォーターフォールとの違いは
　　メソッドか、マインドセットか
　　アジャイルはなぜ繰り返すのか
　　すべて作ろうとするから失敗する
　おおきくしない・作らない
　　１００この機能を作るのなら、ウォーターフォールの方が早い
　　１０こづつつくって、５０こでやめる
　　受託では１００個つくらないと・・

・受託開発に潜む問題「ディフェンシブな開発」
　　発注者と受注者でのゴールの違い
　　使う価値よりも、要件定義に従う
　　詰め込む要求と計画を守る対立
　　生産性が低いほど、高くなる見積もり
　ビジネスモデルの構造的欠陥
　　→ボンクラ集めたほうが儲かる

・ディフェンシブな開発がもたらすもの
　　受託開発ビジネスの本質は保険屋
　　人月見積もりと成果物責任のねじれ
　　多重請負の見積もりによるバッファ
　　使いにくい使われないシステム
　誰も幸せになっていないのでは？

　世界は変わらない？→「世界」は、変わっている

・世界の変化
　ＵＢＥＲ
　あずまま（ベビーシッター予約）

　企業を取り巻く状況と重要性を増すソフトウェア
　ＵｂｅｒやＡｉｒＢｎｂなどのＩＴ企業の登場
　既存のマーケットを根底から覆す
　ＩＴの利用からＩＴを前提

・これからのソフトウェア開発に求められること
　要件の予測は困難で日々変化する
　ユーザーが使い始めてからスタート
　システムの完成は目指していない
　小さく初めてから大きく育てたい
　事業の成長を支えるパートナー
　→内製：社内にエンジニア

・受託開発に求められる顧客ニーズの変化
　事業の成長に合わせて回収したい
　長期的視点と経営視点を持つこと
　内製は開発者の採用と育成が困難
　従来の害虫は高額で柔軟性が低い
　新たなニーズに対する受託開発

・納品のない受託開発
　月額低額で、開発と運用を続ける
　顧問としてすべての工程を担当する
　働く時間でなく、成果を提供する
　ビジネスの成長をＩＴでささえていく
　コンサルティング＋開発

・メリット
　　要件定義をしなくてもよい
　　仕様変更はいつでもできる
　　直接エンジニアに相談してもよい
　　作らない提案をしてもらえる
　お客様の問題解決が仕事

・やっていないこと
　　　ドキュメントはいっさい作りません
　　　訪問しません
　　　営業担当はいません
　　　納期を死守する約束はできません
　圧倒的な費用対効果を実現

・ＡｓＭａｍａ
　　エンジニア０人
　　ソニックが技術担当

・コモンプログラマという新しい職業
　　プログラミングで問題解決をする
　　コンサルタントができる開発者
　　ソフトウェアすべてに責任
　　事業成長を支える
　難しいから価値がある

・通勤のないワークスタイル
　社員の半数が地方から働く
・リモートチームという働き方
　　仲間と一緒に働くリモートワーク
　　雇用関係・長期的関係で共に働く
　　個人の結果でなく、チームの結果

・リモートワークの誤解を解く
　　顔を見ながらの打ち合わせはある
　　場所は離れても同じ時間帯に

・オフィスRemotty
　同僚の顔や様子が見えて声がかけやすい
　自分用に書きこめる場所があって、気軽に発言できる
　独り言が流れる

・リモートワークのメリット
　生産性のアップ　９時からスタート、会議室の予約要らない
　給与格差はない
　場所に縛られずに採用できる
　選びたい場所と仕事と仲間の両立
　オンとオフの小口化ができる

・管理のないマネジメント
　　社会の変化、テクノロジーの深化
　　単純労働から再現性のない仕事へ
　　指示・命令のマネジメントは不適
　　ナレッジワーク
　管理しないが生産性が高い
　　なにも管理しないと生産性が一番高い

　金タイ進捗業務管理しない
　役割分担はあるが指示命令はない
　上司はおらずセルフマネジメント
　ビジョンはあるが売り上げ目標はない
　自己組織化された

・業務文章のない組織戦略
　　属人性を重視
　　チームを重視
　　中間管理職を置かない
　　兼務を推奨（会社に組織図がない）
　ヒエラルキーで支配しない

・ピープルファーストの人事戦略
　　案件あり木で採用せずに人ありき
　　人材の採用まで長い時間をかける
　　コア・コンピタンスは採用と育成
　　仕事の評価と報酬は連動させない
　良い社員と良いお客様をつなぐ

ソニックガーデンを支える経営モデル
　　ストックビジネスだけに集中する
　　太い客より細い客をたくさん持つ
　　キャッシュフロー
　　イノベーションのための部活
　お金を稼ぐより時間を稼ぐ
　　　腕を磨くと人月さがる
　　　コンサル：腕を磨けば
　遊んでたから、新規事業になった

・管理なくても経営はある
　ビジョンを考えて伝えていくこと
　率先して変化を起こしていくこと
　現場での実体から制度にすること
　人に依存しない仕組みをつくること
　仕組みで勝って人で圧勝する

・受託開発の未来に向けて
　来るべき社会の変化
　　少子高齢化人口構造の変化
　　量に頼らず価値を出せる仕事とは
　　世界に新しい価値を生みだす仕事
　　誰かの難しい問題を解決する仕事
　価値ある仕事へのシフト

・これからの仕事
　　ナレッジワーク
　　リモートワーク
　　ライフワーク
　　パラレルワーク
　一人ひとりの多様性を大事にする

・アジャイル企業の目指すポジショニング
　予測型計画重視ー適応型結果重視
　　　　ＶＳ
　大人数ー少人数
　　従来型の企業
　　アジャイル企業

・アジャイル経営宣言
　　変化への対応
　　個人の自主性
　　持続的な顧客価値
　　社員の幸せ

API活用で未来をひらく方法を聞いてきた

７月２６日、「API活用で未来を拓け～APIエコノミー成功のカギ～」をきいてきたので、その内容をメモメモ。

ちなみに、途中で

　シティバンクのハッカソンでＡＰＩ公開
　GoogleMap API,Yelp API,Citi Wallet API

とでてくるYelpの日本版が、昨日書いた【Pokémon GO】「周辺のポケストップ」検索方法がわかりにくいので、やり方をかいてみるの検索だと思う。

---

■IoTで拡大する、ＡＰＩエコノミー～ヤフーにおけるmyThingsの取り組み～

・米ベライゾン買収：日本は元気にやっている！
・ポケモンＧｏ
　Google：ナイアテック　イングレス
　ポケスポット：ランドマーク　写真
　　→イングレスのときにランドマーク：クラウドソーシング
　　　ビッグデータ
・Google APIの創り方が上手い
　イングレス：他でも利用できること前提
　薄皮一枚で、やってなかったイングレスのゲームが、みんなやっている
　→ＡＰＩエコノミー

・ＡＰＩを使うことで、事業の自由度もかわるし、タッグも組める
　Ｗｉｎ－Ｗｉｎ：どう実装するの？
　　それぞれ創りこんだら、市場は待ってくれない
　　すぐにできないと
　　　昔はＰＣの電源入れるところから：立ち上がるまで５～６分まってくれた
　Go To マーケット：ＡＰＩ

・自己紹介
　モバイル野郎です

・YahooもＡＰＩ
　RESTfulなＨＴＴＰ多い
　２つある：
　　公開しない
　　社外の人と、オープンイノベーション
　　　Ｇｏｏｇｌｅは上手い
　ＹＡＨＯＯは９割強が社内ＡＰＩ

・YAHOOショッピングＡＰＩ公開
　　あまぞん、らくてん、ＹＡＨＯＯ
　　出展料無料→出展数、出品数も日本Ｎｏ１
　　お客さんの立場に立って
　　自由度高い
　　外部との提携：寺田倉庫　みにくら
　寺田倉庫さんと話した中で・・・

・ＡＰＩエコノミー
　オープンイノベーションと
　　お客様の目線に徹する
　　だれかもってませんか？→はい、持ってます！！

・ＡＰＩ利用事例：ハッカソン（Hack Day）

・Open Hack Dayの実施要綱
　２４時間でプロトタイプ
　９０秒のプレゼンテーション
　なんでもアリ！

・Open Hack Day3
　IoT：協賛
　プロトタイプ：最終製品にそのままなるとは思っていない
　持ち帰って、社内で「この軸で考えてみよう」

　ＡＰＩとオープンイノベーション：セットでとらえる

・インターネット活用はスマホからIoTへ
　　モノがインターネットに繋がることで、
　　生活がもっと便利になっていく世界へ

・あのときが起点になる年
　２０２０年　オリンピックイヤー
　　自動運転、先進的：世界にアピール
　スマホの進化：とまっている（大体同じ）
　→インターネット活用はスマホからＩｏＴへ
　iPhoneも減速：もう８年経ってる・・
　がらけー(2000年）からiPhone(2008)：８年
　→プロダクトサイクル：８～１０年
　次は？ＩｏＴ
　　クラウド

・YAHOO Japanがなぜやるのか
　速い世の中の動き
　→企業も消費者も巻き込んで、新しい活を創造する
　　オープンイノベーションが成功のカギ
　すまほ：インプットとアウトプット一体化
　IoT：ばらばら（ディスプレイを持たない）
　　天気予報で色が変わるかさ

・個別個別に対応するのは不可能：ＡＰＩ
　→スピード間に合わない　自前主義は難しい
　スマホ　ＢＬＥ：はまだまだ
　いつでもどこでもインターネット
　→人にコンピューティングが合わせる
　　ディープラーニング；学習
　→選択肢を効率的に出すのは出てくる；確率

・ＩｏＴ：センサー　山ほど
　世の中になかったデータが生まれる
　：ディープラーニングにぶっこむ
　：新たな価値
　ＡＰＩ

・myThingsのご紹介
　４９個のサービスやモノとの組み合わせで新しい生活体験を提供

　協業事例　(株）グラモ様
　家の最寄り駅についたら　へやをあたためる
　ユカイ工学　ぼっこがお話

・すべての企業・開発者にオープンにしていく

まとめ
　エコノミクス、オープンイノベーション
　ＡＰＩがないと、間に合わない
　クラウド・ビッグデータへの投資とＡＰＩ
　そこから先は簡単、がわを変えれば色違いのクルマが出来る

センサーネットワーク：
　可視化できる

---

■ＡＰＩエコノミーを知る～企業が繋がるエコシステム

・ＳＯＡ化ＥＳＢから、ＡＰＩ化
・企業に大きく影響するのは業界の融合
　今具３－５年でもっとも自社に影響を及ぼすトレンドは？

・うーばりぜーしょん
　ウーバー症候群：
　モバイルの進化が業界の融合を加速する

・ＡＰＩ公開が最高のモバイルを生む
　ＢｔｏＥアプリ：
　　草食系モバイル：スケジュールとか
　　ガテン系モバイル：現場の写真
　　社交系モバイル：社交的使いから
　　師匠系モバイル：ワトソン
　　執事系モバイル：今日ここ

・Fintechもモバイルとともに進化した
　Fintech企業：スタートアップ
　　リーマンショップ：アンパックド（銀行口座もてない人）
　　　→モバイルでおくれる
　ＰＦＭ：ぱーそなる・ふぁいなんす・まねじめんと

・ＡＰＩエコノミーのバリューチェーン
　ＷｅｂのＡＰＩを公開するかしないか　大きなインパクト
　　→発見できる

・今起きているＡＰＩエコノミーと特徴
　一社でやっているのには無理がある
　　→いつまで自前でやるんですか？

事例
・金融機関のＡＰＩ公開の可能性
　ＰＦＭアプリがスクレーピングをやめ執事系へ

・銀行ＡＰＩ公開
　シティバンクのハッカソンでＡＰＩ公開
　GoogleMap API,Yelp API,Citi Wallet API

・航空会社のＡＰＩ公開の可能性
　旅行アプリがスクレーピングをやめ執事系へ
＊スクレーピング　ログインしてＨＴＭＬ画面を開き、
　一定のところを読み込んでいる

　新たなＡＰＩプランでパートナー差別化

・自動車会社のＡＰＩ公開の可能性
　ＩｏＴデータをＡＰＩで安全に公開
　　パートナーの差別化＆強化

・必要なこと
　これからは２スピードＩＴに対応していく
　　デジタルＩＴ：変化激しい、クラウド
　　エンタープライズＩＴ：

・モバイル対応初期：モバイルユーザーの要求に自前で個別対応
　ＡＰＩ化初期
　　ＡＰＩゲートウェイに進む：デベロッパーに移管
　ＡＰＩエコノミー
　　インテグレーション推進でＳｏＲの価値を最大化
　　ＳＯＡ化：その先にＡＰＩ公開

・インド州政府の２ＳｐｅｅｄＩＴ対応
　ＡＰＩ管理のためのソフトウェア：API Connect

・関西の製造業の２ＳｐｅｅｄＩＴ対応例
　　社内デベロッパーのためのニーズ

・ハッカソン
　アイデアソン、ハッカソン

・ＡＰＩを公開する、ＡＰＩを利用する価値
　　ブランドイメージの向上
　　エンタープライズＩＴを統合して、ＡＰＩエコノミーをリードする

---

■APIエコノミーがもたらす、未来のラジオ始まる
日本発デジタルラジオ放送局
・ムービー

・V-Lowマルチメディア放送
　１～３チャンネルの帯域を使って
　ラジオをデジタルにしよう！

　ＡＭ　ＦＭ　i-dio　ＴＶ
　２０１６年３月１日正午から放送
　７月１５日　amanekチャンネル本サービス

・ideoのモビリティ視点での特徴
　ＩＰを放送に流せる
　輻輳に強く一斉同報
　クルマと親和性高い

・６つのラジオ局
　TS One
　Amanek
　クラッシックなど・・

・創業者
　　いまい氏：ＨＯＮＤＡ
　　庄司氏：音楽、データベース　レコメンド→タワーレコード、napstar

・震災
　被災地支援
　あれから５年　あの時、道は圏外だった
　　カーナビ：通信網がやられた
　災害のときに、的確に情報を伝える

・動画 Amaneku

・１４社で、８億３千万出資（今でも募集中）

・特徴
　スタジオからドライバーを空から見守る
　放送Ｘ通信ＸＧＰＳＸビッグデータを融合
　１５分先の未来を伝える

・ドライバーを空から見守る
　ビッグデータ可視化モニター

・放送Ｘ通信ＸＧＰＳＸビッグデータが融合した新しいメディア
　自社に関わる情報を車載木が選択して再生

・１５分先の未来を伝える
　１５分先の気象リスクを自動音声ＴＴＳで伝える

・ドライブに影響する気象警戒情報を１Ｋｍ単位で
　２４時間３６５日

・Ａｍａｎｅｋチャンネル
　チャンネルナビゲーター
　アプリをダウンロードして

・でも；動画

・Amanekアプリの特徴
　放送から直接ＩｏＴとつながる
　クルマでの使い勝手を考えた、ノールックインターフェース

・クルマでの使い方
　チューナーを新しく開発
　スマホにＷｉＦｉ　スマホからＢｌｕｅＴｏｏｔｈ

・インターネットでも受信できる

・Amanek事業チャンネル
　２セグ
　　働くクルマチャンネル
　　　ドライバーに寄り添った番組
　　サイネージチャンネル
　　　サイネージをダイナミックに制御
　　地方創生チャンネル
　　　地域ＦＭと連携

・ＡｍａｎｅｋとＡＰＩ公開
　ＡＰＩ３つ
　　渋滞情報
　　設定した時間に楽曲配信
　　広告・クーポン配信
　気分に合わせた音楽配信：ＡＰＩ
　ＡＰＩと放送用プラットフォームを公開、
　パーソナルロボットがしゃべる

・amanekドローン
　東京タワーから

・ＧＰＳつき、移動体向け防災ラジオ
　ペットボトル形状

・ＧＰＳつき移動体向け防災ラジオの展開

・自動運転
　ＡＤＡＳ（次世代安全運転）
　・センサーフュージョン
　・予測して走る
　ダイナミックマップ用データ収集・配信案

　気配＝道路管理者に提供
　トンネル内に入るな警告
　逆走検知の配信→カーナビが通信で繋がる

・モビリティを愛する全ての人のために
　

---

■ＡＰＩエコノミーを実現する　企業のＡＰＩを支える技術
海外はＦｉｎｔｅｃｈ以外でも
・デジタル化された喫茶店では２１％の注文がモバイルで行われています
・プジョー：車両データをマネタイズ
・シティーバンク：ハッカソン

ＡＰＩエコノミーのバリューチェーン
・既存エンタープライズＩＴ資産を
・ＡＰＩとして公開する
・開発者がセルフサービスで利用
・顧客体験の差別化
・革新的なアイデアをアプリ化

ＡＰＩはあらゆる事業を変化させる

なぜＡＰＩに取り組むのか
・スピードの向上
・ＳＯＲを安全に外に
・ブランド価値
・
ＡＰＩとして公開する
既存のエンタープライズＩＴ資産を？

デジタル変革を実現するマルチ・スピードＩＴ
　変化の激しいデジタルＩＴ：クラウド中心
　安定したエンタープライズＩＴ
　→ＩＢＭ　Ｃｏｎｎｅｃｔ

様々なソリューション：IBM Connectシリーズ
ＳＯＲをＡＰＩ化、利用促進
ＩＢＭ　クラウドの会社になっている
ＩＢＭ　クラウドサービス
　ＩａａＳ：ＳｏｆｔＬａｙｅｒ
　ＰａａＳ：ＢｌｕｅＭｉｘ
　ＳａａＳ：ＡＰＩサービス
→CloudFoundry,Dockerコンテナで
BlueMixＩＢＭが提供するＡＰＩエコノミープラットフォーム
ＡＰＩを使ってサービスを解放：ひっかかる
ＡＰＩ；中で使っているのが多い
　→ＡＰＩの利用シーンは外部連携に限定されません
　　public ,protected,private
　　→privateがおおく、ここからはいるのが良い

良いＡＰＩとは→解はない
だめなＡＰＩとは
・ドキュメントに問題
・コミュニケーションに問題
・使い方は難しい、仕様が独創的
・利用条件や制約が分からない
・信頼性が低い
・利用者向けのツールが貧弱
・適切なサポートが提供されていない
　など

出典：Ten Reason Developer Hate your API

良いＡＰＩとは→そのはんたい

ＡＰＩ　ＧＷソリューション IBM API Connect
　ワンパッケージ
　ＡＰＩ公開に伴って発生する課題を解決
　　　迅速にＡＰＩ開発
　　　ランタイムの品質性能
　　　管理を効率的に
　　　セキュリティ

ＡＰＩ基板アーキテクチャ
　　ＡＰＩサーバー
　　　↓
　　ＡＰＩゲートウェイ

　　ＡＰＩポータル
・機能コンポーネント
・クラウド・オンプロミスで柔軟に展開可能

ＡＰＩ公開のステップ
役者
　ＡＰＩ開発者：開発する
　ＡＰＩ管理者：課金体制なども決める
　アプリ開発者：ＡＰＩを利用する

ステップ
　ＡＰＩ開発
　ＡＰＩ仕様とポリシー定義
　ＡＰＩの製品化
　ＡＰＩキー発行利用登録

ＡＰＩ仕様
　Swagger2.0で仕様を記述する
　　　セキュリティポリシー設定
　アセンブル＝フローエディタ

製品化とレート制限
・製品：ＡＰＩをパッケージ

開発者ポータル

分析機能

まとめ
・ＩＢＭと一緒に始めてみませんか

おわりに
・ＡＰＩはＷｅｂページに続く企業の顔になります
・ＩＢＭ　ＡＰＩカフェ

---

■トークセッション
　ＡＰＩエコノミーを広める～ＡＰＩユーザー企業からの提案
　スマイルワークス

・ＣＳＶの連携：たいへん
・業務ソフト　クラウドになる
・写真取ると、家計簿付けてくれる

連携事例１　入出金明細自動会計仕訳連動

連携事例２　リアルタイム経営診断

連携事例３：自動請求書発行・自動入金消しこみ

連携事例４：クラウドＸＩｏＴＸクラウドソーシング
　　デバイス to クラウド→APIが効率的

マルチベンダー連動標準インターフェースの実装

経営３資源のソリューション

・会社概要