東京藝大のチームマネジメント - Game: Fragile project
▼前置き
初投稿になります、現東京藝大大学院メディア映像研究科所属の林です。
本記事ではこの春に挑戦したゲーム制作プロジェクトを振り返りつつ、自分がどのように失敗を重ね、その中でどこまでを達成できたのかをレポートとしてまとめていきます。
東京藝大というと、世間からはエキゾチックな動物園かのように思われているような感触がありますが、もう少し生々しいリアルな内状レポとして読んでもらえたらと思います。
Project website:
●目次
- 概要
- 結成
- 離散
- 再構築
- 再始動
- 難航
- 合宿
- 決断
- 発表
▼プロジェクト概要
2021年東京藝術大学大学院ゲームコース(以降藝大)-南カリフォルニア大学ゲーム学科(以降USC)コラボレーション、チーム制作カリキュラム
TUAの学生とUSCの学生で平均3人のチームを組み、1月~4月の期間で一つのゲームを制作し、5月のUSCのエキスポに出展する。
作業は基本的にチーム内部でオンラインで進め、2週に1度のクラスでTUA/USCの教授陣を交えて状況をプレゼンし、フィードバックをもらう。
▼チーム結成
2021/1/20 プロジェクトキックオフ。チーム組みは各々のスキルセットを鑑みて教授陣によって振り分けられ、僕は
・藝大アニメーション学科のM
・USCのC
との3人チームに配属された。
藝大のゲームコースはまだ正式に科として成立もしていないプロトタイプの状況で、基本的に本カリキュラムはUSCの胸を借りる形での実施だったため、クラスもチームでのコミュニケーションも英語ベースで行われた。
僕自身のクラス受講のモチベーションを簡単に話しておくと、それまで藝大で個人だったり小規模でのプロジェクト運営をやっていく中で開発リソースや広報能力などあらゆる面で行き詰まりを感じており、チームでプロジェクトを進行していくディレクションやマネジメントのノウハウを身につけたいというのが一番大きなモチベーションだった。
はじめ、進行は順調だった。USCはアメリカでもトップのゲーム教育がある学校で、Cの主導によるブレインストーミングやクラスでのプレゼンなど、システマチックにスムーズに行われた。
日本のチームにありがちな、なんだかふわふわした中とくに話題も進まずに時間ばかりが過ぎていく謎のMTGなどもなく、それぞれのMTGでは今日の議題、ゴール、所要時間をはっきり設定して執り行われたことで、物事は着実に前に進んでいった。と、思われた。
ブレストでの決定の概要としては
・やっぱり今はコロナとかウィルスは大きなトピックだね(林)
・ウィルスと幽霊って関連あると思うんだよね。目に見えないけど存在しているものについて。(林)
・犬派か猫派で言ったら犬がいいな(M)
・老人の孤独死問題はアメリカでも大きな問題だ(C)
etc.
→犬を触っていたら死んだお婆さんとウィルスを介して話せるゲーム
このように決まった。
ToolTops:
ブレストのツールには“Google Drawings”がオンラインホワイトボードとして使いやすかった。
▼チーム離散
一見それぞれの意見を取り入れた順調な滑り出しのように見えるが、すでにいくつかの問題があった。
・まずひとつ目の問題は、ゲームのブレストとしてこれはあまりにナラティブの要素に寄り過ぎていたことだ。ゲームにはパズルゲームやアクションゲーム、あるいはジャンルも定まらないものなど様々ある中で、上記のテーマではそういったゲームのシステムやストラクチャーへのディスカッションがほとんどなされないまま、爺さんと婆さんとの過去を描くこと、それと犬との関係を描くこと、ウィルスの作用を描くことなど、ストーリー部分の説明として必要な要素が既に膨大な量で決定しまっており、ストーリーテリングのゲームにならざるを得ない状況になっていた。
これはMTGを主導していたCの進め方によるものだった。Cはプロダクトとして成立するようなストーリーテリングのゲームを作りたかったようだ。しかし僕はもう少しシステム的に(ゲームのインタラクティブ性などについて)、あるいは批評的に(現在の時勢や自分の研究範囲について)ラディカルなものに挑戦したかった。Mはなんだかよくわからなかった。
・そしてそういった調子で、それぞれのやりたいことと議事録上の記録が微妙に食い違っていたのが二つ目の問題だ。そんなそれぞれのアイデアが合成された結果、メンバーのモチベーションがそれほど合致しない中で、3ヶ月で完成させることが既に殆ど不可能なテーマを掲げてしまうことになった。
いくつかの言い訳としては、英語でのディスカッションの中で僕やMはその場の議題への案を出すことで精一杯で進行面まで考えを巡らすことができなかったこと、ゲーム制作の経験値として規模感の想定が難しかったことがある。当然言語だけでなく、チームマネジメント的にメンバーで同じ方向を向くことへの意識が足りていなかったことも問題だった。
幸いだったのは、破綻がわりにすぐだったことだ。
2月2週目、PaperPrototypeの発表があった。PaperProtoというのはゲーム制作プロジェクトにおいて、ゲームエンジンでの開発に入る以前、例えば紙を用いて実際に動いている様子をシミュレーションする段階のことだ。
ゲームエンジンでの開発は非常に時間や手数がかかるので、この段階に力をかけて完成図をなるべく想像し、トライ＆エラーを繰り返すことがゲーム制作ではとても重要になる。
その制作に取り掛かる中、Cloudがクラスをリタイアする旨を告げた。詳細な状況説明は省くが、私見ではやはりやりたいことの方向性を共有できていなかったのが1番の問題だった。言語の壁以上に、やりたいことのすれ違いを補正できていない状況が、メンバーそれぞれに少しずつストレスをかけていた。システマチックなブレストは一見物事を前に進めていたように見えたが、実際は言語の問題とプロジェクトの規模感をもっと考慮しながら、丁寧にみんなが同じ方向を向くように時間をかけるべきであったのだ。
Cが抜けたことに対して学校側に対応を求めたが、欠員が補填されることはなかった。
他のチームに加入することは提示されたが、もうそれぞれのチームでゲームアイデアがある程度固まっており、チームワークも安定しているように見えた。その時点で加入してもチームマネジメントを経験するというよりは、自分の役割を見つけてこなす技術者としての経験になってしまう。また正直に言えば、さほど面白そうなアイデアを掲げているチームがなかったということもあった。
しかしそこでクラスを諦めるには、USCの教授にコメントしてもらうというのはとても貴重な機会だったし、それまでにかけた時間も勿体なかった。
リーダーのポジションを引き継ぎ、PaperPrototypeの映像を作り上げたところで、しかし僕のそんな思いとは裏腹にMの気持ちはどんどんとプロジェクトから離れていった。
「鼻の高いイケメンとやりたい」そう言い残して別のチームへと去っていった。
そうして僕は、「犬を触っていたら死んだお婆さんとウィルスを介して話せるゲーム」という訳のわからないヘビーなアイデアだけが残された状態で、1人になった。
ToolTips:
最近知ったのだが、議事録をとっていったりするのには“Scrapbox”がwebツールとして使いやすい。Googleドキュメントは増えていく議事録リストのURLの把握が次第に困難になった。アクセス権がどうとか、フォルダ構造がどうとか、そんなことに時間をかけている場合ではない。その点Scrapboxはもう少し機能が絞られている代わりに動きが軽快で、ビジュアルに情報を広げられる。
▼再構築
そんな状況になると意地を張ってやり遂げてみたくなるもので、自分でチームメンバーを再構築することにした。
藝大や以前少し繋がりのあった東大のVRサークルの繋がりなどに声をかけて、なんとか現行のメンバーに興味を持ってもらうことができた。
メンバーを募集する際は、藝大とUSCとのカリキュラムであり、学校の展示やエキスポに出展すること、コンペに出すことなどを目標に掲げ、5月までのプロジェクトであること、お金は出ないこと、週1でオンラインMTGしてそれぞれが各自で作業を進めていくことを提示した。
藝大生の特に油画科は無償労働への警戒はとても強い。
アーティストというのは個人の自営業なので、チームで何かを作り上げる意識があまりなく、自分が稼働することには直で自分に見返りがあることを期待している。ふわふわした学生団体のノリで付き合うと、かなりよくない関係を迎えてしまうので、注意が必要である。
別に藝大生に限ったことではないと思うが、モチベーションとなる目標と、お金や稼働時間についてはきっちりと最初に明確にし、共有しておく必要がある。その点は今回のプロジェクトでは最終的に問題は起きなかったのでよかった。
メンバー構成
林裕人(me)
- ディレクター、エンジニア
松永海(海くん/早稲田物理学/UTvirtual)
- シナリオ
Kyoi(藝大アニメーション)
- アートワーク
田中小太郎(こたろう/藝大音楽環境創造科)
- サウンド
阿部浩大(Kodai/サウンドメイカー)
- サウンド2
+
Fidelia Lam(USC)
- メンター。上記メンバーではもはやUSC要素は無くなってしまったので、学校側に要請してメンターについてもらうことにした。
改めて書き出してみると、ディレクターとエンジニアを兼任と、役割が集中してしまっているのがわかる。エンジニアを再募集しない決定に至った考えとしては、これ以上メンバーが増えるとMTGのやりとりに不都合が生じやすいし、ある程度スキルのあるエンジニアを探すことは藝大の自分のコネクションからは困難で、自分がやってしまった方が早いと考えた。それに関してはそれほど間違った判断ではなかったと思う。その時点で事実上これは自分のプロジェクトになっていたし、ある程度負担を背負うのは完遂させるためには致し方なかった。
しかし大きな反省もあった。上記の表には重要な役職である「マネージャー」が隠されてしまっていた。これは非常に大きな問題で、結局それは当然僕の役割となり、メンバーの仕事進行管理、全てが英語で進むクラスとのやりとりの窓口、書類整理、発表用のwebの整備など、この段階ではきちんと想定していなかったマネジメントの仕事全てが、自分1人に集中してしまった。
僕にとっては5名のメンバーが集まってくれただけで嬉しくなり達成感を感じてしまっていて、無根拠に楽天的になってしまっていたのだと思う。厳しいスケジュールになることは薄々勘づいていたが、睡眠時間を削ればどうとでもなるだろうと、その時はそう考えていた。油画科出身で藝大での活動は個人制作が主だったため、睡眠時間を削ればその分遅れや不足は巻き返せる部分が確かにあった。しかしチーム制作では自分の睡眠時間を削るだけではどうにもならない。的確なタイミングで的確に周りと合わせて物事を進めていかなければならない。しかしそういったチーム制作での進行について、その時の僕は今ひとつわかっていなかったのだ。
▼再始動
テーマである「犬を触っていたら死んだお婆さんとウィルスを介して話せるゲーム」
これは短いテキストではあるが、すでにやらなければいけない多くのことを規定していて、残り3ヶ月のプロジェクトであることを加味するとシナリオとシステムの骨格は自然と見えた。それに沿って新メンバーそれぞれに仕事を割り振ることもすんなりいった。
・まずシナリオにはおじいさんとおばあさんの過去のストーリーや設定構築、エンディングの方向性の決定
・アートワークには部屋のシーンと犬のシーンのイメージボード作成
・サウンドも同様に2つのシーンのデモテープの作成
制作はオンラインで、都度自分が各メンバーとZOOMでMTGを重ね、完成イメージに近い作品や、リファレンスとなる文献などを共有しながら進めていった。
僕の頭の中にぼんやりとあったり、あるいはまだぼんやりとすら無いイメージを共有するのはそれなりに時間のかかるものだったが、それはこれ以上効率化したり横着できるようなことではなく、しっかりと時間をかけて一対一で話していき、逐次アウトプットとコメントを繰り返すことでようやく方向性を共有できるものだったと思う。
その中でもサウンドは人数が2人だったこともあり、順調に進んだ。2人での仕事の分担はシステム的にはそれほど効率的だったわけではないと思う。そもそもオンラインでの作業において同じトラックを複数人で作り上げていくのはとても難しそうだった。ただ、2人は初対面だったけれどそれなりに気はあったみたいで、雑談や相談しながら制作することができたのは、モチベーションにいい影響があったと思われる。
アートワークは担当のKyoiさんが中国出身だったこともあって、日本家屋の空気感や特徴を共有するのに最初の困難があった。小津安二郎の映画や家屋の間取り陰影礼賛などのテキストを僕自身もリサーチし、共有してスケッチしてもらうことを繰り返して行った。
この段階でのポイントは、あまり作り込まない軽い段階のスケッチを繰り返し作ってもらうことだ。最終的なものにはならないことをあらかじめ伝え、あまり時間をかけずにラフなものを出してもらう。ディレクターの僕自身の中にも完成品の確固たるイメージはないわけで、出てきたものを見て想像力が一歩進む。なるべく無駄な作業にならないようイメージの共有をしつつも、各担当のクリエイティビティを発揮してもらえる余白は残し、予期せず出てきたものを柔軟に取り入れていくことが重要だ。
ToolTipsまとめ:
チーム進行のツールは
・Slack: 連絡
・GoogleDrive: データ共有
を用いた。
他に使うべきだったもの
・Scrapbox: 上述の通り
・SpreadSheet: うまく使えなかったが、マネージャーが時間をかけてスケジュールやガントチャートを綺麗に作り、全員が参照しやすいように公開しておくと、プロジェクトの進行には役立っただろう。ただこれは、徹底して行われないと意味がない。きちんと進行管理できるマネージャーがいなければ、現状の日程と想定された日程の差は開いていくばかりで、次第に現実味をなくした呪いのようなセルたちはメンバーにストレスをかけるばかりで何の役にも立たないものになってしまう。
▼難航
サウンドとアートワークは進行が順調で、東京藝大の各専門が担当しているだけあって僕だけでは到底作ることができないものをスケッチ段階で出してくれた。
ボトムネックになってしまったのはシナリオでだった。担当の海くんはシナリオをやるのは初めてだがとてもやる気のある様子で、しかしそれがすなわち順調な進行に直結するかどうかはまた別のようだった。
また僕が担うべきエンジニアリングパートも、芳しい進行ではなかった。
今回のプロジェクトは複数シーンを跨ぐもので、それなりに規模の大きいプログラム構築が要求された。
Opening->News->Room0->Dog0->Night0->…->Room3->Dog3->Ending
完成には10個以上のシーンをまとめあげなければいけないわけである。またRoomとDogはシステムを共通化することで馬鹿正直に10個以上のシーンをそれぞれ作るよりは効率的だと考えたが、実際は流用できるよう、かつ各シーンでの独自オプションの拡張実装に開かれたシステムを構築するのは骨の折れる仕事だった。
本当はきちんとPS工程を踏んで、フローチャートや状態遷移図を書いて整理して、っていうのをやらなければいけなかったけれど、そんなのは初めてだったし、はっきり言って僕はそこまでツヨツヨエンジニアではなかった。抽象クラスやインターフェースを改めて勉強し直し、シーンごとにマネージャーを配置して、シーンのスタート処理タイミングを整理して…、そうやって地道にひとつずつ実装していった。そう言った作業は楽しいものでもあったけれど、また悪い癖で無駄に凝った機能を実装してみたりし始めてしまい、そうやってエンジニアとしての自分の仕事に遅れが出てくると、マネージャーとしての自分の仕事にも影響し、他の人の仕事をうまく引っ張っていくことができなくなった。自分が遅れてるのに他の人の仕事状況を考えたり、尻を叩いたりなどなかなかできないものだ。
プロジェクトがうまくいこうがいかなかろうが時は過ぎていき、3/11のクラスでバーティカルスライスの発表があった。
バーティカルスライスはゲーム制作の1ステップで、一部分でいいから、完成品のクオリティで美術・サウンド・プログラムを見えるようにする、というものだ。
語源はケーキだという。いわく、「ショートケーキをカットすると、下から上まで断面が見えるだろう。そういうことだ」と言われた。
ショートケーキの断面は全部完成しないと見えないだろうなどとも思ったりするけれど、要は一部分だけでも完成パートを作ることで、全体のクオリティレベルを設定し、全体の完成までの仕事量を想定しやすくするという話だ。
しかし我々のチームはまだそんな段階にはなく、なんとかシーン遷移システムができてきて、ようやくRoomシーンに取り掛かるところ、というレベルだった。
問題はシナリオとエンジニアリングの遅れにあるのが明白だった。
シナリオはいまだにエンディングをどう迎えるか、おじいさんとおばあさんの関係性はどのようなものだったか、お話の見所はどのような部分か、といった初期の注文の肝要な部分にまるで形を与えることができていなく、そうなるとサウンドやアートワークにどんなものを、どんなトーンで、という注文も出せなくなった。エンジニアリングの遅れは、上述のようにマネジメントの遅れとも直結してしまっていたから、そんなシナリオや他メンバーをフォローしていくことも難しくなった。
マネジメントを意識して立てていなかったことの弊害が如実に現れて、まさに行き詰まっている中で、1~2週に1回やっていた全体MTGでの進捗発表もどんよりした雰囲気が立ち込めた。
遅れない、というのは無理であるから、一つのセクションが遅れることの全体への影響をなるべく抑えるようなエンジン（マネジメント）を意識して設置する必要があった。結論から言えばそれが今回のプロジェクトではうまくいかず、最終的に完成しないままプロトタイプの発表で幕を閉じることになった。
状況はまずかった。遅れているセクションは遅れていることが辛かったし、サウンドのような手の空いているセクションは手持ち無沙汰でやや無用な作業をしていたりして、全体MTGもあまり盛り上がらなかった。状況を変える打開策が必要だった。合宿だ。
▼合宿
4月上旬、2回の合宿を行った。みんなを自宅へ招待し、話し、カレーを振る舞い、みんなで楽器を演奏し、リファレンスになる映画を観賞し、作業を進めた。
これは非常に良かった。
やはり、何かものを作るにあたって、同じ方向を向くというのはとても重要なことだ。それぞれがどんなものを面白がっていて、どんなところに価値を感じていて、じゃあ面白そうだから僕もここを作ってみよう、そういうことはオンラインではどうしたって難しい。
オンラインでのやり取りは、個人作業を進めてタイミングで進捗を報告する、というようなタスク処理的作業には向いているが、新しいアイデアについて考えたり、共同でこの時間に進めようというような作業とは相性が悪い。何より、同じ部屋にチームメンバーがいる、そういう血の通った人間の存在感みたいなものを削ぎ落としてしまう。それに、どんなにプロジェクトがうまく行ってなくても美味い物をみんなで食べればそれなりに楽しいものだった。
合宿により即ちゲームが完成するなどということはなかったが、モチベーションとして状況は大分好転した。
▼決断
しかし、やはりシナリオは進まなかった。シナリオに注文した最初のタスクが「エンディングの方向性はどうするか」だったのだけれど、結局2ヶ月たってもそれは決まらなかったのだ。プロジェクト期間は5月までだったから、これはもうアウトだった。
ディレクターである僕がシナリオには大幅にテコ入れと決定を入れた。
そして苦しいところではあったが、完成とUSCのゲームEXPOへの出展は諦めてWEBベースのプロトタイプ発表を目標に切り替えた。
WEBでの発表の決断は、当初のEXPOへの出典やコンペ出品の約束を反故にすることを意味していた。状況の厳しさはメンバー全員認識していたから、特別僕にそのことへの苦情があったわけではなかったが、少なくない時間をかけてきた分、メンバーのため、また自分自身のために、発表形態はできるだけ価値を最大化したかった。
そこで今プロジェクトのゴールとして、メンバーそれぞれが自身のキャリアとしてポートフォリオに載せやすいよう、WEBでの発表をできるだけ綺麗に整えることにした。
WebGLで書き出してゲームを埋め込み、またトレーラービデオも用意して、なるだけ多くの人がコンテンツへアクセスできることを目指した。
自分自身何度かゲームを作ったことがあるが、実際にプレイしてもらうまでの障壁はかなり大きい。
個人の小規模開発ではストアリリースまで整えるのは時間がかかってしまうし、アプリデータだけでは起動にセキュリティ要件で弾かれたりするなど、ユーザーフレンドリーとは言えない部分がある。
そもそも数百MB~数GBのファイルをダウンロードしてもらうこと自体ハードルが高い。
それを潜り抜けてプレイしてもらうのは実際のところかなり難しいのだ。
なので概要がわかるビデオが必須で、可能であるのなら一部のシーンだけでもWebGLでプロジェクトページからプレイできるとよかった。
しかしWebGLに関しては達成することができなかった。システムとしてはエラーなくビルドして書き出すことができたが、全てのアセットをビルドデータに格納していたためにゲーム容量が大きくなってしまい、ブラウザでのプレイは現実的でなかった。WebGLでのプレイを想定するのであれば、画像などのデータはサーバーに上げておき、シーンのロード時にテクスチャーデータとしてパースしていくシステムを構築する必要がありそうだ。またGarbageCollectionのタイミングも任意にできないので、それに沿ったシステムの最適化も必要になる。なかなか、ゲームを発表するのは難しい…。
▼発表
エンディングを含むシナリオの大枠が決まるとアートワークのキャラクターデザインも進み、上がってきたイメージやサウンドの素材をUnityに組み込んでプレイすると、それは思っていた以上に、感動的な美しさがあった。
月並みな言葉だが、1人では作り得ないものが形になるというのはやはり素晴らしいものであり、その点はゲーム制作の大きな喜びの一つだろう。
幸いWebは簡単なものであれば僕が作れたので、5月末、なんとか発表までこぎつけた。
もう一度サイトのURLを貼っておく。PCからであればダウンロードしてプロトタイプをプレイできるようにしてあるし、それも辛抱ならないという大多数の人のためにビデオももちろん用意してある。アートワークのKyoiさんとサウンドのこたろうがビデオの制作も手伝ってくれた。東京藝大学生のアートワークやサウンドはやはり一件の価値があると思う。それだけでも見て行ってもらえると幸いだ。
////////////////////
▼後書き
なんだかんだと大変だったことや文句ばかり書いてしまいましたが、自分自身の振り返りとしてもとても有意義な時間になりましたし、当初の僕の目的は「チームマネジメントを経験すること」だったのである意味それは高級な失敗の経験として達成されたとも言えます。
途中なかなか思うように進まない状況に陰鬱なムードがチームに流れたりしましたが、その中で合宿を成功させたことはチームワークを一つ上の段階に成長させてくれ、振り返ってみるといいプロジェクトだったしまたチームで制作したい（次こそは完成まで含めて！）と思えるものになりました。
ところでですが、ついこの間Netflixで「映像研には手をだすな」のアニメを見ました。あの作品で金森さんのマネジメントの部分なんか、このプロジェクトを殆ど終えた段階で見ると非常に身につまされるものだったと思います。フィクションですから幾分調子良く進みすぎな部分もありますが、モノづくりのチームマネジメントとしてとても勉強になりました。
僕にとってプロジェクトの終わりは、次のプロジェクトの始まりを意味しています。次はARか、QRコードか、古民家あたりを扱って面白くしていこうと考えています。大変な楽しい夏になりそうです！
この記事が気に入ったらサポートをしてみませんか？