目で聴くラジオという聴覚障害者のためのＣＳ放送、ケータイで情報料とってやれば？

　今ＮＨＫで、「目で聴くラジオ」という、聴覚障害者のための、字幕＆手話のＣＳ放送の話をやっていた。しかし、受信機の購入や契約が必要とか、お金がかかって、普及がいまいち、かつ今は、補助金などで運用しているとのこと。。

　うーん、こんだけ、ネットやケータイが発達してるんだから、むしろ、ネットで放送して、それを見てもらうとか、ケータイで流すとかしたら、どうだろう。
　情報量をとるようにできれば、お金もはいってくるし。。

　聴覚障害者にとって、ケータイは便利そうだし（って、耳が聞けないのに、なぜ！という人に。メールを使うっていう話を聞いたことがある）。

　また、聴覚障害者以外でも、ケータイで動画放送をみる、情報料でお金を回収するっていうのは、アリな気がする。。

朝日新聞支局長の年収“Winny”で流出、４０代後半現在１９００万円、５５歳まで上昇

ここの痛いニュース
朝日新聞支局長、巨額給与・“年収１９００万円”　赤裸々情報“Winny”で流出　「取材源教えろ」と夕刊フジに
http://blog.livedoor.jp/dqnplus/archives/899644.html
（元ねたは、ここ）
によると（以下斜体は上記痛いニュースより引用）


朝日新聞支局長（４０代）の個人情報がファイル共有ソフト「Ｗｉｎｎｙ」（ウィニー）で流出したことが１５日、分かった。

（中略）

その中に支局長の全資産が事細かに記入されていた。
中でも驚くべきは「現在の年収約１９００万円」。現在、支局長は４０代後半だが、５５歳まで上昇するという。

（中略）

ピークの年収は「２１００万円」。その後、「年約１７５万円減少する」と記載されているが、
６０歳で定年退職すると「３０００万円（見込み額）」。さらに退職後は企業年金などで
「７００－１０００万円」の年収があるという

（中略）

流出文章によると、支局長は都内にマンション（約６１００万円）を購入しているが、家族は
公団の賃貸マンションに住ませ、所有マンションは住宅ローン返済のため賃貸に出している。

支局長は４人家族。今年から２年ごとに１００万円をかけて家族で海外旅行に行く予算”
までもが流出文章に記されていた。


で、このWinny漏洩について


支局長は夕刊フジの取材に、「家計情報は別にして教授には迷惑をかけてしまった。これはやばいなぁ。
（前任地の）メールを自宅に転送したもので、自宅のパソコンにウイルスが感染したかもしれない」と応じた


と語っているそうです。

っていうか、そんなに、お金持ちなら、Winny使わないで、
ちゃんと、ソフトやコンテンツを買いましょう！！

こー言う人が、格差社会とか、Winny問題とか書いても。。。ねえ（－＿－；）

電子政府関係をまとめたページを作ってみました

　いままで、電子政府のことを書いてきたので、
　せっかくだから、その内容をまとめたページを作ろうと、
　いろいろまとめたページをつくりました。

ここ
EAと電子政府
http://www.geocities.jp/xmldtp/index_ea.htm

内容は、こんなかんじ
・電子政府やEA関係のリンク
・独断と偏見による変遷
・最適化計画関係を批判したもの
・ウィリアムのいたずらがいろいろ書いたこと（ブログ）
などなど。。

EAについては、今後、もちょっと充実するかも。。

クラス図に落とし込むには、先にフレームワークが決まらないとできない。

　ＤＯＡやオブジェクト指向の図を業務をまとめたシートと、入出力についてまとめたシートをつかってつくるというシリーズの続きです。

　現在
　ＤＯＡの
　　　・ＤＦＤ
　　　・ＥＲ図

　オブジェクト指向の
　　　・アクティビティ図
　　　・ユースケース図

　については書きました。

　で、今度は、クラス図になるわけなのですが。。。

---

■クラスは、いろいろなものに対応してしまう

　業務のシート１枚に対して、クラス１個が対応するなら簡単なのですが、
　実は、そうは行かないのです。

　業務は、本来メソッドなので、それは、メソッドになってしまうのですが、
　メソッドも、クラスになることがあります。
（イベントはクラスとなりえるので、イベントに相当するメソッドは、クラスになることがあります）

　さらに、シートにおいて、受注というのが１つのシートにまとまっている場合、
　それは、受注という画面があって、子アクティビティは、それぞれの画面のボタン１つ１つというケースもあります。
　さらに、受注の親に営業なんていうのがあると、それはもう、コンピューター化されないので、なにもないっていうことになります。

　つまり、シートは、

　・コンピューター化されない
　・メニュー画面になる
　・クラスになる
　・メソッドになる

など、いろんな可能性があります。

　さらに、そのシートのアクティビティと、子アクティビティの関係を見ると、自分がクラスの場合、子アクティビティがクラスやメソッドなら話は簡単なのですが、そうとも限らず、たとえば、受注で、子アクティビティに受注入力画面とあって、Strutsを利用している場合、それは、自分とは関係ない別のActionクラスとなってしまい。。などなど、

　親子関係もはっきりしません。

---

■業務とクラスの対応関係は、フレームワークによって決まってしまう

　じゃあ、業務とクラス図の関係って、どーなるんだという話ですが、
これは、フレームワーク（方式設計、アーキテクチャ）で決まってきます。

　たとえば、Strutsを使う場合、画面部分と、そこから呼び出されるクラス関係は
Strutsで規定されます。
　したがって、業務のなかの、呼び出される部分は、このStrutsのActionクラス
ということになります。

　で、残りの部分に関して、今度は、
　　　データベースの部分は？
　　　帳票の部分は？
　　　機能はSOAでやる？
　ってやっていって、さらに残った部分に関して、どのようにクラス化して
いくかの方針をきめて。。。

　ということになります。

　その際、重要になるのが、入出力のシートになります。

　そして、フレームワークが変わると（StrutsでなくAWTでやる場合など）
クラスやメソッドの関係も変わります。
　たとえば、上記の例だとAWTに変われば、StrutsのActionクラスは、画面の
内部クラスのメソッドになる可能性もあります。

---

　ということで、クラス図を決める前に、本来は、フレームワークから入っていくことになります。このフレームワークが決まらないと、（決まらないで詳細化すると、決まらないうちに画面なんかを適当に決めてしまうと）あとで、「こんなもの作れない！」とか、「ここにコレが必要なので仕様変更！」などということが、頻繁に起こり、システムは崩壊に向かいます（と、思います。ウィリアムのいたずらの経験では。。。）。

オブジェクト指向か、データ中心指向かより、利用者指向かのほうが、大事だと思う

　といっても、今までのような文脈での利用者指向ではないんだけど。。
　以前、このブログで、EAのように、トップダウンでやる場合、これはEAじゃなくってもDOAでコンテキストダイアグラムを書く形でもいいんだけど、

　とにかくトップダウンでやると、
　実際には範囲が広すぎて、発散してしまい
　システムがにっちもさっちも行かなくなる

ことがある。ってことを書いた。で、そこでは書かなかったけど、これで無理やりやろうとすると、えいや！と適当に決めることになるので、後で仕様変更で矛盾、それを直すと違うところで矛盾、とかなって、デスマーチになってしまう。

---

　で、これを防ぐために、

・外部の体系化、つまり、利用者を体系化して
・そのなかで、自分の扱える範囲でやっていき
・一通りできたら、さらに範囲を広げるというようにする

　って書いた。で、その例として、税金のケースについて書いた。

　今日は、こいつをまとめて、利用者指向で考えた場合、システム化のはじめは、どういうふうにするかってことを考えてみたい。

---

■利用者指向のシステム開発－その１：利用者を体系化する
　まずはじめに、トップダウンで内部から考えるのでなく、会社なり、システムなりの外部からデータ入出力してくれるものを考える。

　会社の場合、お客さん、システムの場合、利用者がメインになるが、それだけではない。
　会社なら仕入先も、外部要因、国家や銀行も外部要因だ。
　このように、従来の利用者指向よりも、幅を広げて、まず、外部からの入出力となるものを考える。

　ただ、利用者といっても、いろんな種類がある。
　そこで、あとで、対象範囲を区切りやすいように、利用者を体系化する。

　この体系はさまざまに作れるし、ここがセンスであり、経営の最重要課題の１つとなる（経営の最重要課題の１つは、顧客の定義と理解である。それができてはじめて、顧客への提案、顧客満足というのが成立する）。

---

■利用者指向のシステム開発－その２：システムで扱う範囲の利用者を限定する

　ここで、先ほど対象化した利用者から、今回のシステムで扱う利用者の範囲を限定する。
　これを幅広くとってしまうと、トップダウンのときのように、手に負えなくなって、栄屋と適当に決めて、矛盾が起こることになる。
　幅を狭く取ると、だんだん広げていく作業のときに手間になる。
　ただ、広すぎるよりは狭すぎるほうが、ぜんぜんましである。

　なので、自分が扱える範囲より、狭めにとる

---

■利用者指向のシステム開発－その３：利用者のシナリオを完結させる

　そして、自分が扱える範囲の利用者まできたら、まず、会社やシステム全体の中身をブラックボックスにして、利用者と、その会社やシステムのやり取りのシナリオを作る。

　たとえば、所得税だったら、税務署の中はさておき、納税者が、申告書を受け取り、資料を集めて申告、納税するまでのストーリ（シナリオ）をつくり、完結させる。

　そして、それをもとに、利用者に対する便宜提供などが提案できれば、それをカイゼンしていく。

　こうすると、会社やシステム全体と利用者の入出力のやり取りができる。

---

■利用者指向のシステム開発－その４：システム最上位の図をつくる

　これで、システム全体と利用者とのやり取り部分ができる。
　データ中心ならコンテキストダイアグラムができる、
　オブジェクト指向なら、最上位クラスとなる。そして、このときのユーザーとのやりとり（＝メッセージ交換）が、最上位クラスのメソッドとなる。

　そして、その利用者と、そこでやり取りするメッセージで出てくるものが、エンティティになる（DOAだと。オブジェクト指向だと、これもクラスになる）
　

---

■利用者指向のシステム開発－その５：利用者から入力を受け取ったらどうするの？

　で、最上位のクラスなり、DFDなりができたら、今度内部を考える。
　その際は、まず、利用者からその情報（申請書なり納税のお金なり）を、システム・会社のだれが受け取り、受け取った後どうするの？のシナリオを作成する。

　シナリオというのは、実際には業務内容になっていく。
　その際に、業務をまとめるシートみたいなかんじでまとめていけば、後の展開は、いま、業務のシートをいろんな図にする方法を書いているけど、そこの方法で、オブジェクト指向にしろ、データ中心指向にしろ、ブレークダウンして、図がかける。

---

■利用者指向のシステム開発－その６：利用者の範囲を広げる

　それで、ある程度のところまで、ブレークダウンできたら（十分見えてきたら）、今度は利用者の範囲を広げて（他の利用者にして）やってみる。
　もう、ある程度の枠組みができているので、それに追加するか、修正するかとか、の追加削除を考える。

---

このように、トップダウンの場合、利用者から見て、範囲を限定する必要があると思う。

そうしないと、システムの範囲を大きく切りすぎてしまう危険だけでなく、
結局利用者は便利にならなかったり、逆に負担をかけてしまったりして
（すべてを電子化できず、電子化した部分と今までの部分の二度手間になったり）

システムができても、使ってもらえなくなり危険があると思う。

ってなかんじです。

　途中、オブジェクト指向でも、データ中心指向でも、どっちでも対処していたように、オブジェクト指向か、データ中心指向かより、利用者指向にする（外部入出で範囲を決めてしまう）ほうが、大事だと思います。

izaって、Ｗｅｂ寄りだと思ってたけど。。自費出版マンセーなの？？

ここのニュース
不登校の女子中学生、ファンタジー小説を出版
http://www.iza.ne.jp/news/newsarticle/natnews/topics/34708/
が話題みたい。
（その話題の様子は、痛いニュースで）
この文章を読むと、まるで、自費出版して、この（不登校の）女子中学生が
すごーい！！みたいに読めちゃうんだけど。。

ちなみに、その本は、ここ
魔法伝説 (単行本)
http://www.amazon.co.jp/exec/obidos/ASIN/4286018288/kimagureeigan-22/ref=nosim/
その写真のした、この本の中身を閲覧するで中身がちょっと見れる。

でも、自費出版で、８００冊を販売してるだけなんだよね。。
それって、すごいの？？

わるいけど、ウィリアムのいたずら、最近、１日で１０００ipを超えることがある。。
なんで、読んでもらっている人は、たぶんウィリアムのいたずらのほうが多い。
だけど、１銭もかかってない。
Ｗｅｂで公開したほうが安上がりだとおもうんだけど。。

（自費出版なら、本が売れれば儲かると思っている人へ。。
　自費出版の多くは、同人誌などでなく、本のカタチで出版する場合、
　たいてい、売り上げ以上に出版費用のほうがかかり、赤字となる）

izaって、新聞２．０とかいって、Ｗｅｂよりだと思ってたけど、
自費出版のほうをこんなカタチで取り上げるってことは。。。

やっぱ、出版のほうがえらいと思っているか、
あるいは、自費出版は、新聞社にとって、広告をだすスポンサーさんだから

ってことかな？