タスク管理＠プロジェクトマネジメント¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. プロジェクト全体像の把握¶
概要¶
概要として、背景と目的、ロードマップ、マイルストーンを整理する。
- 背景と目的 (現状の課題)
- 状況の整理
- ロードマップ (目指したいゴール)
- マイルストーン (そこに至るまでの手段)
状況の整理¶
▼ 担当者¶
- 自社
- Aさん
- Bさん
- 外部会社
- Cさん
- Dさん
▼ プロジェクトツール¶
- チャット
- Slack
- Mattermost
- ミーティング
- Google Meet
- Teams
- ドキュメント
- Confluence
- Backlog
- 進捗管理
- Jira
- GitHub Issue
ロードマップ¶
どのようなゴールを目指すのかを明確にする。
ロードマップ策定は、成果や達成度の見せ方としても大事である。
| 対象範囲 | 詳細 | 成果物 | 対象範囲外 |
|---|---|---|---|
| 〇〇機能の実装 | △△機能の実装 | ||
| 〇〇アーキテクチャの検討 |
02. 大粒度でタスクの洗い出し¶
大粒度でタスクの洗い出しとは¶
issueやEpic issueを1つのタスクとみなし、大きく洗い出す。
この段階では、タスクは大きくて問題ない。
以下のような表を作成すると良い。
| タスク | 優先度 | 見積もり |
|---|---|---|
| 〇〇する | 高/中/低 | n |
03. 進捗管理¶
タスクステータス¶
| ステータス名 | 説明 |
|---|---|
| オープン | 未着手の問題 |
要報告 |
アーキ定例で作業状況を報告した方がよい問題 |
進行中（アーキ定例報告不要） |
アーキ定例で作業状況を報告しなくてもよい問題 |
| クローズ | 完了した問題 |
ラベル¶
| ラベル名 | 説明 |
|---|---|
backlog |
すぐには実施予定なし。定期的に見直して優先度を再評価する。 |
critical |
即時に対応する必要があり、放置すると障害・重大リスクがある問題。 |
low |
現状すぐ対応しなくても問題はないが、将来的に改善すべき課題。チームリソースに余裕があるときに実施。 |
medium |
優先度を上げる理由がなければこのレベルが標準。 |
ミーティングの実施¶
▼ 月次¶
必要であれば実施する。
▼ 週次¶
週次ミーティングでタスクの状態を定期的に管理する。
- タスクの進捗を確認 (特に優先度 高)
- タスクボード：<ボードのURL>
- 新しい課題を積み課題ボードに追加
- 積み課題ボード：<ボードのURL>
- 『積みラベル』をつけてボードに追加する
- 積み課題のタスク化と担当者アサイン (特に優先度 高)
- 積み課題ボード：<ボードのURL>
- 積み課題に 『担当者』『タスクラベル』を設定する ➡️ タスクボードに自動振り分け
- 監視チャンネルを巡回し、必要に応じて積み課題ボードに追加
- devチャンネル：<監視チャンネルのURL>
- prdチャンネル：<監視チャンネルのURL>
- その他共有事項あれば
▼ 日次¶
必要であれば実施する。
タスクの優先順位決め¶
▼ タスクの優先度決めとは¶
機能として欲しい期待度のこと。
ガントチャートとタスク表を組み合わせると、スケジュールを管理しやすい。
クリティカルパスでタスク間の関係を可視化すると、優先順位を見つけやすくなる
▼ 優先度の種類¶
高、中、低の3段階でを決める。
ビジネス側と議論しながら決めると良い。
- 高：必ず実装する必要がある。
- 中：できる限り実装したい。ただし、後回しにできる。
- 低：なくてもよい。一番最後に後回しできる。
04. タスクを依頼する¶
タスクの依頼とは¶
タスクをメンバーに依頼し、タスク全体を細分化してもらう (メンバーのスキル次第では一緒にやる) 。
工数を定量化しやくする。
見積コストが大きい場合 (目安は13以上) はEpicとしてタスクを分割すると良い。
実装以外のタスク (調査、設計、ドキュメンテーションなど) もタスクとする。
ユニットテストは、タスクの見積りに含めるようにする。
締め切りを決める¶
人間の心理として、締切がないと危機感が生まれず、いつまで経ってもタスクが始まらない。
そのため、締切 (リリース日) の融通がきくタスクであっても、締切を決めてしまう方が良い。
ちなみに、これは虎案件の某PM氏がよく言っていた。
05. 振り返り¶
KPTなどで、プロジェクトを振り返る。