本文へスキップ
SpecifyDocs

活用ガイド

コードとチーム資料から引き継ぎ文書を作る

担当者が変わっても実装範囲が分からない。企画メモとコードを照合し、実装済み機能と未完了の要望を分けます。実行方法と次の担当者の確認一覧を残します。

担当者が変わるとき、企画メモと実際のコードを照合し、次の担当者が使える引き継ぎ文書を作ります。

こんな問題があるとき

メモに要望と完了作業が混在すると、次の担当者は実装範囲を把握できません。実行方法や運用情報も分散していると、同じ質問を繰り返し、未完了の要望を見落としやすくなります。

Specifyで解決する

  1. プロジェクトメモと版を記録したコードスナップショットをSpecifyに用意します。
  2. AIに要望と実装を照合させ、完了機能・上限・未実装項目と根拠を区別します。
  3. 実行方法と次の担当者の確認一覧を保存し、コードでは分からない運用情報を担当者が補完します。

得られる成果物

開発チーム・受託開発会社・保守担当者向けの引き継ぎ文書を作成します。RelayDesk Demoは架空のプロジェクトで、アップロードしたコードのスナップショットとプロジェクトメモの原文を照合します。

CSV実装範囲と企画上の要望、役割制限、ZIP未実装を区別する引き継ぎ文書の比較表
企画書の要望を実装済みとみなさず、提供されたコードで確認した動作と比較します。

用意する資料

サンプル資料とコードをダウンロードし、次の2文書をワークスペースにアップロードします。

資料役割
relaydesk-project-brief.md要望、決定記録、担当する役割、運用上の未確認情報
relaydesk-code-snapshot.md固定した版の実装コード・テスト・実行コマンド

スナップショットはリポジトリの現在の状態ではありません。版・コミット・対象範囲を記録し、変更後に資料を更新してください。GitHubブランチを直接接続する方法はドキュメントプロジェクトで確認できます。

操作の流れ

  1. メモとコードの範囲を一緒に用意する

    要求メモ、コードの写し、実行案内を集め、それぞれの版を明記します。例のポリシーを実装済みセキュリティ対策の証拠にはしません。
  2. 新しいチャットで引き継ぎ先を指定する

    新しいチャットで新規開発者や保守担当者などの読者と、読む資料の名前を指定します。
  3. 要望と実装を比較する

    実装済み機能、実装上限、後続要望、確認できない項目を分けます。各判断に文書IDとコードのパスを求めます。
  4. 実行方法と確認項目をレビューする

    文書を保存してコマンドを確認し、運用上の未確認事項の担当を決めます。テストファイルの存在だけで、実行や性能検証が完了したとは判断しません。
RelayDesk Demoの引き継ぎメモとコードスナップショット1.4を読んで比較してください。
概要 / 要望と実装の比較表 / 実行・検証方法 / 引き継ぎ確認一覧を作成してください。
コードで確認した機能・上限と、企画上の要望・未実装機能を区別してください。
文書IDと実際のファイルパスを根拠にし、運用・配備情報がなければ未確認としてください。
コードは固定した写しであることを明記し、ライブのリポジトリを調査したとは書かないでください。
「プロジェクト引き継ぎ」として保存し、原文は変更しないでください。

この例で確認する違い

未確定の機能範囲、運用・復旧手順、試験記録、FAQ更新を整理した引き継ぎ確認一覧
説明だけで終わらず、次の担当者が確認すべき作業を残します。
  • 企画上の要望は10,000件ですが、実装の上限は1,000件です。
  • 渡された役割パラメーターを検査するコードと、実際のログイン・権限発行システムを区別します。
  • ZIP機能や実際の配備・復旧手順はこの例にありません。日程や運用担当者の実名を推測で補いません。

最新の状態を維持する

この実行はアップロードした原文とコードのスナップショットを直接参照しています。検索に未反映の資料は原文を指定して確認できます。スナップショット後の変更は結果の範囲外です。

新版の資料を準備して同じ依頼で差分を確認します。すべての運用文書が自動更新されるとは考えず、生成結果をチームの実際の引き継ぎ手順と照合してください。