システムはステークホルダ→目的→優先順位を決め、費用対効果で効果あるものをやるべき

　で、話途中で止まってた、政府の“国民電子私書箱”構想、ライフログのマーケティング目的利用を検討に対する話。
　いままでの話で考えてきたように、結局、システムは利用目的に基づいて、計画的に。。。っていうことになる。

そーすると、こんな順番でかんがえることになるのかしら
・まず、システム利用者、関係者を決める
・その人たちのシステムを利用する目的を確認する
・その際の制約条件などがあれば、確認する
・そして、費用対効果を見極めながら、優先順位を・・・

---

　で、そーやって考えると、国民電子私書箱の利用者は、国民なわけで、国民にとって、プラスになることを、政府が提供することが、最優先ということになります。政府提供のサービスとして大きいものはやはり、

　年金
　介護
　健康保険

なわけでして、これに加えて

　各種サービス（保育園、図書館など施設利用）

その対価として、

　税金（国に対して、地方に対して）

っていうことが重要で、それが最優先されるべきです。とくに、特定の人ではなく、広範の人に影響するものほど（っていうと、年金、保険かな）優先されるべきです。

---

　ここで、ライブログというのは、やりたい人もいるだろうし、必要ないと考える人もいるでしょう。そして、このサービスを国家が始めてしまうと、その分ディスクや管理人件費が割かれ、利用してない人も（税金という形かもしれないけど）費用負担しなければならなくなってしまいます。使わない人が利用負担するのは不公平です。じゃあっていって、すべての人にライブログを強要するのもおかしな話です。国家が強要すべき必要性が感じられないからです。そのようなことは、やりたい人にだけやっていただきましょう。

　ましてや、マーケティング目的利用っていうのは変です。この情報はただで提供されるのでしょうか？それは、提供する民間会社に対して、不当に有利な情報を提供していることになるので、国家がやるべきことではないし、もし、お金を払って行うとしたら、そのお金は、国家が受け取るべきなのでしょうか？情報を提供した個人が受け取るべきなのでしょうか？

　というわけわからない問題に加え、個人情報を収集してしまうと、漏洩する危険があり、漏洩する危険があるということは、漏洩した場合の損害補償リスクが生まれるということです。逆に集めなければ、そんなリスクは生まれません。国家が、とらなくていいリスクをとる必要性がありません。

　以上により、ライフログのマーケティング目的利用をする正当な理由は、目的から考えると、見出せません。

---

　ただ、もっと大きな問題として、そもそも、電子政府の目的って、国民目線からみたら何？って言う部分はあるんだけどね・・

クロスメディアとかワンソースマルチユースとか、自動組版とか、そのへんをまとめてみる その２

　その１で書いた、ワンソースマルチユースとか、自動組版についての話。全体像をまとめると、こんな図になる。


　「ためる（保存）」「配送する」「（メディア）変換する」と３つにわけて考えるとすっきりする。

　ワンソースマルチユースという場合、素材を全部きれいに整理してとっておいて、必要なものだけ取り出して、まとめ、それをバッチの場合にはフォーマッター、DTPの場合には、DTPソフトに送る。そのため、素材を保存しておくデータベースなり、ファイル置き場が必要になる。これが保存というところである。

　フォーマッターとは、素材から、メディア（PDFとかWebのHTMLとか、書籍用のPSファイルとか）用にフォーマッティングして作り出すもので、XMLの場合、XSLT＋FOフォーマッター（FOPなど）がそれにあたる。この過程で、出力イメージは見えない。
　DTPの場合は、同様に素材を読み込み、メディアを出力するが、出力イメージを見えるので、そのイメージを見ながら調整できる。

　事実上、成り行きで組版する場合、枠ぎりぎりの文字数だと、組版エンジンの端数処理などにより、ぎりぎり入るかあふれるかは事前予測が困難になっている。そこで、枠のあふれがありえるような場合は、DTPでいったん読み込ませるのがよく、逆に帳票のような、枠のあふれがありえない（あっちゃいけない）ような場合では、バッチのほうが有利である。

　配送は、この保存とメディア変換（フォーマッター、DTPソフト）の間をつなぐもので、今回利用する素材を取り出したり、作り出したりする。素材とは、そのメディア作成のための部分的部品であり、大きく、
　　・文章テキスト
　　・イメージ（写真）
　　・線画（ベクターデータ）
の３種類に分かれる。この３種類の素材をどこに置くかをレイアウトというが、このレイアウトも素材同様に扱える。
　旅行パンフレットにおける小組枠など、これら素材をあらかじめ組み合わせて、部品とする場合もある。その場合、部品を「ライブラリ」というところに入れておく。

---

　自動組版という場合、データからフォーマッターでフォーマッティングする手法のみを指す場合もあるが（その１ではこれを伽藍型と述べた）、これらは、あとで調整できないので、組版エンジンによる成り行き割付結果が問題にならない帳票、Webサイトなどに限られる。
　しかし、素材作りや、DTPソフトを自動的に動かすためにコンピューターを利用することも意義深く（その１では、これをバザール型と述べた）、とくにDTPソフトを自動的に動かす部分も、（ウィリアムのいたずらなど、主義主張のない人は）自動編集、自動組版と呼んでいる。

　ただし、XMLを利用する人々は、前者しかみとめず、後者のDTPをXMLに流し込んでいったん自動編集し、その後編集をすることを、「無駄な作業だ、なんでDTPで読み込むんだ」などと激しく非難されることもあるので、要注意である（空気を読もう。そういう人に何を言っても無駄なので、逃げるがかちだ）

---

　で、この枠組みで考えた場合、XMLは、保存も可能だけど、データ配送用の素材の一部（論理構造付文章テキスト）という位置づけになる。
　こんなことを、XML利用で考えている人の前でいわないように。
　かれらXML主義者は、XMLですべてができると思っているので・・・

　でも、現実違うので、まあ、主義主張ない人用に説明すると、そういう意味では、DTPのタグ付テキストとXMLは、おんなじ様なもんだけど、タグ付テキストが、物理構造を反映しているのに対して、XMLは基本的には、論理構造のみを記述し、物理構造はXSLなどで記述する・・・

　・・・が、論理構造だけなら、テキストから読めるんじゃない？っていう話もある
　（＜章＞ってタグがなくても、第○章って書いてあるところは章だよって話）
　ただ、そうだとしても、後段の処理で、DOMで読み込めるってところが、メリット。つまり、扱いやすいんだね！

---

　ふー、やっとここまで説明して、本題に入れる・・・

クロスメディアとかワンソースマルチユースとか、自動組版とか、そのへんをまとめてみる その１

　まず、自動組版とか、ワンソースマルチユースを考える場合、３つの機能に分けて考える

・ためる
・配送する
・（メディア）変換する

　ためるというのは、データ、つまり素材を保存しておくことで、DB（RDBまたはXMLDB)やファイルが考えられる。
　素直に考えれば、RDBが実用的。

　そのDBデータ（素材）から、今回必要なデータを取り出し、配送する。
　この配送には、後々の変換工程が行いやすい形で配送するのがよく、そう考えるとXMLが向いている。
　（絶対ではない。テキストそのもの、EPS、TIFFなどもあり）

　そして配送されたデータを出力用にメディア変換して出力するということになる。

---

　このメディア変換において、

　　　・WYSWYG
　　　・バッチ

　と２とおりある。WYSWYGは、組体裁をGUIで確認しながら行うケースで、データや図を流し込んだ結果、どうなるか（あふれる枠がでるとか、トリミングが適正かとか）わからないようなとき、DTPソフトなどを使って、データを流し込み、レイアウティングを確認しながら行うもの。
　もうひとつのバッチは、ある特定の組体裁でかまわない、あるいは複雑な組版ルールが決まっているような場合、レイアウティングを確認する必要がない場合（請求書、DMなど）、一気にレイアウティングから印刷までを自動的に編集する。

　バッチの場合、一気に行くので、逆戻りはない。という意味では、システム開発のウォーターフォールモデルに似ている、一方、WYSWYGですぐに作って確認、小組など部分部分からつくって、大きくしていくのは、アジャイルに似ている。
　ただ、ソフトウエア開発において、ウォーターフォール型のCASEツール、つまり全工程を網羅する伽藍型のCASEツールが失敗し、部分部分の自動化、CASEツール化を目指したバザール形CASEツールが成功したように、印刷などでも、伽藍型フルバッチにしてしまうと、融通が利かず、ゲラ刷りまでわからない！という状況になってしまい、自動組版のメリットが生かせないので、バザール型のDTPに読み込ませるデータの自動生成といったようなプラグインによる開発が多く、成功を収めている。

---

　さて、この「ためる」「配送する」「（メディア）変換する」について、今後、全体像を解析していくわけだけど、それは次回。

　

コンピューターにとってエコなのは、いらないデータを捨てることで、それにはi*法いいかも？

　今まで書いてきたデータの経済性から考えると、コンピューターにとってのエコは、いらないデータをがんがん詰め込んでおきながらコンピューターの消費電力を下げることではなく、そもそも必要なデータ、プログラムだけに絞って、それ以外はコンピュータを使わない（電力を消費しない）ってことになってくる。

　で、いらないデータ、プログラムを捨てるには、
　　・今使われているか？
　をまずチェックし、使われてないプログラムについて、
　　・使われる可能性があるか？
　って分析することだと思う。
　この使われる可能性を知るには、そのプログラムの目的を調べることなので、こーいうことにも、ゴール指向、i*法などは使えるかも・・・（新規システムの作成以外にも）

GENOウイルスって何？。。。

話をまとめると、
・Adobe ReaderやAdobe Flash Playerの脆弱性を突いたウイルス
・ホームページを見ただけで感染
・感染すると、重くなったり、起動しなくなったり、個人情報を漏らす
・対策はAdobe ReaderやAdobe Flash Playerを最新にすればいいの？
　（よくわかってない・・・）

いつもなら参考サイトをリンクするんだけど、
下手にリンクして、そのサイトが感染しているとまずいので、
今回はリンクなし。
興味がある人は、Googleで「GENOウイルス」を検索してみてね！
でも、実際にそのサイトを見るかどうかは自己責任で
（感染しちゃうかもしれないので。。）

新型インフルで関西部会の発表が中止―XMLコンソーシアムWeek

　今日のXMLコンソーシアムWeekの一番のポイントは、前に書いたi*法ではなくて、関西部会の発表が中止されたこと！！

　新型インフルの影響で、発表者の企業が出張規制→東京に来れず→中止

　だそうな（ほかの発表は、ふつうに行われた・・・とおもう。途中で帰ってきてしまったのではっきり言い切れないけど。たぶん）。

　身近なところまで、新型インフルの影響が・・・・
　（今日、XMLコンソーシアムWeekの人が少なかったのも、そのせいかしら？）

i*法におけるアクターとアクティビティ図のスイムレーンなどについて

　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のクラウドのサーバーがどこにあるのか、わからない。ということは、自分が思いもよらないところにデータが格納されていて、その地域で大停電が起こったり、新型インフルエンザが流行して保守できないとなったら、ある日突然、データにアクセスできなくなるという危険も否定できないのではないか？

　その時点でバックアップを取ろうとすると、みんなバックアップを取り始めるので、帯域が足らなくなる。

---

　そーすると、やっぱり、サブプライムのようなお金の借り入れに対しては、「ご利用は計画的に」ってやるように、
　クラウドコンピューティングに関しても、何でもクラウドではなく、「ご利用は計画的に」なんだろうな・・・

微弱電波のワンセグで、ケータイからパソコンを操作出来たら、楽かも。。。

今、思った。
前に、微弱電波（免許取らなくていい）で、ケータイのワンセグに電波が流せるっていう話をかいたけど、あれ使って、パソコンの画面をケータイに飛ばしてくれて、ケータイから、ブルートゥースや赤外線をつかって、パソコンを操作できるようになると、

　パソコンの画面を見ないで、寝ながらケータイで、パソコンを操作できるから、楽かもお・・・

はい、ただいまつかれているだけの話なんですけどね・・・

データの経済学（データバブルの到来）

　この前書いたクラウドとユビキタスの関係をそろそろまとめたほうが、よくね？のつづき。

　前の話は、クラウドとユビキタスが発展すると、どこで処理するかという技術的な問題はなくなってきて、最終的には、どこで計算して、データをもつのが経済的か？という話になるってことだった。

　で、ここで問題なのだが、そもそも、データを持っていることが、経済的に理にかなうことか？という問題が出てくる。

---

　経済的に考えると

　　データが生み出す価値　　＞　データを保持するのにかかる費用

　のときに、データを持っているのが意味があり、データ保持にお金がかかれば、持っている意味はないということになる。

　たとえば、４月１０日、午前８時２０分に、中央線四ッ谷駅からウィリアムのいたずらが乗車した
　というデータがあったとしよう（架空データです。８時２０分は、いつも、「まいにち中国語」を聞いてます。

　このデータ、何年間も保持しているとすると、CDまたはハードディスクに入れたり、それなりの費用がかかる。
　で、このデータが、なにかを生み出すかというと・・・なんか分析したときには役立つだろうけど、さして今重要でない。
　そーすると、データが生み出す価値は、データマイニングとかすれば価値があるかもしれないけど、まあ、そんなに価値はないデータだ。

　一方、年金を収めたデータなんていうのは、価値がある。そのデータがなくなったら、年金の調査をしなくちゃいけないし・・・
　そー言うデータは、是が非でも保持しないといけない。ただし、すぐに出てくる必要はないかもしれない。

---

　こーやって考えると、データには、価値を生み出すもの、保存しなきゃいけないものと、そうでないものがある。

　ここで問題なのは、爆発的に増えている動画データだ。
　そのうちの一部は、価値あるデータだが、著作権違反のデッドコピーの価値ないデータ（オリジナルさえあればOK)なんていうデータや、だれーもみてない動画データなどもある。

　このようなあまり価値のない動画データが急速に増えると、そのデータを保持しておくためのディスクがひつようになる。
　結果として、データが生み出す価値以上に、データ保存のために投資しないといけなくなる。

　これをデータバブルとよぼう。

　これの問題は、

　　データが生み出す価値　　＜　データを保持するのにかかる費用

　なのだから、データが増えて、どんどん投資しても、その投資を回収できる見込みがないことだ。

　しかし、そのような価値ないデータ（ごみデータ）は、どんどん増えていく。いつかは爆発することだろう。

---

　この問題は、錯覚しやすい

　というのも、クラウドにデータを追いやってしまうと、データがなくなったような気がする（いや、クラウド上にデータはあるんだけどね）
　記憶媒体が安くなったら、データ保持費用が下がるので、どんどんデータを入れていいような気がする（けど、ものには限度がある）

でも、それは、「データを保持するのにかかる費用」が安くなったというだけで、安くなった分、データを生み出してしまえば、また変わらなくなる。

次回は、このデータの経済性という視点から、クラウドについて、捉えなおしてみたい。

Javaデータ放送？

　きのう、サイエンスZEROを見ていたら、NHKの技研公開が、もうじきらしく、その話をやっていた。
　ってことで、技研公開2009のページを見ていたら、こんなもんが！！

Javaデータ放送
～ 高機能なデータ放送サービスを目指して ～
http://www.nhk.or.jp/strl/open2009/tenji/t23.html

Javaデータ放送！？なんじゃそりゃ？？
地上デジタルのBMLがJavaにかわるの？

・・・よくわからん！？技研公開（２１～２４日、NHK技研）行って聞いてこないとだめ？？
（ちなみに、技研公開は、ふつうの展示会と違って、気軽に聞いて、親切に答えてくれる）

うーん、でもますます、自作テレビ（中身はパソコン）の時代になりそうだ（＾＾；）

パソコンは小型化よりも標準化だよね！

この前書いた、テレビの話。ソニーの小型化について書いてあったが、ユーザー的には、小型化よりも、標準化のほうがいいよね。

　つまり、紙の大きさA4,B5みたいに、外観の大きさは何種類かに揃えてもらって、それにあう棚を作ってくれたほうがいい。そーすれば、それにあう棚も売られるだろうから、インテリア的にもいいよね。

　そして、小型化されて分解できないよりかは、ある程度の大きさで、基盤だけを”ぱかっ”てはずして、捨てられたりできれば、そして、基盤回収ボックスみたいなのができれば、

　基盤だけ集めてリサイクルできるし、
　のこりの箱はプラスチックならリサイクルできるし・・・
　　　　　　　金属でも箱だけ集めれば、リサイクルできる

　基盤ごとに入れ替え可能なくらい、標準化（互換性を持たせる化）すれば、
　　性能アップできるし、
　　故障したとき、自分で切り替えられる。

　今後は、リサイクルとか、部分的な入れ替えとかのために、小型化よりか標準化をめざしてほしいよね。たとえば、ネットブックとかも軽くしてくれるのは歓迎だけど、大きさに関しては、いたずらに小さくするより、A5判とか、文庫版とか、大きさを紙媒体に合わせてほしい。そうすれば、バッグに入れやすいから。ポケットに入るくらい小さくしても、落ちちゃうような感じじゃあ、結局バッグに入れるのだから・・・

MySQL創始者、「Open Database Alliance」を結成

ここのニュース
MySQL創始者、「Open Database Alliance」を結成
http://sourceforge.jp/magazine/09/05/15/0250241
によると（以下斜体は上記サイトより引用）


スウェーデンMonty Programと米Perconaは5月13日（フィンランド時間）、MySQLの業界団体「Open Database Alliance」の結成を発表した。MySQL関連の取り組みを結集し、分断化を防ぐとしている。MySQLに加え、MySQLのコミュニティブランチ「MariaDB」もプッシュしていくようだ。

で、けっきょく、MySQLはどーなるの？？

液晶テレビは誰でも作れる By 日経ビジネス － やべー、作りてー。。。

　日経ビジネス２００９年５月１８日号の表紙、見ました？

　激安デジタルの脅威
液晶テレビは誰でも作れる

ま、まじっすかあ（＠＿＠！）ウィリアムのいたずらでも、作れるんですかあ？
・・・作りてー。。。

そして、記事、２９ページ１段目、下のほうに、某ベンチャー企業の金社長いわく
（以下斜体は日経ビジネスの上記箇所より引用）

「ブラウン管の技術開発が必要だったアナログと違い、デジタルテレビは簡単に作ることができる。パソコンと同じように、液晶パネルと電源コード、信号処理基盤といった部品を揃えれば、一般ユーザーでも自作できるかもしれない」


うん、ぱ・そ・こ・ん？？

そっかあ（＠＿＠！！）

・パソコンは、自作できますよね！
・それに、パソコン用地デジチューナーも売ってるので、つけられますよね
・その上にWindows、インストールできますよね
・地デジチューナー用のソフトは入ってる＝インストールします
・Windowsって、たしか、ひとりしか使わないで、パスワードとか設定しないと、
　そのまま立ち上がった気が・・・
・で、スタートアップに、その地デジソフトを入れると・・・
・電源を入れると、自動的に地デジが立ち上がる・・・

・・・おおおおお、あとは、キーボードの代わりにリモコンにすれば・・・

・・・なんか、できそーじゃん！！

・・・どっかのメーカーで出してくれないかなあ、自作用地デジキット

やべー、そんなの出てきたら、作りてー・・・