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