GitHub Projectsで進捗管理する方法（2人チーム編）

2026年11月12日

この記事は、2人で制作するチームが、GitHub Projectsで作業の分担と進み具合を見える化する方法を説明します。個人制作の見積もりとExcelのガントチャートはUnity個人制作の進捗管理で扱っています。先にそちらを読んでおくと進めやすくなります。

対象は、GitHub Desktopでのコミット・プッシュ・プルを経験した方です。ゲームそのものの実装やGitの初期設定は扱いません。

GitHubの説明は2026年11月4日に確認したGitHub.comの現行Projectsが対象です。画面名は英語表記を併記します。以前のProjects (classic)向けの「Basic kanban」を選ぶ手順は使いません。画面が異なる場合は、各節の公式資料を確認してください。

1. 2人チームの計画例

作業の分け方（WBS）は、個人制作の記事と同じコイン収集ゲームを例にします。

AさんとBさんが、1人あたり週6時間、4週間取り組むとします。2人で使える時間は合計48時間です。ただし、相談、レビュー、環境調整もこの時間に含まれます。実装だけで48時間を埋めないようにします。

工数と期間を分ける

工数は実際に取り組む時間の量、期間は開始から終了までの日程の幅です。「3時間の作業」でも、授業が週2回なら数日間にまたがります。レビュー待ちの時間もあるため、工数をそのままカレンダー上の長さにしないようにします。

次の表は、2026年11月9日開始の架空の計画例です。日付は開始日・終了日とも含みます。IDは説明用で、実際のIssue番号ではありません。

ID	作業	担当	見積工数	開始予定	終了予定	先に必要な作業	完了条件
T1	ルール・共有環境をそろえる	A/B	各2h	11/09	11/10	なし	同じUnityバージョンで双方がプロジェクトを開け、ルールと担当を共有した
T2	移動・壁との衝突	A	3h	11/11	11/13	T1	左右移動でき、壁を通り抜けず、統合後に確認した
T3	コインPrefab・取得・得点	B	3h	11/11	11/18	T1	接触したコインが1回だけ消え、得点が1増える。T2と組み合わせて確認した
T4	得点UI・クリア・リトライ	A	4h	11/16	11/20	T2、T3の得点通知の約束	取得数が表示され、5枚でクリアし、リトライで0枚に戻る
T5	統合・通しプレイ	A/B	各3h	11/23	11/27	T2〜T4	別の人の環境でも、開始からリトライまで通して遊べる
T6	不具合修正	A/B	各2h	11/30	12/02	T5	発表を妨げる不具合が解消し、再現手順で再確認した
T7	ビルド・説明・配布確認	A/B	各2h	12/03	12/04	T6	配布先で起動し、操作説明に沿ってクリアできる

共同作業の「各2h」は2人合計4hです。表の見積もりはAさん16h、Bさん12h、合計28hです。残る20hは相談・レビュー・見積もりのずれなどに使う余裕とします。毎週の負荷も見て、特定の人に集中していたら分担や日程を変えましょう。

T3は移動の実装を待たず、仮のプレイヤーで準備できます。ただし、本当の完了確認にはT2との組み合わせが必要です。T4も、得点の受け渡し方を先に相談すれば、仮の値でUIを作れます。このように、着手できる条件と、完了できる条件が異なる場合があります。

図では週単位にまとめています。T3の準備は第1週から始まり、第2週に動作確認を終える想定です。

期限に間に合わないと分かったら

期限から逆算すること自体は役立ちます。ただし、必要な作業量を無視して日程だけ縮めると、確認の時間がなくなります。

例えばT3が2日遅れたら、T4への影響を確認します。仮の値でUIを進められるか、装飾を省けるか、担当を手伝えるかを相談します。テストを全部削るのではなく、「今回完成させる範囲」を小さくすることも選択肢です。

2. GitHubの道具をどう使い分けるか

道具	役割	記録する内容
GitHub Desktop	手元の変更をGitで記録し、GitHubとやり取りする	ブランチ、コミット、プッシュ、プル
Issue	1件の作業や不具合を相談・追跡する	目的、担当者、完了条件、困りごと
Pull Request（PR）	ブランチの変更を確認し、取り込む相談をする	変更内容、動作確認、レビュー
Projects	Issueなどをまとめて見渡す	状態、担当者、日程、優先度

今回は1つの作業に1つのIssueを基本とし、ProjectsにはそのIssueを登録します。PRのURLはIssueからたどれるようにします。同じ作業のIssueとPRを両方カードとして数えると、件数による進捗を重複して数えやすいためです。

Issueは「やること」、PRは「そのための変更」です。コードを書き終えただけで、Issueが完了したとは限りません。

3. 現行GitHub Projectsを作る

準備

チームのGitHubリポジトリでIssuesを使えるようにし、全員が対象リポジトリにアクセスできる状態にします。この記事では、代表者の個人アカウントでProjectを作る例にします。組織で管理する場合は、組織のProjectsから作成します。

Projectの編集権限と、リポジトリの権限は別です。Projectへ招待しただけでは非公開リポジトリのIssueは見えません。公式：アクセス権の管理

Tableを作り、Issueを追加する

1. プロフィール画像から Your profile → Projects → New project を開く。
2. Start from scratch の Table を選ぶ。
3. Project名に「コイン収集ゲーム」と入力して Create project を選ぶ。
4. 必要なメンバーを Settings → Manage access から招待し、更新担当には Write を付ける。
5. リポジトリのIssuesで、先ほどのT1〜T7に相当するIssueを作る。タイトルだけでなく完了条件も本文に書く。
6. Projectの最下行にある追加欄へ、IssueのURLを貼り付けてEnterを押す。

確認点は、カードを開くと元のIssueが表示されることです。作業名を文字だけで入力すると、Project内だけに存在するdraft issueになります。実際のリポジトリで追跡する作業には、既存IssueのURLを使うと区別しやすくなります。

参考：公式：Projectの作成、公式：項目の追加

最初に用意する項目

項目名	種類	この教材での使い方
Title	標準	行動と対象が分かるIssue名
Assignees	標準	主担当を1人決める。共同作業者はIssue本文に記載
Status	単一選択	Todo / In Progress / Done
Start date	Date	開始予定日
Target date	Date	現在の終了予定日
Estimate hours	Number	見積工数。共同作業は合計時間を入れる

日付フィールドはTableの右端の追加ボタンから New field → 名前を入力 → Date → Save で作れます。Numberは工数を記録したい場合に追加してください。完了条件はIssue本文に置き、同じ文章をProjectへ複製しない運用にします。公式：日付フィールド

Boardで状態を確認する

ビューの追加メニュー（New view）でビューを作り、名前を「作業状況」にします。View → Layout → Board を選び、列の基準を Status にします。元のTableを残しておくと日付などを編集しやすくなります。

この教材では状態を次の意味で使います。

状態	意味	移すタイミング
Todo	まだ着手していない	Issueと完了条件を準備した
In Progress	実装・レビュー・確認の途中	担当者が作業を始めた
Done	完了条件をすべて確認した	統合後の動作確認まで終えた

着手したカードをTodoからIn Progressへ、完了したカードをDoneへ移します。レビュー中も今回はIn Progressに含めます。慣れてから「In Review」を増やしても構いません。

列へ移動すると、基準にしたフィールドの値が変わります。同じIssueを別ビューで開き、Statusが一致することを確認しましょう。公式：ビューのレイアウト

Roadmapで日程を確認する

別のビューを追加し、名前を「制作日程」にします。View → Layout → Roadmap を選びます。

1. Date fields を開く。
2. Start date に同名の開始予定フィールド、Target date に同名の終了予定フィールドを指定する。
3. Tableで各Issueの日付を入力する。上の例なら年を含めた2026年の日付にする。
4. Roadmapに戻り、11月から12月初めが見える範囲に調整する。

日付フィールドが未作成なら、Date fieldsの New field から作成することもできます。バーが見当たらない場合は、日付の未入力、フィールドの選択、表示期間、絞り込みを確認してください。

Roadmapのバーをドラッグすると日付が変わる場合があります。閲覧のつもりで予定を変えないよう注意し、変更したらTableの値も確認します。公式：Roadmapのカスタマイズ

Roadmapは時間軸で作業を見渡すために使えます。ただし、バーを置くだけで、この教材の依存関係や担当者の空き時間まで自動計算されるとは考えないでください。先行作業が遅れたら、後続への影響をチームで見直します。

4. Issueの完了条件を動作で書く

例えば「コイン取得を作る」というタイトルだけでは、何を確認すれば終わりか分かりません。次の本文をコピーし、自分たちの仕様に合わせて変更してください。

## 目的
コインを取った結果がプレイヤーに伝わるようにする。

## 作業範囲
コインへの接触判定、コインの削除、得点の更新。
UI表示は別Issueで担当する。

## 完了条件
- [ ] プレイヤーが触れるとコインが消える
- [ ] 1枚につき得点が1だけ増える
- [ ] 同じコインで二重加算されない
- [ ] 統合したブランチで、移動と組み合わせて確認した

## 確認手順
1. ゲームを開始し、コインを1枚取る。
2. 得点が1増えることを確認する。
3. 同じ場所を通り直しても得点が増えないことを確認する。

## 分担・前提
主担当：Bさん。移動担当Aさんと、得点の受け渡し方を相談する。

## 実績・困りごと
開始日、終了日、確認結果、困った点をここへ追記する。

担当者が実装したら、GitHub Desktopで変更を記録・プッシュし、PRで確認を依頼します。同じSceneを同時に編集しないように、AさんはメインScene、BさんはコインPrefabなど、編集範囲も先に相談しておきましょう。

この教材では、レビュー → マージ → 統合後の動作確認 → Issueを閉じるという順番にします。PR本文には Refs #実際のIssue番号 と書いて関連を示し、動作確認が終わってからIssueを手動で閉じる運用です。Refsには自動で閉じる指示はありません。

Closes #番号を使う場合は挙動が異なります。PR本文の対応キーワードは、既定ブランチを対象とするPRで解釈され、マージ時にIssueを閉じるため、統合後の確認がまだでも閉じられることがあります。公式：PRとIssueのリンク

自動化の設定も確認する

Project右上のメニューから Workflows を開きます。公式資料では、初期状態で「Issue/PRが閉じられたらDone」「PRがマージされたらDone」のワークフローが有効になると説明されています。テンプレートや既存設定もあるため、自分たちのProjectで確認しましょう。

この教材の手動確認を徹底するなら、必要に応じてDoneへ移す自動化を無効にし、確認後に担当者がDoneへ移します。自動化を使う場合は、Issueを閉じる前に完了条件を確認するルールにします。StatusとIssueのOpen/Closedは別の状態であり、連動は設定に依存します。 公式：組み込みの自動化

5. 毎日5分で更新する

授業や作業の始まりにBoardを開き、各自が次の3点を話します。

• 前回、何が確認できたか。
• 今回、何を終える予定か。
• 困っていること、ほかの人を待っていることは何か。

終わりに状態を更新し、困りごとはIssueへ残します。「レビュー待ち：Aさんに依頼済み」のように、誰の何を待っているかを書きましょう。

毎週末はRoadmapも見て、今の終了見込みを更新します。元の計画は日付付きの表やIssueコメントに残します。例えば「当初11/18 → 見込み11/20。得点の二重加算の修正に時間が必要。UIの仮表示は先に進める」と記録すれば、変更の理由が分かります。

進捗率は補助として使う

この演習では、曖昧な「90%できた」より、完了条件のチェックと残作業を重視します。7件中3件がDoneなら、件数ベースでは約43%です。ただし、作業の大きさが違うため、開発全体の43%が終わったと断定はできません。

「残りは統合確認だけ」でも、そこで不具合が見つかることがあります。率と一緒に、残っている確認、終了見込み、助けが必要かを伝えましょう。

6. 計画がうまくいかないときの直し方

起きていること	見直すこと
「UI作成」がいつまでも終わらない	表示・更新・クリア・リトライへ分け、完了条件を決める
1人だけ作業がたまる	担当者ごとの予定と工数を見て、分担・順番を調整する
バグが出るたびに予定が崩れる	早く小さな通しプレイを行い、修正の余裕を確保する
更新に時間がかかり、誰も見ない	必須項目を担当・状態・日付に絞り、作業時に5分だけ更新する
ExcelとProjectsで日付が違う	日々の更新先をProjectsに決め、Excelは計画記録として残す
期限までに全部は作れない	必須の遊びを残し、装飾や追加機能を次回へ回す

計画は守れたかどうかを責めるためだけのものではありません。遅れを早く見つけ、相談して完成までの道筋を変えるために使いましょう。