GitHub IssuesとProjectsの使い方：やることを管理する

外注エンジニアBへの修正の依頼がメールとチャットに散らばり、どれが終わったのか分からなくなることがあります。GitHubには、コードの隣にやることを書いておく場所があります。IssueとProjectsです。サンプル料理教室の「料金表の修正」と「夏の教室の追加」を例に、書き方から表やボードに並べるところまで順に書きます。読み終わると、自社でGitHubのIssueを使うのか、kintoneやスプレッドシートのままでいいのかも決められます。

この記事の内容

1. 先に答えると
2. IssueとProjectsの関係
3. 料理教室で回す流れ
4. Issueの作り方
5. Projectsの作り方
6. コードを触らない人をどう入れるか
7. ghで操作する
8. 他の手段で足りる場面
9. 公開リポジトリのIssueに個人情報を書かない
10. できないことと、その代わり
11. よく詰まるところ
12. 次に読む

先に答えると

Issueは、やることや不具合を1件ずつ書く掲示板です。Projectsは、そのIssueを表やボードに並べて進み具合を見る画面です。Issueだけでも回せます。件数が増えて一覧で見たくなったらProjectsを足します。

• どちらもGitHubのFreeで使える（2026年11月時点）
• 非公開リポジトリのIssueは、権限のある人にしか見えない
• OrganizationのReadの権限があればIssueを書ける。ただしコードも読める
• プルリクエストの説明に Closes #12 と書くと、合流したときにIssueが閉じる
• コードに関係ない仕事の管理なら、無理にGitHubへ寄せなくていい

IssueとProjectsの関係

リポジトリ（ファイルと変更履歴の置き場）には「Issues」というタブがあります。ここに1件ずつ書くと、#12 のような番号がつきます。Issueはリポジトリの中にあります。

Projectsは、Issueとプルリクエストを集めて並べる画面です。プルリクエスト（Pull Request、PR）は、変更を本筋に合流させる前に確認を頼む機能です。Projectの中で項目を動かしても、元のIssueとつながったままです。

比べるところ	Issue	Projects
何か	やることを書いた1件	Issueを並べて見る画面
置き場所	リポジトリの中	Organizationか個人の下
見るもの	説明、コメント、担当、ラベル	表、ボード、ロードマップ
複数のリポジトリ	1つのリポジトリに属する	Organizationの複数のリポジトリのものを集められる
最初から要るか	要る	件数が増えてから

サンプル料理教室なら、website のIssueに「料金表の修正」を書き、reservation-mail のIssueに「予約確認メールの文面の修正」を書きます。Projectを1つ作れば、両方を同じボードで見られます。

料理教室で回す流れ

受付Aが電話で「料金表の金額が違う」と気づいたところから始めます。

段階	誰が	やること
1	受付A	Issue「料金表の修正」を書く
2	代表	担当を外注エンジニアBにし、ラベルをつける
3	B	枝を切って直し、プルリクエストを出す
4	代表	差分を見て承認する
5	B	合流する。Issueが自動で閉じる

受付Aはコードを触りません。困っていることを書くだけです。代表は優先順位を決めます。Bはやることが1か所で見えます。実際に運用していると、依頼をメールからIssueに移すだけで「あの件どうなりましたか」の往復がだいぶ減ります。

Issueの作り方

1. リポジトリ website を開く
2. リポジトリ名の下の「Issues」を押す
3. 「New issue」を押す
4. テンプレートの選択が出たら「Open a blank issue」を押す
5. 「Title」に 料金表の修正 と入れる
6. 説明の欄に内容を書く
7. 「Submit new issue」を押す

説明には、何が困っているか、どこを見たか、どうなってほしいかの3つを書けば足ります。

料金表の「和食の基本」が6,000円のままです。
4月から6,500円に変わっています。
menu.html の該当の行を直してください。

右の欄で担当などを決めます。ただし権限によって、触れる項目が変わります。

項目	何か	料理教室の例	要る権限
Assignees	担当者	外注エンジニアB	Triage以上
Labels	分類の札	料金、急ぎ	つけるのはTriage以上、作るのはWrite以上
Milestone	締切のあるまとまり	夏の教室の公開	作るのはWrite以上
Projects	載せる先のProject	ホームページの修正	Projectの権限

全部埋める必要はありません。最初は担当だけで足ります。ラベルが要るのは、件数が増えて絞り込みたくなってからです。Milestoneは、夏の教室のように関連する数件を同じ締切で動かすときに使います。

プルリクエストと繋げる

プルリクエストの説明かコミットのメッセージに Closes #12 と書くと、Issueとつながります。合流すると、Issueが自動で閉じます。手元で動かした表示です。送り先は練習用の場所で、本物のGitHubには送っていません。

$ git switch -c fix-menu-price
Switched to a new branch 'fix-menu-price'
$ git add menu.html
$ git commit -m "料金表を修正" -m "Closes #12"
[fix-menu-price 709eea0] 料金表を修正
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log -1 --format='%h%n%s%n%n%b'
709eea0
料金表を修正

Closes #12

$ git push -u origin fix-menu-price
To ../website.git
 * [new branch]      fix-menu-price -> fix-menu-price
branch 'fix-menu-price' set up to track 'origin/fix-menu-price'.

-m を2回つけると、2つ目がコミットの本文になります。Gitにとっては Closes #12 はただの文字です。意味を読むのはGitHubです。

使える言葉は次の9つで、後ろに番号を書きます。

意味の近いもの	言葉
閉じる	close、closes、closed
直す	fix、fixes、fixed
解決する	resolve、resolves、resolved

別のリポジトリのIssueなら Fixes sample-cooking/website#12 のように書きます。

注意が1つあります。効くのは、既定の枝（普通は main）に合流するプルリクエストだけです。add-summer-class のような別の枝へ合流しても、Issueは閉じません。

閉じる、消す

終わったIssueは閉じます。閉じても検索で見られるので、消す必要はありません。経緯が残っていることに価値があります。

消せるのは、個人のリポジトリなら持ち主です。Organizationでは、ownerが削除を有効にしたうえで、adminかownerの権限の人だけが消せます。Issueの右の欄の「Delete issue」を押し、「Delete this issue」で確定します。消すと元に戻せないので、間違って個人情報を書いたときの手段と考えます。

Projectsの作り方

Organization sample-cooking の下に作ります。

1. 右上のプロフィール写真を押す
2. 「Organizations」を押す
3. sample-cooking を押す
4. 組織名の下の「Projects」を押す
5. 「New project」を押す
6. 「Start from scratch」の「Board」を押す
7. 「Project name」に ホームページの修正 と入れる
8. 「Create project」を押す

テンプレートから始めることもできます。GitHubが用意したものが選べます。迷うなら白紙のBoardで足ります。リポジトリのIssueをまとめて最初から載せたいなら、「Import items from repository」を選びます。

3つの表示

同じ中身を3通りで見られます。あとから切り替えられるので、最初の選択で悩まなくて構いません。

表示	見え方	向いている場面
Table	スプレッドシートのような一覧	担当や期限を並べて見る、絞り込む
Board	列にカードが並ぶ。Statusの列の間で動かす	今どこまで進んだかを見る
Roadmap	時間の軸に並ぶ。日付の項目を使う	夏の教室のように期限のある話

Roadmapには、開始日と終了日のような日付の項目が要ります。日付を入れないと並びません。料理教室の修正の管理なら、Boardだけで足ります。

Statusの項目

Boardの列は Status という項目です。カードを別の列に動かすと、Statusが変わります。Projectには最初から2つの自動の動きが入っています。

• Projectに載っているIssueかプルリクエストを閉じると、Done になる
• プルリクエストを合流すると、Done になる

つまり Closes #12 を書いておけば、合流でIssueが閉じ、ボードのカードも Done に移ります。代表が手で動かす必要はありません。

Issueを載せる

1. Projectの一番下の行にある「+」を押す
2. 「Add item from repository」を押す
3. リポジトリを選ぶ
4. 載せるIssueを選ぶ
5. 「Add selected items」を押す

Issueの右の欄の「Projects」から載せても同じです。

Projectの見える範囲

Projectには、リポジトリとは別に公開範囲と権限があります。

設定	誰が見られるか
Public	インターネットの全員
Private	少なくともReadの権限を渡された人

権限はProjectの右上のメニューから「Settings」「Manage access」で見ます。「Base role」はOrganizationの全員への既定の権限で、No access、Read、Write、Adminから選びます。

Projectの公開範囲と、中のIssueの見え方は分けて考えます。会社のものはPrivateのままにします。

コードを触らない人をどう入れるか

Issueを書いてもらうには、GitHubのアカウントが要ります。受付Aにも作ってもらいます。

入れ方は、リポジトリの持ち主によって変わります。

持ち主	受付Aに渡せるもの	できること
個人アカウント	共同作業者のみ	読むだけの招待はできず、書き込みもできてしまう
Organization	Read	Issueを書く、コメントする、自分が書いたIssueを閉じる
Organization	Triage	Readに加えて、ラベルをつける、担当を決める、全部のIssueを閉じる

受付Aに渡すなら、OrganizationのReadかTriageです。代表が担当を決める運用ならReadで足ります。

見落としやすいのは、Readを渡すとコードも読めることです。website なら困らなくても、reservation-mail には渡しません。受付Aが要るのが website だけなら、そちらだけに招待します。

コードは見せずにやることだけ受けたいなら、コードを置かない空のリポジトリ requests を作って、そこにIssueを書いてもらう手があります。BのプルリクエストからはIssueを Closes sample-cooking/requests#3 の形で閉じられます。公式の機能ではなく運用の工夫です。

料金は増えるのか

Issue・ProjectsはFreeに含まれ、Freeは非公開の共同作業者の人数にも上限がありません。受付Aを入れても料金は増えません。

Teamにしている場合は別です。受付AもOrganizationのメンバーとして1人に数えるので、1人月$4が増えます。代表とBの2人で月$8なら、受付Aを足して月$12です。読むだけの人にも席が要るので、Teamでは入れる人を選びます。

ghで操作する

GitHub CLI（gh）は、GitHubの操作をコマンドでやる道具です。受付Aが使うものではありません。外注エンジニアBやAIが使う場面で読めれば足ります。次は gh issue create --help で確かめた書き方で、実行はしていません。Issueが本当に作られるからです。

gh issue create --title "料金表の修正" --body "和食の基本を6,500円に" --assignee ユーザー名 --label 料金

指定	意味
--title、-t	題名
--body、-b	説明
--assignee、-a	担当。@me で自分
--label、-l	ラベル
--milestone、-m	Milestone
--project、-p	載せるProject。権限の追加で gh auth refresh -s project が要る
--web、-w	ブラウザの作成画面を開く

他の手段で足りる場面

GitHubのIssueが向くのは、コードに関わるやることです。無理に寄せる必要はありません。

手段	合う場面
GitHub Issues	修正の依頼、不具合、プルリクエストと繋げたいもの
kintone	問い合わせや予約など、業務の記録。項目を決めて全員が入力する
Notion	文書と一緒にタスクを持ちたい。文章を中心に管理する
スプレッドシート	件数が少ない。全員が使い慣れている
Jira	開発の管理をすでにJiraで回している

判断の軸は2つです。1つ目は、その仕事がコードの変更で終わるかどうか。「料金表の修正」はコードで終わります。「夏の教室の講師の手配」は終わりません。2つ目は、関わる人全員にGitHubのアカウントを作ってもらう価値があるかどうかです。

サンプル料理教室は、ホームページと予約メールの修正だけをIssueにして、教室の運営の予定はこれまでのスプレッドシートのままにしました。修正の依頼が月に1〜2件のうちは、Projectsも作っていません。Issueの一覧で足りています。

公開リポジトリのIssueに個人情報を書かない

公開リポジトリのIssueは、インターネットの全員が読めます。受講者の名前、電話番号、予約の内容、問い合わせのメールの本文はそのまま貼りません。

非公開のリポジトリでも、招待した人全員に見えます。外注エンジニアBにも、これから招待する人にも見えます。本文には「○月○日のお問い合わせの件」とだけ書き、詳しい内容は予約システムや共有ドライブの権限のある場所に置きます。

間違って書いたら、編集で消すより先に、そのIssueの削除を権限のある人に頼みます（Organizationで削除が有効になっていないと、頼んでも消せません）。すでに通知のメールを受け取った人の手元には残るので、消せば元どおりにはなりません。誰に何が届いたかを確かめ、受講者への連絡が要るかどうかは代表が判断します。

できないことと、その代わり

できないこと	その代わり
GitHubのアカウントなしでIssueを書く	受付Aにアカウントを作ってもらう。無理なら代表が代わりに書く
同じリポジトリでコードを隠してIssueだけ見せる	コードを置かないリポジトリにIssueを集める
Issueごとに見える人を変える	リポジトリを分ける
業務の記録を項目どおりに入力させる	kintoneなど業務向けの道具を使う

よく詰まるところ

症状	原因	直し方
「Issues」タブが見当たらない	リポジトリの管理者がIssueを止めている	権限のある人に有効にしてもらう
担当やラベルを変更できない	Readの権限では変えられない	Triage以上を渡すか、代表が決める
Closes #12 を書いたのに閉じない	合流先が既定の枝ではない	main への合流か確かめる。手で閉じる
別のリポジトリのIssueが閉じない	番号だけ書いている	Closes sample-cooking/website#12 の形で書く
Projectが他の人に見えない	Projectの権限が渡されていない	「Manage access」で権限を渡す
カードが Done に動かない	項目がそのProjectに載っていない、自動の動きを止めた	載っているか確かめる。Workflowsの設定を見る
Roadmapに何も並ばない	日付の項目がない	日付の項目を足して入れる
gh issue create --project が止まる	project の権限がない	gh auth refresh -s project を実行する

次に読む

Closes #12 の先の確認の流れは「プルリクエストとは：作り方・レビュー・マージの流れ」に、受付Aに渡す権限は「GitHubの権限と2段階認証：共同作業者・Organization・非公開リポジトリ」に書きました。Teamの席の数え方は「GitHubの料金：Free・Team・Enterpriseと無料でできる範囲」、公開と非公開の考え方は「GitHubとは：できることと、公開・非公開の考え方」です。