今日のXMLコンソーシアムWeekの一番のポイントは、前に書いたi*法ではなくて、関西部会の発表が中止されたこと！！
新型インフルの影響で、発表者の企業が出張規制→東京に来れず→中止
だそうな（ほかの発表は、ふつうに行われた・・・とおもう。途中で帰ってきてしまったのではっきり言い切れないけど。たぶん）。
身近なところまで、新型インフルの影響が・・・・
（今日、XMLコンソーシアムWeekの人が少なかったのも、そのせいかしら？）
今日のXMLコンソーシアムWeekの一番のポイントは、前に書いたi*法ではなくて、関西部会の発表が中止されたこと！！
新型インフルの影響で、発表者の企業が出張規制→東京に来れず→中止
だそうな（ほかの発表は、ふつうに行われた・・・とおもう。途中で帰ってきてしまったのではっきり言い切れないけど。たぶん）。
身近なところまで、新型インフルの影響が・・・・
（今日、XMLコンソーシアムWeekの人が少なかったのも、そのせいかしら？）
i*法は、ゴール分析に使われるが、その際、i*法のアクターと、それ以降の工程で行われる業務分析で使う図のアクター（たとえば、アクティビティ図ならスイムレーン、ユースケース図ならアクター、DFDなら外部からの入出力を示す、外部）とは、粒度をあわせるべきだろう、というか、同じものにするべきだろう。
i*法では、アクター間におけるゴール、ソフトゴールを記述し、明確化する。
このゴールが、業務で実現できているかを確認するには、i*法のアクター、タスクが、アクティビティ図のスイムレーンやアクティビティ（DFDなら外部からの入出力とプロセス、ユースケース図ならアクターとユースケース）と関連付けられ、そこで行われているアクティビティが、ゴールを達成しているか、実現性のある話かを検証しなければならない。
ところがここで、もし、i*のアクターと、アクティビティ図のスイムレーンがずれると、どれがどのアクティビティに対応しているのやらわからなくなり、ゴールが達成しているのかわからなくなる。
たとえば、XMLコンソーシアムのビジネスイノベーション研究部会で作った気象庁の防災情報XML。
これに関するi*法での図があるようだ（というのを見た。今日）。一方、Webサービス研究部会で実証実験しているのは、前に書いたとおり。
ここで問題は、Webサービス研究部会ででてくる実証実験の二次プロバイダ、つまり気象庁データを受け取って、一般の人々に配信する会社＝アクターは、i*法で分析したビジネスイノベーション部会の何にあたるか？ということだ。
もし、地方自治体がそれにあたるのなら、地方自治体のゴールは、自分の地域の安全を守ることだから、一般の人々（アンドロイド端末を持った人々）が、他の地域に行ってしまったら、その人たちの行動を追う必要はない。
なので、実証実験で考えているような、端末を持っている人の情報すべてを二次プロバイダ（ここでは地方自治体）が持っていてくれる。。。
というのはゴールにあわず、自分たちの地域に入ったら、その人だけ、情報を持っていたいということになる。
また、もし、「気象何とか。。。（名前忘れた）」っていう気象データを配信する人だとしたら、その人たちはビジネスでお金を儲けるのが、ゴール。
ということは、もし大災害になって、採算が会わなかったら、その地域に配信をしてくれないかもしれない。
（っていうか、ゴールうんぬん以前に、災害があっても配信できる会社って、NTTなど、ごく限られた会社だけど）
って考えると、「二次プロバイダ」は地方自治体なのか、気象何とか・・・っていうものなのか、それとも、ここに出てないアクター（たとえばネットワークプロバイダとか）があって、それが「二次プロバイダ」なのか？それによって、ゴールが違ってきて、開発すべきシステムも変わってくると思う。
なので、アクターは合わせて、システムを考えたほうがいいと思う。
XMLコンソーシアムの話は、たまたま今聞いて思ったので書いただけの話であって、一般的に、ゴール分析で出てくるアクターは、ワークフロー分析ででてくる誰のことかは、明確にして（できるだけ、同一名にして）議論したほうがいいと思う。
ここのニュース
浅尾見られない？ビーチ無観客試合も
http://headlines.yahoo.co.jp/hl?a=20090519-00000013-dal-spo
無観客・・・いまからテレビは無理としても、
ネット配信とか、あるのかなあ？
なんか、そしたら、見たいなあ・・
他のスポーツでも、今後、無観客試合ってありそうだけど、
ネット配信、検討しないのかなあ？？
昨日のデータの経済性という話で考えると、サブプライムとクラウドコンピューティングの共通点が見えてくる。
サブプライムは、本来かしちゃいけないような人に、お金を貸して、住宅を買わせた。
そして、その貸し付け債権を、優良な貸付債権とごちゃ混ぜにして、小口化して、証券化として売り出した。
この証券化の過程で、元のサブプライムのリスクが見えにくくなり、また、そのリスクが分散された。
そして、最終的に行き着くところまで行って、経済的にパンクしてしまうと、そのサブプライムのリスクが顕在化、分散されているために、あちこちに深刻な被害を引き起こした。
クラウドコンピューティングも同じで、本来、わざわざデータとして保存しなくてもいいようなもの（＝サブプライム）も、必要なデータ（＝優良資産）と一緒に、クラウドにごちゃまぜに入れてしまう。そして、このデータは、仮想化（小口ならまだいい、仮想なんだよ ＾＾；）されて、どこかのサーバーに入っている。この過程で、データの価値は見えにくくなり、またデータは、分散される。
このようにごみデータも必要なデータもがんがんクラウドに入れていくと、クラウド提供会社のストレージは、がんがん増えていくことになる。が、ストレージは、ただで、無尽蔵に提供できるわけではないので、もし、
ストレージ提供スピード ＜ データ蓄積スピード
となると、どこかで限界が来る。いきつくところまで行き着いてしまう。
こうなって、クラウドサービスが提供できない！となると、データは分散化されて、どこに何があるかわからないので、バックアップもままならず・・・ということで、深刻な被害を招く可能性がある。
サブプライムが格付け会社などによって、信用力があがったように、クラウドもGoogleやAmazonというブランド力によって、信用が上がっている。しかし、実際にAmazonのクラウドのサーバーがどこにあるのか、わからない。ということは、自分が思いもよらないところにデータが格納されていて、その地域で大停電が起こったり、新型インフルエンザが流行して保守できないとなったら、ある日突然、データにアクセスできなくなるという危険も否定できないのではないか？
その時点でバックアップを取ろうとすると、みんなバックアップを取り始めるので、帯域が足らなくなる。
そーすると、やっぱり、サブプライムのようなお金の借り入れに対しては、「ご利用は計画的に」ってやるように、
クラウドコンピューティングに関しても、何でもクラウドではなく、「ご利用は計画的に」なんだろうな・・・
今、思った。
前に、微弱電波（免許取らなくていい）で、ケータイのワンセグに電波が流せるっていう話をかいたけど、あれ使って、パソコンの画面をケータイに飛ばしてくれて、ケータイから、ブルートゥースや赤外線をつかって、パソコンを操作できるようになると、
パソコンの画面を見ないで、寝ながらケータイで、パソコンを操作できるから、楽かもお・・・
はい、ただいまつかれているだけの話なんですけどね・・・
アクセス
トータル
ランキング
