こいつに、テキトーなデータを食わせると、どんな解析がいいか教えてくれるんだって！

金曜日、　トップエスイー「ビッグデータイブニングセミナー」に行ってきた！

前回は、NECだったけど、今回は、富士通！

競争優位を生み出すビッグデータ利活用技術とその応用
株式会社　富士通研究所
ソーシャルイノベーション研究所第二ソリューション研究部
の、昔、テキストマイニングしてた人

の講演をメモメモ。

なお、表題の「こいつに、テキトーなデータを食わせると、どんな解析がいいか教えてくれるんだって！」を知りたい人は、最後のほうにある、「データから分析シナリオを絞り込む」から見てください。

---

分析技術とその応用

富士通の考える未来像
・ヒューマンセントリック・インテリジェントソサエティの実現
　　ビッグデータ利活用技術

１．ビッグデータ
　３V
　　　アメダス
　　　Cバンドレーダー
　　　XバンドMPレーダー：アメダスの１０万倍→ビッグデータ

IDCによるビッグデータの定義

ビッグデータビジネスの動向
　　どこからどこまで？→数字は分かれている
　　ITロードマップ：３段階
　　　　活用できていなかった
　　　　異業種
　　　　センサー・社会インフラ
　富士通：今後の柱

ビッグデータに対する認知度
　２０１１から２０１２で認知度向上
　情報システム部：関心
　現場：まだまだ
　多くの企業は、バズワードとみている

・ビッグデータで何がうれしいのか？
　→イメージわかない、投資対効果
　　提案力が鍵

富士通研究所のビッグデータの取り組み
データ収集：メディア、プライバシーの話
データ処理：Hadoop,CEP
分析：
活用

ビッグデータ利活用技術
　データと目的・価値を結びつきえる技術
　従来：活用できるデータが足りない
　現在：活用しきれていないデータが増加

データ分析技術の適用イメージ
　　過去の分析
　　現在の監視
　　未来の予測

過去の分析の実現イメージ
　　事象の発生パターン、特徴、シナリオ
　　　予防型リスクマネジメント
　　　運行情報活用

現在の監視
　　過去事例から抽出・構築した
　　　災害発生検知

未来の予測
　　説明的→予測的
　　　ヒット予測・・

過去の分析
　予防型リスク管理
　　　リスクマイニング技術
　　　　　品質、安全性のトラブル：現場では分かっていた
　　　　　　→ヒヤリハット、ニアミス：ハインリヒの法則
　　　　　トラブルレポート
　　　　　　　何回も起こる：対応が間違えている？
　　　対応の優先、内容の変化
　　　トラブルレポートの例：交通事故
　　　　　定型項目と非定型項目で出来ている
　　　　　なぜなぜ分析をやらなくても、経過でわかる
　リスクマイニングのコア技術
　　　　テキストマイニング
　　　　リスクシナリオ分析：イベント連鎖モデル
　　　　センサーデータ活用
　テキストマイニング技術
　　　形態素解析
　　　かかりうけ解析
　　　統計処理
　　　共起関係集計
　　　分析・可視化（概念マップ、クラスタリング）
　　　　→テキストデータのトップダウン分析
　イベント連鎖（順序ある）
　　リスクシナリオ分析
　　　　分種別の判定
　　　　格フレームの抽出
　　　　イベント抽出
　　　　順序関係の抽出
　統合マイニング
　　　テキストと数値データを組み合わせ
　　　　定量的な因果モデル
　　　トラブルレポート：正常が書いていない
　　センサーデータを取っておく
　　マニュアル・手順書
　　→情報大航海プロジェクト　JALと実証実験
　センサーデータ活用
　　テキスト＋数値データから定量的な因果モデル
　　　　微妙なタイミング、微妙な操作量
　　車載端末情報からのドライバモデル抽出
　　　　でじたこ（でじたるたこめーたー）

　ビッグデータ：非構造

現在の監視
　複合データ分析による災害検知
　　XバンドMPレーダーの雨量データとTwitter
　　Twitterを人間センサーに
　　　GPS情報→ランドマーク→市区町村レベルで推測
　　　伝聞情報の排除

未来の予測
・テキストデータの予測
　　　専門家、非専門家
　　　専門家の予測はサルにも劣る
　　　　http://www.asukashinsha.co.jp/book/b101697.html

　長期的予測は難しい：バタフライ効果
　　人間、社会の予測難しい
　　　→AKB総選挙をあてることはできないか？

　商品ライフサイクル
　　　売り上げ予測→ソーシャルメディア
　　　前評判；機械学習

　電子機器のヒット予測
　　　何を作ったら売れるか？

　未充足ニーズ
　　デルファイ法
　　Twitter
　　問いかけをしないで集める

　商品観察
　　アンケート
　　グループインタビュー
　　ソーシャルでは分からない

　ユーザー属性推定
　　書き込み内容から推定：機械学習
　行動表現解析技術
　　行動表現抽出辞書

　どんな人分析
　　属性ごとの特徴分析
　　どうして分析（行動の詳細分析）

未来の予測２：センサーデータを利用
　　故障・生涯の予測、予兆検知
　　・故障予測に基づき、予防保全のコストを最小化
　　　リスク低減とコスト削減
　　　個体の予測
　　　　　マクロ→マイクロ
　　　いろんなセンサーで故障予測分析
　　　　　部品寿命を予測：生存時間解析
　　故障予測、予兆検知：いろいろはいっている
　　　異常検知
　　　予兆検知
　　　確率的予測
　　　故障メカニズムの分析
　　　保全計画の最適化

　予兆検知：イベントログ
　　　メッセージを分類
　　　　スライディングウィンドウで
　　　数値データを利用（モデル作成→モデル適用）

　確率的予測
　　　発生リスクと期間をモデル化

　→過去に起きたことの繰り返しパターン

未来の予測３シミュレーション
　広域道路交通シミュレーター
　　　最近やってない

最適化と制御
　・ビッグデータ利活用に対する期待
　　　　未来を知りたい
　　　　意思決定を最適化

運用イメージ
　　異常検知、故障予測
　　電力の効率的利用
　　オフィスの電力マネジメント→ピークシフト

オープンデータの利用
　　LOD活用基盤
　　まだぴんとこない
　　アメリカ：おばまさんビッグデータを第４の柱に
　ビッグデータ：どこにあるんだっけ？
　そこで問題：公開すれば使えるの？
　　→LOD；オープンデータのネットワーク
　　　　　セマンティックWebとも近い話
　　リンク自動的にはるとか
　ゆくゆくこういう時代

分析シナリオの自動推薦
　　データサイエンティストみたいな話
　　　→スーパーな人がいない
　　専門家の知識の再利用

インテリジェントプラットフォーム
　　テンプレートの再利用
　　　ビジュアルプログラミング的にできる
　　　設計する人は、はじめは専門家
　Rつくったのって、埋もれてるよね！
　　残していきましょうよ
　　他の人は再利用できる？

　データから分析シナリオを絞り込む
　　足りない情報を出す
　　抽象化して、テンプレート

　　http://jp.fujitsu.com/journal/strength/technologies/201212.html

　データモデルは作れる？
　　こういう仕組みは成り立つ
　　データサイエンティストが毎回行かないといけないのか？

　Interstage Business Analyics Modeling Serverの拡張機能として実用化

（分析知識の再利用）

FUJITSU Big Data Initiativeセンター
オファリングメニュー

開発について
　最近だと、ソフトウェア地図

「社会福祉援助の展開過程」からみた、ソフトウェア開発の進む道（１）

今、NHKのラジオ「社会福祉セミナー」の「社会福祉援助の展開過程」
をきいていたのですが、この「環境モデル」から「物語モデル」が
今後のソフトウェア業界の方向に大きく関係しそうなので、
まずは、今の番組の内容をメモメモ

---

■援助
援助対象、援助方法、援助関係

援助活動の特徴
・日常生活に支障がある状況

日常生活
２つの軸：個人的－環境的、主観的－客観的

による４つの領域
　個人的側面：
　環境的側面：日常生活
　物語的側面：人生
　文化的側面：（常識、偏見）

４つの領域→援助異なる
　個人的側面：個人モデル→医療
　環境的側面：環境モデル→社会福祉　そのままでいい
　物語的・文化的側面：マニュアルX

　・主観的は変わりにくい

■環境モデルを例に
　　開始から終結を４段階：循環的

・開始段階：
　　申請
　　紹介（依頼）
　　出向援助（アウトリーチ）
　
・アセスメント（事前評価）
　　アセスメント表
　　社会資源、長所、意欲の確認
　　さまざまな制度；資格要件
　　→目標の明確化

・援助計画の作成
　　実施方法、機関
　　成果・費用の明確化
　　近隣、ボランティアの活用
　　関係者会議
　→状態、ニーズの変化：あらためて作成

・援助計画の実施
　　クライエントが自由に精勤選べる
　　ワーカーが支援
　　ワーカーがかわりにする

・モニタリング
　　計画通り？トラブルない？の評価
　　→援助による直接効果は計りにくい
　　→満足しているかどうか
　　→生活の質の変化
（→アセスメントに戻って循環）

・終結
　　一定期間はアフターケア
　　フォローアップ

■物語モデルを例に
　環境モデルが主→クライエント・家族→物語をきいていく

　こうすれば、こうなるというマニュアルがない！

　物語の書き換え：予想つかない
　寄り添う、立ち会う

　物語はなぜ書き換わるのか？

・保守的整合性
　　矛盾しない筋立てが望ましい
　　　：人生は、単純な因果では説明できない
　　　　何の因果もないわけでない
　　　　→そこで物語

　　物語は変化しにくい
　　　物語を変える＝生き方を変える・自分を変える

・相互主体的構成
　　物語は聞いてくれないと・・・
　　目の前に人がいて、話を聞いてくれないのに語り続ける：無理
　　　→語る、聞く：語る主体・聞く客体もあるが、
　　　　積極的に聞く主体と、重い口を開く客体もある
　　　　→相互主体

　　理解できるような物語しか聞き取れない
　　　聞き取ってくれそうな人しか語らない：場合によって迎合的
　　→思いつくままに聞ければ、これまで語れなかった出来事も

　　語りを繰り返す中で、整合性が保てない
　　　　　→整合性を保つための書き換え

---

なにが、システム開発に関係するのか？
と思うかもしれない
　　環境モデル：従来の開発
　　物語モデル：アジャイル開発
と考えると、思いもよらないものが見えてくる

今までの開発は環境モデルと同じ
　　→だから、開発と環境モデルの援助が対応する

アジャイルは、物語を作っていく過程なのだよ
（だから、型にはまらない）

もっと詳しく、別エントリで書く

米Microsoft、ブラウザ版無料Officeの「Office Online」を発表

米Microsoftは20日、Webブラウザーから無料でOfficeの主要機能を利用できる「Office Online」を新ドメイン「Office.com」サイトで公開した。Microsoftアカウントがあれば誰でも無料で利用できる。

だそうです

米Microsoft、ブラウザ版無料Officeの「Office Online」を発表
http://internet.watch.impress.co.jp/docs/news/20140221_636298.html

より（太字は上記サイトより引用）

※Microsoftアカウント＝旧 Windows Live ID

サーブレット等で、同一ブラウザでユーザーごとにセッションの中身を替えたい

品質は後付けできる例

１つのブラウザで、複数タブを使った場合、サーバー側では、同一セッションになる。
ということは、

・はじめ、ユーザー名xmldtpでログインしておき、
　その後、新たなタブでウィリアムとログインしても、
　同じセッションが使われる

・はじめ、ユーザー名xmldtpでログインしておき、
　その後、新たなタブでxmldtp（と同名で）ログインした場合、
　　　（１）先にログインしているからエラー
　　　（２）後でログインしたものを優先し、セッションを作り直す
　のどちらもできる。ただし、（２）でセッションを作り直した後に、
　はじめ操作していたタブでアクセスすると（２）で新しいセッション
　になっているのでおかしくなる可能性がある（場合によっては落ちる）

---

■お題

ここで、

xmldtpでログインすると、

のように、アクセス回数とセッションIDを返すプログラムで、
何回もxmldtpでアクセスして

のようになった状態で、

のように、新たなIDでログインすると

のように初期化され

と戻すと

のように前の値を持ってくることを考える

※上記のセッションIDを見ると、みんな同じ。つまり、値は変わっているが、
　同一セッションを使いまわしている

---

■概要

Tomcat7で指定URLのみクッキーを無効に
http://questionbox.jp.msn.com/qa7881678.html

の「ANo.3」に書かれているとおり。つまり、

・Filterに、ハッシュマップをstaticで用意する（＝全体で１個）、
　　→そのハッシュマップには、
　　　　キーはログイン名、値は保存したい値を持っておく

・FilterのdoFilterで、
　　　パラメータから、ログイン名をチェック
　　　上記ハッシュマップに値が入っていたら、その値をセッションに入れる
　　　→ここで、ログイン名ごとに、セッションの値が入れ替わる

・セッションのリスナーで
　　　セッションの値が書き換わったら、上記ハッシュマップの値も書き換え

・セッションが破棄されれたら、上記ハッシュマップのログイン名のデータも破棄

ということをする。

---

■お題に関係ない部分

お題に関係ない、はじめの画面は、こんな感じのJSP(index.jsp)

<html>
<head>
<title>MySession</title>
</head>
<body>
<form method="post" action="kekka.jsp">
login name<input type="text" name="loginName"/>
<input type="submit"/>
</form>
</body>

ここで、ログイン名を入れているので、上記フィルタにより、
noの値がログイン名ごとに入れ替えられ
結果表示のJSP(kekka.jsp)

<%



	int ino;



	String no = (String)session.getAttribute("no");

	if ( no == null )

	{

		ino=0;

	}

	else

	{

		ino = Integer.parseInt(no);

		ino++;

	}

	session.setAttribute("no",String.valueOf(ino));

%>



<%=ino%>

<%=session.getId()%>

にわたる。ここでnoに１足すと、リスナーが呼ばれる。

ここまでは、あまり今回のお題に関係ない

---

■セッションの値を入れ替える部分：フィルタ

フィルタの値を入れ替えるJavaプログラムMyFilter1.javaはこんなかんじ。

package mytomcat1;



import java.io.IOException;

import java.util.HashMap;



import javax.servlet.Filter;

import javax.servlet.FilterChain;

import javax.servlet.FilterConfig;

import javax.servlet.ServletException;

import javax.servlet.ServletRequest;

import javax.servlet.ServletResponse;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;



public class MyFilter1 implements Filter {

	static HashMap<String,String> svdata = new HashMap<String,String>();

	@Override

	public void destroy() {

		// TODO 自動生成されたメソッド・スタブ



	}



	@Override

	public void doFilter(ServletRequest req, ServletResponse res,

			FilterChain chain) throws IOException, ServletException {



		// http://www.javaroad.jp/servletjsp/sj_servlet10.htm

		HttpServletRequest myreq = (HttpServletRequest)req;



		HttpSession session = myreq.getSession();

		String loginName = myreq.getParameter("loginName");



		//	セーブ領域から、データ復元

		if ( loginName != null)

		{

			String no = svdata.get(loginName);

			if ( no == null)

			{

				no = "0";

			}

			session.setAttribute("loginName",loginName);

			session.setAttribute("no", no);

		}



	    chain.doFilter(req, res);



	}



	@Override

	public void init(FilterConfig arg0) throws ServletException {

		// TODO 自動生成されたメソッド・スタブ



	}



}

---

■値が書き換わったとき：リスナー

セッションの値が書き換わったら、セーブしてあるデータも書き換える
MyFilterListener1.javaはこんなかんじ

package mytomcat1;



import javax.servlet.http.HttpSession;

import javax.servlet.http.HttpSessionAttributeListener;

import javax.servlet.http.HttpSessionBindingEvent;

import javax.servlet.http.HttpSessionEvent;

import javax.servlet.http.HttpSessionListener;



public class MyFilterListener1 implements HttpSessionListener,

		HttpSessionAttributeListener {



	@Override

	public void attributeAdded(HttpSessionBindingEvent arg0) {

	}



	@Override

	public void attributeRemoved(HttpSessionBindingEvent arg0) {



	}



	@Override

	public void attributeReplaced(HttpSessionBindingEvent arg0) {

		//	http://www.javaroad.jp/servletjsp/sj_servlet9.htm

		//	セッションが変更されたら、保存しているデータも変更

		HttpSession session =arg0.getSession();

		String loginName = (String)session.getAttribute("loginName");

		String no = (String)session.getAttribute("no");

		if ( loginName != null)

		{

			if ( no == null)

			{

				no = "0";

			}

			MyFilter1.svdata.put(loginName,no);

		}





	}



	@Override

	public void sessionCreated(HttpSessionEvent arg0) {

	}



	@Override

	public void sessionDestroyed(HttpSessionEvent arg0) {



		//	セッションが削除されたら、保存しているデータも削除

		HttpSession session = arg0.getSession();

		String loginName = (String)session.getAttribute("loginName");

		if ( loginName != null)

		{

			MyFilter1.svdata.remove(loginName);

		}

	}



}

---

■web.xml

フィルターとリスナーをweb.xmlに登録する。こんな感じ

<?xml version="1.0" encoding="ISO-8859-1"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"

    version="2.4">

    <display-name>Test Servlet</display-name>

    <description>Test Servlet</description>

    <filter>

	    <filter-name>MyFilter1</filter-name>

    	<filter-class>mytomcat1.MyFilter1</filter-class>

 	 </filter>

	<filter-mapping>

    	<filter-name>MyFilter1</filter-name>

    	<url-pattern>/*</url-pattern>

  	</filter-mapping>



    <listener>

    	<listener-class>mytomcat1.MyFilterListener1</listener-class>

  	</listener>

    <servlet>

        <servlet-name>MyServlet1</servlet-name>

        <servlet-class>MyServlet1</servlet-class>

    </servlet>

    <servlet-mapping>

        <servlet-name>MyServlet1</servlet-name>

        <url-pattern>/MyServlet1</url-pattern>

    </servlet-mapping>

</web-app>

---

■つけたし

(A)以上でできるのだが、これを実行すると

のように、違うブラウザでも、ログイン名が同じだと、同じセッションデータ
を使ってしまう。これはこれでいいかもしれないが、いけない場合、
ログイン名のほかにセッションIDを足したものをキーとすればよい

(B)後がちにするには、保存しているデータに、ログイン時間を持ち、
　　サーバーアクセスする際には、ログイン名とログイン時間を常に
　　パラメータで渡す。ログイン名は一致するが、ログイン時間が一致
　　しない場合は、後からログインされたものとみなして、
　　すぐに終了処理をするなり、セッションにその旨の値を入れる

(C)ユーザーAがログインしたら、B,Cはキャンセルという場合、
　ユーザーAがログインしたら、ハッシュマップのB,Cデータを
　消せば、B,Cがアクセスしたとき、ログインデータをなくせる

(D)これは、排他制御はしていない。したがって、同時アクセスされるとおかしくなる。
　排他制御をするなら、ハッシュマップの（上記のソースだとsvdataの）ログイン名と
　値を直接変更し、その際排他制御をし・・・とかいうと、セッションそのものを
　自作しているのと、なんらかわらない（＾＾；）

---

■いいたいこと

で、いいたいことは、このやりかたでなく、
ユーザーごとにログインしたいとか、(A),(B),(C)のバグ修正
をするとしても、基本的に１を足すというロジック部分は変わっていない
（変わっているのはセッション部分で、主にフィルターとリスナーの中）
つまり、ロジック部分を分離すれば、あとは入出力部分で品質は変えられる。

ユーザーは、ソフトの品質・機能等にお金を払うのではなく、ベネフィット等払うようになったから

デブサミ2014、講演関連資料まとめ
http://codezine.jp/article/detail/7640


というのを見て

「ソフトウェア工学からコンピューターサイエンスへ - 今後のシステムアーキテクチャーに必要な技術的切り口とその裏側」

なんていうのをやっていたのを知った。

もっとも、クスマノが、「ソフトウエア企業の競争戦略」で指摘しているけど
（今、手元に無いので、何ページで指摘しているか忘れた。
　たしかはじめのほう）

　　ヨーロッパ→コンピューターサイエンス
　　日本　　　→ソフトウェア工学
　　アメリカ　→ソフトウェアビジネス

という構図がある。なので、「コンピューターサイエンス」は
もともと脈々と続いていて（計算論、形式仕様、分散技術も？）
ソフトウェア工学が没落したから、コンピューターサイエンスが
目だったってことになるんじゃないかな？

でも、togetterを見ると、「ソフトウェア工学」のdisりが足りないようなので（＾＾；）ここで、「ソフトウェア工学」をdisってみる。

---

■ソフトウェア工学の没落１＜＜現場とアカデミックの乖離＞＞

　まず、ソフトウェア工学というものが、現場で考えているものと、アカデミックでさすものが、かなり違う。

　現場では、フレームワークのよしあしとか、生産性改善のためのツール、品質向上のためのツールをさすを思っているかもしれないけど、そういうことは、アカデミックの議論にはならない。理由は、以下の２点

●フレームワークで生産性向上！ということが難しい。

　極論すると、最近のフレームワークでは生産性も品質も向上しない。
　ZendとCakePHPでどちらが生産性があがるか？とはいえないし、
　そもそも、生産性の基準が難しい。

　たしかに、ステップ数は自動化すれば上がるけど、そのために教育に何ヶ月もかかっていたら、トータルで見たとき、生産性があがっていると、いえるのか？


●最近のツールには、新規性が、実はない。

　高速開発とかいうが、それって、Railsと、どう違うの？
　いろんなフレームワークが生まれてるけど、それって既存のフレームワークの方言程度の違いじゃない？
　ってことを言われると、反論できない。新規性がない。


　そこで、アカデミックでやるとすると、もっとぶっとんだ、

　・要求仕様から、いきなりソースコードを作る、テストも作る
　・テストの要求分析
　・バグの出方から推測される、担当者の性格

　など、現場とは直接関係ない方向に進みつつある。
　(上記のテーマは、たぶん今やれば、最先端）

---

■ソフトウェア工学の没落２＜＜品質・生産性に金を払わない＞＞

　そもそも、ソフトウェア工学というのは、ソフトウェアの品質向上、生産性向上のために行われた学問だが、ユーザーは今、品質向上、生産性向上にはカネを払わない。

　高品質で、適切な納期より、ぼろぼろの品質でも、短期間のほうが求められる。なぜなら、ユーザーは、適切な納期－短納期＝利用期間の差で、莫大な利益を上げられるから。。つまり、ベネフィットを優先する。

　生産性をあげて１０個の無駄なプログラムを作るより、お金になる１個のソフトを作ったほうがいいと考えるようになった。

つまり、品質・生産性に金を払わず、ベネフィットにお金をはらうようになった。こうなると、設計・実装の品質向上、生産性向上は意味が無く、ベネフィットを生み出すビジネスモデルの構築と要求分析になる。

　これは、ソフトウェア工学ではなく、ビジネス（経営学・・・でもないんだよな）である。

---

■没落したソフトウェア工学は、どこに向かうのか→サービスサイエンス

　ということで、ソフトウェア工学は、アカデミック的には、

（１）ユーザーとプログラマ、デザイナー、ビジネス分析者などの
　いろんな人が、いれかわり、たちかわりペアプログラミングして

（２）それらの人が、ビジネスモデルや要求を作った時点で、
　プログラミング、シミュレーションできる

という方向に向かっていると思う。

　（１）については、これを実現するには、昨日書いたフラット型組織が必要となる。開発形態はアジャイル。

　（２）の部分が出来てしまえば、（１）の人たちで、ビジネスモデル作成に専念できる。そこのイメージは、今のIDEOが行っているかんじ・・・つまり、デザイン思考になる。

　そう、今、ソフトウェア工学で大注目なのが、デザイン思考なんです。

　そして、そのビジネスモデルをモデル化し、評価する学問としてサービスサイエンスに注目されている。

　ビジネスモデルが出来れば、そのモデルから自動的に、ビジネスに必要な基本的な部分のソフトウェアを組み上げ、品質は後から必要に応じて足していく。

昔、平鍋さんが

アジャイルの「ライトウィング」と「レフトウィング」
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

というのを書いていたけど、ライトウィングであるソフトウェア工学は、もう新規性が無くなり、今は、レフトウィングが注目されているというかんじでしょうか・・・

---

　なお、上記の話は「アカデミック」な視点が結構入っちゃってる。
　つまり、ビジネス的には、旧態依然とした、ウォーターフォールで生産性・品質を上げたいという話はあるし、今後も続くと思う。

　ただ、いままでは、それが全てだったけど、そこに上記のようなサービスサイエンスが入ってくるという話。

　ただし、フレームワークは、宗教論争はあるけど、設計上の話では、これ以上新しいものは・・・ないかもしれないね・・・

　むしろ、基本的にはソースコード作成部分の生産性は上がっても、覚えるのに時間がかかったり、はまっていく部分が多くなって、全体的には教育から保守まで考えると、生産性が下がっていくんじゃないかなあ？

デザインドリブンイノベーションの理論と実践

昨日、公開セミナー　知的資産経営新ビジネス塾に行ってきて、

第６回　まとめ「デザインドリブンイノベーションの理論と実践」

を聞いてきた。その内容をメモメモ

なお、＜＜先生＞＞は、パネルディスカッションに参加している先生のうちの「だれかの」発言（特定の１人の先生ではない）

---

デザイン
１０年、２０年前の言葉と違う
　　プロダクトデザイン→画面、社会そのもの、人生・・・多様
　　デザインということばの変遷

１回
・デザインドリブンイノベーションをどう見ていくか
　　意味のイノベーション：新しくない、リスクある
　　解釈者に耳を傾ける

２回
・３Ｄプリンタ：ロングテールに向いている？ベンチャー

３回
・神経科学？

４回
・日立デザイン本部：エクスペリエンスデザイン
　　インフラ、ソーシャルイノベーションのツール
　　北九州にIBMで競り負けがきっかけ
　　ニーズを抽出→ニーズはないって言ったほうが・・

５回
・IDEO：戦略コンサルとはずいぶん違う
　　結局元に戻ってしまう

デザインドリブンイノベーションとは何か
そしてその実践はどのように行うのか

　→　技術主導＋意味のイノベーション

どうやって起こしていくか
解釈者との関係性
　→リードユーザーも入っている
　→ユーザーイノベーションも含んでいる？
ベルガンティの本

解釈：ユーザーが手にしたこともないものを
　アンケートしても？

技術の事業化・収益化と技術の応用開拓に及ぼす
技術開示・公開の影響

---

■デジタル時代のデザイン・ブランド戦略

意匠権
アップルVSサムソン
・新聞は特許と書いているけど
　　→デザインパテント
　デザインについての主張をしている
　国によって争点が違う
　　日本では特許
　　→日本と中国は画面デザインを保護していない

・世界中でサムソンが意匠登録
　　はっきりとした戦略

・画像デザイン

・新商標：音とか→法改正

・特許庁がやろうとしても、業界が反発

・大企業ほど甘く見ているのでは？

・デザイン：商品設計そのもの

---

■レビュー

＜＜先生＞＞
・ますますわかんなくなっちゃった？
・解釈者はどこにいるか
　　技術をどこに見せていたか
　　　成功したプロジェクト：自分たちと遠い人にみせたとき
　　　失敗したプロジェクト：同じ会社の上司が最悪
　　技術を誰に見せれば、いいヒントをくれるのか
　　解釈は技術者自身、ヒントは離れた人

　　不確実性、変化を楽しむ
　　他人に対して：共感能力
　　利他性：営利を追及してない、よりよい生活
　　過去の蓄積でなく、未来から現在を見る
　　　自分が作るしかないという覚悟

＜＜先生＞＞
・総括
１．デザインの定義
　　はっきりとした答えは得られなかった
　　キーワード：体験、サービス、ビジネス
　　　表面のデザインをきれいにすることでない
　　　プロダクトデザイナーの処遇になやんでいる
　　→顧客に対する体験の提案
　　スタイリングの意味かいつも、考える必要

２．デザインとイノベーションの関係
　　期待を超える
　　　ポジティブな期待の不一致を高め
　　　ネガティブな期待の不一致を低める
　　いまのマーケティングは向かない
　　　新しい市場を作る
　　　従来の延長線上ではない→異質の市場を作り出す

３．ツール
　　デザインシンキング
　　３Dは？
　　　ラピッドプロトタイピング
　　　　→IDEOは使ってない？

　　アンケートベースではない

　　想定外のことを社内で実行→こまる→リーダーシップ

４．知財
　　スタイリングじゃない：意匠ではない・・・
　　→ユーザーインターフェース：特許

５．その他

＜＜先生＞＞
・３つの疑問
（１）なんで、いまさらデザイン？
　競争環境がきびしくなったから
　　国内：成熟化
　　海外：日本のポジションが、先進国のところ
　プロダクトデザインに収まっていない
　　ユーザーエクスペリエンス

（２）デザインの背後の組織構造
　ブランドに落とし込んでのデザイン
　　これを支える組織構造？
　解釈者が組織構造におさまるか？

　・・・よくわかんなかった・・・

（３）デザインイノベーションの競争戦略
　マーケット側の戦略だが、
　マーケティングではない
　技術サイドでなく、マーケットサイド
　イノベーション論の原点に戻っている
　　→既存技術の結合：デザイン
　イノベーターのジレンマ
　　既存のマーケットに力がある
　　→新マーケットには対応できない
　→デザインイノベーションを大企業がやるのは難しい
　デザインイノベーションの使い方

＜＜先生＞＞
・２０年前のデザインとちがう
　なぜ、今なのか？

　ソフトウェア
　　→モジュールの展開
　　→社会システム→どういうふうに付加価値

　基礎研究やらなくても・・・
　　→あらたな価値経営

　IDEO：別の視点

　サムソン：いいデザインを残した
　　→簡易金型：早くフィードバック
　　→簡単にできるようになった

・日本：新興国が登場してきたとき、
　　どういう技術を残すか
　　→グローバルなビジネスモデルのデザイン

＜＜先生＞＞
・解釈という言葉が出る：感慨ぶかい
　　現象学的解釈主義：探索
　　昔、解釈はキワモノ
　インタープリテーション
　　　ミーニング　アトリビューション
　　　メイク　センス
　→コンセプト
　　正解のない世界に出て行く

　身体知の束縛
　知能知の呪縛

　コンピューターは計算機で勝てるか？
　　→早く正確にを追求しはじめる
　→メディア：もう古い
　→ネットワークサービスのインターフェース

　デザインとプランは違う
　　構想：ビジョン→アクションプラン
　　デザイン：プロジェクションやリフレクション
　　　→ラーニング
　　学習効果：ごがくごしゅう
　　　→サービスサイエンスで話題

デザインの階層
１．スタイリング、可視化される
２．プロダクトデザイン商品企画
３．バリューデザイン：プロダクト＋サービス
４．ビジネスデザイン：コミュニティ、コミュニケーション
５．インダストリアルデザイン：どんな産業
→新価値の付加でなく、置き換え

アップル：わくわくするような価値を創造
　　→そして知財を取得

---

実証研究になじまない
やりにくいはなし・・？
　　技術者を大量に持っている会社がやるポイント

＜＜先生＞＞
　クリステンセン的な解：組織を分ける
　→それ、疑ってる
　　アップルがやったこと、どんどん独裁的、一体化！
　もしかして、ちょっと違う？
　　独裁的な決定ができないこと？

＜＜先生＞＞
　意思決定の話してる
　　　ベンチャー
　ダイソンの扇風機
　日立：デザインドリブンをプロダクトに適用していない

＜＜先生＞＞
　大規模企業が社会を変えている
　トヨタの新興国戦略IMVプロジェクト
　　　TPSのトヨタでない。離れるような組織構造を作っている
　　　ルーチン化：効率いい→新しいところには逆効果

＜＜先生＞＞
日本企業とアップルの違い
　ファイナンス：社内投資家
　　即時この手をうちたい→バジェテング
　　機動的予算：投資部門


＜＜先生＞＞
　デザインイノベーション部を作ったらおわるよね
　ＩＭＶ：商品開発に事業開発をつけていった
　　→普段は発動しない
　大企業でもスイッチが押せれば

＜＜先生＞＞
　３Ｍ：自由な時間→むだを許容する
　アップル：ああやらざるをえなかった？
　本田・ソニー：むだなロボット

＜＜先生＞＞
　意匠法をどうこうすればいいという話でなく
　知財をどうするか

＜＜先生＞＞
　特許庁はいろいろ考えているよ
　知財：守るという意識
　デザインブランド戦略：知財だけではないが、最低のところはちゃんと
　意匠：日本だけ減ってる

＜＜先生＞＞
　日本で出さなくてもＡＳＥＡＮには出したほうがいいことも

＜＜先生＞＞
　法律の専門家が多い。ダイナミックに変えることに賛成でない
　クアルコムは製造業か（知的な）サービス業か？
　ダイキンのエアコン：付加価値はどこ？ソフトウェアにノウハウ
　　サービス化にシフト

＜＜フロアにいた先生＞＞
　知財：ちゃれんじんぐ
　さむそん：変わった２００１年デザイン経営センター１５００人
　　デザイナーが解釈者
　　２００５、６年知財：あきらかに意匠権、デザインパテント、
　　２００７年デザインを知財ツールに
　１０００億円の賠償金：デザインパテント
　　→激動の知財

＜＜某参加者＞＞
　ビジョンを考えろ：スローガンを考える
　ブランドビジョン：わくわく：経験したことがない
　　→できそうだ！
　　　誰も見たことがない絵
　３Ｄプリンター：クラウドに似たようなもの
　　→なにを与えるか：はやくみつける
　アップル：トップダウン
　　会長がばんばんやらないと
　　中小企業の社長さん「明日からやるよ！」
　　　→引っ張っていく人

＜＜会場から＞＞
・・・よくわかりませんでした・・・

＜＜先生＞＞
解釈
　エイジェンシュタイン；モンタージュ論
　嶋口先生：手をたたき、ひざを打つ
　想定外がでたとき、どこまでが想定内か
　　→日本の想定内が狭すぎる

せんでん
　サービス「モノのサービス武装」　東洋経済
　スマートデザイン
　　　いつもの便利、もしものソナエ

＜＜会場から＞＞
意匠登録したほうがいい、裁判したほうがいい

＜＜フロアせんせい＞＞
　戦わないことです！！！！！
　ただし、デザインパテントは使いやすい

プライバシーに関わる情報を隠すにはハッシュ化はいいけど・・・

　さっきの話。ビッグデータを扱うとき、プライバシーに関わる情報は出したくない。そこで、その部分をコード化する。

　このとき、コード化を
　　　暗号で行う、
　　　ハッシュで行う、
　　　コード表をどこかに持っておく
　　　ある規則を決めて変換する
　という方法が考えられる。

　この中で、ハッシュは、たしかにお手軽にできる。

　でも、ハッシュ化する場合、ちゃんとデータクレンジングして、名寄せしたものに対してやるのならいいけど、そうじゃないと、前に書いたように、同一データを違って見てしまったりする。あとで、「おかしい」と気づいても戻せない。

　そもそも、ハッシュだと長くなるので、よくないんだけどね。

IT業界が崩壊するといわれる２０１５年問題って、ネットワーク閉鎖論VS構造的空隙

日経コンピューター２０１４年２月６日号（今来ている号でなく、一つ前の号）

に出ている、（ｐ２３からの）２０１５年問題、つまり

　　２０１５年までは、消費税、マイナンバーとか、仕事いっぱいあるけど、
　　そのあと、急に仕事なくなるよね・・・どうするの？

というお話。

その対応策？として、

　　現在のIT業界の元請け→５次請け？のピラミッド構造を、
　　ユーザーを中心として結び付くフラット構造へ

というお話があるけど・・・

あ～これって、要するに、

　　ネットワーク閉鎖論VS構造的空隙論

だよね！この結論は、もうでている。

---

■ネットワーク閉鎖論による利益構造

　現在のIT業界の元請け→５次請け？のピラミッド構造
の組織が優れているという議論は、ジェームズ・S・コールマン
によって、ネットワーク閉鎖論として、議論されてきた。


ジェームズ・S・コールマン　「人的資本の形成における社会関係資本」
http://kanetaka-doctoral-course.blogspot.jp/2008/04/s.html


のダイヤモンドの卸市場の話とかを、聞いたんじゃないかな？

この場合、ネットワークが閉鎖していて、相互に強く結合しているから
（元請から、５次請けまで、下請け構造という形で系列化されているから）
こそ、利益を生み出すという考え方。

---

■構造的空隙による利益構造

　これに対して、「いやいや、そのような構造だと、いろんなものを
結び付けて新たなものを生み出すときに、問題あるでしょ！」という
のが、構造的空隙論

ロナルド・Ｓ・バート 『競争の社会的構造』――構造的空隙の理論
http://www.shin-yo-sha.co.jp/mokuroku/books/4-7885-1018-9.htm

にあるように、ネットワークが閉鎖してしまうと、情報が流れない。
（構造的空隙が生まれる）。この空隙を弱い紐帯でうめると、
利益をうみだすよだよ！という考え方。

---

■どっちも大事

この２つの考え方、つまり、ネットワーク閉鎖性（コールマン・レント）と
構造的空隙（バート・レント）のどっちが大事か？っていう議論は


ロナルド・S・バート　「社会関係資本をもたらすのは構造的隙間かネットワー

ク閉鎖性か」
http://kanetaka-doctoral-course.blogspot.jp/2008/04/s_13.html

に（以下太字は上記サイトより引用）

構造的な隙間間を橋渡しして仲介することが付加価値を生み出す一方、閉鎖性も

構造的隙間のなかに埋蔵されている価値を実現するために重要な役割を担う。

と書かれているように、結局、どっちも大事なんだよね・・

---

■使い分け、すみわけ

つまり、

バート VS コールマン 議論の論点
http://kanetaka-doctoral-course.blogspot.jp/2008/04/vs.html

にあるように、両方大事なんだけど、どういう風に使い分けるか？
ということが、重要なんだよね。

元請け→５次請けまでの下請け構造はウォーターフォールのような
大規模「開発」にむいている

それに対して・・・と書くと、まるで、フラット型は、
アジャイルに向いていると書きたいんでしょう？
と予測するかもしれないけど、残念でした。

フラット型は、大規模開発に入るまえの、「どうやったらそれを
解けるか」のクリエイティブな要求分析、設計段階に向いている。
小規模開発なら、これで済んでしまい、アジャイルでOKってことになる。

---

２０１５年問題が起こった場合、

・フラット型で受注を興す（ここで構造的空隙を埋める人が重要）
　　→アジャイルで済んじゃうかも？

・興した受注のうち、大型案件は、今までどおり下請け構造へ
　　（ここでネットワーク閉鎖性）

ということになると思われる。

つまり、受注をどう興すか？が重要で、そこには、いままでの
下請け型ではだめで、フラットな構造の新しい仕組みが必要に
なってくると思われる。

P.S　構造的空隙って、大澤先生の「チャンス発見」の人によるネットワーク版

？

ハッシュ化と暗号化は違う。ハッシュ化（SHA1,MD5)すると、元には戻らない

あ～、私の周りで、ハッシュ化と暗号化の違いが分かってない人が
多く居るので、ここで、はっきりさせておこう

---

■分かってない事例

【事例１】日経コンピューター２０１４年２月２０日号　ｐ６４
動かないコンピューター
厚生労働省
約１６００万人のメタボ検診データを生かせず
入力時に全角／半角が混在し、突合不能に

に対して、全角／半角変換なんて、簡単ジャン！という意見
（記事中に、全角／半角部分含めて「ハッシュ化して」IDとし、
　それを突合していると明確に書かれているし、図まで付いている）

【事例２】ある日のこと
　このSHA1の復号化はやいですね。瞬時に、もとのパスワードを
　返してきますよ！

・・・なわきゃーない（＾＾；）

---

■ハッシュ化と暗号化の違い

まず、ハッシュ化とは、入力値をハッシュ関数を使って変換することだが、そのハッシュ関数は

http://e-words.jp/w/E3838FE38383E382B7E383A5E996A2E695B0.html

にあるように（以下太字は、上記サイトより引用。赤字はウィリアムのいたずらが振りました）

与えられた原文から固定長の疑似乱数を生成する演算手法。生成した値は「ハッシュ値」と呼ばれる。「要約関数」「メッセージダイジェスト」とも呼ばれる。通信回線を通じてデータを送受信する際に、経路の両端でデータのハッシュ値を求めて両者を比較すれば、データが通信途中で改ざんされていないか調べることができる。不可逆な一方向関数を含むため、ハッシュ値から原文を再現することはできず、また同じハッシュ値を持つ異なるデータを作成することは極めて困難である。通信の暗号化の補助や、ユーザ認証やデジタル署名などに応用されている。


つまり、ハッシュ化されたものから、元へは「戻らない」
ハッシュ関数としては、SHA1,MD5などがある

一方、暗号化されたものは、復号化すると、元に戻る。

ハッシュの場合は、以下のようにして、同じかどうか確認する

（１）元の値をハッシュ化する
　　　例：パスワードを登録する場合、登録したパスワードを
　　　　　ハッシュ化して（例：saltつきsha1)それを、保存する

（２）調べたい値をハッシュ化する
　　　例：今、ログインしてパスワードが入力され、
　　　　　それが登録されたものと一致しているか調べたい場合、
　　　　　登録してあるハッシュ化されたパスワードは
　　　　　　復元できないので
　　　　　今調べたいパスワードも、同様にハッシュ化して

（３）（１）と（２）のハッシュ化した結果が一致するか確認する

---

■事例１について

全角／半角変換なんて、簡単ジャン！という人は、

（１）全角のハッシュ化されたIDを元に戻して、
（２）その全角部分を半角に直して、
（３）それを再度ハッシュ化すれば、突合できる

と考えているのかもしれないが、（２）は出来ても、
（１）はハッシュ化しているので、上記理由により不可能。

つまり、ｐ６６にあるように、元のデータを全角なり、
半角なりに合わせて、もう一度ハッシュ値を作り直さないと
いけない。

これって、膨大なレセプトないしは特定検診データの
生データを変換することになるから・・・できるのか？
っていう話になる（もう、そのデータが捨てられていたら、
復元できない）

---

■事例２

SHA1のハッシュ値から、もとのパスワードは作れない。
（作れたら、それはそれで、やばいでしょ)
たぶん、もとのパスワードをDBで持っていて、SHA1で毎回作っているか、
（SHA1変換はここの途中に書かれているように比較的早い）
DBにSHA1のハッシュと、もとのパスワード両方持っている。

---

わかりましたかあ？

このへんが分からないと、SHA1からSHA2への移行の大変さがわからない
（つまり、SHA1でハッシュ化されたデータを戻して
　SHA2に置き換えるということが、できないのだよ・・・）

P.S　それと、この事例は、ビッグデータにも関係する。
　　　それは長くなるから、また今度にしよう。



【２０１６年３月１６日追加】

　なお、SHA1ハッシュ値から元の値を求めるサイトがあり、Google検索すると、そのサイトがひっかかるため、
元の値がわかることがあるが、それは、復号化しているのではなく、元の値とSHA1ハッシュ値をDBに持っていて、
そのDBを検索している。詳しくは、以下を参照のこと

SHA1ハッシュ値から、もとの言葉を教えてくれるサイト
http://blog.goo.ne.jp/xmldtp/e/c656e55f4bdcace48e60a0d33dd53308

リンク先に、後から情報を載せるJQuery

デブサミ２０１４の

【14-B-2】グリーを支えるデータ分析基盤の過去と現在
http://www.slideshare.net/devsumi/14b2

の２１シート目

おお、これ「かわゆい」作ってみましょう！

---

■お題

あるサイトをみると、リンク先に、アクセス遷移結果などが
でるというもの。
つまり、

と外部にたいしては表示しているけど、
社内では

のように、遷移したパーセントが見えるというもの。

---

■前提

・あるページに対して、すべてのリンク先と、遷移したパーセントを
　JSON形式で返すWebAPIなり、データファイルなりがあるとする。

　たとえば、今、ページのIDが１２３だとすると、

　data123.txt

　というファイルの中に、

{
	"http://www.yahoo.co.jp": "23.4%",
	"http://www.google.co.jp": "76.6%"
}  

のように、ページID123のページ内で、Aタグで書かれているリンク先URLと
遷移したパーセントをJSON形式で書いてある。

なお、ブラウザはIE7

---

■やることの概要

（１）上述のリンク先とパーセントを返すサイトにAJAXでアクセスする

（２）その結果を受け取ったら、
　　　　$.each($("A"),function () {
　　　で、すべてのリンク先に対して
　　　　　　２－１　リンク先URLを取得し
　　　　　　２－２　位置を取得し
　　　　　　２－３　$(this).offset()で、絶対位置を取得
　　　　　　２－４　DIVタグで書き出す。そのとき、
　　　　　　　　読み込みデータ[リンク先URL]　
　　　　　　　　で、書き出すパーセントが取得できる。

（３）表示用に、適当にCSSを作って、クラス設定しておく

---

■ソースファイル

こんなかんじ

<!doctype html>

<HTML>

<head>

<style type="text/css">

.mymsg {

	background: yellow;

	opacity:0.8;

	filter: alpha(opacity=80);

	z-index:100;

	position:fixed;

}

</style>

<script src="http://code.jquery.com/jquery-1.9.1.js"></script>

<script>

mydataurl="data123.txt";

$(function(){

	$.ajax({

  		type: "POST",

   		url: mydataurl,

		dataType:"json",

		success: function(msg){

			draw_msg(msg);

		},

		error: function(XMLHttpRequest, textStatus, errorThrown){

			msg="--- Error Status ---";

			msg=msg+"\n"+"status:"+XMLHttpRequest.status;

			msg=msg+"\n"+"statusText:"+XMLHttpRequest.statusText;

			msg=msg+"\n"+"textStatus:"+textStatus;

			msg=msg+"\n"+"errorThrown:"+errorThrown;

			alert(msg);

		}

	});

});



function draw_msg(msg)

{



  $.each($("A"),function () {

	myurl=$(this).attr("HREF");

	myoffset=$(this).offset()

	toppos=myoffset.top;

	leftpos=myoffset.left;

	mystyle ="top:"+toppos+"px;left:"+leftpos+"px;";

	buf= "<DIV class='mymsg' style='"+mystyle+"'><B>"+msg[myurl]+"</B></DIV>";

	$(this).prepend(buf);

  });

} 



</script>

</head>

<body>



<A HREF="http://www.yahoo.co.jp"><B>やふー</B></A>

<A HREF="http://www.google.co.jp"><B>ぐーぐる</B></A>

</body>

</html>

---

■ちなみに・・・

これだと、常に出てしまうので、

<script>
mydataurl="data123.txt";

以下の、関数をかいてあるところを

<script>
mydataurl="data123.txt";
</script>
<script src="mymsg.js"></script>

のように、mymsg.jsという別ファイルに追い出し、

・外部に公開するときにはmymsg.jsの中身を空っぽ
　にしておく→ふつうにリンクしか出てこない

・社内で使う場合は、mymsg.jsの中に、scriptタグの中
　$(function(){
　 $.ajax({
　　：
と
　function draw_msg(msg)
　　：
を書いておく

・なお、サイトによって、ajaxでアクセスする先
　mydataurl="data123.txt";
　のdata123.txtが変わる。

・では、あるサイトに、どのようなリンク先があるというのを、
　どうやって登録するのか？

　mymsg.jsに、１回だけ
$.each($("A"),function () {
　　　　URLを取ってきたら、
　　　　AJAXで、サーバーのリンク先登録APIを呼び出す
　}

　みたいな感じを書けばいい。
　そのプログラムがおわったら、mymsg.jsを上記の
　「社内で使う場合」のものに、置き換える。

品質は、後付けできるか？ → 作りかたによっては、出来ると思う。

日経コンピューター２０１４年２月６日号、９１ページ
「脱出！暗闇プロジェクト」第三回の

セオリー４　品質を後付けしてもよいモジュールを見極める

だが、実は、品質は後付けできる方法がある
（作りかたによっては後付けできる）
その方法と、その証明とまではいかないけど、説明を書いてみる。

---

■まずは、品質とは

というと、ソフトウェア品質特性になる。

ここで、品質特性は、

機能性、信頼性、使用性、効率性、保守性、移植性

になる。機能性のうち、
正確性は、ロジックに依存する部分になる。

しかし、これ以外の、
信頼性を上げる→入出力障害に対応
使用性→ユーザーインターフェース（入出力）
効率性→資源＝入出力＋メモリ、CPU処理
保守性→表示部分＋ロジック部分
移植性→表示部分＋ロジック部分

となる。そこで、
・ロジック部分を分離して、ものすごく移植性が高くする
　　　→簡単な数式で表現する
　　　→または自動生成

すれは、あとは入出力の問題になる。

---

■方針

とすれば、このようにすると、品質を後付けできる。

（１）ロジック部分を、事前条件を満たした場合、
　　ある数式を実行し、結果を返す
　という風にする。このとき、単純な数式で表現し、
　複雑なものは、局所化し、別関数（別メソッド）にする

例
　　　商品金額＝税抜き金額＊（１＋その商品のそのときの消費税）
　　　買い物合計＝総計（商品金額＊購入数）

（２）局所化した別メソッドはあらかじめ、作っておき、テストする

（３）（１）と（２）を単体テストまでして、確認しておく。
　　　→ここで、スピードを確認。
　　　　また、移植性、保守性あるコードで書いているかチェック。

※つまり、この段階では、値を変数にセットする形にしておき、
　画面、DBなど、外部の入出力部分は、まだ作らないし、接続しない


---ここまでが、コア品質。これ以降は、後付けできる-----------------


（４）とりあえず、入出力画面を適当につける
　　ここで、（３）の変数と、入出力画面をつける。
　　フレームワークに組み込み、画面は、コントローラーで接続する。
　　DBは、DAO部分を、O/Rマッパーなどのフレームワークに置き換える

（５）事前条件を満たすように、画面にチェック機能を付ける

（６）DBアクセスのチューニングをする
　　　DBのセキュリティ向上

（７）UIを装飾したり、移植性を高める
　　　画面のセキュリティ向上

（８）実際のセッションを使うのでなければ、ここで中間メモリに置き換える
　　　などする

（９）暗号化など

（１０）（４）～（９）を、満足のいく品質まで繰り返す、ないしは
　　どこかを重点的に行う。

---

■つまり、

機能ロジック部分が出来てしまい、これが入出力と疎な関係に
つなげてあれば（ラッパーをかぶせて、ラッパーを呼び出すようにする）
入出力部分の品質は、後付けできる。

ただし、仮にフレームワークを使っても、
ロジック部分と入出力部分が密な関係に成っていると
（モデルから、DBを直接JDBCのクラスを使って呼び出しているような場合）
ロジックに手をいれないといけないので、後付けはむずかしい。

Excel活用テクニック～知っ得・まとめ～

あとで見る。

特大ボリュームで送る便利技まとめ　Excel活用テクニック～知っ得・まとめ～
http://itlifehack.jp/archives/8258111.html

たしかに、マイグレーションのチェックシステムは必要だよね！

NTT R＆Dフォーラムであった、TUBAMEというオープンソースのシステム、


TUBAME
http://tubame.github.io/migration-tool/index_ja.html


これは、（以下太字は、上記サイトより引用）

商用APサーバからJBoss、またはJBoss同士のマイグレーション時に必要な修正箇所の抽出や修正工数の算出ができるツール


とのこと。つまり、移植するとき、ソースコードと設定ファイルを入れると

（１）どこを修正するべきか
（２）どうやって修正するべきか
（３）どのくらいの工数がかかるか

をナレッジベースから検索して教えてくれるシステムらしい。

（３）は、オープンにされても。。。ってことはあるけど、
（１）、（２）、特に（１）は、公開して、みんなで利用／追加できるようにするといいよね！
たとえば、Tomcat6からTomcat７に移行したい、TomcatからJavaEEに移行したい
というとき、どういうことが必要になるのかというのは、
みんなが、必要な情報なので、
こういうマイグレーションのチェックシステムは、必要だよね。

SRAとかNRIとか、公開して、やんないんですかねえ？
（（１）を公開して、（２）、（３）を有償にすればよい）

データサイエンティストを雇っても、ビッグデータの半分しか活用していない

ビッグメディアの探索と活用で言われているように、ビッグデータの利用方法には２種類ある

１つは、分析、学習などにビッグデータを利用する方法。
分析をすると、統計を利用することになるので、
一般的には、平均値が得られる。
学習の場合も、基本的に、まれにしか起こらないものは学習されない。

なので、結果

　　夏にはサンダルが売れ、冬には、ブーツが売れる

という結果になる。


もう一つは、蓄積して、探索する方法
異常値があったとき、同じ事例を探す。
たとえば、

　　夏にはサンダルが売れ、冬には、ブーツが売れる
　　けど、
　　夏にブーツが売れるケース、冬にサンダルが売れるケースは？

と検索し、その特殊ケースの特徴を探る。

前者の「分析・学習」に、データサイエンティストを利用するわけだが、
もともと、統計学を利用するなら、データを多量にあつめなくても、
全数調査しなくてもいいわけだ。
学習も、当たり前のことなら、わかっているので、ロジックで組んだほうが早い

一方、「蓄積して、探索する」場合は、例外的なことを探すので、
大量にデータを集めないと、例外が集まらない。
なので、データを多量に集めることには意義がある。

データサイエンティストを雇って・・・というのは
「分析・学習」をさせる方法であり、
「蓄積して、探索する」ほうを使っていない
（「蓄積して、探索する」方法は、例外事象を検索するだけだから、
　検索知識さえあれば、BIでできる）
そして、「分析・学習」では、ビッグデータを集めても、
そこまでしなくても得られる統計上の知識しか得られない。
→特殊な事例こそ、お金になりやすいので、あまり役立たない。
　　　例：「夏にはサンダルが売れ、冬には、ブーツが売れる」
　　　という情報より、夏にブーツが売れるわけのほうが重要

ということは、

データサイエンティストを雇っても、ビッグデータの半分
（分析・学習）しか活用していないことになる。

NTT R＆Dフォーラム２０１４に行ってきて・・・

そのほか、NTT R＆Dフォーラム２０１４について

■展示について概要
　去年は、ビッグデータとSDN(Openflow）関係が多かったけど、
今年はそんな感じではなく、ネットワークはWiFiとか５Gとか
ありましたね。

　ビッグデータは、「ビッグデータですう！」というそのもの
より、「あなたのこと、あなたのやりたいことを理解します」
のような、ビッグデータを使って、どうよ・・といった、
応用例とおもえるようなものが、出てましたね。

　なんか、ウエアラブル生体センサが派手でしたね・・

　ソフト関係は、「Webアプリケーションのテスト全自動化技術」のほか、
マイグレーション検討を効率化する支援ツール「TUBAME」と
PosgreSQLでシャーディングするPostgres-XCなんかが出てました。
TUBAMEは、ちょっと面白いので、別エントリーとして、あとで取り上げる予定。


　あと、クラウド関係では、分散ストレージのSheepdogさん、
OpenStackを使ってハイブリッドクラウド、
「あなたのそばに・・・LittleCloud 」などなど・・

あとは、基礎的な、量子、ナノデバイスなどなど・・・
って感じですかね・・・

---

■R＆D

　いくと、ガイドブックのほかに、「R＆D」というNTTの研究所紹介
のパンフレットをもらう。
　そのパンフレットの中の２０１３年と２０１４年の主な違いは、
こんなかんじ

・２０１４年の冊子には、NTT Innovation Institute Inc(北米の研究所）
　のチラシが１枚入っている

・２０１３年の「プロデュース活用事例」
　　クラウド
　　ひかりLivingサービス
　　医療健康共通サービス基盤
　　スマートホーム（HEMS）
　のページが、２０１４年では、最先端研究センター
　　機械学習・データ科学センター
　　イノベイティブフォトニックネットワークセンター
　　ナノフォトニックセンター
　の紹介に変わっている

・コミュニケーションサービス２０１３年は、
　　代表的な研究分野の３番目
　　クラウド基盤、オープンソフトウェア、ソフトウェア工学
　が、２０１４年は
　　クラウド基盤、OSSサポート、ソフトウェア開発技術
　とし、説明文もTCO削減と、具体的な記述になっている
　　

・コミュニケーションサービス２０１３年は、
　　高臨場感映像音声通信
　の紹介が、２０１４年は
　　雑音下でも強い音声認識、音声合成技術
　　秘密分散、秘密計算
　に変わっている

・コミュニケーションサービスのクラウド技術関係
　２０１３年と２０１４年では説明文が違い、
　全体像が、明確に示されている。
　（以下にその図を引用）

　全体像の一部にSDNが書かれている
　おお、Swift,sheepdogと同じレベルに（面積的には、小さい？）

・最先端技術の例、２０１３年の
　　デジタルコヒーレント
　　フォトニック結晶
　が２０１４年は
　　次世代無線LANプラットフォーム
　　ウェアラブル電極
　に変わっている。

---

どうした、SDN！

※なお、２０１４年版は

http://www.ntt.co.jp/RD/OFIS/organization/pdf/rd-j.pdf

から入手可能