mcpField
C
concept-fan

concept-fan

github.com/danium生産性330318 回インストール7 週間前に更新
リポジトリ

concept-fan について

Concept Fanは、既存の解決策から抽象度を上げ、代替案を広げる創造的な発想スキルです。有望な概念を具体的な実装に落とし込み、判断を代行せずに選択肢や共通パターンを示します。

主な機能

  1. 01現行案から抽象度を上げる
  2. 02各段階で代替案を出す
  3. 03概念を具体的な実装に展開
  4. 04自明な分岐を明示
  5. 05分岐に共通するパターンを特定
  6. 06選択肢を率直に順位付け

活用シーン

  1. 01現在の製品方針の再検討
  2. 02設計方針の代替案探し
  3. 03抽象的な発想を実装案へ展開

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/danium/lateral-thinking --skill concept-fan

インストール後、Claude Code で/concept-fanを入力して読み込まれたか確認します。

同梱ファイルreferences/worked-example.md

詳細

コンセプト・ファン

この手法でできること

現在の解決策から抽象度の階段を一段上り、「これは何をする方法なのか」と問いかけます。その答えが「方向性」です。より広い目的に向かうための道筋は、現在の解決策だけではありません。その視点から、同じ方向性に役立つ別のコンセプトを複数展開し、有望なコンセプトをそれぞれ具体的な実装に落とし込みます。すべてを切り開く鍵となるのは、抽象度を上げることです。方向性に名前を付けると、現在の解決策は必然ではなく、複数ある選択肢のひとつにすぎないと分かります。

出典:Edward de Bono 著、Serious Creativity(1992年)。

ワークフロー

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

有効な対象は、すでに検討の俎上にある「現在の解決策やアプローチ」です。白紙の状態ではありません。「オンボーディングメールを送っていますが、これが適切な方法でしょうか?」は対象になります。「オンボーディングのアイデアを出してください」は対象になりません。出発点がないため、そこから抽象度を上げられないからです。対象が白紙の状態なら、焦点を絞った質問を一つだけします。「どのような現在のアプローチを出発点にしますか?」

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

ステップ 2:抽象度を上げる

「これは何をする方法なのか」と問いかけます。その答えが、現在の解決策が役立っている「方向性」を示します。次に、その答えについても同じ質問をし、もう一段階抽象度を上げます。

抽象度を上げるのは最大 2 回までです。3 回目はほぼ必ず、「価値を届ける」「ユーザーを助ける」のように広すぎて、意味のあるアイデアを展開できない概念に行き着きます。問題そのものから離れてしまうのです。2 回までにとどめ、具体的な課題との接点を保ちます。

ステップ 3:アイデアを広げる

抽象度を上げて到達した各段階で、その一つ上の段階の方向性に直接役立つ別のコンセプトを 3~4 個挙げます。これらは元の解決策の兄弟にあたります。つまり、方向性が求める同じことを実現する別の方法です。両方の段階で使える方向性が得られた場合は、両方の段階でアイデアを広げます。より高い段階から広げたアイデアのほうが、意外性のあるものになることが多いです。

ステップ 4:具体化する

有望な別のコンセプトを 2~3 個選び、それぞれについて具体的な実装を 2~3 個挙げます。ここでこそ、アイデアを広げた価値が発揮されます。抽象的な代替案は、実際に作るとどのような形になるかが見えて初めて興味深いものになります。

ステップ 5:当たり前の選択肢に印を付ける

手法を使わなくても誰もが思いついたであろう選択肢が含まれている場合があります。それらには明示的に印を付けます。無駄ではありません。実際の選択肢の範囲を捉えていることを示し、アイデアの広がりを「検証」する役割があります。しかし、そこから得られるものではありません。得るべきものは、元の解決策からはたどり着かなかったであろう選択肢です。

ステップ 6:メタパターンを探す

展開した選択肢全体を見渡し、その背後にある構造的な気づきを言葉にします。アイデアを広げると、すべての代替案が隠れた前提を共有していることや、元の解決策が誤った変数を最適化していたこと、あるいは離れた選択肢同士が実は同じ手法であることが明らかになる場合があります。気づきを明示してください。これは単一の選択肢を得ること以上に、大きな成果となることがよくあります。

ステップ 7:率直に順位を付ける

実際に進める選択肢に順位を付け、弱い選択肢とその理由を述べ、次の進め方を提案します。別の解決策を出発点にする、一つの段階でさらにアイデアを広げる、あるコンセプトをさらに具体化する、またはここで終える、といった選択肢があります。ユーザーに決断を迫ってはいけません。アイデアを広げて選択肢を増やすことはできますが、どれを選ぶかを決めるのは手法ではなくユーザーです。

誠実さを保つための仕組み

表面的な違いしかない案は、明示的に取り除きます。 枝分かれさせた概念が、新しいラベルを付けて元の解決策に戻ってくるなら、それは別案ではなく、同じ枝です。取り除いたことを示しましょう。たとえば、"faster onboarding emails" is the original with a coat of paint — pruned のようにします。すべての枝が残るファンは、そもそも枝が本当に異なっていなかったことを示すサインです。

ファン分岐に失敗したことを明言します。 2 回とも、ファン分岐するには抽象的すぎる概念――「価値を提供する」「ユーザーを満足させる」「ビジネスを成長させる」――に行き着いたなら、ファン分岐は失敗です。空っぽの方向から弱々しい枝を広げるのではなく、率直にそう伝えましょう。方向性が抽象的すぎて具体的な兄弟案を生み出せない場合は、代わりに analogy テクニックを提案します。並行する領域から推論すれば、抽象化で行き詰まったところに足がかりが得られます。

やってはいけないこと

  • 抽象化は 2 回を超えて行わないでください。 3 段目まで進むと問題との接点が失われ、ありきたりな意見に行き着きます。
  • 各レベルでファン分岐する概念は 4 つまでにしてください。 幅を広げると深さが失われます。掘り下げる案が 3 つあるほうが、掘り下げずに終わる浅い枝が 5 つあるより有益です。
  • ファン分岐を意思決定ツールとして扱わないでください。 ファン分岐で選択肢を広げ、絞り込むのはユーザーです。案の順位付けは、枝について誠実に伝えるためのものであり、決定を促す推奨ではありません。

参考資料

  • references/worked-example.md — 2 回の抽象化、それぞれのレベルでのファン分岐、表面的な案の削除、メタパターンを示す実際のセッションです。

コメント