個人開発で複数プロジェクトを回す｜docsだけで再開できる仕組み

個人開発で複数のプロジェクトを並行させると、数週間ぶりに開いたリポジトリで「どこまで進めたか」を思い出せず、そのまま塩漬けになりがちだ。敵は忘却だ。対策は記憶力ではなく、docs から文脈を復元できる構造だと考えている。本稿は、多数のプロジェクトを止めずに維持するための「セッション再開規約」と「進捗表」を、実運用の実物とともに整理する。

セッション再開規約 — 読むファイルを固定する

並行運用の核は、再開時に読むファイルを2点に固定することである。一つは各プロジェクトのフェーズ計画、もう一つはそのプロジェクトで直近に承認された成果物——それ以外は読まない。この記事群を回している記事制作ワークストリームでは、フェーズ計画ファイルの中でこの規約を明文化している。

再開時に読むのは本ファイル＋直近フェーズの成果物のみ。会話履歴に依存しない。承認記録は下の進捗表に追記する。

なぜ2点で足りるのか。フェーズ計画が、全体の地図と現在地の両方を持つからである。計画には工程の全体像とゲート条件が、末尾の進捗表にはどのゲートまで承認済みかが載る。計画ファイルを開けば「地図」と「現在地」が同時に手に入るわけだ。もう一方の直近成果物は、次のフェーズの入力そのものになる。前フェーズが産んだ設計文書や計画表を次がそのまま読む——雛形が成果物で上書きされ、その成果物が次の雛形になる連鎖である（この連鎖を生むスキャフォールドの設計は別稿で扱う）。

会話履歴に頼らないことが要点だ。チャットのセッションはいずれ流れて消えるが、ファイルは残る。文脈を記憶に置かずリポジトリ内の docs に置けば、セッションが切れても同じ2点を読み直すだけで再開できる。

進捗表とゲート記録 — 承認を成果物側に残す

再開の現在地を担うのが進捗表である。この記事群のフェーズ計画に載っている進捗表は、いま次のようになっている（メモ列は省略）。

表を見れば、計画（G1）まで承認済みで記事は01〜10まで通過し、残りは11と12——本稿が11番目——と一目で分かる。数週間ぶりに開いても、この数行で次にやることが一意に決まる。ゲートを人間承認で通す設計そのものは別稿で扱った。

運用上の約束が一つある。会話で「承認する」と言われても、この表に追記されるまで承認は存在しない扱いにする。承認をファイルに固定するからこそ、履歴が消えても効力が残る。進捗表は生きて更新され続ける——それ自体が、記録が会話ではなく成果物側に積まれていることの証明である。

実際に回っているポートフォリオ

手元には現在16のリポジトリがあり、新しいものほどこの運用を濃く適用している（実測。すべてに CLAUDE.md があり、rules・agents・commands の三点セットが揃うものが8、モデル配分計画まで同梱するものが3——docs の厚みには世代差がある）。すべてが同時に動くわけではない。多くは数日〜数週間単位で止まっては別へ移り、また戻る——この往復を記憶ではなく docs で支えている。

公開に至ったのは3つのツールと、この紹介ハブ自身である。株式指標を読む日経225企業分析、都道府県別の人口を可視化する人口カルテ47、国会会議録をローカル LLM で要約する国会議事録 AI要約——いずれもフェーズ計画と進捗表を持ち、開発が中断しても再開できる形で進めてきた。止まっていた期間があっても「どこから再開すればよいか」で立ち止まった記憶はほとんどない。再開のたびに文脈を思い出す作業が消えたことが、並行を成立させている最大の要因だと感じている。

セッションの記録側——開発の終わりに判断とハマりを残す仕組みは、複数のリポジトリで /devlog や /devlog-session といったコマンドとして実在する。その詳細は別稿に譲る。

破綻パターン

この運用にも、決まった崩れ方がある。

一つ目は docs 更新の先送り。作業自体は進めたのに進捗表へ書き残さないと、次の再開で「どこまでやったか」を思い出す作業が復活し、二度手間になる。

二つ目はゲートなし再開。前回どこまで承認済みかを確認せず手を動かすと、承認範囲を踏み越えて進め、手戻りになる。再開時にまず進捗表を読む、を省いた瞬間に規約は空文化する。

三つ目は会話履歴頼み。「さっきの続き」をチャットの文脈に依存すると、履歴が流れた時点で文脈ごと消える。

対策はどれも同じで、「終わりに書く」を仕組みにすることに尽きる。人間の意志に任せず、セッションの終わりに docs を更新する操作をコマンド化しておく（記録側の具体は別記事で扱う）。

よくある質問

何プロジェクトまで並行できるか。 上限は記憶力ではなく、docs の質で決まると考えている。再開に必要な情報が docs に揃っているなら、本数自体はさほど問題にならない。具体的な上限を数字で示すことはしない——それは記憶に頼る運用の発想である。

優先順位はどうつけるか。 ゲート待ちの無いものから動かす。人間の承認待ちで止まっているプロジェクトは待ち時間なので、その間は自分が手を動かせるものに時間を使う。

まとめ

並行開発が止まるのは、意志や時間の問題である前に、文脈を記憶に預けているからだ。だから再開時に読むファイルをフェーズ計画と直近成果物の2点に固定し、承認履歴は進捗表という成果物側に残す。docs から現在地を復元できる構造にしておけば、どのプロジェクトを数週間空けても迷わず再開できる。記憶するのではなく、書いておく——それが並行を成立させる条件である。