寓話
カウンターの後ろでいつも書き換えられる口令帳
銀杏旅館には接待係の一団がいた。彼らは毎日、口令帳に従って客の質問に答える。部屋の規則、キャンセル条件、VIP割引、夜に誰が扉を開けるか。早年は客が少なく、番頭が自ら数句を直せば、皆はそれを読み上げればよかった。
後に宿屋は支店を開き、自動で応答する木偶も雇った。口令帳は各地に複製され、ある者は丁寧語を加え、ある者は販促の話術を補い、ある者は苦情対応のために制限条件をこっそり削除した。
店主は回答が漂い始めたことに気づく。同じ質問に対して、東店は無料アップグレードを約束し、西店は追加料金を要求する。人形は時には古いルールで答え、時には内部メモを客に話してしまう。
彼の最初の修補は、グループを作り、全員がパスワードを変更したらグループで一言言うよう求めることだった。数日後、グループのメッセージは請求書、シフト、雑談に埋もれ、どの一言がオンラインで現在使われているバージョンなのか誰にも分からなくなった。
ある大口顧客が誤った約束を持ち込んで賠償を求めたとき、店主はようやく認めた。合言葉は気軽に書くメモではなく、宿屋の生産システムの一部である。それにはバージョン、変数、テスト、承認、リリース、ロールバックが必要だ。
彼らは中央パスワード保管庫を構築した。各パスワードには用途、担当者、適用店舗、変数の説明、変更記録がある。新しいパスワードはまず固定の問題セットでテストし、合格後に小範囲でリリースする。
受付係は口令の効果も見られる：どの質問が人へ多く回され、どの回答が顧客の追加質問を招き、どの変更が苦情を減らしたか。各事故は、曖昧な「最近変えた」ではなく、具体的なバージョンまで追える。
口令帳はそれによって死んだわけではない。むしろ、皆はより大胆に変更するようになった。変更には実験があり、比較があり、承認があり、退路もあるからだ。店主は最後に理解した。話す人形が増えるほど、口令は散在する文書で管理してはならない。プロンプトはアプリケーションロジックであり、コードのようにガバナンスされねばならない。後に宿は価格調整に直面した。旧来の方法なら、各店が壁に一言ずつ書き換え、月末には必ず混乱する。中央口令櫃はまず新バージョンを作り、二店を選んで試用し、客の追問と解約の変化を記録し、それから徐々に開放した。エラー時には、店主は即座に前バージョンに戻せた。皆はこれで理解した。口令を管理することは受付係を束縛することではなく、毎回の表現変化をテスト可能、追跡可能、撤回可能にすることだ。