動く試作品と、次の判断に必要な確認記録。

この例のチームは、問い合わせを受け取り、対応するキューへ手作業で振り分けています。最初に確かめたいのは、元の本文をレビュー担当者に見せたまま、適切な振り分け先を提案できるかです。自動返信とCRMの更新は対象に含めません。

合意する最小範囲は、架空のメッセージを入力し、提案を採用するか、人の確認が必要な状態を明示するところまでです。サポート責任者が分類基準を決め、開発者がビルドとテスト入力を記録します。発注側の責任者が書面の範囲に照らして受入を判断します。

1. 01テスト用の本文→
2. 02分類の提案→
3. 03人による確認→
4. 04判断の記録

資料名は引き継ぎ構成の例です。ダウンロードは説明用文書であり、ソフトウェアのリポジトリではありません。

以下の4件は書式を説明するための記入例で、顧客案件のテスト結果ではありません。成功した確認と一緒に、難しい入力や足りない証拠も残します。各項目を開くと、入力と判断根拠を確認できます。

範囲を絞った2週間PoCの進行例です。実際の日程は、合意した範囲、入力資料、レビュー担当者の予定に左右されます。各段階で、発注側が確認できるものを残します。

1. 着手前

   確かめる問いを決める

   業務、分類基準、架空または承認済みのデータ、対象外、確認項目を合意します。実装前にレビュー担当者とデモ環境を決めます。

2. 1週目の終わり

   最初の利用経路を見る

   入力、提案、人による確認を一緒にたどります。意見を範囲に照らして記録し、不足する資料やアクセスを早い段階で特定します。

3. 2週目

   例外を確認する

   曖昧な入力、不正な入力、合意した障害ケースを試します。観察結果をビルドに結び付け、修正した箇所は再確認します。

4. 最終レビュー

   次の判断を記録する

   デモを再現し、未完了項目と引き継ぎを確認します。受入または残る条件を記録し、次の依頼が必要かを判断します。

1. 1

   同僚に、設定手順とテストデータの識別子だけでデモを再現してもらいます。不足する手順は、開発した担当者が対応できるうちに引き継ぎ課題にします。

2. 2

   受入済みの各基準が、同じビルドの確認結果を参照しているかを見ます。修正と未確認の項目を残します。見栄えのよいデモはレビューの一部にすぎません。

3. 3

   リポジトリへのアクセス、設定の管理者、次の環境の運用責任者を確認します。認証情報はレポートに書かず、合意した方法でアクセスを移管します。

4. 4

   社内の承認手順に従って判断を記録します。Markdownは再利用できるレポートの例であり、ソースコード、公開済み試作品、本番環境一式を含みません。