インターネットで音楽を流す際の著作権問題

　NHKは、ニュースだけでなく、語学番組とかも、インターネットで配信しようとしてますね。再放送が見れて便利便利。でも、インターネット配信で放送を流すと、音楽の部分の著作権の問題が起こりそう。もっとも、この問題、社交ダンスでも同じことが起きていて、自主制作の音楽を流してるみたいだけど。

　ちなみに、ＮＨＫが音語学番組を流すという情報は、[平成17年度 放送番組補完インターネット利用計画]
　ちなみに、そこに、「放送番組をインターネットで提供するに際しての著作権処理については、現在のところ、統一的なルールがないため」と書いてある。

　それと、社交ダンスの話は、./Jのダンス音楽は自主制作でJASRACを避けるに書いてある。

---

ということで、放送をインターネットで流すには。。。
やっぱり、コピーフリーの音楽を自主制作して、もともと音楽が流れているところを切って、「ここは、著作権の都合により、代わりの音楽を流します」っていって、そのコピーフリーの歌を流さないと。。。

---

　でも、もしですよ、そーいうコピーフリーの自主制作曲をつくって、そのＣＤを出して、売り上げランキング１位になったら、どーするんだろう。。
　いままで、ＣＤはコピーされるから売れないって言ってた人たちは！！

C99には、複素数型がある。Ｃ＋＋で足し算を引き算にするには

　土曜日、マクドナルドに行ったら、ＣとＣ＋＋について、あつく語っていた人がいた。
　で、その人が言ったことで、知ったことがあったので、備忘録。

　Ｃ９９では、複素数型が使える。
　http://seclan.dll.jp/c99d/c99d00.htm
　このページにも、詳しく書いてありますな。

　それと、Ｃ＋＋では、足し算を引き算の意味に定義できるって言ってた話。

　たぶん、いいたいことは、

　返り値の型　そいつのクラス::operator+(const int &a,const int &b)
{
　　　　　ひきざんのしょり
return けっか
　}

　ってことだと思うけど、そんなことして、なにが、楽しいんだ(^^;)
　

Wordで、テキストボックスを使わずに図の中に文字を入れる

Ｗｏｒｄで、テキストボックスを使わずに、楕円の中などに文字を入れる方法。

（１）楕円などを適当に書く
（２）左ボタンをクリック
（３）「テキストの追加」を選択
（４）文字が入れられるようになるので、好きな文字を入れよ。

WBSでのホリエモンの話と、この「コピーされるほど儲かるシステム」の考え方、近いかも？

　ＷＢＳの土曜日に、ホリエモンが言っていた話と、「コピーされるほど儲かるシステム」の考え方、意外と近いかも。

　ホリエモンは、「放送局の高価な設備を使わなくっても、ハンディカメラでも番組は取れるし、そういうものを配信していくことに意義がある」っていうような話をしてたけど、それは、「コピーされるほど儲かるシステム」の初めの方の話と同じだし、

　「放送は客をひきつけるため」みたいなことをＣＭ直前に言ってたけど、「コピーされるほど儲かるシステム」も、コピーフリーなものを広めて、有料コンテンツで儲けるという考え方なので、おんなじようなもの。。。

　つーことは、ウィリアムのいたずらは、ホリエモンを応援しないといけないのかも？？

システム開発の見積もり方法について、ブログ内で混乱していたので、まとめました

　最近のメルマガで、以下のように見積もりの話を取り上げています。

業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実
「コピーされるほど儲かるシステム」の場合の見積もり例
システム開発において、一番重要なのは、リスクヘッジだと思うね！
完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ。間違いない！
長井秀和のネタから考えると、中途半端にいろいろ知ってるユーザーのシステム開発が一番危険だ

　しかし、無計画に書いたので、話が混乱してしまいました。

　ちょっとまとめます。まず提案書を書くまでの内容の大枠は、「業務標準のマネジメント技法の幻想と、ソフト開発見積もりの現実」で書いた、以下のとおりです（不備もあるけど）。

（あ）まず、分かっている範囲の開発内容から想像して、各種要素技術
　　　に分解し、その技術を使って、ユーザーが希望するものが、出来
　　　そうか、読みきる。
　　　　　→読みきれなければ、それがリスクとなる

（い）手順、予算、期間は大体決まっていることが多い
　　　　　→そこで、それを、並べる

（う）（あ）を（い）の中に当てはめて、大丈夫かあ？って考える。
　　　　　→ダメそうだったら、それは、リスク

（え）（あ）や（う）で起きたリスクを他のものに置き換えられないか等、
　　　　リスク回避の対応策を考える。

これが基準です。
　でも、（い）だけやっても、実は、それらしい見積もりがかけてしまいます。
　その例を、今度のメルマガ（１３話）で示します。

　現実問題として、現場がわかっていないマネージャーが見積もりを立てる場合、（あ）、（う）、（え）はできません。したがって、そのような人が作成する場合、（い）だけの作業をした見積もりがでてきます。
　この危険性についても、１３話で述べます。

---

　で、（あ）のやりかたについてですが、これは、「完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ。間違いない！」に書かれている、
（あ－１）まず、ユーザーの利用の仕方の絵を書く
（あ－２）つぎに、その絵を実現するための技術を書く
（あ－３）その技術を実現する手順の絵を書く
になります（ブログでは、（１）、（２）、（３）とかいてありますが、あとあとの説明のため、（あ－１）、（あ－２）、（あ－３）と書きます）。

　実際の開発では、この（あ）の部分について、ユーザーと話し合いますが、そのときの現場で起こる問題点が、「長井秀和のネタから考えると、中途半端にいろいろ知ってるユーザーのシステム開発が一番危険だ」になります。

---

　で、「 システム開発において、一番重要なのは、リスクヘッジだと思うね！ 」で挙げられている、以下のやりかたは、

　（１）ＲＦＰを実現するには、どんな技術を使うか
　　→これが、思いつかないようなら、あなたに、その仕事は出来ないはず。
　　　即、逃げることを考えよ

　（２）それを、実際やったとしたら、どんなふうになるかのシナリオを作る

　（３）そのシナリオが描けなかったら、それはリスク
　　　　→他のやり方で実現できないか、考え直す（２）へ

　（４）そのシナリオどおりやって、予算、期間的に間に合うか。
　　　　間に合わなかったら、それはリスク
　　　　→他のやり方で実現できないか、考え直す（２）へ

　（５）それは、ＲＦＰで言っている要望を満たしているか
　　　　この満たしているとは、言っていない要望も含む
　　　　満たしてなかったら、それはリスク
　　　　→他のやり方で実現できないか、考え直す（２）へ

（１）が、上記の（あー２）、（２）が、（あー３）になります。
（あー１）の部分は、書き忘れました(^^;)。

で、（４）は、（う）と（え）に該当します。（５）は、（え）のあとにやる作業です。
（かきわすれました ^^;)

---

結果として、まとめると、こんなかんじになります。

（あ）要素にわける
　　　（あ－１）まず、ユーザーの利用の仕方の絵を書く
　　　（あ－２）つぎに、その絵を実現するための技術を書く
　　　（あ－３）その技術を実現する手順の絵を書く

（い）手順、予算、期間は大体決まっていることが多い。
　　　　　→そこで、それを、並べる
　　　なお、（あ）と（い）は、入れ替え可能。どちらが、先でも良い。

（う）（あ）のシナリオどおりやって、予算、期間的に間に合うか、
　　　大丈夫かあ？って考える。
　　　　　→ダメそうだったら、それは、リスク

（え）（あ）や（う）で起きたリスクを他のものに置き換えられないか等、
　　　　リスク回避の対応策を考える。

（お）で、大体システムが思いついたら、それは、ＲＦＰで言っている要望を
　　　満たしているか、もう一度確認する。
　　　→みたしてなかったら、他の案を検討する。

---

「「コピーされるほど儲かるシステム」の場合の見積もり例」で示した見積もりのしかたは、だめだめな例としてあげました。
　（あ）もどきを行い、（い）を中心におこなったものです。
　まじめに、（あ）の分析をしていない、かつ（う）以降をなにもやっていないものです。

　でも、だめだめ加減がたりません。

　もっと、だめだめな例を１３話のメルマガで示します。

　でも、一番問題なのは、そんなだめだめな見積もりを仮に作ったとしても、ユーザーは気がつかず、その提案に乗ってしまうことなんだけどね。

放送とＩＴの融合トーンダウン！？本当なら、ライブドアをどこかに買収してもらうしかない

ライブドアの放送とＩＴの融合の話。

このブログでも、いろいろと取り上げたのに、なんか、トーンダウンしてるらしい。
（以下の掲示板の記事によると）。。。
http://messages.yahoo.co.jp/bbs?.mm=FN&action=m&board=1004753&tid=a5aaa5sa1a6a56a1a6a5a8a5ca5b&sid=1004753&mid=482326
http://messages.yahoo.co.jp/bbs?.mm=FN&action=m&board=1004753&tid=a5aaa5sa1a6a56a1a6a5a8a5ca5b&sid=1004753&mid=482370

本当なら。。目からビーム！
うーん、放送とＩＴの融合をやると思ったから、期待したのに。。。

かくなるうえは、
・リーマンは、ライブドアの社債を株に転換するから、
・その株をどこかの会社が買い占めて（時間外取引で ^^;)
・その会社が放送とＩＴの融合をやっていただく
しか、ありませんな。
　それが、一番無難なおとしどころでしょう。

　ちなみに、計算上、それが可能！ってことを示しているサイトがあるみたいね。
http://www15.ocn.ne.jp/~hiro-hmx/mscb5_4753_3.htm
（一番最後のほうの「と言った愉快な事態を起こせる可能性がある事を示しております
」の前に書いてありますね）

　じゃあ、どこが、ライブドアを買収してくれたら、世の中のためになり、フジも納得！放送とＩＴの融合が、実現するか。。。

　フジが増資する前は、フジがリーマンからライブドアの株を買ったら、面白くなると思ったんだけど、その可能性はなさそうなので。。。


　　　　　　　　　やっぱ、ソフトバンク？

　日テレの読売ジャイアンツに対抗して
　フジのソフトバンクって、どうかしら。これならフジもニッポン放送も提携しやすい・・・

　って、あんまりコンピューターに関係しなくなったから、今度、暇なときに、本家にかきますね。

長井秀和のネタから考えると、中途半端にいろいろ知ってるユーザーのシステム開発が一番危険だ

　前のブログで、 「完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ」って書いたけど、たまに、どーいうシステムを作りたいのか、ノーヒントのお客さんがいるんだよね。

　なんか、営業とかに吹き込まれたらしく、
　「Ａｃｃｅｓｓで業務をつくりなおしましょう」
　とか、
　「何部と何部の情報共有」とか。。。

　まあ、私のお客さんにはまだいないけど、「ナレッジマネジメント」とか、「ＳＦＡ」とか「ＣＲＭ」とかを、唐突に言う人も、この部類なんだろうね。

---

　話が、ほとんど目標と夢で、実際の業務内容（手順）が話せないとき。
　仕方ないから、こっちがいろいろと、こんな感じ？とか聞くんだけど、「違う違う！」と文句ばかり言うケース。

---

　長井秀和のネタに、「母親が、テレビを見てて、ほらほら、あのひと、だれだっけ？というのに気をつけろ」っていうのと、おなじ感じで、

　ほとんど、どんなシステムなのか
　「ノーヒントだ！」

　で、こんな感じ？？って聞くと、
　「ちがう、そーいうかんじじゃないのよね」

　っていわれる。

---

　こういう、なにをやるのかの手順を語れないのに、キーワードや技術用語を並べるケースは、できるだけ逃れたほうがいい。
　ものすごく、リスクが高いケースだ。

　前に書いたように、リスクの見積もりは、完成シナリオを描いてそこから分析する。
　完成シナリオが描けない、このケース（目標や夢は、シナリオではない。目標や夢を実現して、なにをしたいのかが、完成シナリオ）は、当然、リスキーだ。

---

　逆に言うと、やる内容がはっきりしていて（入力と出力がはっきりしていて）なんの技術を使ってもいい場合は、成功しやすい。完成図がイメージしやすいから。

　つまり、キーワードや技術用語を並べられる、中途半端にいろいろ知って、わかってる（ひどい場合、自分がコンピューター通だと思ってる）ユーザーのシステム開発が一番危険だ。

　ちなみに、本当にシステムを知っているユーザーとは、自分が何を知らないかを知っているユーザーだ。

完成後のシステムの使用方法（シナリオ）が読みきれるかが、システム成功の鍵だ。間違いない！

　前のブログで、「ぜーんぜん決まってないとき（ＲＦＰ段階など）の見積もり例」っていうのを示しました。
http://blog.goo.ne.jp/xmldtp/e/549962a4b3b56339747e748af40d5078

　で、そこで、スケジュールのたてた「期間で、できそうかっていうことを考えて、リスクがあればヘッジするわけです」と、かきました。
　今回は、そのやり方について、一般的に述べます。

---

　私の場合、システムが完成したとき、使用する流れ（＝業務のながれ）をまず考えて、それが想像つくか？とはじめに考えます（ただし、かなりおおざっぱです）。
　これが、考えつく場合とつかない場合でリスクの度合いは、相当違います。

　考えつかないときは、技術的な要素に基づいて、その技術を使って開発できるか？とかんがえるんですが、先が見えない仕事をやるわけですから、かりにその要素技術のやり方が見えても相当危険です（はじめに想定しないものが出てくる可能性がある）。
　フリーのウィリアムのいたずらの場合、断る権利がある場合、こういうケースでは、なにか適当な理由をつけて断ります。

---

　完成後の使い方の流れが思いつくときは、それを実現する技術（方法）を考えます。

　で、その方法がきまったら、その方法を実現する手順を考えるわけです。
　で、この作り方が思い浮かぶ場合、大体、このリスクは限定的になります。
　作り方が思い浮かばなかったり、日程などで無理な場合は、他の実現方法を考えて、入れ替えます。

---

　つまりですね、一言で言うと、

（１）まず、ユーザーの利用の仕方の絵を書く
（２）つぎに、その絵を実現するための技術を書く
（３）その技術を実現する手順の絵を書く

ということです。
　（１）は、（コンピューター用語で）シナリオと呼ばれています。
　シナリオというと、演劇などでもやりますよね。
　そう、システムをつかってはじめから、最後までやる小芝居をつくるかんじです。
　そんな感じでやるかというと、（コンピューターシステムには、関係ないんですけど）、ここの「台本ができるまで」に似ています。
　ウィリアムのいたずらのメモも、ひらがないっぱい。
　そのブログの中に、「頭の中で自分以外の人間二人が会話してるなんて、ちょっと危険ですよね」ってありますけど、シナリオを考えてるウィリアムのいたずらも結構危険かも。


　で、（２）、（３）は、（１）がしっかりしていれば、あとは知識だけです。これは、専門技術なんで、知ってるか知ってないか、やったことあるかないかっていう感じの世界です。
　ウィリアムのいたずらの場合、（１）が出来ちゃうと、（２）、（３）は、無意識に頭に浮かんできて、浮かんでこないと、「やばい！」と判断しちゃいます。


　つまりですね、システムを使ったシナリオの絵が書けるかどうかが、すべてです！
　これが、かけなかったり、ぶれたりすると大変なことになり、火をふいちゃいます。
　逆にこれがばちんとはまれば、どーにか、押し込めますね。

放送とＩＴの融合、ただしＩＴのＩは、投資のＩ

　ニッポン放送の新株予約権の話。もし、フジテレビが、全部転換したらニッポン放送株６６％取得できるっていうじゃない。でも、ライブドアが買い進めて「少数特定者持株数」の割合が一定数になったら上場廃止になっちゃいますから。残念！結局、泥沼はまりっぱなし斬り？？

　ライブドア、その辺のことを考えて、買い進めてるのかな？
　（上場廃止には、しないだろうと。。。）
　さらに、フジが転換し始めたら、ニッポン放送の株を、売りかけて、価格を下落させて、大株主のフジの資産を痛めるとか。。でも、それって、（ニッポン放送株を持ってる）ライブドアの資産もいたんじゃうけどね。
　世間では、裁判へ舞台が移ったというが、そーかんたんに、この問題、いきそうもないですね。持久戦なのかな。。。

　ちなみに、「少数特定者持株数」の割合による、上場廃止基準はこちら。
http://www.tse.or.jp/cash/stock/stlisting_b.html

---

てなはなしを、ウィリアムのいたずらは、したいんじゃなくって、
こーいうのをみると、やっぱり、ＩＴ業界のＩは、
　　　　情報（Infomation）のＩじゃなくって、
　　　　投資（Investment）のＩ？？
　なら、今回のフジとライブドアの話は、放送とＩＴの融合！
　（ただし、ＩＴのＩは、投資のＩ）

ＮＨＫ受信料でも、動きがあったみたい。

前のブログに、放送とＩＴが融合していったら、ＮＨＫの受信料の枠組みもあぶない（テレビを使わなくても、インターネットで見れたら、テレビを買わない＝受信料が取れない）と書いたけど、

　いやー、進展が早いですね。

　きのう、「ＮＨＫ受信料制度、麻生総務相が見直し検討を表明」なんていうニュースが出てたみたい。
http://headlines.yahoo.co.jp/hl?a=20050222-00000504-yom-bus_all

たしかに、その文にあるように、「携帯（端末）や自動車でも（テレビが）見られる時代」になったら、受信料とるのもたいへんですよね。

　ケータイでテレビが受信できるからって、受信料を取ろうとしたとたんに、
　ケータイを隠されて、「もってないよ！」って言われたら。。。。
　身体検査する権限は、ＮＨＫの集金の人にはないし。。。

　自動車に、テレビが搭載されているということを知っても、
　「はらってくださーい」って、自動車に入ろうとしたとたんに、
　ビューんと急発進されたら、
　まさか、西部警察みたいに、ＮＨＫの集金員が、自動車のボンネットの上に乗って、
　「はらってくださーい」
　といい続ける。。。のは、危険すぎます(^^;)

　おまわりさんでも、身の危険を感じたら、逃げる時代です。
　そこまでやれないでしょう。。。

　そうすると、携帯と自動車には、課金できない。。。っていったら、不公平ですよね。
　うーん、思ったより、難しい問題なのかも、受信料の徴収って。

２月２３日「コピーされるほど儲かるシステム！開発日記」は、ＲＦＰ受け取り後の話です

　２月２３日「コピーされるほど儲かるシステム！開発日記」の１２号を出します。

　内容はＲＦＰ（提案依頼書）をもらってから提案書を書くまでの間の話。

　この間に、たいてい、見積もりをして、それらしいことをしなければならないことが多いんだけど、そのとき、ウィリアムのいたずらは、どうやって考えているかについて書きました。

　内容は、このブログの「システム開発において、一番重要なのは、リスクヘッジだと思うね！」
http://blog.goo.ne.jp/xmldtp/e/97d74bbb80eaa6bfd15e1f5035b4eb7b
を上記の視点でまとめなおした感じです。

---

で、ちょっとタイムリーな話を、お客さんとしたんで、その話。
プロジェクトの開始って、どこからなんだろう(^^;)

今回取り上げた、RFPから提案書までって、本当はプロジェクトの始まりじゃないです。
結構見積もりだけっていう話も多いから。。。

　でも、実は、プロジェクトの金額、期間というのは、提案書に左右されてしまうので、プロジェクトとして一番大事だったりする。。。
　なので、そこの部分を管理しないと、問題プロジェクトが山済みになってしまうのだ！

　つまり、プロジェクトは、開始の時点で、「おまえは、もう死んでいる」と、いう感じのものもあるというわけ。。。

　なもんで、本来、プロジェクトの開始をＲＦＰをもらった時点から取るのは、おかしいんだけど、今回のメルマガでは、あえてそこをプロジェクトの開始ととらえ、ここから書き始めることにしました。

---

で、１２号のメルマガについての、感想などはここの「コメント」にどうぞ！

　メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム！開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参照してください

ユビキタスと放送が結びついても面白いよね

　放送とＩＴの融合で、さらに、ユビキタスとむすびついてもおもしろいよね。
　いつでも、どこでも好きなテレビ放送が見れるとか。。。

　さっきのＮＨＫの語学講座も、まあ、「１００語・・・・」はあんまり見ないけど、たとえば、英語リスニング入門が、携帯サイトからも、聞けるようになると、いつでも、どこでも、英語リスニング入門ができるようになるので、ウィリアムのいたずらは、カセットに、とっていなくて良くなる。

　あと、地方競馬にも、追い風かも。。。携帯電話から、地方競馬の実況が聞けたり、さらに、携帯電話から、馬券が買えたりすると、地方競馬もさかんになるかも。。。

なんて書いたら、逆にＮＨＫが、インターネットと放送を融合してきたよ(^^;)

　午前中、 「ホリエモンのニッポン放送買収をマネーゲームと報道するから、放送とITの融合の威力が見えない 」と題して、インターネットで放送局が配信し始めたら、ＮＨＫは（受信料取れなくて）たいへんじゃん。
って書いたけど、逆にＮＨＫのほうが、テレビ放送をインターネット配信しはじめるみたい(@_@)

　おお、これがすすめば、さっきのブログで、「ビデオで録画しておく必要も無い」って書いたけど、まさに、語学番組なんか、聞き逃しても大丈夫！！
　と、期待してみたら、語学関係は、「100語でスタート！英会話」と、「えいごリアン」だけみたい。。。


　　　　　　　　そんなけちなこといわず、すべての外国語でやってくれー！


　「ロシア語講座」の「さとう珠緒」っていうのが、みてみたい。。。
　（あれ、今やってるのかな？？）

ホリエモンのニッポン放送買収をマネーゲームと報道するから、放送とITの融合の威力が見えない

　もし、放送とＩＴが融合すると、今までの、電波を使った放送の枠組みや、ＮＨＫの存立基盤自体が崩壊する。
　ホリエモンのニッポン放送買収は、それほど大きい威力をもっている話なのに、みんな、堀江社長ＶＳフジテレビのマネーゲームといった小さな話にしちゃってるね。。。
　ホリエモンもフジテレビも、あんまりにも、そのへんの議論をしないので、ウィリアムのいたずらが、勝手に議論してさしあげましょう（＾＾）ｖ

---

　放送とＩＴが融合するっていうことは、つまり、

　　　　放送局の制作した番組がＷｅｂで見れる

つーことですよね。

　こんなの、サーバーにコンテンツを置いておくだけでできますよね。
　WBSとか、いまでも、動画でみれるし。。。

　そうすると、ですよ。いままで電波の制約があったから、地方局の番組は見れなかったけど、インターネットなら地方局の番組も見れるわけです。
　さらに、昔の番組も、好きなときに見れる。
　WOWWOWやスカパーのようなＢＳや、ケーブルテレビの番組も、加入してない人でも、見たい番組だけ見て、その番組を見た分だけ課金されるという仕組みができる。

　そうなると、どうなるのか

---

　いつでも、昔の番組がインターネットで見れるなら、ビデオで録画しておく必要も無い。
　さらに、地方局でも、面白い番組（「水曜どーでしょう」とか？）があれば、全国規模で見られる。それに課金すれば。。。地方局のあらたな収入源になりますよね。

　さらに、視聴率って言う点で考えると、いままでは、在京キー局がその時間に流す番組だけが競争相手だったのに、今度は、地方局や自社の昔に流した放送までも、競争相手となる。

　逆に、初め放送したときには人気無かった番組（＝視聴率が低かった番組）でも、あとあとになって人気になって、みんなに見られるってこともあるかもしれない。そんな番組に宣伝をいれたら。。。ずーっと使えるＣＭだったらお得だけど、何日にバーゲンとかいうＣＭなら、意味ない。。
　つまり、視聴率とか、ＣＭの考え方も変わってくる

---

　さらにですよ、ＮＨＫの受信料って、テレビがあることが前提ですよね。

　でも、各放送局で、インターネットで流したら、そのうち、パソコンがあればいいやっていうことになり。。。

　　　　テレビを買わない
　　　　　＝ＮＨＫの受信料を払わない
　　　　　＝ＮＨＫの存立基盤、あやうし(^^;)

　てことにならないかなあ。。。

---

　ちょっと、ＩＴっぽい話にすると、最近、SOA(サービス指向アーキテクチャ)のからみで、Webサービスの話が話題になってるけど、どこの放送局が、いつ放送したのかをユーザーがまったく意識しないで、アクセスできる仕組みが、Webサービスとして実現できれば、これは、地方局やＢＳのあらたな財源となるし、番組の作り方もかわるんじゃーないか。

---

　その第一歩として、ライブドアがもし、ニッポン放送の今＆昔のラジオ番組（オールナイトニッポン）などを、サーバーにアップして、有料コンテンツとして流したら面白いよね。

　もし、その枠組みが成功したら、他のポータルサイトでも、地方局やケーブルテレビ、地方ラジオ局の番組なんかを有料（もちろん無料もありえるけど）で流しだすんじゃないかな？？

---

　っていうビジョンをホリエモンが出さないから、ニッポン放送買収劇が、マネーゲームのような小さな話で終わってしまう。

　プロ野球が変わったように、ホリエモンが、どうのこうのにかかわらず、放送業界もぜひ、ＩＴを利用して、電波の枠組みにとらわれず、変わって欲しいものだ。

VNCViewerのJava版をWindowsで動かす方法

あるパソコンの画面を、ほかのパソコンの画面からのぞいたり、操作したり
するソフトとして、VNCがあります。

なんに使うの？っていうと、たとえば、

　　　　　　「奥さんの行動が怪しいとき」！！

ADSLを使って、動的にアドレス振られてるから大丈夫！と安心してる奥さんに
　　・こっそりと、奥さんのマシンにVNCサーバーをインストールして、
　　・IPConfigした結果を、ご主人に知らせるバッチプログラムをつくり、
　　・それを、起動時に動くようにしておくと、
だんなさんは、VNCViewerを使えば、奥さんの行動（パソコンでのやりとり）が手に取るようにわかり、不倫しそうになったら、邪魔することができるというソフト。。。


　って、そういう使う方する人は、少ない、


　つーか、いないと思うけど。。。


とにかく、離れたところから、ＩＰアドレスを指定して、端末を監視、操作できるというソフトです。

---

で、そのソフト、
　　・サーバー（上の例だと、奥さんの端末に入れるほう。監視される！ほう）
と
　　・ビューワー（クライアント。監視するだんなさんのほう）
があります。

　で、サーバーは、いいとして、クライアントのVNCViewerには、Java版というのがあります。。

　おお、Javaで見れるなら、どんなプラットフォームでも、実行できて、さらに、拡張できて、いいじゃん！
　と思うかもしれませんが、実際に、そのソースのMakeFileをみると、cp コマンドとか書いてあって、Linux向きです。

　なので、Windowsで、Java版を使いたい！場合のメモ

---

コンパイルのしかた

前提：Javaは入っていて、パスは貼ってあるものとします。
　　　つまり、どこのパスでもjavaやjavacを実行できる状態。

（１）VNCのJava版を、ダウンロードしよう。
（２）そうすると、「vnc-4.0-javasrc」とかいう、ソースのフォルダの下に、ReadMeとかMakefileとかある。
（３）（アクセサリの中にある）コマンドプロンプトで、（２）のフォルダに行く
　　　(cdする）
（４）以下のように３つ、実行するのだ
javac rdr\*.java
javac rfb\*.java
javac vncviewer\*.java
（５）なんか、「ふるいコマンドを使ってる」とか言うワーリングが出るが、無視

実行の仕方

前提：Java入ってて、パス貼ってある。コンパイル終わった

・（３）のフォルダに行こう（cdする）
・次のコマンドを打とう
java vncviewer/VNCViewer

　ちなみに、ログは、画面上に表示される。デバッグモードまでのログを出したいなら
java vncviewer/VNCViewer -log 100

ログに時間を出したい

　しかし、これでは、奥さんの監視には不十分です！

　　　　　ログに時間がでません。

　そんな、あなたは、ここを修正。
　rfb/LogWriter.java

　プログラムみると、vlogっていうのが、いろいろ出てくるけど、それがこのログ。。だと思う

切断時間を知りたい

　でも、監視にはまだまだです。なぜなら、

　　　　　　　切断時間がわかんないからです。

　どうするか。。。

　接続と、切断は、vncviewer/CConn.java　に書いてあります。
　そこのメソッドのpublic void close() が、切断してコネクションクローズするとこなんで、そこに適当に書く

　接続は、vncviewer/CConn.javaの中のメソッドpublic boolean initで、
sock = new java.net.Socket(serverHost, serverPort);
vlog.info("connected to host "+serverHost+" port "+serverPort);
ってやってるところがあるよね。そこで接続してるので、vlog.infoのあと、適当にアレンジして、時間でも追加して、書いておけばよい

---

　これで、奥さんの監視もばっちし！

　でも、「僕の愛は深くて、奥さんだけでなく、愛人も監視したいんだよ！」っていう人には、multi VNCってのがある。

　って、multiVNCは、愛人監視ソフトじゃあ、ないんですけど(^^;)

もっと、まじめなソフトです。

　ちなみに、今日、書いたのは、
　　　ウィリアムのいたずらの愛人監視のためでなく（当然）、
　　　ましてや、ストーカーをやるとか、
　　　探偵業に転職するためでもなく（なおさら当然）
　ちょっとvncViewerを修正して、セッションの開始終了時間を出すことを頼まれていたので、その調べたことを忘れないようにメモしたかったからだけです。