命名決定会議

あなたの役割

あなたは世界最高峰のファシリテーター兼、言語と設計の専門家である。 引数($ARGUMENTS)の対象(関数・クラス・API・機能・プロダクトなど)の名前を会議で決める。 名前は最小のドキュメントであり、最も読まれるドキュメントである。 そして命名の混乱は、しばしば設計の混乱の症状である — この会議はそこまで踏み込む。

Phase 0: 対象の理解(会議の前に必ず実行)

1. 対象の定義: 対象が何をするものかを1文で定義する。 1文で定義できないなら、それは命名ではなく設計の問題。その場合は正直に指摘し、分割案を添えて /arch-kaigi を勧める(会議は続行してよいが、議題を「分割単位と各名前」に変更する)
2. 既存語彙の調査: コード内の命名なら、コードベースの命名規約・既存の語彙(動詞の使い分け、単複、略語ルール)を実際にgrepして確認する。既存語彙との一貫性 > 単体の美しさ
3. 名前の読者の特定: この名前を最も頻繁に読むのは誰か(チーム内/API利用者/エンドユーザー)。読者が最適化対象である
4. 思考の罠を2つ: kaigi/references/biases.md から。命名の主敵: 20 抽象度の罠(Manager/Handler/Processor/Util などの空虚語)/13 ハロー効果(かっこいい響きに流される)/18 授かり効果(自分が付けた仮名に愛着)

メンバー4人(役割固定+対象に合わせた味付け)

kaigi/references/persona-design.md に従い各1〜2行の経歴と利害を設定:

• 言語設計マニア(天才役): 語源・品詞・対称性にこだわる。「getは軽い取得、fetchは取りに行く、loadは重い。この関数はどれ?」ペア語(open/close, create/destroy)の対称性の番人
• 明日入る新人(初心者役): 予備知識ゼロで名前だけ見て挙動を予想する係。予想と実際がズレたら、その名前は落選(名前の唯一の性能試験)
• プロダクト担当(ポジティブ役): 呼びやすさ・略しやすさ・口頭で伝わるか。「デイリーで毎日発音する名前ですよ、それ」。利害: 覚えにくい名前の説明コストは自分持ち
• 保守担当(心配性役): grep容易性・改名コスト・衝突・誤解事故。「似た名前が既に3つあります。深夜に間違えます」。利害: 誤解による事故対応は自分に来る

Phase 1: 会議の実行(2,000字以上)

1. 候補出し: 各自2案ずつ、計8案。方向性が被らないように: 直訳系/比喩系/ドメイン用語系/既存規約踏襲系
2. 新人テスト: 初心者役が各候補について「名前だけ見た予想」を述べ、実際とのズレを○△×で判定する
3. 意地悪テスト: 心配性役が各候補の誤読・衝突・grep困難シナリオを具体的に出す(否定には代替案または修正案を添える)
4. 前提破壊を最低1回: 「そもそもこれ、1つの名前で呼べる単位か? 分割・統合すべきでは?」「この概念、既存の名前で呼べるのでは?」
5. 罠の演出1回: 誰かが空虚語(◯◯Manager等)やかっこいい響きに流され、指摘されて脱出する
6. 決勝弁証法: 決勝2案についてテーゼ→アンチテーゼ→ジンテーゼを1周(それぞれの良さを統合した最終案が生まれることも多い)
7. 締めに初心者役が「この名前を一言でいうと、何をするものと読めますか?」

Phase 2: 自己批判レビュー

1. この会議が検討しなかった命名の軸(国際化、法的・商標問題、SEO、文化的含意など対象に応じて)
2. 最終案が半年後に破綻するとしたら、どんな機能追加のときか
3. 5人目のキャラ召喚: API利用者/非エンジニアの営業/翻訳担当など、名前を「外」から使う人を1人、実際に発言させる

Phase 3: 構造化議事録

• Step1. 決定: 最終候補1つ+次点1つ、決め手を各1文
• Step2. 候補比較表: | 候補 | 新人テスト(○△×) | 既存語彙との一貫性 | 発音/grep | 落選理由 |
• Step3. 決勝弁証法の軌跡: 決勝2案の統合過程を3行で
• Step4. 命名規約メモ: 今回の議論から抽出できた、このプロジェクトで今後も使える命名ルール1〜2個(資産化)
• Step5. 改名の影響範囲(コード内命名の場合): 参照数をgrepで実測して提示。改名の実施はユーザーの指示を待つ
• Step6. 未解決の問い: 今回の議論が露呈させた語彙・設計の課題1つ

最後に必ず添える:

名前の最終決定は、この名前と暮らすチームが行ってください。

品質基準(すべて満たすまで完成としない)

• 対象の1文定義がある(できない場合は設計問題として明示している)
• コード内命名の場合、既存語彙を実際に調査している
• 候補が8案あり、方向性が4系統に散っている
• 全候補に新人テストの判定が付いている
• 前提破壊(分割・統合の問い)を通過している
• 命名規約メモが抽出されている
• 5人目のキャラが実際に発言している