# 進捗の見える化

受け渡して終わりではなく、いつ何を作るか・今どこまで進んでいるかを同じ場所で管理します。

## ダッシュボードの使い分け

ログインして最初に開くのはAIアシスタントで、ダッシュボードはサイドバーの「ホーム」から開きます。編集権限のあるメンバーは、目的に合わせてダッシュボードを切り替えられます。

![PM on Railsのダッシュボード。要求の準備、自分の作業、遅れ、サイクルが一覧になる。導入前は進捗を手で集めていた。導入後は確認と判断の材料が向こうから揃う。](https://pmonrails.com/docs-img/dashboard.png)

| タブ | 確認すること |
| --- | --- |
| 開発の準備 | 資料・要求カード・スコープ・ストーリーの準備状況、AIへの相談入力、要求の整理リスト（5件ずつAIレビュー）、次に進む画面 |
| 自分の作業 | 自分が担当するタスク、作業予定、次に取り組む作業 |
| 進捗・管理 | ワークスペースのオーナー・管理者は全体の進捗や注意点、その他の編集メンバーは自分の作業状況 |

開発サイクルが始まる前は「開発の準備」から始められます。開発開始後もタブで準備状況に戻れます。閲覧専用のメンバーには、閲覧者向けの確認画面が表示されます。

## 作業と連携して進捗を更新する

タスクの着手・レビュー・完了は、カンバンやMCPから記録できます。**GitHub連携とPRの紐付けを設定すると、PRの動きもタスクの状態へ反映されます。** 開発サイクルや日々の集計は、以下のように自動で更新されます。

- **PRがmainに届くと自動で完了** — タスクに紐付けたGitHubのPRが既定ブランチ（main）にマージされると、そのタスクが自動で「完了」になり、**親ストーリーの状態も自動で再計算**されます（配下が全部終われば親も完了に）。featureブランチへのマージは「待ち」として記録され、そのブランチがmainに届いた時点で完了します。紐付けはブランチ名・PR本文のどちらでも成立します（[GitHub連携](https://pmonrails.com/docs/github.md)）。
- **開発サイクルの状態は日付で自動進行** — 「準備中 → 進行中 → 完了」は開始日・終了日から自動で切り替わります（手動操作不要）。
- **毎日の進捗を自動で記録** — 進行中の開発サイクルの消化状況を毎日スナップショットし、バーンダウンに描きます。
- **遅延を自動で検知して知らせる** — 毎朝、**期限を過ぎた / 期限が近い / 期限が未設定 / 長く放置されている**タスクを自動で検知し、担当者へ通知します。チーム全体の注意点は[毎朝の開発状況サマリー](https://pmonrails.com/docs/notifications.md)に1通でまとまります。

## 更新履歴（履歴と通知を1箇所で）

![PM on Railsの更新履歴。誰が何を更新したかの時系列。導入前は変更履歴がチャットに散らばっていた。導入後は同じ流れの更新を追える。](https://pmonrails.com/docs-img/activity.png)

サイドバーの「履歴 → 更新履歴」を開くと、プロジェクトの動きを時系列で追えます。通知を見逃していても、ここを見れば直近の動き（新しいPR・タスクの進行など）に追いつけます。

- **自分宛て** — 選択中プロジェクトの自分宛て通知の全履歴です。他プロジェクトの通知は出ません。ベルに出る直近分より前まで遡って読めます。開くとこのプロジェクトの未読だけが既読になり、他プロジェクトの未読はベルに残ります。
- **プロジェクト全体** — プロジェクトで起きたこと（誰が・いつ・何を）を新しい順に一覧します。タスクの作成・状態変更・担当変更などが対象です。

![PM on Railsのロードマップ。サイクルや四半期の予定と、今作っているまとまりが見える。導入前はいつ届くかを報告で聞いていた。導入後は自分でいまの状況を追える。](https://pmonrails.com/docs-img/roadmap.png)

## ロードマップ（Epic）

- Epicのバーを**ドラッグして期間を移動・変更**。変更はすぐ保存されます。
- 状態は「未着手・進行中・完了」から選びます。
- ラベル（リリース名・四半期・テーマなど）で色分け・絞り込み、担当者の指定、Epic同士の前後関係、子ストーリーの紐付けに対応。
- **ストーリー同士・Epic同士の依存関係** — 「先に終わらせるべきEpic」をEpicの詳細パネルで指定でき、ロードマップ上に前後関係として表示されます（[依存関係](https://pmonrails.com/docs/tasks.md)はタスク・シナリオでも設定できます）。
- **ストーリーの期間は開発サイクルに依存しません** — ストーリー自身の開始日・終了日を持ち、ロードマップ上でドラッグして変えられます（どの開発サイクルでやるかはカンバンで決めます）。

## 開発サイクル（期間で区切る）

![PM on Railsの開発サイクル。期間、割り当て、進み具合が見える。導入前は『今スプリントで何をやるか』が口頭だった。導入後は日付でサイクルが進む。](https://pmonrails.com/docs-img/cycles.png)

開発サイクルとは、「この期間でここまで進める」という**反復の単位**のことです（サイドバーの「計画・設計 → 開発サイクル」）。だらだら進めるのではなく、一定の期間で区切って「その間にやることを決める → 進める → 終わったら振り返る」を繰り返すことで、進み具合とペースが見えるようになります。1〜2週間など、チームに合った長さで区切るのが一般的です。

- **サイクルを1本作る** — 「いつからいつまで」の**期間（開始日・終了日）だけ指定**して開発サイクルを作ります。
- **このサイクルでやることを決める** — その開発サイクルに、今回こなすストーリー・タスクを割り当てます。ここで決めた分が「今回の約束」になり、バーンダウンやキャパシティの基準になります。
- **状態は日付から自動で進む** — 「準備中 → 進行中 → 完了」は開始日・終了日から自動で計算されます。手動で切り替える必要はありません。終了日を過ぎると完了通知が自動で送られます。
- **やり残しは次のサイクルへ** — 繰り越しを有効にした開発サイクルが終わると、未完了のタスクを次のサイクルへ自動で移します。
- 割り当てたタスクは、ストーリーごとにまとまった**カンバン**で日々動かします。

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

**カンバンは既定で「今の開発サイクル」に絞られます。** 選択中の開発サイクルに割り当てられたストーリー・タスクだけが表示され、上部の表示切替（「今のサイクル」／「バックログも表示」）でサイクル未割り当て（バックログ）も混ぜて表示できます。バックログのストーリーは「バックログ全件を開発サイクルに追加」でまとめて今のサイクルに取り込めます。

## バーンダウンとベロシティ（消化ペース）

ダッシュボードに、進行中の開発サイクルの消化状況がグラフで出ます。

![PM on Railsのバーンダウン。残作業が日付に沿って減るかが見える。導入前は遅れが納期直前まで見えなかった。導入後は未決を残したまま進んだ損失が週単位で見える。](https://pmonrails.com/docs-img/burndown.png)

- **全体（スコープ）と完了量** — 全体の見積もり合計（上の線）と、これまでに完了した量（伸びていく線）を毎日記録します。今日の位置と、残り日数（網かけ）も示します。上の例では「全体23h / 完了12h（52%）/ 残り11h」。
- **スコープの増減も反映** — 途中で追加されたタスクは全体の線に反映されるので、「やることが増えていないか」も分かります。
- **数え方** — 実績は開発サイクル開始後に完了にしたタスクだけを数えます（開始前から完了済みのものは含めません）。
- **ペースの推移と予測（ベロシティ）** — 過去の開発サイクルの消化ペースから、次のサイクルで「どれくらい入れられそうか」の目安を出します。

> バーンダウンが動かないときは、開発サイクルが**進行中**（開始日 ≤ 今日 ≤ 終了日）か、タスクがストーリー経由で開発サイクルに紐づいているかを確認してください。

## メンバーの負荷（入れすぎを防ぐ）

開発サイクルに作業を詰め込みすぎていないかを、メンバーごとに見える化します。

- **作業できる量（キャパシティ）** — メンバーごとに「1開発サイクルでこなせる量」を設定します（例: 13ポイント）。
- **稼働率** — その開発サイクルで、その人をどれくらい使えるかの割合です（休暇・兼務などで減ります）。例: 半分しか入れないなら50%。
- **実際に使える量** — キャパシティ × 稼働率。例: 13ポイントの人が稼働率50% なら **6.5ポイント**。
- **負荷の表示** — 「割り当て済みの量 ÷ 使える量」で、各メンバーの混み具合を色分けします。
  - 余裕あり
  - **警告（90% 以上）** — そろそろいっぱい
  - **過負荷（120% 以上）** — 入れすぎ。割り振りを見直す合図（例: 使える量6.5ポイントの人に8ポイント割り当て → 約123%）

> キャパシティを設定していないメンバーは負荷表示に出ません。設定は「プロジェクト設定 → 連携 → キャパシティ / 稼働率」から行います。

## つながりを辿る（トレーサビリティ）

- どの項目からでも**前後の両方向にたどれます**（要求 ⇄ 要件 ⇄ ストーリー ⇄ シナリオ ⇄ タスク、最大6段先まで）。
- 「この要件はどの要求が根拠か」「この決定の影響を受ける要件は」をすぐ確認できます。会話（[AIアシスタント](https://pmonrails.com/docs/ai-assistant.md)）やエンジニア向けの [MCP](https://pmonrails.com/docs/mcp.md) からも使えます。

## 自動見積もり（AI ＋ 個人差の補正）

タスクの編集画面（カンバンでタスクを開いて「編集」）の「AI見積もり」から使います。

![PM on RailsのAI見積もり。提案値と根拠が見える。導入前は見積もりが勘と経験だった。導入後は人が採否を選び、値はストーリーとタスクに残る。](https://pmonrails.com/docs-img/estimate.png)

- タスクの内容と前後の情報から、**2段階の見通し**（標準の見込みと、余裕を見た見込み）をAIが提案します（最終決定は人）。
- 担当者の過去の**所要時間（着手から完了まで）** をもとに、「この人がやるなら約6時間（余裕を見て9時間）」と**推奨値**を表示します。着手後に担当変更されたタスクは、最終担当者の実績として全量カウントせずサンプルから外します。
- 注意: この所要時間は待ち時間も含むため、純粋な作業工数ではなく「かかる時間の予測」です。データが少ない人はチーム平均に寄せて控えめに見積もります。

## 次のステップ

- [AIアシスタント](https://pmonrails.com/docs/ai-assistant.md) / [Claude Web・Claude Code・MCP連携](https://pmonrails.com/docs/mcp.md)

---

https://pmonrails.com/docs/progress