付録：ケース集（NG→OK）
本付録では、会社組織のエンジニアが高頻度で直面する交渉テーマを、再現可能な手順に落とすためのケースを集める。
ポイントは「言い返す」ではない。相手の利害・制約・判断軸を観測し、合意可能領域（ZOPA）を作るために、条件を設計し直すことである。
各ケースは、次の形式で記載する。
- 状況（何が起きているか）
- 利害/制約（何が重要で、何ができないか）
- NG例（悪い意味での“正論”になりやすいパターン）
- OK例（合意形成として前に進むパターン）
- 設計ポイント（スコープ/期限/品質/責任分界/運用負荷など）
- フォローアップ（合意を実装に落とす）
ケース1：工数見積もりの交渉（「来週までにできるよね？」）
状況
機能追加の依頼に対して、相手が「来週まで」と期限を固定している。要求の背景が言語化されていない。
利害/制約（例）
- 相手: リリース計画の維持、上長への説明、機会損失の回避
- 自分（チーム）: 品質（テスト/レビュー）、既存作業の継続、障害リスク回避
NG例
- 「無理です。そんな短期では品質が担保できません」 （正しいが、相手の利害に接続しておらず、代替案もない）
OK例
- 「来週まで、という期限の背景を確認したいです。『何が起きると困るか』を先に共有してもらえますか」
- 「期限を守る案として、スコープを2段階に分けます。Phase1（来週）は最小機能＋監視/ロールバック、Phase2（翌週）は仕上げ（UX/例外系/テスト強化）です」
- 「品質を落とすと、来週の先に障害対応コストが発生します。リスクを数行で整理して、意思決定できる形にします」
設計ポイント
- 期限の“固定”を前提にしない（背景・利害に戻す）
- 「期限/スコープ/品質」を同時に動かせる状態にする
- 合意のDone（Phase1で何が満たされればOKか）を明示する
フォローアップ
- Phase1/2 の合意を Issue/Design Doc に残す（スコープ境界を明文化）
- 期限の前提（依存チーム/外部要因）をリスクとして記録する
ケース2：スコープ追加（スコープクリープ）
状況
開発中に要求が増えるが、納期・体制は固定されている。
NG例
- 「それはスコープ外です」 （事実でも、受け手の次の行動が不明確になりやすい）
OK例
- 「追加要求を受けるなら、何かを落とす必要があります。優先度を一緒に決めましょう」
- 「“今入れる価値”が高いものは、要件を絞ってPhase1に入れます。そうでないものはバックログに積み、期限後に再評価します」
設計ポイント
- 追加要求を「議論の対象（バックログ）」に乗せる（口頭のまま流さない）
- スコープ境界を合意の単位にする（Phase/スプリントで切る）
- 優先度の判断軸（顧客影響/売上/法令/運用負荷）を明示する
フォローアップ
- 追加要求の受け入れ条件（期限・品質・運用）をテンプレ化する
ケース3：技術的負債返済の予算/時間確保
状況
機能開発が優先され、負債返済が後回しになっている。事故や遅延は起きているが、意思決定につながっていない。
NG例
- 「技術的負債が限界です。返済しないと破綻します」 （強いが抽象的で、投資判断ができない）
OK例
- 「負債を“種類”で分けます。障害リスクに直結するものから優先します」
- 「1スプリントで返済できる最小単位に分割し、効果測定（リードタイム/障害件数/MTTR等）をセットにします」
- 「機能を止めるのではなく、各スプリントで返済枠を固定（例: 20%）し、残りで機能開発を進めます」
設計ポイント
- 負債は“返すか/返さないか”ではなく“どれを/いつ/どの単位で”に落とす
- 「事業リスク」へ変換する（第1章/第2章の文脈）
- 成果を可視化し、継続的インテグレーションとして運用する（おわりにの文脈）
フォローアップ
- 返済バックログを公開し、優先順位の変更ルールを明確化する
ケース4：セキュリティ投資（恐怖訴求に寄らない）
状況
対策の必要性は感じているが、予算・工数がつかない。「そこまで必要か」と疑問視される。
NG例
- 「危ないのでやりましょう」 （恐怖訴求は短期的に効いても、合意形成の再現性が低い）
OK例
- 「対策の目的を“リスク低減”ではなく“事業継続”として整理します」
- 「最小対策（必須）と、追加対策（余裕があれば）を分け、段階導入で合意します」
- 「運用負荷（誰が、いつ、何をやるか）まで含めて提示します」
設計ポイント
- 目的→選択肢→条件→運用の順で説明する（第2章の“インターフェース”）
- 合意のDoneを、監査・運用・責任分界で定義する
フォローアップ
- 例外処理（期限つき例外、レビュー頻度、解除条件）を文書化する
ケース5：障害対応後の再発防止（責任追及から合意形成へ）
状況
障害後の場で、原因追及が強くなり、学びや再発防止が進まない。
NG例
- 「それは〇〇チームのミスです」 （正否に関わらず、相手の防衛反応を強める）
OK例
- 「事実（タイムライン）と解釈（仮説）を分けて整理します」
- 「再発防止は“行動”で定義します。誰が/いつまでに/どう測るかまで決めます」
- 「責任の議論は別枠にし、まずは顧客影響と再発防止を合意します」
設計ポイント
- 感情の熱量が高い場ほど、手順を固定する（第5章の文脈）
- “再発防止”を、設計・テスト・運用のどこに入れるかまで落とす
フォローアップ
- ふりかえりログを残し、同じクラスの事故に横展開する
ケース6：他チーム依存の調整（SLO/運用負荷/引き継ぎ境界）
状況
チーム間で責任分界が曖昧なまま、作業だけが進む。運用負荷が不均衡に積み上がる。
NG例
- 「そっちでやってください」 （境界が曖昧な状態で投げると、関係が悪化しやすい）
OK例
- 「責任分界（RACI）と、運用の“呼び出し条件”を定義しましょう」
- 「SLO/エラーバジェットを共有し、どこまでを“受け入れ可能”とするかを合意します」
- 「引き継ぎのDone（ドキュメント、監視、当番表、オンコール）をテンプレ化します」
設計ポイント
- 境界を、責任・運用・SLO で定義する（第6章の文脈）
- “お願い”ではなく“運用可能な契約”に落とす（第2章の文脈）
フォローアップ
- 依存関係を可視化し、変更時の通知/レビュー手順を決める
次に読む： 付録：実践ツールキット / 目次（トップ）