# 対象者別ガイド

失敗の出方は役割で違います。ログインして最初に開くのは、どの立場でもAIアシスタントです。プロジェクト参加時に選んだ役割（PM・一人で担当 / エンジニア / 確認・レビュー担当）に合わせて案内と最初の3手順が変わります。

![PM on RailsのAIアシスタント。会話の下に確認カードが出ている。資料を添付すると、要求・確認事項・タスクは確認カードを承認したあとだけ作られる。実行を押すまで、何も書き換わらない。](https://pmonrails.com/docs-img/chat.png)

詳しい説明は立場別ガイド（[発注](https://pmonrails.com/method/client) / [PM](https://pmonrails.com/method/pm) / [エンジニア](https://pmonrails.com/method/engineer)）にあります。このページは、自分の課題と画面で何が変わるかを確認してから操作へ進むためのページです。

## PM・一人でプロジェクトを担当する方へ

**誰:** 要望を出す人と開発のあいだで、要件定義と進捗を追いかけている人。

**失敗の型:** 議事録を読み直して要件定義書を完成させ、機能を積み上げる。

**画面で起きること:** 議事録から、誰が何のために必要としているか、作らないこと、完成条件、タスクまでがつながったまま整理されます。文書づくりではなく判断に時間を使えます。

| いま | これから |
| --- | --- |
| 会議のあとに議事録を読み直し、機能リストを渡す | 誰が何のために必要としているかが整理され、範囲と完成条件を決められる |
| Slackの回答を反映し忘れる | 回答を記録して解決すると仕様の更新案が自動で作られ、人が確認して適用する |

**なぜ今か:** 実装が速くなるほど、「ついでに作ろう」が増えます。

**なぜこのプロダクトか:** 要件定義書を仕上げるための道具ではありません。要望から完成条件までが途切れずにつながるので、文書づくりではなく判断に時間を使えます。

![PM on Railsの確認事項。未決の質問と回答待ちが一覧になる。ヒアリングで固める前の未決事項が、この一覧に残る。](https://pmonrails.com/docs-img/clarifications.png)

次に見る画面は、次のとおりです。

- [ナレッジに集める](https://pmonrails.com/docs/knowledge.md) — 議事録・資料・音声をためる
- [要求カードを作る](https://pmonrails.com/docs/demands.md) — AI抽出 → 希望と決定を分ける
- [スコープを確定する](https://pmonrails.com/docs/scope.md) — MoSCoWで作る／作らないを合意
- [ユーザーストーリー](https://pmonrails.com/docs/stories.md) — 開発単位へ展開
- [確認事項](https://pmonrails.com/docs/clarifications.md) — 聞くべきことを横断で見る
- [進捗を管理する](https://pmonrails.com/docs/progress.md) — ロードマップ・開発サイクル・カンバン・遅延検知
- [AIアシスタント](https://pmonrails.com/docs/ai-assistant.md) — 会話で整理・要約・進捗確認

## エンジニアの方へ

**誰:** Claude Code / Codexに毎日コードを書かせる人。

**失敗の型:** 機能リストとタスク名だけを渡され、完成条件が無いまま推測で書く。

**画面で起きること:** 誰が何のために必要としているかと完成条件がつながった状態で実装に入れます。PRの動きはタスクと進捗に反映されます。

| いま | これから |
| --- | --- |
| 実装前に機能リストを探し、どこを直すかを推測する | 背景と完成条件を読んでから着手する |
| 実装は進んでいるのに、カンバンの更新が溜まる | PRがタスクと進捗に反映され、報告作業がなくなる |

**なぜ今か:** コーディングエージェントは、指示どおりに速く作ります。渡すものが機能リストだと、使われないものが速くできあがります。

**なぜこのプロダクトか:** タスク名だけを渡すと、AIは推測で書きます。誰が何のために必要としているかと完成条件がつながったまま渡るので、指示書を書かなくても実装できます。

次に見る画面は、次のとおりです。

- [Claude Web・Claude Code・MCP連携](https://pmonrails.com/docs/mcp.md) — 外部AIツールから同じ情報を操作
- [ユーザーストーリー・シナリオ](https://pmonrails.com/docs/stories.md) — 受入シナリオ（Gherkin）
- [基本設計](https://pmonrails.com/docs/basic-design.md) — API設計書・DB設計書（AI叩き台）
- [タスク管理](https://pmonrails.com/docs/tasks.md) / [バグと変更管理](https://pmonrails.com/docs/bugs-changes.md) — 種別・見積もり・カンバン・影響範囲
- [GitHub連携](https://pmonrails.com/docs/github.md) — Issue同期・PR紐付け（featureブランチへのマージは待ち、mainに届いて完了）
- [進捗を管理する](https://pmonrails.com/docs/progress.md) — トレーサビリティ・自動見積もり

参加時に「エンジニア」を選ぶと、既存の仕様・資料 → 作業と担当 → 開発で使うAIの接続、の順に案内されます。

![PM on RailsのClaude Code / Codex連携。背景と完成条件がつながったまま渡る。仕様探しとボード更新を、実装の流れの中で済ませるための連携。](https://pmonrails.com/docs-img/mcp-tools.png)

## ステークホルダー（要望を出す側）の方へ

**誰:** 要望がどう反映され、いつリリースされるかを見たい人（お客さん・事業側・社内の依頼者など）。原則は閲覧専用です。

**失敗の型:** ヒアリングで固めて丸投げし、リリースで「違う」となる。

**画面で起きること:** 要求カード、スコープ確定、ロードマップで、誰のための要望がどう入り、いつリリースされるかを自分で確認できます。

| いま | これから |
| --- | --- |
| 報告を待ち、機能リストがどこに入ったのか追えない | viewerで要求、範囲、予定を見られる |
| 「できた／違う」がリリース直前に起きる | 完成条件とテスト結果、必要ならバグ報告を残せる |

**なぜ今か:** 開発が速くなるほど、間違った発注の追加費用は大きくなります。

**なぜこのプロダクトか:** 新しいツールを覚える必要はありません。見る箇所が決まっていて、気になる点はコメントで残せます。

次に見る画面は、次のとおりです。

- 招待されると、参加したプロジェクトを **viewer（原則閲覧専用）** で見られます。コメントに加え、受け入れ確認のテスト結果と受入シナリオに紐づくバグ報告は追記できます。
- [要求カード](https://pmonrails.com/docs/demands.md)（自分の要望がどう要求になったか）、[スコープ確定](https://pmonrails.com/docs/scope.md)（今回どこまで作るか）、[ロードマップ](https://pmonrails.com/docs/progress.md)（いつ何が出るか）
- 権限の考え方 → [メンバーと権限](https://pmonrails.com/docs/members.md)

![PM on Railsのロードマップ。予定と今作っているまとまりが見える。報告を待たずに、要望の行き先とリリースの時期を自分で確認できる。](https://pmonrails.com/docs-img/roadmap.png)

> ステークホルダーは原則閲覧専用です。コメント、テスト結果、受入シナリオに紐づくバグ報告は追記できますが、既存記録や仕様は変更できません。作業もする業務委託の方は編集ロールなど別ロールで招待します（[メンバーと権限](https://pmonrails.com/docs/members.md)）。

---

https://pmonrails.com/docs/audiences