Preserving Productive Tensions

生産的な緊張関係を維持する

概要

解決すべき問題ではなく、維持する価値のある情報を示す緊張関係もあります。異なる状況で複数のアプローチが本当に有効な場合、どれかを選ぶよう強制すると柔軟性が失われます。

基本原則： 状況依存性を示す緊張関係は維持します。必要な場合にのみ解決を強制します。

生産的な緊張関係を見極める

次のような場合、緊張関係は生産的です：

• どちらのアプローチも、それぞれ異なる妥当な優先事項（コスト対レイテンシ、シンプルさ対機能）を最適化している
• 「より良い」選択肢は技術的な優位性ではなく、デプロイ環境によって異なる
• ユーザーやデプロイ環境によって異なる選択肢が選ばれる
• トレードオフは現実に存在し、巧みなエンジニアリングで解消されるものではない
• ステークホルダーが、互いに対立する妥当な懸念を抱えている

次のような場合、緊張関係を解決する必要があります：

• 両方を維持する実装コストが法外に高い
• アプローチが根本的に対立している（共存できない）
• このユースケースにおいて、明確な技術的優位性がある
• 後戻りできない選択肢である（選択によってアーキテクチャが固定される）
• 両方を維持しても価値がなく、複雑さが増す

維持するためのパターン

パターン 1：設定

アーキテクチャに選択肢を組み込むのではなく、設定可能にします：

class Config:
    mode: Literal["optimize_cost", "optimize_latency"]
    # Each mode gets clean, simple implementation

使用する場面： どちらのアプローチもアーキテクチャ上は両立し、切り替えが実行時の判断である場合

パターン 2：並行する実装

共通の契約に基づき、どちらも独立した明確なモジュールとして維持します：

# processor/batch.py - optimizes for cost
# processor/stream.py - optimizes for latency
# Both implement: def process(data) -> Result

使用する場面： アプローチが大きく異なる一方で、同じインターフェースを共有する場合

パターン 3：文書化されたトレードオフ

緊張関係を、ドキュメントや意思決定記録に明示的に残します：

## Unresolved Tension: Authentication Strategy

**Option A: JWT** - Stateless, scales easily, but token revocation is hard
**Option B: Sessions** - Easy revocation, but requires shared state

**Why unresolved:** Different deployments need different trade-offs
**Decision deferred to:** Deployment configuration
**Review trigger:** If 80% of deployments choose one option

使用する場面： コード内で両方を維持できないものの、その選択が意図的だったことを記録する必要がある場合

危険信号 — 解決を無理強いしています

• どちらも有効なのに、「どれが一番か」と尋ねる
• 理由を説明せずに「どちらか一方を選ぶ必要がある」と言う
• ユーザーの状況ではなく、自分の好みで選ぶ
• 緊張関係を維持すること自体が前進なのに、「前に進む」ために解決する
• 多様性に価値があるのに、合意を強制する

これらに当てはまる場合はすべて、立ち止まってください。緊張関係を維持することを検討しましょう。

解決を強制するタイミング

次の場合は、解決を強制すべきです：

1. 実装コストが法外に高い

   • 両方を構築・保守すると、開発が大幅に遅れる
   • チームに並行するアプローチへ割ける余力がない

2. 根本的な対立

   • アプローチが矛盾するアーキテクチャ上の前提に基づいている
   • 懸念事項をきれいに切り分けられない

3. 明確な技術的優位性

   • この特定の状況では、一方のアプローチが客観的に優れている
   • 「X の方が好き」ではなく、「X なら制約を満たせるが、Y では満たせない」

4. 後戻りできない選択肢

   • 選択によってアーキテクチャが固定される
   • 選択肢間の移行に多大なコストがかかる

5. シンプルさのために選択が必要

   • 両方を維持すると、実際に複雑さが増す
   • YAGNI：必要なのが一方だけなら、両方を構築しない

明確に尋ねましょう：「どちらか一方を選ぶべきですか、それとも両方を選択肢として維持しますか？」

ドキュメントの形式

緊張関係を維持する場合は、明確に記録します：

## Tension: [Name]

**Context:** [Why this tension exists]

**Option A:** [Approach]
- Optimizes for: [Priority]
- Trade-off: [Cost]
- Best when: [Context]

**Option B:** [Approach]
- Optimizes for: [Different priority]
- Trade-off: [Different cost]
- Best when: [Different context]

**Preservation strategy:** [Configuration/Parallel/Documented]

**Resolution trigger:** [Conditions that would force choosing one]

例

生産的な緊張関係（維持する）

「コストとレイテンシのどちらを最適化すべきでしょうか？」

• 回答： 設定可能にします。デプロイ環境によって必要なトレードオフは異なります。

技術的な決定（解決する）

「SSE と WebSockets のどちらを使うべきでしょうか？」

• 回答： SSE にします。一方向の通信だけで十分であり、実装もよりシンプルです。

ビジネス上の決定（保留する）

「オフラインモードをサポートすべきでしょうか？」

• 回答： 両方を維持しようとせず、ユーザーのニーズに基づいてステークホルダーに判断を求めます。

覚えておくこと

• 妥当な優先事項の間にある緊張関係は、バグではなく機能です
• 時期尚早な合意は、価値ある柔軟性を損ないます
• 無理のない場合は、選択の強制より設定を優先します
• トレードオフを明示的に記録します
• 正当な理由があるなら、解決してもかまいません