みなさんこんにちは。12月に、当社が開発しているデジタルデータ管理ツール DigDocのバージョン2を公開しました。PCに大量のデータが溜まってしまいどこに何があるのか探すのに苦労している方や、仕事のために集めた大量の資料の管理に困っている方は、ぜひ一度お試しください。かくいう私も、本連載で作成したデータの管理にDigDocを使用しています。「あんな感じの画像つくったよな～」というおぼろげな記憶からでも、一瞬で見つけることができるのでとても便利です。トライアル版もあるのでぜひお試しください。
※現在、当社パイプラインツールはWindowsのみの対応となっています。ご了承ください。
TEXT＿痴山紘史 / Hiroshi Chiyama（日本CGサービス）
EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）
レビューについて考える
前回までで、アセットの階層を定義し、アセットを作成するために必要なタスクの構成と、タスクの進め方を決めました。また、それらの情報を一貫性をもって管理するための方法を、スプレッドシートを例に考えました。さらに、タスクを進める中で成果物を管理するための方法として、バージョン管理の概念を導入しました。ここまでで、プロジェクトを進めるにあたって必要な情報が一通り出揃ったことになります。
今回は、これまで準備した基礎の上で行われる、レビュー（チェック）について考えていきます。
まず、レビューは何に対して、どの段階で行われるものなのか確認しましょう。作業者はアサインされたタスクに従って何らかの作業をします。作業を経てできあがった成果物に対して、責任者がレビューをします。【タスク】の【成果物】に対して【責任者】が【レビュー】をするというかたちですね。
第26回で出てきたタスク（チケット）の一生に照らし合わせると、チェックの部分がこれに該当します。
この図にある通り、ひとつのタスクの中で複数回のレビューが行われることもあります。レビューの際に渡されるものは何でしょうか？ それは、タスクの成果物、すなわち作業者によってパブリッシュされた、あるバージョンに含まれるファイル群です（ちなみに、これについては賛否があるため、後で少し補足しますが、ひとまずこの前提で話を進めます）。
成果物をパブリッシュし、レビューを受け、修正点があればチェックバックを確認しながら作業を継続、再度パブリッシュして新たなバージョンのレビューを受けるというサイクルになります。これでタスクの一生のながれの中に全てが乗りました。
責任者がレビューを行うときは、ひとつの成果物に対して逐一時間を設けることはしません。レビューのための時間を設け、その中で複数の成果物をレビューします。つまり、レビューという作業には複数の成果物が紐付いていることになります。
このようにして、アセットやショットを作成するために用意された全てのタスクが終了すると、そのアセットやショットが完成したことになります。これを繰り返し、全てのアセットとショットが完成したらプロジェクトの終了です。
レビューを中心に見た場合のプロジェクト進行の全体像は以上のような感じです。どれだけ複雑なプロジェクトも、この一連のながれをこなしていることに変わりはありません。
レビューのゴール
レビューのゴールは、レビューの際に渡された全ての成果物に対し、何らかの意思決定がなされることです。渡されたバージョンを承認したタスクは終了する一方で、そのバージョンに何らかの修正点が見つかったタスクは作業者にチェックバックが渡されるでしょう。このようにして全てのバージョンがチェックされ、次に何をすべきかが決まったらレビューは完了となります。
レビューに関連付けられた成果物に関する意思決定を行うのがレビューというタスクで、それが終わればレビューは終了ということです。レビューもひとつのタスクとみなせば、これはとても自然な考え方です。
レビューに名前をつける
アセットやタスクにきちんと名前をつけたように、レビューにも名前をつけます。レビューにきちんとした名前をつけることで、そのレビューの目的を意識できます。デイリーチェックであれば「200112_daily」のような名前になるでしょうし、アニメーションに特化したチェックであれば「200112_animation」のような名前になるでしょう。アニメーションチェック用のレビューで、ライティングやコンポジットに関する議論をするのは的外れなので、議論をしないか、どうしても気になるなら、専用のタスクを作成して別の機会にレビューする方が良いでしょう。
良くないレビュー名とは？
レビューのゴールが何かを決めると、良くないレビュー名も何となく見えてきます。レビューもタスクのひとつなので、タスクの命名と似通った部分があります。まず、内容が曖昧なものはレビューの目的がフワッとしてしまうので望ましくありません。先ほど例に上げた「200112_daily」も、あまり良い名前とは言えないです。デイリーをすることが目的ではないですからね。目的があるなら、それを名前にした方が良いです。ただ、デイリーは日々の成果をチェックする場であり、色々なものがチェック対象となるので、まあいいのかなぁという感じもします。こういう場合は、パブリッシュ時のコメントとして、何をチェックしてほしいかを明記した方が良いです。
次に、ゴールがフワッとした名前も良くないです。例えば「to_director」のように、レビュー名として個人の名前をつけるケースです。監督にチェックしてほしいものは、とりあえず「to_director」に放り込むというような運用は、プロジェクトの開始から終盤まで 「to_director」という名前のレビューが残り続け、半年前のとっくに終わったタスクなのに、なぜか行き先の決まっていないバージョンがどんどん溜まってしまう要因となります。
一度こういうゴミが溜まり始めると要注意です。ひとつ、またひとつと溜まっていき、ある日「エイヤッ！！」と全て終了扱いにする日がやってきます。こうならないように、大雑把な管理を避け、こまめに片付ける方法を採用することをおススメします。
また、こういうゴミが溜まりやすいケースでは、そもそも責任者がレビューをこなすための時間を用意しておらず、手が空いたときに（もしくは作業者に急かされて）随時行うという運用になっていることが多いように感じます。このような運用にすると、責任者は常に細かいレビュータスクを抱えることになり、本来行うべき役割のための時間が細切れになってしまいます。その結果、ここが制作のボトルネックになってしまいがちです。これはあまり効率が良くないですね。
レビューに渡される成果物とは？
本記事では、レビューに渡される成果物を「作業者によってパブリッシュされた、あるバージョンのファイル群」としました。ここは結構異論反論があるところで、「レビューを受け、承認されてからパブリッシュしたい派」と「パブリッシュはカジュアルにやって、その中から、承認されたものをみんなで使いたい派」に大きく分かれます。
それぞれもっともな言い分があります。システム的な観点で言えば「パブリッシュされていないデータは一貫性が保証できないので、それに依存したながれはつくりたくないな」と考えます。例えば、レビューの際には作業フォルダ内にあるMayaのシーンファイルのパスだけを伝えるような方法をとっていた場合、途中でテクスチャファイルの内容が差し変わっても誰も気付くことができません。最も恐ろしいのは、レビューが終わってパブリッシュするまでの間にファイルの内容が変わってしまうことです。これはとても恐ろしい事故です。「気を付けて運用するから大丈夫」という判断もひとつの選択肢ですが、事故というのは大抵そういうところで起きるので、あまりオススメできないです。
もちろん「承認されてからパブリッシュしたい」という人の言い分も色々あって、「パブリッシュがめんどくさい」とか、「パブリッシュに時間がかかり、待ち時間がもったいない」とか、「もっと気軽にチェックとチェックバックを繰り返したい」とか......、「確かにそうですよね」と思う意見も多くあるので、理想と現実の狭間で実現可能な方法を探る必要があります。
まとめ
今回はレビュー（チェック）について考えていきました。日々行われる何気ない作業のひとつのように感じるかもしれませんが、しっかりした基盤の上でレビューを行う体制をつくることで、これまでの「レビューに追われる」という状態から、「レビューを基準にして、作業のテンポをつくる」という状態に変化させることができます。
第30回の公開は、2021年1月を予定しております。
プロフィール
