第30章既存プロダクトへ安全に追加する

新規事業では、まだ存在しない利用体験を確かめます。既存プロダクトの機能追加では、すでに利用している顧客、蓄積されたデータ、契約、料金、問い合わせ対応を壊さずに変える必要があります。新機能の価値だけでなく、変えないものと、問題時に戻せる範囲を先に決めます。

30.1 現在の基準値を保存する

機能追加後だけ測っても、改善したか判断できません。着手前に次を確認します。

ログがない場合は、それ自体を制約として記録し、短期間の観察や標本調査で基準値を作ります。

一つのボタン追加でも、データ、権限、請求、サポートへ影響します。

利用者と画面
  ↓
業務手順と承認
  ↓
API・外部サービス
  ↓
データ保存・検索・削除
  ↓
権限・監査・セキュリティ
  ↓
料金・契約・顧客への説明
  ↓
監視・問い合わせ・障害対応

各段で、変更点、変えない点、所有者、確認方法、戻す方法を記録します。図の矢印は手順の方向だけを示し、責任の移動まで意味させません。

AI へ渡す前に、データの意味と利用条件を確認します。

履歴データに過去の差別や不公平が含まれていれば、AI はそれを効率よく再現する可能性があります。精度だけでなく、顧客区分ごとの差を確認します。

API を変える場合、既存利用者が使う項目や動作を突然変えません。新旧の形式を一定期間併存させる、版を分ける、変更予告を出すなどの移行策を決めます。

AI 出力を後続システムが利用する場合は、自由文のまま渡さず、必要項目、形式、許容値、欠落時の扱いを契約として決めます。形式チェックに合格しない出力は、人へ戻すか安全な既定値へ切り替えます。

機能フラグとは、コードを再公開せず、特定の利用者だけ機能の有効・無効を切り替える仕組みです。次の順に範囲を広げます。

各段階に、対象、期間、成功基準、停止条件、判断者を置きます。顧客ごとに設定が違う場合は、誰が何を利用できるかサポート担当者も確認できるようにします。

データ形式や業務手順を変える場合は、次の段階で確認します。

バックアップがあることと、復旧できることは同じではありません。復旧手順を実際に試し、所要時間を測ります。

本番公開の条件には、機能テストだけでなく次を含めます。

AI の誤回答をソフトウェア障害と別物にしません。顧客へ損害を与える品質低下は、事故として報告、停止、調査、再発防止の対象にします。

既存プロダクトでは、新機能が料金と契約へ影響します。

販売資料が技術的な限界を越えて約束しないよう、営業、法務、サポート、開発で同じ説明を持ちます。

利用率が上がっても、確認工数や誤回答による損失が増えれば成功とはいえません。

対象顧客を段階的に増やしながら、基準値と比較します。改善が見えなければ、モデルを変えるだけでなく、対象業務、画面、人の確認方法、機能そのものの必要性へ戻ります。

本番後に必要な仕事ごとに社内所有者を置きます。

外部支援終了後も、モデルやデータの変更時に誰が再評価するかを決めます。担当者名だけでなく、必要な権限、時間、手順、代理者を確認します。

考えてみる問い

追加しようとしている機能について、現在の基準値、影響を受ける既存顧客、段階公開の最初の対象、停止条件、戻す先、公開後の所有者を書いてください。

既存プロダクトへの追加で大切なのは、慎重さだけではありません。小さい範囲で早く学び、問題があれば止め、証拠が増えた分だけ範囲を広げることです。