YouTubeへの対抗策は、「融合放送」なのか？というか、融合放送に問題はないか？

ここのニュース
YouTubeへの対抗策となる「融合放送」を提案～野村総研
http://internet.watch.impress.co.jp/cda/news/2006/11/17/13985.html

というので、Ｙｏｕ　Ｔｕｂｅのロングテール戦略に対して、ロフティヘッド（上位以外しか相手にしない）という戦略をだし、Ｙｏｕ　Ｔｕｂｅの対抗策として、融合放送という概念を打ち出した。

それは、こんなかんじ（以下の斜体は上記ニュースからの引用）


　融合放送を実現するための主な要因は、
1）放送免許を持つこと、
2）自主制作であること、
3）配信側がタイムテーブルを組むこと、
4）放送規律を守ること、
5）通常の動画再生ソフトで視聴でき、DRMを使うこと、
6）オープンかつコミュニティ性のあるネットワークで配信すること、
7）広告収入であること。


この考え方、かなり問題ないか？っていうことについて考えます

---

■そもそも、インターネットに免許って、ありえるのか？

　つまり、「インターネット上でも放送規律を守る会社に対しては、放送免許を付与することができる。と、なぜ断言できるのか？

免許というのは、
　「いったん全員を禁止する」
　「しかし、例外的に、何かの条件を満たしたものだけ、その禁を”免”じて”許”可する」
から、免許って言うんだよねえ。。

・日本では、拳銃をもってはいけません
・だけど、猟銃の免許を持っている人はＯＫです。

とか、

・日本では、勝手に車を運転してはいけません
・だけど、車の免許を持っている人はＯＫです。

とかとか。。

そうすると、いったん禁止するっていうことになって、この場合、禁止する理由がある。
たとえば、拳銃をもってはいけないのは、拳銃をみんなが持つとあぶないから。
勝手に車を運転してはいけないのは、車を操作できない人が、運転するとあぶないから。

で、放送についてなんだけど、これは、電波の希少性ということから、言われている
つまり、
・同じ地域で、同じ時間に放送すると、みんな混信して、なにいってんのか、わかんなくなる
・なので、いったんみんなだめＸとして、
・その中で、同じ地域で、同じ時間に放送する人を規制する
という免許制をとっている。

だから、混信することがまずないような、微弱な電波は、免許を持たなくてもＯＫっていうことになっている（トランシーバーやラジコンなど）。

　で、インターネットだが・・・
　
　うん、なんで、免許なんだ。。

　つまり、いいかえると、なぜ、この「融合放送」を、免許を持ってない人がやっちゃいけないんだ？？？

　べつにいいじゃん。タイムテーブル作ってＣＭとって、ＤＲＭつきの動画を流して、国ではなく、何社か集まって民間の規制の範囲内で自主制作しても・・・？？これを禁止する、理由がない・・とおもうけど？？

---

■免許する必要がないのに、免許制にすると、それは、単なる政府介入の規制になる

　だから、これを免許制にすることに意味はない。
　それを免許に無理やりすると、たんに、国のすすめる方針にそった放送をしているという
お墨付きに過ぎなくなる。

　たとえば、免許制にして、規制条件として、「拉致問題について取り上げること」とかすると、
（こーいう規制は、じゅーぶん考えられる）それは、免許という名の政府お墨付きつーか、政府の介入になってしまう。

　なので、免許制にしないでいいものは、免許制にすべきではない。

---

■それ以前の問題として、ロフティヘッドを実現するのに、融合放送なのか？

　それ以前の問題なんだけど、視聴率上位のものをあつめるのに、なぜ、「融合放送」なんだ？

　テレビ番組などは、見る人がかなり多い。だから、もし、テレビ局がすべてのコンテンツをインターネットに載せたら、視聴率上位、ロフティヘッドになると思う。

　ウィリアムのいたずらは、むしろ、

　ロフティヘッドになる放送を実現するための主な要因は、
1）放送局が、
2）自分たちが制作した番組を、
3）配信側がタイムテーブルを組まず、いつでも視聴できるようにして、
4）放送規律を守って（いるけど）、
5）通常の動画再生ソフトで視聴でき、DRMを使うこと、
6）オープンかつコミュニティ性のあるネットワークで配信すること、
7）広告収入であること。

を満たせば、実現できると思う（赤字は、融合放送との大きな相違点）

　つまり、今のＹＯＵ　ＴＵＢＥの著作権問題は、放送局の著作権のある番組について限って言えば、それら著作権のある番組がＹｏｕＴｕｂｅに流されることが問題だと思う。

　なぜ、ながされるかといえば、一度放送したものは、録画してないと、見れないから。

　なので、録画した人がアップする。

　これが、放送局が自分たちの番組をいつでもどこでも、インターネットで見れるようにすれば、見そびれた人は、それをみればいいし、引用したい人は、テレビ局のその番組にリンクを貼ればいい。

　さらに、Ｙｏｕ　Ｔｕｂｅ側でも、番組が公開されれば、それをもとに、チェックして、同じ番組がアップされていたら、はじくということもできる。

　だから、「ロフティヘッド」に限らずＹｏｕ　ＴＵＢＥ対抗策は、既存の放送局が、ネット配信することなのだ。

---

■問題はテレビ局が、テレビ番組のサーバ型放送に乗る気でないことだ。

　そして、既存の放送局が、ネット配信するっていう問題は、技術的には、広告をどうするか？だが、これはある程度、決め事でいける。つまり、技術的な問題ではなく、既存の放送局の意識の問題になる（自分の放送エリア外で、自分たちが配信している時間以外に視聴される問題）。

　どーも、この問題が大きいようだが、これは、意識の問題なので、ある日突然変わることがありえる。

　そして、Ｙｏｕ　Ｔｕｂｅをたたいたり、新しい概念を持ってくるより、既存の放送局がネット配信して、むしろＹｏｕ　Ｔｕｂｅと組んだほうが、お金は儲かると思う。（放送局にとってもＹｏｕ　Ｔｕｂｅにとっても）。もちろんユーザーが、一番多くの恩恵を受けるわけだが。。

依存性の問題の対応策（その１：窓口、引数を一本化してしまう）

なんか、ツッコミすぎな気もしますけど、前に書いた構成管理とテスト・バグ修正段階における依存性の問題と解決法、で書いた、依存性の問題について、
（引数が修正されても知らない人がいて、コンパイルエラーになることを防ぐ話）

コンパイルを通したときに警告を出して、依存性の問題を知らせる＆調べる方法については、

JAVAでＡＰＩが変わったことを示し、コンパイルで落ちないためのDeprecatedとその限界

で書きましたけど、

そもそも、上記依存性の問題のブログを書いたときの対応策としてあげた、「コンパイルエラーを出さないような窓口の一本化」について、書いていないので、そーいう話について、一応書いてみます。

　長い話になるので、今回は１回目です（分割して書きます）

---

■そもそも、どーいうケースなのか

　簡単な例を挙げます。

●仕様変更前（初めの状態）

aさんは、以下のように、メッセージを出すプログラムをよんでいたとします

public class a {
	public static void main(String[] args) {
		b.errmsg("aのメッセージ");
	}
}

bさんは、実際にメッセージを表示する部分だとします。

public class b {
	public static	void errmsg(String msg,int level)
	{
		System.out.println(msg);
	}
}

dさんも、bさんのメソッドを呼び出していたとします。

public class d {
	public	d()
	{
		b.errmsg("作成");
	}
}

●仕様変更
　これだと、エラーメッセージばっかり出て困るので、エラーレベルというのを付けて、
　それにもとづき出力することにしました。
　エラーレベル　０　　　デバッグ情報
　　　　　　　　１　　　一般情報
　　　　　　　　１０　　警告
　　　　　　　　１００　エラー
　　　　　　　　９９９　致命的エラー

　この連絡は、aとbの間でだけ行われました。
　その結果、aは以下のように修正しました。

public class a {

	public static void main(String[] args) {
		b.errLevel	=	10;	//	通常のレベル
		b.errmsg("aのメッセージ",999);	//	999　致命的エラー
	}
}

　bは以下のように修正しました

public class b {
	public static	int	errLevel	=	0;

	public static	void errmsg(String msg,int level)
	{
		if ( level	＞=	errLevel)
		{
			System.out.println(msg);
		}		
	}
}

（上記＞は、本当は半角です）

●依存性の問題
　でもdには、連絡が行ってないので、まえのまま、

　　　　　b.errmsg("作成");

　と呼び出したままです。そうすると、引数が足りないので、コンパイル
エラーになります。

＊実際に、こんなに単純な例でミスすることは、まずありませんが、
　話を簡単にするため、これでいきます。

＊ちなみに、これのひねりで、
　　　a=自分たちが作成しているアプリ
　　　b=PHP
　　　c=PHP上で動く他社が作ったアプリ
　で、自分たちが、PHPの最新バージョンのものが使いたくて、PHPの
　バージョンを上げたら、他社が作ったアプリが動かなくなった。
　などというケースがあります。

---

■解決策

こういう問題が起きないための解決策というのは、いくつかあり、
状況によって使い分けます。

１．はじめから、１箇所の窓口に集める
２．古いメソッドを入れておき、落ちるようにする

さらに、問題を軽減する方法として、こんなところで手を打つ場合もあります。
３．引数だけは、共通化する

それと、前回書いた方法
４．古いメソッドをDeprecatedにして入れる
５．古いメソッドをDeprecatedにして入れた上で、落ちるようにする

今回は、まず１について書きます。

---

■はじめから、１箇所の窓口に集める＝仕様概要

それぞれのクラスを呼び出すときは、かならず、

execute(HashMap map)にして、その引数のハッシュマップに設定されている

値に応じて、動きが規定されるとします。

そうすると。。。

●仕様変更前（初めの状態）

aさんは、以下のように、メッセージを出すプログラムを呼ぶことになります。

import java.util.*;
public class a {

	public static void main(String[] args) {
		HashMap	map = new HashMap();
		map.put("job","errmsg");
		map.put("msg","aのメッセージ");
		b.execute(map);
	}
}

bさんは、実際にメッセージを表示する部分だとします。

import java.util.*;

public class b {

	public static	int execute(HashMap map)
	{
		String job;
		
		//	ハッシュマップからジョブ取り出し
		if ( map	==	null )
		{
			throw new RuntimeException();
		}
		job = (String)map.get("job");
		if ( job	==	null )
		{
			throw new RuntimeException();
		}
		
		//	ディスパッチ
		if ( job.equals("errmsg")	==	true)
		{
			String	msg;
			msg = (String)map.get("msg");
			if ( msg	==	null )
				msg	=	"";
			errmsg(msg);
			return	0;
		}

		//	なんにも該当しない
		else
		{
			System.out.println("Jobが設定されていない");
			throw new RuntimeException();
		}
	}
}

dさんも、bさんのメソッドを呼び出していたとします。

import java.util.*;
public class d {

	public	d()
	{
		HashMap	map = new HashMap();
		map.put("job","errmsg");
		map.put("msg","作成");
		b.execute(map);
	}
}

●仕様変更
　変更時に、以下のように、かわります。
aさんのソース

import java.util.*;
public class a {

	public static void main(String[] args) {
		b.errLevel	=	10;
		
		HashMap	map = new HashMap();
		map.put("job","newerrmsg");
		map.put("msg","aのメッセージ");
		map.put("errLevel","999");
		b.execute(map);
	}
}

（赤字が変わったところです）

ｂさんのソース

import java.util.*;

public class b {
	public static	int	errLevel	=	0;

	public static	int execute(HashMap map)
	{
		String job;
		
		//	ハッシュマップからジョブ取り出し
		if ( map	==	null )
		{
			throw new RuntimeException();
		}
		job = (String)map.get("job");
		if ( job	==	null )
		{
			throw new RuntimeException();
		}
		
		//	ディスパッチ
		if ( job.equals("errmsg")	==	true)
		{
			System.out.println("このやり方は、廃止されました");
			throw new RuntimeException();
		}
		if ( job.equals("newerrmsg")	==	true)
		{
			String	msg;
			int	errLevel = 0;
			msg = (String)map.get("msg");
			if ( msg	==	null )
				msg	=	"";
			try
			{
				String nobuf = (String)map.get("errLevel");
				errLevel = Integer.parseInt(nobuf);
			}
			catch(Exception e)
			{
				e.printStackTrace();
				throw new RuntimeException();
			}
			errmsg(msg,errLevel);
			return	0;				
		}

		//	なんにも該当しない
		else
		{
			System.out.println("Jobが設定されていない");
			throw new RuntimeException();
		}
	}

	private static void errmsg(String msg,int level)
	{
		if ( level	＞=	errLevel)
		{
			System.out.println(msg);
		}		
	}
}

(上記＜　＞は、本当は半角です）
赤字の部分は、修正箇所です。

●依存性の問題
　Ｄさんは、何も修正していませんが、コンパイル上問題ありません。
　なぜなら、Ｄさんは、変更前executeを呼び出していますが、変更前と後で、このメソッド名と引数は変わってないので、コンパイルは通ります。

　ただし、実行すると、引数のjobに設定されている値が古いerrmsgなので、実行時には、落ちます（なお、落ちるように書いているから落ちるのであり、何もしないように書けば、なにもしない）

---

■はじめから、１箇所の窓口に集める＝メリットデメリット

●メリット
　このように１つのメソッド、変数全体が入る引数でやれば、仕様変更に対しては柔軟にできます。引数の型チェック、機能がコーディングされているかどうかなどは、実質、実行時になるので、コンパイルは通り、構成管理上楽です

●デメリット
　逆に言えば、もし、依存性の問題があった場合、実行時までわからないということになります。
　デグレードさせない回帰テスト（リグレッションテスト）を、確実になっていればいいのですが、そうでないと、以前通った部分は、再度テストされないこともあるので、テストされないから気づかないという危険性が出てきます。

　あと、どんなときでも同じメソッドを呼び出し、引数だけで処理を変えるので、ソースを追いにくいということがあります。
　とんでもないところで、jobを設定してしまうと、読み手は、「一体この処理はなにをやっているんだ？」ということになります。

---

■はじめから、１箇所の窓口に集める＝どこで使うか？

　なので、ここまで過激なものはないのですが、テーブル操作や画面操作で、こういうことをすることがあります。
　引数で、ＳＱＬを受け取り、executeでＳＱＬを実行するっていうクラスをつくってしまい、
　どんなテーブルでも、どんなＳＱＬでも、こいつで処理させるというものを作ることがあります。

　画面でexecuteといえば、Struts。Strutsの場合、呼び出し関数がexecuteであるときまっているから、多種多様な画面があっても呼び出せるということになります。
　これを応用して、画面入出力システムを自分で作る場合、全部帰ってきた後の呼び出し先をexecuteにするなんていうきめうちをすることもあります。

　このように、処理レイヤと入出力レイヤなど、２つの大きな処理塊が合って、それが、頻繁に変わったり、予測不能だったり、汎用的に作らないといけない場合、この手法は使われます。
（とくにJavaの場合、リフレクションと組み合わせて使うと、便利便利）

米ヤフー、幹部がメモで組織改革や最大20％の人員削減など求める

ここのニュース
米ヤフー、幹部がメモで組織改革や最大20％の人員削減など求める＝ＷＳＪ
http://today.reuters.co.jp/news/articlenews.aspx?type=technologyNews&storyid=2006-11-20T071830Z_01_NOOTR_RTRJONC_0_JAPAN-236786-1.xml&src=rss&rpc=112

によると（以下斜体は、上記ニュースより引用）

　米ウォールストリート・ジャーナル（ＷＳＪ）紙は、米インターネット小売り大手のヤフー(YHOO.O: 株価, 企業情報, レポート)で１０月、大々的な組織改革や最大２０％の人員削減が必要だと幹部が社内メモで指摘していたと伝えた。

　メモを書いたのは、シニアバイスプレジデントのブラッド・ガーリングハウス氏。ガーリングハウス氏は、ヤフーが一貫性のある指導体制や事業の焦点、「単一のまとまった戦略」が欠けていると指摘した。


ほー。。

　でも、事業の焦点、「単一のまとまった戦略」が欠けているっていうのは、日本のＹＡＨＯＯもっていうか、検索エンジン会社すべてにいえるような。。

　意外と、検索エンジン会社の戦略って、（シェア１位になるとか以外）むずかしいかもよ。。
（ただし、じゃあ、戦略はなくていいという話には、もちろんならないけれど。。）

BREWで複数画面を開発する場合の方法論（その１９：Ｅｘｃｅｌで自動生成－その４：第二弾ソース）

　シリーズBREWで複数画面を開発する場合の方法論のつづきです。
　前回、第二段の仕様を書きました。
　第一弾との違いは、画面定義の仕様に指示があれば、その部品内容をソースに書き出すというものです。

　で、さらに前回、雛形ソースについては（仕様の中）示しました。
　なので、あとはExcelマクロで、固有のプログラムであるinitAppDataを

各画面のシートの部品部分（５行目以下）に、記入がなければ、 　　　従来の「各画面ヘッダ」と「各画面ソース」を出力（変更なし） 　各画面のシートの部品部分（５行目以下）に、記入があったら、 　　　今回作成した「各画面（部品追加）ヘッダ」と「各画面（部品追加）ソース」を出力

のように修正すれば良いことを書きました。

今回は、その修正ソースを示します。

---

■ソース

今回修正するExcelソースは、「ユーザー作成部分」のモジュールのほうです。
一般的な「標準処理」には、手を加えません。

以下、「ユーザー作成部分」のモジュールのソースです。

'//*************************************************//
'//                                                 //
'//         個別処理                                //
'//                                                 //
'//*************************************************//
Public Const gamen_teigi_str_gyo As Integer = 5

'//=========================//
'//     前処理              //
'//=========================//
Sub initAppData()
    Dim gyo As Integer
    Dim pathdir As String
    Dim i As Integer
    
    
    '// 作業一覧シートクリア
    gyo = Sheets("作業一覧").Range("A65536").End(xlUp).Row
    If (gyo ＞= 5) Then
        Sheets("作業一覧").Range("A5:C" & CStr(gyo)).Clear
    End If
    
    '// 値の初期設定
    pathdir = ActiveWorkbook.Path   '//  読み込み書き出しパス
    gyo = 5                         '// 書き出し開始行
    
    '// 主処理：作業一覧の書き出し
    For i = 1 To Sheets.Count
            '//=========================//
            '// 画面一覧の場合          //
            '//=========================//
        If (Sheets(i).Range("B1") = "画面一覧") Then
                
                '// アプリ用ソース書き出し
            Sheets("作業一覧").Cells(gyo, 1) = pathdir & "￥app_c.txt"
            Sheets("作業一覧").Cells(gyo, 2) = Sheets(i).Name
            Sheets("作業一覧").Cells(gyo, 3) = pathdir & "￥" & Sheets(i).Range("B2") & ".c"
            gyo = gyo + 1
            
                '// アプリ用ヘッダー書き出し
            Sheets("作業一覧").Cells(gyo, 1) = pathdir & "￥app_h.txt"
            Sheets("作業一覧").Cells(gyo, 2) = Sheets(i).Name
            Sheets("作業一覧").Cells(gyo, 3) = pathdir & "￥" & Sheets(i).Range("B2") & ".h"
            gyo = gyo + 1
            
                '// バージョン用書き出し
            Sheets("作業一覧").Cells(gyo, 1) = pathdir & "￥version_h.txt"
            Sheets("作業一覧").Cells(gyo, 2) = Sheets(i).Name
            Sheets("作業一覧").Cells(gyo, 3) = pathdir & "￥version.h"
            gyo = gyo + 1
        End If
            
            '//=========================//
            '// 各画面定義の場合        //
            '//=========================//
        If (Sheets(i).Range("B1") = "画面定義") Then
                
                '// 画面用ソース書き出し
            
            If (Sheets(i).Cells(gamen_teigi_str_gyo, 1) = "") Then
                Sheets("作業一覧").Cells(gyo, 1) = pathdir & "￥gamen_c.txt"
            Else
                Sheets("作業一覧").Cells(gyo, 1) = pathdir & "￥gamen_b_c.txt"
            End If
            Sheets("作業一覧").Cells(gyo, 2) = Sheets(i).Name
            Sheets("作業一覧").Cells(gyo, 3) = pathdir & "￥" & Sheets(i).Range("D2") & ".c"
            gyo = gyo + 1
            
                '// 画面用ヘッダ書き出し
            If (Sheets(i).Cells(gamen_teigi_str_gyo, 1) = "") Then
                Sheets("作業一覧").Cells(gyo, 1) = pathdir & "￥gamen_h.txt"
            Else
                Sheets("作業一覧").Cells(gyo, 1) = pathdir & "￥gamen_b_h.txt"
            End If
            Sheets("作業一覧").Cells(gyo, 2) = Sheets(i).Name
            Sheets("作業一覧").Cells(gyo, 3) = pathdir & "￥" & Sheets(i).Range("D2") & ".h"
            gyo = gyo + 1
        End If
    
    Next
End Sub

'//=========================//
'//     後処理              //
'//=========================//
Sub freeAppData()

End Sub

（上記＜　＞　￥は、本当は半角です）

赤字のところが変更箇所です。
やっていることは、仕様のとおりなので、特に説明することはないと思います。
なお、gamen_teigi_str_gyoというところで、画面定義の繰り返し開始行
（５行目から部品を書くので５になります）
を定義してしまっているので、汎用性を失っていますが。。
ま、ここは、固有処理で、この仕様書の形式の場合の処理を書くところなんで、いいしょ！
っていうことにしています（＾＾；）

---

　ということで、これで一通り説明が終わったので、
あとは、公開ってことになりますが、それは、このシリーズの次回
（かな、それ以降かな？ただ、もう、話題は全部書いたんですけど。。）
ということになります。