chain-roleplay-debate-synthesis

連鎖型ロールプレイ → ディベート → 統合

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Roleplay → Debate → Synthesis Progress:
- [ ] Step 1: Frame the decision and identify roles
- [ ] Step 2: Roleplay each perspective authentically
- [ ] Step 3: Structured debate between viewpoints
- [ ] Step 4: Synthesize into coherent recommendation
- [ ] Step 5: Validate synthesis quality

Step 1: 意思決定の枠組みを定め、役割を特定する

意思決定の内容を明確な質問として示し、正当性がありながら利害が対立する2～5人のステークホルダーの視点または役割を特定し、どのような統合が成功とみなされるかを明確にします。生産的な役割の選び方については、意思決定の枠組みを参照してください。

Step 2: 各視点を忠実にロールプレイする

各役割について、その立場、優先事項、懸念、根拠を述べます。わら人形論法に陥らず、それぞれの視点を真摯に擁護してください。真摯に擁護する手法については、ロールプレイのガイドラインを参照し、全体の構成にはresources/template.mdを使用してください。

Step 3: 視点間で構造化されたディベートを行う

意見が分かれる重要な点について、視点同士が直接議論できるように進行します。緊張関係を明らかにし、前提に異議を唱え、エッジケースを検証し、核心となる論点（どのような証拠があれば各視点の考えが変わるか）を特定します。ディベートの形式と進行手法については、ディベートの構成を参照してください。

Step 4: 一貫性のある推奨案に統合する

すべての視点から得られた知見を、トレードオフを認め、各視点の妥当な懸念を取り入れ、何を優先するのか、そしてその理由を説明する統一された意思決定にまとめます。統合の手法については、統合のパターンを参照し、統合のフレームワークにはresources/template.mdを使用してください。複雑で複数のステークホルダーが関わる意思決定については、resources/methodology.mdを参照してください。

Step 5: 統合の質を検証する

resources/evaluators/rubric_chain_roleplay_debate_synthesis.jsonに照らして統合を確認し、すべての視点が忠実に表現されていること、ディベートによって実際の緊張関係が明らかになっていること、統合に一貫性と実行可能性があること、また、検討を経ずに退けられた視点がないことを確かめます。このアプローチが適切だったかを確認するには、このスキルを使用すべきでない場合を参照してください。

---

意思決定の枠組み

生産的な役割の選び方

適切な役割の選び方：

• 利害の対立：役割ごとに正当性はあるものの、優先事項が異なります（例：スピードの擁護者と品質の守護者）
• 異なる専門性：役割ごとに異なる知識領域を持ち寄ります（例：エンジニア、デザイナー、顧客）
• 価値観の緊張関係：役割が両立しない価値観を代表します（例：プライバシーの擁護者とパーソナライゼーション）
• ステークホルダーの代表：役割が実際の意思決定者や影響を受ける当事者に対応します

一般的な役割のパターン：

• 機能別の役割：エンジニア、デザイナー、PM、マーケター、財務、法務、顧客
• アーキタイプの役割：楽観主義者、悲観主義者、リスク管理者、ビジョナリー、現実主義者
• ステークホルダーの役割：顧客、従業員、投資家、コミュニティ、規制当局
• 価値観に基づく役割：倫理責任者、グロースハッカー、ブランドの守護者、イノベーションリード
• 時間軸に基づく役割：短期思考者、長期戦略家

役割の数：

• 2つの役割：明快な二者択一の議論（構築か購入か、成長か収益性か）
• 3つの役割：三者間の緊張関係（スピードか品質かコストか）
• 4～5つの役割：複数のステークホルダーが関わる複雑さ（エンジニアリング、デザイン、マーケティング、財務、顧客が関わるプロダクト戦略）
• 5つを超える役割は避ける：扱いが難しくなり、統合が複雑になりすぎます

質問の枠組みを定める

適切な枠組み：

• 「YよりもXを優先すべきでしょうか？」（トレードオフが明確）
• 「AとBの適切なバランスは何でしょうか？」（緊張関係が明示されている）
• 「戦略Xを追求すべきでしょうか？」（具体的で実行可能）

適切でない枠組み：

• 「何をすべきでしょうか？」（漠然としすぎています）
• 「いいとこ取りをするにはどうすればよいでしょうか？」（誤った解決策を前提としています）
• 「誰が正しいのでしょうか？」（統合ではなく勝者がいることを前提としています）

---

ロールプレイのガイドライン

誠実な主張

各役割は次のことを行うべきです：

1. 立場を明確に述べる：何をすべきだと考えていますか？
2. 優先事項を明確にする：どのような価値観や目標が、この立場の根拠になっていますか？
3. 懸念を明らかにする：ほかのアプローチにどのようなリスクや欠点があると考えていますか？
4. 根拠を示す：どのようなデータ、経験、推論が、この見解を裏付けていますか？
5. 弱みを認める：この役割は、どのような不確実性や限界を認めていますか？

ストローマン論法を避ける：

• ❌ 「エンジニアは目新しい技術を使いたいだけだ」（戯画化）

• ✅ 「エンジニアは保守性を重視し、新しいフレームワークによって技術的負債を減らせると考えている」

• ❌ 「営業は契約を取ることしか考えていない」（見下した表現）

• ✅ 「営業は収益に責任を負っており、この機能が競争上の位置付けに不可欠だと考えている」

譲歩せずに共感する： ある視点に深く共感することと、その視点に賛同することは別です。各役割は、自分自身の物語における「主人公」であるべきです。

視点を把握するためのチェックリスト

各役割について、次の問いに答えてください：

• この視点から見た成功とは何か
• この視点から見た失敗とは何か
• この役割が最も重視する指標や根拠は何か
• この役割は、別のアプローチについて何を懸念しているか
• この役割が知っていて、ほかの人は知らないかもしれないことは何か
• この役割が直面している制約やプレッシャーは何か

---

議論の構成

生産的な対立を促す

議論の形式：

1. 賛否を交互に述べる

• 役割 A が自分の立場を主張する
• 役割 B が異議や反論を述べる
• 役割 A が異議に答える
• 役割 B の主張についても同様に繰り返す

2. 悪魔の代弁者

• 1 つの役割が「既定の」または「明白な」選択肢を提示する
• ほかの役割が前提を体系的に問い直し、リスクを明らかにする
• 目的：決定前に、選択肢を厳しく検証する

3. 建設的な対立

• 重要な判断軸を 3～5 個特定する（コスト、速度、リスク、品質など）
• 各役割がそれぞれの判断軸に対する立場を明確にする
• 視点が最も衝突する点を明らかにする

4. 決定的な論点を見つける

• 各役割に尋ねます：「考えを変えるには、何が真実である必要がありますか？」
• 議論の方向を変える、検証可能な前提や根拠を特定する
• 立場の言い直しではなく、決定的な論点に議論を集中させる

緊張関係を明らかにする質問

• 「あなたの立場に対する最も強い反論は何ですか？」
• 「［別の役割］には見えていて、あなたが見落としているかもしれないことは何ですか？」
• 「あなたたちの視点の間にある、避けられないトレードオフは何ですか？」
• 「反対の見解を最も説得力のある形で示すなら、何と言いますか？」
• 「あなたのアプローチでは、エッジケースにどのように対処しますか？」
• 「ほかの人が最適化の対象にしていない、何を最適化していますか？」

議論における危険信号

• 早すぎる合意：実際の緊張関係を明らかにしないまま、役割同士がすぐに合意する
• 話がかみ合わない：役割同士が議論に応じず、異なる論点について主張する
• 権威への訴え：根拠を示さずに「CEO がそう言ったから」と主張する
• 誤った二分法：「X をするか、失敗するかのどちらかだ」と述べ、中間の選択肢を探らない
• 根拠のない主張：根拠や推論を示さずに「誰もが Y を知っている」と述べる

---

統合のパターン

統合アプローチ

1. 重み付けした統合

• 「Xを優先しつつ、Yの懸念に対する保護策を取り入れます」
• 例：「迅速なリリース（PMの優先事項）を目指しつつ、機能フラグとモニタリング（エンジニアの懸念）を導入します」

2. 順序付け

• 「まずXを実施し、その後Yに取り組みます」
• 例：「市場をテストするためにMVPをリリースし（グロース）、プロダクトマーケットフィットが実証された後に品質へ投資します（エンジニアリング）」

3. 条件付き戦略

• 「条件Aの場合はXを実施し、条件Bの場合はYを実施します」
• 例：「第1四半期にユーザー数が10Kを超えたら規模拡大に投資し、そうでなければフィードバックに基づいて方向転換します」

4. ハイブリッドアプローチ

• 「複数の視点の要素を組み合わせます」
• 例：「中核部分は社内で構築して（制御性）、周辺コンポーネントは購入します（スピード）」

5. 再定義

• 「議論によって、真の問いはX対YではなくZだと明らかになります」
• 例：「価格設定についての議論から、まず顧客をセグメント化する必要があると分かります」

6. 制約条件の特定

• 「両方の視点が合意する、結果を左右する制約を特定します」
• 例：「スピード重視派も品質重視派も、エンジニアリングのキャパシティがボトルネックだと認めています。統合案は、まず採用することです」

統合の質を示す指標

優れた統合：

• ✅ 複数の視点の妥当性を認めている
• ✅ 何を優先するのか、またその理由を説明している
• ✅ 各視点の主要な懸念に対応している
• ✅ 受け入れるトレードオフが明確である
• ✅ 実行可能な推奨事項がある
• ✅ 重要な前提を確認するモニタリング計画がある

不十分な統合：

• ❌ 「すべてやりましょう」（優先順位がない）
• ❌ 「Xの勝ち、Yの負け」（妥当な懸念を退けている）
• ❌ 「もっと情報が必要です」（決断を避けている）
• ❌ 条件を明示しない「場合によります」
• ❌ 具体的な次の手順がない、曖昧な決まり文句

---

例

例1：簡潔な統合

意思決定：モノリスをマイクロサービスとして書き換えるべきでしょうか？

役割：

• スケーラビリティエンジニア：個別にスケールし、より速くデプロイするにはマイクロサービスが必要です
• 現実派エンジニア：書き換えには12～18か月かかり、リスクも高いです。モノリスは問題なく動いています
• 財務：投資対効果はどうなりますか？書き換えにはエンジニアリング工数で200万ドルかかります

統合案： すべてを書き換えるのではなく、スケーリングの必要性が明確な2～3個のサービス（認証、決済処理）を独立したマイクロサービスとして切り出します。中核となるビジネスロジックは、当面モノリスに残します。これにより、ボトルネックとなるコンポーネントのスケーラビリティに関する懸念に対応し（スケーラビリティエンジニア）、リスクと期間を抑え（現実派エンジニア）、コストを200万ドルから40万ドルに削減できます（財務）。切り出したサービスが成功し、このパターンの有効性が実証されたら、全面的な移行を再検討します。

例2：詳細な分析

詳細なロールプレイ、議論、統合を含む、手順をすべて示した例については、以下を参照してください。

• resources/examples/build-vs-buy-crm.md - 営業、エンジニアリング、財務によるCRMプラットフォームの意思決定に関する議論

---

このスキルを使用しない場合

次の場合は、ロールプレイ・議論・統合を使用しないでください。

❌ 明確な専門家が1人だけいる場合：1人が決定的な専門知識を持ち、他の人がその判断に従うなら、その専門家に尋ねてください ❌ 本当の対立がない場合：関係者が実際には合意しているなら、議論は形式的なものになります ❌ 価値観について交渉できない場合：倫理的な一線に関わるなら、非倫理的な立場をロールプレイしないでください ❌ 時間が切迫した意思決定の場合：数分以内に決断しなければならないなら、完全な議論は省略してください ❌ 実装の詳細に関する場合：意思決定が「するかどうか」や「何をするか」ではなく「どのようにするか」に関するものなら、議論ではなく技術的な協業を利用してください

次の場合は、よりシンプルなアプローチを使用してください。

• ✅ 明確なデータがあり、意思決定が単純 → 意思決定マトリックスまたは期待値を使用
• ✅ 評価ではなく創造的な選択肢が必要 → 議論ではなくブレインストーミングを使用
• ✅ 視点の対立ではなく詳細な分析が必要 → 分析フレームワークを使用
• ✅ 意思決定ではなく実装計画が必要 → ロールプレイではなくプロジェクト計画を使用

---

高度なテクニック

複数のステークホルダーが関わる複雑な意思決定については、以下をご覧ください：resources/methodology.md

• 複数ラウンドの議論（立場を反復的に洗練する）
• 対象者の視点への切り替え（ステークホルダーによって統合結果がどのように変わるか）
• ファシリテーションのアンチパターン（議論がうまくいかない原因）
• 不確実性がある状況での統合（証拠が不完全な場合）
• ステークホルダーのマッピング（誰を代表させる必要があるかを特定する）

---

リソース

• resources/template.md - ロールプレイ → 議論 → 統合分析のための構造化テンプレート
• resources/methodology.md - 高度なファシリテーションのテクニックと議論の形式
• resources/examples/ - 分野ごとの完全な実例
• resources/evaluators/rubric_chain_roleplay_debate_synthesis.json - 品質評価ルーブリック（10項目）