デザイナーだった私がどうやってスクリプトを組めるようになったか？

私は他社で15 年ほどデザイナー職だったのですが、2 年前に株式会社セガへ入社し、テクニカルアーティストへ転向しました。

デザイナーの多くがプログラムを勉強してもなかなか身につかず、志し半ばで挫折するケースが多いのではないかと思いましたので、私がどのような経緯でスクリプトを組めるようになったのかをご紹介いたします。

きっかけ

私は今までデザインやデザイン管理、デザインワークフローの構築等に従事していたのですが、あるときテクニカルアーティストの強烈な仕事の成果を目の当たりにしてから、「自分もそうなりたい」と思うようになりました。

しかし当時の私はプログラムやDCC ツールのスクリプトを組んだ経験はなく、経験も知識もない自分にできるのだろうかと疑問でいっぱいでしたが、「テクニカルアーティスト」が放つ強烈な印象を忘れることができなかったので、ダメ元でやってみようと思い、行動を起こしました。

最初のアプローチと壁 ～「良い感じ」にならないことへの不満

まず「プログラム作成の基礎が理解できていないとスクリプトは組めない」と考えたので、会社と自宅のPC にVisual C++ をインストールして、休み時間や休日を利用してプログラム例文をひたすら打ち込むことにしました。

しかし、学んでいくうちにデザインとまったく関係ないように思える内容について「これを覚えると本当にテクニカルデザイナーになれるのだろうか？」……という疑問に襲われました。

どうしたらデザイナー的感覚での「良い感じ」なプログラムになるのかビジョンがまったく見えなくなり、デザイナーがプログラムを覚えようとすると最初に遭遇する「目的を見いだせない壁」にぶつかったのです。

その結果、教本を何周かなぞらえた後に勉強を投げ出してしまいました。

ピンチと転機

その後、現在勤めている株式会社セガへ転職し、デザイン業務から離れ、Maya を使った開発現場への技術サポート業務に従事しました。

入社したての頃はMaya のスクリプトであるmel も組めませんでしたが、あるときmelをスクリプトエディタで開いて中身を眺めていると、部分的に何をやっているかわかることに気がつきました。

mel がC 言語のルールに似ていたため、以前勉強していたプログラムの基礎学習がここで開花したのです。

それからほどなくして、ある業務でまだまともに組んだことがないmel を私が書かねばならなくなる個人的なピンチに遭遇しました。

基礎学習を思い出し、mel リファレンスを調べ、わからないところは弊社のMaya ツールプログラマーに教えを乞い、何とか現場に出せるmel を完成させました。

これが転機となり、私が組めそうなmel 作成の案件は自分で受けて現場へ提供し、以前よりクオリティの高いサポートを開発現場へ促せるようになりました。

結論

デザイナーだった私がスクリプトを組めるようになったのは、次の「違い」に気づいたからです。

まず、モチベーションの発生源の違いです。

デザインは感覚的な「良い感じ」の追求がモチベーションの発生源になりますが、プログラムは「自分が行いたい、最も効率的、かつ効果的な処理のロジック」を完成させることがその発生源になります。

次に、デザインとプログラムの作業工程の違いです。

デザイン作業は完成の指標が「良い感じか否か？」のような曖昧な場合が多く、納得するまで果てなく完成形を模索できるので、作業初期に明確なデザインの完成形を決めづらいのですが、プログラムは作成当初から処理のゴールを明確にしなければならないため、仕様や指標が曖昧だとプログラムを完成させることが極めて困難になります。

プログラム作業の開始前に明確な処理のゴールを決めることは、プログラマーにとってはすごく当たり前なことですが、感覚作業が主であるデザイナーはこの違いになかなか気づかないのです。

これらに気がつくことで、初めて「壁」を乗り越えられると思います。

この経験談を読んだことで1 人でもスクリプトを組めるデザイナーが増えたら幸いです。