予測分析プロジェクトの成功と失敗の分岐点～失敗しない為の７つのEssence～

前に書き忘れたシリーズ？のつづき。

９月１２日IBM Xcite 2014の

予測分析プロジェクトの成功と失敗の分岐点
～失敗しない為の７つのEssence～

の話をメモメモ

---

成否を分けるポイント
　　目的と手段
　　予測と誤差
　　部分と全体
　　ビルドタイムとランタイム
　　サイエンスとアート
　　理論と実践
　　投資と効果

【１．目的と手段】
Ｘ全社高度分析基盤を検証しています。どんなインフラが必要ですか？

　　統計・多変量解析（～１９９９）
　　データマイニング（１９９９～）
　　予測分析（２００６～）
　　ビッグデータアナリティクス（２０１１年～）
　　　　ＡＩ、分散処理やクラウドなど、キーワードは変化する。
　　　　自社データで何ができるのかを見極めて、有効な領域に投資
　　　　投資価値のあるビジネス領域にデータを使って改善する

　目的を明確に持ち、常にそこに立ち返る
　目的
　　　人　　　　　　　　製造業
　　顧客化　　　　　　品質改善
　　顧客育成　　　　　予知保全 Predictive mentenance
　　顧客維持　　　　　需要予測
　　リスク審査　　　　営業生産性向上
　　不正検知　　　　　価格適正化
　　　　　　　　　　　販促最適化（オムニチャネル）
　業務でどう生かせるか
　Predictive Maintenance Quality
　モニター情報から保守

【２．予測と誤差】
Ｘ予測って、本当に当たるんですか？

　あたりません
　誤差が生じる前提で、業務視点から、これに折り合う誤差を小さくする
　正誤行列と予測精度・・片方に寄せてしまうと正答性が上がるとき
　判別効率グラフ：疑わしいのをとる
　オオカミ少年と転ばぬ先の杖
　だれがどれだけ得をする？

【３．部分と全体】
Ｘビッグデータ分析なんだから、サンプリングしたら意味ないですよね

　正しくサンプリングすれば、全体事象に近似する
　データがたくさんあることが、ビッグデータではない
　　１．情報のリアルタイム収集
　　２．分散データ処理
　　３．情報の連携
　いろいろなデータを潔く捨てることも必要

【４．ビルドタイムとランタイム】
・業務実装後、勝手に学習しながらモデルが賢くなる技術はないんですか？
　　チャンピオン　チャレンジャー　モデル
　　テクノロジー上はできる
　ビルドタイムとランタイム
　　式をつくる：ビルドタイム
　　実行する：ランタイム
　モデルを作るときは、精度だけでなく、安定性も重要
　collaboration & deployment services
CADS

【５．サイエンスとアート】
○現場のベテランの勘も不思議と当たるんですよね
　　ハイブリッドなやり方→仮説がある人
　サイエンスとアート
　　ＫＤＤ（勘と度胸と・・）　ビジネスルール
　　これはやらないという企業のポリシー
　　経験と予測を融合させる：デシジョンリスト

【６．理論と実践】
Ｘ分析プロジェクトには、理系出身者が向いているんですか？
　　後から理論を学べばよい
　　アンサンブルモデル

【７．投資と効果】
・この予測分析ＰＪで、なんぼ儲かるの？
　　スモールスタート
　　リスクの回避やコスト削減


■まとめ
　　目的と手段→目的に立ち返る
　　予測と誤差→誤差を織り込み利益を確保
　　部分と全体→正しく捨てる潔さが必要
　　ビルドタイムとランタイム→作ると運用するは違う
　　サイエンスとアート→経験と予測を調和させる
　　理論と実践→実践先行で、理論が追従
　　投資と効果→小さく初めて、大きく稼ぐ

Netezza Analytics +SPSS によるビッグデータ・アナリティクスの世界

前に書き忘れたシリーズ？第二段。

９月１２日IBM Xcite 2014の

Netezza Analytics +SPSS によるビッグデータ・アナリティクスの世界

の話をメモメモ

---

●分析システム基盤とは
　違うもの
　　　　基幹、業務系→ミッションクリティカル、ビジネスをとめてはいけない
　→この逆が分析システム
　　　　・データを自由に扱うことが最優先：仕様変更が仕様
　　　　・余計なことを考えさせない、とまらせない
　理想の分析システム
　　　・データの重さを意識しない

●Pure Data System for Analitics 概要＆デモ
　→Netezzaのこと

　データ分析専用
　　　　高性能
　　　　簡易性
　　　　低コスト
　位置づけ：分析の専用システム

　アーキテクチャ概要
　　１、並列計算機のアーキテクチャ：非対称型超並列処理（ＡＭＰＰ）
　　２、ＦＰＧＡの採用　ＤＢ処理におけるＦＰＧＡの活用
　　３、ＺｏｎｅＭａｐ採用　アプライアンスの革新、何処に何時位のデータをおいておくか
　・ＦＰＧＡで列絞込み、行絞込みを行う

　デモ
　　購買トランザクション１．２Ｇ（何件かは不明の状態で）
　　create database、テーブル作る、ローディング→２５００万
　　　データ１０倍でも検索スピードほぼ同じ
　　データスコアリング　５千万
　　　　ＳＰＳＳ統計→Ｃになおし→ＦＰＧＡにインストール

　　７０億件１Ｔバイトの決定木→５０分
　　　　→NetezzaとSPSSが買収され、共同で開発するようになった

　「ＩＢＭ３分アナリティクス」で検索
　(リンク先を開くとすぐに音が出ます）
　　　大量データは当然
　　　人間がデータの重さを意識しない
　　　システムが人間の思考をとめない

AngularJSのお勉強

ここ

AngularJS入門 (全12回)
http://dotinstall.com/lessons/basic_angularjs

でお勉強した成果をメモメモ

---

●#01 AngularJSとは何か？
　JavascriptのＭＶＣフレームワーク

●#02 はじめてのAngularJS
1,スクリプトを読み込み、ng-app
　　→ng：A"ng"ular

２．INPUTタグに対して、ng-model="name"
　　→{{name}}で値が入る（ある程度評価できる）

●#03 コントローラーを使ってみよう
　１．divタグで、ng-controller=mainCtrl

　２．別ファイルにvar mainCtrl =function($scope){
　　　　$score.users=[
　　　　　　連想配列でデータ
];
　　　}

　３．{{users.length}}で、配列の大きさを返してくれる

４．ulタグで囲み、liタグにng-repeat="user in users"
　　　{{user.name}}
　　　とかすると、人数分繰り返す


●#04 フィルターを使ってみよう
　　{{user.name|uppercase}}
　など、|をつけて便利な機能
　　　|number:4 小数点４けた
　　　|number カンマ区切り
　　　|currency:"\" 円記号
　　　|date:'yyyy-MM-dd'日付

●#05 ループで使えるフィルター
　１．ng-repeatのフィルター
　　　ng-repeat="user in users|orderBy:'-score'|limitTo:3"

　２．フィルターを使って対象文字だけを絞り込む
　　　input type="text" ng-model="query"
　　　ng-repeat="user in users|filter:query"

　３．query.nameで名前だけ

●#06 ループで使える便利な命令
　１．ng-repeatの中で
　　{{$index}}　番号
　　{{$first}}　最初の要素？
　　{{$last}}　 最後の要素？

　２．ng-class-even,ng-class-odd

●#07 コントローラーのネストとイベント
　１．コントローラーは、入れ子に出来る
　　親要素からのデータを引き継げる

●#08 フォームの基本を学ぼう
　　ng-submit


●#09 エラーメッセージを表示する
　１．formタグ novalidate
　２．INPUTタグ ng-minlength
　３．エラーメッセージ:spanタグで、ng-show

●#10 フォーム部品を設置しよう (1)
　１．INPUTタグのtype=number,email,urlなどもできる

●#11 フォーム部品を設置しよう (2)
　１．type=checkboxのとき ng-true-value,ng-false-value
　２．type=radio ng-modelの名前を同じにする
　３．textarea {{140-user.memo.length}}で１４０字からの残り文字指定

●#12 フォーム部品を設置しよう (3)
　１．リストボックス
　　　ng-optionsでoptionタグ自動生成(初期値はng-init）
　２．ＡＰＩリファレンスに細かく載っている

---

P.Sこのドットインストールの

レッスン一覧
http://dotinstall.com/lessons

みると、すごい・・・

AWSおよびパートナーサービスを使った、データの集約および活用設計パターン

９月９日の、AWS Cloud Storage & DB Day 2014に行って来た内容のメモメモ！で、書き忘れていたのがあったので、
きょう、こっそり追加。

---

AWSおよびパートナーサービスを使った、データの集約および活用設計パターン
あまぞん、荒木氏

データ集約システム構成例
・データ：社内
・外にあるデータ：ＩｏＴ→どうやって集めるか

データ集約の基本方針
・あらゆるデータの発生源に対応する
　既存のアセットを最大限に活かす
　ＡＷＳのメリットを享受する

ＡＷＳのデータ関連サービス
データ
→ストレージ（Ｓ３，ぐれーしゃー）
→データベース
→データウェアハウス
→バッチ
→ＮｏＳＱＬ
→自動化（データパイプライン）

主力３サービス
Ｓ３
　オリジナルデータの保存
　中間データの保存
ＥｌａｓｔｉｃＭａｐＲｅｄｕｃｅ
　データのバッチ処理
　非構造化→構造化
ＲｅｄＳｈｉｆｔ
　ビジネスアナリティクス
　ＳＱＬアクセス

Ｓ３
・非常に耐久性の高いオンラインストレージ
　暗号鍵を管理できるようになった

ＥＭＲ
・Hadoopクラスタのサービス
　１時間単位の従量課金
　クラスタのサイズを後から変えられる
　アルゴリズムによって違う→同じデータを
　別のクラスタで処理してＡ／Ｂテスト
・終わったら終了

RedShift
・データウェアハウスサービス
　運用管理の手間がほぼない
　初期費用０、低価格
　ＳＱＬ
　エコシステム使える

データロード
・FlyData
・Ａｔｔｕｎｉｔｙ
・ＤａｔａＳｐｉｄｅｒ
・Ｔａｌｅｎｄ
違った特色
　ＪＤＢＣ／ＯＤＢＣ
　Ｓ３からのＬｏａｄをネイティブで持っている
ＦｌｙＤａｔａ　Ｓｙｎｃ　Ｆｏｒ　ＭｙＳＱＬ
　バイナリログを吸い出して、Ｓ３になげる
　トランザクションデータＭｙＳＱＬ
　統計処理ＲｅｄＳｈｉｆｔ

ＢＩツールとの連携
　ＪＤＢＣ／ＯＤＢＣ
　　　多くのベンダーがつないでくれている
　　　Ｔａｂｌｅａｕ
　　→可視化に強いベンダー

ビッグデータのソリューション
スケーラブルにアプローチ
・ビッグデータの一般的なアプローチ
・ビッグデータのストリーム処理
蓄積された過去のデータ
今のデータ

Amazon Kinesis
・フルマネージドなリアルタイムデータ処理

DynamoDB
・高速、予測可能なパフォーマンス

ＡＷＳを付き合ったＩｏＴアーキテクチャイメージ
・リアルタイムに流れるデータ処理
・用途によったデータ変換とデータ保存
・ユーザーエクスペリエンス部分

ＶＰＣ（バーチャルプライベートクラウド）
→デフォルトＶＰＣ
　専用線をつなぎこむことも

ＶＰＣ内のシステム構築のために
　サブネット：
　　ログインする必要ないものは、目的別に分けない
　　ログインする必要のあるものは、細かく分ける

AWSのＡＰＩ使用にはインターネット接続が必要
　　ＥＩＰ
　　ＮＡＴインスタンス
　　オンプレミス側インターネット船
　→ＡＷＳのリソースは原則ホスト名

AWS Direct Connect
　　ポートを用い、専用線
　　建屋→構内接続

cloud hubのHubとしてのVPC
　　→AmazonにVPNをあつめる

ネットワークキャリアによる拡張
　　閉域網へのアクセス手段
　　　　ＬＴＥ，３Ｇ，フレッツ
　　パートナーキャリア
　　　　ＫＤＤＩ
　　　　ＮＴＴコミュニケーション
　　　　ＫＵＨ
　　　　Tokaiコミュニケーション

Ｓ３へのファイルコピー
　　バケット
　　マルチパート
　　ファイル名の分散
　　ツール:
　　　　attunity cloud beam
　　　　ExpeDat Gateway
　　　　cloud berry

インスタンスへのファイルコピー：高速
　　Tsunami UDP
　　ASTERIA
　　Skeed

ブロック
　　　AWS StrageGateway
　　　DRBD,DRBD-proxy
　　　DataKeeper

転送先最適化サービス
　　　AWS OFA(オバマ・フォー・アメリカ）
　　　　→CloudOptを利用

システム設計
　　インフラ
　　データ集約
　　データ活用
ＡＷＳ専用線アクセス体験ラボ
　　受講するトレーニング
　　　ＶＰＣダイレクト
　　　　　トレーニング１　１０／２
　　　　　トレーニング２　１０／２１
　　　　　実機ハンズオン　１１／５
　　随時開催

まとめ
　　データをどこかに保存する　ＡＷＳ
　　体験ラボ

システム開発がプロジェクトマネージャー型からタスクフォースリーダー型に変わるかも？

前のブログの戦略型タスクフォースリーダーとコンピューター業界の関係について。

突然ですが、人との結びつき（ネットワーク）には、２種類ある。

　ピラミッド型組織で、内部の連結を強化するコールマン・レント型と、
　弱い紐帯で結ばれている各組織を結びつけるバート・レント型。

コンピューター業界の開発は、

　　元請けのプロジェクトマネージャーをトップとして、
　　元請けの社員、
　　下請けのプロジェクトマネージャー
　　下請けのＳＥ
　　派遣会社からきた、ＳＥプログラマー・・・

などなどと、ピラミッド型組織をつくり、各部門に仕事を割り振り
組織内部で仕事を「処理」（作業）するように組織化されている。
つまり、典型的な、コールマン・レント型であり、
その頂点は、プロジェクトマネージャーである。

---

　ところが、これで処理できないシステムが出てきた。
　クラウドを利用するようなシステムの場合、
　いろいろな分野（ネットワーク、ＮｏＳＱＬ、仮想化）の高度な専門的知識
　を統合してシステムを開発していかなければならない。

　これは、組織を超えて作ることになるが、
　カフェテリア的に技術を使っているのであって、
　各技術要素は、ほんの少しでしかない。

　なので、上述のように組織化してしまうと、膨大な組織が
　出来る割に、情報が流れないので、仕事が進まない。
　この仕事を進めるには、

　お客さんや専門家の要望を解釈して実装する会社（解釈者）Ａ
　　　ネットワークのある部分を行う専門会社Ｂ
　　　ネットワークの別の部分を行う専門会社Ｃ
　　　仮想化に強い会社Ｄ
　　　RedShift関連をやる専門会社Ｅ
　　　RDSと会社のＲＤＢに強い会社Ｆ

　のように、専門会社＋それを解釈してお客につなげる人が
　必要になる。こうしないと、高度に専門家を利用して、
　予算内・納期内にシステムを作れない。

　逆に、いろんな部分の自動化、部品化により、コーディング量は
　少なくなっているので、これですんでしまう。

　まさに、この組織は、専門会社と解釈者が弱い紐帯で結ばれている
　バートレント型で、解釈者が構造的空隙となる。

　この解釈者＆境界連結者がタスクフォースリーダーとなる。

---

ということで、
システム開発がプロジェクトマネージャー型からタスクフォースリーダー型に変わるかも？

戦略タスクフォースリーダーをいかにして育てるか

知的資産経営新ビジネス塾の「戦略タスクフォースリーダーをいかにして育てるか」
を聞いてきた！

これが、どうコンピューターに関係するのかは、今後のエントリーで説明していく
けど、まずは、聞いてきた内容のメモメモ

---

■戦略タスクフォースリーダー養成プログラム

・プログラムの目的
　　戦略タスクフォースを組織・運営
　　経営トップに提言を行う
　　　→戦略タスクフォースリーダーの養成

・知的資産経営戦略タスクフォースリーダーとは
　　　全社横断型
　　　起案・提言を行うまで

・具体的なリーダー候補者
　　　大企業の全社企画部門
　　　技術開発リーダー
　　　中小企業の社長または社長後継者

・知財関係の研修ではない

・パブリックファンディングマネジメント
　　→国プロを上手く活用する

・プログラムの内容
　　　オープンクローズ戦略
　　　新興国イノベーション戦略
　　　デザインドリブンイノベーション
　　　標準を利用した戦略

・聞いたことがある→わかった
　　　ケース
　　　ロールプレイ
　　　タスクフォース実施のために
　　　どういうことがわかっていないといけないか
　　　個別

・意義
　　成功例が高くない
　　研究→クロスファンクショナルチーム


タスクフォース：やったけど、成功率低い

ＮＰＥ：パテントトロール
→シンガポール特許庁

----------------

■戦略タスクフォース・リーダーをいかにして育てるか

ケース演習：「知っている」から「わかった」へ

・契約マネジメント
　　チームプレイ
　　契約書の書き方？
　　戦略？
　　→まんなかくらいをねらいたい
　Qualcommのチップライセンス／ネットワークライセンスの二重構造
　グラントバック→パテントプール→制限

・交渉
　　基本と応用

交渉の三段階
　　準備：一人でできる
　　説得：相手→違う
　　契約書
タスクフォース：交渉チームリーダー

---------

■タスクフォースリーダーをいかに見出し育てるか

・リーダーシップ論で終わらせたくなかった
・コンフリクトマネジメント終わらせたくなかった
　戦略
　タスクフォース：軍隊用語→企業経営　ex 3.11
　リーダー
・お役所が好む「タスクフォース」
・企業では使わない「プロジェクト」→期間長い
　　→クロスファンクショナルチーム
　　　　日産

・最近の戦略的タスクフォース事例
　　ソニー

・クロスファンクショナルチームはかなりヒットする。
　　　→通常組織とあまり変わらない
　タスクフォースになるほど、プロジェクトより落ちる
　　その上を行くのは？

・耳を持つ
　つなぐ人
　説明する力（解釈者）
→境界連結者と解釈者を兼ね備えた人物

ＰＡＲＴ２：タスクフォースリーダーとは誰？
　　　境界連結者(バウンダリースパナー）
　　とゲートキーパー(組織所属外といろいろもってる）

タッシュマン
　　スター：有名な人と、組織外部と接合を持っているか？
　　　　部署によっては多くつながってるが、そうでない場合も・・・
他の事例
　　　　社外とつながっている人が、社内とつながっているというわけではなさそう
　　　→タッシュマンを指示
　　　→社内で活躍している人は、あやまり！
解釈者
　　　→管理職

発見：みつからない

そもそも、育てることができるか？
　　理論的にはなれるが、現実的か？
　　リーダー：育てても元に戻る

---------

パネルディスカッション

ジョブローテーション→あんまり聞かない
　　異なった分野の言葉を分かる人を育てようというのが・・・
　　→言葉通じない

ＩＰＢＣ
知らないと、相当損をする

解釈の仕方の多様性

ケースに答えを求めるのはキケン
　　→分かったつもりになって終わるかも
　　→自分の経験で解釈の多様性を失ってしまう

学び方を忘れる→経験から外れられない
　事実をはっきり取れない
　マインドセットをかえることにフォーカスしたら？
　しったかぶり、ものしりになったら困る

多様な議論をどう担保するか
使えるか
解釈演習、解釈１０００本ノック
connect the dot(jobs)

場面から学ぶ

プロジェクト
解釈者＝おしゃべりで、やさしく人に語れると、成功する
　　→分野外の人

---

オープンソースで遠隔地にプレゼン・授業するためのソフトBigBlueButton

遠隔地と会議したり、プレゼンしたりする場合、
Ｗｅｂカメラで見えるだけでなく、
プレゼン資料を共有したり、書き込んだりしたいことがある。

そういう、「遠隔地にプレゼン・授業するためのソフト」で
オープンソースのものがあるらしい。
BigBlueButtonというらしい。こんなかんじ。

http://bigbluebutton.org/overview/より引用。


くわしくは
http://bigbluebutton.org/
を参照のこと。downloadには、ubuntuでのdownloadのしかたが書いてある。

「仕様書基づきシステム設計、プログラミング、テストする」ことで収入が得られるという幻想の終焉

ほんの少し前まで、
お客さんが仕様書を作成し
　　（ここでの仕様は最低要求仕様書・外部仕様書の一部を含む）、

それに基づきシステム設計、プログラミング、

プログラミングした内容が仕様書とあっているか、各種テストする

ということで、システムエンジニア、プログラマは収入が得られた。

---

しかし、これは、経済的に考えると、幻想でしかない。

（１）なぜなら、このモデルは、お客さんが完璧な仕様書を作れない限り、
　　　発注できない、ＳＥ，プログラマは作業できない
　　＝完璧な仕様書は作れないから、作業がはじまらない
　　　もう、どうしょうもなくなったところで、
　　　「えいや」と仕様書を投げ、突貫工事でシステムを作ることになる
　　

（２）もし、「仕様書を作らなくても、うちは仕事を請け負います」
　　　という会社が出てきてしまうと、その会社に仕事をとられてしまう
　　　さらに、この会社は早期に請け負えるので、（１）の会社よりも
　　　工期を長く取れ、突貫工事をしなくて良い＝残業代のような
　　　特別経費がかからない。

ということで、このビジネスモデルは、「仕様書を作らなくても、
請け負う会社が出る」という会社が出現したとことで終了するモデル
である。

---

そして、そのような会社が出始めた。

ちょっと古いけど、日経コンピューター　２０１４年９月４日号
１３ページ

ＡＯＫＩがオムニチャネル本格化
ＣＲＭ開発費を９０００万円に抑える

にあるように、この開発では、要件定義書を作成していないで、
画面のモックアップを作成しただけで実作業に入っている。

実際には、ある程度の規模までは、最近は、
画面のモックアップまでは作れて、それを承認もらえばＯＫ、
みたいなところがある。
（し、実際そういう仕事が増えている）

さらに今後は、どういう画面を作ればいいかまで
任される仕事が増えてくるだろう・・

---

とすると、仕様書から設計、ましてや、
Ｊａｖａ、ＰＨＰなど、言語にこだわったプログラマさんは、
上流から仕事を他社にとられて、
仕事が回ってこなくなる（か、おそろしいダンピングをしないといけなくなる）
のではないかと思う。

とりあえず２０１５年問題があるから、当分仕事はあるかもしれないけど、

そのさきは、

「仕様書基づきシステム設計、プログラミング、テストする」
ことで収入が得られるという幻想は、終焉し、

客のためにビジネスモデルを作成し、そのモデルから、最適なシステムを
デザイン、推奨して、一気に作成、ないしはパッケージソフト、
サービスを構築して、デプロイする

ということが出来る人たちだけが残るんじゃないかと、
思いますね・・・

JQueryで、セレクタをID指定("#id")して、うまくいかないとき確かめたいこと・・

目的の対象が、自分(this)か、自分の先祖の場合、

$(this).attr("id");　・・・自分の場合

$(this).parents(".class_name").attr("id")・・・自分の先祖で、クラス指定されている場合

などを使って、ＩＤを取得し、そのＩＤを表示してみよう
alert($(this).attr("id"));

そしてもし、うまくいかないのが変数を使っている場合、そいつも表示してみよう。
書き間違いや、（クロージャーによる変数書き換えなどでの）変数の思い違いは、
これで気づける。


なお、thisと$(this)は、オブジェクトの型が違うから注意！
thisは、HTMLのオブジェクトとして処理される。
つまり、this.attr("id");はエラーになる。

これが$(this)と書くと、JQuery型に変換され、JQueryで書けるようになる。

D3.jsで日本地図出して、点をうつ方法

前に、Ｒで日本地図出して、気象庁のデータ読み込んで、軌跡を描くところまでは、できた>で、最後に「D3.jsで日本地図出して、点をうつ」ところまで出来たと書いておきながら、その方法を書いていなかった。

今回、その方法を書いておく。

【お題】
結局、こんなやつを出す。


【前提】

日本地図を用意する。本当は

http://cloud.aitc.jp/20140627_D3js/201406xx_D3js.pdf

の１５ページや

http://www.slideshare.net/dsuket/d3js-35239244

の３４シート目にあるように、
（１）http://www.naturalearthdata.com
　　　にいって、データをshape形式でとってきて
（２）それをGeoJSONに変えるため、ogr2ogrし
（３）さらにGeoJSONをTopoJSON形式に変換

となるんだけど、今回は、そのシートの４０枚目にある
http://bit.ly/japantopo
つまり、
https://dl.dropboxusercontent.com/u/1662536/topojson/japan.topojson
のデータを使います。


【プログラム】
こんなかんじ

<!doctype html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>Sample 01</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script> 
<script src="http://d3js.org/d3.v3.min.js" charset="utf-8"></script>
<script src="http://d3js.org/topojson.v0.min.js"></script>
<script type="text/javascript">

$(function(){

//	日本地図
var topoJsonUrl = "https://dl.dropboxusercontent.com/u/1662536/topojson/japan.topo.json";

//	変数設定
var width = 500,
    height = 500,
    scale = 1;

// bodyにSVGをつくり、g(地図グループ）を作る
d3.select("body").append("svg")
	.attr("width", width)
	.attr("height", height)
	.append("g").attr("id", "all-g");

//投影法の設定
var projection = d3.geo.mercator()
		.center([138, 38])
		.scale(1200)
		.translate([width / 2, height / 2]);
    
// 地図読み込み
d3.json(topoJsonUrl, onLoadMap);

// データ設定
var mydata =[
[135.25508,34.336263],
[140.103417,39.706976],
[139.69194,35.659432]
];

//==============================//
//	地図と点を描く		//
//==============================//
function onLoadMap (error, jpn) {

	//地図を描く
	var path = d3.geo.path().projection(projection);
	var features = topojson.object(jpn, jpn.objects.japan);
	d3.select("#all-g")
        	.append("g").attr("id", "path-g").selectAll("path")
            	.data(features.geometries)
            	.enter()
            	.append("path")
            	.attr("fill", "#f0f0f0")
            	.attr("stroke", "#999")
            	.attr("stroke-width", 0.5/scale)
            	.attr("d", path);

	//	点を描く
	d3.select("#all-g")
		.append("g").attr("id","circle-g").selectAll("circle")
		.data(mydata)
		.enter()
		.append("circle");

	//	赤く塗る
	d3.selectAll("#circle-g circle")
		.attr("fill", "red")
		.attr("opacity", 0.5)
		.attr("transform", function(d) { 
			var coord = projection([d[0], d[1]]);
			return "translate(" + coord.join(",") + ")"; 
		})
		.attr("r", 5/scale);
}

});

</script>
</head>
<body>

</body>
</html>

【参考】
上記スライドシートのほか
http://jsfiddle.net/dsuket/sEFjd/
など。

SPSS Modelerだと、たしかに分析、簡単そうだ・・・でも・・・

IBM Xcite 2014に行って来て、IBM SPSS Modelerについて習ってきました。
結果、こんな感じのものを作りました。

ＲＦＭ分析等も、ノード（下にいろいろ並んでいるアイコン）があって、
それを使って、簡単に分析できるらしい。

この前、「分析手法がたくさんあって、手がつけられない→よく使うのは５つだけ」
で、JALの人が、よく使う分析は
　　　クロス集計
　　　ロジスティック回帰
　　　決定木
　　　アソシエーション分析
　　　非階層的クラスター分析
の５つだけという話をしていたことを書いたけど、あの程度なら、ＳＰＳＳ Modelerを
使うと、簡単に出来るのかも・・という気もしないでもない
（ノードがあるかどうかの話だけど。。。）

ただ、お値段が、それなりにするみたい。

う～ん・・・

ビッグデータの市場って、ドコモのdマーケットと同じ程度しかないの？

ビッグデータの市場規模だけど・・・

国内ビジネスアナリティクス市場におけるビッグデータ市場予測を発表
http://www.idcjapan.co.jp/Press/Current/20140123Apr.html

2017年には1,016億円とのこと。
約１０００億円・・・

１０００億円！

１０００億円って、たしか、Ｄｏｃｏｍｏのd-マーケットの
市場規模じゃなかったっけ？

https://www.nttdocomo.co.jp/corporate/ir/library/docotsu/60/financial.html


あの話題のビッグデータ市場＝ドコモのdマーケット

意外と、小さいんだな・・・

分析手法がたくさんあって、手がつけられない→よく使うのは５つだけ

IBM Xcite 2014に今日(9/12)行って来た
その内容、メモメモ。
まずは、基調講演


５月より、具体的ソリューション

---

■データ、クラウド、エンゲージメントによる企業改革
春から１１３日たった。
この期間、どんなものだったか
この間、日本で生成だれたデータ、情報
　　→ＤＶＤ　１億７千万枚のＤＶＤがいる
　　→富士山の高さの５４００倍

３つの戦略的変化
・データ
　　天然資源としての
　　モバイルデータ通信量２０１７年までに日本１人当たり１４倍
・クラウド
　２０１６年までにソフトの５分の１がクラウド用
・エンゲージメント
　８０％　ソーシャル・メディアを使用する８０％の人々が
　個人情報を共有

ＩＢＭがしたこと
・プレス発表
　IBM Cloud marketplace
　　クラウド・イノベーションをワンストップで支援する
　　オンライン店舗

　IBM BlueHub
　アベノミクス：３本目の矢
　　提携して、支援
　２つのシェアードスペースと新たに提携し、スタートアップを支援

　ＩＢＭ　ＸＣＩＴＥ　ビジネス・パートナー・デイ
　６７０億のＲ＆Ｄ

---

■クラウド、ビッグデータ、エンゲージ面とがもたらすビジネス革新
（ろばーとさん）
・ビジネス・イノベーションの最前線に位置するＩＴ
　新たな価値を想像する３つのメソッド
　　　ビジネスの成長エンジンとしてのクラウドを活用
　　　競争上の優位性を得る新たな基盤としてデータを利用
　　　生産性とブランド価値を高めるためにシステムオブエンゲージメントを実現

　いろんなものをいっぺんに→ちゃんす
　　ＣｘＯの７９％が新たなトレンドに迅速に対応
　　ＣＩＯの３～５年先の最優先課題は、企業戦略の重要な実現者になること
　　９１％がクラウド向け（２０１４年）

　クラウドがビジネス船体の革新を実現
　　デベロッパー
　　　サービスを迅速に組み立てることで次世代の革新的なアプリ
　　ＩＴリーダー
　　　ハイブリッドクラウド
　　ビジネスリーダー
　　　顧客が期待するスピードで変革

　既存の投資を活かしながら、オンプレ、オフプレ
　　　数時間、数日の上に開発できないとＸ

　エンタープライズＩＴをシームレスに拡張するハイブリッドクラウド
　企業のおよそ７０％が２０１５年までに、ハイブリッド・クラウドを推進
　　　ガートナー

　ハイブリッドクラウドにより迅速な革新とコスト削減を実現
　　　セキュアな統合；システムズ・オブ・レコード(SOR),エンゲージメント(SOE)
　　　ポータビリティと最適化
　　　スケールアウト
　　　バックアップとアーカイブ

　クラウドの全ての階層を網羅するＩＢＭのポートフォリオ
　　　ビジネスプロセス as a Service
　　　ソフトウェア as a Service　　　　　→オンプレミス、クラウド環境
　　　プラットフォーム　 as a Service
　　　インフラ　as a Service
　ビジネスプロセス　ＨＲ
　　　自社で、クラウドで

　ＩＢＭ　IaaS：ハイブリッド・クラウドの管理を簡略化
　　　Softlayer
　　完全な制御性、アクセス、透明性
　　シームレスで耐障害製のあるマルチサイト・トポロジー
　　
　複数のセンター

　ＩＢＭ　ＰａａＳ　Bluemix
　　モバイル／ＷＥＢアプリケーションの配信に無限の可能性を
　　デベロッパーは、イノベーションに注力できる

　ＩＢＭ　ＳａａＳ　フロント・オフィスとバック・オフィスを効率化
　　　リスクアナリティクス
　　　パフォーマンス管理
　　　資産管理
　　　ソーシャルコラボレーション

ビジネス成長の原動力としてのクラウド
　　京セラドキュメントソリューションズ
　　ユニホー（マンションのメンテナンス）
　　日本の大手自動車会社

ビジネス全体にわたるクラウド・サービスでＩＢＭの価値を提供

競走場の優位性を得る新たな基盤として、データを利用

データから得られる知見が起業を変革
　　販売／マーケティング／サービス
　　ＩＴとビジネス運用
　　財務／不正／リスク
　　人材
　業界のリーダーは決定の大半をデータに基づいて
　行う割合が通常の２．７倍

ビジネス上の重要な知見とそれを支えるＩＴ基盤が競合優位を確立
　　全てのデータソース
　　　トランザクションとアプリケーション
　　　マシンとセンサー
　　　エンタープライズコンテンツ
　　新規／拡張アプリケーション
　　　顧客経験

Watson Foundation:
　統合プラットフォームとしてビジネス上の知見を実現
　非構造化データをリアルタイムで
　　　新たな知見を発掘
　　　リアルタイム処理
　　　信頼と革新

ビッグデータ活用による新たな競争優位基盤を獲得
　　顧客満足度工場：All About
　　ビジネス変革を加速：国内大手飲料メーカー
　　顧客維持率の向上：ＮＴＴぷらら

生産性とブランド価値を高めるために
エンゲージメント

セキュアな環境とモバイルとソーシャル・テクノロジにより
人々の係わり合いが大きく変化

２０１４年末までに、日本の消費者の６２％がづマートフォン所有（ぶるーむばーぐ2013/12/11）
１９００万人の日本の消費者がスマートフォンを利用してデータを共用
２４５億円：日本では典型的なデータ漏洩で２４５億円の損失

人間中心のエンゲージメント

ＩＢＭ　MobileFirst
モバイル・エンタープライズがエンゲージメントを加速
　　Protect/保護
　　Build/構築
　　Transform/変革
　　Engage/エンゲージ

インタラクションのパターンがちがうから、
いまのソフトをモバイルに載せてもＸ

プラットフォームでどれが主流になるか、賭ける？
　IOS,Android・・・
予見性：だれもが、モバイルデバイス
ＩＢＭ：ＢＹＯＤを認めている
　コーポレート→なくしたらワイプアウト
　パーソナル

モバイル、ソーシャル、アナリティクスの機能を統合して
人間中心のエンゲージ面とを推進する
　　スマーターコマース
　　スマーターワークフォース
　　スマーターシチズン
ソーシャル・ビジネス

IBM MailNext：まもなく登場
　→次世代のユーザーのインターフェース：異なる
　モバイルファースト
　クラウド、あとからオンプレ

高度な脅威を食い止める、セキュリティの統合アプローチ
　ＩＢＭセキュリティ・フレームワーク
　　　インテリジェンス
　　　統合
　　　専門知識
　・ビジネスデータよりセキュリティデータのほうが多いことも
　・データを理解、アクションへ

生産性とブランド価値を高めるために
システムズ・オブ・エンゲージメントを実現

・ヤマトファイナンシャル：
　　IBM Connectionをクラウドへ：３週間

・資生堂
　お客様の店頭経験を刷新：worklightとipadを配布

・上位５社に数えられるエネルギー企業
　高度なセキュリティの脅威を防衛
　２０億件以上のイベントを分析、２０～２５件の潜在的攻撃を発見

これらを組み合わせて、すべてが変わる
　　クラウド
　　データ
　　エンゲージメント
made with IBM cloud
　ITはenablerである

事例紹介
しものさん

　クラウド
　　はじめ、買うか借りるか、
　　サービス化していく過程がクラウド
　　　→製造業からサービス業

　データ
　　ものが賢くなった

　エンゲージメント
　　コミュニケーション
　　本質的にまったくちがう

---

■クラウド事例：パイオニアＶＣサービス
　グローバル規模の製造・設計現場でのコラボレーションサービス
　V-cubeとPioneer
・Visual collaboration
　web会議やテレビ会議とは異なるニーズにこたえる

・大きなパネルでコラボレーション

・パイオニアグループ活用状況
　全体の８５％はコラボレーション

・お客様の課題
　　クラウドセキュリティ
　　経済性
　　システムとネットワークの運用・可用性
・Softlayer
　　プロビジョニング　１５分～３０分
　　ミドルウェア、ＣＣＳ導入　３０分
・IBM Softlayerを選んだ理由
　　設定の容易さと豊富なオプション
　　変更の容易さ（自社の特性に合った設計可能）
　　レイテンシーの正確さ

・ばいしんく(xSync)システム構成
　導入成果：IBM Softlayerによるサービスの広がり
　SoftLayerのGlobalバックボーンが実現

---

■ビッグデータ分析でお客様に最高のサービスを提供する
しぶやさん

・ＪＡＬブランドにこめた想い
・ＪＡＬホームページ：５０万人１日
　　２億ページビュー
　２０１２年　企業ウェブサイト価値ランキング１位

・リアルのお店の場合
　　店員さんは、常にお客様やお店の状況を見て販売
・jal.co.jp
　数字が取得できないため、来訪者や閲覧ページの状況など、まったく把握せずに商売
・最適なレコメンド
　（１）お客様が何を望んでいるか、知る必要がある
　（２）トライアルを繰り返し、制度を高める
　→SPSS MOdeler

・SPSS MOdelerのよいところ
　操作が簡単

・導入までの経緯を振り返って
　　何がやりたいか
　　どんなデータが使えるのか　→この部分を省略すると、失敗する
　　どういうツール・ハード必要か
　　分析開始
　どんなデータがあるのかと、どんなデータが使えるかは違う

・効果
　　ＣＶ（こんばーじょん）が１０倍、ＣＶ額が数千万円以上も

●一般の事業会社における
　データサイエンティストの作り方

　雑誌で出ているのは特別な人
　中心：自分で分析ができるマーケッター

・分析人材と必要なスキル
　ビジネスを理解し、分析結果を「わかりやすく」伝える能力が必要
　　マーケティング、ビジネス担当
　→いかに分析のハードルを下げるか

・実務：多変量解析とデータマイニング
　　→立ちはだかる統計学の壁
　　　　→必要以上にハードルをあげる
　　→ツールの力を借りて、実務の分野へ

・分析手法がたくさんあって、手がつけられない
　よくつかうのは５つ
　　　クロス集計
　　　ロジスティック回帰
　　　決定木
　　　アソシエーション分析
　　　非階層的クラスター分析

・怖がらずにはじめよう
　決してハードルは高くない

---

■企業ソーシャルによるグローバルなワークスタイル革新
　　J-SQWare
・ＪＣＢ　４つの事業ドメイン
　　　ブランド、カード、加盟店、プロセシング事業
・ＪＣＢの目指す姿：２０２０年のありたい姿
　　　ＩＴ部門の課題→Socialで解決
・なぜSocial
　　部門を越えた情報共有
　　ファイルサーバー卒業
・体制が成功の鍵

・ＩＢＭを選んだ理由
　　Ｄｏｍｉｎｏからの移行のしやすさ
　　踏み込んだ提案

・JSQWare
　プライベートクラウド
　　コミニティ→社長のトップ発言、社内提案制度
　　掲示板／部門共有
　　ポータルコンテンツ

・導入効果
　社員の意識変化
　能動的な情報共有
　在席確認の活用

・こんな想定外
　既存ＤＢの利用状況整理
　想像以上に新しい機能はユーザー利用に違い

・すべての成功はユーザーが決めること
・踏み出す人に世界は微笑む

Ｂｌｕｅｍｉｘチャレンジの表彰式

PostgreSQL9.4のJSONB型と、JSON型比較、GINインデックスなど、聞いてきた！

9月11日、
PostgreSQL9.4 最新情報セミナー
～新しいJSONデータ型開発者のOleg氏を迎えて～

を聞いてきたので、メモメモ

---

最近勢いでてきた
　日本は、以前からPostgreSQLつよい
　エンタープライズ、基幹業務で使われる
　外国での勢いすごい！
　　イギリス気象庁
　ＧＩＮインデックス

２００６年、国際コンファレンス
　　・前文検索
　　・ＧＩＮインデックス
　　・locale対応

ロシアでの開発状況
　９．４　９月末リリース予定

自己紹介

アジェンダ
　JSONB,いんでくしんぐ、ウォッカ

問題
・ＢｉｇＤａｔａ
・Ｗｅｂアプリ→サービス指向
　　一貫性
　　同時実行
　　ＡＣＩＤの負荷をかるく
・新しいＤＢ　ＮｏＳＱＬ
　　スケーラブル、えふぃしゃんと、フォールトトレラント

ＮＯＳＱＬ
・キーバリュー
・カラムファミリー
・ドキュメント
・グラフ

問題点
・ＡＣＩＤが必要でＮｏＳＱＬの柔軟性
・ＲＤＢでスキーマ変更は難しい
・リリースタイミング
・ＪＳＯＮフォーマット＝スキーマなしに対応できる！
　　課題

ＰｏｓｔｇｒｅＳＱＬのチャレンジ
・ＰｏｓｔｇｒｅＳＱＬに半構造化データ
　　ストレージ
　　演算子
　　拡張子
・ＰｏｓｔｇｒｅＳＱＬはスキーマレスで２００３から
　→HStore
Google Insightでしらべると。。。
　２００６年→発表したときから注目

HStore
・キーバリューのペア
・スキーマ変更いらない
・インデックスもサポートしている
２００６年１２月　HStore
２００７年　　ＧＩＮインデックス

転地インデックス

ＧＩＮ２つのツリー
　　エントリー：キーワード
　　ポスティング：ページ番号とか

汎用転地インデックス

ＧＩＮ９．４改善点
・圧縮
・検索早くなった
　　よく出てくる言語に比例
　　めったに確認されないほうに

valueにレアを使うと早い
９．４にするとはやくなる
エクステンション入れても早くなる

シンプルすぎた→JSONへ
HStore VS JSON
・でもJSONはおそい
　→HStoreのドキュメントベースモデル必要
　　→JSON

２年前：ねすてぃっどHStore
PGCon2013で
→ネステッドHStoreよりJSONBへ
ＪＳＯＮＢ；バイナリーＪＳＯＮ

ＪＳＯＮ：ＡＳ　ＩＳ
ＪＳＯＮＢ：重複なし、ソーテッドされている
入力パフォーマンス
　　ＪＳＯＮ：おそくなる
　　ＪＳＯＮＢ：もっとおそくなる

検索パフォーマンス
　　ＪＳＯＮＢ：１秒
　　ＪＳＯＮ：９．６秒
　ＪＳＯＮＢのほうがはやい

pathとバリューを組み合わせると、２０００倍早くなる

ＭｏｎｇｏＤＢと比べると・・・
ローディング　１３分→ＪＳＯＮＢ　４３秒
検索　ほぼ同じ
インデックス　ＪＳＯＮＢのほうが早い

指定の仕方
・ルートから特定化
・JSONBの検索言語：JSQuery
　　　キーへの演算子
　　　バリュー向け演算子
　　　タイプチェック
・オプティマイザーがないと遅くなる
　　　プランナーを使って時間短縮
・JSQuery
　　オプティマイザー New
　　ヒント-New -noindexなど

・エクステンションで導入可能

マイクロソフト：JSONサポートない
Ｏｒａｃｌｅ：ない
MySQL：インデックスとかはサポートしない
PostgreSQL:サポート

ＧＩＮインデックス
・２つのキー
・インデックスの長さ制限

アクセス方法
・spgist opclass
・ＧＩＳ　フルテキストサーチ
CREATE INDEX USING VODKA（うぉっか）
・インデックスツリーは選べる
・エンティティにSPGistとか
・VODKAでは、Ｒｔｒｅｅ→Ｂではない
　　→マルチカラムインデックス

・いっしょにやりたいひとがいたらかんげい

ＶＯＤＫＡ(うぉっか）：飲み物ではない
　→Optimized Dendriform Keys Array

GIN（じん）：飲み物ではない
　→アラビアンナイトの魔法かけるジーニーから

Ｑ＆Ａ
ヒントはPostgreSQLいれないっていう方針だけど、
どうやってＹＥＳと言わせた？
→エクステンションなんで・・・ってことで・・・


トランザクションに対応しているか？
ＪＳＯＮＢは対応している

---

■PostgreSQL9.4評価検証報告

●Part1　性能アップって、どのくらいですか？
・GINインデックス性能改善
　　すべての局面で早くなった
　　　→ポイント気にせずに作っても
　　　→さっきの話だと、レアなものを選ぶと

・ＷＡＬの性能改善
　　ＷＡＬ：トランザクション
　　ＷＡＬ出力量が減った
　　→流れるデータで変わる

・ＷＡＬ書き込みの同時実行性
　　ＣＰＵコア数多く、ディスクは早いとき

・JSONとJSONB型の比較
　　投入はJSONBが少し遅い
　　　ＧＩＮインデックス
　　　関数インデックス
　　検索はインデックス使わなくても
　　　所要時間半分：バイナリで格納

・CouchBaseと比較
　　投入
　　　やはり、couchbaseがはやい。が、大差ないが。。
　　並列ランダム更新
　　　couchbaseがはやい
　　読み込み
　　　GINインデックス使ったほうがはやい

●Part2　この新機能は何ですか？
・レプリケーションスロット
　　プライマリとスタンバイをつなぐ絆
　　→レプリケーションコンフリクトを起こさないため
　　　ＷＡＬ削除の問題を起こさないため

・logicalレプリケーションスロットの可能性

・更新ビューのＣＨＥＣＫオプション
　集約クエリでＦＩＬＴＥＲオプション

・ＡＬＴＥＲ　ＳＹＳＴＥＭで設定変更できる
　ＡＬＴＥＲ　ＴＡＢＬＥＳＰＡＣＥ　ＭＯＶＥで一括移動

・ＲＥＦＲＥＳＨ　ＭＡＴＥＲＩＡＬＩＺＥＤ　ＶＩＥＷの
　ＣＯＮＣＵＲＲＥＮＴＬＹオプション
　　→マテビューにゆにーくインデックス必要

・ＡＬＴＥＲ　ＴＡＢＬＥのロック競合

●レポート形式の資料
「PostgreSQL9.4に関する検証報告」
SRA OSS 日本支社→技術情報→PostgreSQL

ＪＳＯＮＢのクラス
　今日現在、いいのはない

アプリに使うときの指針

カラムとの比較

タスクフォース人材、軍師型知財人材の育成

ちょっと毛色ちがうけど、「デザイン・ドリブン・イノベーション」には
デザイン思考もでてくるからということで・・
さっき（９月１１日）「東京大学　新ビジネス塾」に
言ってきて、話聞いてきたので、メモメモ

---

・来年度の構想
・一部を実証プログラム
・３回のうち１回
　　今回、オープンクローズ戦略
　　来週、詳しく説明

---

■軍師型知財人材の育成
（小川先生）

３つからなりたつ
・日本経済が抱える基本問題
・軍師型知財人材がなぜ必要か
・チームとして

国際貿易から見た日本経済の成り立ち
貿易収支＝輸出－輸入　輸出の９６％が製造業：グローバル市場と戦えないと・・

ドイツは小規模企業の輸出力で蘇った
ドイツ：統合で赤字
２００１年から良い方向
→赤字国債を発行しなくても良いように

全く違うメカニズム

アベノミクスによって企業人のマインドが好転
・ＲＯＥを高くしよう＝稼ぐ力
　　→なにをすればいいの？
　　→国内でものづくり
・実体経済と乖離した実効為替レート
　　→海外にいっちゃう
・特許をいっぱい出しなさい→出しても？

日本からアジア地域へ移転した日本企業の生産拠点数
国内製造業の雇用変化と工場立地面積変化
　　→同じ形
工場は、地方にある
最終品の工場原価に対する輸入品比率　輸出品比率との関係
政策乖離→工場出て行く→地方に工場なくなる→都会へ
地方の人口減：第三次

プロダクトイノベーションの成果を国内に残すことのできない知的財産思想
→１００年に一度という産業構造変化
　なせ、電機だけで起きたか？産業によって違う

ソフトウェアリッチ型に転換した製品（デジタル化）が
産業構造をビジネス・エコシステム型に変えた
→グローバルな分業型
　航空機産業

太陽光発電もビジネス・エコシステム型に変わると
グローバル市場の競争ルールが全く変わってしまう
→特定のレイヤしかやらない

このときの知的財産の出し方は？

なぜ、日本企業が勝てなくなるのか
・技術は国境を越える
・製造業が弱くなったのではない
　　売上高間接費
・何をやれば・・・

１９８０年代初期から２０１０年代まで
　　→自動車、ロボット、間違いなく来る
　　　医薬品、石油化学も兆候

オープンクローズ
・利益ないと雇えない
・独占がないと会社なりたたない。
　　→経済学は独占ない状態で考えている
　自由競争と独占の両方がないと

２．なぜ軍師型の知財人財が必要なのか
　　コア領域と公開する部分
　　エコシステムを持たせる部分

・インド、中国市場

自社優位に競争ルールを事前設計しよう
コネクテッドカー
先手を打つ
知財をどうするか

２００兆円つぎこんで、製造業は従業員を減らしている
守るところとまもらないところ
オープンクローズ

国家プロジェクトの知財マネジメント
・精密高分子
いままでは、おなじ業種でやってしまう
カーボンナノチューブ：中国つよい

グローバル市場の価値を引き寄せること可能
伸びゆく手
構造を作る：特許は数ではない

完成品が主導する伸び行く手形成の基本モデル
つなぐメカニズムをどうするか？
オープンクローズ
　完成品と部品ではちがう

インダストリ４．０
→付加価値とは？

チーム軍師を育成

知的財産のメカニズム
企業収益、貿易収支、経常収支
オープンイノベーション→オープンアンドクローズ
→イノベーションのやりかたの違い

---

■タスクフォース人材
（各務先生）

代表する企業
・日本：戦中戦後
・アメリカ：若い会社がある

時価総額を、どう理解するか
ＩＢＭ：メインフレーム→サービス・コンサルティング
　ジョン・エーカーズ→ガースナー：基礎研究所解体、業態転換
　１０年単位で経営
ＧＥ：業態変わっている
　ジャックウェルチ：Ｍ＆Ａ
　Ｇｏｏｇｌｅも買っている

・Ｍ＆Ａをどうやれるか、
・ぽすと、アクイジッションの問題
→改革を起こす二代目になっている
　海外会社：自分の色に染める
ＲＯＥ：アメリカ２０％、日本５～８％

自前式から、いかに変えられるか？

オープンイノベーション
東京大学→１６２２件：共同研究→共願特許３００→でも製品は？
研究所からラインにあげる方法がない
研究者にイノベーションマインドがない
企業研究者：稟議を上げるリンクがない
→人材に重きを置いた、産学連携

---

■デザイン・ドリブン・イノベーション
(杉光先生）

　　テクノロジープッシュ
　　マーケットプル
　デザインドリブンは、テクノロジープッシュと交わるが、
　マーケットプルではない。

ロベルトベルナンティ「デザイン・ドリブン・イノベーション」

・製品を通じて、従来の常識とは異質の快い体験を顧客に提案し、
　新たな市場を創り出すこと

Ｗｉｉ：
　マーケットの声をきいたわけではない
　新しい提案
　ブルーウォーシャン戦略；かさなっている

類似概念
・ブルーウォーシャン
　経験価値マーケティング

どうやって、実践するの？
・デザイン思考→ＩＤＥＯ：ブレインストーミング
・デザインディスコース→ベルガンティ：ブレインストーミング否定
→考え方違い

デザインディスコース
・あらたな体験の提案：研究のプロセス
　　→ユーザーの声は聞かない
課題
（１）解釈者の見つけ方→つながっているとこと
（２）数週間から数ヶ月研究プロセス
（３）解釈者をかえるとき
（４）アウトプットのシェア：上手くコントロールできる？（契約）
→リーダーシップ

---

タスクフォース人材
・事前設計をしろ
・今日の内容は１層目、２層目、３層目のどれ？
　１層目からやる予定だが、３層目からやる方法も。

・タスクフォース人材に求められる人ちがう
　→フィードバックされていない

１０月２５日からの実証プログラムの紹介