# タスク管理

タスクは開発の作業単位です。ストーリーの下に置き、担当・優先度・見積もりを付けながらカンバンで日々動かします。

![PM on Railsのカンバン。未着手 / 進行中 / レビュー / 完了でタスクが並ぶ。導入前は実装が進んでもボードが古かった。導入後はPRの動きが進捗に戻る。](https://pmonrails.com/docs-img/kanban.png)

![カンバンの操作動画。列ごとのタスクと、紐づいたPRを確認する。日々の作業が要求と完成条件の下で進むことが分かる。](https://pmonrails.com/docs-video/kanban.webm)

## タスクの種類（3つ）

- **作業** — 内部改善・リファクタ・調査など、振る舞いの形で書きにくい作業。
- **振る舞い（シナリオ）** — 「○○できること」をGiven / When / Thenで書ける作業。受入シナリオとそのまま対応します。
- **不具合（バグ）** — 既存機能の不具合。詳しくは[バグと変更管理](https://pmonrails.com/docs/bugs-changes.md)を参照してください。

> 種類は迷わないよう3つに絞っています。「インフラ作業」「デザイン」などで種類を増やすことはせず、後述の単発タスクやラベルで表現します。

## 1つのタスクに付けられる情報

タスクを開くと、次の項目を編集できます。

![PM on Railsのタスク編集。見積もり、担当、期限が見える。導入前は見積もりがチャットの数字だった。導入後はストーリー配下の作業として残る。](https://pmonrails.com/docs-img/estimate.png)

- **担当** — ワークスペースのメンバーから選びます（未アサインも可、後から変更・解除できます）。
- **優先度** — 低 / 中 / 高 / 緊急 の4段階を色分けボタンで切り替えます。
- **見積もり** — プロジェクトの単位（ストーリーポイント `pt` または時間 `h`）に合わせて入力します。
- **期限** — 期日を設定できます（遅延の検知にも使われます）。
- **ラベル** — 自由なタグを付けて、横断的な分類・絞り込みに使えます。
- **説明** — 作業メモや補足を書けます。受入シナリオのGiven / When / Thenはシナリオ側で編集します。

## AI見積もり（規模の目安を出す）

「AIに見積もってもらう」を押すと、要求・要件・背景をふまえて**規模の目安**を提案します。

- **平均的なエンジニア基準**でp50〜p80（控えめ〜余裕を見た値）を返し、根拠も添えます。「p50を採用 / p80を採用」で見積もり欄にそのまま反映できます。
- 過去の実績（着手〜完了の所要時間）が貯まっている担当者なら、**その人向けの推奨値**も併せて出します。
- 注意: 値は提案です。採用するかは任意で、最終判断は人が行います（[進捗を管理する](https://pmonrails.com/docs/progress.md) の自動見積もりも参照）。

## カンバンで動かす（4状態）

タスクは「未着手 → 進行中 → レビュー → 完了」の4状態をドラッグで動かします。

- **既定で「今の開発サイクル」に絞って表示**します。上部の表示切替（「今のサイクル」／「バックログも表示」）で、サイクル未割り当て（バックログ）も混ぜられます（[進捗を管理する](https://pmonrails.com/docs/progress.md)）。
- ストーリーごとにまとまって表示され、種別・優先度・担当・見積もり・ラベル・PRの状態がカードで一目で分かります。
- **完了で親ストーリーを自動更新** — 配下のタスクが全部終われば、親ストーリーの状態も自動で進みます。
- **PRを紐付けると自動で完了** — GitHubのPRをタスクに紐付け、マージすると自動で「完了」になります（[GitHub連携](https://pmonrails.com/docs/github.md)）。
- **「レビュー中」の意味を分けて読む** — カンバン列は4つのままですが、**実装状況**（未着手 / 進行中 / マージ済み）と**検証状況**（不要 / 待ち / 充足）をタスク詳細で別軸表示します。PRはマージ済みなのに列が「レビュー中」のまま、という状態は「マージ済み・証跡待ち」として案内され、[テスト結果](https://pmonrails.com/docs/test-results.md)の記録が次の一手になります。カンバンカードでは、レビュー列のうち実装がマージ済みのものに控えめな印が付きます。

## 階層で見渡す（ストーリー → タスク → サブタスク）

![PM on Railsのタスク詳細。親のストーリーと、元になった受入シナリオが同じ画面に出る。導入前はタスクの根拠を説明し直していた。導入後はなぜこの作業があるかを辿れる。](https://pmonrails.com/docs-img/task-hierarchy.png)

- ストーリーを開くと、その配下のタスク・受入シナリオが一覧で見えます。
- 各タスクに「子（サブタスク）」を足して、大きい作業を分割できます。
- 受入シナリオは、カンバン上ではscenario task（「○○できること」の作業カード）として扱えます。カードは実装・PR・テスト結果をまとめる場所で、シナリオの本文は受入シナリオ側にあります。
- **単発タスクも作れます** — どのストーリーにも紐づかないインフラ作業などは、単独のタスク（プロジェクト直下）として管理できます。

「どのストーリーのために、今どこまで進んでいるか」が、階層をたどるだけで分かります。

## 依存関係（先にやることを決める）

タスクの詳細画面に「依存関係」があり、「**先に終わらせるタスク（これらが前提）**」を指定できます。「前提にするタスクを選択」から選んで追加すると、そのタスクは前提が終わるまで着手待ちだと分かります（受入シナリオもタスクの一種なので同じ画面で指定できます）。ロードマップのEpic同士でも、詳細パネルから前後の依存関係を設定できます（[進捗を管理する](https://pmonrails.com/docs/progress.md)）。

## 準備完了・完了の基準（DoR / DoD）

着手してよいか（Definition of Ready）・完了とみなすか（Definition of Done）を、**チェックリスト**で確認します。品質の抜けや「まだ決まっていないのに着手する」失敗を防ぎます。

![PM on RailsのDoR / DoD設定。着手前と完了の確認項目が並ぶ。導入前は『まだ早い／もう終わり』が人による判断だった。導入後は足りないものが項目で見える。](https://pmonrails.com/docs-img/checklist.png)

- **項目はプロジェクトで決めます** — 「プロジェクト設定 > 着手・完了の条件」でDoR / DoDの項目を編集します（初期値として「要求・要件が明確」「受入シナリオがある」「シナリオのGiven/When/Thenが具体的」などが入っています）。
- **タスク・ストーリーの編集画面でチェック** — 満たした項目にチェックを付けます。**まだ満たしていない必須項目がそのまま並ぶ**ので、「着手・完了までに何が足りないか」が一目で分かります。
- **カンバンで動かすときに確認されます** — 「進行中」に動かすときにDoR、「完了」に動かすときにDoDを確認します。未達のときは、設定に応じて**警告を出す**（そのまま進めます）か、**移動をブロックする**かを選べます（「プロジェクト設定 > 着手・完了の条件」）。
- 着手可否の判断は、実際に手を動かす単位（タスク・ストーリー）で持ちます。要件の段階では「決まっているか（確定したか）」に焦点を当てます。

## コメントで相談する

タスクごとにコメントを残せます。仕様の確認ややり取りを、その作業の場所に紐付けて記録できます。ゲスト（業務委託など）もコメントで**共同作業者をメンション**できます（[メンバーと権限](https://pmonrails.com/docs/members.md)）。

## Claude Web / Claude Code / Codexで管理・開発するとき

タスクは、Claude Web / Claude Code / Codexなどの外部AIツール（[MCP連携](https://pmonrails.com/docs/mcp.md)）から直接あつかえます。PMはClaude Webで整理・確認し、エンジニアはClaude Code / Codexで背景を読みながら実装できます。

### 着手から完了までの流れ

1. **タスクを選ぶ** — 「次のタスクに着手して」と頼むと、担当・状態・見積もり・背景を読み取り、着手するタスクを決めます。
2. **状態を「進行中」に** — 着手すると状態が「進行中」に変わり、**着手した時刻**が自動で記録されます（あとで所要時間の実績になります → [自動見積もり](https://pmonrails.com/docs/progress.md)）。
3. **ブランチとPRの雛形を受け取る** — 着手時の応答に、そのタスク専用の**ブランチ名**と **PRトレーラー**（`PMR-Task: ...` の1行）が含まれます。Claude Code / Codexはこれをそのまま使うので、IDを手で書く必要はありません。
4. **背景を読みながら実装** — 紐づく要求・受入シナリオまで読めるので、「何を満たせばOKか」を踏まえて実装できます。
5. **PRをマージ → 自動で完了** — ブランチ名かPRトレーラーで紐付いていれば、GitHubのPRをマージした時点でタスクが**自動で「完了」** になり、親ストーリーの状態も再計算されます（[GitHub連携](https://pmonrails.com/docs/github.md)）。

### 実装中に仕様が変わっても気づける

Claude Code / Codexは「自分が着手したあとに、上流の要求・シナリオが変わったか」を検知できます。着手中に仕様が変わっていれば、PRマージ時に「再確認が必要」とマークされ、古い仕様のまま取り込んでしまうのを防ぎます（[変更の追従](https://pmonrails.com/docs/change-tracking.md)）。

### 画面での操作と同じ結果になる

Claude Web / Claude Code / Codexから更新しても、画面から更新しても**同じデータ**が変わり、同じ権限・安全確認が効きます。担当・状態・見積もり・ラベル・依存関係など、画面でできる編集はエージェントからも行えます。ツールの一覧と実用プロンプトは [Claude Web・Claude Code・MCP連携](https://pmonrails.com/docs/mcp.md) を参照してください。

## 次のステップ

- [バグと変更管理](https://pmonrails.com/docs/bugs-changes.md) / [進捗を管理する](https://pmonrails.com/docs/progress.md) / [Claude Web・Claude Code・MCP連携](https://pmonrails.com/docs/mcp.md)

---

https://pmonrails.com/docs/tasks