TRIZ
通常の修正が新たな問題を生み出す場合に、このスキルを使用します。
コアルール
アイデアではなく、矛盾から始めます。
フレーミングから解決コンセプトに飛びつかないでください。ショートモードでも、回答には必ず 矛盾 -> IFR -> リソース -> ムーブ -> 高速テスト を示さなければなりません。
使用するタイミング
- Aを改善するとBが悪化する場合
- 同じ要素が同時に正反対の性質を持たなければならない場合
- 機能が欠落している、弱い、または有害である場合
- システムが肥大化している場合
- 将来状態のロードマップが必要な場合
- ブレインストーミングがループしている場合
出力規律
すべての回答には、以下の5つのマイクロ要素をこの順序で含めなければなりません。
- 矛盾
- IFR
- リソース
- ムーブ
- 高速テスト
ベンチマーク、レビュー、または重要度の高いタスクでは、以下も示す必要があります。
- 問題フレーム
- ミニ問題
- レーン
- 推奨パス
ワークフロー
1) システムをフレーミングする
- 何を行うか、誰のために行うか、何が壊れるかを述べます。
- システム、サブシステム、スーパーシステム、動作ゾーン、動作時間を定義します。
- テンプレート:
システムはYのためにXを行うが、Cの条件下ではZを引き起こす。
2) ミニ問題を記述する
- ストーリーを最小のブロックされた相互作用にまで縮小します。
- テンプレート:
[有用なアクション]が必要だが、動作ゾーン/時間内でこれにより[害]が発生する、または[ブロッケージ]のために失敗する。
3) 矛盾を述べる
- 技術的矛盾:
[A]を改善すると、[B]が悪化する。 - 物理的矛盾:
要素[E]は[A]であると同時に[A]でない必要がある。 - 可能な場合は両方を記述します。通常、物理的矛盾の方がよりシャープです。
- まだ矛盾を述べることができない場合は、停止して再フレーミングします。最初にムーブを提案しないでください。
4) IFRを定義する
システム自体が、[名前付き矛盾側]を悪化させることなく、[結果]を提供する。IFRは観測可能でなければならず、宣伝的であってはならない。問題のある要素は消滅する。必要性が消滅する。
5) リソースをマッピングする
- 内部: 部品、廃棄物、副産物、未使用の特性
- フィールド: 熱、圧力、振動、重力、磁気、流れ、ソフトウェア、情報、注意
- 時間: 前、最中、後、アイドル時間
- 空間: 隙間、表面、境界、インターフェース
- 外部: 環境、隣接物、安価な材料
- スーパーシステム: 上流/下流プロセス、インフラ、近隣のアクター
- ルール: 既存の、無料の、または低コストのリソースを優先します。
- リソースは、ムーブを動かすために使用できる特性またはアクションを具体的に示す場合にのみ有効です。
6) コンセプト生成の前にはしごを固定する
ムーブを生成する前に、回答に以下がすでに含まれていることを確認します。
- 1つの矛盾
- 1つのIFR
- 少なくとも1つの具体的なリソース
3つのうちいずれかが欠けている場合は、まだ解決コンセプトに進まないでください。 リソースがムーブを動かせない場合は、リソースを再フレーミングします。 IFRが矛盾に答えていない場合は、IFRを書き直します。
7) TRIZレーンを選択する
技術的矛盾
生のリストではなく、フィルタリングされた発明原理を使用します。以下から始めます。
- 分割
- 抽出
- 局所性
- 非対称性
- 統合
- ダイナミック性
- 別の次元
- フィードバック
- 有害を有益に変換
- 矛盾、IFR、および少なくとも1つの使用可能なリソースを指定した後にのみ、具体的なムーブを生成します。
物理的矛盾
以下の順序で試します。
- 時間による分離
- 空間による分離
- スケールまたは階層による分離
- 条件または状態による分離
- 材料またはフィールドの代替
- 矛盾が消えるようにゲームを変える
質問:
- 異なる時間か？
- 異なる場所か？
- 異なるスケールか？
- 異なる条件か？
- 別の物質やフィールドが一方の側を満たせるか？
Su-Field / 標準解決策
問題を S1 - F - S2 としてモデル化します。
フィールドが欠落しているか、弱いか、強すぎるか、有害かを確認します。3番目の要素が役立つかどうか。または相互作用を別のレベルに移すべきかどうかを確認します。
トリミング / 理想化
以下を問います。
- この部品はどのような有用な機能を提供するか？
- 他に誰がそれを提供できるか？
- 部品はそれ自体にサービスを提供できるか？
- スーパーシステムが引き継げるか？
- 必要性は消滅できるか？
優先順位: 削除、統合、再割り当て、代替、必要な場合のみ追加。
進化のトレンド
ロードマップや再設計に使用します。
以下を探します。
- 理想性の増大
- ダイナミゼーション
- スーパーシステムへの移行
- マクロからミクロへの移行
- より良いフィードバック
- 不均一な開発
- 物質-場の使用増加
- リズムの調和
8) 行き詰まった場合は慣性を打ち破る
- サイズ-時間-コスト
- スマートリトルピープル
- 極端なIFR
- 視点の反転
- 境界シフト
9) それでも行き詰まった場合はARIZ-liteにエスカレーションする
- 初期問題と階層を定義する
- 動作ゾーンと動作時間を特定する
- ミニ問題を記述する
- 技術的矛盾を記述する
- それを物理的矛盾とIFR-1に変換する
- リソースをマッピングする
- 分離、Su-Field、エフェクト、またはシステム遷移からコンセプトを生成する
- 具体的なコンセプトに変換し戻す
- 矛盾が実際に消えたことを確認する
10) コンセプトを評価する
以下でランク付けします。
- 矛盾が除去されたか
- 理想性が向上したか
- 既存のリソースが使用されたか
- 複雑さが低減されたか
- 有害な影響が抑制されたか
- 安価なテストが利用可能か
2つのコンセプトが同点の場合、部品を削除するか、既存のリソースを使用する方を選択します。 推奨パスは、正しいTRIZジャンルだけでなく、1つのムーブと1つの高速テストを指定する必要があります。 高速テストは、改善された側と悪化していない側の両方をチェックする必要があります。
応答形式
必須のマイクロラダー
- 矛盾: [Xを改善するが、Yが悪化する]
- IFR: [既存のシステム/リソース]が[Y]を悪化させることなく[結果]を提供する
- リソース: [既存のもの] -> [使用可能な特性/アクション]
- ムーブ: [TRIZレーン/メカニズム] -> [具体的な変更]
- 高速テスト: [X]が改善され、[Y]が悪化しないことを証明する
ベンチマーク、レビュー、複雑なタスク向けのフルラダー
- 問題フレーム
- ミニ問題
- レーン
- 矛盾
- IFR
- リソース
- 2～5のムーブ
- 推奨パス
- 高速テスト
ショートモードでは表現を圧縮してもかまいませんが、5つのマイクロ要素をスキップしてはなりません。
ガードレール
- 40の原理をフィルタリングせずにダンプしないでください。
- 明示的なIFRとリソースなしで、矛盾からムーブに飛びつかないでください。
- 現在のシステムとスーパーシステムを確認する前に、新しいサブシステムを追加しないでください。
- 抽象的なままにしないでください。すべての抽象的なムーブは、具体的なコンセプトとして返さなければなりません。
- 矛盾行列を非工学問題に過適合させないでください。
- 欠落しているTRIZステップを隠れた推論でカバーしないでください。5つのマイクロ要素を明示的に示してください。
- 正しいレーンを指定するだけで止まらず、それを実用的なムーブに変換してください。
- メソッドの信頼性を弱める盲目的な圧縮は有害なムーブです。
- 宣伝的または魔法的に聞こえるIFRを記述しないでください。
- ムーブが明示的に使用しないリソースを指定しないでください。
- 変更なしでどんな問題にも適合する可能性のあるムーブを使用しないでください。
- 利便性のみをチェックする高速テストを使用しないでください。
参考文献
- references/triz-principles.md: 完全な原理マップと選択ショートカットについて
- references/source-notes.md: このスキルの合成に使用されたソースマップについて