# 基本のことば（用語と関係）

PM on Railsで出てくる言葉を、つながりの順に説明します。専門知識は不要です。

![PM on Railsの要求カード一覧。『誰として何をしたいか』、背景、受け入れ条件、優先度がカードで並ぶ。導入前は希望と決定が混ざっていた。導入後は未決だけを聞いてから範囲を決められる。](https://pmonrails.com/docs-img/demands.png)

## 全体の流れ

> 議事録・資料 → 要求カード → 要件 → ユーザーストーリー → 受入シナリオ ／ タスク

「要望を出す人の言葉」から始まり、だんだん「開発できる形」へ具体化していきます。

## ひとつずつ

| ことば | かんたんに言うと |
| --- | --- |
| プロジェクト | 1つの案件。要求やタスクはこの中に入ります |
| 議事録・資料（ナレッジ） | 打ち合わせの記録やもらった資料。すべての出発点 |
| 要求カード（Demand） | 「[誰] として [何] したい」というステークホルダーの要望 |
| 要件（Requirement） | 非機能要件・制約。機能仕様はユーザーストーリーの概要に書く |
| ユーザーストーリー（User Story） | 開発の単位。「アクターが〜できる」。概要にステークホルダー向けの機能仕様を書く |
| 受入シナリオ（Scenario） | 「こういう状況で・こう操作すると・こうなる」という完成の確認手順 |
| タスク（Task） | 実際の作業。ストーリーの下に付く（不具合＝バグもタスク） |
| カンバン | タスクを「未着手 / 進行中 / レビュー / 完了」で動かすボード |
| トレーサビリティ | 要求から実装までの「つながり」を辿れること |
| グラフ | 情報を表ではなく「点と線のつながり」で持つしくみ（[AIのしくみ](https://pmonrails.com/docs/graphrag.md)） |
| AI抽出・構造化 | 議事録から要求やストーリーをAIが自動で起こすこと |

## 要求と要件は別もの

- **要求** = ステークホルダー（お客さん・事業側・チームメイトなど、要望を出す人）の「こうしたい」。合意するのはここまで。
- **要件** = エンジニアの「ではこう作る」という技術提案。

分けて管理することで、「なぜ作るのか」と「どう作るのか」が混ざりません。

## 画面との対応

左メニューの「作業の流れ」の各画面が、この流れの各段階に対応しています（資料・議事録 / 要求カード / スコープ確定 / ストーリー・シナリオ / レビュー・未確定事項 / カンバンで実装 / テスト・フィードバック）。

流れは一周で終わらず、2つのループで回します。

- **実装の前 — DoRを満たすまで繰り返す**（要求カード〜レビュー・未確定事項）: ステークホルダーの声を要求に整理し、作る範囲を決めて、ストーリー・シナリオにします。実装の前に必ずレビューを挟みます。「レビュー・未確定事項」の画面からストーリーをAIレビューにかけると、決まっていないこと・シナリオどうしの矛盾・要件との食い違い・異常系や境界値の抜けが指摘されます。ステークホルダーに確認すること・自分たちで決めることを確認事項として残し、回答を反映して、再レビューします。着手の条件（DoR）を満たすまでこれを繰り返します。
- **実装の後 — テストとフィードバックで直す**（カンバンで実装〜テスト・フィードバック）: DoRを満たしたものから実装し、受入シナリオをテストして、レビューとステークホルダーのフィードバックをもらいます。指摘は更新案として要求・シナリオに反映します。実装済みのタスクには対象ストーリーの修正タスクが提案され、承認するとカンバンに追加されるので、そこで実装を直します。新しい要望は要求カードとして次の周回に回します。

工程以外の画面は、その下の「確認・共有」「計画・設計」「資料の取り込み」「履歴」「設定」にまとめています。必要なグループを開いて使います。

---

https://pmonrails.com/docs/concepts