・ソフト自動化編
まずこの章に入る前にひとつ重要な注意を。
この章で書くことは、「育て方」という観点から見ればすっごく重要なことなんですけど。じゃあこれを実際に「うちの局でもやってみよう」となると・・・・多分できないと思います（笑）。
まぁ単純に費用という問題もあるんですが、それ以上に「その局なりの特殊事情」みたいなものが大きいと思うんですな。ですので費用面をクリアして丸パクリしたところでそれが機能するかどうか、という点に関しては私は多少疑問視して見ております。こうゆうのってケースバイケースですから。
ですので、ここでは紹介する一事例として、そして「問題があって、それを解決するためにどうゆう手段を取るか」のプロセスに着目した上で読み進めてもらえればと思います。こっちでも注意して書き進めたいと思いますので。
んじゃ本題。
くりらじが始まって、規模が大きくなるにつれ、次第に問題も噴出するようになってきました。その中でも一番の問題となったのが。
作業時間。
この辺のところは私が現役時代（笑）の時に書いた「オーバーワーク警報発令」あたりもご参照頂けますと幸いなんですが。要は番組が増え、収録回数が増えとなってくることで、もはや手作業では追いつかなくなる位、各更新に必要な作業ってのが加速度的に増えてしまったと。この作業を行うために本業をおそらかにしなければならない的な本末転倒状況下に追い込まれてしまった、ということが一時起こりました。
で、これは端から見ててもちょっとシャレにならない雰囲気だったので、こっちからも口出ししぃの、くりらじ側でも試行錯誤しぃのでかなり徹底的な「手間の省略、自動化」というのが行われたんです。機材（音声）編でも挙げたハードディスクレコーディングなんかもその一手段。
その結果、現在でもこうやってくりらじは番組を作り続けることができております。オーバーワークにならずに済んでる。
じゃあ結果としてその屋台骨を支える自動化手段ってのはどのようになったのか、という当たりをここでは取り上げてみようかと思います。
★自動化その１ エンコーディング
んではまずはこちらの方から。
前出のハードディスクレコーディングが終わった時点では、音源はAIFFフォーマット(WindowsでいうところのWAV)として保存されています。でも実際にはこれらはRAフォーマットに再変換されWebに乗る形になる訳で。そこでまずこの作業を行う必要があると。
これね、文章で書くと簡単そうに思えるけど、実際やってみるとめんどくさいんだよー。慣れれば難しい作業ではないんだけどなにせ時間がかかりますし。ルーチンワークとなるのと比例して、作業そのものにかかるストレスもバカになりませんし。
という訳でここの負荷削減手段としてくりらじではこのソフトを活用しています。
まず値段見るとひきますね。88000円（笑）。これは日本語版が出た時に改訂されている値段でして、くりらじでは日本語版リリース前に英語版を購入しておりますので当時値段は約100000円したとのこと。ひえー（くりらじの名誉のために書いておきますがちゃんと正規ライセンス購入しております）。
この手のソフトも動画配信が当たり前となった今では多種多様のソフトが出ておりますが、その中でもなぜにこれを選ぶことになったのか。その決め手になったのが以下のふたつ。
- バッチプロセシング
- 遠隔地サーバ対応
この結果、このエンコーディングの作業がどうなったか。前後で比較してみましょうか。
＜導入前＞
その日の収録が終わった時点で作成されたAIFFをいっこいっこRAファイルへと変換していきます。くりらじの場合、高音質版(ISDN向け)と低音質版(アナログ向け)を提供しておりますので、その日の番組分＊２回数分エンコードを繰り返します。作成が終わったらそれらのファイルをサーバにアップするために別途FTPにて送信します。
＜導入後＞
その日の収録が終わった時点で作成されたAIFFをCleanerからファイル指定します。いくつか項目を選択して「実行ボタン」を押します。終わり。
どうよこの差。私が威張ってどうする。
複数のファイルを複数のフォーマットに一括変換するためにCleanerのバッチプロセシング機能を使用しています。この辺の設定は既にプリセットされているので、必要な最低限の設定をするだけであとは自動化できると。そしてCleaner自体が作成したraファイルを勝手にアップロードしてくれる（要はFTP内蔵してると思いねぇ）ので、これが終わった時点では既にアップするための最低限の下ごしらえができている、という訳なんですな。
で、なぜにこれが有効なのか。更に明確にするために図示しましょうか。
２つの矢印を並べました。上から下へはそれぞれ時間の流れを示してると思ってください。
それで注意して欲しいのはエンコーディングに掛かる時間ってのはCleanerを使っても劇的に短くなってはいない、ということです。要はCleaner使おうが使うまいが時間そのものは一緒だぞ、と。
なのに何故ラクなのか。決め手は水色で示した丸の数。
この丸の部分はパソコンではなく、人間が手で操作しなきゃいけない、ということを意味するんです。エンコーディング終わったら確認して、それを手でFTPして・・・この繰り返しを行えば当然その回数分、人間が作業しなきゃならない。ということは、結局その間、人間がパソコンの前に張り付いてなければならないということを意味します。その張り付いてる時間がそのまま作業時間に跳ね返るんですな。
これらを全部自動化しておけば、一度実行押せば後は寝るなり遊ぶなりで放っておけばいい訳ですから。もう一目瞭然でしょう。ＯＫ？
★自動化その２ HTML自動生成
さて、んじゃとりあえずエンコードにかかる（＝人間が作業しなきゃいけない）時間に関してはこれで一通りの解決を見たと。
んでも、こと「番組をWebに載っけて公開できる状態にする」という意味ではまだ不十分なんですな。これをHTMLに関連づけて、公開できる状態に持っていかなければならない。
例えば、2003年3月17日の「くりテク」の前半のダウンロード用ファイルが、
http://www.c-radio.net/20030317/tech1l.ra
の位置に存在するとします。この場合、「20030317」「tech」「1」「l」の４カ所を各番組に対応させた上で、それをHTMLに載っけなきゃならない訳で。言うの簡単だけどこれもめんどくさい。実際手作業ですと些細な入力ミスひとつで「番組が更新されてない」とか「ファイルが存在しない」ということも起こりえちゃう訳で。わざわざその為に人間の目と手でチェックする訳にもいかないと。
加えてくりらじの場合、一部番組ではRealSlideshowも使用しております。これがまたクソめんどくさい代物で（笑）、音声と静止画像を連動させて動かすためのメタファイルも作成しなきゃならないと。一回二回だけならともかくこれを毎週手作業でというのも負荷が高すぎると。
という訳でくりらじではそこの負荷分散もやってしまいました。
具体的にはスタッフのSAG氏が自作で自動更新用のCGIを作成、それを運用することで実現しています。
「言語はPHP、DBにPostgreSQLを使いました。作成期間はほぼ２週間。作るのは確かに手間だったんですけど、一旦作ってしまえばその後は随分ラクできてますので、充分に元は取れてますね。」
とのことだそうで。
えーと、ということは。２人週で設計とコーディングと試験と運用監視・・・わてらの業界なら少なく見積もっても60〜70万円位は取れる仕事量だよな・・・。
こらこら＞俺。
（実際のところこれらのCGI群は公開されておりません。導入を検討される方（主に企業向きだと思うけど）は直接くりらじSAGさんの方までお問い合わせお願いします。）
んではこの辺の動きを差し障りの無い範囲内で説明しておきます。これを読まれる皆さんに「全部真似しろ」というのは多分無理だと思います、が。たとえばHTML更新の手間を省くために部分的にアイデアを貰う・・・みたいなことはできると思うんですよ。実際に頂けるかどうかはWebマスター（うわ、こっぱずかしい名前だ（笑））の腕の見せ所、ということになりますかね。
んじゃまずは全体図から。まとめてみるとこんな感じ。
まず予め、
- 音声ファイル（上のエンコーディングにおいて既に作成済み）
- RealSlideshow用の画像、連動情報
- 各番組毎の更新説明文等
これらをCGIを介する形で予め登録しておきます。この際、おなじみのストリーミングメタファイル等はここでは用意しません。CGIに勝手に作ってもらいます。 RealSlideshowに関しても、CGIから「3:24から4:35までaaa001.jpgを使う」といった感じでCGIに打ち込むだけです。これもCGIにメタファイルを作成してもらいます。
CGIの方はネット経由で各メンバーが自宅からアクセスできますので（ログインには認証及び権限が必要）、収録後スタジオに居残ったり、休日に出てきたり・・・といったこともする必要がありません。これも自動化の重要な要素ですね。
一通りの入力作業が終わりましたら更新の日時まではほったらかしです。そして更新時間（くりらじでは月曜日と木曜日の23:00）になりますと、自動起動されたCGIがDBより情報を拾ってHTMLファイルやメタファイルの生成置換を自動的に行い、Webサーバに反映。かくして誰も触らずに時間になったら勝手に更新、となる訳です。パチパチパチ。
ちなみに説明文の登録がない等の理由で正常に更新されてない場合は、気が付いた他のメンバーが、手動で再度更新・・・という段取りになっています。
★自動化その３ ネタ収集の省力化
さて。ここまで読んだところで、鋭い方であれば、こんな疑問が浮かぶと思います。
「ん？確かに作業自体は自動化できてる。でも実際の更新紹介や画像ファイルなんかは結局は手で打ち込まなきゃならないんじゃないの？それじゃあまり意味無いんじゃ？」
正解。これに気付かれた方、マジでSEの才能ありますんでご連絡下さい。力作業でなんとかなると思ってる筋肉馬鹿SE駆逐しないと、いつまでたってもこの業界デジタルドカタ扱いだっつーの。
こらこら。私情を書くな＞俺。
話戻す。まぁ実際のところそうですわね。文章書いたり画像用意したり、ってのは番組の質にも直結しますし、それこそ一番時間の取られる作業であるということが言えると思います。
まぁこれをあーだこーだやるのが楽しいという説もあるんですけどね。それも作業量次第ですな。膨大になれば楽しいはずの作業も苦痛に変わる。人間なんてワガママですから。
という訳でこの辺のところのお話を。
で、まずは結論から書いてしまいますが、くりらじの場合これらの各作業は基本的に収録前の「ネタ合わせ」の段階で行われています。
まずは共同作業スペース（これもSAGさん自作のCGIによって作成されています）に、各メンバーが予め「こんなネタを話そう」「この画像使えそう」みたいなものをぽんぽんと放り込んでいきます。
そうだなぁ。収録日＊番組単位で（例えば「2002年3月24日」の「Mowton」用）それぞれに掲示板がいっこずつ用意されてるようなイメージを思い浮かべてくださいな。厳密には掲示板とは違うんだけど、メタファとしては充分ですから。
こんな感じですかね。ブラウザを介することでデータベースの存在を意識することなくそれぞれに好き勝手ネタを放り込めると。
この共同場所自体が作業量削減に有効なのは言うまでもありませんよね。わざわざ時間前にどこかで集まってネタ合わせする必要もありませんし。ここにネタ溜め込んでおけば、当日スタジオに行って即収録、ということができますから。
でも、この共同場所が真価を発揮するのはむしろこの後からなんですな。
まず収録そのものでは、この溜め込まれたネタ群がそのまま進行表として使用されます。各メンバーはそれぞれスタジオにノートパソコン持ち込みまして、スタジオの無線LANからCGIにアクセスする形で参照していきます。
そして収録後はこの共同場所にためこまれたデータを加工する形で更新用文章等を作成、CGIに登録します。当然元ネタがある訳ですから、これ作るのも対した手間ではありませんわね。登録された後はもうおまかせですから、この時点で人間の手を離れます。
こうして毎週毎週作成されていったデータ群はDBの中で日々蓄積され、場合によってはそれがさらにフィードバックされていったりする訳です。
つまりどうゆうことか。
こんな感じ。時系列に対して二度手間が無いんですわ。同じようなものを二度も三度も作る必要が無いと。事前にかき集められたデータ群がそのまま最初から最後までこき使われると。
これによって得られるメリットってハンパじゃねーぞマジで。どこぞの企業にこれ見せて「個人がここまでできてるのにお前ら揃いも揃って何やってんじゃ能無し軍団が！」と怒鳴り散らしてやりてーっつーの。だから私情を出すな＞俺。
★この章まとめ。
という訳で以上、こうゆうのを構築していくことによって「番組作りのみに労力を集中させる環境」というのを作成していきました、めでたしめでたし・・・というお話でした。
なんだそれは。
でもねぇ。実際にこれ見せてもらった時にはちょっと感慨深いものがありましたよ。冗談抜きで。
だってさ。初期のドタバタ状態の時のこと知ってるもん私。番組数増やして人数増えて・・・で週を追う度にドタバタしていってる様が、Webの更新精度にも、番組内容にも、モロににじみ出てるのがわかりましたからね。「これこのまま続けたら、絶対こいつら燃え尽きる」とまで思ってましたもん、一時は。
それがこうやって試行錯誤重ねてここまで持っていった・・・というのを考えるとね。やっぱ嬉しいもんがあるよな。親心みたいなもんなんでしょーか（笑）。
という個人的感想はさておき。
さてと、じゃあこれを他が「そのままやろう」とした場合どーすればいいんでしょーか、ということになると思うんですが。
さすがに全部やるのは無理でしょうなぁ。サーバの概念含めてUNIXの動き覚えてPHP覚えてDB覚えてネットワークの事も覚えて・・・ってやってたらできるかもしれんけど。さすがに素人さんにそこまでやれとは言えん(^^;;;。いや、実際便利ですけどね。興味ある方はどうぞ・・・とまでしか言えない現実はある。
でもさ。たとえば部分的にでも、ということだったらできると思うんだな。
例えば今巷では流行ってるコラボレーションツールであるWiki。これをネタ集め用に使ってしまう、なんて手も有効じゃないですかえ？
HTML生成だったら、Perlとかのスクリプト系言語でやってみるという手もあるし、フリーウェアの組み合わせとかでどうにかできちゃいそうな気もしてるんですな。
要はいっこいっこは細かくてもそれが束になれば十分に作業量減少とかの目標は達することができると思うんですよ。根底にあるのはそれを活かせるかどうかのアイデアというか、直感に近いものだと思うんです。
私、本業（プログラマ）とかで新人さんとか抜けてる上司に説教する時（笑）、「怠けるために努力することを厭うな」つー言い回しをよく使うんですが。これって、別にどの世界にでも当てはまることなんではないかと。
作業量に潰されてしまったらそれまでだしね。やってなんぼ続けてなんぼなんだし。特にインターネットラジオなんかは典型じゃん？世に公開しなきゃ何やったって成果は「ゼロ」ですもんね。
やりたいことが増える度に、宿命的に作業量は増える。これはもう現実です。嘆いてたってしょーがあるめぇ。だったらいかに「やりたいことだけをやるか」という部分に目を向けることがいかに重要か、ということを改めて思ったりしましたな。
うん、いい刺激になりました。