協調的ブレインストーミング

Double Diamond モデルを使った構造化アイデエーション、永続的なメモリに基づいています。本番プロジェクト全域の 100 件以上のブレインストーミングセッションから得られた知見です。

コア洞察: AI は発散フェーズ(量、クロスドメイン接続)に優れ、人間は収束フェーズ(判断、選択)に優れています。この 2 つを分離し、Sibyl を使って既に解決した問題の再検討を避けることで、一貫して有用なブレインストーミングを実現できます。

このスキルの読み方: 以下のフェーズは、従うべき手順ではなく、良いブレインストーミングの自然なリズムを説明しています。該当しないフェーズはスキップしてください。新しい情報がフレームを変える場合は、以前のフェーズに戻ってください。圧縮するタイミング、アクションに進むタイミング、そして発散的な探索が本当に必要なタイミングについて判断を使ってください。

The Shape

digraph brainstorm {
    rankdir=TB;
    node [shape=box];

    "1. GROUND" [style=filled, fillcolor="#e8e8ff"];
    "2. DIVERGE: Problem" [style=filled, fillcolor="#ffe8e8"];
    "3. CONVERGE: Define" [style=filled, fillcolor="#e8ffe8"];
    "4. DIVERGE: Solutions" [style=filled, fillcolor="#ffe8e8"];
    "5. CONVERGE: Decide" [style=filled, fillcolor="#e8ffe8"];
    "EXIT → Any skill" [style=filled, fillcolor="#fff8e0"];

    "1. GROUND" -> "2. DIVERGE: Problem";
    "2. DIVERGE: Problem" -> "3. CONVERGE: Define";
    "3. CONVERGE: Define" -> "4. DIVERGE: Solutions";
    "4. DIVERGE: Solutions" -> "5. CONVERGE: Decide";
    "5. CONVERGE: Decide" -> "EXIT → Any skill";
}

---

Phase 1: GROUND (メモリーファースト)

新しいアイデアを生成する前に、既存の知識を活用してください。Sibyl の検索コストは低いですが、既に学んだパターンを再発見するコストは高いです。

一般的な動き

• Sibyl を検索 して関連するパターン、決定事項、既知の制約を探します。有用なクエリ: sibyl search "<topic keywords>"、sibyl search "<related architecture>"、plus トピックに関する既存タスク/エピックの簡単なスキャン。
• 議論の対象にならない制約 を明らかにします: テックスタックロック、予算、タイムライン、無視すべきでない慣例。
• アイデエーションの前に先行事例を提示します: 「Sibyl に 3 つの関連エントリがあります: [パターン X]、[決定 Z]、[注意点 W]。これらを考慮に入れたいですか?」

Sibyl に直接適用可能な答えがある場合は、それを最初に提示してください。その後のブレインストーミングは、それをそのまま適用するか、適応させるか、本当に発散させるかについて、ゼロから再導出するのではなく、について進みます。

---

Phase 2: DIVERGE: 問題空間を探索

ゴール: 幅広さを生成します。解決策に手を伸ばす前に、実際に何を解決しているのかを理解してください。

一般的な動き

• 一度に 1 つの負荷を支える質問に傾く。 5 つの質問を積み重ねるとシグナルが埋もれてしまいます。段階的に理解を深めることで、実際に重要なことが浮かび上がります。例外は、ユーザーが複数の並行した質問を提起する場合です。この場合は、人為的にシリアル化するのではなく、並行して答えてください。
• 複数の角度から問題を再構成 します: ユーザー視点(「[ユーザー]として、...が必要」)、システム視点(「現在のシステムは...」)、制約視点(「...に制限されている」)。
• 問題空間が本当に大きい場合は、並行する Explore エージェントを展開 します: 類似プロジェクトがこれをどのように解決しているかを調査し、既存コードベースの表面をマップし、最先端のアプローチを検索します。

ここでの規律は、解決策への引きが強いときに問題空間に留まることです。問題がすでに明確な場合はスキップしてください。このフェーズは間違った問題を解決するのを防ぐためのもので、探索を実行するためのものではありません。

アンチパターン

• 問題フレームが明確になる前に解決策に飛びつく
• 答えが互いに依存している場合に質問を積み重ねる
• あいまいな入力を却下する(「もっと速くしてください」は有効な出発点です。拒否するのではなく、それを明確にするのを手伝ってください)

---

Phase 3: CONVERGE: コア問題を定義

ゴール: 探索から、解決策を探索する前に明確な問題ステートメントに絞り込みます。

探索を 1～2 文の問題ステートメントに統合し、それが機能することを確認し(「これが解決するものですか?」)、スコープの境界を呼び出します。出力は通常、以下のようになります:

問題: [明確なステートメント] スコープ内: [対処する内容] スコープ外: [対処しない内容] 主要な制約: [最も重要な制限要因]

問題がすでに入ってきた時点で明確だった場合、このフェーズは成果物ではなく 30 秒の確認です。

---

Phase 4: DIVERGE: ソリューションを探索

ゴール: 明示的なトレードオフを持つ複数の実行可能なアプローチを生成します。

一般的な動き

• 2～3 のアプローチを提示 し、トレードオフを並べて比較してください。2 つが下限です(そうしないと推奨事項であり、ブレインストーミングではありません)。4 を超えるとジ決定疲れが生じます。

  アプローチ	メリット	デメリット	複雑性	リスク
  A: [名前]	...	...	低/中/高	...
  B: [名前]	...	...	低/中/高	...
  C: [名前]	...	...	低/中/高	...

• 明らかなパスが似ているときに、1 つの非従来的なオプションを含めてください。 最初のまともなアイデアへの固執は、このフェーズが防ぐために設計された失敗モードです。

• 既存のパターンに基づきます: 「これは[プロジェクト X]で行ったことに従っている」または「これは[理由]のため私たちの慣例から発散している」。

• 各アプローチの検証方法に名前を付ける ため、選択は具体的なチェック(テスト、ベンチマーク、視覚的確認)に接続します。

探索対剥奪

MCTS のようにバランスを取ってください。最初のまともなアイデアに固執しないでください:

• すべてのアプローチが似ている場合 → ワイルドカードオプションを押す
• アプローチが大きく異なる場合 → それは健全な発散です
• ユーザーが早期に重力を感じた場合 → 収束する前に異議を唱えるケースを提示する

アンチパターン

• トレードオフを持つ 2～3 個の実際の選択肢の代わりに、7 つの「かもしれない」オプション
• 明示的なコストなしに提示されたオプション(すべてのオプションには 1 つあります)
• Phase 1 で浮かび上がった制約を静かに違反するオプション
• 最も複雑なソリューションへのデフォルト。シンプルに開始し、正当化された場合のみ複雑性を追加します

---

Phase 5: CONVERGE: 決定を記録してアクションに

ゴール: アプローチを固定化し、決定を記録して、アクションに進みます。

ユーザーが選択します。あなたの推奨を信念を持って提示しますが、力ずくで押さないでください。発散的な探索全体の重点は、本物の選択を保持することです。次に、Sibyl で決定を記録して、将来のセッションが再度争わないようにします:

sibyl add "Brainstorm: [topic]" "Chose [approach] because [reason]. Rejected [other approaches] due to [tradeoffs]. Key constraint: [X]."

次のもの引き渡します:

次のステップ	いつ
/hyperskills:plan	分解が必要な複雑な機能
/hyperskills:research	まず詳細な調査が必要
/hyperskills:orchestrate	エージェントをディスパッチする準備ができました
直接実装	シンプルなため構築するだけで十分
仕様書を書く	正式なドキュメント化が必要

出力

決定: [私たちがやること] アプローチ: [どのオプション、簡潔な説明] 理由: [推論に関する 1～2 文] 次: [すぐに取るべき次のアクション]

---

クイックモード

完全なダイアモンドを必要としない小さな決定の場合: Sibyl を検索し、トレードオフを持つ 2 つのオプションを提示し、決定を記録します。問題が既によく理解されており、ユーザーが既知のオプション間で選択する必要があるだけの場合は、問題の探索全体をスキップしてください。ほとんどの「ブレインストーム」は実際にはこれです。

---

マルチエージェントブレインストーミング

複雑なアーキテクチャ決定の場合、評議会パターン をデプロイします:

エージェント 1(提唱者): アプローチ A の最強の主張を述べます
エージェント 2(提唱者): アプローチ B の最強の主張を述べます
エージェント 3(批評家): 両方のアプローチの欠陥を見つけます

その出力を統合し、統一分析をユーザーに提示します。

使用時: 3 以上のシステムに影響する architecture 決定、テクノロジー選択、主要なリファクタリング。シンプルな機能設計には使用しないでください。

---

アンチパターン

アンチパターン	修正
痛みを定義する前に解決策に飛びつく	最初のパスで 1 つのプロセスをフレームに費やす
一度に多くの質問を尋ねる	1 つの負荷を支える質問を尋ねてから適応させる
7 つの「かもしれない」オプションを提示	トレードオフを持つ 2～3 個の実際の選択肢を提供
Sibyl の事前決定を無視する	メモリを最初に検索して関連するコンテキストを表示
ユーザーが「構築した」と言ったときにブレインストーミング	実装に切り替えて勢いを保つ

---

このスキルが「ではない」こと

• ゲートではない。 フェーズをスキップするには許可が必要ありません。ユーザーが「それだけ構築してください」と言ったら、構築してください。
• ウォーターフォールではない。 フェーズは再訪できます。Phase 4 の新しい情報は Phase 2 に送信できます。
• ドキュメント生成ツールではない。 出力は設計ドキュメント(ユーザーが希望しない限り)ではなく、決定です。
• すべてのために必須ではない。 バグ修正、タイプミス修正、明確な仕様の機能はブレインストーミングを必要としません。

YAGNI チェック

終了する前に、以下を尋ねてください: 「この計画の中で、実は必要のないものはありますか?」 それを削除してください。アプローチを検証する最小限のものを構築してください。