Advice for Creative Technologists

この記事は、ニューヨークのFake Loveのクリエイティブ・テクノロジストであるブレア・ニール氏のMediumでの記事「Advice for Creative Technologists」の内容が素晴らしかったということで、1-10の森岡さんに紹介してもらった記事を、テクニカルディレクターとして活動しているBASSDRUMの清水がブレアさん本人の許可を得て、翻訳したものです。
Blair Neal
https://twitter.com/laserpilot
Visuals/Music/Art/Code/Tech/Humans - Director of Creative Technology at http://fakelove.tv
本文中では、「クリエイティブ・テクノロジスト」という用語が使われていて、これは厳密には技術にまつわるコミュニケーションをつかさどることが中心になるテクニカルディレクションよりももっと現場寄りなポジションとして描かれていますが、実際にやっている領域はかなり近いので、多くの要素はそのままテクニカル・ディレクターへのアドバイスとして活用することができます。

読みやすさのために、部分的にかなり超訳している部分もあるのと、まだ翻訳っぽい日本語になってしまっているところもありますが、ご容赦くださいませ。


クリエイティブ・テクノロジストへのアドバイス
ブレア・ニール

これを読んでいるあなたがもし初心者ならば、クリエイティブ・テクノロジーのプロの世界に入るのは大変なことだ。

この業界の中であなたの興味と能力に見合う、その上で生活を成り立たせてくれるような領域を見つけるのはなかなか難しい。

「クリエイティブ・テクノロジスト」という言葉はまだあんまりきちんと定義されていなくて、会社によっても全然定義が違ったりする。

ではあるが、あなたが技術を手段として使っているアーティストであるならば、あるいは(使い古された言い方だけど)「アートとテクノロジーの交差するところで仕事している」ならば、チャンスはあると思う。


この記事を通して、私は自分がクリエイティブ・テクノロジストとして過ごした日々の中で考えたいくつかのことをお伝えしたい。

私は自分が初心者の頃に戻ったつもりで、学んできたことや物について書いていこうと思う。

2010年にエレクトロニックアートの大学院を卒業したとき、私は自分のスキルをどういう職場だったら一番活かせるのかが全然わからなかった。

私は映像を撮って編集する方法を知っていたし、音楽を作曲してミックスすることもできた。AV機器をつかったりMax/MSPとC++をちょっとだけ使って、基本的なソフトウェアを書くこともできた。

私が卒業する前のほとんどの業務経験はコンピュータとかハードウェアのセットアップとイベントの制作仕事だった。

私はそのあたりの仕事まわりで便利な何でも屋だったが、どこかの会社に就職できるレベルで熟練したスキルはなかった。

最終的にどうにかこうにか、2011年にFake Loveに入社することができた。が、この領域はどんどん変わっていっている。そして、私が書いていく自分の経験のほとんどは、広告と制作の世界での仕事から得たものだ。なので、他の領域でクリエイティブ・テクノロジーをやっていきたいのであれば、ちょっとそっち寄りに偏った記事だと思っておいて欲しい。


で、9年経った。こんな感じの背景を持った学校を出たての人間が良い職を得るにはまだまだ問題が多い。しかし、この業務領域はここのところ、かなり成熟してきているし、安定してきていると思う。

この領域にはあなたの能力を活かせるいろんないい感じの就職先がある(あるいはまあ、自分の会社をつくっても良いと思う)。

いったん行き先を決めて、働く準備ができたところで、よりスムーズに仕事をしていくためのアドバイスをいくつかさせて欲しい。下記について書いていこうと思う。

・リスペクト
・チームワークとコミュニケーション
・自分が得たいスキルの設定と育成
・インスピレーションの維持
・細かいいろいろ

リスペクト

まず最初に、これはどんな業界でも言えることなので、あんまりこれについてくどくど言いたくはないと思っている。が、仕事の中のいくつかの領域については触れておいたほうが良いだろうと思う。

・自分へのリスペクト

これをするのはすごい楽しいのだが、ときにきつい。 

あなたは、ちょこちょこ良く知らない新しい技術や学習中の技術を使って、ストレスとプレッシャーの中で仕事をしなくてはならなくなる。 

スケジュールは得てしてきつい。なんだかうまくいかないことも多々ある。
大企業の仕事をするようなこともあるだろう。ライブイベントは、あなたを待ってくれはしない。 

広告の仕事っていうのは人を縛って潰すものだとも言われている。 

ちゃんと自分のために時間が確保されていることを確認しよう。 

どうやって仕事をこなすか、だけではなく、ちゃんと仕事に線引きしよう。自分のプライベートワークをちゃんと続けよう。自分の軸にあるものをちゃんとリスペクトすることで、より長続きするし、満足も得られるものだ。

・プロジェクトやクライアントへのリスペクト

業務の性質上、私たちが取り組むプロジェクトはだいたいそれまでにやられたことがないようなものだったりする。 

あなたのクライアントはプロジェクト全体の成功に賭けている。 

彼らはいま使おうとしているテクノロジーの詳細や限界については知らない。それどころかこういうインタラクティブなプロジェクトをやったことがなかったりする。 

クライアントがそういったものを理解するのを助けよう。で、導こう。なんだったらチームも教育しよう。 

多くの人は物わかりがいいと思う。しかしあなたは、クライアントの立場に立って、何が彼らを躊躇させるのかを考えないといけない。 

こういうふうにコミュニケーションするのは誠実だし、クライアントは常に課題に対して回答を持っているみたいに感じてくれるはずだ。 

早めにクライアントの信頼を勝ち取れば、プロジェクトの後半になって彼らがいろいろ迷いだしてもうまく行く。

・アートやアーティストへのリスペクト

あなたが取り組むプロジェクトは、アートの世界でつくられているものとたくさん共通点がある。 

しっかり時間をかけて、そういったアートの世界での仕事と技術活用から学ぶべきだ。 

しかし、「影響を受ける」ことと「パクリ」の間には微妙な境界線がある。そのあたりの倫理には則って欲しい。 

自分が作っているものが、既存の作品に似通い過ぎていることに気づいたら、チーム全体で方向性を変えるか、あるいはオリジナルをつくっているアーティストに連絡をするべきだ。 

お金や時間を寄付したり、ミートアップを開いたり、記事を書いたり、オープンソースコミュニティに貢献したり、アートのコミュニティに対してちゃんと「お返し」するべきだ。

・ユーザーへのリスペクト

プロジェクトがクライアントのために存在しているのではなく、クライアントの顧客、ユーザーのために存在しているようなことは多い。 

そういったユーザーとつながること、つまりユーザーの気持ちになって考えること、それが大事だ。あなたがつくっているものは、今まで誰も経験したことがないようなものになるだろう。直感的なインタラクションはわかりやすく、説明なしでユーザーを体験に引き込むことができる。 

「やらされてる感」なく、主体的にユーザーを導こう。

もう1つ、ユーザーをリスペクトするために大事なこと。それは、細かいところに手を抜かないことだ。マウスカーソルやメニューバーが画面上に出ていたり、装置の回路がむき出しになっていたりすると、ユーザーは現実に引き戻されてしまう。 

そういうところへのケアをしていないとき、体験はぶち壊しになってしまう。だからそういった最後の詰めはとても大事なのだ。

・チームへのリスペクト

これについては2つある。チームメンバーとしての場合と、チームを率いる立場の場合だ(ちゃんとやっていればあんまりこの2つには大差ないが)。
あなたが管理者なら、チームがベストを尽くせるように動くのが役割だ。明確な指示を出し、働かせすぎず、自分たちの時間をキープできるようにし、話を聞いてもらえている感じをつくる。ということだ。 

チームメンバーとしては、チームの誰もが違うスキルセットやバックグラウンド、あるいは不安を持ってプロジェクトに参加していることをわかるべきだ。 

みんながベストを目指しているということを信じれば、チームと歩調を合わせて進むことができる。 

大きなことでも小さなことでも感謝しよう。相手がつくったものを褒めよう。切磋琢磨しよう。これについては次の章で書いていく。

チームワークとコミュニケーション

キャリアを積んでいくと、より大きなチームで仕事をするようなことになるだろう。 

チームでの動き方を学ばないクリエイティブ・テクノロジストは、最終的に仕事の規模を広げられなくなってしまう。 

業界・コミュニティは狭い。だから誰それが一緒に働きやすいとか働きにくいとかそういう評判はすぐに広がってしまう。 

良いチームメンバーであろうとする努力は、必ず後で返ってくる。 


学校で何かつくるのなら、あなたのチームはクラスメートか一緒に作業するコラボレータになる。これはやりやすい。なぜかというと大概、同じ考え方とアプローチをする人たちだからだ。つくっているものについて、みんな同じ価値観を持つ。先生以外のクライアントはいないし、とにかくみんなが楽しんでくれるであろう何かをつくっていくだけだ。

最終的に、チームが成長すると、自分たちと同じようなアートとテクノロジーへの愛とリスペクトがない人や、違う価値観を持った人と仕事をしなければならなくなる。 

大きいプロジェクトになると、まあ技術だけの話ではなくなる。 

デザインやUX、お金に物流、ハードウェアや人材管理に至るまで、いろんな要素が出てくる。 

プロの世界に入っていくと、チームは制作から営業、クリエイティブやデザインに至るまで、いろんな人で構成されるようになる。 

働いている会社によっては、ファブリケータや舞台美術、あるいはハードウェアのセットアップやケーブリングまでやるような音響装置のチームなどの外部の人々と仕事をすることになる。 

そしてクライアントもいる。クライアント企業の担当だけではなくて、クライアント側の技術と連動するような場合は、クライアント側のいろんな人とコミュニケーションすることにもなる。


ビジネスをやっていくためには、いろんな人たちの力が必要になる。 

一緒に働く人たちの立場を理解するのは、とても大変で経験も必要だ。 

コンセプトをお買い上げいただくために、外向的で鋭く、自身に満ちたプレゼンターが必要になる。 

いけているものをつくるために、素晴らしいクリエイティブ・ディレクターが必要だ。 

戦略的に制作を進めて利益を上げるプロデューサーも必要だし、アイデアを形にするために内向的でオタッキーな技術チームも必要。こういったことは一人でやろうと思えば、できないこともない。 

しかし、適材適所で各々が得意なことをできている状態がよりよいはずだ。


チームをつくったとき、コミュニケーションが次なる障壁になる。 

特に、新しいテクノロジーを使って何かやっている場合、各々が最高のものをつくるためにいろんなことをやっていつつも、コミュニケーションがうまくいかなくなって破綻してしまうことがある。 

リアルタイムにテクノロジーの限界を学びながら、それをチーム全体に伝えていく必要もある。 

何か必要なときは、きちんと声をあげなくてはいけない。しつこすぎると引かれてしまうのが怖いかも知れないが、ちゃんと伝えることでみんながあなたがやっていることとやったことを理解してくれる。 

「なぜこのタッチスクリーンやセンサーを採用したのか?」とか「なぜこのARライブラリやモバイルデバイスを採用したのか?」とか、チーム内の技術がよくわからない人たちに、技術的判断について簡潔に説明しなくてはいけないこともある。


コミュニケーションについて、もう1つ重要なのが、批判を恐れないということだ。 

アートを学んできたことはその助けになるといえばなるが、十分ではない。あなたのプロとしての評価は、批判を受け入れ、学ぶ力に密接に関係している。 

とっつきにくくて好戦的にふるまうと、評判が落ちる。すぐに防衛的になってはいけない。他の人の言っていることをその人の立場になって理解しよう。 

これは、打たれ強い人になれということではないし、良い批判と、根拠のない悪い批判を見分ける能力もつけなくてはいけない。 

何にせよ、批判には感謝して前に進もう。ちゃんと主張して自分の考えをシェアする。ギブアンドテイクを楽しんでお互いを信頼する。


すべてのプロジェクトは違うプロジェクトだ。しかし、プロジェクトを正しく始めるためには、ちょっとした共通の大事なことがある。それは、機材構成図と、ソフトウェア構成図だ。 

機材構成図は、どんなハードウェアが必要か、どんな問題が起こりうるかを整理するのを助けてくれる。 

「うーん。このケーブルは200フィート(60メートル)延長しつつ、4Kの映像信号を送るのか・・・?」みたいな。 

機材構成図は他のチームメンバーとコミュニケーションする場合にも役立つし、設営現場やファブリケータ、映像音響機材チームとのコミュニケーションにも大いに役立つ。 

自分のインスタレーションにどのくらいの電力やどんなネットワークが必要か、などを知らなくてはいけないときに、この機材構成図は大きな助けになる。 

同じことは、複雑なシステムを設計する際につくる、ソフトウェアのUX構成図にも言える。いろんな要素が入ってくるときに、全体の流れを時間軸やイベントに分解して考える必要がある。

ユーザーがこれをやって、

センサーがこの情報を取得して、

バンクエンドがこれを処理して、

表示機がこれを表示して・・・

みたいなことだ。

たとえば、

こんな感じの構成図は技術チームで分業をしなければいけないときや、全体像をシェアしなくてはいけないようなときに非常に役に立つ。 

この図は、ユーザーがどういう体験をするのかを明瞭にしてくれるし、何か忘れていることがないかを確認できる。 

最後に、体験の検証やリスク検証計画を早くつくっておくことも、チームにとっては大きな助けになる。 

技術のことだけではなくて、最終的にプロジェクトを設営したときにどんな問題が起こるのかに準備しておくために、リスク管理は重要だ。開発を通してそういったリスクをクリエイティブチームに早めにシェアすることを心がけよう。そうすれば彼らは、作品が思い通りに動かないときのために前もって計画を立てておける。

自分が得たいスキルの設定と育成

クリエイティブ・テクノロジスト、という肩書きはまだまだ微妙な肩書だ。
(アンディ・ベルが2012年のEyeoでの講演でも言っていたが)90年代後半における「ウェブマスター」みたいな感じだ。 

この領域では、ある種ゼネラリスト(いろいろできる人)であることが求められる。センサーについて、映像表示装置について、ソフトウェア開発について、その他もろもろについてちょこちょこかじっておかないとプロジェクトがつくれない。 

しかし、毎年のように古い技術の上に新しい技術が登場する。全部の細かい変化についていくのは無理だ。


もしあなたが2019年におけるシニアなクリエイティブ・テクノロジストであるならば、知っておかなければいけないことの全体像が下記の図だ。 

すべてを深く知る必要はない。しかし、これらの技術がいつどのように使われるかは知っておかなくてはいけない。 

そしてもちろん、抜け漏れや間違いもある。まあこれは、ざっくりとしたものだと考えてほしい。 

これらをマスターしようとするのは無益だ。何かのスキルに集中して、本当にあなたが得意だと思える領域を育てることが重要になってくる。 

何でも屋としての知識をキープしつつ、自分の専門領域を見つけることは、あなたのキャリアにとってとても重要なことだ。新しい人を採用したりフリーランサーを探すときに、自分の場合は何でも屋の人を選ぶことは少ない。
自分は、グラフィックなりバックエンド開発なり、センサーとの連動なり、ハードウェアの専門家なり、強力な能力を持った人を必要とすることが多い。 

私だったら、何かをやるために新しいスキルを学ばなくてはいけない何でも屋よりは、既にやり方を知っている専門家と一緒に仕事をしたい。 


「これだ!」というものを見つけるのには時間がかかる。たとえば何かにハマってやってみて、1年後にそれが自分がやりたいことでないとわかったり向いていないとわかったりすることもある。素晴らしい作品を見たとき、そのすべてを学びたくなったりするものだ。アートと技術を両方やる学校なんかにいても、専門を見つけるために十分な時間を得られるわけではない。単位を取るために、ウェブの開発やらProcessing/openFrameworks/Unityみたいのから機械学習にARにデジタルファブリケーションに、ウェアラブル、ジェネラティブオーディオ、UIデザイン、映像制作、などなど、いろいろやらなくてはいけない。 

これらは、数年で吸収するには多すぎるし、他の場所でそれらの素晴らしさに気づいたりもするだろう。(ちなみに、こういったクラスに出席することは、アート+技術の業界で働く上で必須ではない。自分で学習したり、他の仕事の中で学ぶことは全然できる) 


その一方で、1つのスキルや道具に突っ込みすぎるのもキャリアを積む上で有害だったりする。Flashばっかり何年もやっていた人々のことを考えてみればわかる。同じことがいつ今のUnityの開発者に起こってもおかしくない。
バランスが鍵だ。プロジェクトの進め方や作り方を学ぶようにすれば、それは、専門的過ぎる技術に没頭するよりも、もっと長持ちするスキルになるはずだ。

私はQuartz Composerでなにかつくるのが好きで、ずいぶん時間を費やしたが、今の若い人たちはたぶん「Quartz Composerってなんだよ?」みたいな感じだろう。しかし、Quartz Composerを通して学んだ「どうやってものをつくるか」は、自分の中に残っている。プログラミングのルールを一度学んでしまえば、他の言語はちょっとした新しい言葉遣いを学べば習得できてしまう。 


いったんプロの仕事に就いたら、仕事を通して学ぶようになる。これがまた、自分の「これだ!」を見つけづらくしてしまう。学校の環境で学ぶときのように、自分で方向付けができないからだ。自分が本当は得意ではないプロジェクトをやらなきゃいけないこともある。それはまあいい。そんなときでもいろんなやりようがある。仕事の後にスキルを磨いて対応してもいいし、自分の限界を認識して諦めてもいい。次にそういうことが起こったときにちゃんと対処できるようにすればいい。 

管理職になりたいのなら開発チームの限界を知るのは重要だし、チームを補強しなくてはいけないタイミングを知るのも重要だ。

その他、知っておくと良いこと

下記について、うまくカテゴライズできなかったのだが、まあいずれにせよ知っておいたほうが良いことを書いておく。追記もする予定だ。


インスピレーションの維持

もし仕事でやっている作業が、自分のパーソナルプロジェクトと似た感じのものだった場合、パーソナルプロジェクトをやる気があんまりなくなってしまったり、他にやりたいことを見つけたくなったりするはずだ。 

それを自覚してちゃんとやっている限りは問題ない。 

もしそういう状況だとしても、パーソナルプロジェクトを続けるのは重要だ。仕事上のゴールと違う目的を持って自由にいろいろやってみるのは大事なことだからだ。


こういったパーソナルプロジェクトを通して学ぶ、予想外の結果やプロセスは、後々仕事にも役立つはずだ。


ここ数年の仕事を通して、私はライブパフォーマンスを仕切ることができるようになったし、変わったモバイルゲームをつくれるようになった。ミュージックビデオもつくれるし、他にも数え切れないプロジェクトに参加した。そのうちのいくつかは全然仕事とは関係なかったし、仕事の合間につくったものもあった。しかしどれ1つとっても無駄になっていない。


あと、仲間からインスピレーションを受けて切磋琢磨するために、コミュニティにつながっておくのはとても大事だ。 

私は個人的に、時間があるときにイベントを開催するのは好きだ。場をつくって、自分たちの仕事をシェアすることはとても大事だ。

もし入りたいコミュニティがなければ、つくってしまうのもいい。


契約書を読む

契約書というのは、業界においてとても大事だ。

フリーランスとして働いていたとき、人を信頼しすぎてしまったり、契約をちゃんと確認しなかったりで、何回か大変な目にあった。

プロジェクトの内容はちょこちょこ変わるし、最悪プロジェクトが変更したりなくなったりした場合に自分を守れるようにしておかなければいけない。
遊びでやっているような小さいプロジェクトでも、お金のやりとりはある。面倒臭がらずに記録して合意しておくのは大事だ。

自分で大きなプロジェクトを動かすような場合、複雑な書類を見てくれる顧問弁護士がいたほうが良いだろう。

ちゃんと30日で支払ってくれるか、とかそういうことを恐れずにしっかり確認しよう。これはビジネスなわけだから、面倒な人と思われたりすることはない。


自分の価値を知る。

契約を読むことにもつながるが、もしフリーランスで働いていたり、起業しようとしている場合、露出を目的とした安い仕事を持ってくる人にはすごく注意したほうがいい。

もしプロジェクトがブランドや高額なイベントに関わるものなら、お金はあるはずだ。そういったものの予算は通常、ちゃんと出ている。自分にとって情熱だけでできてしまうアートプロジェクトに見えたとしても、クライアントがお金を払っているなら、あなたもお金を支払われるべきだ。


お金を出ししぶるのは誰にとってもよくないことだし、将来の業界のレベルの底上げを難しくする。

もちろん、自分のポートフォリオのために仕事をしなければいけないこともある。しかし、ちゃんと自分を尊重して、いまつくっているものは、常設のものではなくて一時的なものということを確認することが大事だ。


正確な開発予算はは働いている街によって変わるし、プロジェクトによっても変わるが、仲間に聞いても良いし、私にプライベートメッセージで聞いてくれてもいい。

whopaysartists.comをみるのも、良い方法だ。

もしフルタイムの仕事を探しているようなときでも同じだ。小さい事務所から給料が良くて福利厚生がちゃんとしている大きい代理店に至るまで、いろんな仕事がある。

小さいスタートアップに入る場合、株をもらうようにするとか、会社を売ったときに何かもらえるようにするとか、そういう条件を要求することもできるだろうが、対価として安いサラリーを受け入れちゃダメだ。

まあ、フリーランスと同じ金額で仕事しないといけないとか思ってはいけない。自分の能力でちゃんと仕事に貢献できると思ったら、ギャラを上げるべきだ。


制作倫理について

広告の世界だと、自分が共感できない業界や会社のために働かなくてはいけないこともあるだろう。
あるいは、その商品が全然良いと思えないような場合もあるだろう。
ユーザーの同意を得ずにデータや写真を集めてしまうような仕事をさせられることもある。
自分の知り合いがつくったアートに似ている何かをつくらされそうになることもある。
この話は書こうと思えば長くなるが、自分の意見を持って、一緒に働いている人や上司と、気持ちよくプロジェクトに取り組めるようにコミュニケーションしよう。


ソフトウェアライセンスをチェックしよう!

上記の「倫理」にも関係してくるが、オープンソースソフトウェアを使って何か開発する場合、概ねの作者はそれにライセンスを設定しているはずだ。
大概の場合、何に利用しても良いMITライセンスだったりするが、一部の作者は「商用利用不可」みたいな規定をreadmeファイルに入れていたりする。
法的な問題はさておき、そういった、「アート利用・非商用利用」を求められている場合はそれに従うべきだ。 

利用について質問があれば、作者に問い合わせよう。 

また、プロジェクトに予算がある場合は、その一部をソフトウェアの作者に支払うことで、自分の開発期間を何日間も何週間も短縮できたりする。


個人情報とデータセキュリティの取扱いは、よりシビアになっている

これは当たり前のことだが、強調しておくにこしたことはない。パーソナルプロジェクトをやっているときは、そんなにたくさんのEメールとか顔写真の扱いに悩むことはないだろう。しかし大企業の仕事をやり始めると、これはすべてのプロジェクトにおいて重要な問題になってくる。 

金融とか薬品とか健康系のクライアントの仕事をやるときなんかは特にそうだ。 

これらの業界では、厳しいコンプライアンスがあるので、先方のルールに沿わなくてはならないし、多くの開発期間を食う。 

さらに、ヨーロッパのGDPRとかカリフォルニアで2020年に始まるCCPAなどの個人情報保護施策は、さらに個人情報の収集をややこしくする。 

一市民としては良いことでしかないが、開発者としては、将来のプロジェクトにおいて、このへんが面倒になることを覚悟しなくてはいけない。 

このあたりのことについては早めに共通の危機認識を持っておくに越したことはない。パスワードや秘密鍵はちゃんと厳重に取り扱ったり、ネットワーク上には置かないようにしたりしよう。


K.I.S.S.

常に「シンプルで愚直であれ(=keep it simple, stupid)」。 

技術アプローチをシンプルで堅牢でわかりやすくする。私たちがつくっているものは得てして複雑になっていくので、なるべく1つのアプリケーションに全部入れたりしてシンプルに保つのが大事だ。 

時間が山ほどある場合を除いて、今までにやられたことがあるようなものなり、結果が出ているものなりがある場合は、最新のテクノロジーに手を出す必要はない。


無線を信じるな

これについては私を信じてほしい笑。 

ネットワークの問題についてはそれだけで1つの記事になる。 

つくっているものが無線で接続される必要がないのなら、有線でやることを考えよう。 

オフィスでちゃんと動いていても、現場に行くとなぜか動かなくなっちゃたりする。 

自分でルータを用意したりするとどうにかなることもある。自分でコントロールできない、現場にもともと設置してあるWi-fiには、いろんなリスクがある。電波が弱かったり、ファイアウォールが入っていたり、接続クライアントを限定していたり。 

それと、Bluetooth。Bluetoothに依存したプロジェクトをいくつもやってきたが、あれは大変だ。使わなくてはいけないのならば、ちゃんと耐久テストをしたほうが良い。


クライアントの製品を変えてしまうやり方は避ける

要素技術はいろいろ組み合わせてものをつくっていかなければいけないが、クライアント側がつくったものは触らないように注意したほうが良い。 

センサーを入れたり、インタラクションしやすくするために、製品の形を変えることはきっとできないだろう。 

製品の見た目を変えないために、通常採用しないセンシングシステムでものをつくったことが何度もある。 

クライアントの技術をデモンストレーションするような場合も、同じことが言える。ハードウェアの基幹部分には触れないだろうし、ソフトウェアのUXをいじることもできない。

これに関連するが、もし自分のアイデアがクライアント側のAPIなりと密接に連動したりするような場合、なるべく早めに情報提供をお願いすべきだ。「クライアント側が間違いなく内部的に持っているだろうデータ」にアクセスしたいような場合とか、クライアント側のデータを通常とは違う方法で入手したいような場合、本当にそうした方が良い。 

先方のエンジニアと電話で話して何が必要かを伝えてみよう。クライアントは予算を計上して仕事を依頼してきている。この予算は通常、外部にいろいろ全部やってもらう前提で組まれているので、内部リソースを投入するのを渋るケースはよくある。 

また、法務確認が必要なセンシティブなデータにアクセスしたいようなこともあるだろうし、コードレビューなんかがあると、開発に時間がかかってしまう。もちろん企業は各々違うし、イノベーティブな協業を望んでいる。が、そのへんは注意した方が良い。

業界の定例イベントを意識して、準備しよう

これは広告やイベントの仕事向けの話だが、たとえばSXSWとかE3とかコミコンとかCESとか、テレビで何をやるかとか、賞がいつ行われるか、あるいは、オリンピックやワールドカップがいつ行われるのか、あとはヨーロッパの人がいつみんなで休日を取るのか、とかそういうことを知っておくのは、大事だ。 

毎年のように、そういったイベントのどれかに関係した仕事が発生する。大きいプロジェクトは計画に何ヶ月もかかるし、実装にもっと時間がかかったりする。1年前に仕事が来ることもあれば、2週間前に来るようなこともある。


現場のみんなと仲良くなろう

現場にいるいろんな人からは学べることが多い。そして、それが全体の流れをスムーズにする。 

たとえば音響チームは、いろんなタイプのケーブルを使ったり(光ファイバーと銅線とか)、電源をコントロールしたり、ライトをうまいこと設置したり、「弁当箱(現場では本当にこう呼ばれている)」からどのくらいの電力が出ているかについて悩んでいたりする。 

ファブリケータは、床や保護シートをバミったり、床を傷つけないために保護材を入れたりとかする。 

彼らの専門用語や進め方を学ぶことは、将来の仕事にとても役立つ。どうやっているのかわからなかったら、ちゃんと聞こう!


バックアップを用意しよう

大きいインスタレーションの仕事をやっているようなとき、ディスプレイアダプターが1つ壊れるだけで仕組み全体がうまく動かなくなったりもする。というわけで、バックアップをちゃんと用意しよう。いろいろ大きな仕事をやっていると最終的に大規模で冗長なシステムが必要になってくる。 

本番数時間前に、部品屋さんがないような場所で何が故障してしまうかは誰にもわからない。


見つけた技術資料をキープしよう

提案用にリサーチしているとき、変わったテクノロジーや開発会社を見つけたら、リンクや資料を保存している。 

あれがどのLED業者のものだったか、あの黒い粉の中で光っているやつがどこのものだったか、変わった光ファイバーのウェブサイトはどこだったか、を思い出さなきゃならなくなったりするし、良い屋外用のTVをどこが扱っていたか。いつ思い出さなくてはならなくなるか、わからない。


プロジェクターはそんなに明るくない。

覚えておかなくちゃ。


チームの多様性は重要

他の記事で散々書かれていることだが、技術の領域では全体的にもっと多様性を高める努力が必要だ。
幅広く、一緒に働ける人を探そう。

 
細かい部分は超重要

ちょっと前述したが、再度言っておく。マウスカーソルをちゃんと消しといたり、つくったものが60fpsで動くようにしたり、配線を整理したり、というところで、そのプロジェクトが誇るべきプロの仕事になるか適当な片手間仕事になるかが決まる。 

その上で、どうすれば自分のプロジェクトが長持ちするものになるか、あるいは少なくともメンテしやすいものになるかを考えよう。

クラッシュや電源が落ちたときに復帰する仕組みを淹れておこう。こういったものは小さいことのようだが、あなたがこういったこと全てに気を配っていることをクライアントが知ったとき、安心と信頼を勝ち得るだろう。


そしてさらに、常設展示をつくるのと、一時的に展示するインスタレーションをつくるのとでは全然違う。常設展示は、注意深く企画・設計される必要があるし、開発にも時間がかかる。 

そして常設展示の場合、全体のプロセスを完璧に資料にしておく必要がある。クライアントのためにだけではなく、自分のためにだ。1年後、2年後にまたその仕組みをいじらなくてはいけなくなったときに、どういう仕組みだったかを忘れてしまうものだ。


根性大事

この業界は大変な業界だ。クライアントワークで、やりたいことと違うことをずっとやっていたりすることもあるだろう。 

思っていたのと違う形で仕事を始めないといけないこともあるだろう。
夢見た仕事に就いたらそれが地獄だったようなこともある。 

この9年間、半端なくいろんな経験をした。こだわり続けて、頑張り続けて、修羅場と失敗から学び続けてやっと、ちょっとだけ一息つけるはずだ。


今のところこんなものだ。
何かあったらまた追加する。読んでくれてありがとう!
そして、いろいろアイデアをくれたり編集してくれたりしたみんなにお礼を言いたい。
Jasmin Rubinovitzさん、Raphael Palefsky-Smithさん、James Powderlyさん、Paul Elsbergさん、Tim Stuttsさんから、追加の要素や、フィードバックを頂きました。

自分が書いた他のおすすめ記事を置いておくので、良ければ読んでください(訳者註:下記は訳していないので原文です)。 


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

38

qanta

BASSDRUM / Tech Director - http://bassdrum.org - http://qanta.jp 日記と過去記事が掲載されるはずです。

note.bassdrum

BASSDRUMが発信する検証や実験、読み物などを発信していきます。お仕事のお問い合わせは、 hello@bassdrum.org まで。 https://twitter.com/bassdrum_org
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。