クラウド／ビックデータの行方 - JEITA...Ichiro Satoh...
103
Transcript of クラウド／ビックデータの行方 - JEITA...Ichiro Satoh...
Ichiro Satoh
講演概要
1. クラウドコンピューティングとは
2. クラウド向けデータセンタ
3. クラウドにおけるサービス提供へ
4. ビッグデータ
5. まとめ
スライドは全部話せません
研究の話はしません
Ichiro Satoh
自己紹介：佐藤一郎
国立情報学研究所・ アーキテクチャ科学研究系・教授
国立大学法人総合研究大学院大学・ 複合科学研究科・情報学専攻・教授
実証実験（イトーヨーカドー）
国立科学博物館（上野）
実証実験（そごう横浜店）
宣伝：
大学院博士課程もあります
最寄り駅： 地下鉄
神保町
または竹橋
Ichiro Satoh
ユーザはサーバ群を意識することなく、従量制でサービスを利用
（スケールアウト性により）必要なときに必要なだけ計算リソースを利用
インターネット
膨大なサーバ群
クラウドコンピューティングインフラ クライアント
クラウドコンピューティングとは
クラウドコンピューティングの定義は雲のようにぼやけている
ベンダーやインフラ提供者が都合の良いように拡大解釈
Ichiro Satoh
クラウドコンピューティングの効用
クラウドコンピューティングにより可能になること
クラウドコンピューティング
ユーザ企業
サービス提供企業 必要なときに必要な
だけサービスを利用
自らサービス提供者になることも可能
サービス提供企業
サービス提供企業
サービスを組み合わせて利用できる
世界中からサービス
利用者を獲得
Ichiro Satoh
クラウドコンピューティングにおいてシステム開発は狭まる
クラウドとシステム開発
IaaS 仮想マシン
環境を提供
OS
Middleware
アプリケーション
PaaS 実行環境となる
プラットフォームを提供
OS
Middleware
アプリケーション
ハードウェア ハードウェア
SaaS 完成品の
ソフトウェアを提供
OS
Middleware
アプリケーション
ハードウェア
オンプレミス
システム
OS
Middleware
アプリケーション
ハードウェア
OS
Middleware
アプリケーション
ハードウェア OS
Middleware
アプリケーション
アプリケーション
カスタマイズ・サービス統合の
お手伝い
システム開発ビジネスが提供するもの
Ichiro Satoh
パブリッククラウド
所有から利用へ
クラウドインフラ上の仮想環境、プログラム実行環境、サービスを利用
低コスト
クラウドインフラは多数サーバを少人数・一括管理（1万５千台に管理者１人）
従量課金制
使った分を使っただけ利用料を支払う（固定費から変動費に）
スケールアウト性
必要なときに必要な計算リソースを利用可能
世界規模のコンピュータ
世界各所の巨大データセンターで
アプリ・データを多重化
自然災害や大規模停電に対応
2009年に写真・ビデオが公開されましたが
5年前のものだそうです
Ichiro Satoh
スケールアップよりスケールアウト
スケールアップ
少数の高性能コンピュータ
スケールアウト
多数の低性能コンピュータ
経験則：
1万台サーバのデータセンタは、1千台のデータセンタより、
規模当たりのコストは5〜7倍安い
Ichiro Satoh
パブリッククラウドの構成
数十万台のサーバから構成
計算リソースは事実上無限大
サーバ故障を前提にした運用
データ・アプリケーションの多重化
分散ストレージ
ストレージ
サーバ
ストレージ
サーバ
ストレージ
サーバ
ストレージ
サーバ
データの複製の複数サーバで保持
非同期データ複製・更新
ライブラリ ライブラリ
仮想マシン
アプリケーション アプリケーション
ライブラリ ライブラリ
仮想マシン
アプリケーション アプリケーション
インターネット
クライアント
Ichiro Satoh
分散ストレージ
複数データストレージにデータを多重・保持
データ更新がとっても遅い
マルチホップによるデータ参照（遅い）
非同期のデータ更新（一貫性が欠如）
キューベースのトランザクション処理
クライアントとインフラ間の通信遅延
クラウドコンピューティングでは
データ更新が多いアプリケーションは不向き
データ更新の一貫性は保証されない
リアルタイム処理には不向き
クラウドコンピューティングの向き・不向き
データ
ストレージ
データ
ストレージ
データ
ストレージ
ロードバランサー
データ
ストレージ
マルチホップによるデータ発見
非同期データ複製・更新
分散アプリケーションサーバ
ノード ノード ノード
インスタンス インスタンス
クラウドコンピューティングはデータ一貫性
よりも可用性やスケールアウトを優先
Ichiro Satoh
高信頼性よりも多重化
クラウドコンピューティングのシステム構成・運用
サーバ台数が増えると、故障も増える
一日辺りの故障率（Googleのデータセンター）：0.55%
サーバ数が多いので、一日に数千台が壊れている
高信頼性ハードウェアは高価
（低信頼な）コモディティハードウェアを数でカバー
故障を前提にしたシステム構成
データや処理を多重化して、部分的故障を隠蔽
サーバ管理の集約化・自動化、故障対応コスト削減
Ichiro Satoh
集中制御と自動化
Amazon、Google、Facebook、Microsoftのデータセンター
管理者一人で15000台以上サーバを管理
サーバ単位ではなく、サーバ群による管理
多重化により、サーバ群ごと交換
OpenFlow/Software Defined Network
(SDN)
ネットワーク機器を集中管理
Ichiro Satoh
サーバビジネス
Microsoft CEO Steve Ballmer曰く
「10年後に自社サーバを持つことはなくなる から、サーバ売りは止めた方がいい」
国内のサーバ構築ビジネスでは
クラウドよりもリースによるIT設備も資産計上（オンバランス化）が大きな要因
セキュリティ的な理由から自社運用に拘る
成長している顧客企業から自社サーバをクラウドに移行
クラウドのメリットはコストよりも柔軟かつ迅速な情報システム規模の変更
成長しないなら固定的な既存システムでも十分では
オンプレミスシステムしか扱えない管理者に仕事を作るという需要も
Ichiro Satoh
萎み続ける国内サーバ市場
国内サーバ市場の推移（出典：IDC Japan調査）
2011年が増加なのは、スパコン「京」が含まれているから
（「京」がなければ減少、スパコン一台で増減するぐらい小さい市場になっている） 市場の縮小よりも、市場が消滅する時期を心配すべき状況
Ichiro Satoh
システム保守・管理
クラウド時代ではオンプレミス情報システム構築の需要が減少
→ システム保守管理業務も減少
需要減よりも価格が下がる方が深刻
オンプレミスシステムの保守管理案件も、パブリッククラウドが提供する廉価な利用料金に引きずられて下がる
大手クラウド事業者は管理者一人で15000台サーバを管理
クラウドに限らず、海外データセンターの利用が拡大
国内においてハードウェアに近いシステム保守・管理の需要は減少
Ichiro Satoh
海外クラウドは安全か？
海外データセンターは、セキュリティの有資格者が設計・構築・運用
事故発生時の訴訟リスクを下げるため
無資格者が関わっていると損害賠償額が膨大になる（米国）
参考：国内データセンターは有資格者は少ない
無資格者が設計・施工・運用するビルに入居する状況
バックアップをとっていない事業者も多い
大手クラウド事業者はデータの複製を相違地域のデータセンターに保持
広域災害や大規模停電時にも
可用性を維持
パブリッククラウドはデータの
保存先地域（複数）を指定できる
Ichiro Satoh
サーバメーカの変遷
Intelのサーバ用プロセッサ
2008年: 75%はHP、デル、IBMの3社で75%程度
2011年: 61%はHP、デル、IBMの3社で75%程度
しかし、実状は：2012年:売上8社で75%程度とされる
Worldwide: Server Vendor Shipments
(from Gartner)
HP
Dell
IBM
Fujitsu
Cisco
Other Vendors
12,437,855,857米ドル 2,346,083台
IDCやGartnerの市場調査に表れないサーバベンダーが台頭
Ichiro Satoh
世界のサーバの20%は4社が所有
2009年3月6日 Financial Timesの記事から
「世界で販売されたサーバの20%は、Google、Microsoft、Yahoo、Amazonが購入している」
備考:2008年の日本のサーバ集荷数は553万台
Ichiro Satoh
クラウド事業者のメーカ化
（サーバメーカの中抜き） 2011年のGoogleの設備投資額は34億ドル
(その大半がデータセンターで運用するx86サーバ)
c.f., 富士通の2011年サーバ売上額が13億ドル
Googleは10年以上前からサーバーを独自に設計
メーカからサーバーを買わずに、チップを含む部品を購入、
生産依頼したOEM/ODMメーカに納めさせて、大量のサーバを生産
AmazonやFacebookも台湾・中国のODM各社に発注
発注先：Quanta、Wistron、SuperMicro、Wiwynn他
ODM先にはHPやDellの発注先も含まれる
IntelやAMDは、GoogleやFacebookなどに特製プロセッサの納入
Ichiro Satoh
Facebookの機材調達先の変異
Facebookの機材調達先の変異
（Facebook社資料より作成）
2008 2009 2010 2011
OEM Rackable
OEM Rackable, HP, Dell,
Penguin Systems
OEM HP, Dell
ODM/OEM Quanta, Wistron,
HP, Dell,
2012
ODM/OEM ODM Alliance
(Open Compute)結成
ハードウェア仕様を標準化
して他社と共有化 FacebookはGoogle、Microsoft、AmazonよりもODM調達に出遅れている
専門ベンダー製品と市販チップセットの性能差が小さくなり、クラウド事業者が設計・生産した方が、自社に最適化できるので調達コストが削減できる
Ichiro Satoh
ネットワーク機器のコモディティ化
サーバの中身はx86プロセッサとチップセット
どのサーバベンダからサーバを調達しても中身はほぼ同じ
ネットワーク機器もマーチャント（Merchant)シリコンの普及
Ciscoなどのネットワーク機器ベンダーもネットワーク機器向けの汎用チップセットを利用
機能的な差別化は困難（ユーザ自らで作っても性能は同じ）
市販ネットワーク機器は無駄な機能だらけ（AppleTalkは誰も使ってない）
ネットワーク処理のソフトウェア化
専用LSIから汎用プロセッサへ
数が出ないから、微細プロセスで専用LSIは作れない
OpenFlowなどのSoftware Defined Networksに移行
Ichiro Satoh
高性能ネットワークスイッチの状況
相違なベンダーの高性能ネットワークスイッチの性能が一致
同じ市販チップ（Merchant Silicon)を使っているから
かつてCiscoは自前ASICで性能的優位を築いたが
ネットワーク機器は数がでないので、ASICを作れない
市販チップを使えば誰でも高性能ネットワークスイッチが作れる
例：Broadcom製チップを利用
メーカ 製品名 ポート数 帯域 バッファ 価格
Cisco Nexus 3064 40Gbps×4+10Gbps×4
8
1.2Tbps 9MB 300万円〜
ARISTA 7050T064 40Gbps×4+10Gbps×4
8
1.2Tbps 9MB 300万円〜
Dell Force10 S4810 40Gbps×4+10Gbps×4
8
1.2Tbps 9MB 180万円〜
IBM BNT RackSwitch
G8264
40Gbps×4+10Gbps×4
8
1.2Tbps 9MB 380万円〜
Pica8 Pronto 3920 40Gbps×4+10Gbps×4
8
1.2Tbps 9MB 150万円〜
Ichiro Satoh
Broadcom製チップを利用する
ネットワークスイッチ
Ichiro Satoh
Ciscoの言い分、PICA8の言い分
Ichiro Satoh
汎用プロセッサによるネットワーク処理
ネットワーク機器は数が出ないから、微細プロセスで専用LSIは作れない
いずれは汎用プロセッサを使ったソフトウェア的ネットワーク処理が、専用プロセッサの性能を抜くはず
ネットワーク処理のソフトウェア化
OpenFlowなどのSoftware Defined Networksに移行
プログラムとしてネットワーク設定・運用
ネットワーク仮想化
ネットワークのソフトウェア化
c.f., サーバ仮想化
Ichiro Satoh
高性能ネットワークスイッチの今後
半導体からネットワークスイッチの今後
ネットワーク向けASICは微細化が進まない（＝性能が上がらない）
数が出る汎用プロセッサは微細化が進む（＝性能が上がる）
いずれはASICは汎用プロセッサ＋ソフトウェアに性能的に抜かれるのか
汎用プロセッサ＋ソフトウェアによるネットワークスイッチ
ネットワーク機器はますます誰でも作れる
例：GoogleやAmazonは10Gbpsスイッチを自作
例：Software Defined Network (SDN)
ネットワークを仮想化し、ソフトウェアレベルでカスタマイズ
例：ARISTA
クラウド・データセンター向けネットワークスイッチベンダー
ネットワーク機器ベンダーなのに、エンジニアの7割はソフトウェア担当
市販チップと（カスタマイズされていない）Linuxを利用
Google自作スイッチ
Build from merchant silicon
100s of ports of 10GE
OpenFlow support
Ichiro Satoh
! "#$"%#&
T&
( - ,@- ,&04/- ,4. I2&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& %T&
+55PI- &( - ,@- ,&
14
R. /. : - 4/- ,&S5V - ,&
S- . H&S5V - ,&u &
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#&
' 5734P&V3/; &S- ,c5,6 . 4: - &34&9, ,. B&
Local! Rack! Array!
DRAM Latency (microseconds)! 0.1! 100 ! 300 !
Disk Latency (microseconds)! 10,000 ! 11,000 ! 12,000 !
DRAM Bandwidth (MB/sec)! 20,000 ! 100 ! 10 !
Disk Bandwidth (MB/sec)! 200 ! 100 ! 10 !
DRAM Capacity (GB)! 16 ! 1,040 ! 31,200 !
Disk Capacity (GB)! 4,000 ! 320,000 ! 9,600,000 !
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& %b&
• #&6 3: ,57,5: - 225,2[&! &+G&RA9= [&d&%̂ G&132H2"2- ,@- ,&
• ! L&2- ,@- ,2",. : H&
• TL&,. : H2&"&. , ,. B&t ` &#dLL&2- ,@- ,2&"&. , ,. B&
N5V - ,&I. /- 4: B&/5&RA9= &34&. 45/; - ,&2- ,@- ,&/; . 4&I5: . I&132H&
C3P; - ,&X. 41V31/; &/5&I5: . I&132H&/; . 4&/5&RA9= &34&. 45/; - ,&2- ,@- ,&
' 5734P&V3/; &Q 5,HI5. 1&x. ,3. _54&
• f 4I34- &2- ,@3: - *&S- . H&82. P- &#z&5j M7- . H&! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& %) &
= 3143P; /& U554& = 3143P; /&
Q5,HI5.1&
#z&
06 7. : /&5c&N. /- 4: B[&G. 41V31/; [&K. 3I8,- [&x. ,B34P&Q 5,HI5. 1&54&Q ( ' &( 5l V . ,- m&
• Q ( ' &( 5l V . ,- &6 82/&/. H- &: . , - &V ; - , - &3/&7I. : - 2&1. /. &V3/; 34&. 4&. , , . B&/5&P- /&P551&7- ,c5,6 . 4: - &
• Q ( ' &( 5l V . ,- &6 82/&: 57- &V3/; &c. 3I8,- 2&P,. : - c8IIB&
• Q ( ' &( 5l V . ,- &6 82/&2: . I- &87&. 41&15V4&P,. : - c8IIB&34&,- 27542- &/5&@. ,B34P&1- 6 . 41&
• = 5,- &- I. X5,. /- &; 3- ,. , : ; B&5c&6 - 6 5,3- 2[&c. 3I8,- &/5I- , . 4: - [&V5,HI5. 1&. : : 56 6 51. _54&6 . H- 2&&Q ( ' &25l V . , - &1-@- I576 - 4/&6 5,- &: ; . II- 4P34P&/; . 4&25l V . ,- &c5,&234PI- &: 56 78/- ,&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& %$&
S5V - ,&@2D&( - ,@- ,&g _I3E. _54&
• ( - ,@- ,&75V - ,&82. P- &. 2&I5. 1&@. ,3- 2&31I- &/5&%LLu &• g 2- 2&{ &7- . H&75V - ,&V ; - 4&31I- Y&• g 2- 2&| &7- . H&75V - ,&V ; - 4&%Lu &8_I3E- 1Y&sLu a &bLu Y&• = 52/&2- ,@- ,2&34&Q ( ' &8_I3E- 1&%Lu &/5&bLu &• +5. I&2; 58I1&X- &=5$#; >?6#&/&#@&5",70>*&&u &7- . H&I5. 1&t&u &7- . H&- 4- ,PB&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& %! &
省エネ重視のデータセンター
冷却設備の徹底した省エネ化
熱いものは集めて冷やす
細かい温度管理で冷やしすぎは避ける
設置・置換の簡単化
コンテナに1000台程度のサーバを格納
! "#$"%#&
d&
S5V - ,&g 2. P- &vj - : _@- 4- 22&
• f @- ,. II&Q ( ' &v4- ,PB&vn : 3- 4: B*&. 6 584/&5c&: 56 78/. _54. I&V5,H&7- ,c5,6 - 1&13@31- 1&XB&/; - &/5/. I&- 4- ,PB&82- 1&34&/; - &7,5: - 22&
• S5V - ,&g 2. P- &vj - : _@- 4- 22&<Sg v>*&5̂/. I&X83I134P&75V - ,&"&0̂ &- Z8376 - 4/&75V - ,&
– 94&75V - ,&- n : 3- 4: B&6 - . 28,- &c5,&Q ( ' [&5&0)34: I8134P&- n : 3- 4: B&5c&2- ,@- ,2[&4- /V5,H34P&P- . ,&
– %DL&t&7- ,c- : _54&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& %s&
Sg v&34&/; - &Q 3I1&<#LL$>&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& #L&
C3P; &Sg v*&Q ; - ,- &R5- 2&S5V - ,&+5m&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& #%&
' 56 78/- ,&&A556 &&93,&&' 5413_54- ,&
' ; 3II- ,&: 55I2&V . ,6 &&V . /- ,&c,56 &93,&&
' 5413_54- ,&
g 434/- , ,87/. XI- &S5V - ,&( 877IB&&<X. F - ,B>&
( - ,@- ,2&h&&U- /V5,H34P&
S5V - ,&&R32/,3X8_54&
g 43/&
+55PI- &Q ( ' &9&Sg v*&%D#d&
%D ' . , - c8I&. 3,&r 5V&; . 41I34P&
• R54W/&6 3k&2- ,@- ,&; 5/&. 3,&- k; . 82/&V3/; &: 5I1&. 3,&<2- 7. ,. /- &V . ,6 &. 32I- &c,56 &: 5I1&. 32I- >&
• ( ; 5,/&7. /; &/5&: 55I34P&25&I3F I- &- 4- ,PB&27- 4/&6 5@34P&: 5I1&5,&; 5/&. 3,&I54P&132/. 4: - 2&
• ?- - 734P&2- ,@- ,2&34231- &: 54/. 34- ,2&; - I72&: 54/,5I&. 3,&r 5V&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& ##&
+55PI- &Q ( ' &9&Sg v*&%D#d&
#D vI- @. /- 1&: 5I1&. 32I- &/- 6 7- ,. /8,- 2&
• ! %}K&342/- . 1&5c&/,. 13_54. I&) b}M&) ! }K&
• K5841&,- I3. X3I3/B&f ?&3c&,84&2- ,@- ,2&; 5F - ,&
TD g 2- &5c&c,- - &: 55I34P&
• ' 55I&V . ,6 &V . /- ,&58/231- &XB&-@. 75,. _54&34&: 55I34P&/5V - ,2&
• N5: . /- &Q ( ' &34&6 51- ,. /- &: I36 . /- &25&45/&/55&; 5/&5,&/55&: 5I1&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& #T&
+55PI- &Q ( ' &9&Sg v*&%D#d&
dD S- ,M2- ,@- ,&%#Mx&R' &g S(&
• A. /; - ,&/; . 4&Q ( ' &V31- &g S( [&7I. : - &234PI- &X. F - ,B&7- ,&2- ,@- ,&X5. ,1&
• 04: ,- . 2- 2&Q ( ' &- n : 3- 4: B&c,56 &sLu &/5&ssu &
bD = - . 28,- &@2D&- 2_6 . /- &Sg v[&78XI32; &Sg v[&. 41&36 7,5@- &57- ,. _54&
! "#$"%#& K. II&#L%#&MM&N- : /8,- &O#& #d&
Ichiro Satoh
Open Compute Project
大型データセンター向きサーバやネットワーク機器を標準化することで、大量のサーバを安価に調達
Facebookが中心に推進
一部ネットワーク機器メーカや、台湾・中国のOEM/ODMメーカが参加
QuantaやWistron他
サーバ、ストレージ、ネットワーク機器の標準仕様を公開
オープンソースソフトウェアのハードウェア版
サーバやネットワーク機器は差別化要素ではない
Ichiro Satoh
データセンター(DC)のコモディティ化
先行クラウドインフラ事業者のアーキテクチャ
Datacenter as a Computer
一つのDCを一つのコンピュータとして扱う
クラウドインフラはDCというコンピュータの分散システム
データセンター間連携が技術的コア
DCのコモディティ化が急速に進んでいる
DCは他社との差別化要因ではない
Google、Amazon、Microsoftなどが
自前DCではなく、他社のDCを利用
することも想定すべき
2009年5月に発表
Ichiro Satoh
データセンター(DC)のコモディティ化
複製データを複数DCに配置し、性能及び信頼性向上
DCをコンピュータと見立てて、その分散システムとして構成
GoogleのMegastoreの
論文(CIDR’2010)から
データセンター間で
データ複製・アクセス
Ichiro Satoh
Google Spanner
分散システムの難しさは、（予測不可能な）通信遅延に起因する
コンピュータの時間情報はずれるし、厳密な時刻合わせは不可能
影響：相違なコンピュータにおけるデータの読み書きは順序づけ不可能
コンピュータ間で明示的に順序付け
（トランザクション）
Google Spannerでは、GPS信号による時刻合わせと原子時計を利用
コンピュータ間で高精度な時刻共有を実現
地球規模の分散システムで、データ読み書きの順序づけを簡単化
= ��=���
Ichiro Satoh
Amazon Glacier
低コストなストレージサービス
10TB／月：0.2ドル
データは 24 時間後まで
ダウンロード可能な状態
（一般的に3～5 時間）
実現方法は謎
推測：おそらく記録媒体はテープ、
そして倉庫用自律搬送ロボット
(Kiva Systems、Amazonが
買収)を利用か？
http://www.youtube.com/watch?v=Fr6Rco5A9SM
Ichiro Satoh
リーディング技術の変化
技術リーダはPCからスマートフォンに移行
スマートフォン向け技術をデータセンターに取り込む
トレンド：ARMプロセッサ搭載サーバ
クラウドコンピューティングの最大コストは電力
組込用プロセッサは消費電力あたりの計算量で有利
SoC化（＝カスタマイズ可能）
288サーバ（１トレイに72サーバ(4コアCortex-A9×４個)
HPによると従来サーバとくらべて、89％の省電力、94％のスペース削減
HP Moonshot
Ichiro Satoh
Ichiro Satoh
物理技術の利用動向
InfiniBandなどの高速ネットワークによるサーバ間接続
ローカルストレージ(HDD)より、他のサーバへのアクセスが高速となることも
SSDの積極利用（=HDDの置き換え）
ストレージアクセス速度を高速化と低消費電力化
主記憶の不揮発性メモリ化を想定した動き
インメモリデータベース
不揮発性メモリによりデータの永続化処理を省ける(DBMSが大幅簡単化）
ノーマリーオフコンピューティング
レジスタ、ALU
キャッシュ
主記憶(DRAM)
二次記憶(SSD)
二次記憶(HDD）
磁気テープ
レジスタ、ALU
キャッシュ
主記憶（不揮発性化）
二次記憶(SSD)
磁気テープ
Ichiro Satoh
質問 世界の年間所得
年収300万円以上の人は世界で何パーセント？
年収600万円以上の人は世界で何パーセント？
これは何の比率？
国名 率 人口(2010年推計）
ネパール 72.5% 29,959,364
アフガニスタン 68.5% 31,411,743
エチオピア 64.5% 82,949,541
パキスタン 62.2% 173,593,383
バングラディシュ 61.9% 148,692,131
… … …
インド 48% 1,224,514,327
… … …
中国 18.5% 1,341,335,152
… … …
Ichiro Satoh
ポストPC
ポストPCの要件は、PCより大きな市場をもつこと
PCは先進国の消費者という市場をもった
残る巨大市場は発展途上国市場だけ
発展途上国のユーザの可処分所得は低い
年収1000ドル以下の人にPCは高すぎる
格安PCの登場
Raspberry PI
25ドルPCボード
Ichiro Satoh
BOPビジネスへの展開
先進国のIT市場はすでに飽和（売上が増えるとは限らない）
既存情報システムと比較するとクラウド上サービスは利便性が低下
既存情報システムが整備されていない国では深刻ではない
例：BOPビジネス (Base of (economic) Pyramid)
BOP市場
貧困層は製品やサービスの「潜在的市場」
全世界で、5兆ドル規模
（世界資源研究所(WRI)調査, 2007）
Ichiro Satoh
クラウドによる端末の高機能化
例：Siri (Apple)音声入力サービス
音声識別を
クラウド側に委譲
Action Input
Elicitation
Domain
Model
Vocabulary
Language
Pattern
Recognizers
Domain
Entity
Database
Language
Interpreter
Short Term
Personal
Memory
Active
Ontology
Task Flow
Models
Dialog Flow
Model
Service Models
Output
Processor
Dialog Flow
Processor
Service
Orchestration
Long Term
Personal
Memory
音声
圧縮
データ
音声
圧縮
データ
Apple Siri Service Cloud
Ichiro Satoh
クラウドによる端末の高機能化
入力した音声データを圧縮・転送、受信した音声データを解凍・再生できれば、どんなデバイスも音声入出力を完備できるはず
Siri対応
エレベータ？
Siri対応
洗濯機？
Siri対応
冷蔵庫？
Action Input
Elicitation
Domain
Model
Vocabulary
Language
Pattern
Recognizers
Domain
Entity
Database
Language
Interpreter
Short Term
Personal
Memory
Active
Ontology
Task Flow
Models
Dialog Flow
Model
Service Models
Output
Processor
Dialog Flow
Processor
Service
Orchestration
Long Term
Personal
Memory
音声
圧縮
データ
Apple Siri Service Cloud
Ichiro Satoh
クラウドで求められるサービス
これまで新しいコンピュータは新しいアプリケーションを生んだきた
例：メインフレームとミニコン、ＰＣではアプリが相違
例：メインフレームは昔も今も同じ目的で使われている
クラウドコンピューティングは新しい（癖が強い）コンピュータ
既存コンピュータのアプリケーション以外のアプリケーションに使うべき
メインフレーム
（金融勘定系） ミニコン
（企業内業務処理）
パソコン
（事務） サーバ
（Webサーバ他）
Ichiro Satoh
クラウドコンピューティングは
インフラからアプリケーションへ
日経ビジネスのエリック・シュミット（Eric Schmidt）氏の
インタービュー記事（2009年10月）
「今は（クラウド時代の到来に備えて） データセンターを構築する時期だ。 それが済んだら、アプリケーション の開発競争が激しくなる。最終的には アプリが収益を生み出すのだから。」
Ichiro Satoh
クラウド時代のシステム開発
開発・統合
ユーザ企業
納品
システム開発業者
サービス提供
ユーザ企業
提供
システム開発業者
開発
サービス
ユーザ
フィードバック 要求分析・仕様
要求・仕様 これまで
（既存の
情報システム）
これから
（クラウド時代）
ソフトウェア
ベンダー
ハードウェア
ベンダー
ソフトウェア
ハードウェア
ソフト
ハード
ソフトウェア
クラウド
インフラ
事業者
計算リソース
ソフト 運用 サービス
システム
ソフト
ハード
Ichiro Satoh
ソフトウェアビジネスの変化
ソフトウェアのサービス化
ユーザ企業：ソフトウェアは買うものではなく使うものに変化
開発企業：ソフトウェアは作りながら動かすものに変化
納品物はソフトウェアではなく、サービス（とその改良）
代価は購入費ではなく、利用料金
莫大な開発量に支えられた人月ビジネスは成立しない
受注開発よりもカスタマイズ
長時間かけて要件定義・仕様凍結よりも、まずは使ってもらう
フルオーダー（オーダメイド）からセミ—オーダー（イージーオーダー）
ユーザ企業の内製化が増える
相違なサービスの統合（マッシュアップ）
ものを生産する消費者の出現（プロシューマーがライバルになる）
Ichiro Satoh
クラウド時代のソフトウェアビジネス
サービスに納品という概念はない
サービスを提供しながら、ユーザニーズを見極めながら日々改良
開発 ユーザ企業
システム／ソフトウェア
納品
SI/ソフトウェアベンダー
運用 ユーザ企業
提供
SI/ソフトウェアベンダー
開発
サービス
ニーズ吸い上げ 要求分析
・仕様
ソフトウェア
仕様 これまで
（既存の情報システム）
これから
（クラウド時代）
Ichiro Satoh
クラウド時代のソフトウェア開発
従来ビジネスモデル
ソフトウェアというものを売る
作ることで対価を得る
プル型ビジネス
大規模化＝売上げ増
多人数による短期間大規模開発
クラウド時代ビジネスモデル
ソフトウェアを使うことを売る
使ってもらうことで対価を得る
プッシュ型ビジネス
ユーザ数増加＝売上げ増
少人数による長期運用・改良
大人数短期開発
ユーザ企業
システム／ソフトウェア
納品
SI事業者・ソフトウェアベンダー
運用
対価
金
提供
サービス
少人数長期開発
ユーザ企業
SI事業者・ソフトウェアベンダー
対価
金
運用
ユーザ企業
ユーザ企業
Ichiro Satoh
サービス開発と運用の一体化
クラウドコンピューティング上のサービスビジネス
サービスを提供しながら、ニーズを吸上げて日々改良の繰り返し
運用 ユーザ企業
SI事業者
開発
サービス提供
ニーズの吸い上げ 要求分析・仕様
ソフトウェア
サービス提供
ニーズの吸い上げ 要求分析・仕様
ソフトウェア
時間 時間 時間
Ichiro Satoh
企画・ 仕様
実装 サポート
クラウドサービス開発は国内向き？
パッケージソフトウェアの開発は多数の開発者を集めて短期に開発・リリース
国内の雇用形態に合わなかった
クラウドサービスの開発は長期にわたる継続的な運用・改良
開発者を長期に雇用する方がよい
世界共通サービスは少ない
サービスはユーザの文化、民族、生活様式に依存傾向
ただし、二次以降の下請け開発会社には厳しいかも
ユーザニーズを拾える能力が重要
企画・ 仕様
実装 サポート
人員数
時間 ソフトウェア開発における人員の変動
企画・ 初期実装
提供・改良
人員数
時間 サービス開発における人員の変動
Ichiro Satoh
クラウドサービスの開発
ユーザからの要求・仕様はない
パッケージソフトウェアのように市場調査と製品企画
市場投入時期は早いほど有利
はじめは基本機能だけを提供して、それ以外は追加で対応
カスタマイズ
サービスの種類を最小化しつつ、ユーザ要求はカスタマイズで対応
日々改良・拡張（持続的開発）
ユーザニーズの拾い出しとそれに基づく改良・拡張の繰り返し
最終仕様は誰も知らない
サービス提供インフラは必要なときに必要なだけ利用
Ichiro Satoh
受注開発からサービス提供へ
クラウドでは納品物はソフトウェアではなくサービス
開発量は意味をなさない
コード量・質ではなく、サービスの質がすべて
ソフトウェアのステップ数や行数、人月計算は無意味
従量課金や期間課金に対応したビジネスモデル
一括払いのソフトウェア代金（＋年間のメンテナンス料金）から、
月ごとのサブスクリプション料金または従量課金
システム規模よりもユーザ数を重視
長期間にわたる運用・改良
ニーズを拾う
サービスに仕様書があるとは限らない（二次以上の下請けは厳しい）
利用状況を見ながらサービス内容変更・拡張
Ichiro Satoh
受注開発
受注開発ではソフトウェアは案件ごとに個別開発（現実はいろいろですが・・）
開発企業
ユーザ企業A
ユーザ企業B
実装したソフトウェア
実装したソフトウェア
要求・仕様
要求・仕様 開発・統合
Ichiro Satoh
クラウドサービスと受注開発
クラウドにおける経済モデル
サービスの種類が多くなると運用コストも増える
少ないサービス種別で多数のユーザをサポートする方がいい
ユーザ企業A
ユーザ企業B
開発企業
開発・統合
サービス提供
サービス提供
要求・仕様
要求・仕様
サービス提供
サービスの種別が増えると
運用コストも増える
Ichiro Satoh
サービスカスタマイズ
一つのサービスで複数のユーザの要求を満足
カスタマイズの手間がユーザロックインにつながる
他社製サービスを含めてユーザ企業のカスタマイズ支援はビジネスチャンス
ユーザ企業A
ユーザ企業B
開発企業
開発・統合
サービス提供
サービス提供
要求
サービス提供
カスタマイズ
カスタマイズ 要求
カスタマイズできるといってもユーザ要求に100%
合わせられるわけではない
Ichiro Satoh
サービス統合
ユーザ企業は複数サービスを選択・統合（マッシュアップ）して利用
ユーザ企業によるマッシュアップによる企業システム開発
マッシュアップの代行はSIビジネスの活躍の場
サービス提供
開発
企業 開発
サービス提供
ユーザ
フィードバック
要求分析・仕様
ソフトウェア ソフト 運用
サービス
統合
ユーザ企業
サービス提供
開発
企業 開発
要求分析・仕様
ソフトウェア ソフト 運用
サービス提供
ユーザ
フィードバック
Ichiro Satoh
規模の経済
クラウドコンピューティングは規模の経済
クラウドインフラ事業者は規模を大きくすることで、インフラの調達・運用コストを下げている
サービス提供者も規模の経済の恩恵を享受
ユーザ数が多いほど収益が増えてる
パブリッククラウドによりサービス提供環境は安価
ユーザ数が多くなければ採算性は難しい（例：広告収入モデル）
個人や中小開発会社のサービスが百万人単位のユーザを持つ可能性がある
利益率80％を超える企業も出現するかも
Ichiro Satoh
Salesforceにみるクラウドビジネス
SaaS型クラウドの成功者Salesforce.comのビジネスモデル
ユーザが要求や仕様が作れない分野を狙う
例：Salesforce CRM
仕様を作ろうと思ったら、企業内の営業全員の要求を聞く必要
があり、現実的に不可能 → Salesforceの既製サービスを使う
例：Salesforce Chatter
新しい分野のサービスであり、独自の要求をもっているユーザ
企業はすくない → Salesforceの既製サービスを使う
例：エコポイントの管理サービス（実質3週間で開発）
短期開発案件はユーザ企業は要求や仕様がまとめられない
→ Salesforceの開発したサービスを使うしかない
ユーザ囲い込みにはカスタマイズには適度な手間が必要
カスタマイズに手間がかかると、ユーザ企業は類似サービスへの移行を躊躇する
Ichiro Satoh
TKC全国会にみるクラウドビジネス
おそらく日本で一番成功している
ASP/SaaSはTKC全国会では？
TKCが提供しているビジネス
はASPそのもの、しかし
ユーザには税理士を見せて、
システムを極力見せない
ユーザは税理士に
頼んでいるという感覚
TKC全国会のやり方を学んで欲しい
クラウドが提供するのはソフトウェアではなくサービス
サービスの界面はシステムである必要はない
システムより人間を前面にたった方がいい場合もある
システムの中で人間が処理していてもいい
Ichiro Satoh
ユーザ企業によるサービス開発・提供
サービスの改良はサービス利用者に近い方がいい
クラウド時代はユーザ企業のサービス内製化比率が上がるだろう
サービスを提供・利用しながらの改良
サービス提供の運用管理はクラウドインフラに任せればよい
クラウド時代は開発企業とユーザ企業の差異は小さくなる
ユーザ企業への人材流動がおきる
自社専用だけでなく、他社への提供も考慮したサービス開発
Ichiro Satoh
ユーザ企業によるサービス提供
クラウドコンピューティング上のサービスは外部に提供可能（例：同業者他社）
スケールアウト性によりサービス提供用の計算リソースは増やせる
ユーザ企業によるクラウド上のサービスが他社にも提供
ユーザ企業は他社への提供を前提とした自社サービス開発を
クラウドコンピューティング
企業A
企業B
（サービス
利用者） サービス
開発依頼
サービス提供
サービス提供 開発会社
サービス提供 企業C
（サービス
利用者）
サービス配置
サービス依頼側企業はサービス利用側企業から利用料収入
サービス利者側企業はサービス開発が不要になる（コスト削減）
Ichiro Satoh
ユーザ企業によるサービス提供
ユーザ企業のサービス提供者化
ユーザ企業は他社への提供を前提とした自社サービス開発を
サービス依頼側企業はサービス利用側企業から利用料収入
サービス利用側企業はサービス開発が不要になる（コスト削減）
クラウドコンピューティング
企業A
企業B
（サービス
利用側、
企業Aの系列） サービス
開発依頼
サービス提供
サービス提供 開発会社
サービス提供 企業C
（サービス
利用側）
サービス配置
サービス利用料
Ichiro Satoh
クラウドコンピューティングがもたらす企業関係
クラウド時代はサービスの提供・利用関係が企業関係に影響
サービス提供側とサービス利用者側の関係
前者は後者の業務内容を監視できてしまう？
後者は前者（のサービス）に依存してしまう？
クラウドコンピューティング
企業A
サービス定義・配置
サービス提供
サービス提供
サービス提供
サービス提供
ログデータ
（他の企業分を含む）
企業B
企業C
企業D
Ichiro Satoh
クラウドコンピューティングがもたらす企業関係
問題なのは地位関係を前提にサービスの利用を求められた場合
例：元請け企業が下請け企業に受注管理サービスの利用を求める
例：銀行が融資先企業に財務管理サービスの利用を求める
将来、何らかの法的な措置が必要となるだろう
クラウドコンピューティング
銀行 サービス定義・配置
サービス提供
サービス提供
サービス提供
ログデータ
（融資先企業分を含む）
融資先企業A
融資先企業B
融資先企業C
クラウドコンピューティング
系列
元請け サービス定義・配置
サービス提供
サービス提供
サービス提供
ログデータ
（他の企業分を含む）
下請け企業A
下請け企業B
下請け企業C
Ichiro Satoh
国家とクラウドコンピューティング
サービス提供インフラとしての電子行政クラウド
（パブリック）クラウドの大規模サーバ群、スケールアウト性
全国民や全法人に対するサービス提供も不可能とはいえない
例：国内全法人に対する税務申告サービス
他国向けに電子行政サービスを提供できるのか？
他国に電子行政サービスを提供するぐらいの覚悟必要
電子行政サービスの提供は新しい国家間関係を構築する
例：ミニ国家ならば隣国の行政サービスを借りた方がいい
Ichiro Satoh
ビッグデータの時代
Facebookのアーキテクト
「競争力の源泉はデータ。だからインフラ技術は（オープンソースソフトウェアとして）共有する」
Twitterも同じ考え方だそうで・・・
ビッグデータを活かす企業では、インフラやソフトウェア技術は差別化要素ではない
Ichiro Satoh
ビッグデータとクラウド
ビッグデータでは情報システムへの要件が定まらない
処理量はデータや関心事に依存
ビッグデータは軌道に乗るとデータ量は（指数的に）増える
分析結果もデータとなる
処理能力が増減できるシステムが必須
ビッグデータは仮説検証の繰り返し
仮説は正しいとは限らない（多くの仮説は間違っている）
ビッグデータのために自前システムを持つべきではない
Ichiro Satoh
ビッグデータとは
教科書的定義では
既存システムで手にあまるデータ量や種類ならばビッグデータ
ビッグデータ技術とはそのビッグをとる技術
ビッグ データ
大量・多様 データ処理
高度な データ解析
高速データ 処理・解析
大容量かつ多様な
データを収集・処理
高度な解析手法により、データから特徴やパターンを抽出
実世界の様々なデータを既知の特徴やパターンと照合
MapReduce/Hadoop
NoSQL
Key-Value-Store
非定型データ処理
Complex Event Processing
オンメモリデータ処理
データマイニング
機械学習
Ichiro Satoh
世界最古のビッグデータ事例
世界最初のビッグデータ事例は、アメリカの国勢調査
1880年国勢調査では集計に7年
1890年国勢調査は移民増により、集計に13年
かかると予想
Herman Hollerithがパンチングマシーンを発明(1890)
米国政府は同マシンを採用して、1年間で集計完了
ビッグデータの歴史はコンピュータよりも長い
Hollerithが設立した会社 Tabulating Machine
Company はその後、 IBMの母体となる (1924)
コンピュータの歴史＝ビッグデータの歴史
集計高速化技術を公募
Ichiro Satoh
精度の低いデータも集まれば価値に
精度の低いデータでも、大量に集めれば精度があがる
各種センサーや端末から生まれる大量データやログデータを価値に
例：震災地域の交通情報(ITS Japan他)
ホンダ、パイオニア、トヨタ、日産のカーナビ情報を収集
通行実績をもとに
通行止め情報を集約
台風12情報時には、
情報提供企業が減少
Ichiro Satoh
既存BIやデータ分析との違い
ビッグデータでは、データを選ぶ、組合せが重要
コース料理からビュッフェ形式へ
分析精度
分析対象のデータが増えることで、分析精度が向上
正確さが低いデータでも大量に集まれば価値につながる
コース形式
（既存データ分析）： 与えられた少量の
料理（データ）を
最大限に楽しむ
ビュッフェ形式
（ビッグデータ）： 多様な料理（データ） から選ぶ（摘み食い）
Ichiro Satoh
コトラーマーケティング３．０
ビジネス環境の変化
景気後退、環境意識、ＳＮＳ、
消費者の影響力増大、グロバール化
消費者は、企業よりも他の消費者を信頼
個々の消費者行動の分析が必須
マーケティング 1.0 マーケティング 1.0 マーケティング 3.0
製品中心のマーケティング
消費者指向のマーケティング
価値・社会指向のマーケティング
目的 製品を販売すること 消費者を満足させ、つなぎ止めること
世界をよりよい場所に
マーケティング 製品開発 差別化 価値
製品管理 大量生産、低価格化 4P (製品、価格、流通、プロモーション）
協創
顧客管理 STP(セグメンテーション、ターゲティング、ポジションニング)
STP(セグメンテーション、ターゲティング、ポジションニング)
コミュニティ化
マーケティングの大御所（P.コトラー）ですら既存手法を否定
Ichiro Satoh
ビッグデータによる商品推奨
Amazonの商品レコメンデーション
他ユーザの購入履歴から
推奨商品を提示
（協調フィルタリング）
5 5 2 2
1 2 4 5
4 5 1 1
5 2 4 1
3 2 3 2
近い:0.98
遠い:0.64
ユーザごとの商品を買う頻度
多数
ユーザ
N
多数商品M
M×Nの巨大データ
→ 既存RDBMSでは対処できるとは限らない
Ichiro Satoh
ディメンションデータからファクトデータへ
従来手法：ディメンションデータの解析
例：店舗別や商品別、月別の売上げ
コンビニチェーン
約3000アイテムとすると、月間商品別売上データ数も3000
店舗数が2000店とすると、月間店舗別売上データ数も2000
ビッグデータ；ファクトデータの収集・解析
個々の販売データ（購入額、品目、数量他）
コンビニチェーン
月別情報（１店舗で一日1000人） 2000店×1000人×5個の商品名×31日=62000000×5個の商品名
販売から利用の把握・分析
ビッグデータはビジネス軸をPoint Of SalesからPoint Of Useに変える
Ichiro Satoh
POSからPOU (Point Of Use)へ
車体よりもLiイオンバッテリの方が長持ち
廃車後もバッテリだけリユース、またはバッテリだけリース
バッテリのリユースに備えたライフサイクルマネージメント
EVから定期的にバッテリ状況や位置などをデータセンターに通信
例：1分おきに送信、充電ステーションの情報を受信（日産Leaf)
商品のPoint Of Use管理(c.f. Point Of Sales)
利用状況がわかれば資産価値の評価精度があがる
Ichiro Satoh
収益拡大よりも損失縮小
収益拡大手法として
他のユーザ行動から、商品を推奨
Amazonなどの推薦機能
ユーザ行動を先回りして商品を提示
損失縮小手法として
不正利用監視
クレジットカードユーザの行動パターンを抽出して、不正を発見
医療データから患者の状態、病気の前兆を発見
短期的には損失縮小の方が確実＆効果的
儲けにつながるデータ特性は未知、損につながるデータ特性は既知
データ分析結果が興味深くても
収益拡大につながるとは限らない
Ichiro Satoh
応用事例：ネットゲームのユーザサポート
退会しそうなユーザを発見
退会ユーザには事前に典型的な行動パターンをとる
例：アクセスが減る、他のユーザとの通信が減る
退会しそうなユーザに特典付与、新規ゲームを提案
ユーザAの履歴
ユーザBの履歴
ユーザCの履歴
ユーザA
ユーザB
ユーザC
パターン
マッチング
退会パターンの発見
退会ユーザの典型パターン
ビッグデータの主要応用先は収益拡大よりも損出削減
Ichiro Satoh
応用事例：解約者分析
T-Mobile： ビッグデータを活用した解約者(Churn)の分析
顧客の通話、メール、コンテンツ利用などに関わるログ情報分析
顧客の動向や多様なニーズを把握することで、解約防止策を展開
従来の予測
解約の主要因は、電波が届かない場所にいるなど
基地局の不備によるものが大きい
ビッグデータの予測
解約の主要因は、家族や友人とのつながりが解約に
大きな影響を与えている
$1Mの投資で、
$70Mの効果（損出縮小）
Ichiro Satoh
顧客の損出縮小
顧客行動を分析して、顧客の損出縮小
例：リース会社
ビッグデータにより顧客のリース品の使用状況を把握・予測
過剰な場合はリースの打ち切りを顧客に推奨
例：事務機器メーカ
利用状況からメンテナンス部品の事前準備（在庫・配送）
利用状況によるシステム更新
壊れる前に機器または部品更新
夜間利用が多ければ壊れにくい機器
事務機器の集約（→自社の収益縮小）
顧客の損出縮小 → 自社の収益縮小、しかし収益安定化
これに相当するビッグデータ事例はまだない
Ichiro Satoh
国内でビッグデータを一番活かした案件
いちおうビッグデータ
事例になっていますが、
関係者に伺ったところ
以前から気づいていた
製品変更にはデータ的
裏付けが必要
ビッグデータ案件として
メディアで取り上げられた
話題性が高まる
Ichiro Satoh
ビッグデータ技術をスモールデータに応用
ビッグデータ技術はスモールデータでも有用
処理能力アップ
処理能力的な制約から、あきらめていたデータを捨てない
小売業の多くは13ヶ月分しかデータを持っていない
データ処理の高速化
バッチ処理のリアルタイム化（処理時間は一晩から10分)
データ処理の詳細化と相違なデータの組合せ
例：売上データの多面的解析、売上データと顧客DBの統合解析
ビッグデータ向け分散処理技術（MapReduce/Hadoop）
特定の処理に特化することで、分散処理を容易化
伸縮可能な情報システム（必要なときに必要なサーバ数を利用）
Ichiro Satoh
Hadoop
Googleが開発したMapReduce処理を実現する分散処理フレームワーク
Yahoo!が開発、その後はOSSコミュニティ(Apache)に移譲
MapReudceの処理
大量データを分割して、同一処理を複数サーバで実行し、結果を統合
分散システムの難しい部分（故障対策、配置）を大幅に簡単化
データ分割
分散処理
分散処理
分散処理
データ統合
大量データ 結果
MapReduce/Hadoop
Ichiro Satoh
Hadoop/MapReduceの事例
インドの文盲率は48% （インドの人口は１２億人）
字が読めなければメールやWebへの需要はない
音声によるメールやWebの読み上げサービス
大規模自然言語処理と音声合成技術を駆使
インドでは加入数が1億人を超える携帯電話事業者が3社
例：日本や米国には加入数が1億人を超える携帯電話事業者はゼロ
ユーザの利用状況の算出処理はビッグデータそのもの
Hadoop/MapReduceを利用して集計
Ichiro Satoh
仮説検証
ビッグデータはビジネスチャンスは見つけてくれない
人間が気が付かなかった特性を見つけてくれることは期待しない
機械学習など高度な分析手法は閉じた系では有効かもしれないけど
仮説検証
関心事によって分析手法は違う
何らかの特性を予測して、その特性があることのデータから調べる
分析してみないと仮説が正しいかはわからない
外すかもしれない仮説のためにシステム構築は難しい
データの収集
データを調べる
仮説の構築
仮説の検証
データの収集
データを調べる
仮説の構築
仮説の検証
データの収集
データを調べる
仮説の構築
仮説の検証
Ichiro Satoh
何を分析するのか
データ分析以前に、区別する対象を決める必要がある
区別しなくても対象までも区別 → データ量は爆発
区別すべき対象を区別できない → 必要なデータ分析はできない
コンピュータは現実世界をそのまま認識できない
現実世界の対象にID（付番）で区別
データ分析ではID設計が肝
例：JANコードは通常品と増量品を区別
できるとは限らない
宣伝： 佐藤一郎著「IDの秘密」（丸善出版、2012年） おそらく唯一のID付けに関する書籍
（業務執筆なので印税ははいりません）
Ichiro Satoh
単一種類データからはわからない
自宅の電力監視
Googleの推奨電力監視セットを入手、勝手に配電盤に取り付け
電力消費データだけで、ユーザ行動推測は難しいのでは？
本人ですら電力消費と利用家電の相関が難しい
粗いユーザ行動推定、例えば家に人がいるか、ぐらい
結局、Googleも撤退した
TED 5000 (Energy Inc.)
スマートメータの応用を語る人で、
自ら試している人
Ichiro Satoh
精度の低いデータも集まれば価値に…
たくさんの自動車から運行情報(位置・速度)を集めれば、
詳細な道路渋滞予測はできるか
詳細データは局所的な短期イベント（安売り店や地域行事、路上駐車）を反映
短期イベントの影響が予測を狂わせる
現実世界は局所的変動が大きい
イベント情報を集めて補正するか、大まかな分析にとどめるか
実際にはサンプリング数を抑えた方が精度が上がることもある
Ichiro Satoh
データの量と質
ユーザ行動解析には、相応データ量が必要（＝コストも掛かる）
例：イオンのWAON、セブン＆アイのNanacoカード
発行手数料300円では採算に疑問（さらにポイント付与）
データを集めるのはコストがかかる
発行側のメリット
顧客囲い込み
顧客行動の把握(最新購買日、購買頻度、購買金額）
おそらく300万枚程度を発行しないと解析は難しい
NanacoはWAONよりユーザ行動分析精度が高い？
Nanacoは発行時に氏名・年齢・住所などを登録（WAONは無記名）
Nanacoはコンビニ向け → 顧客層が広い → 分析が難しい
正確な登録情報は少ないといわれる
Ichiro Satoh
プライバシー問題
個人データ保持は経営リスク
必要以上に情報を持たない
ビッグデータの考え方は矛盾
情報を持たなければ、情報漏洩は起きない
データを廃棄する手順・規定の整備が必須
Ichiro Satoh
プライバシー問題
個別データでは見えないユーザ行動が、相違なデータの組合わせで見えてくる
実例：水道メータとガスメータの遠隔共同検針（2002年）
某自治体水道局と某ガス会社
PHS回線及び電灯線を利用した遠隔検針
実証実験（戸建住宅：100軒、集合住宅:60軒）
しかし、プライバシー問題の危惧から実証実験開始直後に中止
水道とガスが同時利用がわかると
お風呂の準備をしていることがわかる
いままで見えなかったことがみえることはプライバシー問題につながりやすい
Ichiro Satoh
マルチステークホルダー問題
ビッグデータにはステークホルダーがいっぱい
データの対象、センサー所有者、分析者、分析結果の利用者他多数
技術で解決できる部分とできない部分
ビッグデータビジネスコンソーシアム（経産省）で設立
例：米国保険会社Progressive
保険会社が自動車取り付けようデバイスを契約者に無償提供
運転頻度、速度、走行距離、運転時間帯等のデータを収集
保険会社に携帯電話回線を通じて送信
運転者のドライブ履歴を分析して、そのリスクを算定し、保険料率反映
運転者を運転状況に見合った保険料
運転習慣を見直し
from Business week
Ichiro Satoh
データサイエンティスト
いまはデータベースや分散システムの技術者の需要が高まっているが、
Hal Varian, chief economist at Google said in
“I keep saying that the sexy job in the next
10 years will be statisticians”
膨大なデータから、調べたい特性に有益なデータを見つけ、その特性とデータにあった解析を方法を選べる人材が必要
統計学や自然科学の実験系の経験・知識のある人材など
ということになっていますが
（そんな勘違いは実際にデータ分析をしていない評論家とベンダーぐらい）
Ichiro Satoh
データサイエンティストより現場
関心事とデータに応じて、分析対象のデータと分析手法を選択
経営者側が何を知りたいかを明確にすることが第一歩
高度な統計手法は有効とは限らない
ビッグデータではデータの品質が悪い
仮説次第
実顧客の行動を知らなければ仮説が立てられない
興味深いデータ特性は現場はうすうす気づいていることが多い
現場の気づきをデータ分析に活かす仕組みが必須
ビッグデータによる分析はリアルタイム化・詳細化
ビッグデータによる分析を活かすのは現場
Ichiro Satoh
データ分析の秘訣
仮説検証：データの特質に関する仮説を作り、それをデータ分析で確かめる
仮説の作り方：対象に最適化された事例を参考にする
例：自販機の商品構成から人の構成がわかる
分析手法や分散システムの知識も重要だが、現実の観察することが一番たいせつ
自販機の設置場所 売れる飲料 売れない飲料
事業所（インドア） お茶・コーヒー系 炭酸・スポーツ系
事業所（工場・アウトドア） コーヒー・お茶類・炭酸 季節に合わない商品
交通関係 コーヒー・お茶類・栄養系
スポーツ施設 スポーツ・機能性 コーヒー
街中 コーヒー・お茶・炭酸飲料
喫煙所 コーヒー
男性の多い場所 お茶（緑茶系） 禁煙場所ではコーヒー
女性の多い場所 お茶 紅茶（ブレンド系・ジャスミン茶）
Ichiro Satoh
システムへの要求
ビッグデータを活かしている企業のデータ量・処理量は指数的に膨張
処理能力を増大できるシステムが望まれる
ビッグデータのデータ解析手法は日々変化
いまユーザの知りたい情報にあわせて、データ解析方法を変える
データ量・処理量は試してみないとわからない
クラウドを積極利用して拡張・縮小できるシステム
→ クラウドコンピューティング
Ichiro Satoh
ビッグデータへの備え
データ解析技術者の確保
データに応じて適切な解析手法を選べる人材
リアルタイム化・詳細化したデータ分析結果を使うのは現場
現場のデータ分析能力を向上
現場裁量の拡大
データ収集
データがなければ分析もできない
インテリジェンス
経営者や現場がほしい情報を明確に
区別すべき対象とそれ以外の区別を明確に（IDが重要）
ビッグデータは魔法ではない
少量データの分析・活用ができない組織が、大量データ分析・活用は無理
Ichiro Satoh
まとめ
クラウドコンピューティングへの動きは止まらない
システム開発業界や開発者だけでなく、企業経営そのものにも影響
新しい計算システムは新しいアプリケーションのために使われる
システム開発からサービス提供に発想の転換が必要
受注システム開発の常識は通じない
作ることではなく、使ってもらうことによって対価をえるビジネス
ユーザ企業がサービス提供者になることも
ビッグデータの本質を見極める
多様なデータの利用が価値を生む（その多くは損出縮小）
企業差別化はシステム技術よりもデータ
POSからPOUへ
Ichiro Satoh
クラウド・ビッグデータの先にある世界
処理よりもデータ
データ処理とデータ提供は不可分
データ共有化
データは囲い込むものから、共有（シェア）するものへ
誰でもシンクタンク化
スプレッドシートが誰でも会計処理ができるようにしたように
物理世界とサイバー世界の不可分化
Cyber-Physical Systems化
シミュレーションとの融合
足りないデータはシミュレーションで補う
