final-final を卒業する：原稿バージョン、正式なソース、Project バックアップ

午後11時、三部作の著者にブックデザイナーから連絡が届きます。「第2巻の第12章に、承認済みの修正が入っていないのはなぜですか」。著者は第2巻の初回レイアウトを準備しながら、第1巻の新版へ読者からの正誤情報を反映していました。フォルダーには「著者最終」「編集者確認」と final-final があり、同期ドライブには競合コピーも増えています。どの名前も正しそうに見えますが、いま制作へ入れるべき Work、バージョン、章を示すものはありません。

古い原稿がページネーションと校正へ入る前に、デザイナーが誤りを見つけました。著者は、final-final に三つの無関係な仕事を担わせていたことに気づきます。今回の出版に選んだ原稿を示すこと、過去のある時点の文章を保存すること、端末故障や操作ミスのあとに Project 全体を復元することです。一つのファイル名では、三つの責任を背負えません。

今回の引き渡しを正確に特定する

Scroll は、著者が選んだ通常のローカル Project フォルダーを使います。一つの Project に一つ以上の Works を登録できるため、第1巻の新版と第2巻の初版は、曖昧な「シリーズの現行原稿」を共有せず、それぞれの境界を保てます。

シリーズ設定が変わっても、三冊すべての原稿が更新済みとは限りません。著者はまず、その変更がシリーズ全体、一つの Work、一つの原稿段階のどこに属するかを決めます。Scroll は、別々の Project 間で Story data を自動的に反映したり、旧版へ後発の設定を採用すべきだと判断したりしません。

著者は第2巻の Work を選び、原稿バージョンとソースを確認し、今回の出版に使うバージョンとソースを Publish Version として記録します。これでデザイナーへ、「第2巻初版にはこの章一式を使ってください。第1巻の改稿は別の Work で進行中です」と伝えられます。会話はファイル名からの推測ではなく、明示した判断の確認になります。

これは管理のためだけの管理ではありません。第1巻の正誤修正と第2巻の編集を同時に進めても、どちらの原稿も識別できる状態を保てます。複数巻にまたがる判断が固まったら、著者が決めた Project の規則に沿って反映します。

バージョン名は判断を、実際の複製は内容を残す

原稿ソースは、著者が開いて編集し、保存する Markdown のままです。原稿バージョンを登録しても、ファイルは複製も凍結もされず、Git のような履歴も作られません。ソースを編集し続ければ、バージョン名が新しいスナップショットになるわけではありません。次の引き渡し前には、章の範囲、順序、未解決の印をもう一度確認します。

意味のある編集段階には、実際の複製が必要です。編集者へ渡す前、構造改稿のあと、校正へ進む前などです。複製はその時点の文章を保存し、バージョン記録はその文章が Work で果たした役割を説明します。

重要な複製には、短いメモも添えます。対象の Work、確認段階、事実確認の状態、後のソースがこれに代わった理由です。二つのファイルがどちらも正しい文書でありながら、一方だけが現在の判断を表すときに役立ちます。更新日時だけで正式なソースは決められません。

Project 全体のバックアップは章以外も守る

原稿ディレクトリだけの複製では、本文を守れても、タスク、保存した Story ビュー、キャンバス、Project 設定、引き渡し記録が抜ける可能性があります。Project 全体のバックアップでは、Scroll を閉じたあと、非表示のファイルとフォルダーも含めた Project フォルダー全体を保存します。対応する手順は、最新のデータ安全性と復旧ドキュメントを確認してください。

ローカルファーストとは、バックアップ先と方法を著者が選ぶことです。閉じた Project の完全な複製は、別のディスク、外部デバイス、信頼できるクラウドバックアップ先へ置けます。ローカルファイルが失われないという意味ではなく、同期成功の表示も、サービスが原稿バージョンの意味を理解している証明にはなりません。

構造改稿、端末変更、正式な引き渡しの前には、小さな復元確認を行います。バックアップを一時的な場所へ複製し、Project を開き、最初と最後の章、著者タスク、Work 情報を確認します。目的は本文だけを取り戻すことではなく、現在の文脈とともに作業を再開できることです。

長く続くシリーズなら、いくつかの復旧地点を意味のある段階へ結びつけます。構造改稿完了、編集者へ引き渡し、Scribe へ進む準備完了などです。頻度は危険度に応じて決めます。目的を説明でき、復元確認済みの少数の地点は、用途を誰も覚えていない大量の複製より役立ちます。

外部編集者や複数端末を使えば、なお競合は起こり得ます。手作業で比較する前に、双方を残してください。競合コピーは判断を要する実ファイルです。更新日時が新しいだけで正式なものにはならず、Scroll が両方の創作上の判断を自動統合することもありません。

本の制作には明示的な引き渡しが必要

原稿が安定したら、Scribe が Appearance、ページネーション、PDF、EPUB、その他の対応する出版出力を担います。Scroll は使用予定の Work、原稿バージョン、ソースを記録します。著者は同じ Project を Scribe で開き、認識された Work、Publish Version、Source folder、章数、章順を確認します。

これはアップロードではなく、Scroll をレイアウトアプリケーションへ変えるものでもありません。上流の準備状態は、Scribe が意図したソースを認識したことや、ページが正しいことを証明しません。Scribe で Source folder、章数、順序、原稿バージョンを確認してから、ページ作業を始めます。

明示的な引き渡しは、実務上の損失を抑えます。古い原稿が制作へ入れば、再ページネーション、校正のやり直し、校正刷りの破棄、発売延期につながりかねません。明確なソースがすべての誤りをなくすわけではありませんが、曖昧なファイル名から生まれた一つの誤りが、制作工程全体へ流れることを防ぎます。

完全な事前確認には原稿が Scribe に進める5つのサイン、より広い分業にはScroll から Scribe へのワークフローをお読みください。構造改稿がまだ終わっていないなら、初稿後の構造改稿ワークフローから始められます。シリーズ作家は、シリーズ作品のための Project・バージョン管理ツールでも方法を比較できます。

「何を変更しているか」「いま正式なのはどのソースか」「Project をどこから復元できるか」に答えられれば、final-final は正式性の証拠ではなく、ただのファイル名へ戻ります。Scroll 長編執筆ワークフローへ戻るか、Scroll 製品ページでローカル Projects、Works、出版ソースの整理方法をご覧ください。