# おすすめの運用（フェーズ別）

PM on Railsは「人がやらなくていいことはAIと自動化に回す」前提で作られています。フェーズごとの使い方の例を、**どの手作業が消えるか**と一緒に見ていきます。チームのやり方に合わせて調整してください。

大事な前提がひとつあります。これは**一方通行の工程表ではなくループ**です。打ち合わせのたびに要求は変わり、テストのたびに不具合が見つかり、それが要求・要件へ戻って次の周回の材料になります。PM on Railsは、この「戻り」を、例外ではなく普通のこととして扱えるように作られています。

```mermaid
flowchart LR
  A["ためる（議事録・資料）"] --> B["要求カード"]
  B --> C["スコープ確定"]
  C --> D["ストーリー・受入シナリオ"]
  D --> R["レビュー・未確定事項"]
  R -->|DoR を満たすまで回答を反映| D
  R -->|DoR を満たした| E["実装（タスク・PR）"]
  E --> F["テスト・フィードバック"]
  F -->|指摘を反映して修正タスクに| E
  F -->|新しい要望は要求カードへ| B
  A -->|次の打ち合わせ| B
```

## どのフェーズでも操作のリズムは同じ

画面ごとに使い方を覚える必要はありません。PM on Railsの操作は、どのフェーズでもほぼ同じ3つの手順で進みます。

1. **材料を入れる** — 議事録・資料・録音・会話。
2. **AIが叩き台を出す** — 要求カード、ストーリーと受入シナリオ、レビュー指摘、設計書の下書き、見積もり。
3. **人が確認して確定する** — 「新規 / 更新 / スキップ」を選ぶ、編集して保存する、承認する。

このリズムを支える共通の性質が4つあります。

- **AIが勝手に確定することはありません。** 生成はすべて提案・下書きで、取り込むかどうかは必ず人が選びます。
- **時間のかかる生成は[バックグラウンド](https://pmonrails.com/docs/jobs.md)で動きます。** 実行中も別の作業を続けられます。
- **開発が始まると、進捗は作業に連動して自動で進みます。** 状態を手で更新して回る仕事はありません（PRが既定ブランチ（main）に届いて完了、開発サイクルは日付で進行）。
- **何かが変わると、バッジや通知で向こうから知らせてきます。** 変更を探しに行く必要はありません。

## 入口は画面だけではありません

同じグラフに、立場と場面に合った入口からアクセスできます。**どこから操作しても同じデータが更新され、同じ権限・同じ業務ルールが効きます。**

| 入口 | 向いている場面 |
| --- | --- |
| 画面（UI） | ステークホルダーと画面を見ながら合意する、ロードマップ・カンバンで全体を見渡す |
| [アプリ内AIアシスタント](https://pmonrails.com/docs/ai-assistant.md) | ログイン後の入口。資料を添付して「進捗は？」「この要望まとめて」と会話で整理・確認 |
| 右側のAIチャット（各画面） | 画面を見ながら「この画面」「このストーリー」と指して相談・指示する。会話はプロジェクトごとに続く |
| Claude（Web / デスクトップ）のコネクタ接続 | PMが画面を開かずに、チャットから要求の起票・優先度の変更・進捗確認などの日常の管理を済ませる |
| [Claude Code / Codex](https://pmonrails.com/docs/ai-coding.md) | エンジニアが実装作業の中からタスク・シナリオを読み書きする |

Claudeのコネクタ接続は、接続時にPM on Railsのログインと同意画面で承認するだけです（承認した権限の範囲でのみ操作できます）。

## 要件定義フェーズ（PM × ステークホルダー）— 書き写しと拾い直しをなくす

打ち合わせのたびに、同じ3手順を繰り返します。

1. **ためる** — 議事録・資料は[ナレッジ](https://pmonrails.com/docs/knowledge.md)で作成・取り込み。録音・動画は「動画・音声を取り込む」から追加すると文字起こしされます。
2. **要求カードにする** — フォルダ単位・プロジェクト全体でまとめて[要求カード](https://pmonrails.com/docs/demands.md)を生成します。結果は確認パネルに並び、「新規作成 / 既存を更新 / スキップ」を選んで取り込みます。MoSCoW・5Why・潜在ニーズ・推定価値が付いた状態で出てくるので、**ゼロから文書を書く工程がなく、人は直すだけ**です。
3. **ステークホルダーと合意する** — [スコープ確定](https://pmonrails.com/docs/scope.md)画面を一緒に見ながら、カードをドラッグして「必須 / 重要 / できれば / 今回は見送り」を決めます。右のパネルで人の判断3軸（ビジネス重要度・受け入れやすさ・実装の容易さ）を調整でき、**AIの優先度と人の判断がズレているカードは「議論すべきカード」の目印**になります。合意はそのまま下流に流れるので、あとで議事録を掘り起こす作業が消えます。

「今回やらない」を明示すると、その要求から作られた要件も自動で対象外になります。認識のズレを防ぐのに一番役立つのは、この操作です。

## 設計フェーズ（PM → エンジニア）— 下書きを白紙から書かない

- 確定した要求から、[ユーザーストーリーと受入シナリオ](https://pmonrails.com/docs/stories.md)を一括生成します（1要求から1〜5個）。方向性が違えば全件作り直せます。
- 受入シナリオは「こういう状況で・こう操作すると・こうなる」の形なので、**ステークホルダーが読んで確認できる完成基準**になります。ここで合意しておくと「できた／できていない」で後から揉めません。
- 着手前に[要件のAIレビュー](https://pmonrails.com/docs/stories.md)で、矛盾・抜け漏れ・曖昧さ・技術的な確認事項を機械的に洗い出します（質問と回答の回し方は次節）。
- 実装のもとになる[基本設計（API設計・DB設計）](https://pmonrails.com/docs/basic-design.md)を、AI叩き台とmermaid図で作ります。白紙に向かう時間をなくします。
- 採用判断・設計判断は[決定の記録](https://pmonrails.com/docs/decisions.md)へ。「なぜこうしたか」を後から思い出す会議が減ります。

## ステークホルダーへの質問と、回答の反映

要件を固める途中で必ず出る「これはどっちですか？」の往復を、Slackのやりとりと承認だけで回せるようにしてあります。

1. **質問はAIがまとめます** — [要件のAIレビュー](https://pmonrails.com/docs/stories.md)の指摘には、**そのままステークホルダーへ送れる質問文**が付きます。指摘は質問として要件に紐づけて残せるので、聞くべきことの一覧＝質問票として[確認事項](https://pmonrails.com/docs/clarifications.md)に横断で集まります。聞き漏らしを頭で覚えておく必要がなくなります。
2. **Slackへは共有先を選んで送れます** — Slack連携を設定していれば、確認事項の「Slackに共有」で、プロジェクトに登録済みのAgent/共有先チャンネルや通知先チャンネルから送信先を選んで投稿できます。共有後はそのSlackスレッドに固定され、以後の返信は同じスレッドから取り込まれます（共有できるのはviewer以上です。viewerにはAgent/共有先チャンネルだけを見せ、通知先チャンネルの存在は見せません。「質問をまとめてコピー」してメールに貼るのでもかまいません）。相手に新しいツールを覚えてもらう必要はありません。
3. **Slack botから未決事項を展開できます** — プロジェクトに紐づいたSlackチャンネルで `@pm-on-rails 未決事項` と書くと未解決の確認事項を一覧できます。`@pm-on-rails 未決事項 展開` と書くと、そのチャンネルに未共有の確認事項を投稿します。Botは発言されたチャンネルの紐づけから対象プロジェクトを判定し、登録されていないチャンネルには展開しません。
4. **Slackの返信を議論ログとして残せます** — 共有した質問のスレッドに相手が返信すると、その内容はPM on Railsの子コメントとして取り込まれます。議論の途中で回答がまとまることもあるため、発言を勝手に正式回答へ昇格せず、会話ログとして残します。取り込まれるのは、同じメールアドレスまたは明示リンク済みのSlackアカウントで、対象プロジェクトを閲覧できるメンバーの返信だけです。こちらから画面で返した内容も同じスレッドへ届くので、会話はSlackとPM on Railsのどちらで見ても同じです。
5. **未決事項のアジェンダも作れます** — 確認事項に残っている未回答・議論中の質問をAIアシスタントやClaude WebのMCP連携に読ませると、次回MTG用のMarkdownアジェンダをすぐ作れます。似た質問をまとめ、決めたいこと・こちらの推奨案・先方に聞く文面まで整理しておくと、そのまま打ち合わせに使えます。作ったMarkdownは[ナレッジ](https://pmonrails.com/docs/knowledge.md)の文書として保存しておくと、次回以降のAIも根拠として参照できます。
6. **回答は仕様へ戻ります** — 回答が付いて解決すると、AIがその内容を踏まえた要件・ストーリー・シナリオへの**更新案**を作ります（回答が変わったときは作り直します）。Slackの返信は会話ログとして残るだけなので、まとまった回答を回答欄に記録してから解決します。更新案は**承認待ち**で残り、確認事項画面の「承認待ちの更新案」で1件ずつ、または「すべて適用」でまとめて適用するまで仕様は変わりません。急ぐときは確認事項ごとの「更新案を作る」でその場で作れます。転記も転記漏れもありません。

「質問を表計算にまとめて、回答をもらって、手で要件書を直して、直し漏れを探す」という一連の作業が、**Slackのやりとりと承認だけ**に置き換わります。

## 計画フェーズ（PM × エンジニア）

作るものが決まったら、「いつ・どれだけやるか」を区切ります。

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

- **ロードマップに並べる** — Epicのバーをドラッグして「いつ何を出すか」の大枠を置きます（[進捗の見える化](https://pmonrails.com/docs/progress.md)）。
- **開発サイクルを切る** — 1〜2週間など、チームに合った長さの**期間（開始日・終了日）だけ指定**して開発サイクルを作ります。状態（準備中 → 進行中 → 完了）は日付から自動で進むので、切り替え操作はありません。
- **今回やる分を割り当てる** — そのサイクルでこなすストーリー・タスクを割り当てます。ここで決めた分が「今回の約束」になり、バーンダウンとメンバー負荷の基準になります。カンバンは既定で「今のサイクル」に絞られるので、日々見るのは今回の約束だけです。
- **見積もりの叩き台はAIが自動で入れます** — 空欄のまま進捗が読めなくなることがありません（最終決定は人）。
- **入れすぎを防ぐ** — メンバーごとのキャパシティ × 稼働率に対する割り当て量が色分け表示され、過負荷（入れすぎ）が割り振りの見直し合図になります。
- **やり残しは自動で次へ** — 繰り越しを有効にしたサイクルが終わると、未完了タスクは次のサイクルへ自動で移ります。過去サイクルの消化ペース（ベロシティ）から、次に入れられる量の目安も出ます。

## 実装フェーズ（エンジニア）— 仕様の説明資料と進捗入力をなくす

**エンジニアがPM on Railsの画面をほとんど開かずに済む**、というのが狙いの体験です。[Claude Code / Codex](https://pmonrails.com/docs/ai-coding.md) から会話で進めます。

1. 「今の開発サイクルの未着手タスクを見せて」— 一覧が返ります。
2. 「このタスクの背景と受け入れ条件は？」— 要求 → 要件 → ストーリー → シナリオと、**つながりごと**返ります。仕様を説明し直す資料を作らなくてよくなります。
3. 着手すると、**ブランチ名とPR本文に貼る1行**が応答に含まれます。そのまま使えばタスクとPRが紐づきます（[GitHub連携](https://pmonrails.com/docs/github.md)）。
4. PRが既定ブランチ（main）にマージされると、タスクは自動で「完了」になり、親ストーリーの状態も再計算されます。featureブランチへのマージは「待ち」として記録され、そのブランチがmainに届いた時点でまとめて完了します。進捗の入力も催促も不要です。

### なぜAIエージェントで「いい感じに」開発できるのか

コーディングエージェントの精度は、**渡されるコンテキストの質**で決まります。PM on Railsが役に立つのは、そこです。

- **背景ごと渡るから** — タスク単体ではなく、要求 → 要件 → ストーリー → 受入シナリオのつながりごとエージェントに渡ります。「なぜ作るのか」「どうなれば完成か」を知った状態で実装が始まるので、思い込みで書かれたコードが減り、PMへの聞き直しの往復も減ります。
- **完成基準が機械可読だから** — 受入シナリオは「こういう状況で・こう操作すると・こうなる」の形式なので、エージェントがそのままテストの根拠にできます。
- **報告作業がないから** — 着手・PR紐付け・完了がすべて実装の流れの中で自動につながり、エージェントも人も進捗報告のための操作をしません。
- **途中の変化に気づけるから** — 実装中にPM側で仕様が変わっても、「自分が着手したあとに上流が変わった」ことを検知できます。古い仕様のまま作り切ってしまう失敗を防ぎます。
- **任せても安全だから** — 画面と同じ権限・業務ルール・安全確認がエージェントの操作にも効きます。

PM側から見ると、**誰も状態を手で更新していないのに[カンバンとバーンダウン](https://pmonrails.com/docs/progress.md)が動きます**。期限切れ・放置されたタスクは毎朝自動で検知され、担当者へ通知されます。進捗確認の定例で「今どこまで進んでますか」と聞いて回る時間がなくなります。

## テストフェーズ — 「何を確認すべきか」を考え直さない

- 受入シナリオがそのまま確認項目なので、テスト観点を別途起こしません。
- [テスト](https://pmonrails.com/docs/test-results.md)画面で、受入シナリオごとの合否（合格 / 不合格 / スキップ）を記録します。開発側（CIなど）からの取り込みにも対応します。
- 不合格のシナリオからは、その場で**バグを起票**して、普通のタスクと同じカンバンに流せます。
- カバレッジと合格件数で、「どこまで本当に完成したか」を要求から一続きで確認できます。

## バグ対応・改修フェーズ

不具合が見つかったあとも、要求からの一続きで管理できます。

1. **バグを起票** — 「不具合（バグ）」タスクとして起票し、重大度と**影響範囲（どのシナリオ・要件に影響するか）** を記録します。
2. **カンバンで対応** — ほかのタスクと同じカンバンで進めます。専用の別画面はありません。
3. **解決を記録** — 「修正した / 対応しない / 重複 / 再現せず」の区分と理由を残します。
4. **再発防止は要件へ** — 「仕様として直すべき」なら、バグから新しい要求・要件を起こします（[バグと変更管理](https://pmonrails.com/docs/bugs-changes.md)）。
5. **変更リクエストで仕様を更新** — 要件やシナリオの変更案を出し、承認 → 適用で新しい版を生成。回帰テストの合格を根拠付きで記録し、「マージ確定」で取り込むと、**関連するバグは自動でクローズ**されます。

この「バグ → 解決 → 再発防止の要件化 → 変更リクエスト → 再テスト」がつながって回るので、直したことが場当たりの修正で消えず、次の改善の材料として残ります。

## 定例のあと・仕様変更が起きたとき — 影響の追跡と追随を人手でやらない

次の打ち合わせが来たら、要件定義フェーズと同じ3手順に戻ります。違うのは2回目以降の挙動です。

- **既存カードとの差分つきで提案されます** — 新しい議事録から抽出した要求を、[差分チェック](https://pmonrails.com/docs/change-tracking.md)が既存カードと意味で照合します。勝手に統合はせず、候補を最新順に「どの項目がどう変わるか」の差分つきで提示するので、選んで適用するだけです。どこが変わったかを目視で突き合わせません。打ち合わせを重ねるほど、カードが増えるのではなく、**同じカードが更新されていきます**。
- **下流が自動で気づけます** — 要求・要件を更新すると変更が記録され、ユーザーストーリー画面に「未確認の上流変更」として件数つきで表示されます。何がどう変わったか（変更前後）と影響するストーリー・シナリオを確認でき、確認状況は人ごとに管理されます（他の人が確認しても自分の未確認は残ります）。さらに **AIが下流（要件・ストーリー・シナリオ）への更新案を自動で用意する**ので、追随作業は承認だけで済みます。着手後に上流が変わったタスクは、PRマージ時に「再確認が必要」とマークされます。
- **関係者に通知が届きます** — アプリ内のベル・メール・毎朝のダイジェストで伝わります（[通知とSlack](https://pmonrails.com/docs/notifications.md)）。
- **大きな仕様変更は新しい版で** — 上書きせず要件・シナリオを新しい版に切り替え、古い版も履歴として残します。「変わったことに誰も気づかないまま実装が進む」が起きません。

## 外部委託先・お客さんと一緒に使うとき

- 作業する委託先は**編集ロール（editor）** で招待します。カンバン・タスクを直接動かせます。
- お客さん・事業側は **viewer（原則閲覧専用）** で招待します。要求カード・スコープ確定・ロードマップを見てもらい、コメントや受け入れテスト結果、受入シナリオに紐づくバグ報告を追記してもらえます（[メンバーと権限](https://pmonrails.com/docs/members.md)）。

> ここはコードで確認できる機能に沿った運用例です。

---

https://pmonrails.com/docs/workflow