Issue（イシュー）
まずこれだけ
Issueは、「やること」「困っていること」「相談したいこと」をあとで追えるように残すカードです。開発の不具合だけでなく、改善案、調査メモ、質問、作業依頼にも使えます。口頭やチャットだけで流れてしまう話を、1つの場所にまとめておくことで、目的、背景、担当、決まったことが見失われにくくなります。
どこで見かけるか
GitHub（ギットハブ） のリポジトリ、タスク管理ツール、サポート窓口、社内の依頼管理で見かけます。GitHub（ギットハブ）では「Issues（イシューズ）」タブに並びます。タイトル、本文、コメント、担当者、ラベル、期限、関連する プルリクエスト などを付けられるので、ただのメモよりも作業の流れを残しやすいです。
具体例
研究会サイトで「API（エーピーアイ）キーの説明が短く、非IT（アイティー）職には怖さが伝わりにくい」と気づいたら、Issueを作ります。本文に、どのページのどこが困るか、誰向けに直したいか、完了条件は何かを書きます。作業する人はそのIssueを見て ブランチ を作り、修正後にプルリクエストをつなげます。すると、相談から変更、確認までが1本の記録になります。
つまずきやすいところ
Issueは細かく書きすぎても、ざっくりしすぎても扱いにくくなります。「サイトをよくする」だけでは大きすぎますし、「句読点を1つ直す」だけなら直接小さな変更で済むこともあります。迷ったら、背景、やりたいこと、完了の目安の3点を書きます。結論が変わった場合はコメントに残すと、後から読んだ人が判断の流れを追えます。
研究会では
GitHubでIssueを作り、その内容を見ながら作業します。できた変更を見てもらう流れが プルリクエスト です。時間を区切るなら タイムボクシング も役立ちます。Issueは「まだ分からないことを置いてよい場所」でもあるので、AI（エーアイ）に聞いた結果や確認した事実を追記していくと、共同作業の土台になります。