プロジェクト管理ツールとしてGitHubを"普通に"使う

プロジェクト管理はどのツールを使うかが一つのテーマになっていますが、以前行ったプロジェクトではプロジェクト管理ツールを新たに導入しなくても、GitHubの機能を普通に使うだけで実はうまくいったのでその時に行っていた管理方法を共有します。

※ここでは「プロジェクト」をチームで達成する計画という意味で使っていて、「*Project*」をGitHubのカンバンツールという意味で使っています。

----

なお、この記事はタスク管理にGitHubを使う一連の記事の中の一つです。

- [情シスのタスクをGitHubのissueで管理するようにしたら捗った](https://qiita.com/itkr/items/1ae5578c1ca761dacf88)
- **プロジェクト管理ツールとしてGitHubを"普通に"使う** ←ここ
- [Google Cloud Functions (Python) を使ってみた](https://qiita.com/itkr/items/d3f8b4f8ff9becf101b4)
- [GitHub App を作ってPythonからAPIを叩いてみた](https://qiita.com/itkr/items/db5ed965bf8cac1cdd4e)
- [Google Apps Script から Google Cloud Functions のHTTPトリガーを実行してみた](https://qiita.com/itkr/items/6a515c5cf8c9a18f1880)

## 導入に至るまで

そのとき自分が関わっていた開発プロジェクトは、始めはとてもミニマルな開発メンバーだったので自分とCTOで設計しつつ、スプレッドシートで１週間毎の計画をたてていました。その後メンバーが増えるにつれTrelloを検討したりWrikeを導入してみたり試行錯誤していましたが、結果的に「GitHubの*Project*で良いのでは？」ということで落ち着きました。

## タスクは*Issue*に集約する

基本的にタスクは細かいものも含めて全て*Issue*を立てます。例えば以下のようなものを含みます。

- 通常の To Do
- 仕様決め
- バグ報告
- リファクタリング
- 個人的に気になっていること
- リリース作業
- 通しテスト
- ...

とりあえず必要だと思われるものは*Issue*を立てて、それぞれに応じたタグを付けておきます。立てた*Issue*はスプリントプランニングのときに、やるかやらないか・工数見積・優先度などを考慮してバックログに組み込みます。

### 細かいタスクは*Issue*の中にチェックリストを作る

一つのタスクの中で細かくやることがある場合は、*Issue*の中にチェックリストを作っておきます。そうすると*Issue*一覧画面などでインジケーターを表示してくれるので進捗を確認しやすくなります。

![issue.png](https://qiita-image-store.s3.amazonaws.com/0/14918/f4432c03-cf54-51d7-d03f-536eeed46b5a.png)

### *Issue*のテンプレートを用意しておく

GitHubの*Issue*はテンプレートを用意することができます。[^1]
具体的にはリポジトリのルートディレクトリ直下に `.github/ISSUE_TEMPLATE.md` か `.github/ISSUE_TEMPLATE` というディレクトリの下に任意のファイルを作成することで実現可能です。

```..github/ISSUE_TEMPLATE/sample.md
---
name: Sample template
about: サンプルテンプレート。
title: ''
labels: ''
assignees: itkr

---

## 概要

issueの内容
```

ちなみに `.github/PULL_REQUEST_TEMPLATE.md` で Pull Request のテンプレートも作成できます。

```..github/PULL_REQUEST_TEMPLATE.md
## 概要

## チェックリスト

- [ ] テスト
- [ ] ドキュメント
```

テンプレートを作っておくことで足りない情報を防ぐことができ、このプロジェクトで作っているサービスの利用者（社内の人）もバグ報告などで迷うことが少なくできます。

## *Project*でタスク管理する

あまり活用しているという声を聞いたことがないのですが、実はGitHubではリポジトリやOrganizationごとに*Project*というものを複数作成することができます。Trelloを使ったことがある方ならイメージしやすいと思いますが、いわゆるカンバンを作成することができる機能です。

![project.png](https://qiita-image-store.s3.amazonaws.com/0/14918/8b39bd42-0348-d127-3a23-1fddfebf669b.png)

### *Project* に **To do**、**In progress**、**Done** を作る

GitHubが最初から用意している **Automated kanban** というテンプレートを利用すると

- **To do**
- **In progress**
- **Done**

というカラムが作成されます。これはあとから設定もできますが、このテンプレートで作っておくと*Issue*を*Project*に追加すると自動で **To do** に入り、*Issue*をクローズすると自動で **Done** に入ります。(作業を開始するときは作業者が手動で **In progress** に移動します)

また、 **To do** はグレー、**In progress** は紫、**Done** は緑にインジケーターが表示されるのでその*Project*がどれだけ進んでいるかを視覚的に把握しやすくなります。

![i.png](https://qiita-image-store.s3.amazonaws.com/0/14918/dc0cef12-55c2-19ac-f780-e23ab8776f08.png)

この３つのカラムで足りない場合は状況に応じてカラムは追加します。例えば **Waiting** など。

### プロジェクト全体の *Project* と、スプリントごとの *Project* を作成する

*Project*は複数作成できるので、プロジェクト全体のタスクを管理する*Project*と、現在のスプリントや少し先のスプリント用の*Project*を作成します。立てた*Issue*をその全体の*Project*と、スプリントごとの*Project*に配置します。こうすることで全体の*Issue*がどれくらい溜まっていて、直近のスプリントでは何をしなければならないのかをチームで共有することができます。

![projects.png](https://qiita-image-store.s3.amazonaws.com/0/14918/bd81d309-2a04-43c0-dfd3-031070e15ef0.png)

### *Project*とリリースバージョンを一致させる

スプリントごとに*Project*を作成することの恩恵はスプリントごとにやることを把握することだけではありません。スプリントごとに「やったこと」を把握することにも役立ちます。そのスプリントを終了するときに行うのはリリース作業です。リリース作業はリリース用のブランチを切ってデプロイを行っています。デプロイ対象のコミットにタグを付けておいて*Project*名とタグ名を一致させることで簡易的なリリースノートの代わりにできます。

![release.png](https://qiita-image-store.s3.amazonaws.com/0/14918/c1d17f10-bcc2-17fd-8942-a6f457b63d14.png)

## ブランチ戦略、テスト、デプロイ

ブランチの切り方は「[A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)」(GitFlow) に従っていて、CircleCIと連携してテストを自動化しています。デプロイはmasterブランチにマージすることでCircleCIでテストが行われるので、それが通れば自動的にデプロイされるようになっています。

![test.png](https://qiita-image-store.s3.amazonaws.com/0/14918/210300ca-b3c8-1b83-21f1-27a46c6dd556.png)

リリース作業が複数ある場合は、issueのテンプレートにリリース作業用チェックリストを含んだテンプレートを作っておきます。リリースする際に毎回そのテンプレートからissueを作成することでリリースの作業漏れがなくなります。

## まとめ

チームの規模やプロジェクトの進め方によっては、新しく管理ツールを導入することもなくGitHubの標準の機能を普通に使うだけで行えることを紹介しました。

人数が増えて技術者以外の人もプロジェクトに関わってくるとまた別の方法が必要になるかもしれませんが、前の記事にも書いたとおりGitHubに集約するメリットしては技術者が見慣れたUIであることと余計なライセンス料を必要としないことだと思います。また、ツールを行き来して集中力が途切れてしまうのも防ぐ効果もあるのではないかと思います。

[^1]: [Creating issue templates for your repository](https://help.github.com/en/articles/creating-issue-templates-for-your-repository)