ビッグデータ分析を超えた先にある、数理と経験を融合するベイズモデル（２）－１

マーケティングの授業、前回の続き
ベイズモデルから

---

ベイズモデル：いろいろあるが、考えていることは
　　・いろんな情報
　　・パラメータも含めて
　　・統計量・推計量：
　　　　点でものを捉える(従来）→分布で考える(ベイズ）
　　　　→通常のアプローチより柔軟

　ベイズモデルの原則：ベイズの定理
　　　３つの分布を考える
　　　　事前分布：パラメータの信念、情報
　　　　尤度：データの確率
　　　　事後分布：データ獲得後

　Ｙ：データ(given)　　尤度　　　事前分布
　Ｐ（θ｜Ｙ）＝　Ｐ（Ｙ｜θ）・Ｐ（θ）
　　　　　　　　　---------------------
　　　　　　　　　　　Ｐ（Ｙ）　→コンスタント＊
　　　　　　　∝Ｐ（Ｙ｜θ）・Ｐ(θ）＝Ｐ（Ｙ,θ）　→同時分布

　＊コンスタント
　　　Ｐ（Ｙ）　＝　∫Ｐ（Ｙ｜θ）Ｐ（θ）dθ　→コンスタント

　　通常の回帰で予測：予測と学習は別プロセス
　　ベイズで予測：学習と予測が同じフレーム

ベイズモデルの構造

・nが人を表現する場合
　　θnは、人毎の推定
　　　　→１０００人なら、１０００個の値・・それを扱うのは無理。
　　　　→分布で考える
　　　　　　　ただし、分布にシバリはある。
　　　　　　　周りにぱらつくというのがP(θn|a）の意味

・nが時点なら
　　　θnは時点パラメータ
　　時点：時間の関係性
　　　　→スタティックとの違い：順序が入れ替わったらＸ

フルベイズ　ＶＳ　エンピリカルベイズ
　a：パラメータのパラメータ（ハイパーパラメータ）の推定の仕方

　　フルベイズ：aもベイズ推定する
　　エンピリカルベイズ：aを最尤法で決める

　　　　
ベイズがなぜ解けるか
　　ｎ＜＜ｐなのに、解ける理由　　確率分布で考えるから
　　　凝ったことをやらない：推定できる
　　　（推定できるのと、使っていいのは違うけど）

ベイズモデル
　　ディターミティスティック：変分ベイズ （モデルによっては近似性能高い）
　　ストキャスティクス（確率）：ＭＣＭＣ法

ＭＣＭＣ法（マルコフチェーン・モンテカルロ）
　実時間でＯＫかは、nの量による→nが大きいとスケールしない
　　スケール：並列計算＝前と従属しないとき
　　ところが
　　ＭＣＭＣ：マルコフチェーン＝前データに従属→スケールしない
　データ数が少ないとき、ＭＣＭＣ強力


事前分布の決め方
（１）主観で決める
　　　　統計の流派は、こんなかんじ
　　　　　　・ベイズ
　　　　　　・頻度論的アプローチ（ネイマン・ピアソン）
　　　　　　・フィッシャー流
　　　　　　・尤度原理
　　　頻度論がひはんしてきたのが、この主観で決めるところ

（２）別の情報源
　　　異種情報統合
　　　メタ分析

（３）自然共役事前分布
　　　　ベイズは、
　　　　　　事前分布、尤度、事後分布
　　　　と３つの分布があるが、
　　　　このうち、事後分布と事前分布を同じ分類系を用いるもの
　　　　例えば；回帰モデルのベイズにおいて、
　　　　　　回帰係数：正規分布
　　　　　　誤差：逆ガンマ
　　　　とするなど
　　　　階層ベイズに多い

（４）平滑化事前分布
　　時系列：状態空間モデル
　　　　ランダムウォーク
　　　Ｚｎ＝Ｚn-1＋Ｖｎ　　　　Ｖｎはノイズ
　　滑らかに動く、階層ベイズと違う


階層ベイズ
　回帰モデルを考える　Ｐ（Ｙn｜θn）
　パラメータ　　　　　Ｐ（θｎ｜a）

つまり、
　　Ｙｎ＝Ｃｎ＋θｎＸｎ＋εｎ

　　θｎ＝α（age)ｎ＋β（sex）ｎ

このとき、α、βは集団共通化する
計算は、尤度の複雑さになる

＜＜フロアからの質問＞＞
　そのときaは、？
回答：
　　a=(α、β、vi）　ここでviは分散
　つまり、aはベクトル

■こらむ
・Ｒはループ計算が遅い
　　→バイトコンパイラー使うと早くなる

・計量的アプローチを行うには３つの知識が必要
　　　　分野の知識
　　　　統計の知識
　　　　プログラム
　　Ｒで、ためしてみることはできる

---

つぎはいよいよ、ＰＯＳ分析へのベイズ応用のはなし。

アプリケーションのクラウド化の進展でサーバの売上が初めて落ち込む

ここ

アプリケーションのクラウド化の進展でサーバの売上が初めて落ち込む
http://jp.techcrunch.com/2013/05/30/20130529server-sales-are-down-as-cloud-apps-abound-at-the-expense-of-ibm-enterprise-giants/

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

サーバの売上は、機種の問題というよりベンダが今直面している問題だ。上位5社の売上は2013Q1で軒並み減少し、ただ一社Dell…x86専門！…だけが14.4%の増加を見た。
RISC/ItaniumのUnixサーバは前年同期比で台数が38.8%減、売上では35.8%減少した。メインフレームは世界全体で売上が3.6%上昇し、相変わらずのしぶとさを見せている。

メインフレームは、今後も安定していくんでしょうね。

クラウドとサーバーの比率はどこかで落ち着くと思います。
でも、問題はそこではなく、社内サーバーも、クラウドと同じく
Ｄｅｌｌとか、安いメーカーから大量購入となってしまう可能性ですね。

そうすると、ＩＢＭや富士通は・・・

日本のSIerの将来と、家電の将来が、重なって見えたり、見えなかったりです・・

　さっき書いたエントリ内で、

　たぶん、日本の新規開発事象は減少する（というか、しているだろう。すでに）。
　保守は増えていくとおもうが、新規開発ほど儲かるものではないので、業界の規模は小さくなっていく。
　この辺のことは、別エントリで書こうと思う。話が長くなりそうだ。


について書いてみる。

---

　この話は、違和感ありありかもしれない。

マイナンバー、運賃１円単位、消費税増税　－　ＩＴ業界はぼろもうけ？
http://blog.goo.ne.jp/xmldtp/e/e1c5b5c8d0246457efa23de178e647b6

　に書いたように、今年後半は、案件目白押しに見えるからである。

　でも、ここで、数年前の家電業界を思い出して欲しい。


　エコポイント制度短縮発表で対象製品の売上が急増
http://kaden.watch.impress.co.jp/docs/news/20101104_404487.html


もうかってましたなあ～、家電業界・・・
これが、今年後半の案件目白押しと重なって見える。
どちらも、官製需要だ。

テレビを見る人が増えたわけじゃない＝コンピューターを使う人が増えたわけではない
どちらも、政府の一時的な政策で需要が増えただけだ・・・

---

　で、いまはどう？


家電量販店市場／2012年は20％減の約7兆円
http://ryutsuu.biz/strategy/d110716.html


家電、大幅減少。シャープ、パナの苦戦をみても、それは読み取れる。
同じ道をSIerがとらないと、いえるだろうか
（いや、言えまい）

---

・・・と思うが、ここに反論があるかもしれない。

コンピューターは、市場を増やせばいいんじゃないか？
ビッグデータとかで・・・

これは、たしかにそうだ。そうなのだが、２つの話題を合成して、
無理に明るくしてしまっている。

・情報システム部市場は、予算が決まっているので伸びない
・情報システム部以外の市場は、まだ立ち上がっていない。

以下、順に見ていこう

---

■情報システム部市場は、予算が決まっているので伸びない

　情報システム部は、コスト部門なので、いくらでもカネを投資していいものではない。
　限界がある。大体、売上の数％だろう。

　ところが、今年はイベントが多すぎる。

　まず、来年に備え、Windows、Officeの買い替え（ＸＰ→８）
　消費税増税（あれば）
　マイナンバー（なんか関連すれば）

　さらに、営業部あたりから

　タブレット、スマホ対応

　そして、

　ＢＹＯＤ対策

　と、ハード＆パッケージソフトで、予算使いすぎてしまうのだ。

　新規ソフト開発には、お金が回らない。
　さらに悪いことに、Windows8をいれたら、操作性がかわるので、これが落ち着くまで、
　あたらしいアプリ開発は控えたいと思うかもしれない。

　ちょっと、SIerさんに、(ハード＆パッケージ以外で）お金が回りそうも無いのだ・・

---

■情報システム部以外の市場は、まだ立ち上がっていない。

　情報システム部以外に売ればいいじゃん！
　たとえば、マーケティング部、営業部にタブレット＆ビッグデータ解析！
　と思うかもしれない。

　しかし、その市場、まだ立ち上がっていない。
　たとえば、ビッグデータ、でお金を儲けるとします。
　どこで、儲けます・・・？情報システム部はだめです。お金ないから。
　マーケティング部にいって、「ビッグデータ、買ってください」って言っても、？？？ですよね。

　要するに、売り方が決まっていない。そこまで成熟していないのです・・
　営業するレベルまで、まだ立ち上がっていないといってよい。

　さっきのオフショアによる海外展開の話もそうで、今の話ではなく、５～１０年後に収益を生み出す話になる。

---

　ということで、今年後半にひょっとすると、大きな仕事の波がくるかもしれないが、その先、仕事が無くなるかもしれない。家電業界がそうであったように。

　仕事がなくなるのに対応するには、保守とか、教育その他サービスなのだが、それはそれで、使う知識が違う。

　実は、この先のかじとりが、難しいのだ・・・

日本のSIerがグローバル展開できなくても、生き残る方法－オフショア先を利用した海外展開

　昨日、「日本のSIerがグローバル展開できないのって、あたりまえだよね！」を書き、日本のSIerは戦略アウトソーシング先として、グローバル企業になるのは、無理と書いた。

　しかし、それは、日本が国内市場にとどまっていてよいということではない。
　たぶん、日本の新規開発事象は減少する（というか、しているだろう。すでに）。
　保守は増えていくとおもうが、新規開発ほど儲かるものではないので、業界の規模は小さくなっていく。
　この辺のことは、別エントリで書こうと思う。話が長くなりそうだ。

---

　ということで、海外の市場を狙わない限り、今の日本のコンピューター業界はやっていけない。
　つまり、いすとりゲームで、会社のイスが無くなった人は、解雇されるという運命・・・ということになる。

　なので、海外市場は狙いたい。
　特に、新興国。ベトナム、インドネシア、ミャンマー、ブラジル、その先にアフリカ・・・

　で、どうやって、この市場を攻めるかというと、
　　アメリカは、戦略アウトソーシング先として、グローバル企業として、これらの市場を攻める
　　日本は、オフショア先を利用した海外展開
　になると思う。

---

　オフショアを、コスト削減のためと見ている人は、今は少ないんじゃないか？
　もし、コスト削減をしたいなら、ニアショアのほうがいい。
　言葉は通じるし、いざとなれば、来てもらうことも簡単にできる。

　オフショアするのは、そのオフショア先が育って、自国の仕事を取ってきて欲しいからではないか？

　具体例のほうがわかりやすいか。
　たとえば、北京富士通とかは、

http://www.fujitsu.com/cn/it/jp/about/subsidiaries/index.html

によると（太字は、上記サイトより引用）

富士通の厳しいソフトウェア開発の基準に従い、グローバルな最新ソフトウェア開発プラットホームやツールを使用して日本からソフトウェア委託開発業務を引受けています。

もあるけど、

中国市場においては、堅実な経営と順調な発展の中から相次いで自社開発ソフトウェアをリリースしております。　また企業システムの経験や中国語ソフトウェア製品の販売と技術サービスを通じて数多くのユーザーを擁しており、好調に業績を伸ばしております。

製造業や流通業のお客様向けのシステム化におきましては、お客様ニーズの分析から、トータルなソリュ-ションのご提案、システム導入作業、関連技術のサポートに至るまで各分野において豊かな経験を積んでおり、大きな成果を挙げております。

というように、中国市場での売り込みもしている。

このように、
　１．海外拠点を作る
　２．そこで、日本から仕事を出して、現地で仕事を覚えてもらう
　３．現地で仕事を探してきてもらい、現地で開発する

そして将来は
　４．現地で仕事を探してもらい、日本に仕事を回してもらう

ということを目指していくのが、オフショアを利用した生きる道なのであろう。
富士通はこの拠点が中国で成功しているが、
いまから拠点作りとなると、中国は、（政治の問題もあるけど、それ以上に、成長率の点から魅力ない。
成長率期待でみると、ベトナム、ミャンマー、インドネシアだろう
（アフリカはまだ早い。ブラジルは主にアメリカのオフショア先なので、日本は食い込みにくいのでは・・）

---

　問題は、日本の上のほうの人が、どう考えるかということだ。
　彼等はアメリカをフォローして儲けてきた。だから、いまだに、グローバル展開しようとしている。

　しかし、時代は変わった。今はダイバーシティの時代。
　多様化された世の中の中で、海外の点と点をつないでいく時代であり、オフショアなどを通じて、現地先の目線で、仕事を取っていくのが重要なのだが、その発想、つまり、アメリカと日本は攻め方が違うという発想に切り替えられるかどうかが重要

・・・なんだが、切り替えられないよね・・・やっぱり・・・

期限切れ後のWinXPは、ネットにつながなければ大丈夫と思われている風潮はないか？

ネットから切ってもだめで、特にOffice2003とか使っていると、マクロウィルス危ないんだけど・・

日経コンピューターの２０１３年５月３０日の３１ページ

頭が痛いＸＰのサポート切れ

なんだけど、最後に「インターネットのアクセスを禁じて社内システムのみ接続を認める」とあるんだけど、
いやいやいや、社内システムのみでも、あぶないでしょ。

---

たとえば、サポート切れ後に、Ｅｘｃｅｌのマクロウィルスができて、
それがメールに添付されて送られてきて、
かならず、開かなきゃいけない状態だったとすると、

社内メールで転送されてくるか、ＵＳＢでコピーしたものを開くことになると思うけど、

サポート切れなんで、Excel2003のパッチは出ていない。
でも、そのファイルは開かなきゃいけないわけで、
開けば、感染するよねえ・・・

メールもしません、ＵＳＢもさしません、外部アクセス一切しません・・・

・・・となったら、今度は、そのパソコン、何のために使っているのか・・・？

---

http://www.microsoft.com/ja-jp/education/eos/default.aspx

に書かれているのは、
(以下太字は上記サイトより引用）

3. パソコンをネットワーク環境から遮断して活用する

インターネットや校内 LAN、USB や CD-ROM などの外部デバイスからアクセスを遮断することで、リスクを軽減することが可能となります。

ってことで、ＬＡＮもＵＳＢもつなげなければ、軽減できるとしか言ってなくて
外部ネットワークにアクセスしなければ大丈夫とは、言っていないんだよね
（表題は、そういうように見えるけど）

---

だから、一番安全なのはＬｉｎｕｘ＋LibreOfficeいれて、
レイアウトくずれたら、ごめんなさいすることじゃないかな？

ルールがいろいろあるときのプログラミング方法

昨日、話になったので、ちょっとメモメモ。

例えば、野球のように、いろいろなルールがあり、
順番に１回から作っていくと、大変なとき
（１３回で引き分けとすると、１３回分作らないといけない）
どうやってプログラミングするかという話。

こういうときは、状態遷移図を描いて考えると思います。

つまり、状態遷移図をかいて、プログラミングとしては

初期状態

終了状態になるまで、以下の処理を実行する
｜
｜　現在ステータスにおける処理
｜
＊－状態のチェック＆次の状態セット

終了状態処理

という具合になると思います。具体的にプログラム例を出して・・

---

■御題

野球のルールを以下のように表しました。

表か、裏か。

で、それぞれ、終了条件があると・・
抜けていたり、おかしかったりするかもしれないけど、
とにかくこれを基に考えましょう（野球のシミュレーターを作りたいわけではないので）。

---

■プログラミング－ルールベースの一般系

mainの部分は、こんなかんじ

public class Game {

	public static void main(String[] args) {
		//	初期処理
		BaseBall b = new BaseBall();
		b.init_set();
		
		//	試合中
		while(b.sts != BaseBall.STS_END)
		{
			//	ゲーム実行
			b.game();

			//	次の状態評価・値セット
			b.hyoka();
		}

		//	試合終了処理
		b.owari();
	}

}

Gameというクラスにしている。これは、野球に限らず、基本的に変わらない部分、
init_setで初期化をして、
終了条件まで
　　game()をして（業務だと、ステータスに応じた処理をして）
　　hyoka()で、評価、次の状態をセットし
owari()で終了処理

---

■プログラミング－野球特化部分

で、野球に特化したクラスを書く。
こんなかんじ

import java.util.*;





public class BaseBall {



	public static final int STS_OMOTE	=	0;

	public static final int STS_URA		=	1;

	public static final int STS_END		=	2;

	

	int	kai			=	0;

	int sts			=	0;	//	表０、裏１、試合終了２

	int	out_count	=	0;

	int	ten 		=	0;

	int	senko_ten	=	0;

	int	koko_ten	=	0;

	Random rnd 		=	new Random();	//	乱数：ゲームに使う

	

	ArrayList<String> senko = new ArrayList<String>(); 

	ArrayList<String> koko = new ArrayList<String>(); 

	

	public void init_set()

	{

		kai 		=	1;			//	１回

		sts			=	STS_OMOTE;	//	表

		out_count 	= 	0;			//	ノーアウト

		ten			=	0;			//	今の回は無得点

		senko_ten	=	0;

		koko_ten	=	0;

	}



	public void game()

	{

		//	点が入ったか？

		if ( rnd.nextInt(2) >= 1 )

		{

			ten++;

		}

		else //	点が入らないときは、アウトになったものとする

 

		{

			out_count ++;

		}

	}

	

	public void hyoka()

	{

		switch(sts)

		{

		case	STS_OMOTE:	//	表のとき

			if ( (out_count == 3) && ( kai == 9 ) && (senko_ten+ten < koko_ten ) )

			{

				senko.add(String.valueOf(ten));

				senko_ten += ten;

				koko.add(String.valueOf("X"));

				sts = STS_END;

				break;

			}

			else if ( (out_count == 3) )

			{

				senko.add(String.valueOf(ten));

				senko_ten += ten;

				sts = STS_URA;

				out_count 	= 	0;	//	ノーアウト

				ten			=	0;	//	今の回は無得点

				break;

			}

			break;

		case	STS_URA:	//	裏のとき

			if ( (out_count == 3) && ( kai == 13 ) )

			{

				koko.add(String.valueOf(ten));

				koko_ten += ten;

				sts 		=	STS_END;

				break;

			}

			else if ( (out_count == 3) && ( kai <= 8 ) )

			{

				koko.add(String.valueOf(ten));

				koko_ten += ten;

				sts 		=	STS_OMOTE;

				out_count 	= 	0;	//	ノーアウト

				ten			=	0;	//	今の回は無得点

				kai++;				//	回数は上がる

				break;

			}

			else if ( (out_count == 3) && ( kai >= 9 ) && ( kai <= 12 ) && (senko_ten == koko_ten+ten ))

			{

				koko.add(String.valueOf(ten));

				koko_ten += ten;

				sts 		=	STS_OMOTE;

				out_count 	= 	0;	//	ノーアウト

				ten			=	0;	//	今の回は無得点

				kai++;				//	回数は上がる

				break;

			}

			else if ( (out_count == 3) && ( kai >= 9 ) && ( kai <= 12 ) && (senko_ten != koko_ten+ten ))

			{

				koko.add(String.valueOf(ten));

				koko_ten 	+= ten;

				sts 		=	STS_END;

				break;

			}

			else if ( ( kai >= 9 ) && ( kai <= 12 ) && (senko_ten < koko_ten+ten ))

			{

				koko.add((String.valueOf(ten)+"X"));

				koko_ten += ten;

				sts 		=	STS_END;

				break;

			}

			break;

		}

	}

	

	public void owari()

	{

		System.out.println("--------------------------------------");

		for(int i = 0 ; i < senko.size();i++)

		{

			System.out.print(senko.get(i) + " | ");

		}

		System.out.println(senko_ten);

		System.out.println("--------------------------------------");

		for(int i = 0 ; i < koko.size();i++)

		{

			System.out.print(koko.get(i) + " | ");

		}

		System.out.println(koko_ten);

		System.out.println("--------------------------------------");



	}

}

BaseBallで
init_setは初期化。これは別にいい
owariも、結果表示。これは、別にいいと思う

game()のところで、処理を書いている。
今回のイベントは、アウトになるか、点が入るかしか
関係ないので、どっちかがおきるように書いた。
もうちょっとまじめにシミュレートするのであれば、
ここをいっぱい書く。

そしてhyoka()
hyokaの書き方は、以下のとおり

１．状態遷移図の状態ごとに、switch文でわける。
　　今回は、表と裏なので、ステータスが、STS_OMOTEとSTS_URAのケースに
　　わかれている

２．その状態から、「外に出て行く線」の条件をif文で並べる

３．if文の中は、ステータスに遷移するステータスをセットして、
　　遷移時の初期化をする。

今回３を明示していないけど、これを明示すると、
ほぼ自動的に、状態遷移図から、プログラムが起こせる
ということは、業務ルールを状態遷移図で表現すれば、
プログラムが起こせるということになる。

日本のSIerがグローバル展開できないのって、あたりまえだよね！

何をいまさら・・・と思ったら、ぜんぜん違う理由が書いてあったので、
ちょっと書いてみる。

日経コンピューター２０１３年５月３０日号の８５ページ

乱反射
１社も残らなかった日本勢

で、（太字は上記記事から引用）

グローバル展開が必須となった日本企業の間で付き合うＩＴ企業
を絞り込むベストストラクチャー計画が進んでおり


最終的には、米国ＩＢＭ，米国アクセンチュア、ＨＰの三社がのこり、
日本が一社も入らなかったという話だが、まあ、当たり前だよな・・・

・・・と思ったら、その理由に

いくらかかるか富士通は顧客に開示し、安心させる
アプローチを取ってきた。その内訳が競合会社に伝わった
場合、競合は富士通より有利な条件を提示しやすくなる


とか、ちょっと本質と外れているんじゃないか
と思えることが書いてあったので、ここに、
個人的な意見を書いてみたいと思う。

日本のSIerは、どこも、絶対、１社もグローバル展開企業の
サポートはできない。

その理由には、すぐに思いつくだけでも３つある。
その理由を書いてみる

---

■理由１：日本のSEは、ローカル、かつ難解な「日本語」しか話せない！

　世界的にスタンダードなのは、今や英語だ。
　だから、グローバル企業で要件をまとめるとしたら、英語
でまとめるしかない。

　でも、日本のSIerに勤めるSEのかなり多く（ほとんどといって良いか？）
は、日本語しかわからない。英語で議論できない。

　だから、グローバルに仕様を検討する会議を開いても、ＳＥさんは、
わからない！

　これじゃあ、用件伝わらないし、翻訳の時間的、費用的なロスもある。
　米国SIerなら、こんな問題はない。

　もう、これだけで、日本のSIerは選ばれず、米国SIerになる。


■理由２：日本のSIerも、コンサルも、グローバルなビジネスを仕掛けられない

　たとえば、ビッグデータは、マッキンゼーが仕掛けたと考えられている。

　Big data: The next frontier for innovation, competition, and productivity
http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation

のレポートだ。

このように、グローバルにビジネスを興すことが、日本のSIerやコンサルはできない。
日本のコンサル、例えば船井とか、タナベ経営とかは、日本国内のビジネスのコンサルであり、
海外のビジネスは興さない。
日本の総研は、調べるだけで、ビジネスを興すことはしない。

だから、グローバルな戦略アウトソーシングをしようとしても、戦略の部分が立てられない（＾＾；）
戦略は、どこか米国のコンサルの考え方をまねるしかない。

だったら、米国のコンサル、アクセンチュアやマッキンゼー、ガートナーとかと組んだほうがはやい。

■理由３：所詮、日本のSIerは、コストしか議論しない

　理由２に繋がってくるというか、敷衍した話であるのだが、
　結局、日本のコンサルは、ビジネスが興せないので、コンピューターは、費用となる。
　いくらかかりますよ！とはいえても、
　これを入れたら、こういうビジネスができて、いくら儲かりますよ
　とはいえない。

　だから、値引き競争になる。

　仮に、システムを入れると１億かかるとする。
　日本の企業だと、そこで、値引きして８０００万で受注しようとする。

　だがもし、ここで、このシステムを入れたら、２億あらたに儲かるビジネス
　を提案できたとしよう。そして、１億の借り入れ先も見つけてきたとする。

　８０００万の経費を払わせるSIerと、
　２億ー１億＝１億円儲かる話を持ってくるSIerと、

　どっちを契約するだろうか？

　日本のSIerは、前者の議論しかしない。

---

だから、日本のSIerがグローバル展開できないのって、あたりまえだよね！

eBayはオークションサイトというより、ＥＣサイトになったらしいというデータ

「ニューヨークの遊び方」の以下のエントリ

米大手ネット・オークション・サイトeBayでオークションが激減?!
http://nyliberty.exblog.jp/20517785/

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

に、eBayにおける

　　オークションでの販売／（オークション＋ポステッドプライス？販売）

の比率が載っている。
２００８年から、オークションの比率が激減しているのだ。
Posted priceって、良くわからないけど（公示価格？）、
売り手が先に値段を示し、買い手がその値段を入れたら即売買成立にするやつかなあ・・？


米国最新ITトレンドを1つ。先日発表された全米経済研究所の依頼でスタンフォード大が行った調査レポート（SALES MECHANISMS IN ONLINE MARKETS: WHAT HAPPENED TO INTERNET AUCTIONS?）によりますと、近年、アメリカでは、インターネット・オークション取引数が減少トレンドにあり、最大手eBayでは上のグラフのような激減ぶり。現在、eBayのオークション限定出品は、全体の15％しかない!?とのこと。

eBay＝オークション・サイトと思いがちですが、実は、もはやアマゾンなどと同じ普通のEコマース・サイト状態なのだとか。

そう言えば、2011年にebayがニューヨークに出したユニークなお店も、オークションぜんぜん関係なかったですし。

でも、なんで???

---

ただ、オークションって、売り手の論理なんですよね。
買い手から見ると、メリットない。

・値段ははっきりしない
・オークション期間、待たされる
・ってか、買えるかどうかすら、わからない。

うーん、買い手はお客様。お客様は神様。
なのに、買い手のほうが不利・・・
じゃあ、オークションが流行らないのも、無理ないですね。

ちなみに、その元になっている調査の論文は、以下のモノ。

SALES MECHANISMS IN ONLINE MARKETS:
WHAT HAPPENED TO INTERNET AUCTIONS?
http://papers.nber.org/tmp/47400-w19021.pdf

電子メールで「落選運動」もＯＫなんだ（＠＿＠！）

日経コンピューター２０１３年６月号　１６ページの下の表をみて、びっくり！

インターネット上でどんな運動が出来るか

「Ｗｅｂサイトや電子メールを使った落選運動」

へ～、落選運動（この人を投票「しないでください」という運動）
もＯＫなんだ。ただし、電子メールアドレスなんかを書かないといけないらしい
（表示義務）

こりゃ～、落選運動、多くなりそうですね（＾＾）ｖ

Ｐ．Ｓ　Ｌｉｎｅって、どれになるの？

ビッグデータは、教育ビジネスですかね・・・そのうちアイドルが出る予感！？

日経ＢＰは、この前の「データ分析・活用実践講座」を、毎月やる気なのだろうか（＾＾；）

データ分析・活用実践講座＜＜演習付き＞＞
http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/nc/130626-2/

これは、６万３千円、この価格だと、毎月やるほど、需要あるんだ～

だけどね・・・

第1期 ビッグデータビジネス実践イノベーター養成プログラム
http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/bigdata/1304/

これは、２９８０００円（打ち間違えてないよな、弐拾九萬八千円）


そして、本なんだけど・・・

『ビッグデータ総覧2013』
http://coin.nikkeibp.co.jp/coin/itpro-s/book/dtl/bigdata2013.html

7月1日に発行予定らしい。こいつは198000円（壱拾九萬八千円）

あ～なんか、すごいことになっているう・・・
ＢｉｇＤａｔａは、教育ビジネスから、火がついた感じがしますよね！
価格から見て、３万円台とかはないので、個人的な研修ではなく＊、企業の投資ですね！

---

マーケティング的には、ここで想起されやすいように、ＢｉｇＤａｔａ教育のキャラクターを
つくるのが効果的なのですが、

　ゆるキャラは、何十万という価格帯からして、ふさわしくない。
　ＡＫＢ４８も、何十万の投資を決めるお偉いさんには、軽く見られる・・・

ということで、ここは一発、大学の先生でしょうか？女性の・・・

　統数研とか、東大のシステム創生、ＴＭＩ
とか、東工大のＭＯＴとか、筑波とか？？

　だけど、実は、一番向いているのは、たぶん、大江アナだと思う。
　う～ん、アメリカ行っちゃったからなあ～・・・
　

---

＊注「価格から見て、３万円台とかはないので、個人的な研修ではなく」：

企業において、１人当たりの教育研修費は、だいたい３～４万円であることが、
以下の調査から知られている

・第35回　教育研修費用の実態調査
http://www.e-sanro.net/sri/news/pr_1110/

・2012年度　教育研修費用の実態調査
http://www.e-sanro.net/sri/news/pr_1210-2/

大学のソフトウェア工学だと、後ろから殴ってくるような人は分析できないかも？

昨日の

社内派閥や愛人関係「も」記述できる、ソフトウェア工学手法
http://blog.goo.ne.jp/xmldtp/e/aa87b665b95a125141eb688f291d81e3

の続きのような話。

大学の授業の場合、要求分析のところで、ステークホルダー分析は、そんなに深くやらないと思う。

やる内容は、
「ステークホルダーは、大きく、ユーザーと顧客と開発者です。
ユーザーと顧客は別です。
ユーザーはシステムを利用する人、顧客はシステム開発費用を負担する人。
たとえば、ＥＣサイトだとすると、

　　ユーザーは、ＥＣサイトのお客さんとＥＣサイトの管理者
　　顧客はＥＣサイトの社長

です」

くらいかしら・・・え、さすがにそれよりも、もう少しやるって？

「そのほかに抵抗勢力、またそのシステムを導入することにより、不利益を被る人
までも入ります。たとえば、システムを導入することにより合理化し、解雇される
従業員（抵抗勢力）、ＥＣサイトを導入することにより、一日中会社を運営する
ことになるので、会社の周りがウルサクなることで困る周辺住人です。

これらを解析する手法として、オニオンモデルがあります」

このくらいは、やるのかしら・・・でも、ここから、先にすぐにいって、
業務分析と化しちゃうよね。

抵抗勢力など、後ろから殴ってくるような人がいるとか
　　→殴るのは、抵抗勢力だけでなく、顧客、ユーザー、開発者のときもある
そういう人をどうやって発見するかとか、
実は権力も無く、要件を聞いてしまってはいけない人がいて
　　→その人の要求をどうするか

とかまで、教えないような気がする。

むしろ、ＫＡＯＳとか、ＣＶＣＡとか教えてしまうと、
これらの人はきえる（そんなこんなで、ＣＶＣＡはオニオンモデルと比べると、ステークホルダー分析が甘い）

---

実際のソフトウェア工学の世界も、抵抗勢力とかを(とりあえず）考えず、
みんないいひと！で業務分析する、新興宗教みたいな分析方法がある。
それがＫＡＯＳ。

ＫＡＯＳの場合、「どういう状態になっているか」という理想像を分析する。
たとえば、「小さな家を建てる」については、こんなふうに分析（詳細化＝洗練）
させていく


ここで、「あなた」は、「イヌ」レベルだ（＾＾；）
しかし、コレを、昨日やった、社内派閥や愛人関係「も」記述できる、
ソフトウェア工学手法であるi*のＳＤモデルで記述してみよう。
こんなかんじ。

不自然な図に見える

なにが、不自然かというと、ふつうは、
　　Ｄの文字が
　　　　　Ｄと
　　　　　ひっくり返ったＤが
　　対応関係にあるのがふつう（Ｇｉｖｅ＆Ｔａｋｅの関係）

ところが、ここで、明子さんは（なぜ明子なのか判らない２０代、３０代の人は、リンク先を見てね！）要求だけ（Ｄだけ）しているけど、反対側のＤがない。見返りになにをするのかわからない。
　さらに、大工さんから見た場合、明子さんとあなたの関係も良くわからない。
　そして、「家を建てる」という要望は、明子さんとあなたで同じなのかどうかもわからない。

　ここで、大工さんは不安になる。

　　明子さん、この図から、はずしてもよくないか？
　　もし、あなたの「家を建てる」要求と、明子さんの「家を建てる」と違って
　　明子さんが図から外れたら・・・明子さんの「家を建てる」要求でやっていると、
　　あとからどんでん返しを食らうぞ？

　ということで、大工さんは、明子さんの要望に従っていいのか、不安になる。

　ここで、大工さんとしては、あなたと明子さんの間の関係を知りたいが、ここに婚姻関係に基づく
依存性があれば簡単なんだけど、そうでないと、外から観察できる範囲では良くわからないし、
そもそも、婚姻関係でなければ、変更の危険性がある、弱い関係になる。

　そこで、大工さんは、「ここで一発、契約だ！」として、
　あなたと、大工さん間で契約を結び、
　明子さんの要求を文書化し、あなたと大工さんの間で合意をとる。
　　　→明子さんとあなたの要求が違った場合は、明子さんの要求は無視する

---

　この「小さな家を建てるプロジェクト」の結末は皆さん知ってのとおり。
　プロジェクトはすぐに終了する（家は建てない）

　もし、ＫＡＯＳで分析していたら、「あなた」の存在は、小さなものなので、
家は建つものとして詳細化、ユースケース分析に入る。
　そこで、いきなりプロジェクト中止と「後ろから殴ってくるような」事態におちいる。

　しかし、i*で分析し、依存関係の不自然さに気づけば、
　あなたに契約内容を確認するため、いち早く、家は建てる気が無いことに気づく。

---

　世の中の開発だと、結構そういうことがあって、現場の人はいろいろＵＩ要求を
出してくれるんだけど、「あんたを解雇するためにシステム導入するんだから、
あんたの使いやすさなんて、ど～でもいいんだよ」というかんじなのに、
そこで、要求が膨らんだり、「やっぱり現場のＸさんは、必要です」とかいう話になり、
さらに「お客様のＸさまに喜んでもらい、プロジェクトは大成功しました」とか、
わけわかんないことで、開発者が自己満足、でも次の発注は来ないことになる。

　顧客（ユーザーのＸさんではない。カネを出す顧客）は、ユーザーＸさんを笑顔
にすることを求めているのではなく、Ｘさんの首を切ることを求めている。

　上記の場合、Ｘさんの首を切れなかったのだから、
　顧客から見たら、システム開発は大失敗！
　当然、そんなベンダーには、二度と開発は頼まない。
　顧客の求めている要望をまったく無視しているのだから、
　Ｘさんが喜び、業務が回っても、金をドブに捨てたことになる。


　Ｘさんも一時的には幸せだが、
　長い目で見ると、古い技術に固定され、転職できず、一生が終わる。
（ＣＯＢＯＬの汎用機での帳票出力のためのパンチしか出来ません！みたいな）

---

この手のストーリーは、大学では、あんまり教えてないんじゃないかなあ？

でも、そこまで教えないと（上記みたいな）要求変更は教えられず、
システム開発の本質（だれかの首切りをしなければならないが、それによって、
きられるほうも、顧客も、開発者も、次の世界にいけて、実はＨａｐｐｙ）
の話もできないわけで・・・

「ユーザーの要求を満たすことで、みんなハッピー」みたいな
箱庭みたいなソフトウェア工学を
教えることになる

もちろん、箱庭が悪いわけじゃなくって、
議論をするためには、箱庭をつくるんだけど、
その箱庭が、実社会と同じと思っちゃうと、それは勘違い。

これは、「箱庭で、社会はもっとどろどろしてるから、使えない部分があるんだよ」
という、限界を教えることが重要だと思うんですよ・・・

株価乱高下の背景、超高速取引が一因＝麻生財務相

う～ん、それもあるかもしれないけど・・・

アメリカのFlash Crashがそれだよね。
Flash Crashって、３つぐらいのアルゴリズムで取引を同時に起こさせると、再現できたんじゃなかったっけ？
なんか、大学院でやった気がする（間違ってるかも）

・・・

ノート確認した。つぎの３つのアルゴリズムを組み合わせるらしい
Ａ．価格を等差数列的に下げて付け、売買成立したら、さらに下げる
Ｂ．Ａと同じ等差数列的価格付けだが、下げ方がＡより細かい
Ｃ．等比級数的に価格を下げる
　メモが間違っていたら、ごめん

---

東証も、たしかにFlashCrashが起こる、ＨＦＴ（高速取引）に対応している。

J.S.エコハ ‏@Koj_Sasaki 5月29日
東証arrowhead高速取引の本質は「約定まとめ」の廃止による約定の個別化。「約定まとめ」とは1991年に取引システム完全電子化の際、情報提供頻度が速過ぎるとの懸念から意図的に3秒のタイムラグを約定間に挿入。最頻時で4秒の集計になる。

とあるように、昔は、約定まとめをしていたが、Ａｒｒｏｗｓになってから、まとめないで、瞬時に執行するので、値段がすぐに動く。

ただし、日本には、値幅制限があるので、ＦｌａｓｈＣｒａｓｈほどにはならないんじゃないか？
また、ＦｌａｓｈＣｒａｓｈの場合、値はもどる。

今回は、それよりも、今まであがりすぎたことと、ヘッジファンドが５月に精算するために利益確定で売りたかった、とか、そっちの理由じゃないかなあ

---

ま、理由はともあれ、一喜一憂しないという麻生大臣の態度は正しい。
もし、大相場になるのであれば、今まで上がりが急だったので、ここで一回さげて、再挑戦ということであろう（このまま、終わってしまうかもしれないが・・・）

まあ、大相場を期待して、気長に待ちましょう・・

Ｅｘｃｅｌ方眼紙がなぜ悪いのか、良くわからない・・・ごめん（＞＿＜！）

最近、Ｅｘｃｅｌ方眼紙が血祭りに上げられている

日経ウーマンが美文書「Excel方眼紙」特集、古傷を刺激された皆さんの叫び声が響きわたる
http://matome.naver.jp/odai/2136948486965928001

が、正直、どうしてＥｘｃｅｌ方眼紙が血祭りになるのか・・・正直、よくわからない。

---

データの再利用という観点から言うと、
Ｗｏｒｄの表で書かれるよりも、
方眼紙でかまわないからＥｘｃｅｌで書いてくれたほうが、再利用しやすい。

なぜなら、普通、データを抜くときは、マクロを書いて抜く。
そのため、Ｅｘｃｅｌだと、たとえ方眼紙でも、たとえどんなに升目が多くても、
セル位置内に文字があれば、
RangeやCellsで位置取得し、テキストを取ってこれる。
そうすれば、後はテキトーにつなげて、ＣＳＶにすれば、
ExcelでもRでもWekaでも、MySqlに入れるにしても、なんでもできる。

ところが、Ｗｏｒｄやパワポでかかれると、このデータを抜きにくい。
（Ｗｏｒｄのマクロはあるけど、該当する部分のデータを指し示しにくい）
テキストでも、構文解析しなきゃいけなくなると、
Ｅｘｃｅｌ方眼紙よりも大変。

ほんと、Ｅｘｃｅｌなら、方眼紙でも何でもありがたい！っていうかんじ。
そのために仕様書はＥｘｃｅｌで書かれる。
仕様書からデータを抜いてプログラム自動生成しやすくするために。

---

実際に、Ｅｘｃｅｌからデータ抜いて、プログラムを自動生成している人
とかでないと、XMLのほうがいいんじゃないか？と思うかもしれないが、
XMLは、大変なのだ・・・

ＸＭＬのＤｏｍの場合、getElementsByTagNameで、タグ名で値をとってくることになる。
このElementsってなっていることろが、面倒なのだ。
NodeListで入ってきてしまう。
なので、１つの値をとってくるのに、一呼吸はいる感じになる。
Ｅｘｃｅｌマクロのように、のりのりに書けないのだ。

---

ちょっと怖いのは、最近、みんながＥｘｃｅｌで書いてくれて、
やっとデータ分析、ビッグデータ解析とかの前処理が
ちょっと楽して自動化できそうになったのに、

文書はＷｏｒｄで書け！
ＴｅＸで書け！

とか、理由わからんこといって、
前処理の仕事を増やすことだけはやめてくれ。

批判する人は、こうやって、データぶっこ抜くと、
Ｅｘｃｅｌ方眼紙よりぶっこ抜き易いという方法論と
ともに、批判をして欲しい。

ＰＳ．
「Ｅｘｃｅｌ方眼紙を利用したＢｉｇＤａｔａ処理」っていう
シリーズ、面白そうだね（＾＾）ｖ

採用ビッグデータ＝「タレントマネジメント」＋「データ分析」

日経情報ストラテジー２０１３年７月号の１７ページに
「採用ビッグデータ」という言葉が出ている
優秀な従業員を採用するために、採用に関してデータ分析するもの。

はっきりとは書いていないが、実際にやることは、

現在、企業で優秀とされる人材のデータを解析して、
それを、採用時データと突き合わせることにより
どういう人を採用するべきか、どういう試験をするべきか

などを提案することでしょうね


今、などと書いたように、これ以外でも、利用価値があって、
あの部長は、顔で選んでいる！
なんていうのを、数値的に表現できたり、できなかったりです・・・

---

ということで、採用試験のデータだけでなく、
現在従業員の経験、能力データ（タレントマネジメント）
が必要で、これをデータ分析するということになります。

文書、音声、顔写真・全身写真・・・のイメージデータが無い限り、
ビッグデータにはならないかも・・・

ただ、今後期待される分野ではある。

社内派閥や愛人関係「も」記述できる、ソフトウェア工学手法

　プロジェクトの多くは失敗し、それは、要求が変化することだということは、
なんかコンセンサスが取れているようだ。
　ただここで、その要求の変化は、社会環境の変化か？といわれると、（学者さんはそう思っているかもしれないが、事実上は）必ずしもそうではない。

　会社内の派閥人事にソフト開発が巻き込まれたりするケースも、
　あったり、なかったりです。

　そうすると、システム開発を成功させるには、会社内の派閥関係を記述でき、どのへんの要求がどこからでてきて、どんなかんじで、権力者の意向が変わるか、権力者自体が変わるかが分析できないといけない。

　もちろん、フォーマルな派閥だけでなく、インフォーマルな、愛人関係、友人関係（中小企業等の社長間では重要）なども表現できないと、要求は、どこから横槍を入れられるか判らない。

　とすると、社内派閥などが記述できるソフトウェア工学手法があるか・・・

　ということなんだけど・・・

　・・　　i*かな、やっぱり。

---

　i*（読みは、i star,iスター、あいすたー）の書き方は


iStarQuickGuide
http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide


にあるとおり。これのＳＤモデルは、
アクター間の
リソース、タスク、ゴール、ソフトゴール
に関する依存関係を書いている。

２人のアクターがいたとき（i*は、アクターを、役割だけでなく、個人、地位のカタチで書き分けられる。そして、地位と個人、役割の関係を「Actor Association Links」で細かく書き分けられる）、

その２人の間にある、ゴール、リソース、タスクの依存関係（アクターＡが、してほしいといい、アクターＢがそれを受け実行する関係）を示せる。

---

ということは、

　　　「これは、本来の使い方ではありませんが！！」

例えば愛人関係なら、こんなかんじで書ける

ＤはＤｅｐｅｎｄのＤみたいだけど、→の矢が膨らんでいるとみると、見やすい。
矢のもとのほう（Ｄのぼうのほう）は、Depender：依頼する人
矢のさきのほう（Ｄの丸いほう）は、Dependee：依頼される人、実行する人になる。

会社の派閥関係で、派閥のボスと、子飼い社員を書くと、こんなかんじ

ここで仕事１は、いろいろかわる。
手作業の業務だったり
システム開発プロジェクトだったり、
そのプロジェクトを妨害することだったり・・・

こうすると、同じ「システム開発プロジェクト」というタスクに対しても、
違った依存関係に成ることがわかる。

社長は利益を得る為、プロジェクトを社員に依頼する。
社員は企業に対しては、お金（給料）を得るためだが、
同じ社員が、派閥のボスに対しては、昇進上有利になることを期待(依頼）する
派閥のボスは、昇進を依頼されているが、
システム開発の成功は、会社から依頼されていない・・・こともありえる。

---

こうやって、企業の欲望を可視化することで、（欲求工学？）
企業の同床異夢の構造は記述できるのだが、
これからどう動くかの「社畜のダイナミズム」は、
まだ判っていない。

・・・論文も出ていないと思う

・・・ってか、たぶんでないと思う（＾＾；）

---

Ｐ．Ｓ

　何回も書きますが、i*は、こういうように、
応用ができるという話なだけで、
　一般には、i*を、こういうことには使いません！！

　ただ、こういうように、企業のどろどろした構造を、
可視化できるところに、ソフトウェア工学のおもしろさが
あると思います。

　あんまり、微分方程式や数理モデル、統計モデルで、
愛人関係とか、子飼いの部下とか、かけないよね！