交渉の基礎語彙（最小モデル）
本書は「交渉を設計可能なプロセス」として扱う。その前提として、最低限の共通語彙を整理しておく。
このページの目的は、交渉理論を網羅することではない。本文と付録のテンプレートを読み解くために必要な語彙を、過不足なく揃えることである。
このページでできるようになること
- 「立場（Position）」と「利害（Interest）」を区別して整理できる。
- BATNA（代替案）と最低受容ラインを、交渉準備テンプレートに落とし込める。
- ZOPA（合意可能領域）を意識して、譲歩や条件提示を設計できる。
1. 立場（Position）と利害（Interest）
- 立場（Position）: 交渉の場で表に出ている要求である。例: 「期限を延ばしてほしい」「予算を増やしてほしい」。
- 利害（Interest）: 立場の背後にある理由・制約・期待である。例: 「障害リスクを下げたい」「監査に通る状態にしたい」「評価指標を守りたい」。
本書の実務で重要なのは、立場のぶつかり合いから入らず、利害を早い段階で言語化して共有することである。エンジニアであれば「要求（API）」「制約（Contract）」「非機能（NFR）」の整理に近い。
2. BATNA（最良の代替案）と最低受容ライン
交渉では「合意できない場合にどうするか」を事前に決めておく必要がある。
- BATNA（Best Alternative to a Negotiated Agreement）: 合意できない場合の、現実的な代替案である。 例: 「段階移行が通らないなら、最小構成のハイブリッドで延命する」。
- 最低受容ライン: これを下回るなら合意しない、という境界である。 例: 「監査要件を満たさない運用は受けない」「24/7オンコールを追加で引き受けるなら人員増が前提」。
付録のテンプレートでは、最低限 batna: を埋めることが、交渉の安全弁になる。
3. ZOPA（合意可能領域）
- ZOPA（Zone Of Possible Agreement）: 両者が受け入れ可能な条件が重なっている領域である。
ZOPAが存在しない場合、説得の問題ではなく「条件設計（スコープ/期限/品質/責任分界/段階化）」の問題である。エンジニア視点では、要件の分割や段階リリースで ZOPA を作りにいく発想が有効である。
4. アンカリング（初期提示の作用）
初期の数字や条件が「基準点」として残り、以降の議論を無意識に引き寄せる現象である。
本書の文脈では、アンカーを「強引に押し付ける武器」ではなく、「議論の土台（前提・比較軸）を共有する手段」として扱うのが安全である。たとえば、見積もりの議論では「前提条件の一覧」を先に提示し、比較軸を固定する。
5. 譲歩設計（Concession Design）
譲歩は、その場の雰囲気で出すものではない。譲歩するなら、以下を事前に設計する。
- 何を（スコープ/期限/品質/優先度/責任分界/運用負荷など）
- どの順番で（価値の高いカードを先に切らない）
- どの条件付きで（条件が満たされない場合のロールバック）
譲歩設計は、第3章「反復的合意形成」と第6章「交渉パイプラインの構築」と強く接続する。
6. 合意の定義（Doneの定義）
交渉の合意は「雰囲気」では完了しない。合意の成立条件を、実務上のDoneとして定義しておく。
- 誰が決めるか（意思決定者）
- 何が決まれば完了か（承認範囲）
- どの形式で残すか（議事録/Design Doc/Issue/契約書など）
本書のテンプレートは、このDoneを「文書として再現可能にする」ための補助輪である。
次に読む： 用語集 / 第1章：コードは雄弁に語る - 技術的根拠による説得術 / 目次（トップ）