「任天堂、正式にYouTubeにムービー広告を掲載」今後、ＹｏｕＴｕｂｅ広告掲載企業は増えるのか？

ここの記事
任天堂、正式にYouTubeにムービー広告を掲載
http://gigazine.net/index.php?/news/comments/20061115_nintendo_youtube/
にあるように、任天堂がＹｏｕＴｕｂｅに、正式に
Ｗｉｉの広告を載せたようです
（ただし、英語です。。が一言しかしゃべりませんので、英語がわかんなくても楽しめます）

ここ　http://www.youtube.com/watch?v=CkS2DJ6VX_g
（すぐに再生して、音が出ます）

今後、こんなかんじでＹｏｕＴｕｂｅにＣＭを載せる企業は増えるんでしょうかねー？

マニュアルの書き方読み方－その２ マニュアルの関連と書く内容などなど。。。

　この前書いたマニュアルの書き方読み方－その１　マニュアルの種類と読み方などなど。。。 の続き。

　この前の話では、マニュアルは、大きく以下の４種類に分けられると書きました。

・インストールマニュアル、導入マニュアル等
・オペレーションマニュアル
・リファレンスマニュアル
・手引書

で、その書き方と関連ドキュメントについて書きます。

---

■インストールマニュアルは、インストール手順をひたすら書く
　インストールマニュアルは、インストール手順をひたすら書くしかないです。

　このとき、ＯＳがらみのものは、画面キャプチャができないことがあります。
　そんなときは、ネット越しに他のマシンからキャプチャしたり、VMWareみたいな仮想マシン上にインストールして、それをキャプチャするとかいろいろあるのですが、
　ま、それはともかく、とにかく、手順どおりに書いていき、画面キャプチャして、インストール手順を説明します。

---

■オペレーションマニュアルは、業務シナリオ＋画面定義書

　オペレーションマニュアルは、業務手順にあわせて、オペレーション、及び画面入力を書いていきます。ここで、業務手順は、要件仕様（要求定義）の、業務シナリオを作成していれば、それとおなじになります。
　作成していなければ、まず、業務手順のシナリオを作成するかんじで、オペレーションを書いていきます。
　ここで、詳しい説明を書いていると、なにかいてるかわかんないので、そー言うのを書きたい場合は、手引書か、リファレンスか、付録に書くようにします。そして、基本的には、業務手順のシナリオレベルで書きます。

　そうすると、画面操作のところがあると思います。そこに、画面を入れていきます。
　画面定義のときに、画面のイメージは作成しているので、それをいれてってもいいってことになります。特に業務シナリオができている場合、オペレーションマニュアルは、画面定義ができた、外部設計終了時点で（コーディングする前に）理論上は作成できることになります（実際は修正が入るのでできないが）

---

■リファレンスマニュアル
　リファレンスは、コマンドラインの関数のような場合は、関数それぞれについて、
　ＧＵＩの場合は、メニューから選んだ処理１つ１つについて、書くことになります。

関数のようなものは、

・関数名
・概要
・書式
・内容
・引数の説明
・返り値の説明
・例外説明（あれば）
・注意事項（あれば）

などから、構成されます。


一方ＧＵＩのほうは、

・メニュー名（操作内容）
・操作方法
・表示される画面の様子と内容

などになります。

---

■手引書はいろいろ

　手引書に相当するのは、一例としては

・システムの開発思想と、システム概要
・他のドキュメントで書き足りなかったこと
・異常系についてなどなど　

いろいろあるのですが、まあ、寄せ集め見たいな感じ出し
（ない場合もある）てきとうにかいてくださいませ。

---

■オペレーションマニュアルとオーバービューなどについて

　前にオペレーションマニュアルとオーバービュー、ツアーガイドは同じと書いたのですが、オペレーションマニュアルは、詳しいことが書いてあけど、オーバービュー、ツアーガイドは簡単なケースしか書かない場合があります。

　その場合は、手引書でそういう内容をかくか、オペレーションマニュアルからリファレンスにとばして、リファレンスの中で書くなどあります。

---

■逆引きについて
　オペレーションマニュアルと、リファレンスマニュアルの中間として、逆引きというのがあります。これは、操作したい目的ごとに１項目になっている仕様書です。
　逆引きがある場合、リファレンスがいらないケースがあります。

　ただし、オペレーションマニュアルについては、将来的に引継ぎなんかあったときに、そのマニュアルに基づいて説明すればいい（あるいは、オペレーションマニュアルを読んでもらえばいい）ので、作っておいたほうが無難かもしれません。

---

ということで、このシリーズは終わりです。

「ＫＤＤＩ国内初のデジタルラジオ携帯電話」より、デジタルラジオの番組「またたびアワー」が気になる！

ここのニュース
ＫＤＤＩ、国内初のデジタルラジオ携帯電話を発売
http://headlines.yahoo.co.jp/hl?a=20061116-00000416-reu-bus_all

　どうも、auが、ワンセグ・デジタルラジオ対応の「W44S」（ソニー・エリクソン製）を12月上旬に発売するらしいのですが、 それはそうと。。

　そもそも、デジタルラジオって、何、放送してるの？

　デジタルラジオの番組表を見てみましょう
　ここ　http://www.d-radio.jp/service.html
　ウィリアムのいたずらは、東京にいるので、東京の番組表（ＰＤＦ）をみると。。いきなり目に飛び込んできたのは。。

またたびアワー

　うん、「またたびアワー」ってなに、「またたびアワー」って？？

　想像つきます？

　それも、９８チャン（３セグメントを利用のＦＭＴｏｋｙｏがやってる番組）は、

一日中、「またたびアワー」！！

　なんなの、その「またたびアワー」って（＠＿＠！）

　ＹＡＨＯＯで検索しても、この番組表ぐらいしか、ひっかかんないし。。

　うーん、もはや、デジタルラジオが発売されたことより、
　「またたびアワー」のほうが気になる

構成管理とテスト・バグ修正段階における依存性の問題と解決法

　ちょっとした思いつきのかけらをまとめてみます。

---

■構成管理において、依存性は、守備範囲外である

　ソフトウエアの構成管理というと、VCCやSubversion,CVSが使われます。

　しかし、ＣＶＳのinfo manualの、「1.2 CVS は何ではない? 」に、何らかの変更があった際に、再構築が必要なファイルを調べるのは、やはり CVS の守備外ですとあるように、依存性（何らかの変更があった際に、再構築が必要なファイルを調べること）は、ＣＶＳの守備範囲外だし、SubversionのマニュアルのＣＶＳとの違いを見ても依存性については書いてないので、守備外だろう。

　というか、一般に依存性は、構成管理では守備外になってしまうだろう。

　というのも、構成管理に依存性を持たせると、言語依存、場合によってはフレームワーク依存とかになってしまうし、さらには、バグ管理とまで関連づければ、バグ票との関連まで、保持しないといけないからだ。

---

■テスト・バグ修正段階における依存性の問題

　では、依存性の問題というのは、どこで起こるのだろうか。
　一例として、テスト・バグ修正段階における依存性の問題を挙げる（これ以外にもあるが）。

＜例＞
今、Ａさん、Ｂさん、Ｃさん、Ｄさんがいて、それぞれ担当のソースをもっています。
開発言語はＪａｖａとします。

バグ票２４５番の修正をするためには、
　ＡさんとＢさんとＤさんの関数の引数を変えて、修正しなければいけません
　２４５番のＢさんの修正は、b.javaのクラスbのメソッドb1だとします。

バグ票２４６番の修正をするためには、
　ＢさんとＣさんの関数の引数を変えて、修正しなければいけません
　２４６番のＢさんの修正は、b.javaのクラスbのメソッドb2だとします。

　つまり、Ｂさんは、２４６番も２４５番も、同じソースの同じクラス（違うメソッド）を修正します。
　このとき、Ｄさんに、バグ票２４５番の修正が、伝わっていなかった（当初、関係者だと思っていなかった）とします。

＜ケース１＞
　ここで、Ｂさんは、バグ票２４５番の修正とバグ票２４６番の修正を両方行ったものを、登録したとします（このように、複数の修正をして、登録することは、普通にある）。
　この場合、ビルドは、失敗します。Ｄさんに連絡が行っていないので、古いままのメソッドで、引数が合わないためです。
　そうすると、Ｄさんに修正を依頼するわけなのですが、これが、すぐに修正できるとは限りませんというか、すぐにはできないでしょう。ＰＴもあるし。。
　っていうと、ビルド担当者ができることは２つ

　　１つは、ビルドコンパイル前のバージョンに戻す
　　　→これは構成管理ツールで簡単にできますが、この場合、テストは進まないことになります。

　　もうひとつは、ビルド担当者がスタブを作って、無理やりコンパイルを通す
　　　→この場合、単純なケースでは通ります。
　　　　で、これだけのケースなら、この方法もアリかもしれませんが
　　　　こんなのが何箇所も入り組んで出てきて、分けわかんなくなってしまう危険性があります。
　　　　というか、こんなことをしている暇は、基本的にビルドしている人にはありません。

＜ケース２＞
　ならば、仮に（実務的には不可能だけど）１つの修正が終わったら、かならず、コンパイルして依存性をたしかめ、ＯＫかどうか判断するというようにしたら、どうなるでしょうか。
　このケースの場合、

１．まず、２４５番の修正が終わった時点でコンパイルします
　　→ここで、Ｄさんに通知ミスが判明する

２．で、Ｄさんに通知するわけですが、ここで、Ｄさんの修正が、非常に時間がかかる
　　ということになったら、。。。２４６番の修正に入れません。

３．じゃあ、スタブをいれて、とにかく通して、２４６番の修正に入ったと、仮にします。
　　　→この場合、単純なケースでは通ります。
　　　　で、これだけのケースなら、この方法もアリかもしれませんが
　　　　こんなのが何箇所も入り組んできたら、いったい、何から修正したらよいか、
　　　　マネージャーは、わけわかんなくなります。
　　　　「これを修正したら。。あ、連絡ミスなんで、ちょっとまってて、じゃあ、こっちを先
　　　　やったら、これはこれに依存してるからダメでえ、じゃあ、こっちを先にやるとすると
　　　　ああ、この人の負荷が高くなって、余計遅れちゃう（＞＿＜！）」みたいな。。

---

■依存性の問題は、何が問題なのか？

　つまり、依存性を排除することは無理で、さらに、その依存性を見抜くということも難しく、それは、構成管理ツールをいれればできるという次元のものではないと。。

　ということは、はじめから、依存性があってもビルドできて、コンカレントにシステム開発ができるようなカタチに、（アーキテクトが）設計しておかないといけないことになります。

---

■依存性の問題への対応策

　で、このように、「依存性があってもビルドできて、コンカレントにシステム開発ができるようなカタチ」にずるには、

１．全部の窓口を１つにする。
２．引数のカタチを同じにする
　　→というか、エンベロープでつつみ、そのエンベロープを同じ型にする

ということが知られています。
（１）を実現する方法は、まさにデザインパターンのファザードなのですが、
　　それ以外の方法としても、リフレクションを使って、実行時にクラスを生成しても、
　　ビルド時の依存性はなくなります（が、そこまではしなくても　＾＾；）

（２）については、引数をハッシュマップやＤｏｍに入れることによって、解消されます。
　　この場合も、ビルド時の依存性はなくなりますが、実行時には、使う寸前に、
　　型をキャストしているのが普通なので、もし、修正前のものが入っていたりすると、
　　キャストに失敗して気づくということになります。

---

　ただし、そもそも、「デザインパターンのファザード」とか「リフレクションを使って、実行時にクラスを生成」とか「Ｄｏｍ」とかが、みんなわかるの？とツッコまれると、返す言葉もありません（＾－＾；）

You TubeがiPodで見れたり、ケータイでみれたりするみたい

まず、iPodのほうから。。

ここのニュース
［新製品］デネット、ワンクリックで「YouTube」の動画をiPodで閲覧可能にするソフト
http://headlines.yahoo.co.jp/hl?a=20061114-00000018-bcn-sci
によると、ＹｏｕＴｕｂｅの動画をiPodでも見れるように変換するソフトが発売されるらしい。

　一方、ケータイのほうでは、Ｙｏｕ　Ｔｕｂｅ自体が２００７年にケータイに対応することは表明しているが、海外においては、このようなサービスを提供する会社が出てきたニュースが報じられた

YouTubeビデオを携帯電話で――Orbが「本家」に先行
http://www.itmedia.co.jp/news/articles/0611/15/news058.html

でも、国内の企業でも、ＹｏｕＴｕｂｅが見れるようにしている会社はあって、
ここのニュース
Colors、携帯電話向けPCサイトビューアの最新バージョンを公開
http://headlines.yahoo.co.jp/hl?a=20061114-00000032-zdn_m-sci
によると、(以下斜体は上記ニュースより引用）


　Colorsは11月13日、携帯便利機能サイト「lupo.jp」で、PCサイトビューア「ぐるっぽ」「SPICE!」のバージョン1.10を公開した。利用料金は無料。

　新バージョンでは、PC用動画の携帯向け変換機能を搭載。閲覧中のページに動画ファイルへのリンクがある場合、動画変換ボタンが表示され、YouTube、GoogleVideoなどの動画を携帯電話（動画再生が可能な機種）で視聴できるようになる。またau、NTTドコモの端末では、ストリーミング再生も可能だ。


おお、これで電車を待つ時間や車内で、ケータイで、ＹｏｕＴｕｂｅみて暇つぶしする人がでてきそうだ！