リポジトリの「墓場」を整理せよ：プロジェクト終了後に潜むリスクと、プロが実践する最強の断捨離術
GitHubのダッシュボードが「何年も前に終わったプロジェクト」で埋め尽くされていないか？
多くのチームが陥る罠がある。「とりあえず残しておけばいつか役に立つかもしれない」という安易な保存だ。だが、それは技術的負債どころか、組織のセキュリティ・ガバナンスにおける「負の資産」でしかない。
今日は、テックリードの視点から、GitHubリポジトリの「アーカイブ」と「デリート」の境界線、そして開発効率を極限まで高めるための「リポジトリ・ライフサイクル管理」の極意を伝授する。
—
1. 「削除」か「アーカイブ」か：判断のロジック
まずは明確な基準を叩き込んでくれ。この判断に迷う時間は、エンジニアのキャリアにおいて無駄でしかない。
Archive（アーカイブ）すべきケース
- 「参照価値」が残っている: 数年後の監査や、類似プロジェクトの設計参考になる可能性がある。
- 依存関係が生きている: コンテナイメージやパッケージが他で利用されており、破壊的な影響が出る。
- 法規制・コンプライアンス: 過去のコード保存義務がある。
Delete（デリート）すべきケース
- 機密情報の混入: 過去にSecretsをコミットしてしまったリポジトリ。GitHubの履歴を完全に消し去る唯一の方法は削除（またはRepo Purge）だ。
- 学習用・実験用の使い捨てコード: 過去のチュートリアルや、Proof of Concept (PoC) で終わったゴミコード。これらは「ノイズ」であり、検索の妨げになる。
- 放置されたフォーク: 派生元のリポジトリが死んでいる、あるいはupstreamに追従する意志がないもの。
—
2. 放置されたリポジトリがもたらす「死の毒」
放置リポジトリは、セキュリティの観点から「攻撃者の踏み台」になり得る。
古い依存ライブラリ（`package-lock.json`や`Gemfile.lock`）には、CVE（脆弱性）が山ほど眠っている。GitHubは自動でDependabotのアラートを飛ばすが、放置リポジトリでそれが鳴り響くと、本当に重要なアラートまで埋もれてしまう。
【鉄則】プロジェクト終了時のREADME追記ルール
アーカイブする前には、必ずルートの`README.md`を更新せよ。次のテンプレートをCIの一部（または手動の完了チェックリスト）に組み込むんだ。
[プロジェクト名] (ARCHIVED)
> Status: アーカイブ済み
> 最終更新日: 202X-XX-XX
> 代替プロジェクト: [リンク]
> 連絡先: [チーム名/Slackチャンネル]
このプロジェクトは現在メンテナンスされていません。
現在のプロダクション環境は `[リポジトリURL]` へ移行しました。
—
3. 生産性を爆速化する「GitHubハック」
隠れたキーボードショートカット
ブラウザ上で`?`キーを押せば全ショートカットが表示されるが、これだけは脳に刻め。
- `w`: リポジトリのブランチ切り替え（これを知らないとマウスで無駄なクリックが発生する）
- `t`: ファイル検索モード（爆速でコードベースを徘徊できる）
- `gc`: コード検索からIssue検索へ瞬時に切り替え
絶対に入れるべき神ブラウザ拡張
- [GitHub File Icon](https://github.com/skratchdot/github-file-icon): ファイル形式をアイコンで視認。ディレクトリ構造の理解速度が3倍になる。
- [Octotree](https://www.octotree.io/): 左サイドバーにディレクトリツリーを表示。巨大なモノレポを扱うなら必須。これなしでのコードレビューは眼精疲労の元だ。
—
4. プロの「設定ファイル」管理ベストプラクティス
チーム開発において、個々人の環境依存は最大の敵だ。GitHubの`.github/`ディレクトリを活用し、チーム全体で設定を共有せよ。
`.github/CODEOWNERS` の最適化
チームの責任範囲を明確にし、PRのノイズを減らす。
核心的なコアロジックはシニアエンジニアが必ずレビュー
/core/ @team-core-leads
ドキュメント変更は自動承認など、柔軟な設定が可能
/docs/ @tech-writer-team
`.github/workflows/cleanup.yml` （自動アーカイブ用スクリプトのヒント）
放置されたブランチを自動で掃除するCIを組むことも検討すべきだ。
name: Stale Branch Cleanup
on:
schedule:
- cron: ‘0 0 1’ # 毎週月曜実行
jobs:
cleanup:
runs-on: ubuntu-latest
steps:
- name: Delete stale branches
# 30日以上更新がないブランチを削除するロジックを実装
run: |
git fetch –prune
# 現場で使う場合は、dry-runでテストしてから適用せよ
—
最後に：テックリードからの提言
「整理整頓」は、ただの事務作業ではない。
リポジトリを整理し、アーカイブと削除の基準を明確にすることは、チームの「認知負荷」を下げるための戦略的な投資だ。
必要な情報に最短でアクセスできる状態を作る。それが、最高峰のパフォーマンスを生むための第一歩だ。
さあ、今すぐGitHubの「Repositories」ページを開き、最初の1つをアーカイブすることから始めよう。それが、明日の君の生産性を変える。