2005年4月

4日  洋画の吹き替え

最近は深夜の映画などで、洋画を字幕で放送することが増えてきました。

字幕は慣れてしまえばほとんど邪魔になりませんし、役者本人の声、オリジナルの音で作品を鑑賞できることもあって映画愛好家の間では吹き替えよりもずっと評価されているようです。僕も字幕自体を否定するつもりはありません。

ただ、「吹き替え」という仕事がもう少し評価されてもいいのではないか、と思うときは結構あります。世間一般の評価を見ると、吹き替えがちょっと不当に低く評価されすぎている気がするのです。

もちろん純粋に映画を楽しむ映画愛好家の間で字幕がもてはやされるのはしょうがないと思います。しかし、世間一般で見て、「吹き替えで映画を見るのはちょっと恥ずかしい」という風潮があるのはちょっともったいない気がするのです。「みんなもっと吹き替えを楽しもうよ」と。

吹き替えの多くは声優さんの仕事で、有名な役者には担当する声優さんがおおむね決まっています。刑事コロンボのピーター・フォークや、ジャン・ギャバン、ローバート・レッドフォード、ハリソン・フォード、クリント・イーストウッド、ジャッキー・チェンなど、顔を見ただけで浮かんでくる声は実は日本語吹き替えの声優さんの声で、本当の声はよく覚えていない、ということも珍しくありません。特に刑事コロンボなど、ピーター・フォークの本当の声を聞いたことが無いという人も少なくないのではないでしょうか。

こういった声優さんたちが十分に創造的な仕事をしていることは誰もが認めていると思います。映画産業の中では裏方さんに近い仕事ですが、「現代の活動弁士」としてもう少し高い評価をしてあげてもいいと思うのです。

ここのところ吹き替えを取り巻く状況は、DVDの登場である程度改善されつつあります。以前のレンタルビデオでは、音声が1系統しか入れられないため、ファミリー/子供向けの一部の作品以外はことごとく字幕版のみがリリースされていました。そのため、日本語吹き替えで見たいと思うと、その作品がテレビで放送されるのをひたすら待つしかありませんでした。しかしDVDでは副音声が入れられるため、一枚のDVDにオリジナルの音声と吹き替えの音声の両方を入れることができます。

このため、今は日本語の吹き替え作品を入手することは以前ほど困難ではなくなりました。とはいえ、まだまだ日本語の音声が入ってないタイトルもかなりの割合になります。また、困ったことに「誰が声を吹き替えているか」がパッケージに書かれていないことが多く、ちょっと買うのに勇気がいります。上に書いたような役者さんは、どうしても「自分が知っているあの声」で吹きかえられているものでなくては見る気がしない、ということも多いのです。

「ロバートレッドフォードを広川太一郎が吹き替えているなら買うけど、それ以外の人なら買わない」という、ロバートレッドフォードのファンなのか広川太一郎のファンなのかよく分からない人も結構いそうです。僕も、吹き替えを誰がやっているかわからないDVDはちょっと怖くて買えません。

DVDのパッケージは小さいので表示するところも少なく大変だとは思いますが、なるべく日本語吹き替え担当者の名前も主だったところだけでいいので表示してもらいたいものです。

6日  庭の水遣り

小さい頃、夏休みの間だけ庭の植物に水をやるのが僕のお仕事になっていたことがありました。父同様、外の水道についているホースを指でつぶして、庭の隅々までピューピューと水を届けるのは、夏の暑い陽射しと、自分に少しだけかかる水しぶきの気持ちよさもあいまって子供心にそれはそれは快感でした。

しかし、今思うとあれはどうだったのだろうと。

今でも庭に水を撒いている人の多くが水道水を撒いていると思います。これには実は二つの問題があるのです。

  1. そもそも、コストをかけて人間が飲めるほど清潔にされた水を植木にやるのはもったいない
  2. 庭の植木に、殺菌された(殺菌作用の入った)水をやるのはよくない
前者はまぁ水道局的な考え方なので「ほっとけ」と言われればそれまでなのでしょうが、後者はもっと大きい意味を持っています。

熱帯魚を飼っていると色々なことを学ばされるのですが、その一つが「バクテリアへの感謝の心」です。

バクテリア、つまり細菌は、一般的に人間からは忌み嫌われていますが、自然界においては無くてはならないものです。庭の土にはこのバクテリアが通常沢山住み着いていて、植物や動物の排泄物、死骸などを植物が吸収できる形に変化させたりしています。

また、バクテリアは土壌の生態系の底辺を支えています。バクテリアはミミズに食べられ、ミミズはさらに大型の動物に食べられ、またそれらの糞は土壌を豊かに保ってくれます。

しかし、このバクテリアは、非常に弱い生き物です。水道水の残留塩素で簡単に死滅してしまうのです。

例えば、バクテリアの住み着いた水槽に間違って塩素中和していない水道水をそのまま投入してしまったとします。その時点で貴重なバクテリアは死滅してしまい、再びバクテリアが水槽に定着するまで最低2週間は必要になります。

ということは、僕は毎日のように庭に塩素をばら撒きその度に地表近くのバクテリアを死滅させていた可能性があるということです。

庭に肥料として鶏糞などを撒きつつも、植木に水道水をあげているのでは、無意味というほかありません。

というようなことを気にしているのは僕だけなのでしょうか?

11日  日本語の識別子

色々なところで色々な業務プロジェクトに参加する際、いつも心の隅にありながら小さく提案したりして、即座に却下されているものがあります。それが「日本語の識別子名」です。

現在業務で使われているプログラミング言語の大半は海外製のもので、古来多くの言語は変数名や関数名に日本語を使うことが禁じられてきました。時々日本語対応を唄う言語が突発的に現れたりもしましたが、そのたびにイロモノ的な扱いを受け消えていきました。

ところが、最近の言語はUNICODEをベースにしているものが増え、何も書いていなくてもさりげなく日本語の変数名や関数名が通ってしまうものが少なくありません。Javaもそうですし、VB.NETやC#もそうです。使いたければ変数名にガンガン日本語を書いても全く普通に動いてしまいます。

ただ、日本語が使えるからといって、じゃぁ使おうか、ということにはならないものです。

理由は、

こんなところではないかと思います。

これらの主張は分からなくもないのですが、ここ数年、僕には日本語の変数名を使ったほうがいいのではないかという局面に何度も遭遇し、その度に見送ってきました。

どういう局面かというと、既に現行システムでデータベースがあり、そのデータベースのテーブル名、カラム名が既に日本語で付けられているような場合です。

日本の業務である限り、業務を扱うテーブルのカラムは基本的に日本語の言葉になります。エンジニアによっては、日本語のテーブル名やカラム名を嫌い、対応する横文字の言葉を作ってそれを使うことも多いようです。

しかし、業務プログラミングの作業の中で、この「日本語の名前と横文字(ローマ字だったり英語だったり)の名前の両方をキャリーしなければならない負担」というのは結構馬鹿にならないものなのです。

通常は日本語の単語に対応する横文字の文字列の対応表などを用意して、

商品コード、SyouhinCD
商品名、SyouhinMei
部門1、Bumon1
部門2、Bumon2
納入業者コード、NounyuuGyousyaCD

というような表を頭の隅において作業をすることになります。この表の作り方が会社によってまた色々で、ソースが長くなることを嫌って子音のみ取り出し

商品コード、SyhnCD
商品名、SyhnNm
部門1、Bmn1
部門2、Bmn2
納入業者コード、NnygysyCD

としたり、英語にこだわっているところは、用法があってるかどうかよくわからない単語まで無理やり持ち出して、

商品コード、MerchandiseCD
商品名、MerchandiseName
部門1、Category1
部門2、Category2
納入業者コード、SupplierCD

だったり、もうバラバラです。

この五つぐらいならまだしも、業務のプログラミングには普通こういう単語が何百も、時には千個単位で出現します。それを正確に記述する負担たるや相当なものです。中にはもうあきらめてしまって、

商品コード、PKEY1
商品名、VALUE01
部門1、FKEY1
部門2、FKEY2
納入業者コード、FKEY3

といった名前をつけることさえあります。どうせ横文字を見てから対応表を見ないと正確な意味がわからないなら、全然わからなくても同じということです。まぁこの例は流石に変数名に使われることは少ないですが、メソッド名などにはかなり頻繁に使われます。タスクIDというやつです。

困ったことに、この対応表は、ちょっと油断すると同じ日本語に違う横文字が付いていたりしてとてもみっともないことになっていることが少なくありません。だから、新しいカラムを挿入したいとき、

という作業が必要になります。流石に大変なので、それ専用のツールが用意されていたりします。対応表を作るのも大変なら、使うのも大変です。

で何が言いたいのかというと、コンパイラで日本語が通るなら、無理に横文字の変数名にこだわる必要はないんじゃないかと、そういうことなのです。

lblSyouhinCD=SyouhinTbl.SyouhinCD; // 商品コード
lblSyouhinMei=SyouhinTbl.SyouhinMei; // 商品名
lblBumon1=SyouhinTbl.Bumon1; // 部門1
lblBumon2=SyouhinTbl.Bumon2; // 部門2
lblNounyuuGyousyaCD=SyouhinTbl.NounyuuGyousyaCD; // 納入業者コード

なんて書くより、

lbl商品コード=商品テーブル.商品コード;
lbl商品名=商品テーブル.商品名;
lbl部門1=商品テーブル.部門1;
lbl部門2=商品テーブル.部門2;
lbl納入業者コード=商品テーブル.納入業者コード;

の方がよっぽど分かりやすいですし、コメントをつける必要もなくなります。

何より、これまでものすごい労力を使って作成していた対応表とオサラバできます。

しかもコードをパッと見て何をやっているかがすぐに分かります。

現在の開発環境なら、識別子は開発環境が列挙/補完してくれますから、コーディング中に日本語を手で入力する必要はほとんどありません。

と、これだけのメリットがあるにもかかわらず、僕かかわったプロジェクトで日本語の識別子が受け入れられたことはありません。たいていは即時却下です。やはり危うきに近寄らずなのでしょう。こういうところですら、変わっていくのに本当に時間がかかるものだなぁと実感します。

実は一度だけ、完全に任されたタスクのコーディングで日本語のクラス名、インスタンス変数名を使ったことがあります。やはりテーブル名やカラム名が日本語の場合で、開発言語はVB.NETでした。流石に日本語のクラス名を使ったことはテスト完了までずっとナイショにしていたのですが、納品時に雇用主がソースを見て絶句していました。結果的には「まぁテストも通っているし、いいでしょう」で済みましたが、頭が固い人なら大目玉で作り直しだったかもしれません。まぁでも開発環境にVB.NETを選ぶような職場でしたから、ある程度は冒険ができる雰囲気があったこともあるのですが。

過去の呪縛から離れて、JavaやVBなどでもそそろそ「日本語解禁」してもいいのではないでしょうか。

17日  セキュリティ

最近オフィスからの情報漏洩が大問題になっているようで、僕の職場でも対策が義務付けられています。

どう対策するのかというと、とあるソフトを入れるだけです。

そのソフトを入れると、そのコンピュータからリムーバブルなメディアへの一切のコピーができなくなります。

それだけではなく、ローカルなコピーや、ネットワークを介した他のコンピュータとのファイルのやりとりも全てログが残ってしまい、しかもログはサーバに自動的に転送され保存されてしまうので、変に趣味的なファイル名のファイルはローカルに扱うことすらできません。正確にはできなくはないんですが、後でログを見ると赤面ものです。

まぁ管理者が全員分のログを定期的に見ているわけはないので、何かコトが起こったときに漏洩元を突き止めるためのものなのでしょう。

とにかくこのソフトを入れてから全てが窮屈で窮屈で、この文章も「memo01.txt」といったファイルに保存していますし、家に持って帰るのも一苦労です。手順は書けませんが、猛烈に回りくどい手段を使って、ログが残らないように細心の注意を払い僕のノートパソコン経由でコンパクトフラッシュに書き込んで持ち帰るのです。

悪いことしないから個人的なファイルぐらい勘弁してほしいです。

本当に悪いことする人は、どんなに対策をしようとも何とかログが残らないようにファイルを抜く方法を考えてしまいますから。