『閃乱カグラ』シリーズや『うたわれるもの斬2』、『キャプテン翼 RISE OF NEW CHAMPIONS』など、著名ゲームタイトルを数多く手がける「タムソフト」は、今年で設立30周年を迎えた老舗ゲームデベロッパーだ。

一貫してコンシューマーゲーム開発を続ける同社だが、手がけるゲームハードの主体が3DS、VITAといった携帯機から据置きの高性能機に移行し、プロジェクトが大型化するに伴って、チーム内コミュニケーションや各人のタスク状態の把握とその管理など、プロジェクトマネジメントにおいて課題を感じるようになっていったという。

そこでタムソフトが白羽の矢を立て、実際のプロジェクトに導入し、実績を残してきたのが、今回紹介するタスク管理ツール「Asana」だ。プロジェクト進行において、同様の課題を抱えるゲームデベロッパーやCGプロダクションは多いことだろう。タスク管理ツールの導入経緯から実際の活用の様子までを綴るこの詳細インタビューは、そうした現場においてきっと役立つ情報となるはずだ。

プロジェクトの大規模化による コミュニケーションロスを無くしたい

CGW：プロジェクト管理に課題を感じるようになった、とのことですが、具体的にはどのようなことでしょうか？

神保ナツミ氏（以下、神保）：やはり当社が手がけるゲームにおいても、ここ数年くらいで大きく変わってきていまして。ひと昔前の携帯機で出すゲームであれば、全体で10人～程度、期間1年といったものも多かったのですが、今ではプロジェクトの規模が拡大して関わる人数が増え、開発スパンも2～3年といった長期間に及ぶようになってきました。そうやって腰を据えてクオリティの高いものを開発をしていかなければ、という流れにおいて、ますます開発過程でのコミュニケーションを円滑にする必要が出てきたんですね。

CGW：プロジェクトの規模が大きくなることによって、コミュニケーションに課題が出てきたということですね。

神保：10人、20人というチームでの意志疎通であれば、たとえば毎週全員参加で定例会を行う、といったことで済んでいたんです。いち担当者の個人の意見として、たとえばデザイナーやプログラマーが「この仕様や処理は実装コストが高いから～」などと意見を出して、そこでプランナーとすり合わせてコスト相殺できるアイデアを出したり、ということができていた。それが50人～60人規模のプロジェクトになると……。

CGW：みんなが一同には集まれないわけですね。

神保：はい。昨今ではコロナ禍もありましたし、会議室に集まっても6～7人、とかって話になるんですね。すると、各セクションのリーダーだったり、代表者しか揃わない。各セクションにおいて個人が抱えている疑問や問題点があっても、直接持ち寄れるわけじゃなく預けることしかできなくなります。そうなると、必ずしも課題に感じていたことが明確にされて戻ってくるとも限らない。それが仕様で正しいのかどうかとか、ぼやけたまま戻ってきた内容に対してもう一度突っ込んでいいのか？とか、さらにはあいまいな流れで解釈されて違う仕様になっていくとか、みんなが色々と動きづらくなってしまっていたんです。

CGW：そういった異なる解釈と失敗談が積み重なって、あれは違ったこれは間違ってる、みたいに責められる雰囲気になると、個々のレベルでの意見は言いづらくなりますよね。

神保：個人から仕様を出したり、新しいアイデアを出しづらい雰囲気になってしまう。上からの鶴の一声を求めてしまうようになる。それはコミュニケーションとして不健全な状態なんですね。

古川：プログラムの立場からしてもこの状況はなんとかしたい、と思っていて、ずっといいタスク管理ツールがないか探していました。以前の小規模体制では、やはり自分たちもヒューマンパワーで直接話をして何とかしてしまっていたので、それでは現状もう対応できないぞ、と。一応プログラム課内では、それまでRedmineやJIRAを使ったりとタスク管理ツールは導入していたのですが、これらはUIも独特だし学習コストが高い。プロジェクト内でセクションを横断的に使えるツールでないと、大元の課題はやはり解決しないんですね。

CGW：そこで「Asana」が出てくるわけですね。

神保：きっかけとしては、Youtubeで業務効率化の話をよくやっているマコなり社長という方がいらして、その方が紹介しているAsanaの動画がわかりやすかったんですね。それで試してみよう、と。最初はプランナーの数人だけで、ラインの詰めのタイミングとかでテストしたんですが、部下とのコミュニケーションが明瞭化されて「あれどうなったんだっけ？」みたいなことが減ったんですよ。無料期間で使い倒して、これはいいかもしれないぞ、と。

導入のしやすさは説明がいらないレベル！　気軽に作れるタスクが抜群の使い勝手

古川：Asanaはインターフェースがすごくとっつきやすいんですよ。他の人に広めるにしても、ほとんど使い方の説明がいらない。これがすごく大事なことなんですね。ライン上のシビアなタスクを抱えている状態で、「管理ツールを導入するからマニュアルしっかり読んで使いこなせ」って言うのは、人にもよるけどかなりきついと思います。学習コストが高すぎる。Asanaはそれがすごく容易に使い出せるんです。さまざまなタスク管理ツールを同時に試したりしましたが、プログラマーだけで使うのではなく、プロジェクト全体で運用するという観点で、Asanaが最終的に残っていったというかたちですね。

CGW：コミュニケーションをとる、という観点では、Slackなどのチャットツールの活用では問題解決にはならなかったのでしょうか？

古川：プログラム課としては、チケット制で管理したいんですね。このタスクは誰が何をするのか、チケットとして発行して配る。これだとステータスとして明確化されるので。Slackでのコミュニケーションだけだと、会話として流れていくだけになって履歴を辿らないとわからないし、手元に何も残らない。タスクが現状どこまで進んでいるのか、リスト化して管理したい。かつ皆がかんたんに扱える、という条件のツールが欲しいぞと（笑）

神保：何度も言いますけど、Asanaは導入するに当たって説明がいらないくらい容易に使い出せた、というのが大きいんですよ。画面見てください、こうですよ、だけで数秒確認して終わり。これでチーム内に広められるというのが大きかった。

CGW：プロジェクトやタスク管理のツールは、社内認知や効果の説明など、導入するまでが大変だと思います。そのあたりもスムーズだったと？

神保：まずテストした人から「使いやすい」というフィードバックと、ラインがこれまでよりスムーズに回ったぞ、という実績がある程度認知されれば、社内的にも推し進めやすい。そういう意味でも、タスク管理ツールの学習コストの低さは、各個人に対してだけでなく、企業としての導入のしやすさでもありますね。

CGW：もう少し具体的には、ゲーム開発というプロジェクト内においてAsanaはどのように活用されていたのでしょうか？

神保：そうですね。最初は思い思いに使い始めた、という感じでしょうか。話したいときに、話したい話題について、話せる場所として使う、というか。仕様がまだ決まっていない、この部分どうしよう？という内容についてとりあえず仮の名前でタスク化しておいて、意見を出し合う。詰まってきたら、本タスクとしてつかって誰が何をやるか、チケット発行して進めていく、みたいな。

CGW：すごくザックリした状態から使い始める、という感じなんですね！

神保：自分たちのラインではそういう使い方をメインにしていましたね。ただ、後で紹介する高須のラインでは、カッチリ組んだスケジュール管理とクライアント向け報告を兼ねた使い方もしていましたし、本当に目的に合わせて自由度の高い使い方ができるツールだと思います。ある程度プロジェクトがカッチリ決まっているなら、次々タスク化していってチケットを割り振ってその進行管理ツールとして使えばいいし、仕様もスケジュールも決まっていないような状態でも、話し合いの場として使える。ゲームづくりの最初って何も決まっていなくてゴチャゴチャしてるんですよ。その段階から面倒をみてくれるのが、Asanaのいいところですね。

CGW：仕様が固まりきっていないところから、かたちになるまでの流れを組み立てやすくなる？

神保：その最初の仕様のわからないフワッとした状態をどうすればいいのか、これまでわからなかったんですが、Asanaによってその状態からでも管理できるようになったんですね。「こんな問題がある」ということをタスクとして置いておいて、それに対して皆で意見を出し合って、「じゃあこれはこういうタスクということだね」というレベルにまで徐々に昇華していける。登録したタスクは後で修正がいくらでも効くので意見が出しやすい。ゲームづくりって、タスク振られて淡々とやるだけじゃなくて、こういうみんなで参加していくことが大事なんです。課題について意見交換しながらタスクを育てることで、昔あったような“みんなでゲームをつくっていく感”が生まれる。プロジェクトが大きすぎて個々の作業に細分化して、「いま自分は何を作っているの？？？」みたいな状態や疑問が生まれにくくなります。これはすごく大きいですよ。

古川：そしてその結果、どういう作業が誰に割り振られているのか、Asanaを見ればすぐわかる、と。みんなで全体状況を共有できる。自分の作業だけじゃなくて全体のことがわかったうえで、その全体の中でこのパートが自分の担当なんだ、という意識が持てる。だから、みんなが同じツールを使って管理できるってことの意義は大きいんですね。

ざっくりした課題の解決から カッチリ決まったプロジェクト管理まで対応

CGW：ここまででも、十分にタムソフト内におけるAsanaについて使いこなし情報が出ていると思います。ですが、さらに実践的な使い方がなされているプロジェクトがある。とも聞いています。

高須健太氏（以下、高須）：実践的というか、我々のラインでは、より内容が決まってきたプロジェクトの情報共有ををうまく回していく、という観点でAsanaを使っていったパターンになりますね。大きなところでいうと、資料の統一でしょうか。これまではマイルストーン表、成果物表、月次スケジュール、クライアントへの報告用プレゼン資料など、それぞれの管理データが複数フォーマット、複数ファイルで存在するような状態でした。それらをAsanaにまとめて統一して管理することで、余計な工数を大幅に減らせたと思います。

CGW：余計な作業が減った、というような感じでしょうか？

高須：そうですね。たとえばモデルやモーションといった成果物が仕上がってきたとして、それを報告用資料に当てはめて表を作る、またはその作業を誰かに依頼する、といったような、“あまりに間接的すぎて無駄に思えるタスクとコミュニケーション”がなくなりました。社内用の詳細なタスク画面と、成果物を拾い上げるクライアント報告用の画面を設定で分けておけば、どちらもAsanaで対応することができる。“報告のためだけの資料づくり”みたいなタスクがほとんどなくなったのは、時間をよりゲームづくりの本質の部分に使うことができるので非常に助かります。

神保：当たり前ですが、ゲームづくりに時間を割くことが最も大事です。……なのですが、クライアント報告にかけるコストは馬鹿にならないんです。高須のところはそれが進んでいて、細かな設定は必要だけど、クライアント向けも社内向けも同じ仕組みのAsanaで管理できている、ということですね。

CGW：体感値として、どれくらい効率化できたイメージでしょうか？

高須：そうですね……。それまで報告に向けて、5つ、6つの資料を都度作っていたことを考えると、それがAsanaの画面にまとまったというだけでも、1/5くらいには圧縮されているのではないでしょうか。実際、重たいときは報告資料の作成に一週間程度かけていた時期があります。それが一日で済むようになった、というくらいの感覚ですね。

CGW：それは大きい！　その分の時間をクオリティ追求の方に使えると考えると、ゲームの品質も上がっていいことづくめに思えます。

高須：具体的には、クライアント向けにはアルファ版1、アルファ版2、みたいなマイルストーンごとの進捗をまとめる社外共有用のプロジェクトを用意する。そこでは、成果物というタスクがあって、その進捗が確認できればOK。

それらは社内用の別プロジェクトのタスクと依存関係をつけて進捗管理を行なっているが、そこは細かすぎるので報告資料としては見せる必要なし、というイメージですね。基本的には全部結び付けて段階分けをしていく中で、どこを切り取って見るか、という話。

タイムラインが微妙に使いづらい部分もあったり、最初は設定が大変だったりもしましたが、それを乗り越えて統一したことで、クライアントもプロジェクトマネージャーも、ディレクターも担当者も、全員が基本的に同じ管理ツールを見て進められるようにできたので、飛躍的に効率は上がったと思います。

CGW：素晴らしいですね。そして一方、そのラインにいたデザイナーさん目線では、Asanaをどう感じていたのでしょうか？

手嶋健二氏（以下、手嶋）：我々のほうでも、やはりプロジェクトの大規模化に伴って、こちらが必要な情報の欠如や、仕様上の問題点のエスカレーション等におけるやりにくさは感じていたので、Asanaの導入はすごく良かったですね。それを見れば全員がすべての情報にアクセスできる状態になるので、担当するアセットに必要な要素が把握しやすくなりました。

手嶋：まず、もう以前のように口頭のコミュニケーションでなんとかできる規模感ではないですし、かといってSlackのようなチャットツールでは、必要な情報をすべて書き切ってやりとりするのは難しい。そういうところに、新社会人の子でもぱっと見て使い出せるくらいの学習コストの低い、感覚的にわかるAsanaのような管理ツールが入れば、ちゃんと定着しますね。もちろん、ちょこちょこあれが必要これが足りないという要望はありますが、それでも「もう使い続けるのはしんどい！」みたいなネガティブな意見がないのはすごいと思います。

CGW：また、デザイナーサイドではアセット管理ツールとしてShotGridも使っていると聞いています。Asanaとはどういった使い分けになるのでしょうか？

手嶋：基本は併用になりますね。ShotGridは、まず画がありきでその評価と管理のためのツールです。デザイナーには仕様が決まった画を完成させる、というゴールがあって、そうした仕様が固まったものについての出来の管理は、やはりShotGridを使います。当社においては主にデザインデータの管理ですね。ShotGridでそのデザインデータが仕様どおり完成したら、その後の工程で、Asanaを使って管理する流れになります。

神保：実は、全員がShotGridを導入していた、という時代もあったんですよ。ただ、当時のプランナーやプログラマーは、もっと文字ベースでやり取りできるツールを求めていました。ShotGridは最終的な仕様が決まった段階であれば非常に有効なツールだと思います。

ですが、まだ開発の立ち上げ段階だったこともあり、各セクションに振っていくタスクも一旦相談していきたいという粒度のものが多く、情報の集約・共有を行うツールとしては目的が少しズレていた気がします。ここはディレクターの力量不足でもありますが、仕様の出し戻しが多かった当時では、ShotGridを扱いきれていなかったというところが正直なところですね……。

CGW：そういう順序を経て、Asanaにたどり着いているわけですね。

手嶋：デザイナー目線で言っても、ゲーム全体の規模が大きくなっているだけじゃなくて、ビジュアルの高品質化に伴って、たとえばキャラクター1つにしても構成要素が増えているわけです。そうすると、たとえばいち担当者に1キャラクターを任せてしばらく見ていないうちに、その一部に作業漏れや認識違いが出てきたり、といったことも起こります。その点Asanaを管理に使っていると、作業者にとっても疑問点やこれってどうなってる？みたいなお題で、不明点は気軽にタスクを立てておけるんですね。そこで疑問は解決していけるし、未解決だったらその状態がAsana上に残っている、と管理側でも視認できる。これならば、まずい問題の放置や忘れがなくなりますよね。

ゲームづくりの純度を上げる！ プロット段階から最終盤までカバーする タスク管理ソリューション

今回のAsana導入インタビューを通じて感じたのが、「忙しさの純度が上がった」という、クリエイターにとってのうれしい本音である。ゲームづくり本筋から外れた細かな雑務に追われる時間を圧縮することで、本来のクリエイティブに注力できる。それこそ、タスク管理ツールに求められる一番の要素だと言えるだろう。

ゲーム開発という多岐に渡るタスクを大規模に管理する必要があるプロジェクトにおいて、自由度が高く、学習コストがかからず導入も容易なAsanaは、極めて適したソリューションである。「ゲーム業界は忙しすぎて考える余裕がなく、まだまだ業務効率化という点において投資できていない」と語る神保氏。同じような悩みを抱えるところではひとまずお試しでも導入をしてみてはどうか、と薦める。

「Asanaのおかげで、今まで見えていなかったタスクも見えてきた。ゲームづくりをますます追及できるだろう。まだまだ過渡期なので、これからさらに効率化は進められるはずだ」（神保氏）。