# コードとチーム資料から引き継ぎ文書を作る
> 担当者が変わっても実装範囲が分からない。企画メモとコードを照合し、実装済み機能と未完了の要望を分けます。実行方法と次の担当者の確認一覧を残します。
担当者が変わるとき、企画メモと実際のコードを照合し、次の担当者が使える引き継ぎ文書を作ります。
## こんな問題があるとき
メモに要望と完了作業が混在すると、次の担当者は実装範囲を把握できません。実行方法や運用情報も分散していると、同じ質問を繰り返し、未完了の要望を見落としやすくなります。
## Specifyで解決する
1. プロジェクトメモと版を記録したコードスナップショットをSpecifyに用意します。
2. AIに要望と実装を照合させ、完了機能・上限・未実装項目と根拠を区別します。
3. 実行方法と次の担当者の確認一覧を保存し、コードでは分からない運用情報を担当者が補完します。
## 得られる成果物
開発チーム・受託開発会社・保守担当者向けの引き継ぎ文書を作成します。RelayDesk Demoは架空のプロジェクトで、アップロードしたコードのスナップショットとプロジェクトメモの原文を照合します。
## 用意する資料
サンプル資料とコードをダウンロードし、次の2文書をワークスペースにアップロードします。
| 資料 | 役割 |
| --- | --- |
| `relaydesk-project-brief.md` | 要望、決定記録、担当する役割、運用上の未確認情報 |
| `relaydesk-code-snapshot.md` | 固定した版の実装コード・テスト・実行コマンド |
スナップショットはリポジトリの現在の状態ではありません。版・コミット・対象範囲を記録し、変更後に資料を更新してください。GitHubブランチを直接接続する方法は[ドキュメントプロジェクト](/ja/guides/doc-projects)で確認できます。
## 操作の流れ
要求メモ、コードの写し、実行案内を集め、それぞれの版を明記します。例のポリシーを実装済みセキュリティ対策の証拠にはしません。
新しいチャットで新規開発者や保守担当者などの読者と、読む資料の名前を指定します。
実装済み機能、実装上限、後続要望、確認できない項目を分けます。各判断に文書IDとコードのパスを求めます。
文書を保存してコマンドを確認し、運用上の未確認事項の担当を決めます。テストファイルの存在だけで、実行や性能検証が完了したとは判断しません。
```text
RelayDesk Demoの引き継ぎメモとコードスナップショット1.4を読んで比較してください。
概要 / 要望と実装の比較表 / 実行・検証方法 / 引き継ぎ確認一覧を作成してください。
コードで確認した機能・上限と、企画上の要望・未実装機能を区別してください。
文書IDと実際のファイルパスを根拠にし、運用・配備情報がなければ未確認としてください。
コードは固定した写しであることを明記し、ライブのリポジトリを調査したとは書かないでください。
「プロジェクト引き継ぎ」として保存し、原文は変更しないでください。
```
## この例で確認する違い
- 企画上の要望は10,000件ですが、実装の上限は1,000件です。
- 渡された役割パラメーターを検査するコードと、実際のログイン・権限発行システムを区別します。
- ZIP機能や実際の配備・復旧手順はこの例にありません。日程や運用担当者の実名を推測で補いません。
## 最新の状態を維持する
この実行はアップロードした原文とコードのスナップショットを直接参照しています。検索に未反映の資料は原文を指定して確認できます。スナップショット後の変更は結果の範囲外です。
新版の資料を準備して同じ依頼で差分を確認します。すべての運用文書が自動更新されるとは考えず、生成結果をチームの実際の引き継ぎ手順と照合してください。
リポジトリとブランチを文書生成に接続します。
営業や顧客対応でもチーム資料を活用します。