期限切れ後の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