4月に入り、新しく会社や部署に入った人も多いのではないでしょうか？
私が新入社員の頃に部署に配属されて困ったことは、
「どうやってプロジェクト管理されてるかわからない！作法ってあるの！？」
ということです。
そこで本投稿ではGitHubを用いたプロジェクト管理の初歩をご紹介します！
※ 内容はあくまでもプロジェクト管理の一例ですので、みなさまの状況にあわせてお使いください。
Project
まずGitHubでプロジェクト管理をするためには、Projectを作成します。
このProjectはいわゆるカンバンです。
作成はタブのProjectsから「Create a project」を押します。
nameやdescriptionを入力して作成。(後から変更もできます)
Projectを作成するとこのようなページが表示されます。
「Add a column」ボタンからカラムを作成していきましょう。
はじめは以下のような構成をおすすめします。
まずは「To do」カラム。
このカラムにはやるべきタスクが配置されるようにします。
上の画像のようにAutomationをチェックしておくと、IssueとPull requestが新しく作られた、または再オープンしたとき自動的にこのカラムへ追加されます。
次に「Developing」「Reviewing」カラムを作成します。
ここにはそれぞれ開発中とレビュー中のタスクを配置します。
最後に「Done」カラムです。
こちらは終了したタスクが配置されます。
ここでも画像のようにAutomationを設定しておくと、IssueとPull requestがclose、またはマージされたときに自動でこちらに移動します。
Automationはすごく便利なので、設定しておくことをおすすめします。
くわしくはAbout automation for project boardsをご覧ください。
以上でProject(カンバン)が完成しました。
ここへ後述するIssue(タスク)を貼っていきます。
Milestone
MilestoneはIssue(タスク)をどの期日までに行うか管理するものです。
リリーススケジュールやアジャイルのスプリントと対応させるとよいでしょう。
IssueタブのMilestonesから作成することができます。
作成すると以下のようにどのぐらいのタスクがあり、進捗率はどのくらいかが把握できるようになります。
Issue
Issueはプロジェクトのタスクや課題を管理するためのものです。
新しい機能の相談や不具合の報告など使われ方は多岐に渡ります。(正直Issueの粒度は一番悩ましいとこです)
今回は以下のように作成していきます。
Issueのdescriptionにはどのようなタスク、課題、要件なのかということを詳細に記述しておくとよいです。
また、このIssueに紐づく粒度の小さいタスクはタスクリストとして記述しておきましょう。
右カラムではこのIssueに関連する情報を紐づけることができます。
AssigneesにはこのIssueを行う人を、ProjectsやMilestoneは先程作成したものを登録しておきましょう。
Labelsはbugやenhancementなど任意のラベリングをしておくと、Issueを管理しやすくなります。
作成したIssueは以下のように表示されます。
作成したIssueはProjectを紐づけておいたので、ProjectのTo doカラムにIssueが登録されています。(べんり！)
なにかタスクを開始する際には必ずProjectのIssueを移動させましょう。
こうすることで、誰がどのIssue(タスク)に取り組んでいるかがひと目でわかるようになります。
なお、Issueのタスクリストの達成度がProject上に表示されるため、Issue内の進捗がどれぐらいなのか把握することができます。
Pull request
Pull requestは自分が実装したコードや行った変更を他者にレビューしてもらう機能です。
IssueをDevelopingに移動したら、開発、Commit、Pushしましょう。
Commitの粒度についてはこちらのスライドが非常に参考になります。
参考：きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会
それでは自分が開発したものをレビューしてもらうためにPull requestを作成します。
Issueに詳しい要件などが書いてあれば、Pull requestのdescriptionにはIssueの番号を書いておくだけでよいとおもいます。
こうすることでIssueとPull requestが紐づきます。
右カラムのReviewersにはレビューして欲しい人を割り当てましょう。
また、右カラムのProjectsはこのPull requestをProject(カンバン)に載せたいときは登録するとよいでしょう。
一方で、このIssueだけ載っていればよく、Pull requestまで載せる必要ないのであれば、登録しないほうがよいです。
レビュー待ちのときはIssueをReviewingのカラムへ移すことをお忘れなく。
CloseとReopen
すべてのタスクリストが完了したら、IssueをCloseしましょう。
該当Issueの最下部に「Close issue」ボタンがあります。
また、Pull requestのdescriptionやCommit messageに"fix"や"close"といったキーワードを入れると、マージされたときに一緒にIssueもCloseすることができます。
参考：Closing issues using keywords
CloseしたIssueはProjectのDoneカラムへと自動的に移動されています。(べんり！)
このIssueに紐づいていたMilestoneも更新されています。
もし新たなタスクが生まれた場合は新しいIssueをつくる、もしくはIssueをReopenして管理していきましょう。
CloseしたIssue最下部のコメント欄に「Reopen issue」ボタンがあります。
ReopenしたIssueはDoneからTo doカラムへと自動的に移されます。
これにてタスク作成から終了までの一連の流れは終了です！
おわり
冒頭にも述べましたが、本投稿内容はあくまでもプロジェクト管理の一例ですので、みなさまの状況にあわせてお使いください。
一番大切なことはIssue, Pull request, Commitなどの粒度をどうするか、どのようにラベルを活用するかなど、プロジェクト内で認識をあわせておくことだと思います。
新入社員の方は先輩にガンガン質問するとよいでしょう！
こういう管理の方法もあるよ！など気軽にコメントいただけると幸いです。
それではプロジェクト管理を円滑にし、よい開発生活を！