本格展開前のMVP引き継ぎで受け取るべきもの

MVPスプリントは、曖昧なデモとアイデア一覧で終わるべきではありません。買い手が次の判断をできるように、動くソフトウェアと十分な文脈を残す必要があります。

AI機能、API、社内ワークフローが含まれる場合は、特に重要です。本物の引き継ぎがないMVPは、人質状況に変わります。動かす・変える・拡張できるのは、作った人だけです。買い手はソフトウェアではなくアクセス権を買っていることになります。

引き継ぎもプロダクトの一部

良い引き継ぎは、何を作ったのか、何が前提なのか、どんなリスクが残るのかを買い手が理解する助けになります。また、次のベンダー、社内チーム、リテイナー契約へ進みやすくなります。

実務的な引き継ぎには、次の内容が必要です。

• リポジトリまたはソースコードの引き継ぎ条件
• セットアップとデプロイメモ
• データとAPIの前提
• 既知の制約
• デモシナリオ
• 受入条件の達成状況
• 推奨される次ステップ

監査でも通用する、より完全なチェックリスト:

コードとインフラ

• 完全な履歴を持つGitリポジトリを、受入日に買い手組織へ移管またはミラー。
• 前提条件、インストール、環境変数、ワンコマンドのローカル実行を記載した README.md。
• 値は伏せて必要シークレット名を列挙した .env.example。
• ターゲット環境向けのIaCまたは手順ベースのデプロイメモ(Vercel、Fly、AWS、GCP、Azure、オンプレ)。
• スプリント中の主要変更を網羅した CHANGELOG.md。

データと連携

• アプリが接続する全外部システムの一覧。認証方式、スコープ、使用アカウントまたはサービスプリンシパル。
• 主要テーブルとAI入出力スキーマの短いデータ辞書。
• 本番データなしでローカル開発できるサンプルフィクスチャ。
• 単発スクリプトやデータバックフィルの移行計画。

運用

• 代表的なインシデントのランブック:モデル障害、連携失敗、キュー滞留、シークレットローテーション。
• 監視・ログ送信先の名前とエンドポイント。
• cronスケジュール、キュートピック、バックグラウンドワーカーの一覧。
• 買い手運用チーム向けの「最初の30日」計画。

ガバナンス

• 受入条件チェックリストの状態、根拠、レビュアー。
• 未解消リスクと、それぞれの推奨責任者。
• 本番で使用中のモデル・プロンプトバージョン、安全に更新する手順。

AIには追加の明確さが必要

AI機能では、モデル前提、データソース、確認ステップ、低信頼時の挙動、フォールバックも説明する必要があります。

含めるべき具体的なAI引き継ぎ節:

• モデルカード。 プロバイダ、モデル名、本番固定バージョン、フォールバックモデル、想定トークン費用、P50/P95レイテンシ。
• プロンプトレジストリ。 すべてのプロンプトをハッシュと人間可読の変更履歴でバージョン管理。デプロイを変えずにプロンプトを更新する手順を文書化。
• 評価セット。 50〜200件のラベル付きサンプルと、リグレッション判定の指標。評価セットがなければ、次のプロンプト/モデル変更は推測です。
• 信頼度ポリシー。 本番のしきい値、承認者、見直し頻度。
• 失敗モード。 タイムアウト、不正JSON、拒否、低信頼、検証失敗のときの挙動。買い手チームが追える形でコードパスを示す。

これがないと、デモは良く見えても、本番利用の承認が難しくなります。セキュリティ・コンプライアンスレビューは、引き継ぎが先回りで答えているべき問いで止まります。

MVP後の判断

買い手は、堅牢化するのか、連携するのか、一度止めるのか、拡張するのかを判断できるべきです。その判断こそが、絞ったMVPスプリントの成果です。

A4 1枚のスプリント終了時判断文書:

• 作ったもの。 1段落、専門用語なし。
• 受入条件の状態。 達成/部分達成/未達+根拠。
• 想定より良かったこと。 2〜3点。
• まだ不確実なこと。 2〜3点+それぞれ緩和策案。
• 推奨次ステップ。 {堅牢化、連携、停止、拡張} のいずれか+概略スコープと価格帯。
• 何もしないリスク。 具体的かつ正直に。

動くソフトウェアは価値の半分です。もう半分は、次の投資に進むための明確な道筋です。最終デモを終えた買い手が、自分の言葉で「何をするシステムか」「運用費用」「何が起こり得るか」「次のスプリントの推奨内容」を語れるべきです。4つ全部語れないなら、ソフトウェアの出来に関わらず引き継ぎは不完全です。