すべての放置されたリポジトリは、かつては午前2時の情熱の対象だった。そのリズムは、身に覚えがあるはずだ。真夜中あたりにアイデアが閃く。コーヒーが冷める前にリポジトリの雛形を作る。それから11日間、ついに解けたという万能感とともに、狂乱的なエネルギーでコードをプッシュし続ける。そしてスプリントが終わる。あるいはボイラーが壊れる。もしくは、単に火曜日の夜にコードを開いたとき、その熱量がどこかへ消え去っている。
ほとんどの開発者が、この重みを抱えている。それは後悔というよりは、「もし〜していたら」という静かなリストのようなものだ。GitHubのプロフィールは、善意のアーカイブと化す。Side Project Cemeteryの作成者は、この問題に正面から向き合ったものを作った。そのツールは、あなたの公開プロフィールを月明かりに照らされた墓場へと変える。そこでは、すべての放置されたリポジトリに墓石と没年月日、そして時にはジョークが刻まれる。
墓場は広がる
サイドプロジェクトが死ぬ理由は、些細なものだ。新しいフレームワークを学ぶ必要があったから、CLIツールを作った。スプレッドシートを自動化したかったから、Pythonのラッパーを書いた。プロトタイプが問題を解決するのに十分なほど機能すれば、それで終わりだ。待っているユーザーもいなければ、迫りくる締め切りも、進捗を求めるマネージャーもいない。外部からのプレッシャーがなければ、モチベーションがすべての重荷を背負わなければならない。モチベーションが下がれば、プロジェクトは凍結する。
典型的な開発者のGitHubを覗けば、そのパターンが見て取れる。あるリポジトリの、錆びついたような色のコントリビューショングラフ。 「TODO: テストを書く」で終わるREADME。6ヶ月前に崖から落ちたかのように途絶えたコミット履歴。私たちはこれらのリポジトリを、恥ずかしい記念品のように扱う。未完成のコードは隠すべきものであるかのように、素早くスクロールして通り過ぎる。Side Project Cemeteryは逆の立場を取る。こう言うのだ。「適切に葬ろう。認めよう。そして、もし望むなら、一つだけ蘇らせよう」と。
墓場の仕組み
インターフェースは無骨でシンプルだ。GitHubのユーザー名を入力する。アプリはGitHub REST APIにクエリを送り、すべての公開リポジトリを取得し、過去180日間にプッシュがないものをフィルタリングする。各結果は墓となる。誕生年、没年、そしてリポジトリの詳細から生成された碑文が表示される。
碑文の中には、穏やかなものもある：
- JavaScriptで記述。コールバックの使いすぎにより死亡。
歴史をより寛大に解釈するものもある：
- 死んでいない。2025年から猛烈に保留中なだけだ。
より個性を出したい場合は、オプションのGemini連携を有効にできる。AIがリポジトリの言語とコンテキストを読み取り、テンプレート的ではなく、そのプロジェクト特有のカスタム碑文をドラフトする。また、ElevenLabsとの連携オプションもあり、追悼の辞を読み上げることができる。自分の放置したAPIラッパーが、厳かなナレーターの声で読み上げられるのを聴くまでは、単なるギミックのように思えるだろう。しかしその瞬間、不条理さが罪悪感を打ち破る。そして、その罪悪感こそが、リポジトリを埋めたままにしていた正体なのだ。
Rekindle：圧倒される気持ちに抗うボタン
墓場は、このプロジェクトの半分に過ぎない。真の機能は、それぞれの墓石の下に隠されている。それは「Rekindle」ボタンだ。それをクリックすると、アプリはREADMEを読み取る。プロジェクトの目的について書かれた内容を解析し、既存のコードと照らし合わせ、なぜ自分がこれに情熱を注いでいたのかを思い出させるための短いピッチ（紹介文）を書き上げる。そして、今夜すぐに取り組める、小さく具体的なアクションを一つ提示して終わる。ロードマップではない。リファクタリング計画でもない。たった一つのタスク。5分間の作業だ。
これが重要なのは、古いプロジェクトに戻る際、最も難しいのはコーディングではないからだ。自分がどこまで進んでいたかを思い出し、中断した自分を許すことなのだ。長く死に絶えたプロジェクトは、途方もなく巨大なものに感じられる。アーキテクチャを理解し直すだけで3時間はかかるだろう、と思い込んでしまう。Rekindleボタンはその思い込みを、たった一つのToDoへと圧縮する。目標は、次のコミットが「あと5分」の距離にあると感じさせることだ。一度でも履歴に差分（diff）が刻まれれば、勢いは戻ってくるものだ。
なぜこれほどシンプルなスタックなのか
技術的に言えば、このプロジェクトは自らの教えを実践している。バニラのHTML、CSS、JavaScriptで構築されている。GitHub REST APIを使用している。サーバーも、ビルドステップも、メンテナンスすべき「今月の流行りのフレームワーク」もない。GitHub Pagesにホストして、そのまま立ち去ることさえできる。
そのミニマリズムは、怠慢ではなく機能だ。古いコードを蘇らせるためのツール自体が、脆弱な依存関係のツリーに依存すべきではない。もし作成者がSide Project Cemeteryを6ヶ月間放置したとしても、この墓場自体が新たな住人になることはない。コードは読みやすいまま。更新すべきwebpackの設定も、パッチを当てるべきDockerイメージもない。これは、ツール作りにおける「抑制」への静かな主張だ。時には、静的サイトとAPIキーだけで十分なこともある。
ボタンが実際に機能する時
開発者は、開発中に自分自身の「死んだプロジェクト」に呼びかけられたと認めています。あるプロジェクトは、一晩限りの執着によって興奮のままに書き殴られ、そのまま忘れ去られていました。そこで、そのプロジェクトに「Rekindle」ボタンを使ってみました。アプリがREADMEを読み込み、前提条件を思い出し、完了させるべき具体的なタスクを提示してくれたのです。それはうまくいきました。その週のうちに、欠けていたピースをリリースすることができたのです。
これこそが、このツールの核心となる主張です。情熱は死ぬのではありません。ただ、うたた寝をしているだけなのです。放棄されたリポジトリの多くは、エンジニアリングの失敗ではありません。コンテキスト（文脈）の喪失なのです。その糸（思考の筋道）があなたの頭の中にしか存在していなかったために、あなたの意識が他の糸へと移ってしまい、糸を見失ってしまったのです。Side Project Cemeteryは、そのコンテキストを外部化します。READMEを読み取ることで、過去の自分をゼロから再構築する必要がなくなるのです。
真の指標は、いくつのリポジトリを復活させたかではありません。どれほど多くのリポジトリに対して「気まずさ」を感じなくなるか、です。この墓場は、あなたが準備できるまで、それらが休める場所を提供します。そして準備が整ったとき、ツールはあなたにシャベルと、たった一つの指示を渡します。「ここから始めよう」と。
アイデアを埋めたままにしておくのは、もうやめましょう。
墓場を https://pyaroslav.github.io/side-project-cemetery/ で訪れるか、Dev.to で開発の全ストーリーを こちら から読んでください。