DX PoCを始める前のチェックリスト

有償PoCは、クライアント側の情報が整理されているほど速く進みます。完璧なドキュメントは不要です。重要なのは、最初の1週間を遅らせる障害を減らすことです。

期日に間に合わないPoCの多くは、技術が難しかったから遅れたのではありません。特定の問いに誰も時間内に答えられなかったから遅れます。「どのフィールドが正か」「下書きを誰が承認できるか」「検証環境はどこにあるか」「APIキーは誰が持っているか」。このチェックリストは、これらの問いをキックオフ後ではなく前に表面化させるためにあります。

業務を準備する

業務責任者を決める

現在の流れを5〜10ステップで説明する

引き継ぎ、ボトルネック、手戻りを特定する

2〜6週間後に何が成功かを定義する

業務責任者は、リストの中で最も重要です。これは役員スポンサーでも情報システム担当でもありません。日常的に業務をしている、あるいは監督している人で、「この下書きは正しいか」を数時間で答えられ、「これで本番に出してよい」と判断する権限を持つ人です。この役割が決まっていないと、週次デモが意思決定の場ではなくステータス報告会になります。

業務を記述するときは「トリガー → アクション → 出力」の形で書きます。例:「共有受信箱に顧客メール着信 → サポート担当が分類・返信下書き・関連記事添付 → 返信送信、Zendeskでタグ付け」。5〜10ステップで十分です。10で収まらない場合はスコープが広すぎます。

データを準備する

安全に共有できるサンプルファイル、画面、エクスポート、メール例、API資料を用意します。実データを共有できない場合は、実際の構造に近い匿名化サンプルを作成します。

実務的には次のような準備になります。

代表サンプル20〜50件(3件ではなく)。AIが壊れるのはロングテールです。十分なバリエーションがないと見えません。

ハッピーパスとエッジケースの両方。 崩れたPDF、怒っている顧客メール、欠損のあるレコード。本番に出せるかどうかはここで決まります。

項目レベルのドキュメント(構造化データの場合):カラム名、型、想定範囲、nullの意味、2系統が食い違ったときにどちらが正か。

APIアクセスまたは安定したエクスポート経路。 1週目はCSVダンプでも構いませんが、本番でどう流れるかは把握しておきます。

書面のデータ取り扱い合意。 社内ネットワーク外に出してよいもの、マスクすべき項目、AIログの保管期間。APPIや社内情報セキュリティレビューは最初のモデル呼び出し前に通しておきます。

匿名化は削除ではありません。氏名、口座番号、識別子は現実的なダミーに置き換えますが、フィールドは消さないでください。AIワークフローは中身がマスクされていても、データの形に依存することがあります。

判断を準備する

スプリント開始前に受入条件を合意します。PoCの最後には、停止、改善、連携、拡張のどれに進むかを判断できる状態にします。

受入条件は具体的かつ測定可能であるべきです。「AIがうまく動く」のような曖昧な条件は、最終レビューを議論に変えます。役立つ例:

「ホールドアウトの100件で、受信チケットの85%以上を正しいカテゴリに分類できる」

「1週間のトライアル中、下書き返信が無修正で採用される割合が40%以上」

「サンプル請求書20件に対して、必須7項目の抽出再現率(recall)が95%以上で、レビュアーに信頼度スコアが表示される」

各指標には必ずフォールバックを対にします。AIが扱えないケースをどう処理するか、です。下位10%を無視するPoCはPoCではなく、デモにすぎません。

環境を準備する

少数のインフラ判断で、1週目の摩擦のほとんどが消えます。

サンドボックス環境:ワークフローが触るSaaSや社内システムの非本番資格情報。

AIワークフロー用のID:サービスアカウント、APIトークン、または署名付きJWTを、最小権限で発行する。

ログ出力先:クライアント側で見られる場所。共有のPostgresテーブル1つ、あるいはSupabaseプロジェクト1つで十分です。

デモURLまたはステージング配備を事前に決める。Vercel、Render、Fly、あるいはクライアント自社クラウド。業務責任者が週次デモ中にスマートフォンからアクセスできる場所であること。

この明確さが、小さなPoCを有効なDX投資判断の材料に変えます。チェックリストは形式主義ではありません。「2〜6週間」を希望的観測ではなく誠実な数字にするための条件です。