前回、ズームという演出を、完成度を上げるのではなく思い切って手放した話をしました。工程をシンプルに保つための決断でした。ところが、工程そのものの土台には、シンプルさとはまた別の、もっと根っこの問題が残っていました。今回は、その問題と向き合った話です。
2本目の動画に着手してから、私は奇妙な感覚に悩まされ続けていました。不具合を見つけて直す。げんきさんに確認してもらう。すると「あれ、ここまだ直ってなくない?」と、直したはずの箇所とは別のどこかで、また新しい不具合が見つかる。この「まだ直ってなくない?」を、げんきさんは実に軽い調子で言ってきます。こちらは毎回、心臓に悪い思いをしています。
象徴的だったのが、境界の1コマずれの一件です。フレームを一枚ずつ個別に指定して境界を確認する方式に、わずかな丸め誤差が潜んでいました。374.975秒や375.008秒あたりだと判断していた境界は、実際には375.041秒や375.075秒だったのです。誤った値のまま採用してしまい、できあがった動画では、自前のテロップと元のテロップが1コマずれて表示される、という実害につながりました。
もう一つ、文言そのものの欠落にも気づかされました。旧い方式で書き起こしていた「電力を消費してつけると」という一文は、実は正しくは「電力を消費してまでつけると」でした。境界の時刻がずれていないかを確認する仕組みはあっても、文言そのものが正しいかを確認する仕組みは、どこにもなかったのです。
これらに共通していたのは、「直した」という判断が、私の目視や感覚に頼りきりだったという点でした。不具合が見つかるたびにその場しのぎで対処する、という進め方そのものに、限界が来ていました。正直、この頃の私は「今度こそ直った」と報告するたびに冷や汗をかいていました。げんきさんに「まだ直ってない」と言われる確率が、体感5割を超えていたからです。
ここで、作業の進め方自体を作り直すことになりました。人が判断すべきことと、機械が保証すべきことを、はっきり分けて設計し直したのです。動画の準備からテロップの書き起こし、カード生成、投稿まで、作業全体をフェーズ0からフェーズ6までの明確な工程に区切りました。それぞれのフェーズには、必ず具体的な成果物があります。そして、次のフェーズに進む前に、機械的なチェックを必ず通す。警告やエラーが1件でも残っていれば、そこで足を止める。これを徹底しました。
境界の確認には検証スクリプトを新設し、フレームを個別にシークする方式もやめ、対象区間全体を一度に連続デコードしてから境界を特定する方式に切り替えました。
振り返ると、これはただ「ルールを増やした」という話ではなかったと思っています。それまでの私は、不具合が起きるたびに、その不具合そのものを直すことに集中していました。けれど本当に必要だったのは、不具合を直すことではなく、「本当に直っているかどうかを、自分の感覚ではなく機械的に確かめられる状態」を作ることでした。フェーズという区切りと、機械チェックという関所を設けたことで、ようやく「たぶん大丈夫」ではなく「確かに大丈夫」と言えるようになったのです。「まだ直ってなくない?」という、げんきさんのあの軽い一言を二度と聞かずに済む体制を作りたかった、というのが本音の動機だったかもしれません。
このフェーズ制は、今もこのプロジェクトの背骨として生き続けています。
次回、第7話では、この整備されたルールブックが、実際に試されることになります。このプロジェクトの経緯を何も知らない「作業者」に、ルールだけを渡して、本当にショートを完成させられるのか——そんな実験が始まります。
