エンジニアと脚本家

mercy
·

理系と文系

この混ざり様のない二つの仕事をしているが、エンジニアって真面目でお堅い人が多いんじゃないかというイメージもあるが、もちろんそういう方もるが、文系出身のエンジニアもいるし、めちゃくちゃ技術力ある人でもアニメの話とかで盛り上がったりして、全然その系統で分けるのは意味がなく、人それぞれって言葉に尽きると思う。

脚本もそう、台詞は文系かもしれないが、構成は理系的な思考が必要だったりして、その両方が必要だったりする。

プログラミングと脚本

キーボードをカタカタ打つのが一緒なだけで、書いてる内容は全く違うんじゃないかと思われるが、意外に似ている。

私のやっている開発はスマートフォンアプリなので、Obj-c、Swift、Java、Kotlin、Flutterなどのオブジェクト指向言語。実はシナリオと作りが一緒。

プログミング → 脚本

  1. プロパティを定義 → キャラクターを作る

  2. プロパティの型 → どんな性格かを表現する

  3. メソッド作成 → そのキャラクターが別のキャラクターと合流し、事件や何かを起こす。

  4. 結果を返却 → 問題が解決し、新しい何かを見つける。

もちろん細かく見ていったら違う部分もあるし、かなりこじつけ感はあるが、実際、脚本書いていて、何か上手くいってない場合などで構成を見直す際に、プログラミングの構成を見直すように、辻褄がおかしく、道理がが通っていない部分などを見直す場合がある。

とは言え全然別モノ

結局のところプログラミングやってたら脚本が書ける訳でもないし、その逆も然り。だからやりくりは難しい。どちらもフリーランスなので、エンジニアの仕事は契約上の勤務時間を日中にこなさなければいけないし、夜や休日は脚本作業をしなければいけない。そうなると問題が生じる。

新しいものを取り入れる

エンジニアとして新しい技術をキャッチアップできない!

脚本家として新しい映画やドラマをキャッチアップできない!

この二つに悩まされる。どちらの仕事でもある一側面では必要であったりする。打ち合わせとか雑談とかで。新しいものを知らないだけでマウントとられたり、とったりw

でも、これってほんとに必要なのは一部の人だけだったりする。通常業務で、新しい事ってすぐに採用されることはない。

エンジニアで言えば、その技術を入れるために大幅なソースコードの変更や、対応OSを上げなきゃいけなかったり、実際それって運用が回っているサービスだと難しい。

脚本で言えば、もう使われているので二番煎じになってしまったり、へたすりゃパクリだとも言われる。

もちろん「新しい事を知る」「新しいチャレンジをする」が必要である現場もある。そう言う時は、やる。

でも、そうじゃない現場が大多数。実は、新しい技術取り入れたぞ!っていう自己満足でしかなかったりする。そんなことより、目の前の業務がバグがなく、障害がなく、要件を満たし、顧客に不満が生じず、安全安心にサービスを提供する事の方が重要だ。脚本もそう。突飛な今までにない、新しい価値観で物語を紡ぐ企画だったらいいけど、そうではなく、一定数のできるだけ多くの人が楽しめる物語であれば、使い古された展開が良かったりすることもある。

必要になった時に、勉強して、取り入れて、活かせばいい。余裕があれば、ちょっと勉強して、活かせばいい。自分ができなかったら「さーせん」と言って、得意な人に任せて、自分は自分の得意な事をやればいい、それだけの事。

これは元任天堂のゲーム開発者・横井軍平氏の製作哲学「枯れた技術の水平思考」に通づるものがある。

一応、今のところ、エンジニアは10年ちょっと、脚本家は3年ちょっと、仕事は継続して貰えているので、そんなに間違った事ではないかと思う。

とはいえ、新しい古いに限らず「あの技術勉強しとかないとな」とも思うし、「あの映画・ドラマ見とかなきゃな」っていうのは思ってはいる。時間は有限なので、うまくやっていくしかない。

@mercy
二足のわらじ、たまに三足いや二.五足