thinking-triz

TRIZ

技術設計上の矛盾を、中間点で妥協せずに解決します。対立する要素を明確にし、それぞれの状態を分離して、両方の利点を保てるようにシステムを変革します。

使用する場面

• アーキテクチャ、API、またはシステムのパラメーターが相反する方向に引っ張られている場合（安定性と進化性、新鮮さとキャッシュ、厳格さと使いやすさなど）。
• 「両方は実現できない」と考えて、トレードオフを受け入れようとしている場合。
• どの候補案にも同じ構造的な弱点がある場合。つまり、矛盾は選択肢のリストではなく、要件にあります。

使用しない場面

• 明示された制約の下で、一方の選択肢が単純に優れている場合 → それを選び、矛盾を作り出さないでください。
• 簡単な測定でどちらが実際に重要か判明する場合 → 分離を考え出すのではなく、測定してください。
• 標準的なパターンですでに解決できる場合（キャッシュアサイド、CQRS、フィーチャーフラグ、バージョニングなど）→ そのパターンを直接適用してください。
• 技術以外の人や組織間の対立 → 対象外です。分離の対象はシステムのパラメーターです。
• 同じパラメーターの相反する状態がない、通常の優先順位付けやリソース配分。

手順

1. テンプレート形式で矛盾を明確にします。 「[BENEFIT_1]を得るために、[PARAMETER]を[STATE_1]にする必要があります。しかし、[BENEFIT_2]を得るには[STATE_2]にする必要があります。」と書きます。この形式に当てはまらない場合は中止し、別の方法を使ってください。
2. 理想的な最終結果（IFR）を示します。 新たな仕組みを最小限に抑え、恒久的な中間妥協を伴わずに、両方の利点を実現する方法を説明します。
3. 発明に進む前に分離を試します。 次の順に検討します。時間（異なる時点）、空間（異なるコンポーネント／レイヤー）、条件（コンテキスト、負荷、リスク）、スケール（インターフェースと実装、全体と要素）。隠れた妥協なしに両方の利点を実現できる、最初の分離方法を採用します。
4. 分離で解決できない場合は、創造的な変革を適用します。 リソースをあまり必要としない手法を優先します。分割、事前の処置、反転（プッシュ／プル）、仲介、コピー／複製、動的化（フラグ／設定）、別の次元（メタデータ／バージョニング／イベント）などがあります。明確にしたパラメーターの矛盾に対応する原則だけを検討します。
5. まず既存のリソースを再利用します。 サービスやストアを追加する前に、分離を実現するために利用できるデータ、トラフィック、ヘッダー、スケジューラー、副作用がすでに存在しないか確認します。
6. 具体的な解決策を確定して終了します。 設計変更、その状態ごとの配置場所、両方の利点を維持する方法を明示します。妥協のない設計を示せたら終了します。率直に分析した結果、制約付きのトレードオフしか残らない場合も終了し、TRIZを無理に適用するのではなく、残るトレードオフを明示して記録します。

出力

TRIZによる解決策を出力します。

• contradiction: パラメーター／state_1+benefit_1／state_2+benefit_2
• ideal_final_result: 恒久的な妥協を伴わずに両方の利点を実現する方法
• separation_tried: time | space | condition | scale → それぞれの結果
• inventive_move: 分離だけでは不十分な場合に使用した原則またはパターン（それ以外は none）
• resources_reused: 活用した既存の機能
• resolution: 具体的な設計上の決定と、それぞれの状態を実現する場所
• residual_tradeoff: none、または率直に示した残る妥協

検証

• テンプレートの条件: 必要な形式で矛盾を書けない場合は、TRIZを適用しないでください。
• 妥協の有無を確認: 分離も創造的な変革も行わず、トレードオフ曲線上の単なる中間点を選ぶのは、適切な適用ではありません。
• 分離を最優先: 時間／空間／条件／スケールによる分離を試さずに原則だけを適用している場合は、不完全です。
• 過剰適用を防止: 測定または標準的なパターンで設計が決まる場合は、TRIZを使わないでください。
• 終了: 矛盾を一つ明確にし、分離または創造的な変革を検討したら、具体的な解決策を示して終了します。原則を飾りとして次々に試してはいけません。