みなさんこんにちは。色々と落ち着かないまま、いつの間にか秋になってしまいました。そして、つい先日ソードアートオンライン（SAO）のアニメシリーズの最新作『ソードアート・オンライン アリシゼーション War of Underworld』が完結しました。本シリーズの一期最初の放映で「これは凄いの来たぞー！！」と興奮してから8年、本作が始まって2年、遂にここまで来たかという感じです。本作はリアルタイムで見ている人には本当に過酷で、2019年12月に最高潮の盛り上がりを見せて最終話終了というそれはもうサディスティックな終わり方をして、そこから4か月お預けかと思いきや新型コロナウイルス（COVID-19）の感染拡大の影響でさらに半年近く延期という、万一このまま死んでも死にきれないという悶絶の期間を過ごすことになったのです。本当、死ななくて良かったですよ............そんな永い旅も終わりかーと思ったら、次のプロジェクト『ソードアート・オンライン プログレッシブ』が発表されて、公開（？）が2022年とか。二年後ですか............また悶々と過ごすことになりそうです............いや、二年は長くないですかね！？！？
個人的な感想は置いておいて、『ソードアート・オンライン アリシゼーション War of Underworld』の群衆表現はすごくて、週一放映のアニメシリーズでこれだけの内容をやるのはちょっとどうなっているのかわからないです。過去の記事を探すとSAOを制作しているA-1 Picturesは以前からGolaemを使用しており、その蓄積の結果のようです（詳細はこちらの記事参照）。群衆シミュレーションは比較的高コストで、映画のようにそこそこコストと期間をかけられる作品の「ここぞ！」という場所で使うものというイメージがあったのですが、まさか毎週毎週群衆シミュレーションがメインになるような作品が放映されることになるとは思ってもみなかったです。この点だけでも、群衆シミュレーション好きな人は一見の価値ありです。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
タスクの一生について考える
本連載の第24回ではアセットの階層構造や命名規則について考え、第25回ではタスクの構成について考えました。これらは、実際のフォルダ構成に直接紐づけることからわかるように、どのようにして入れ物の構造を決め、中身を詰めていくかというお話でした。今回はちょっと内容が変わって、詰めた中身をどのように管理するかというお話になります。管理の方法になるので、ディスク上の何かと直接対応するものではないです。このちがいは頭の片隅に置いておくと良いかと思います。
第25回では、タスクを（作業フェーズ名）:（タスク名）という形で二階層の構造になるように定義しました。今回は、このタスクの一生について考えていきます。
タスク管理はExcelやGoogleスプレッドシート、Shotgun、Redmineなど、様々なツールを使って行われています。今回は特定のツールの使い方ではなく、"タスク" というものの扱いについて考えます。また、プロジェクト管理やタスク管理を行う上で、スケジュールや予算の見積もり、上から押しつけられた無茶な予算をやりくりする方法、進捗が出ない作業者の尻を叩く方法といったプロジェクトの運営に関することは言及しません。それはそちらの専門の方の解説をお待ちしています。ですが、タスクをきちんと管理することでプロジェクト全体を把握することができるようになります。プロジェクトの状況を把握することはプロジェクト管理の第一歩なので、タスク管理はとても大切なことです。
チケットの一生
タスクは、管理システムによってはissueまたはチケットと呼ばれることもあります。どちらかというと、そちらの呼び方の方が一般的かと思われます。本記事では、プロジェクト上で管理する作業をタスク、プロジェクト管理システム上で作成される、タスクに対応するアイテムをチケットと呼ぶことにします。
チケットは、作成されてから終了するまで様々な人の手を渡り、状態を変えながら一生を過ごしていきます。ここでは、チケットの状態をステータス、チケットが一生の間にどのようにステータスを遷移していくかを示したものをワークフローと呼ぶことにします。
チケットのステータスに何を盛り込むかは喧々諤々の議論になりがちです。例えば、Shotgunでは以下のようなステータスが用意されています。
また、Redmineでは新規、進行中、解決、フィードバック、終了、却下という5つのステータスが用意されています。この2つを見比べるだけでも、ステータスの中身に大きなちがいがあることがわかります。一概に何が正解というものはないですが、最初は極力シンプルにしておいて、慣れたら徐々に細かい管理をしていくようにするのが良いでしょう。
ステータスが決まったら、ワークフローを決めていきます。基本となるのは下図のような形です。
最初にチケットが作成されると、新規というステータスで作業を行うべき相手としてBさんが割り当てられています。Bさんはこのチケットに着手する際にはチケットのステータスを進行中に変えてから作業を始めます。作業が一段落してチェックに回す段階でステータスをチェックに変えて、チケットの担当者をチェック担当者のCさんに変えます。CさんがチェックしてOKならステータスを終了にし、もし何か変更点があればステータスをチェックバックに変えて担当者をBさんにします。Bさんはチェックバックの内容を確認してさらに作業を進めます。
チケットの一生が新規で始まり、進行中、チェック、チェックバックのループを通って終了で終わるという、とてもシンプルなながれです。まずはこの形を基本にしていくことをおススメします。
普段行なっているワークフローを書き出してみると、意外と複雑な形をしていることがあります。また、あるステータスからどのステータスに移動すべきかというルールが曖昧な場合もよくあります。このような部分を洗い出して整理します。
ステータスの数
ステータスの数は、細心の注意をはらって必要最低限に厳選しないとすぐに増殖し、大きな混乱を招く要因になってしまいます。
ステータスやワークフローを定義するのは主に管理者側のスタッフで、必要に駆られて高いモチベーションをもって問題に取り組もうとしています。また、議論を進めている間は内容が全て頭に入っているため、細かいちがいもハッキリと区別することができます。それに対して、実際に使用してデータを蓄積するのは現場で手を動かしているスタッフになります。現場から見れば細かいルールに沿ってチケットを運用するメリットは特に感じられず、むしろ嫌悪の対象となることすらあります。そのようなスタッフに対して、できるだけ余計な手間をかけさせないで運用してもらえるように環境を整えることはとても重要です。
ステータスを増やしたいという欲求に駆られたときには最低十回はそのステータスは本当に必要なのか、ほかのステータスとまとめることはできないか、もしくはステータスを増やすのではなくタスクを分割することで対応できないか考えるようにしてください。個人的には、Shotgunに標準で用意されているステータスはちょっと多いなぁという気がします。最初はRedmineに用意されているくらいの内容にして、どうしても必要なら追加するという運用にしていくのが良いと思います。
チケットの担当者
チケットの担当者をどうするかというのも検討すべき事柄になります。原則的にはチケットに対してそのときに責任をもつべき人物を担当者とします。 作業者は自分にアサインされているタスクを見ることで自分が何をしなければいけないか把握できますし、プロジェクト管理者はタスクの進捗が遅れていた場合、担当者に問い合わせます。そのときに情報の更新を忘れていた場合、更新を忘れていた人の責任になります。
先の図の場合、チェックの段階で担当者がCに変わっていることがわかります。チェックを行うのは作業者とは別の担当者なので、作業者が必要な作業を行なった後にチェックへ回したら、そのタスクは一旦手元から離れ、チェック担当者が処理すべきタスクということになります。
チケットベースで作業を管理しているということは、自分の担当しているチケットを消化したら次に責任をもつべき人にそのチケットの責任を押し付け、自分の手もちのチケットをゼロにするゲームをしていることだと考えると良いでしょう。
まとめ
今回はタスクを管理する方法について考えていきました。この部分は、管理者はもちろん、作業を行うスタッフも日常的に関わるところなので、ほんのちょっとの変更が大きな影響を及ぼすことになります。そのため、様々な人の意見が入り乱れてカオスになりがちです。ぜひとも細心の注意を払って運用を行うようにしましょう。
第27回の公開は、2020年10月を予定しております。
プロフィール
