概要
私は普段、PMとして複数の開発案件のプロジェクトマネジメントをしています。
エンジニアなら実装に、デザイナーならUI作成に、そしてPMならそれらの管理に集中できるようタスクの作り方や管理方法を日々模索しているわけですが、調べてみても「具体的なタスクの作り方のベストプラクティス」があまり出回ってない印象です。
本記事では自分がどのようにタスク管理しているかを具体的に紹介してみようと思います。
前提
- ソースコードはGithubで管理しています
- 実装タスクは Github issue と Projects機能 で管理しています
- Beta版のタスクリスト機能を使ってissue同士の紐付けを行なっています
- ウォーターフォールでもアジャイルでも使ってます
Projects機能
- Githubの標準機能で、issueをカンバンやリストで見やすく管理できる機能です。
- カスタムフィールドを追加する、独自のラベルをつける、フィルターで絞り込む、などいろいろカスタマイズ出来ます。
- issueが新規作成されたら勝手にprojectsに追加してくれるようなワークフローも設定できるのが結構便利です。
タスクリスト
- 本記事の執筆時点ではベータ版として提供されていて、順番待ちリストに参加してから利用できます。
- 今までもissueに
- [ ]を追記すればTODOリストを追加することができましたが、それと同様にTODOを追加できます - TODOリストとしてissue番号を追加するとissue同士が親子関係で紐付きます
- Projects機能で表示するとタスク消化数がいい感じに表示されます
記載例
```[tasklist]
### タスクリスト
- [ ] TODOで何かあればテキストで書くこともできる
- [ ] #123
```
前置きが長くなりましたが、早速具体的な方法に触れていこうと思います。
issueを作成する
issueを作成するときに意識していることは以下の2点です。
- テンプレに沿って記載していく
- issue同士の親子関係を意識する
テンプレートは.github/ISSUE_TEMPLATEのファイルから設定できます。メンバー各自が好き勝手な形式で書くと、タスクを渡された側は読み取るのに時間がかかります。テンプレ例もあとで記載してます。
親子関係は、先でも触れた通りタスクリスト機能を使って紐づけていきます。「タスク作れてなかった」「この機能ってどこまで終わってるんだっけ」を防ぎます。
上記の通り FEATURE > STORY > TASK の順で親子関係を作って細分化します。細分化されるほどissueに記載される内容は具体化していきます。FEATURE,STORY,TASKそれぞれの位置付けや詳細は次の通りです。
FEATURE issue
何が書かれている？
- 機能要件に相当する一番大きな括りです。
- issueのタイトルには「〜機能」と付けることが多いです
- 詳細な仕様は書かず、どういう機能か、この機能で何をしたいのかがざっくり分かればOKとしています。
テンプレ例
---
name: 機能要望
about: プロジェクトに機能を要望する
title: "[FEATURE] 機能名"
labels: feature
assignees: ""
---
## 機能の説明
実現したいことを明確かつ簡潔に説明してください。
## 背景
この機能を追加する背景（ユーザーにどういうメリットが有るか)を明確かつ簡潔に説明してください。
## Story
```tasklist
## STORY
- [ ]
```
## 課題・検討・補足
補足があれば、記入してください。
誰がいつ作る？
- 新機能追加のタイミングや、PJ立ち上げ時にPM（私）が作成しています
いつクローズする？
-
FEATUREに複数ぶら下がっているSTORYが全てクローズした時- つまりこの時点で機能として全て完成している状態
STORY issue
何が書かれている？
- その機能（FEATURE）で実現したいユーザー価値を記載します
- issueのタイトルには「〜できる」と付けることが多いです
- 実現したい仕様をSTROYごとに基本設計レベルで記載します。
テンプレ例
---
name: ストーリー
about: ユーザーストーリー
title: "[STORY] 〜をする、〜をしたい"
labels: story
assignees: ""
---
## ストーリーの目的
- このストーリーによってユーザーが得られる価値はなんでしょうか
## 経緯・背景
- このストーリーが作られた経緯があれば記載します
## 実現方法/UI
- このストーリーを実現するための方法、UI はなんでしょうか
## 受入条件・完了の定義
- ストーリーが達成されたことを確認する条件を箇条書きします
## 詳細タスク
```[tasklist]
### 調査
- [ ]
```
```[tasklist]
### 設計
- [ ]
```
```[tasklist]
### フロント実装
- [ ]
```
```[tasklist]
### バックエンド実装
- [ ]
```
```[tasklist]
### テスト
- [ ]
```
誰がいつ作る？
- 仕様全体を把握しているPM（私）が作成しています。
- UIが完成したらデザイナーに追記してもらうこともあります
いつクローズする？
-
STORYに複数ぶら下がっているTASKが全てクローズして、動作確認できた時- つまりこの時点で機能の一部だけ完成している状態
TASK issue
何が書かれている？
- ユーザー価値（STORY）を実現するための具体的な実装タスクを記載します
- issueのタイトルには「〜を実装する」と付けることが多いです
- フロントエンド、バックエンド、事前調査など、
STORYを実現するためのタスクを複数のissueに分けて作成します
テンプレ例
---
name: タスク
about: タスクを作成する
title: "[TASK] タスク内容"
labels: ""
assignees: ""
---
## タスク <!-- タスク内容を明確かつ簡潔に説明してください。 -->
## 資料 <!-- 資料があれば、追加してください。 -->
## 作業 <!-- 作業内容を箇条書きで記述しください。 -->
```[tasklist]
### tasks
- [ ]
```
誰がいつ作る？
- STORYが作成し終わってからエンジニアに作成してもらっています
- issue作成するエンジニア自身が開発する場合はよしなに、外部パートナーに依頼する場合は詳細に書いてもらっています
いつクローズする？
-
TASKを実現するために必要な pull request がマージされた時
issueを管理する
ステータスを管理する
issue単体だとopenまたはcloseしか管理できませんが、projects機能と組み合わせて細かいステータスを作って管理することができます。ここで管理したいのは基本的に TASKのステータスです。STORYやFEATUREは、大変なので TASKほど細かくステータス管理してないです。
右上のSettingsからカスタムフィールドを追加できます。また、Workflowsから自動でステータスを設定したりアーカイブしたりすることができます。
ステータスの種類
以下の表の種類で運用しています。
PJメンバー全員でステータスの意味を理解して各自で管理してもらっているのですが、リアルタイム性はあまり重要じゃないので週次Mtgの時までに正しいステータスにしてくれていればOKですし、もし間に合わなくてもMtg内で確認する時間は取っているのでそこで正しいステータスに変更します。
| ステータス | 意味 | 説明 |
|---|---|---|
Todo |
未着手 | issueが新規作成された時に自動で付与されるステータス。 |
Sprintbacklog |
未着手 | スプリント内でこれから実装予定のissue。 |
In Progress |
着手中 | 実装している最中。 |
Review In Progress |
レビュー中 | 対応したプルリクがレビュー中の状態。 |
Merged |
マージ済み | 対応したプルリクがマージ済み状態。 issueをcloseしたら自動でMergedに変更される。 |
Done |
完了 | マージされた内容を週次Mtgで動作確認して、 問題ないことをPJメンバー全員で共有できた状態。 |
ステータス名自体はどうでも良いですが、それぞれの意味をメンバー全員の共通言語にしていくことが大事です。また、ステータスの粒度が細かすぎてもPM/エンジニア共に管理コストが高くなるので注意です。私もブラッシュアップしていき最終的に上記の6種類に落ち着きました。
スプリントで管理する
まずスプリントとは、２週間などの区切られた期間のことを指し、イテレーションとも呼ばれます。1スプリントの中でSTORYをいくつか消化していき、これを繰り返すことでPJ期間内にFEATUREを全てクローズしていく流れになります。
issueとスプリントの紐付けは、Projects機能のカスタムフィールドや、マイルストーン機能を使って管理してます。
スプリントが始まる前
次のスプリントで実装するSTORYを事前に確認します。確認観点は以下の通りです。
- 必要な設計書が揃っているか
- UIデザインはfixしているか
-
STORYの完了条件は明確か -
STORYに紐づくTASKは全て作成されているか
必要に応じて設計書や各種URLを貼って、そのSTORYが着手可能な状態まで持っていきます。
スプリント中
TASKを粛々と進めてもらいます。
実装中に上がった課題や検討事項など頻繁にQAが飛んでくるので、なるべく即レスするよう心がけてます。自分がボトルネックになってエンジニアやデザイナーの手が止まることはなるべく避けるようにしてます。
スプリントが終わる時
スプリント終了時点では大体のTASKがMergedのステータスになってるはずなので、これらを全て動作確認し、確認を終えたものは手動でDoneのステータスに変更していきます。動作確認は基本的に全員集まって行い、月曜や金曜など区切りがいいタイミングで実施するのが良いと思います。
動作確認中に不具合などを見つけたらその場ですぐissue作成して次のスプリントで対応します。負債はなるべく残さないようにします。
また、わざわざMergedのステータスを設けているのは「issueとしては完了してるけど期待した動作になっているか確認してない」「動作確認してなかったから考慮漏れ状態のまま放置されてた」というのを防ぐためです。
その他tips
Projects機能で目的別のビューを作る
Table、Board、Roadmapの3種類でビューを作ることができます。開発規模が大きくなるとカンバン（Board）では管理し切れなくなるのでTableを使うことが多いです。
またビュー別にフィルタリングをかけて、目的に応じたビューを使い分けています。
各種ドキュメントもGithubで管理
各種設計ドキュメントはMarkdownで作成してGithub上で管理しています。
Excel方眼紙やパワポで作成されることが多いですが、最新版がどれか分からない、古い資料を参照したまま設計してた、などバージョン管理が大変です。
Github上で管理することで、レビューも履歴が残りますし、issueやプルリクにそのままリンクを貼り付けるだけで共有できて、資料が最新化されてもそのURLを貼り替えることも不要になります。
issueにFigmaを表示するchrome拡張を入れる
issue作成時にデザインも一緒に記載しますが、画面キャプチャではなくFigmaのURLを貼り付けます。
URLをわざわざ踏んでissueと行き来しなければいけないのは面倒なので、以下の拡張機能を入れてissue上にFigmaのフレームを表示させています。
まとめ
色々理想的な方法を書いてみましたが、運用するのは正直結構大変です。この方法ではPM自体の負荷は下がりませんが、タスクの受け渡しが効率的になり、抜け漏れも多少減るのではないかと思ってます。
NCDC株式会社( ncdc.co.jp/ )のエンジニアチームです。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください！ ※エンジニア以外も記事を投稿することがあります
Discussion