GitHub Projects チーム運用チェックリスト｜担当・優先度・見積もり

2024年10月19日2026年11月13日

1. 役割を押し付けず、窓口を決める

Projectの所有者・管理者であることと、チームのすべての判断や実装を担うことは別です。代表者は設定と共有の窓口になり、作業の分担や優先順位はチームで話して決めます。

役割	確認すること
代表者・設定担当	Project作成、共有権限、ビュー、Workflowsを整える
各Issueの主担当	着手、実装、確認、困りごとの記録を更新する
レビュー担当	PRの差分と動作を確認し、結果を残す
チーム全員	完了条件、優先順位、担当変更や遅れへの対応を相談する

2. 開始前のチェック

• 2人ともProjectと元のIssueを開ける。
• 更新担当にProjectのWrite権限がある。
• リポジトリのCollaboratorとProjectへの招待を別々に確認した。
• 1件の作業に1件のIssueがあり、主担当と完了条件が書かれている。
• DoneとClosedをどのように連動させるか決め、Workflowsを確認した。

Issueの担当者はリポジトリ側の条件に基づきます。Projectに招待されていることだけを、Assigneesに設定できる条件と考えないでください。

3. 優先度は必要になってから足す

作業順が口頭だけでは分からなくなったら、ProjectにPriorityというSingle selectフィールドを追加し、High・Medium・Lowなどの選択肢を用意します。フィールド名と値はチーム内でそろえます。

優先度の例	判断基準
High	遊びの成立、起動、進行を妨げる問題など、今回の完成に必須
Medium	今回入れたいが、必須部分を先に確認できるもの
Low	装飾や追加機能など、時間が足りなければ次へ回せるもの

重要度だけで着手順が決まるとは限りません。ほかの作業の前提になるものや、相手を待っているものも確認します。

4. 見積もりの単位を統一する

時間を管理するなら、NumberフィールドのEstimate hoursなどを使います。1人が2時間なら2、2人がそれぞれ2時間なら合計4というように、合計工数を入れる運用にそろえると比較しやすくなります。

ストーリーポイントは時間とは別の相対的な大きさの尺度です。授業で時間を見積もる場合は、ポイントと時間を混ぜず、時間に絞って構いません。

• 実装だけでなく、レビューや確認の時間も見込んだか。
• 見積時間と、カレンダー上の開始・終了予定を区別したか。
• 担当者ごとの作業量が偏っていないか。
• 予想外の修正の余裕があるか。

5. 自動化を追加する前に確認する

自動化	確認すること
Item added to project	新規項目のStatusをTodoにしたいか
Item closed	Issueを閉じたとき、どのStatusにするか
Auto-close issue	Doneに変えた時点でIssueを閉じてよいか
Auto-add to project	どのリポジトリの、どの条件の項目を今後追加するか

本編②③は、Item closedを有効、Auto-close issueを無効とし、確認後にIssueを閉じる運用です。別の運用へ変える場合は、チーム全員に完了のタイミングを説明します。

Auto-addを有効にしただけでは、すでにある対象項目が一括で追加されるわけではありません。既存分はAdd item from repositoryなどで追加し、今後作成・更新された項目の追加をAuto-addで扱います。作成時のImportとも区別してください。

6. 毎回・毎週の確認

タイミング	確認すること
作業開始	今回終えること、困りごと、レビュー待ち
作業終了	Status、確認結果、相手への依頼
週末・区切り	現在の終了見込み、担当の偏り、次へ回す範囲
担当変更・欠席	引き継ぐIssue、未確認の点、Assigneesの更新

口頭で相談したことも、決まった内容をIssueに短く残すと、欠席した人や後から見る人が追いやすくなります。

7. 運用が重くなったら減らす

更新されない項目が増えたら、Title・Assignees・Statusへ戻してみましょう。入力欄を増やすことより、次の行動を共有できることを優先します。

公式資料

• Projectのアクセス権
• Issueの担当者
• フィールドの種類
• 組み込みの自動化
• 項目の自動追加

関連する記事