# PM on Railsとは

開発がうまくいかなくなる原因は、技術力より手前にあります。現場ヒアリングだけで要件を固め、機能を積み上げ、実物を見る前に契約すると、リリースのあとで「思っていたのと違う」が出ます。PM on Railsは、会話を「誰として何をしたいか」、作らないこと、前提・もし・ならば（完成条件）までつなげて整理します。新しく作るものは確認カードで承認してから作られ、既存のカードは差分を見て更新します。勝手には上書きしません。

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

## 失敗の出方は役割で違う

| 誰 | 失敗の型 | 画面で起きること |
| --- | --- | --- |
| PM | 要件定義書を完成させ、機能を積み上げる | 誰が何のために必要としているかと、今回作らないことを先に見せられる |
| エンジニア | 機能リストとタスク名から推測して書く | 背景と完成条件を読んでから書き始められる |
| ステークホルダー（要望を出す人） | ヒアリングで固めて丸投げし、リリースで「違う」となる | いまどこまで進んだかを自分で確認し、受け入れに参加できる |
| 経営者 | あれもこれも入れて、使われないものを買う | 判断の材料が会社に残る |

![PM on Railsの要求カード一覧。「誰として何をしたいか」、背景、受け入れ条件がカードで並ぶ。機能一覧の前に、誰のどんな困りごとかが整理される。](https://pmonrails.com/docs-img/demands.png)

詳しくは [対象者別ガイド](https://pmonrails.com/docs/audiences.md) と立場別ガイド（[発注](https://pmonrails.com/method/client) / [PM](https://pmonrails.com/method/pm) / [エンジニア](https://pmonrails.com/method/engineer)）へ。

## いまとこれから

| いま | これから |
| --- | --- |
| ヒアリングで固めて、一括発注する | 誰が何のために必要としているか、作らないこと、完成条件がつながったまま残る |
| 人が機能リストを書き、人が進捗率を更新する | AIが整理を支え、人は作る／作らないと完成条件を決める |
| 完成の判断がリリース直前になる | 完成条件を先に合意し、ダッシュボードとロードマップで追える |

![PM on Railsのダッシュボード。要求の準備、遅れ、サイクルが一覧になる。ヒアリングで固めていた材料が、ここで揃う。](https://pmonrails.com/docs-img/dashboard.png)

## なぜ今か

実装は速くなりました。何を作るかを決める速さは、変わっていません。「AIでコードが速く書けるから要件定義を短くしていい」は逆です。間違った要件のまま書くと、間違ったシステムが速くできあがります。

## なぜこのプロダクトか

立派な要件定義書を完成させるための場所ではありません。会話を、今回の範囲、利用者の目的、前提・もし・ならば、実装、動作確認までつなぎます。確認カードと差分チェックがあり、画面、Slack、Claude Codeのどこからでも同じ完成条件を扱えます。

![PM on Railsのスコープ確定。必須 / 重要 / できれば / 今回は見送りにカードを置く。あれもこれも積み上げる前に、作らないものを決める画面。](https://pmonrails.com/docs-img/moscow.png)

![PM on RailsのClaude Code / Codex連携。同じ完成条件を開発AIが読む。機能リストだけで書かせないための連携。](https://pmonrails.com/docs-img/mcp-tools.png)

## 最初に開くのはAIアシスタント

ログインすると、選んだプロジェクトの **AIアシスタント**が開きます。資料を添付して相談するところから始められ、要求カード・確認事項・タスクの作成は**確認カード**を見て「実行する」を押したときだけ行われます。作業中はどの画面でも、ヘッダの「AIに相談・指示」から**右側にチャット**を開いて続きを相談できます（「この画面」「このストーリー」と指して聞けます）。ダッシュボードはサイドバーの「ホーム」に残っています。

**スマートフォン幅**では、左上の「メニューを開く」から左のドロワーでサイドバーと同じ導線を開きます。カンバンなど主要画面は狭い画面向けの表示に切り替わります（PC幅では従来どおり左サイドバーが常時表示されます）。

## 全体の流れ

1. **ためる** — 議事録・メモ・資料・音声をナレッジに集める
2. **整理する** — AIが要求カードを自動生成し、希望と決定事項を分ける
3. **決める** — MoSCoWでスコープ（作る／作らない）を確定する
4. **設計する** — ユーザーストーリー・受入シナリオ・API / DB基本設計へ展開する
5. **開発する** — MCPでClaude Web / Claude Code / Codexから同じつながりを読み書きする
6. **進める** — ロードマップ・開発サイクル・カンバンで進捗を管理する
7. **出す** — MarkdownやGitHub Issue / PRへ書き出す
8. **戻す** — 変更リクエスト・バグ・確認事項・フィードバックを次の改善へつなげる

![PM on Railsのユーザーストーリー。要求から開発単位と完成条件へ展開する。ためる・整理する・決める、のあとの「設計する」に当たる画面。](https://pmonrails.com/docs-img/stories.png)

![PM on Railsのカンバン。未着手から完了までタスクが動く。「開発する」「進める」を、完成条件とつながった同じボードで扱う。](https://pmonrails.com/docs-img/kanban.png)

中心のつながりは、次のとおりです。

> 要求カード → 要件 → ユーザーストーリー → 受入シナリオ ／ 開発タスク

| つながり | 意味 |
| --- | --- |
| 資料 → 要求カード | その要求の根拠になった議事録・資料 |
| 採用の判断 → 要件 | 「作る」と決めた判断が要件を生む |
| 不具合 → シナリオ・要件 | その不具合が影響する範囲 |
| 新しい版 → 古い版 | 仕様を変えたときの履歴 |
| ストーリー → 開発サイクル・ロードマップ | いつ作るかの割り当て |
| 確認事項・フィードバック → 要求 / 変更案 | 確認事項への回答や運用中の声を次の改善へ戻す |

AIアシスタントは関連する情報をたどって答えます。利点は[AIのしくみ](https://pmonrails.com/docs/graphrag.md)を参照してください。

## 用語

| 用語 | 意味 |
| --- | --- |
| ワークスペース | プロジェクトやメンバーを管理する最上位の単位 |
| プロジェクト | 案件単位。要求・ストーリー・タスクはプロジェクトに属する |
| 要求カード | 「[誰] として [何] したい」形式で整理したステークホルダーの要求 |
| 要件 | 非機能要件・制約。機能仕様はユーザーストーリーの概要に書く |
| ユーザーストーリー | 要求から起こす開発単位。概要に機能仕様を書き、受入シナリオ・タスクを束ねる |
| 受入シナリオ | 「こういう状況で・こう操作すると・こうなる」で書く「できたかの基準」 |
| MCP | Claude Web / Claude Code / Codexなどの外部AIツールから操作するための接続口 |

> 操作へ進む方は「[クイックスタート](https://pmonrails.com/docs/quickstart.md)」へ。役割別に読む方は「[対象者別ガイド](https://pmonrails.com/docs/audiences.md)」へ。

---

https://pmonrails.com/docs/overview