スクリプト対策総論

ようやく確定申告の清書も終わり、あとはコピーをとって控えを作るだけなのですが、生憎と台風接近のため外に出る気にもならないので、久しぶりに「VRM-Nietzsche」カテゴリを使って書きますか。


さて、専門分野ではない私がこんなことを書くのも何ですが、ＶＲＭ４のスクリプトに関する問題点、というかスクリプトに挑むに当たってのユーザー側のあるべき姿勢のまとめ書き（いや単なる参考意見か）をしようと思います。この文章は、各命令や構文の仕様とかの細かいことを指摘するものではなくて、大局的なことについて書きます。

ＶＲＭ４においてスクリプトは重要な要素ですが、これがあるからＶＲＭ４は気軽に扱えないと考えているユーザーもいらっしゃるはずで、そういうユーザーにはもしかすると役に立つかもしれませんが、まぁあまり過度な期待はしないでください。結局のところ、自分で道を切り開くしかないですから。

また絵もない長文です。異論もあるでしょうが、暇な方だけお付き合いください。
第１段階「プログラミング言語に拒否反応を示す人」

スクリプトが使えないという方の多くが「「使えない」のではなく「使おうとしない」という食わず嫌い状態なのではないかなぁ」と私は勝手に想像しているのですが如何でしょうか？
「記号のような意味のわからん宇宙人の言語みたいなもん、わからんし、わかりたくもないわ」
ごもっとも。このように考えておられる方は、アイマジック社が何かしらの対応を取るまで待つしかないでしょう。そしてそれは多分かなり絶望的な状況であろうと思います（少なくともＶＲＭ４時代においては）。

tettaさんの記事の中で、「ＶＲＭ４のスクリプトが低級言語である」という文章が出てきますが、私はそうは思いません。ＶＲＭ４のスクリプトは高級言語だと思います。しかしながら、プログラミングをする人にとって低級であろうが高級であろうが、プログラミングをしない人にとっては全てのプログラミング言語が低級なのであって、この議論は不毛でしょう。このギャップを埋めるためには「なでしこ」のような日本語プログラミング言語を使うとか、ユニット化された命令群をフローチャート上でドラッグ＆ドロップしたら変数とかの煩わしいものを全部自動で設定してくれるＧＵＩ環境を整えるとか、そういった対策がとられない限りは無理なんだろうと思っています。

この部分に関しては、１ユーザーが吠えたところでどうにもならないので、次にいきます。


第２段階「何から手を付ければ良いのかわからない人」

私はAutoCAD系のインストラクターをやっていたことがあり、その経験上、結構多かったのがこういう人でした。例えば、線１本を書くにしてもＣＡＤでは幾つもの手法があります。機能が多く、選択肢が多いものほどこの傾向は強くなります。

ある人が言っていました。「大海に一人ポツンと立ち尽くしているようだ」と。
そういう人にはこう申し上げます。「頭を使うだけでは生き残れないから、まず手を動かしなさいよ」と。

私はサラリーマン時代には管理職の時間が多かったですから、新しいソフト等を導入した時には部下達に対して、「まず弄って遊べ」という指示をよく出していました。どういうことかと言えば、先にマニュアルを見て頭を使うよりも、手を使って実際に操作し、わからない部分が出てきた時に疑問を持ち、そこで頭を使って考え、マニュアルを見て解決策を導け、ということです。マニュアルを見て操作を覚えるよりも時間はかかるでしょうが、より深い理解を得られ、尚且つ問題解決能力の訓練にもなれば、最終的にはこちらの方が近道であるという考え方です。

私は「勉強（勉めることを強いる）」という言葉が大嫌いで、「学習」は「遊ぶ」ということから始まるという考え方をしていますので、よく「遊べ」という言葉を使いますが、それは単純に「遊ぶ」ということではなく、それに慣れてそこから学び取れという意味合いです。

そうすると「こうやれば出来るみたいだけど、これが一番良い方法なのがわからない」という人も出てきます。
そういう人にはこう申し上げます。「初心者ごときが、何がベストかなんて考えるなんぞ１０年早い」と。

お客さん相手にここまで言ったりはしないですし、部下に１０年かかられても困りますが（笑）。
とにかく、何か新しいことを覚えるに当たっては、こういう「何がベストか？」という考え方はまず捨てましょう。それを考えるのは、最善ではなく不細工なものであったとしても何か１つの手法を自分の中で確立した後の話です。だって、その確立したものが無ければ、どっちが「ベター」かの比較のしようも無いでしょ。いわんや「ベスト」をや、ですよ。


さて、それでは具体的にスクリプトに対する対処方法を書きましょう（今までの文書は序文（笑））。

まずは標準でインストールされている「SCRIPTウィザード」のスクリプトを使うことです。

スクリプト初心者がいきなり自分で１からスクリプトを書き始めてはいけません。またスクリプトを本気で学ぼうとするならば、いきなりghostさんが作られたような高レベルのスクリプトを使ってもいけません（絶対とは言いませんが）。

自分が理解し扱えそうな単純なスクリプト群を「SCRIPTウィザード」で作らせ、それを動かし、それを解析し、そのパラメーター等を弄って、まずは最小限の理解をすることが大切です。単純なものから手を出さないと混乱するだけです。

ghostさんは「SCRIPTウィザードのこのスクリプトは宜しくない」という発言をされることがありますが、初心者はその言葉を鵜呑みにしてSCRIPTウィザードを使わないということをしてはいけません。まず最善ではなくとも理解しやすいものを使うべきです。そして、それが理解できて始めて、ghostさんの言葉を考えるべきです。

という訳で、偉そうなことを申し上げておりますが、結局のところ、「トライ＆エラー（試行錯誤）を繰り返して、覚えていくしかないよ」という当たり前のことを言っているに過ぎません。こういうことが苦手とか嫌いとか仰る人には、まぁ向いていないということで、諦めるか、ghostさんに頼るかのどちらかしかないでしょう。


第３段階「チャレンジしたけどうまくいかない人」

ここでようやくcaldiaさんの記事と、それに対する45-50sさんとghostさんの「はてブでのコメント」の話になります。

caldiaさんの記事では、「「動作が見えない」⇒「わかりづらい」⇒「難しい」」というお話ですが、確かに「わかりづらい」ことが「難しい」と感じる方もいらっしゃるとは思うので間違ってはいないとは思います。ただ、もっと大きい根本的な理由があると思います。それが、

45-50sさん＞難しい要因が「条件式」「見えない処理」というのはあるけどそれだけじゃないと思います。むしろ一行一行のスクリプトが簡単すぎて幻滅するのではとか。

ghostさん＞個人的には、普通のユーザーは“結果指向”であり、そこから段階を遡って原因を考えるという発想がそもそもないのだと思っている（悪いことではない）。

というおふたりのコメントにあると思いますし、私もおふたりの意見に同感です。一見おふたりのコメントは別もののように見えますが、実はこの２つの意見の根っこの部分は同じものだと思いますので、補足という名の余計なお世話を１つ。


これはプログラム設計に限らず、機械設計でも言えることなので、総じて「設計」というものに言えることだと思いますが、この「設計」が苦手とか出来ないとかいう人に言えることは、「事象の把握と細分化、それに対する方策の構築というものが出来ない」ということだと思います。難しい言葉を使ってそれらしく言ってしまいましたね。具体例を示し、簡単な言葉に翻訳していきましょう。

例えば、ＶＲＭ４でスクリプトを使って「１編成による自動運転」（という大分類）をやらせたいとします。その「自動運転」の内容が複雑であれば複雑であるほど、「噛み砕いて分解」していかなくてはならない要素が増えます。

実際の「自動運転」を考えると「出発」「加速」「減速」「停止」「再出発」「分岐」といったような各要素にまず分解できるわけです。まだこの「出発」とかのレベルはまだ中分類です。その中分類の「出発」の中に、「信号機を青にする」「発車ベルを鳴らす」「発車する」というような小分類の項目が来ます。ここで場合によっては小分類の「発車する」によって中分類の「加速」は兼用できるので不要になるかもしれません。そういった全体を把握しつつ、細かい要素に分解していくという作業を通じて、全体を構築しておくということが必要なのです。

こういった骨格というか流れみたいなものを無視して、いきなり細部のスクリプトを書いていってしまうと、後で破綻したり行き詰まったりすることがあるのです。慣れている人はこれを頭の中に咄嗟に描き出すことが出来ます。しかし、慣れていない人には当然出来ません。そういう人はまず紙に設計図（フローチャート等）を書くことです。そうして、全体を把握しつつ、細かい要素に分解していけば、自ずと道は見えてきます。小分類の「信号機を青にする」といったものになれば、実際のスクリプト言語でどう書けば良いのかということにかなり近づいてきているはずです。

これがつまり、ghostさんの仰る「そこから段階を遡って原因を考える」というコメントにつながるものであり、そういった分解をかなり細かいレベルまでやっていかないと実際のスクリプトに翻訳できないので、45-50sさんの仰る「むしろ一行一行のスクリプトが簡単すぎて幻滅するのでは」というコメントにつながる訳です。

如何でしょうか？　おわかりいただけましたでしょうか？
・・・そんなことわかっている？　それは失礼。

もちろん、これ以外にも変数というものの基本的な使い方ですとか、ＶＲＭ４のスクリプトはオブジェクト指向言語なのでイベントドリブン方式の基礎知識とかいったものも必要になりますが、この「大局から細部へ」「解体作業から翻訳作業へ」「そして全体をとりまとめる」といった流れを頭に思い浮かべておかなければ、なかなかうまくいくものではないということなのです。

設計に携わる技術屋にとってはごく当たり前のことなのですが、技術屋でもなければこんなことは当たり前のことではないので、それがハードルになっているのではないかと思います。


「最後に」

最後になりますが、このスクリプトの習得にはある意味、職人気質が求められると思います。

ある程度スクリプトが扱えるようになってきたら、先達の築き上げてきたものを見て、そこから技を盗んで自らのものにするということが、レベルアップには必要です。幸いにもＶＲＭ界にはghostさんというＶＲＭスクリプトの大御所がいらっしゃるわけで、ghostさんのスクリプトから学ばない手はないわけであります。まぁ私は色々あってそれが出来ていないので偉そうなことは言えませんが（笑）。

更に付け加えると（余談ではありますが）、「VRMスクリプト会議室」によく「○○がわかりません。教えてください。」なんて質問をする人がいますが、私だったら「もう少しまともな質問を考えて出直してこいや」と言って追い返すだけですね。まぁ実際に「ほったらかし」状態になっていますが。

そういう質問をする人には「質問を受ける立場の人のことを考えなさいよ」と申し上げたい。全く努力もせずに人に尋ねるのは論外として、「あなたがどのレベルにいて、どのような状況でどういった問題に当たったのか」がわからなければ答えようがないし、それを推測して考えてあげようなんてことは面倒臭いし、かなりの労力を必要とするので答える気になどなりはしないでしょう。それに「こういう質問の仕方をする人には例え答えを教えてあげても、その人の実力が伸びるわけでもない」ということを私は経験しているので、皆さんも同じ考えなのでしょう。現実社会となんら変わらないということですよ。

・・・ここで書いても仕方ないか。「VRMスクリプト会議室」にでも書き込まないと対象者に伝わらんな。