← すべての記事
scroll · 執筆進捗 · プロジェクトタスクボード · 小説執筆 7 min

「本を完成させる」をプロジェクトタスクボードで見える仕事へ変える

Story の出来事と書き手のタスクを分け、プロジェクトタスクボード、プロジェクトタスクカレンダー、プロジェクトタスクリスト、プロジェクトタスクスケジュールで執筆と改稿を管理します。

「小説を書き続ける」はタスクのように見えます。実際には、完了するには大きすぎ、始めるには曖昧すぎます。毎回、本全体を見渡すところから始まります。第3章の動機が弱い。首都から国境までの旅程を確認していない。第2幕の約束にまだ応えていない。最新の読者レポートで、メモがさらに7つ増えた。

疲れるのは未完了の仕事があることではなく、そのすべてを頭の中で動かし続けなければならない感覚です。

プロジェクトタスクボードは、その認知負荷を目に見える場所へ移し、小説には管理ではなく創作の論理で育つ余地を残します。列を作る前に、仕組みを信頼できるかを決める境界を設けます。Story 上の出来事は「作品の中で何が起きるか」に、執筆タスクは「書き手が次に何をするか」に答えます。

「冬至に王国が港を閉じる」は出来事です。「第3章から第6章まで港の閉鎖日を一致させる」はタスクです。「世継ぎが同盟を拒絶する」は出来事で、「世継ぎが寝返る理由を強める」はタスク。前者は Story、後者は書き手の仕事に属します。

Scroll ではタスクを関連する本文やカードにつなげられます。両方を同じ意味の記録にせず、作業項目から Story の文脈へ戻れます。

範囲を絞った執筆・改稿タスクを置いた Scroll のプロジェクトタスクボード
タスクが本全体ではなく書き手の仕事を表すと、執筆の進捗を確認しやすくなります。

役に立つタスクカードは動詞から始まる

「第3章で世継ぎの動機を強める」「首都から国境までの旅程を確認する」「読者の指摘を受けて第8章の冒頭を書き直す」は、「第3章」「人物の動機」より行動に移しやすい名前です。動詞が注意を問題領域から行動へ向けます。

次に、確認できる完了条件を与えます。「旅程を確認する」なら、関連出来事の移動日数が一致し、本文の出発、到着、宿泊を確認し、残る不確かさに印をつけた状態かもしれません。正式な受け入れ文書にする必要はありません。未来の自分に、どこで止めてよいかを教えれば十分です。

状態と優先度は基本的な選択を支えます。日付、親タスク、依存関係は判断が良くなるときだけ追加します。タスクを章や Story カードへリンクすれば、「何を直すか」を「なぜ必要か」へ戻せます。

タスク B がタスク A より前には本当に完了できないとき、依存関係を作ります。旅の所要時間を決めてから、複数章の日付を直す必要はあるでしょう。二つとも時間の話だからという理由だけでは足りません。飾りの依存関係は管理を増やし、仕事を明確にせず循環を作ります。

プロジェクトタスクボードの価値は、進行中の仕事を絞ることにある

最小のボードは、未着手、進行中、確認待ち、完了の4状態で足ります。終えたタスクは必要に応じてアーカイブできます。名前より、各状態を一貫して判断できることが大切です。

多くの書き手は、あまりに多くの仕事を始めています。章の途中で歴史上の細部を調べ、調査から人物構成の変更へ進み、読者コメントで冒頭へ戻る。一日の終わりには5つに触れ、何ひとつ閉じていません。

進行中の上限は、その選択を見えるようにします。4つ目の改稿を始める前に、現在のひとつを完了する、理由を明記して未着手へ戻す、意図的に保留することはできないか。目的は工業的な生産性スコアではなく、高くつく文脈切り替えを減らすことです。

スイムレーンやタグは、区分が実際の判断を導くなら、執筆、調査、改稿を分けられます。タスクが少ないとき、分類を増やすと次の行動が隠れます。ボードは、書き手の決め方を映す範囲で役立ちます。手入れの必要な美しいダッシュボードが、守るはずの執筆時間を奪うこともあります。

4つのタスクビューは異なる問いに答える

同じタスクを4つに複製せず、複数のビューで点検できます。

プロジェクトタスクボードは状態の流れと進行中の仕事を示します。確認待ちに残るものは何か。すでに進行中の項目はいくつあるか。

プロジェクトタスクカレンダーは日付を問います。今週は詰まりすぎていないか。日程のないタスクはどれか。外部フィードバックの2回の間に、十分な改稿時間があるか。

プロジェクトタスクリストは項目と階層を見渡しやすくします。「第2幕を改稿する」は、本当に完了できる行動へ分かれているか。優先度や停止条件のない項目はどれか。

プロジェクトタスクスケジュールは期間、節目、依存関係をガント形式のタイムラインに置きます。必要な構造判断より先に、章ごとの改稿を予定していないか確認できます。

4つのビューは同じ Project タスクを使います。窓を変えても、4つの正本となる記録は生まれません。Story ビューと同じく、先に問いを決め、答えられる画面を選びます。

一週間の改稿を、有限の選択へ変える

壮大なファンタジーの初回構造改稿を考えます。月曜日、「首都の危機を修復する」を7つに分けます。世継ぎの立場の変化を強める、国境までの移動時間を確認する、評議会の日付を合わせる、包囲戦の冒頭を書き直す、魔法の代償を見直す、落とした約束を回収する、最後に連続性を確認する。

7つすべてを進行中にする必要はありません。世継ぎの動機と移動時間から始め、進行中を抱えられる範囲に保ちます。最初のタスクが終わったら、関連する本文と Story 記録が実際に保存されたことを確認し、包囲戦の冒頭を進行中にします。

水曜日、地図の縮尺が決まらず旅程は保留のままです。その理由をタスク Notes や関連素材に残し、未着手に戻し、距離に依存しない魔法体系の確認へ進みます。週末には完了したカード数だけでなく、未完了が大きすぎたか、依存関係が未解決か、優先度が違ったか、Story の事実自体が未決定かを問います。

完了した仕事は永久削除せず保管済みにできます。あとで改稿の理由を確認し、繰り返し戻ってくる仕事に気づけます。

操作上の重要な境界があります。タスクを完了にしても、参照先の文書は保存されません。 タスク状態は仕事に対する書き手の判断で、開いているファイルの保存には代われません。終了前に、関連タブと Project 内容が保存されているかを確かめてください。

進行管理に本を飲み込ませない

タスクカードは追跡が必要な書き手の仕事に使います。2分で直る綴りはその場で直せます。発想の断片は本文 Notes や関連カードに残せます。Story 世界の出来事は出来事カードに属します。

タスク日付は Scroll 内で予定を見直す助けになりますが、アプリを閉じている間に OS 通知を出しません。締切、インタビュー、チーム承認が通知に依存するなら、システムカレンダー、リマインダー、共同作業サービスにその責任を持たせてください。

複雑なチーム承認、組織全体の権限、ワークフローの自動化が必要なら、汎用の共同作業基盤のほうが適することがあります。Scroll のタスク作業画面は、書き手の Project 内の創作と改稿作業が中心です。

直線的に書き、未完了項目が少ないなら、小さなリストで十分かもしれません。プロジェクトタスクボードは、執筆、調査、外部フィードバック、複数回の改稿が重なるとき有用になります。方法は解決する負担に合わせて育てます。

次の一歩を、始められる大きさにする

短い整理を試してください。

  1. 頭の中で最もうるさい3項目を選び、表題を動詞から書き直す。
  2. 各項目をどこで止められるか一文で書き、文脈となる章またはカードをリンクする。
  3. ひとつを進行中にする。完了するか明確な停止理由が生じるまで、次を選ばない。

タスクを分けるうちに、Story で何が起きるか未決定だと分かったら、ひとつの Story に11のビューが必要になる理由へ戻ります。繰り返す事実の記録方法が難しいなら、Story テンプレートは物語の公式ではないを読んでください。全体を見直すなら長編執筆ガイドへ戻れます。

正確なビューと項目の境界は、タスクと執筆進捗ガイドタスク作業画面ガイドにあります。編集上の原則はもっと小さなものです。ボードに「本を完成させる」を、今日始めて本当に止められるひとつの行動へ変えてもらいます。