個人のタスクを GitHub issue で管理する — Phase と Status の2軸と、状態遷移のルール
私は個人のタスクを GitHub issue で管理しています。アプリ開発、ブログ、会社の手続き、家の用事の一部などを、1つのリポジトリの issue に集めています。進行の管理には GitHub Projects を使い、「いつやるか」の Phase と「いまどういう状態か」の Status の2つのフィールドで見ています。
この記事は、その2つのフィールドの値の意味と、どのタイミングで遷移させるかのルールの紹介です。日々の issue 操作は Claude Code が行うことが多いので、ルールを文書に置き、Claude Code もそれを読んで判断する形にしています。Status に選択肢を1つ追加したときの API の仕様と、Claude Code に任せるときの注意点も後半に書いています。
全体像
- タスクは全部 GitHub issue。種類 (epic / ops / task / stock) と領域 (app / blog / accounting …) をラベルで分類
- 全 issue は GitHub Projects のボードに自動で追加され、Phase と Status の2フィールドで管理
- 完了処理は issue の close。close をきっかけに Phase と Status が自動で Done になる
運用ルールとして「issue が closed ⇔ Status=Done ⇔ Phase=Done」の三点を常に一致させています。この一致は自動化に任せていて、Phase は自作の GitHub Actions ワークフロー、Status は Projects の組み込みワークフローが担当しています。
Phase — いつやるか
自作のフィールドです。ボードを Phase でグルーピングすると、カラムがそのまま「今やること・次にやること・いつか」の一覧になります。
| 値 | 意味 |
|---|---|
| Now | 今取りかかる (取りかかっている) もの |
| Next | Now の次に着手するもの |
| Later | いつかやる。優先度は低い |
| Ongoing | 終わりのない継続業務 (ops) やアイデア置き場 (stock)。カラムに常駐 |
| Done | 完了。close で自動設定 |
Now / Next / Later は優先度の判断そのものなので、私が直接動かすことも多いです。Claude Code に任せている操作 (起票・着手) でも設定はしますが、私が変えた値を Claude Code が戻すことは基本的にしません。
Status — いまどういう状態か
Projects の組み込みフィールドに、Writing を1つ足した5値です。
| 値 | 意味 |
|---|---|
| Todo | 未着手。issue を作ると自動設定 |
| In Progress | 作業中 |
| Writing | 本体の作業は完了し、ブログ記事の執筆・公開だけが残っている |
| Blocked | その issue の中では解決できない待ちがある (待ちの理由は issue のコメントに書く) |
| Done | 完了。close で自動設定 |
Writing は、このブログの記事が「作業した issue の実作業が終わったあとに書く」流れになっていて、記事を書き終えるまで issue を close したくない期間があるために足した値です。Blocked は理由別に選択肢を増やさず、理由はコメントに残す運用にしています。
状態遷移のルール
図の点線の Writing は、記事化の予定がある issue だけが通る経路です。運用ルールは次のとおりです。
- 新規作成 → Status は Todo (自動)。Phase はその時の状況で Now / Next / Later を設定 (ops・stock は Ongoing)。起票を Claude Code に任せたときは Claude Code が判断して設定
- 作業開始 → Status を In Progress に、Phase を Now に
- 実作業が完了し、記事化の予定がある → Status を Writing に (Phase は Now のまま)。ここでは close しない
- 記事の公開まで完了 → issue を close (Status と Phase は自動で Done)。記事化の予定がなければ、実作業の完了で close
- その issue では解決できない待ちが発生 → Status を Blocked に。解消したら In Progress に戻す
Claude Code との分担
起票 (ラベルと Phase の設定)、着手時の Status / Phase の更新、完了時の close は、作業を任せている Claude Code がそのまま行います。私が直接触るのは主に Phase の優先度の入れ替えです。
このルールは、タスク管理用リポジトリの README と Claude Code のメモリの両方に置いていて、どのセッションでも同じ判断になるようにしています。Writing を足したのは、以前は実作業が完了したら issue を close するルールにしていて、ブログに書きたい issue がたまってくると、どれが記事待ちなのか分からなくなってきたためです。「実作業が終わっても記事を書き終えるまで close しない」を、値としてもルールとしても持たせた形です。
選択肢の追加を Claude Code に任せたときの注意点
Writing の追加は Claude Code に任せました。このときに関わってくる GitHub Projects の仕様が2つあります。UI から追加する分には関係しませんが、Claude Code に任せると API 経由の操作になるため、同じ構成の方は知っておくとよい仕様です。
updateProjectV2Fieldは選択肢を全置換する — 「追加」のつもりでも既存の選択肢ごと作り直しになり、内部 ID が全部変わって、全 issue の Status 値が消えます。うちでは「open で作業中なら In Progress、closed なら Done」の規則で当日中に復元しました- 組み込みワークフローは選択肢を ID で参照している — 参照先の ID が消えると設定値が空になり、ワークフローは自動で OFF になります。エラーの通知はなく、Workflows 画面に赤い「!」が付いて、開くと値の欄が「A value is required」と空欄になっています
うちで止まっていたのは Status を参照する3つ (Item closed → Done / Item added → Todo / Auto-close issue) で、close しても Done にならない・新しい issue に Todo が付かない、という形で三点一致が崩れていました。復旧は Workflows 画面で値を選び直して ON にするところまでで、プロジェクトのオーナー権限が必要なので私がやりました。そのあと Claude Code が検証用の issue を1件作り、作成で Todo・close で Done・Done に変えると close、の3方向が動くことを確かめています。
ワークフローの ON / OFF は GraphQL で一覧できるので、選択肢を触ったあとはここを見ておくと安心です。
query {
user(login: "<owner>") {
projectV2(number: 1) {
workflows(first: 20) {
nodes { name enabled }
}
}
}
}
教訓は2つです。選択肢の変更は Web UI から行うこと。選択肢を作り直したときは、それを ID で参照している自動化の確認と動作検証までを1つの作業と考えることです (Phase 側の GitHub Actions も選択肢の ID をコードに直書きしているので、Phase の選択肢を作り直せば同じことが起きます)。
まとめ
Status まわりは今もこの5値で回していますが、これはスモールスタートの形です。追加した当時はブログの本数が少なく、Writing 1つで足りていました。最近は記事の下書きがたまってきたので、「下書きは書き終わった」「レビュー中」「まだ取りかからない」のような、Writing の中をもう少し分けた状態を増やしたいなと思ってきているところです。
Phase 側は、いま Now に31個たまっています。数字だけ見ると多いですが、そこまで困ってはいません。何をやったらいいのか、次に何をやるのかは、まだ把握できている状況です。やりとりの内容を忘れてしまっても、issue ごとに Claude Code のセッションを1つ立てて進めているので、そのセッションの履歴を開けば思い出せます。履歴の並びはやりとりした順なので、新しいところから見ていけば、だいたい優先度の順にもなっています。
2軸のフィールドと自動化、それにルールの文書化という小さな仕組みですが、同じように個人のタスクが増えてきた方の参考になればうれしいです。
参考リンク
一次情報 (公式ドキュメント・上流の議論):
- Using the built-in automations (GitHub Docs) — Projects の組み込みワークフローの公式ドキュメント。「closed になったら Status を Done にする」などの仕組みはここに載っています
- Using the API to manage Projects (GitHub Docs) — GraphQL API で Projects を操作する公式ガイド。item のフィールド値の更新はここにある方法で安全にできます (選択肢そのものの変更は UI からが安心です)
- Adding new options to ProjectV2 fields via the API clears existing issue assignments (GitHub Community Discussion #198803) — 本文の「注意点」と同じ報告。
updateProjectV2Fieldは既存の選択肢を全置換する仕様で、既存の割り当てが消えるという内容です。回避策として「既存の選択肢を読み取ってから、全部を含めて送る」ことが挙げられています