型付き辺: 出 3 / 入 1
ADR-0018: TODO 管理の Phase・優先度・レイヤー 3 軸グルーピング — GitHub Issues 移行を保留する判断
- Status: Accepted (旧形式「## ステータス: 採用済み」より転記)
- Mode: Light (内容から推定・旧 README 一覧より移設)
- Kruchten Type: Executive
- Scope: ops
- Implementation Status: Done (TODO 3 軸 Markdown 維持運用中)
Kruchten Type は ADR-0031 (2026-05-13) で遡及追加。分類根拠は ADR-0031 §決定セクションおよび docs/adr/README.md の Kruchten 3 分類ガイドを参照。 Status / Mode / Scope は 2026-06-11 に遡及追加 (ADR-0031 corrigendum パターン)。出典: Status = 旧形式「## ステータス」節の機械転記 / Mode = 旧 README §既存 ADR 一覧の推定値 (git 履歴) / Scope = ADR-0049 4 層分類の遡及付与 (PR レビューで確定)。
ステータス: 採用済み
コンテキスト
開発案件が 100 件を超えた時点で、管理方法を見直す必要が生じた。一般的なチーム開発では GitHub Issues / Linear / Jira といったチケット管理ツールを使うが、現時点では 1〜2 名体制のため、ツールの運用コストが価値を上回る可能性がある。
選択肢:
- 案A: GitHub Issues に全案件を移行（チーム標準）
- 案B:
docs/_internal/TODO_future.mdに Markdown テーブルで継続管理、3 軸（Phase / ステータス / レイヤー）でグルーピング
決定
案B を採用する。 TODO_future.md を単一ファイルで維持し、以下の 3 軸で案件を整理する。
| 軸 | 意味 | 例 |
|---|---|---|
| Phase (P1〜P4) | ビジネス進展の段階 | P1=現行強化, P2=FP&A充実, P3=商用化準備, P4=長期 |
| ステータス | 進捗状態 | 未着手 / 仕様書完了 / MVP 完了 / ✅ 完了 |
| レイヤー | エンジニアリング担当領域 | UI / Domain / Data / Infra / Report 等 |
GitHub Issues への移行はチームが 3 名以上になった時点で再検討する。
理由
- 1〜2 名体制では、GitHub Issues の「担当者アサイン・マイルストーン管理・通知設定」のオーバーヘッドがメリットを上回る
TODO_future.mdは Claude Code から直接編集・検索できるため、仕様書作成や開発作業と同じセッションで案件管理ができる- Phase × レイヤーの 2 軸で見ることで、「次のフェーズで UI 開発者を採用した場合に任せられる案件リスト」が即座に抽出できる
- 単一ファイルのため
git diffで変更差分が追跡でき、PRレビューのコンテキストとしても機能する
結果・影響
- ポジティブ: ツール切り替えなしに案件管理・仕様書作成・実装を同一コンテキストで継続できる
- ポジティブ: レイヤー別の未着手件数が一目でわかり、採用計画（どのスキルを持つ人材を採るか）の根拠になる
- ネガティブ: 2 つのワークスペース（main / sub）が同ファイルを編集するとコンフリクトが最も起きやすい（CLAUDE.md に「TODO_future.md は sub 専属」として規約化）
- 移行トリガー: チームメンバーが 3 名以上 かつ GitHub Projects や Linear の利用コストが許容できる時点で移行を再検討
Confirmation (準拠確認 / Fitness Function)
本セクションは ADR-0036 (Accepted 2026-05-14) で遡及追加された。ADR-0031 パターン (業界標準準拠メタデータ後付け = 誤字修正範疇) に準拠する遡及で本文の意思決定内容は不変。
- 検証手段: N/A (ガバナンス ADR で実装不要のため継続検証対象外)
- 実行頻度: —
- 違反時の対応: —