GitHub初心者の非エンジニアが、GitHubでIssue管理・PRレビュー依頼をやってみた

GitHubはエンジニア向けのツールだと思い込んでいましたが、実際に触ってみるとタスク管理やレビュー依頼など、チーム全体で活用できる機能が満載でした。今回、初心者目線でGitHubを使ってみて感じたことをお話しします。

2026.07.14

 はじめにこんにちは、Haradaです。
今回、チーム内でGitHubを使ったタスク管理やレビュー依頼を試す機会がありました。

それまでは、「ゴリゴリのエンジニアがコードを保管して何かすごいアレコレができるツール」という漠然としたイメージを持っていて、上長から「使ってみよう！」という提案があった時に「私なんぞが使うなんて恐れ多い！」と思った程でした笑
実際に触ってみると、GitHubはコード管理だけではなく、以下のような用途にも使えることが分かりました。
Issueでタスクを管理する
Projectsで担当者やステータスを見える化する
Issueのテンプレートで起票内容を統一できる
READMEに運用ルールをまとめる
Pull Requestでレビュー依頼を出す
この記事では、私がGitHubを初めて使い、実際にやったこと、つまずいたこと、便利だと感じたことを書いていきます。
 今回やってみたこと今回試したのは、GitHubをタスク管理やレビュー依頼にも使ってみることです。
具体的には、以下をやってみました。
GitHub Organizationに参加する
Repositoryの権限を付与してもらう
他の人のRepositoryの権限を付与してみる
GitHub Projectsに参加する
Issueを作成する
Issueのテンプレートを作成する
ProjectsでIssueを管理する
READMEに運用ルールをまとめる
Pull Requestでレビュー依頼を出す
GitHubを「コードを置く場所」としてだけではなく、チームのタスクやレビュー状況を集約する場所として使えるかを試しました。

この記事では、この中からいくつか触れながら、実際にやってみて感じたことをお話しします。
 最初のつまずき：GitHubに入るまでにも段階がある使いはじめる前段階で、GitHubはいくつか段階があるということを知りました。
GitHubのアカウントだけ持っていても、チームのRepositoryやProjectに入れてもらわなければいけません。
GitHub利用申請を行う
Organizationに参加する
対象Repositoryへの権限を付与してもらう
GitHub Projectsへ参加する
必要に応じてProject側の権限も調整する
最初は「Organizationに参加できれば、配下のものは全部見える」と思っていました。
しかし実際には、Organization、Repository、Projectでそれぞれ参加状態や権限が分かれていました。
この時点で、GitHubには以下のような概念があることを知りました。
Organization
Repository
Project
Issue
Pull Request
Reviewer
README
権限
まだまだ慣れませんが、「Organizationの中にRepositoryがあり、RepositoryにIssueやPull Requestがあり、Projectでそれらを一覧管理できる」と考えると、少し理解しやすくなりました。

 Issueでタスクを作ってみる次に、実際の業務タスクをGitHub Issueとして登録してみました。
Issueは、タスクや課題を管理するための単位です。
最初は「タイトルと本文を書けばよいのかな」と思っていましたが
タスク管理として使おうとすると、次のような情報も必要だと感じました。

そこでチームの上長が提案してくれた項目は以下です。
担当者
ステータス
種別
優先度
期限
関連リンク
補足情報
シンプル設定で分かりやすい！

必要最小限の項目で始めて、実際に使いながら足りない項目を随時追加していくのが良さそうです！
 Issueテンプレートを作ると起票しやすくなるIssueを作ってみて、他メンバーから「毎回ゼロから書くのは難しい」という声があがりました。
確かに、空白のIssue作成画面を前にすると、何を書けばよいか迷うし、人それぞれでは視認性も良くないですね。
そこで、用途に応じて以下のようなテンプレートを用意しました。
施策用
問題報告用
タスク用
テンプレートなし
テンプレートがあると、Issueを作成する人は項目に沿って入力できます。
そのため、起票内容のばらつきを減らしやすくなります。

 Pull Requestでレビュー依頼を出してみる次に、Pull Requestでレビュー依頼を出してみました。
これまでAIで作ったコードのレビュー依頼はVisual Studio Code経由・Backlogで依頼をしていたのですが、初めてGitHub内だけで完結させてみました。
今回やってみた流れは以下です。
変更内容をPull Requestとして作成する
Reviewerを設定する
レビューを依頼する
コメントを確認する
必要に応じて修正する
問題なければMergeする
現在は、BacklogでレビュワーがコメントするとSlackに連携される運用になっていますが

GitHubではレビューなどの通知はメールをチェックする必要があります。
ここは今後、依頼者・レビュワー共に気付きやすい設計が必要だなと感じたポイントでした。
 AIに聞きながら進めた今回、GitHubの操作を進める中で、AIも補助的に使いました。
たとえば、以下のような場面です。
GitHubの用語を確認する
Issueの文面を整理する
Pull Requestの操作手順を確認する
レビュー依頼時の文章を整える
GitHubに慣れていない状態でも、AIに聞きながら進めることで、作業のハードルは下がりました。
一方で、AIの回答をそのまま採用するのではなく、実際のチーム運用に合っているか・GitHubのベストプラクティスに合っているかを確認しながら進めました。
 ハマったこと 全部英語でアワワGitHubの項目はすべて英語で、GitHubの機能としての日本語変換はできません！

AIに確認し、Chromeの『このページを翻訳』機能をONにしたところ、一見良いかな…と思ったら…



Titleに入力した「【AI__施策__】」が「【AI__一歩__】」と謎変換されてしまい戸惑いました。
・翻訳機能OFF時

↓　↓　↓　↓
・翻訳機能ON時

なんかちょっと演歌っぽくて心に沁みます。笑
ということで、Chromeの『このページを翻訳』機能はOFFにしました。

英語の項目名にはなれるしかなさそうです。
 まとめGitHubはエンジニアだけのものと思っていましたが、実際に触ってみると、非エンジニアでも活用できる場所が多くあると感じました！
今回学んだことは以下です。
GitHubはタスク管理やレビュー運用にも使える
Issueテンプレートがあると初心者でも起票しやすい
Projectsを使うと担当者やステータスを見える化しやすい
Pull Requestレビューでは通知ルールも大事
AIは補助として使いつつ、最終判断は人が行う
まずは小さくIssueを1つ作るところから始めると、GitHubの使い方を理解しやすいと思います。