analogy

強制的なアナロジー（構造の移植）

この手法でできること

問題を取り上げ、その本質的な構造、つまり関係者は誰か、その間で何が流れるのか、どこで詰まるのかだけに絞り込み、形が同じ別分野のシステムを探します。免疫系、航空管制塔、夕食時のレストランの厨房などです。次に、そのシステムが詰まりに対して何をしていて、自分たちは何をしていないのかを考え、その仕組みを具体的なアイデアとして持ち帰ります。大切なのは距離です。参照元の分野が問題から遠く離れているほど、その解決策はホワイトボードにすでに書かれている案とはまったく違ったものになります。

出典：シネクティクス（William J.J. Gordon, Synectics: The Development of Creative Capacity, 1961）、特に「直接類推」の手法。バイオミミクリーやTRIZに隣接する実践で広く用いられています。

ワークフロー

ステップ 1：対象を確認する

有効な対象は、具体的な創造上または設計上の課題です。何かを成長させる方法、何かを経路に沿って流す方法、プロセスやシステムを再設計する方法などです。曖昧な場合は、焦点を絞った質問を一つだけ尋ねます。「どのようなシステムを作り変えようとしていて、どこで詰まっていますか？」

デバッグ、コードレビュー、変更の実装など、分析作業の実行を求める依頼は断り、代わりに分析的なアプローチを提案します。そのようなプロセスの再設計やアイデア出しは、有効な創造上の対象です。「コードレビューの進め方を一新する」は対象内ですが、「このPRをレビューする」は対象外です。

ステップ 2：問題の構造を一文で示す

対象を関係者、流れ、ボトルネックに絞り込みます。分野特有の用語も、解決策に関する言葉も使わず、形だけを示します。たとえば、「独立した生産者が多数いて、経路が一つしかなく、そこが混雑し、品質にばらつきがある」のようにします。この一文が手法全体を支える要です。自分の業界をまだ示しているなら、抽象化が足りません。

ステップ 3：構造が響き合う分野を3〜5個選ぶ

references/domain-pool.md を参照してください。問題に関連しているように聞こえる分野ではなく、ステップ2の文にある構造的な特徴と合致する分野を選びます。移植する発想が本当に異なる論理から生まれるように、生物学的、運用的、社会的・文化的な分野をそれぞれ少なくとも一つずつ混ぜます。一度に五つを超える分野を扱ってはいけません。

ステップ 4：分野ごとに、役割を対応付けてから仕組みを移す

各分野について、次の二つを順番に行います。

1. 役割を対応付ける。 問題のどの要素が分野のどの要素に当たるのかを、率直に示します。「私たちのユーザーは採餌者で、私たちの経路は獣道です」のようにします。対応が明確なら、一行で十分です。
2. 移転の問いを投げかける。 「この分野では、私たちがしていないどのような方法で、ボトルネックに対処していますか？」と尋ねます。次に、見た目のイメージではなく、実際に使われている仕組みを1〜2個、問題に対する具体的なアイデアとして持ち帰ります。

ステップ 5：メタパターンを探す

一連の分野を検討したあと、うまく移せた仕組みを見比べ、共通する構造的な洞察を名付けます。「役に立った分野はどれも、ボトルネックを量の問題ではなく、経路選択の問題として扱っていた」のようにします。これを明示してください。この分野横断的な観察は、たいてい個々の移植案より価値があります。

ステップ 6：率直に順位付けし、無理に結論を急がない

最も鋭い移植案を選びます。弱い案があれば、その理由も述べます。次の選択肢として、別の分野をさらに探す、一つの分野を深掘りする、手法を切り替える、あるいはここで止めることを提案し、選択はユーザーに委ねます。ユーザーに決断を迫ってはいけません。

正直さを保つための仕組み

無理に当てはめる役割は1つまでです。 きれいに対応づけるには、比喩的な飛躍が1つ必要です。ある領域を成立させるために、2つ目の役割を無理に当てはめる必要が生じた時点で――「では、アリが女王でもあり、道が巣でもあるとしたら……」のように――その構造は実際には韻を踏んでいません。移し替えではなく、飾り立てているだけです。はっきりと採用をやめ、その理由を述べてください。

表面的な類似は指摘して、採用しません。 対象と語彙は共通していても、構造が共通していない領域は、最も魅力的で、最も役に立たない落とし穴です。表面的な類似にすぎないと指摘して、採用をやめてください。すべての領域がきれいに転用できるバッチは、出力を後付けで合わせている兆候です。少なくとも1つは、正直に採用をやめることになるはずです。

韻を踏む領域がない場合。 どの領域にも2つ目の役割を無理に当てはめる必要があるなら、問題はたいてい領域ではなく、ステップ2の文にあります。その文を書き直してください。書き直してもボトルネックが特定できない場合は、領域を描くのをやめて、診断を述べ、次の一手として適した手法を提案してください。自分でその手法を実行せず、そこで止めてください。

• 構造を述べる文が形ではなく解決策になってしまう → concept-fan を提案してください。これを使うと、本当の問題が見つかるまで掘り下げられます。
• 構造は実在するものの、それに対応する遠い領域が見つからない → random-stimulus を提案してください。飛躍に構造的な韻を必要としません。

してはいけないこと

• 対象と語彙が共通する領域を選ばないでください。 ソフトウェアからマーケットプレイス、アプリからプラットフォーム――近すぎます。共通する言葉によって、実際には何も転用できていないことが見えにくくなります。価値のすべては、距離にあります。
• 仕組みではなく、見た目を転用しないでください。 「サンゴ礁は色鮮やかで多様だから、私たちの製品も活気に満ちた印象にすべきだ」というのは、移し替えではなく飾りです。サンゴ礁の見た目ではなく、サンゴ礁が何をするのか（多くの小さな生物が作り上げた構造が、ほかの生物のすみかになる）を転用してください。
• 1つのバッチで扱う領域は5つまでにしてください。 それ以上では効果が薄れ、対応づけが曖昧になります。
• 複数の役割を無理に当てはめる必要がある領域を救済しないでください。 採用をやめて、次に進んでください。

参考資料

• references/domain-pool.md — 転用可能な特性とともに、参照できる構造豊かな領域を掲載しています
• references/worked-example.md — 実際のセッションの全体像を示す例です。正直に採用をやめる例も1つ含まれています