板谷×かとりく

プロフィール
板谷勇飛（板谷）：2001年生まれ。株式会社IDENCE代表取締役。大のあんこ好き。
加藤陸（かとりく）：2000年生まれ。3DCGデザイナー。ものづくりオタク。
藤井桃子（藤井）：2000年生まれ。マネージャー。チョコレート好き。

目次

RBCって何？

ふじも：今回は板谷とかとりくに来てもらって、最近社内で頻繁に会話に登場するRBCについて話を聞いていきます。
早速ですが「RBCってそもそもなんぞや？」って話ですよね。
一般的な用語ではないのでざっくり説明お願いします。

かとりく：RBCは、レンダーベースドチェック(Render Based Check)の略です。
俺が発案して2024年の10月ぐらいから運用してるので、半年経ったぐらいです。
レンダーベースドチェックというのは、映像制作を進めていく上での社内のチェック体制のことを指しています。

ふじも：CG制作においてのシステムだよね。

かとりく：そうね。
CG案件のルックを詰めていく上での、IDENCE独自のチェック体制です。
プレビュー出力や、編集画面を直接共有する確認方法ではなく、クライアントチェック前にも複数回レンダリングしたもので社内チェックを挟もうという考え方ですね。

RBC中の様子

RBCが生まれた経緯

かとりく：これまでは、クライアントに対しての初校提出や第2校提出に間に合うように制作するという流れでやっていて。
ただ「決まったタイミングにプロジェクトメンバー全員でチェックして進めよう」みたいな決まりが特になかった。
どうやってクオリティチェックしてたかっていうと、板谷が俺の作業してるモニターを覗いて「今どんな感じ？」って声かけてきて、俺が「今こんな感じで作ってて、この部分は作り終わってないけど、もう少し表現改善するよ」って答えるみたいな。
特に形式化されてない会話を重ねながら、ちょっとずつクオリティを上げていくやり方でした。
もしくは、俺がひたすら制作途中のスクリーンショットをメッセージで投げ続けて、板谷が五月雨式にコメント返すみたいな感じ。

ふじも：うん、そうだったよね。
要するにレンダリングをせずにチェックしてたってことだよね。

かとりく：そう。
だけど、すごく非効率だなっていう感じがずっとしていて。
っていうのも、チェックのやり方が形式化されてないから、ライティングは全然詰めきれてない状態の時に、板谷からライティングについて指摘されて入れ違いになったり。
レンダリングされた最終形態で確認できないと、どうしてもある程度想像で完成イメージを補完しながらチェックしないといけないから、フィードバックする側としても、コミュニケーションが取りにくいっていう問題点もあったと思う。

板谷：そうだね。
これからブラッシュアップするんだろうなって思ってたら、最終チェックの時にもブラッシュアップされてなくて、指摘したら「たしかに」ってなることがあったんですね。
レンダリングして見せてほしいって相談もしたけど、流石に時間かかるし非効率だからやめましょうみたいな話になってた。
でも、クオリティを上げていくには、きちんとレンダリングしてチェックする方がいいんじゃないか、レンダリング時間が増えて大変に思えるけどあとあと結局楽になるでしょうって、そんなところから始まった話ですかね。

従来のクオリティチェックの様子を再現

RBCの流れ

ふじも：実際にRBCをするときの流れはどんな感じ？

かとりく：まず、事前に日時が決まってて、参加者全員のスケジュールが押さえられます。
クリエイターはRBCが始まる前までに、レンダリングした動画ないし画像を、担当プロデューサーに対して共有するんですね。

RBCなど社内のさまざまな予定が入力されているカレンダー

ふじも：レンダーベースドチェックだからね、必ずレンダリングしたものをチェックする、と。

かとりく：そう、そこがミソです。
いよいよRBCの開始時間になったら、画像や動画をMTGルームの大きな画面に映しながら、みんなからフィードバックを受けます。
プロデューサーには、チェック体制を整えてRBCの進行担当と、フィードバックをまとめたスライド資料作るのもやってもらってます。

板谷：この「クリエイターではなくプロデューサー中心で進める」っていうのもRBCのポイントですね。
プロデューサーに、自分がその映像の最終権限を管理してるんだっていう意思を確実に持ってもらいたいという狙いもあるんですね。
なので、担当している案件は自分が作ったものであるという思いを持ってもらった上で、それを見せてもらうっていう立て付けです。

ふじも：なるほど。
仕組み的に、クリエイターとプロデューサー両方に責任感を持って進行してもらいやすくなってるんだね。

RBCの進行役をするプロデューサー（あらだ）

RBCのココがいい！

ふじも：そんなRBCですが、ココがいい！というポイントを簡単に教えてください。

かとりく：そうねー、いろいろあるけどとりあえず曖昧なコミュニケーションが減ったかな。
レンダリングの作業は増えたんだけど、その工数以上にコミュニケーションの効率化が起きた。

ふじも：さっき話したフィードバックのすれ違いとか、噛み合ってないな、みたいな問題が減ったってこと？

板谷：わかりやすい例で言うと、例えば今までだと、レンダリングされてないワイヤーの状態で、アニメーションチェックが送られてきたりしてたんだよね。
その状態でも明らかな問題がないかどうかはわかるけど、実際レンダリングして見てみたら全然印象が違うってことはあったりして。
RBC制度が定着した今は、フィードバックの効率も良くなってると思う。

ワイヤー状態のアニメーションチェック動画

かとりく：レンダリングする工程自体が、完成状態を想定して作業するのとイコールなところがあって。
レンダリングするって決まりが1つあるだけで、自ずとクリエイターは完成状態に向けて作業しなきゃいけない状態が生まれる。
クリエイターの心理的にも、ある程度の期間で完成まで持っていこうって意識が生まれて、面倒くさい作業を後回しにすることもなくなるし、早めに問題点を共有できるっていう利点もあるかな。

ふじも：うん、作業期間が区切られてる方が効率的に進むよね。

かとりく：そうね、RBCを設定すると納品までの見通しもつきやすくなるから、それもいい。

板谷：あとはやっぱり、レンダリングしなきゃわかんなかった問題ってのがあるんですよ。
技術的な問題もそうだし、表現的なところもそうだけど「完璧だと思ってレンダリングしてみたらエラー出てた」とか。
それについても、最終納品までに何回もRBCが設定されていることによって、その分レンダリング挟むことになるんで、シンプルにエラーに早く気づけるって利点もあります。

ふじも：レンダリングしないとわからない問題を早期発見できるのは大きいね。
自然と納品までのワークフローが洗練されるよね。

かとりく：そう、顕在化してない問題が限りなく減るから。

板谷：ここまで色々話してるけど、もっと根本的なところでもいい効果が生まれてて。
組織体制の変化もあって、俺が1案件ごとに細かく干渉することがほぼなくなってきたんです。
そうすると、みんなが何やってるか詳しく知らない状況が生まれちゃって、納品完了してから「こんなの作ってたんだ」みたいになってた。

ふじも：そんな時期もあったね……。

板谷：今からしたら信じられないと思うんだけど、そうなっちゃってた。
これはまずいってことで、全てのRBCに板谷も参加することで、全案件のクオリティを握った状態でいられるようにしました。
会社として出していいクオリティラインに達しているかどうか、社長チェックの機会としてもRBCはすごく重要です。
あと、俺にとってはRBCの時間が全案件と向き合う貴重な時間になってるので、会社のメンバーにとっても「外せないチェックタイミング」として効力が強まってますね。

かとりく：我ながらいいシステムだ〜〜！

板谷：今から考えれば、当たり前にできていて然るべきチェックだと思うんですけど、意外としっかりとした制度化まではできていないプロダクションも少なくないと思うんですよね。
IDENCEの品質保証の証しとして、今納品させていただいてる全ての案件は、初校をお出しする前から数回のRBCを経て、お客様にお届けさせていただいてます。

ふじも：うんうん、ありがとうございます。
悪いところを強いていうとしたら、レンダリング総時間が増える分、作業が重くなってしまうってことくらい？笑

かとりく：そうだね。
でも、意外と合計の作業時間は減ってるかもしれない。

ふじも：あ、そうなんだ。

板谷：ちなみに、レンダリングってどれぐらい時間かかってるんだっけ？

かとりく：レンダリングは、いつも1フレーム大体3分ぐらいの基準にしてやってるから、1秒の動画を書き出すだけでも3分×24で1時間以上かかる。

板谷：しかも、かなりのハイスペックPCを使っててそれくらいかかるってことだよね。

かとりく：そうそう。

ふじも：あれ、待って。
かとりくがサラッと3分×24って言ってたけど、フレーム数の説明もお願いします！

かとりく：映像は、1秒間に大体24コマか30コマの画像が連続で表示されて、それが動いて見えてるんですね。
1フレームっていうのは、そのうちの1コマの画像のことで、それを3分かけて書き出す設定だと、1秒の映像が書き出されるのに1時間以上かかる計算ってことになります。

ふじも：長いよねーー。

4秒の動画を書き出し終わるまでに、トータルで5時間半かけている様子

かとりく：どうしても時間は取られちゃうから、なるべくレンダリングは最小限にしたいと思っちゃうんだけど、RBCがあるから一旦完成のクオリティまで持っていかなきゃ、ってなるんですね。
そうすると、何か問題が発生してもだらだら対処する暇がないから、なんとか終わらせようと試行錯誤するうちにひらめいて解決したケースも結構あって。
長い時間をかけて技術課題に対処するよりも、一旦社内チェックに出して、フィードバックをもらってまた出す、を繰り返した方が作業全体の効率も上がるし、クオリティも上がるし良いこと尽くしですね。

板谷：あと、RBCを始めたことによって、案件のタスク進捗状況をプロデューサーベースで毎日スプレッドシートに更新していくシステムが生まれたんですね。
案件によっては、当初の制作スケジュール表から実際の進捗がズレてくることも多い。
常にプロデューサーがスケジュールを握り続け、ちょっとでも怪しそうなところがあったら、朝礼で漏らさず確認するというシステムが出来たのは、会社としてもしっかりしてきてるかなと思ってて。

ふじも：そうだね。
朝礼で案件の進捗チェックするときに、RBCの設定漏れがないかどうかも確認してます。

かとりく：今までだと、初校提出までの2週間を使って完成させようみたいなざっくりしたスケジュールだけだった。
今はRBCのおかげで1日単位の作業もみんなで共有が取れるから、社内でそれぞれの稼働を細分化する上でも役に立ってる。

ふじも：うん。
最終納品が2ヶ月先だからといって、丸2ヶ月作業できるわけじゃないからね。
見通しを立てることがいかに重要か、身に染みてきてるよね。

かとりく：意外と仮でもスケジュール立てると見えてくるものって多いから。

ふじも：ね、そう。

かとりく：「意外とそんなに作業できる日数ないんじゃない？」って気付いたり。

ふじも：RBC導入する前と導入してからの期間でみると、納品物のクオリティも変わってきた？

板谷：成果としても変わってきてます。
1番わかりやすいのは、全員のクオリティ管理に対する意識が明らかに変わってるなって。
要は全員担当者集まって、容赦なくチェックされる機会ができた。
で、プロデューサーによって修正対応項目として全部スライドにまとめられて、クリエイターにプレゼントされるわけですよ。
残りの期限でブラッシュアップしなきゃいけないことが明確になるし、それを潰せなかったら明らかにクオリティ低下要因が残ってることになるわけで、最終納品までの作業ロードマップがすごくきれいに可視化されていく。
だから、そもそもに会社全体としてクオリティをしっかり上げていこうって雰囲気が強まった気がしますね。

かとりく：うんうん。
自分が作った映像が誰かに見られてる状態を認識する機会って意外と意識しない限りなくて。
でも、作った映像は誰かに見られるものなんだから、どう見られるかっていう意識は絶対に持ってなきゃいけない。
だけれども、それを体感する機会があまりなかった。
RBCを始めてからは、社内のみんなから見られるっていう疑似体験ができるので、客観性を上げる良いきっかけにもなってると思います。

より良い仕事につながるシステム

ふじも：じゃあ最後、RBCの活用方法や他にチャレンジしたいことはありますか？

板谷：これから我々が進んでいく道として、強みとさせてもらっていた部分を1つのサービス化して会社の方向性を整えていこうってことになりまして。
そうなると、より上流からプロジェクトに取り組むことが必要になってくる。
プロジェクト全体を客観視した上で、どういうところで使われて、どういう人に見られて、どんな機能を持ってないといけないのか、細かく振り返りながら進めていくことが欠かせないと思うんですね。
今後の展望としては、関係企業にもRBCに参加してもらって、みんなでチェックすることもできるかもしれないし、これから先、いかに頂戴した予算に対して誠実なものを納品するかという部分で、このシステムが活躍すると期待してます。

ふじも：うんうん、ありがとうございます。
かとりくはどう？

かとりく：社内で起こりがちなエラーに対して、実際にシステムを考えて解決した例が出来たのはすごくいい流れだと思う。
今後もより良い仕事のためにできることがあれば、どんどん新しいことも試していきたいです。
今回このmagazineでRBCについて言語化出来たのも良かった！

板谷：そうね、現場から上がってきた意見で作られた仕組みであるっていうのもいいよね。
今後もIDENCEメンバーがそれぞれ、会社のためにできることを考えながらやっていってもらえたら嬉しい。

ふじも：そうだね。
みんなでより良い働き方、仕事のクオリティを上げるために考えていきたいね。
それでは今回もお読みいただきありがとうございました！