寓話
使者は提案を一段書くだけでなく、作業票を差し出すことを学んだ
倉庫に賢い使者がいた。人の要求を理解できる。作業員が在庫を調べたいと言うと、彼は立派な説明文を書くことができたが、システムに実際に調べさせることはできなかった。
管理者は最初、伝令に命令を文の中に書かせた。エンジニアはさらに文からどのシステムを呼び出すのか、パラメータは何かを推測する。
推測はすぐに問題を起こした。顧客の「来週水曜日までに」が誤って解析され、製品型番は一文字欠け、注文のキャンセルと注文の照会も混ざり合った。
ある者は正規表現とキーワードで修繕しようとした。業務アクションが一つ増えるたびに、例外ルールが山ほど増え、保守コストはどんどん高くなった。
新しい管理者は規則を変えた。実行可能な動作はまず関数として登録し、名称、引数、型、必須項目、意味を明記する。伝令が行動を起こすには、構造化された作業票を提出しなければならない。
システムはチケットを受け取るとまずパラメータを検証し、次にアプリケーション層が実行するか、承認するか、追加質問するか、そして結果をどのようにメッセンジャーに返すかを決定する。
メッセンジャーはもはや自然言語の一言で外部システムを動かさない。関数を選びパラメータを埋める役割を担い、実際の実行は依然として制御されたプログラムが行う。
管理者は依然として誤りを防がねばならない。関数設計が広すぎたり、説明が曖昧だったり、権限や冪等性の制御が欠けていれば、構造化呼び出しでも実際の損失を生む。彼は理解した。機械にツールを請託させる鍵は、より上手く話させることではなく、機械可読なパラメータで審査可能なアクション要求を出させることだ。その後、さらに厄介な仕事が来た。表面的には旧問題の拡大に見えるが、実際にはプロセスに隠れた隙間をすべて押し出した。誰が先に引き継ぐか、誰が変更できるか、誤りが出たらどう前の段階に戻るか。かつては顔なじみの暗黙の了解でやり過ごしていた場所を、今はすべて明確にしなければならない。主事人はもう皆に「もっと気を配れ」と促さず、現場をもう一度歩き直した。彼は各引き継ぎ、各失敗、各補救を記録させ、どこが単に遅いだけか、どこが結果を誤って傷つけるか、どこが一度誤ると追跡しにくいかを明らかにした。新しい規則が広まってから、最初の数日はしっくりこなかった。検査が一つ増えたと嫌がる者もいれば、古い経験が侮辱されたと感じる者もいた。しかし次に異常が起きたとき、皆は初めて痕跡をたどって問題の発生位置を見つけられた。結果を囲んで互いに推測するのではなく。