IoT×Big Data×AI Meetup#1 に行ってきた

＜株式会社ABEJA＞

人工知能をもともとやってる。
WEGOとかアパレル。

店舗でカメラ、画像解析。
さくら、ソラコムとも協業。

上りのIoT
→貯めていく側
→センシング
→簡易化キット

下りのIoT
→活用側
→自動化や省力化
→照明の制御
→上りよりはメーカ少ない。

IoTと人工知能
→下りのIoTを使って人工知能は世界へのアウトプットを実施
→人工知能は仮説→検証→

置き方
→①物理的な設置、②電源の確保、③通信の確保

①
見た目の問題(オーナー側への配慮)
→デザインで工夫
→複数の選択肢
→既設のインフラ活用

許可の問題(建物の所有者、セキュリティ部署との連携)
物理的な問題

②
概ね必要な場所にコンセントはない(天井など)
→初期段階から説明し施工
→PoEを利用
→半導体の進化、電池も重点研究

③
実環境では無線は混みまくり
カメラなど高度な転送容量が大きい
Internetに出るための口を業務と共用できるのか
→Wi-Fiは使わない
→ABEJAがISPになって実施

③
エッジ処理による転送データ自体の減少
BAN(人間を通信路)

まとめ
→設置、電力、通信
→総合的に解決

はじめは技術者も現場出て解決。
アパレルは来店しても買わない。
→オペレーション改善につなげる。施策を提供しやすい。

コンビニは単価を上げていく。

DAIKIN
→エアコンの故障予知。故障原因の分析したい。

＜株式会社チカク＞
代表は元アップルのセールス部長
→淡路島の祖父母に孫の写真を届けたい
佐藤さん(研究)
下りのIoT

携帯ネットワークを使ったIoTのはじめ方
まごチャンネル
あなチャンネル

まごチャンネル
→動画データだが非同期なので低速回線でも大丈夫。

仮説検証(プロトタイプ)
量産試作

アリババだとめちゃ安い
→サービス悪い(当たり外れあり)
→日本代理店
→技適に気をつける
→アンテナも考慮(メーカに問合せ必要)

通信規格の進歩は常にチェック
→5G規格はいつ決まる?
→5Gモジュール販売はいつ?

セルラーIoTの今後

通信世代
→仕様決まった翌年モジュール販売が多い

来年からLTEのM2Mがアツイ
→日本では各キャリアでLTEカバーエリアが地方にもだいたい届いた。

LTE専用モジュール費用<3Gモジュール費用
→なので安くなる

通信モジュール産業
→チップセット屋、モジュール屋
→5G頃には聞いたことないメーカ出てくる

ソラコムが提供しているのは、SIMとネットワーク。

製品のライフサイクルは大切な観点
バージョンアップ

＜株式会社ウィンクル＞
武地さん

Gateboxの紹介
→生活をサポート
→ARとIoTの技術を融合

今のIoT
→自分でコントロール
将来
→自動でコントロール

Google Home
Amazon Echo
→凄いことやってる。
Jibo

理解＝上りのIoT(現在、過去の記憶)
ライフパートナー
応援＝下りのIoT(エアコンつける)
理解⇆応援

生活習慣の蓄積。

飽きない
→自分が好きなキャラ

ボット
→社内SNS

①ターゲットと利用シーンを絞る
欲しい情報を得て活用するために

②IoTにこだわる必要ない
大切なのはビジョン(夢)

③IoTに対しての独自の解釈を持つべき

JSUG勉強会 2016年その8 ～ 今から始めるSpring

<DI・AOPについて学んでみました>
株 ティーアイオー

1.DIについて
ソフトウェアパターン。

メリット
→結合度の低下によるコンポーネント化の促進
→単体テスト効率化

DIコンテナがオブジェクト生成し、インスタンスを利用するクラス変数に設定してくれる。
→newがなくなる
→だから?
→脳内アプリ

DI使わないApp構成
→密結合。new複数つかう。
DI使うApp構成
→疎結合。

メリット
→変更が容易
→テスト簡単(DBなくてもテストできる。実行クラスにモック)

実装チームに知識があれば、メリットを享受できそう。

2.AOPとは
アスペクト指向

本来すべきでないもの
→ログ出力、トランザクション処理などを一元管理できる
→あとから追記可能
※いつ、どの処理をトリガーにログ出力など

AOP使わない場合
→人によって書き方もマチマチ、同じ処理を複数クラスに記述。

AOPつかう場合
→どのタイミングでトランザクション開始・終了するかをApplicationContext.xmlに記述

可読性あがる。

<Springを何となく使ってる人が抑えるべきポイント>
資料わかりやすい。

業務個別のBean(Controllerなど)はアノテーション

DI使いところ
→すべてのクラスをBean管理する訳ではない。
→Controller、Service、DaoはBeanにしてDIで紐付け

AOP使いところ
→レイヤー間にAOPで共通処理を挟み込む
→業務的な処理しない。基本は。

トランザクション開始・終了の記述はSpringがやるのでコード不要?!

<悩めるJava初級者のための Springをドーンとやってみよう>

はじめてのプレゼンテーションデザイン

http://ppt.design4u.jp/

書籍あり
■第１部　コンセプト紹介　プレゼン資料のデザインとは
講師　Webマーケ

読み手の視点で伝わりやすいか
スライドの最後まで読まずに理解できること
基本は縦横比は変更しない、もしくは縮小して使う

昨今、話す前にビジュアルでお客さんは決めてしまう
→例）モノを購入する場合にもネットで基本情報を確認したうえで店頭に訪れる

デジタル・ネイティブの台頭
→目が肥えている

レイアウト【大事】
→文言の関係性をあらわす(近ければ関連が深い)

■第２部　プレゼンデザインの実践　明日から使える！プレゼンデザインTips

ジャンプ率
→見出しと本文のフォントサイズ差異
→大体1.5～2.0倍ぐらいの範囲で調節が妥当

光の三原色
→見た目にキツイ
→自然色にない(危険な色)

Adobe Color
→色の組み合わせ順で掲載

色材の三原色については、おすすめ
→マゼンダ：注釈
→イエロー：背景色、マーカー的な使い方、背景に青の場合には目立つ(色相環による反対色なので)
→シアン　：

余白をとる目安　版面率

版面率：低い　タブレット
版面率：高い　新聞

図版とテキストは対比で見せる
→両端揃え
→余白もすべて埋めることで他のスライドとのメリハリをつけることができる。

広告の3大目的
知る　→　理解する　→行動する

シチュエーションによって見せ方異なる

プロジェクタ
24pt以上

https://speakerdeck.com/

http://photoshopvip.net/

ＢＡＢＯＫ入門

ＢＡＢＯＫ入門

＜概要＞
BABOK（Business Analysis Body of Knowledge)は業務分析（ビジネスアナリシス）における知識や実施すべきことを
整理した知識体系です。BABOKは超上流工程（システム化計画、要件定義）の品質を高めるものとして注目されています。
本コースではBABOKの狙いと全体像、ビジネスアナリシスの位置づけ、各知識エリアのポイントについて学習します。

＜対象＞
超上流工程（システム化計画、要件定義）に携わる方

＜目標＞
BABOKの必要性と全体像を理解する
BABOKの７つの知識エリアを理解する
BABOKの活用ポイントを理解し、超上流工程の品質を高めるビジネス分析に活かすことができる

＜メモ＞
IIBAという組織がある。

ビジネスとシステムの橋渡しが求められている。
→何が問題なのかが大切であり、明確にする必要がある
→ステークホルダーが共通認識をもつことが大切
→これがお座なりになってしまい、システム内部の話で盛り上がっている
→システム=ソリューション


ビジネスアナリティクス
→タスクのテクニック
→ビジネスアナリスト

BABOKガイド冊子

ドメイン
→対象領域
ソリューション
→現状に加えた変更の集まり

ビジネス要求＜ステークホルダー要求＜ソリューション要求＜移行要求
→きちんと整合しているか

うまくいかない時にBABOKのノウハウを借りて活用する

統計学基礎

統計学入門メモ

＜概要＞
現状、企業や組織には業務における大量のデータを保有しています。
今までは管理しきれないため見過ごされてきたデータ群を記録・保管して即座に解析することで、
ビジネスや社会に有用な知見を得て、これまでにないような新たな仕組みやシステムを産み出す可能性が高まります。
本研修ではデータの活用の礎となる、統計学の手法を理解し、数値の捉え方をケーススタディから学習します。

＜対象＞
企業内データを分析する方法を学びたい方、上流工程で業務の分析、改善を行う方。

＜目標＞
ビジネスにおける統計学の重要性を理解する。
代表的な統計手法の種類を理解する。
代表的な統計手法をビジネスで活用できる。

＜メモ＞
【第１章】ビジネスにおける統計学の重要性
目的）
　規則性を発見し、将来を予測するため。

求められるスキル）
　１．どの手法を適用すればよいか？- 統計学の手段を選ぶこと
　　手段を選ぶスキルが必要。
　　数学は不要。深掘りすれば必要かもくらい。研究職の仕事。
　　ビジネスでは優先度低い。
　　
　２．正しく結果(事実)を読み解く
　　
　
分析の必要性）
　客観的で説得力のある説明が求められている。
　意思決定のための材料。
　→成功確率が求められている。
　
　例　受注データ ⇔ 年代の客層
　
　欧米のMBA必須科目は統計学

データ分析の手順）
　統計学は万能ではない。
　
　１．目的設定
　２．仮設づくり
　３．データ収集
　４，分析方法の決定
　５．分析実施
　６．結果解釈
　
　データ分析は仮説検証型
　目的設定-仮設づくり

　誤解　→　データ分析すれば何か出てくるのでは？？
　※狙いと仮説が必須

　目的　顧客減少の原因は何故か
　→仮説　商品満足度が落ち込んでいる？
　　→分析方法の決定　相関分析
　　　→分析実施
　　　　→結果解釈　結論を導く or 再度検証

ＳＷ）
　統計ソフトウェア
　→SASという製品(大規模向け)
　　特徴 CUI中心
　　→ある程度ITリテラシー必要
　
　→SPSS IBM社
　　中規模向け
　　
　→R言語
　　※注目されている
　　※OSS
　　大規模であるが手軽に使える
　　オラクルが採用。
　　→もともと学者が使っていたもの
　　　敷居高い。CUIなので。
　　　
　Excelで十分学べます。
　
【第２章】代表的な統計手法
記述統計学と推測統計学）
　記述統計学　→　多くの情報を集約・要約する
　　　　　　　　　１年間の受注実績データ
　　　　　　　　　ヒストグラム、標準偏差

　推測統計学　→　得られたデータから未知のデータを推測
　　　　　　　　　一部のデータから全体を語る
　　　　　　　　　視聴率(サンプルをもとに傾向をつかみ全体を語る)

なぜ２つ必要か？）
　両方共組み合わせて使う
　
　一般的な順番
　　１．記述統計
　　→２．推測統計

　まずは記述統計学を行い、使用するデータを絞っていく
　データの外観を捉えることが大切。
　
　１で特徴あるデータを捉え、２で深掘りしていく。


記述統計学）
　ヒストグラム
　→データを一定の範囲に分けて視覚化
　→可視化しないと出てこない発想
　
　代表値
　→平均値、中央値、最頻値
　→どのデータが妥当か検討
　
　分散と標準偏差
　→標準偏差：人間が見た時に見やすくしたもの
　　例　±3.8万円(標準偏差)
　
　基本統計量：統計学で基本的な指標となるもの
　　　　　　　(平均値、中央値、最頻値、分散、標準偏差)

　散布図
　　右肩上がり(正の相関関係)
　　外れ値を最初から無視するのではなく、内容を吟味したほうがよい
　　→イレギュラーデータが明確になることでビジネスチャンスがあるかも
　
　相関
　　相関係数：2変数の関係の強さを表す指標
　　→絶対値が１に近づくもの＝相関が強い(すなわちゼロは相関なし)
　　→一般的に0.7以上だと相関関係ありと言える
　　→擬似相関には注意(直接的な相関なし)
　
　
推測統計学）
　母集団と標本
　　母集団：語りたいこと(目的・ゴール)
　　標本　：手元のデータ
　
　　前提→基本的に正規分布に従う
　　　
　単回帰分析
　　単回帰式→予測式 y=ax+b
　　　説明変数　説明材料(例：最高気温)
　　　目的変数　求めたいもの(例：売上)
　
　　y(目的)=ax(説明)+b
　
　　手順あり
　
　重回帰分析
　　説明変数が２つ以上だと重回帰分析
　　y=a1x1+a2x2+a3x3+・・・
　　※考え方として、説明変数をなるべく小さくする
　　※説明変数が互いに相関関係があると誤った答えが導かれてしまう
　　　例：駅からの距離、駅から徒歩時間
　
　検定
　F検定
　t検定
　x2検定
　分散分析

第33回 PaaS勉強会(2016/8/2)

１．10 分でわかる Cloud Foundry Summit 2016 報告
Hiroaki UKAJI さん
約１００セッション

(私見)頻出キーワード
　１．Digital Transformation(DX)
　２．Multi Cloud
　３．Microservices

　１．Digital Transformation
　　クラウドネイティブな世界へ
　　
　　オーストラリア政府のサービス基盤をCFを使ってCI化
　　

　２．Multi Cloud
　　ハイブリッド・クラウド的な話

　３．Microservices
　　設計思想
　　

２．10 分で書ける Cloud Foundry Route Service
Hiroaki UKAJI さん

　Route Service
　→アプリへ到達する前に何か処理してくれる

　アプリ ⇔ サービス(MySQLサービスとか)
         ~~bindという

　当然性能は低下する。
　ほぼただのHTTPサーバ

３．帰ってきた鬼っ子　～ Stackato を知っているか～
jyoshise さん(HP Enterprise)

　HPとしてはパブリック・クラウドはやめたが、AWSとかとパートナー契約している。

　Cloud FoundryはPivotalでしょ。
　
　Stackato
　→Pivotal CFとの違い？
　　→CFベースのPaaS商用ディストリビュート

　コンセプト
　　情シスが持てるPaaS <= 管理機能を強化
　　事業部ITが持てるPaaS
　　あなたが持てるPaaS

　パブリックの上にプライベート環境を構築できる。

　特徴=>コンテナがDocker
　DEAをDockerで動かしてきた

　参考）
　https://visualstudiogallery.msdn.microsoft.com/4cad4d95-099c-449e-9d90-7d4da5c4a0c0

　開発環境でPaaS活用できると生産性あがるかも

　PC上で動くお手軽PaaSもある。

　将来的にはMesosにも対応

４．「 DC/OS (何？)」をさわってみた
nota-ja さん

　https://dcos.io/get-started

５．みんなだいすきマイクロサービスと lambda スタイル。
　 (fabric8 と funktion の紹介と解説)
tnaoto さん(富士通)

　富士通クラウドサービス(UKリージョン)
　http://jp.fujitsu.com/solutions/cloud/k5/

　fabric8
　→プラットフォーム。CI 継続的改善

６．Open PaaSの新潮流？ Deis Workflowの話
jacopen さん

　Deis
　→Kubernetes(クーバネイティス) Google開発

　Request Rooter
　→これが実際のAppを指定しているので同じIP、PortでもURL(リクエスト)をもとに
　　切り分けできる。PaaSだと普通。

　PaaSとは、、、アプリの開発・運用支援サービス

　OpenShift敷居高い
　→Kubernetes知らないと使いこなせない。

JJUGナイトセミナー(2016.7.11)～Java API訴訟問題を考える～ に行ってきた

2016/7/11@日本マイクロソフト本社

19:00-19:30「Oracleが訴えるまでの経緯について～SunとOSSとIBMとAndroid～」
鈴木雄介（JJUG会長）

■Javaのエコシステム
→2011年から個人で仕様策定に参画できるようになった。
→独自機能によってロックインしていた。(Weblogic独自機能など)
ベンダーのためのエコシステム
SUNは認定することで利益を得ていた。
各社は独自実装を販売して利益を得ていた。
どんどん肥大化していった。

■OSSのエコシステム
Apache Software Foundation
オープンソースを支援する任意団体
2002、2004年OSS(Struts等)を受け入れることでとても盛り上がった。
→IBM(WebSphere)がとても貢献していた。
→OSSビジネスの成功
→Linuxの成功体験がベース
→Eclipseは2001.11にOSS化
2004年TomcatがRI(参照実装、検証)
2006年JBoss旋風
JavaEEではOSSをベースに盛り上がった。
→SEでもできないか?

■JavaとOSS
2005.5 Project Harmonyが提案
Eclipseみたいなものを目指していた。
2006.10 Apache Harmony誕生
2006.11 SunがJ2SEをOSS化
OpenJDK
2007年、公開書簡
Harmony「この利用制限を外せ」
Sun「嫌だ」
2007.8 SunがTCKを公開
Sun⇔それ以外

■AndroidとJava
2005年ごろ GoogleのAndroid戦略
オープンソースによる共有資産
2007年以降、Android普及へ
→無料で手を入れられるOS
→もうSunにライセンス料払わなくていい

■その後
SunのOSS戦略は成功せず
2016年、AndroidがOpenJDK

■まとめ
IBMはOSS戦略成功、Sunは失敗した。
IBMすごい。したたか❔

19:30-20:10「Oracle vs Google訴訟の全貌と概要 ～APIは著作権で保護されるべきか～」
栗原潔（弁理士）

http://www.slideshare.net/KiyoshiKurihara/oracle-vs-google-63898283

■日本と米国の違い
日本→条文に書いてあるかどうかを重視
米国→裁判結果を重視(市場への貢献しているかどうか、という考え。フェアユース)
やってみないと分からないのが米国。
→裁判するお金ないと不利になる。1億円くらい必要。