仕様書・コード・本番のどれを正しいとするか

正式仕様は、用語、責任、目指す構成をそろえるために必要です。ただし、採用を決めた機能がまだ実装されていないこともあります。「仕様にある」を「使える」へ読み替えると、未実装を実績として公開してしまいます。

反対に、コードだけを正しいとすると、移行途中の互換処理や一時対応まで将来の仕様になります。何を残すべきかは、正式な意図へ戻って判断します。

本番の応答は、現在の利用者が何を受け取るかを知る強い証拠です。対象の版、時刻、経路を記録すれば、「公開したつもり」と実際の配信を分けられます。

ただし偶然動いた一件は、例外時の復旧、データの意味、将来の意図を証明しません。さらに利用者が仕事を完了できたかは、サーバーの成功応答だけでは分かりません。本番確認と現場受入を分ける理由です。

サイトマップ、AI向け概要、一覧画面、進捗集計は、正式データから生成できます。派生資料を別々に手で直すと、更新のたびに差が生まれます。

Corporate Siteでは、記事データからcanonical URL、サイトマップ、構造化データ、事前生成HTML、llms.txt、ai-context.jsonを同期します。公開後はProductionで、生成物が同じ版を示すかを確かめます。

「顧客の正式名称はどこか」「今公開されている記事は何か」「この機能は現場で使えるか」。問いが変われば、所有する場所も確認方法も変わります。

情報源を一つへ集める前に、重要な問いを十個書き、それぞれ誰が、どの場所で、いつ確定するかを決めます。万能なSource of Truthを探すより、矛盾が起きたときにどこへ戻るかが明確になります。

仕様書は、何を実現するつもりかを知るための正本です。コードは、今どのように作られているかを知る手掛かりです。本番の観測は、公開環境で何が起きているかの強い証拠です。そして現場の記録は、仕事が実際に終えられたかを教えます。どれか一つを万能の正本にすると、別の問いに答えられなくなります。

食い違いを見つけたとき、まずどれが間違いかを決めようとすると対立しがちです。代わりに、今回の問いは何かを言葉にします。意図を確認したいのか、実装を直したいのか、障害を調べたいのか、業務が成立したかを確かめたいのか。問いが決まれば、先に見る場所も決まります。

ピース・ビズ グループでは、設計、実装、公開確認、現場受入を混ぜない考え方を取っています。派生した資料を人が黙って直して新しい正本にしないことも重要です。食い違いは恥ではなく、どの情報がどの問いを持つかを見直す契機になります。