数行のスクリプトであっても、コンピュータプログラムを実際に作って、ファイルやフォルダのリネームを処理するようになると、明確に「それ以前と以後」で当人に変化があらわれます。それは‥‥
人間もプログラムも、両方で扱いやすい、ファイル＆フォルダの命名規則
‥‥を考えるようになるのです。
なぜかというと、人間だけでなく、プログラム的に見ても、扱いやすいファイル名のほうが、運用が円滑で効率的になるからです。
例えば、
a0001.tga
‥‥というファイル名があったとします。そしてこの名前の「a」を「b」へと自動処理で変えたいとします。
その時、どのようにプログラム上で名前を変更するでしょうか。
「a」は１文字だから、２文字目から最後までを抜き出して、先頭に「b」を足せば良い。つまり‥‥
"b"+"a0001.tga".substr(1);
‥‥とスクリプト文を書けば、結果は‥‥
「b0001.tga」
‥‥で、めでたし、めでたし。
‥‥と考えるのは、よくあることでしょう。
しかし、それはハッキリ申しまして「浅知恵」と言わずばなりません。
もし、「A上セル」の場合にファイル名が‥‥
a-ue0001.tga
‥‥だった場合は‥‥
"b"+"a-un0001.tga".substr(1);
‥‥とスクリプト文が以前と同じままだと、結果は‥‥
「b-un0001.tga」
‥‥で、全然ダメ。
なので、スクリプト文を部分的に書き直して、
"b"+"a-un0001.tga".substr(4);
‥‥と書けば、「a-ue0001.tga」を「b0001.tga」に変更できる。‥‥めでたし、めでたし‥‥？
‥‥のようになりましょう。本当に「めでたし」でしょうか？
問題は明らかです。ファイル名の状況によって、毎度毎度、スクリプトのコード文を修正しなければ使えないのです。
「大した手間じゃないし」と考える人もいましょうが、スクリプト・プログラムを導入するのは「自動処理で効率化」する目的なのですから、「毎回毎回スクリプトを手動で書き換えていたら、それはもはや自動処理と言えない」わけです。
「じゃあ、後ろから数えて、連番と拡張子を抜き出せば良い」と思いますよネ。つまり‥‥
"b"+"a-un0001.tga".slice(-8);
‥‥と書けば、後ろから8文字以降を抜き出せるので、"b"と合体して‥‥
b0001.tga
‥‥となり、思った通りの結果を得られる。
「ならば、ソレでいいじゃん」と思いがちです。でも、よく考えて見れば、連番は必ず4ケタと言い切れるでしょうか？ セル素材の場合は2ケタだったり、コンポジット後の連番は5ケタだってあり得ます。連番のケタ数が変われば、その時点でスクリプトは台無しです。
"b"+"a-un_01.tga".slice(-8);
結果：「bn_01.tga」〜余計な文字が入り込み、「b_01.tga」に変換できない
毎回異なる状況に合わせて、「-8」を「-7」「-9」などその都度スクリプトを書き換えなければ、正常に機能しません。つまり、「何度も使いまわせる自動処理」とはなりません。
前から数えようが、後ろから数えようが、文字数に合わせて「1」とか「-8」などの決まった数字を使っている限り、臨機応変に対応する自動処理にはならない‥‥ということです。
‥‥と書いてて何ですが、正規表現を使えば、かなりの柔軟度でファイル名を修正できます。以下の正規表現でアニメ制作の実質的な連番関連の文字列を抜き出せるからです。
new RegExp("[_-]*[0-9]+¥¥.[A-Za-z0-9]{2,}");
＊「¥」は、実際はバックスラッシュです。このブログのフォントが日本語フォントの影響だか、「￥」に見えてしまうようです。ブログのコード直書き機能でフォントを英語フォントにすれば良いのかな‥‥。
上記正規表現ならば、「アンダーバーかハイフンの区切り文字（＝無くても可）のあとに、連番と拡張子をもつ、ファイル名」を全て共通のコード内容で処理できます。
"a0001.tga"を"b0001.tga"に変えたい
"b"+"a0001.tga".match(/[_-]*[0-9]+¥.[A-Za-z0-9]{2,}/);
結果："b0001.tga"
"a-un_001.tga"を"b_001.tga"に変えたい
"b"+"a-un_001.tga".match(/[_-]*[0-9]+¥.[A-Za-z0-9]{2,}/);
結果："b_001.tga"
"a-01.tga"を"b-01.tga"に変えたい
"b"+"a-01.tga".match(/[_-]*[0-9]+¥.[A-Za-z0-9]{2,}/);
結果："b-01.tga"
＊注）match()を実行すると、実際は「配列」が返ります。例では「暗黙の型変換」で処理していますが、After Effectsなどで実行する際はString()で囲んで明示的に型変換＝キャストしないと、エラー（ゼロによる除算）で構文チェックにひっかかる可能性もあります。
ファイル名がセル名と連番が直結していようが、アンダーバー（アンダースコア）やハイフンで区切られていようが、何桁だろうが、全て連番と拡張子以外を名前変更します。実際は「a0001.tga」や「b」は動的に自動入力されますから（ファイルの繰り返し処理や親フォルダ名から取得するなどして）、スクリプトを変更せずに処理できます。
でも、こうした、まるで呪文のような複雑な正規表現を、アニメ制作上で頻繁に用いるフォルダ名・ファイル名に適用しなければ、名前の変更１つすら自動化できない‥‥なんて、いかにも「運用上の命名規則の甘さ」のリカバーそのものです。
運用開始時点で、プログラムにも人間にも判りやすい、汎用性の高い命名規則を制定すれば良いのです。
最初っから、先を見越して、決めておけば良いのです。その場その場で場当たり的に対応するのではなく。
プログラムが、現場のルーズな運用規則をリカバーするばかりに徹するのではなく、現場のファイル運用もプログラムによる運用効率化に歩み寄るべきです。自動処理、スクリプト処理云々以前に、作業者ごとでまるでバラバラな命名規則で運用し、その都度対応して無用な手間を増やし続けて、口にするのは「手間が多くて大変だ」なんて、窮状の自作自演と言われても何も言い返せません。
ファイル名・フォルダ名は「その場の雰囲気でつける」ものではありません。たとえ、簡素な命名規則でも、実は根っこに色々な工夫が張り巡らされているものです。
そして、その命名規則は、人間だけでなく、プログラム・スクリプトにとっても活用性の豊富な規則であれば、効率化はどんどん加速します。制作進捗状況を記録するデータベースにおいても、円滑に処理できる基盤となるでしょう。
例えば、アンダーバーは「カット固有や素材ファイルの要素を区切る文字」と決め、ハイフンは「注釈や派生を付記する文字」と決めれば、人間でもコンピュータでも、ファイル名から解釈は容易です。
anim_05_234_mo_t1.mov
意味：作品「anim」の「05」話のカット「234」の出力種別「mo」の「テイク1」のQuickTimeファイル
a-ue_0004.psd
意味：「a-ue」素材の「４」つめのPhotoshopファイル
b_01.tga
意味：「b」素材の「１」つめのTargaファイル
こうした、シンプルだけども汎用性や拡張性の高い命名規則を規定しておけば、ファイル名を変更するスクリプトを何度もそのままで流用可能になりますし、データベースなどへの情報記録もフォルダやファイル名から一貫できます。
ファイル名やフォルダ名は、制作運用上のメタデータと心得るべきです。
そのためには何よりも、ファイル命名規則を規定する人間が、人間主観だけでなく、プログラムの観点からも鑑みることが、必要になります。
例えば、After Effectsでテキストレイヤーのエクスプレッションなどで形成する「カットボールド」は、作品・話数・カットの各文字列がアンダーバーでセパレートできれば、何度でも無修正で使いまわせる雛形コンポが作れます。substrで「何文字目」なんて毎回変更せずとも、配列のインデックスでどんな作品でも要素を確定できます。
「thisComp.name.split("_")[0];」は作品キーワード（作品略号）
「thisComp.name.split("_")[1];」は話数またはシーン
「thisComp.name.split("_")[2];」はカット番号
同じ「数字指定」をしても、セパレートの文字＝デリミタをあらかじめ規定しておき、そのデリミタで文字列を「split()」で分解して処理すれば、作品ごとに「数字指定を変更せずとも通用する」のです。
プログラムを知れば、ファイル命名規則の考え方も変わってくる。
ファイル命名規則の考え方が変われば、ファイルやフォルダの運用も変わってくる。
ファイルやフォルダの運用が規則的になれば、制作現場のデータ運用も変わってくる。
データ運用の無駄を抑制できれば、金銭や時間や人的資源の運用コストも変わってくる。
運用コストを改善できれば、現場全体を改善へと導くきっかけとなる。
‥‥と、以前、「地道に状況をレゴブロックのように積み重ねる」と書いたことは、まさにこうした流れのことを指します。秘密兵器、必勝兵器なんて存在せず、地道で先見性のある「積み重ね」だけが現場を変えていけると、少なくとも私は考えます。
改善の積み重ねも無しに、業界外部の門外漢の人々に、いくら「私たちアニメ業界はお金に困っています。増額してください。」なんて訴えたところで、「まず、自分らの基礎的で地道な改善をしてから、訴えてくださいよ」とひと蹴りされておしまいです。効率改善、現場の改善なんて、どんな業種だって重要なテーマです。アニメ業界だけが野放図に状況にひきづられてダダ漏れコスト消費のなすがままで良い‥‥なんて「あるわけがない」のです。
構造の改善は全く着手せず、現場作業者の目先の報酬を徐々にカットしていく‥‥なんて、アホ丸出しです。ゴツ石だらけ、ゴミだらけの畑に、いくらタネと水を撒いても、まともな作物なんて育ちません。上の人間も下の人間も、制作構造の「土壌」から改善することを、2020年代の目標にすべきと思います。
「コンピュータを毎日使っていながら、コンピュータの基本的かつ絶大な能力を使っていない」なんてことが起こらないよう、プログラムの「ちから」を制作現場にもっと導入すべき‥‥と考えます。
＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊
おまけ：正規表現によるフォルダ内リネーム
今回のブログ記事用にせっかく「アンダーバーかハイフンで区切られた（区切られていなくても良い）、１桁以上の連番と、ドットと、拡張子」にマッチする正規表現を書いたので、以前ブログで書いた「ESTKからフォルダ内をリネームするスクリプト」を改造して、汎用度を高くしました。
以下。
_1801_RENAME_RE=new RegExp("[_-]*[0-9]+¥¥.[A-Za-z0-9]{2,}");
alert(main());
function main(){
var theFolder=Folder.selectDialog("フォルダを選択してください");
if(!theFolder){return "処理をキャンセルしました";}
var theFiles=theFolder.getFiles();
if(theFiles.length<1){return "フォルダが空です";}
for(var i=0;i<theFiles.length;i++){
var reMatch=theFiles[i].name.match(_1801_RENAME_RE);
if(reMatch&&theFiles[i].name.match(/^[A-Za-z0-9]/)){
theFiles[i].rename(theFolder.name+String(reMatch));
}
}
return "処理が正常に終了しました";
}
これなら、「a-01.tga」でも、「a_1.tif」でも「a_001.tiff」でも、「a0001.psd」でも、全て「ファイル名に含まれる素材名部分を親フォルダ名に書き換えてリネーム」できます。
ドットで始まる「隠しファイル」がわんさか存在するOSXでの運用を鑑みて、「match(/^[A-Za-z0-9]/)」の条件は念のため入れときました。先頭に記号を付与して、事前に処理対象から意図的に外すことも可能です。
まあ、まだ穴はある（エラーで止まる条件は残っています。例えば、「a0001.tga」と「b0001.tga」が同じフォルダに入っていた場合、２つとも「親フォルダ名0001.tga」にしようとして失敗する‥‥など）のですが、かなり現場の作業傾向を吸収できそうです。
私は正規表現の使い手ではなく、必要に応じてチョコっと‥‥という程度なので、「.」を「¥.」にするまでは良かったものの、「""」で囲む時に「¥自身のエスケープ」を忘れて、期待通りの動作をせずにウンウン唸ってました。「""」で囲む＝クォーティングする場合は、「¥¥.」ですよネ。正規表現に限らす、「" "」や「' '」のクォーティングの際にエスケープ文字自身をエスケープするのは、基本ですよね。
そんな程度の私でも、日々の制作作業において、自作スクリプトは大活躍です。‥‥というか、自作のスクリプトやヘルパーソフトウェア、エクスプレッションがなければ、「できることもできなくなる」のが未来の制作技術だと痛感しています。数百にも及ぶキーフレームを意のままに操作するなんて、手作業でいちいち操作してたら無理ですもんネ。
