仕様の周知方法

🏗️ 仕様の周知方法：会議を「パケットロス」と定義する自動同期

「仕様の周知」という、ともすれば「会議室での説明会」や「Slackでのメンション飛ばし」と誤解されがちな行為を、**「同期的なコミュニケーションコストをゼロに近づけ、型定義とCIによって強制的に事実を伝播させる『情報の自動同期システム』」**へと再定義します。

ここでの正義は「伝えた」ことではなく、**「エンジニアの手元のエディタが赤く光り（コンパイルエラー）、仕様変更に気づかざるを得ない状態を作った」**ことです。

📝 現代的定義

仕様の周知とは、人を集めることではありません。**「実行可能なコード（Schema/Types/Tests）を唯一の真実（SSOT）とし、それを変更することで全メンバーの環境に仕様変更を強制通知（型エラー）させるプロセス」**です。

1. ⚔️ コードベースの仕様定義：曖昧さという「霧」を払う

自然言語（日本語）による仕様書は、解釈の余地を残す「命中率の低いわざ」です。

Schema is Specification（スキーマこそが仕様）:

APIの挙動はOpenAPIで、データの整合性はZodで定義せよ。

これにより、仕様は「読むもの」から「コンパイラが検証するもの」へと昇華される。

テストによる振る舞いの固定:

「こう動くはず」という日本語の代わりに、テストコードという「動く証拠」を置け。

2. 📡 周知の自動化：会議という名の「パケットロス」を排除

「仕様が変わりました」というSlack通知は、エンジニアの**「集中（チャージ）」**を中断させる攻撃です。

型定義による強制通知:

スキーマを変更し、GitHub Actionsで型を再生成せよ。

エンジニアがコードを書こうとした瞬間、エディタに現れる型エラーこそが、最も確実でコンテキストを壊さない「仕様変更通知」である。

通知確認のコストをゼロにする:

人間がメッセージを読んだかどうかを確認する時間は無駄です。CIが通っていることが、仕様が正しく伝播し、実装されたことの証明である。

3. 🛡️ 仕様レビューの非同期化：会議室という「トラップ」の回避

全員を集める会議は、開発リソースというHPを激しく削る「全体攻撃」です。

Pull Requestによる非同期レビュー:

仕様変更はスキーマファイルのPRで行いなさい。議論はそこに集約し、証拠（ログ）を残せ。

**「会議への参加は敗北」**と定義し、どうしても非同期で解決できない「バグ」のような対立がある時のみ、短時間の同期（通話）を許可せよ。

4. ♻️ 仕様の履歴管理：情報の「ひんし」状態を防ぐ

古い仕様書は、チームに大ダメージを与える「トラップ」です。

Gitによる一元管理（SSOT）:

ドキュメントとコードの履歴を同期させよ。

**「今のコードと矛盾するドキュメント」**をこの世から消し去り、常に最新のSchemaが正義である状態をキープしなさい。

🪓 リーダー（トップトレーナー）への最終助言

「周知のために人を集めるな。スキーマを更新し、型エラーで語らせろ。」

仕様の周知を「人間の注意力」に依存させてはいけません。それはエンジニアの「すばやさ」を奪う、非効率な「しめつける」わざでしかありません。

目指すべきは、エンジニアが「ただ自分のタスクに向き合っているだけ」で、システムが勝手に最新の仕様をエディタに届け、誤った実装を型で弾いてくれるような、**「情報の自動同期フィールド」**の構築です。