# 動く試作品と、次の判断に必要な確認記録。 問い合わせ分類の試作を題材にした説明用レポートです。以下の記録と結果はすべて架空で、納品判断の記録方法を示しています。 問い合わせ分類PoCの引き継ぎ例を、合意した範囲から確認結果、残る課題、最終提案まで紹介します。着手前に、この粒度で成果物と判断方法をそろえます。 **受入レポート** · SUPPORT-POC / DEMO-01 提案例：未完了の2項目に確認記録がそろうまで、本番展開を保留します。 ## 01. 合意した業務フロー この例のチームは、問い合わせを受け取り、対応するキューへ手作業で振り分けています。最初に確かめたいのは、元の本文をレビュー担当者に見せたまま、適切な振り分け先を提案できるかです。自動返信とCRMの更新は対象に含めません。 合意する最小範囲は、架空のメッセージを入力し、提案を採用するか、人の確認が必要な状態を明示するところまでです。サポート責任者が分類基準を決め、開発者がビルドとテスト入力を記録します。発注側の責任者が書面の範囲に照らして受入を判断します。 テスト用の本文 → 分類の提案 → 人による確認 → 判断の記録 ## 02. 引き継ぎ資料の中身 ### 一通り動く利用経路 01 / 試作品 合意したデモ環境で、入力、レビュー一覧、判断状態までを確認します。利用者の作業を最初から最後までたどり、人の責任が残る箇所を把握できることが重要です。 ### 再現できるデモ手順 02 / デモ台本 開始条件、テストデータの識別子、操作順、期待結果をまとめます。説明会に参加していない同僚も、録画だけに頼らず同じ経路を再現できるようにします。 ### 受入確認の記録 03 / 受入レポート 各基準を、入力、期待結果、観察した結果、状態に結び付けます。確認したビルドを特定し、失敗した項目と、まだ試していない項目を区別します。 ### 未解決の課題と判断 04 / リスク記録 既知の制約、次の作業への影響、担当者、完了に必要な証拠を示します。主要なデモがうまく動いても、残る課題を見えなくしないための資料です。 ### コードと運用手順 05 / 引き継ぎメモ 合意したソース、設定手順、設定項目名、依存関係、復旧方法をまとめます。権利、ライセンス、アクセス、デプロイの責任は案件の契約に従います。 ### 次の範囲への提案 06 / 判断メモ 進める、範囲を絞る、追加資料を集める、止めるという選択肢から提案します。本番作業は別途見積もりと受入条件を定め、PoCから自動的に本番展開へ移行しません。 ## 03. 受入確認の記録 以下の4件は書式を説明するための記入例で、顧客案件のテスト結果ではありません。成功した確認と一緒に、難しい入力や足りない証拠も残します。各項目を開くと、入力と判断根拠を確認できます。 ### DEMO-01: 明確な請求書の問い合わせ **期待どおり** - **入力:** 「前回の請求書のコピーを送ってください」。この例の分類は「請求」と「アカウントへのアクセス」です。 - **期待する動作:** 「請求」を提案し、元の本文を表示します。レビュー担当者が確定するまで判断を保留します。 - **確認メモ:** 記入例では「請求」が表示され、本文が保持され、判断はレビュー待ちになっています。 ### DEMO-02: 担当先が2つ考えられる問い合わせ **要修正** - **入力:** 「請求書をダウンロードしたいのですが、ログインできません」。両方の分類が当てはまる可能性があります。 - **期待する動作:** 合意した曖昧さのルールに従い、分類を未確定にして人の確認へ回します。 - **確認メモ:** 記入例では曖昧さを示さず「請求」を選びました。ルールを修正し、再確認する必要があります。 ### DEMO-03: 空の送信 **期待どおり** - **入力:** 同じ入力画面から、空白だけのメッセージを送信します。 - **期待する動作:** 分かりやすい入力エラーを示し、分類処理を呼び出しません。利用者が入力を修正できるようにします。 - **確認メモ:** 記入例では入力欄のそばにエラーを表示し、レビュー一覧に新しい項目を作っていません。 ### DEMO-04: 分類サービスに接続できない **未確認** - **入力:** 有効なメッセージを入力した際に、分類を行う外部サービスが利用できません。 - **期待する動作:** 入力を保持し、失敗を表示します。合意した再試行または手動確認へ進み、処理を重複させません。 - **確認メモ:** この例には確認記録がありません。未検証の復旧経路を、確認済みとして扱うことはできません。 ## 04. 2週間の4つの確認機会 範囲を絞った2週間PoCの進行例です。実際の日程は、合意した範囲、入力資料、レビュー担当者の予定に左右されます。各段階で、発注側が確認できるものを残します。 ### 着手前: 確かめる問いを決める 業務、分類基準、架空または承認済みのデータ、対象外、確認項目を合意します。実装前にレビュー担当者とデモ環境を決めます。 ### 1週目の終わり: 最初の利用経路を見る 入力、提案、人による確認を一緒にたどります。意見を範囲に照らして記録し、不足する資料やアクセスを早い段階で特定します。 ### 2週目: 例外を確認する 曖昧な入力、不正な入力、合意した障害ケースを試します。観察結果をビルドに結び付け、修正した箇所は再確認します。 ### 最終レビュー: 次の判断を記録する デモを再現し、未完了項目と引き継ぎを確認します。受入または残る条件を記録し、次の依頼が必要かを判断します。 ## 05. 判断と未完了の対応 ### 判断例：本番展開を保留する 通常の経路は確認できますが、この例には曖昧な入力の誤分類と未検証の復旧経路が残っています。範囲を限定した追加確認を提案します。この記録は、本番運用への準備完了、費用削減、実際の問い合わせに対する精度を証明するものではありません。 ### 分類の重複を解消する 人の確認が必要な条件を合意し、動作を修正します。受入前に、識別できる次のビルドでDEMO-02を再実行します。 **対応責任者:** サポート責任者と開発者 ### 復旧の確認記録を付ける 合意したテスト環境で外部サービス停止を再現します。保持された入力、エラー表示、復旧結果を記録してから本番展開を検討します。 **対応責任者:** 開発者と発注側のレビュー担当者 ## 06. チームで確認する手順 1. 同僚に、設定手順とテストデータの識別子だけでデモを再現してもらいます。不足する手順は、開発した担当者が対応できるうちに引き継ぎ課題にします。 2. 受入済みの各基準が、同じビルドの確認結果を参照しているかを見ます。修正と未確認の項目を残します。見栄えのよいデモはレビューの一部にすぎません。 3. リポジトリへのアクセス、設定の管理者、次の環境の運用責任者を確認します。認証情報はレポートに書かず、合意した方法でアクセスを移管します。 4. 社内の承認手順に従って判断を記録します。Markdownは再利用できるレポートの例であり、ソースコード、公開済み試作品、本番環境一式を含みません。 ## よくある質問 ### 実際の顧客案件の納品物ですか？ いいえ。業務、入力メッセージ、観察結果は、書式を説明するための架空の例です。サイトで紹介する自社プロダクトの事例とは区別しています。 ### 2週間のPoCに本番展開は含まれますか？ 書面の範囲に明記した作業だけが含まれます。本番アクセス、強化作業、監視、デプロイ、継続サポートには、担当者と受入条件を別途定めます。 ### 基準を満たさない項目があった場合は？ 観察結果、影響、次の対応責任者を記録します。発注側が契約に照らして受入を判断します。新しい要望や範囲変更は明示的に扱います。 ### 社内のレビュー書式を使えますか？ はい。範囲を決める前に、受入書式、調達要件、レビュー手順を共有してください。大切なのは、基準と証拠と判断が結び付いていることです。 ## 自社用の受入記録 ### ビルドと環境 [ ] ### 範囲と基準 [ ] ### テスト入力と手順 [ ] ### 期待結果 [ ] ### 観察結果と証拠の場所 [ ] ### 状態と未解決の課題 [ ] ### 対応責任者と確認予定日 [ ] ### 発注側の判断 [ ] [次の範囲を相談する](https://urbanodx.com/ja/contact/?package=poc&from=service_details&utm_source=urbanodx&utm_medium=sample&utm_campaign=202609-deliverables)