graphics.hatenablog.com

技術系テクニカルアーティストのあれこれ

テクニカルアーティストのための「5つの習慣」

GDC Vault - Technical Artist Bootcamp: Identifying Technical Art by Its Habits

あまり見かけないかんじでおもしろかったのでざっとまとめてみる。内容は、「習慣」というものからどういった性質をもつ人間がテクニカルアーティストたりうるかを考える、といったもの。


前半はビジネス系啓発本でよくある「なぜ "習慣" について考えるのか？」という話なので、それこそ「7つの習慣」でも読めばいい。そのあたりの思想を前面に出してくる TA に会う機会なんてそう滅多にあるものではないので、そういう意味でも、TA としてのちょうどいい差別化要因になるのかなという気はする。

あと個人的な印象では、いわゆる「自責/他責」の話題に絡む部分が多いなーと。周囲を動かすために如何に自分が動いていけるか、みたいな。このあたりは以下の一連のエントリもとても良い資料だと思う。


というわけで以下、後半部分にある具体的な「習慣」についてのまとめ。超訳とも言う。なお、文中の一人称はこの講演の講演者を指す。

フレーミング効果 (Reframing)

問題それ自体を変えることはできなくても、問題に対する視点を変えることで、それがどういった問題なのかという認識がだいぶ変わってくる。ゲーム開発のなかでテクニカルアーティストが扱う話題なんて不確実性の塊みたいなもんだけど、不確実だからこそ、複数の視点から観察する価値があるというもの。そこから思いもよらなかった改善点、あるいは問題点が見えてくるかもしれない。

　たとえば、とあるアーティストが Perforce の問題点について相談してきたとしよう。

  • そもそも なぜ そんな問題が起きたのか？
    • Perforce についての理解が浅いために、的外れな誤解から不適切な問題提起をしていた。
  • では相談者は なぜ 正しい知識を持っていないのか？
    • そんな知識は持っていて当然、あるいは業務を通して体得すべきものと思っていた。または時間的な成約のために、研修期間がまっさきに削られてしまった。
  • 「持っていて欲しい知識」があるにも関わらず、 なぜ それを教えていなかったのか？
    • 教育の責任は現場のリーダーにあると考えたが、彼らは彼らでいつも忙しかった。
  • なぜ その責任がリーダーにあると考えたのか？
    • 彼らは本来であれば、実際にそれをやってみせたり、現場からの相談に応じたりするべきだ。
  • なぜ そうのように考えているのか？
    • 長期間に渡りそれらを行って結果を出すは難しいことので、そういった機会を模索していなかった。そのため、現場との適切なコミュニケーションが生まれていなかった。


　最終的に私たちが出した解決策は以下のようなものだ

  • テクニカルアーティストがビデオ講義と作成して社内 wiki にて共有した。
  • それらを新人研修の一部に組み込んだ上で、研修中に設けたチェックポイントで理解度の確認を行った。


　そもそもテクニカルアーティストとは、これらの問題に取り組むことを通して、個々のスタッフがアーティストとして自立していけるよう力添えをすべき立場だといえる。

最初の「なぜ？」に答えただけでは何の解決策も見えてこない。だが、「そう答えた理由」を視点を変えながら深掘りしていくことで、背景に潜む問題や、それまで見えていなかった改善点が見えるようになってくる。

概観効果 (The Overview Effect)

宇宙飛行士が宇宙から地球を見下ろすと、自分が如何に巨大な系の一部であるか、またそれらがすべて繋がっているのだと実感して、意識の変革が起こるという。普段の自分がいる場所から一歩引いて全体を見渡すことで、ひとつひとつの小さな行いが関連するすべてのものごとに波及して、結果的に大きな影響を与えうることがわかる。

　例えばテクニカルアーティストとして、描画系のパフォーマンスに責任を持っているとしよう。これはゲーム開発に携わるすべての担当者に関わる問題で、ちょっとしたルール付けが最終結果に劇的な変化を与えうる良い例だろう。


　一人のプランナーが、誰にも相談せずにカットシーンのカメラ位置を変えてしまったとする。それによって非常に計算負荷の高いピクセルが描画範囲内に多く含まれるようになってしまい、数日後の QA 時にフレーム落ちというかたちで問題が発覚した。


　一方のプランナーはそんなことも露知らず、その変更には既にゴーサインが出てしまっている。私たちにはフレーム落ちを解消する責任がある。もちろん、現行のゲーム体験に影響を与えずに、だ。

すべての要素は密接に繋がっているので、小さな変更はさざ波効果のように全体に波及していく。だが、そのように全体を見渡すことはなかなか難しい。

何かの意思決定をするときは手前の問題以上に大きな視座に立ち、しかるべき相手にその影響を伝えなければいけない。すべての関係者を巻き込み、個々の仕事が最終的なプロダクトに如何に大きな影響を与えうるかを示す必要がある。

パンくずリスト (Breadcrumbs)

個々の問題を解決する直接的な手段なんてのは、いつでも明確にそこにあるわけじゃない。対応すべき問題のパターンを見出すためのタイムラインを、自分で構築しなければいけないこともある。

　たとえば自分宛てに大量の問い合わせメールが来ているとしよう。


　手許でそれを振り分けて、過去に同じ問題がないか調べて。手許で解決できなければ報告者のところにいっていろいろ試して、問題解決の暁には、そこに至る経緯を情報として残すために、当初の問い合わせ内容と併せて返信をする。すぐに解決できるときもあるし、その問題がどれくらい致命的かが判明するまでは手を付けないこともある。


　そんなときは社内 wiki にでも解決までの経緯をまとめておけばいい。ページタイトルには問題の概要を。そして、報告者がまずそこを参照してくれるように、ページの存在を広く知らしめることに注力する。それは報告者に問題解決のノウハウを提供することになるし、うまくいけばそれを現場間で共有してもらえる。先を見越して教育を続けていこう。これは自分たちのために役立つだけでなく、例えばその問題が起きたシステムの開発者へのフィードバックとしても利用できる。

ここでは、自分たちが扱った問題のタイムラインを残しておくという習慣を取り上げた。これはまた別の解決すべき問題を見つけるのに役立つかもしれない。

曖昧さの力 (The power of ambiguity)

立場の異なる人同士のコミュニケーションというのは、本当に多くの衝突を引き起こすし、そういった場を如何にうまく収められるかというのは、テクニカルアーティストの存在意義のひとつだろう。だったら、職種間の衝突に巻き込まれて疲弊するよりは、そこから新たな視点が得られないかを考えてみたい。

　たとえばツール制作について、そのツールが自分たちにとってどう役立つかというのは、ユーザーの立場によって変わってくることも多い。


　以前私は、「パフォーマンス改善のためのフィードバックツール」というのをつくったことがある。ただ、現場のアーティストやプランナーが想定通りの使い方をしてくれた一方で、マネージャー陣は、各スタッフの評価やタスク管理のためにそのツールを使い始めた。「フィードバック」というものに対する考え方の違いによって、こういったことが起きたのだろう。

様々な捉え方の違いを受け入れることで、今後の自分の仕事をより良くしていくことができるはずだ。

人に教えることで自分の理解度を測る (If you can teach it, you own it)

目標に対する自身の到達度を測るというのは本当に難しい。まず成果を得るまでに多くの時間がかかるものだし、未解決の問題を扱っていればなおさらだ。

　たとえば私は、何か問題の調査やツール制作を始めるときには、スクショや参考文献も含めてその過程をドキュメント化して、周囲に共有するようにしている。


　そうやって作成していったメモ帳は自分の進捗や考え方を周囲に伝えるために役立つし、それに対するフィードバックは自分のやり方が間違っていないかの確認に使えるだけでなく、より多くの人を巻き込むことで自分がクリティカルパスになるリスクを減らしてくれる。


　その過程で当初は思いもよらなかったひらめきがあるかもしれないし、ドキュメント化するというマインドセットをチーム全体に広めて、自分たちの進捗を見える化することにつながる。


　なおドキュメント化の際には、写真や図などの視覚的表現を積極的に利用し、色使いに気をつけてぱっと見で要点が理解できるように注意することを強くおすすめしたい。