長編執筆のワークフロー：構想から改稿、バージョン管理まで

日曜の午後10時。月曜日になるまで、小説に使える時間は90分です。第12章の日付は Timeline と食い違い、ある人物の名前には3通りの表記があり、編集者のコメントにはまだ「中盤が停滞している」とだけ書かれています。

足りないのは意欲ではありません。長い Project では、いくつもの種類の負荷が同時に生まれます。構想、執筆、調査、改稿、バージョンの判断には、それぞれ異なる次の行動が必要です。

このガイドは Scroll を使う書き手の出発点です。今日つまずいている状況に近い節を選び、ひとつの道に集中してください。次の場面を書くために、作業方法のすべてを組み直す必要はありません。

Story の姿が見えにくいとき

人物、場所、出来事、ルールが複数のノートに散らばっているなら、新しい文章のアウトラインを作る前に Story の構造から見直します。

• ひとつの Story に11のビューが必要になる理由では、書き手が記録した同じ Story data を、各ビューが異なる角度からどう読み取るかを説明します。
• 物語の公式にしない Story テンプレートでは、何を項目や正式な関係として扱い、何をノートのまま残すかを考えます。
• Story に役立つ世界設定では、設定作業を場面ごとの選択と結果につなぎ直します。

Story ビューは、日付、関係、手がかり、欠けている事実を自動で推理しません。Project に記録した情報を点検しやすくするものです。Relationship graph では、明示的な関係に加え、ビュー設定に応じて共有イベントなどから派生する読み取り専用のつながりも確認できますが、本文から正式な関係を自動作成するわけではありません。この境界があるからこそ、何が真実かを決める責任は書き手に残ります。

作業が前へ進まないとき

Story は十分に見えていても、執筆時間の使い方が見えないことがあります。「本を進める」では大きすぎて着手できず、画面の混雑や作り込みすぎた進捗管理が、短い時間をさらに窮屈にします。

• 小説執筆を進めるプロジェクトタスクボードのワークフローでは、Story 内の出来事と書き手の仕事を分け、改稿を完了可能なタスクにします。
• 続けられる、気の散らない執筆空間では、明確な目的、必要最小限のフィードバック、安全な終了を軸に Black House を捉えます。
• Markdown 執筆の Visual Mode と Source viewでは、整形された執筆画面とソースの直接確認を、別々の原稿にせず行き来する方法を扱います。

目的は一分ごとに測ることではありません。次の作業単位を見える形にし、完了できる大きさまで小さくすることです。

調査と改稿が Project を占めているとき

原稿が育つと、不確かさの種類も変わります。誰が何を知っていたかを確認し、ある記述の根拠を探し、章をまたぐ構造上の問題を直し、現在の正本となる原稿を特定しなければならないかもしれません。

• 手がかり、時系列、人物の認識を管理するでは、実際に起きたこと、各人物が知っていること、読者に示されたことを分けます。
• 調査ノートを原稿につなぐでは、外部の原資料、Project 内の複製、書き手の判断、原稿上の表現を区別します。
• 初稿後の構造改稿ワークフローでは、幅の広い講評を、範囲の定まった一回の改稿へ変えます。
• 原稿バージョンと Project バックアップでは、Works、原稿バージョン、Publish Version、Project 全体の復旧を整理します。

これらのガイドが扱う Scroll は作業環境であって、自動診断の装置ではありません。Timeline は入力した日付の関係を見せますが、筋が成立しているかは決めません。検索は語句の場所を示しますが、その意味を確定しません。編集上の確認は、最後まで書き手が行います。

原稿が「本」になり始めるとき

Scroll が担うのは構想、執筆、改稿です。組版済み PDF、EPUB、印刷レイアウトを Scroll が直接作るわけではありません。原稿がページと出版の作業へ移れるほど安定したら、Scroll と Scribe のワークフローガイドへ進んでください。

今日は、ひとつの問いとひとつのガイドを選びましょう。役に立つワークフローとは、Project を開いたときよりも明確な次の一歩を持って席を立てるものです。