role-switch

役割の切り替え

目次

1. ワークフロー
2. 役割選択のパターン
3. 統合の原則
4. 一般的なパターン
5. ガードレール
6. クイックリファレンス

ワークフロー

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

Role Switch Progress:
- [ ] Step 1: Frame the decision or situation
- [ ] Step 2: Select relevant roles
- [ ] Step 3: Inhabit each role's perspective
- [ ] Step 4: Surface tensions and tradeoffs
- [ ] Step 5: Synthesize alignment and path forward

ステップ 1：意思決定または状況を明確にする

何を決定するのか、主な制約（時間、予算、範囲）、そして合意形成が重要な理由を明確にします。種類ごとの意思決定の明確化については、一般的なパターンを参照してください。

ステップ 2：関連する役割を選択する

目標、動機、または制約が異なる役割を 3～6 個選びます。ステークホルダーのマッピングについては、役割選択のパターンを参照してください。複雑なマルチステークホルダーの意思決定については、RACI と権力・関心分析を学ぶためにresources/methodology.mdを参照してください。

ステップ 3：各役割の視点に立つ

各役割について、何を最適化しようとしているか、何を恐れているか、成功をどのように測るか、どのような制約に直面しているかを明確にします。構造化された分析にはresources/template.mdを使用してください。現実的なロールプレイについては、認知的共感の手法を学ぶためにresources/methodology.mdを参照してください。

ステップ 4：緊張関係とトレードオフを明らかにする

視点が対立する箇所を特定し、両立しない目標を整理して、明示的なトレードオフを明確にします。緊張関係の分析については、統合の原則を参照してください。

ステップ 5：合意形成と今後の道筋を統合する

共通点を見つけ、主要な懸念に対処する解決策を提案し、勢いをつけられるように意思決定の順序を組み立てます。resources/evaluators/rubric_role_switch.jsonを使って自己評価してください。最低基準：平均スコア ≥ 3.5。

役割選択のパターン

典型的なプロダクトの三者構成（最も一般的）：

• エンジニアリング：実現可能性、技術的負債、システムの複雑さ、保守性
• プロダクト：ユーザー価値、ロードマップの優先順位付け、市場投入のタイミング、機能の完全性
• デザイン：ユーザーエクスペリエンス、アクセシビリティ、一貫性、満足感

ビジネス上の意思決定でよくある四者構成：

• 財務：コスト、ROI、キャッシュフロー、ユニットエコノミクス、利益率
• 営業：顧客獲得、案件成立、競争上の位置づけ、ノルマ達成
• マーケティング：ブランド認知、顧客生涯価値、ポジショニング、コンバージョンファネル
• オペレーション：スケーラビリティ、プロセス効率、リスク管理、リソース活用

規制／コンプライアンス関連の状況：

• 法務：リスク軽減、責任、契約条件、知的財産の保護
• コンプライアンス：規制遵守、監査証跡、ポリシーの適用、認証
• プライバシー／セキュリティ：データ保護、脅威モデル、アクセス制御、インシデント対応
• 倫理：公平性、透明性、ステークホルダーへの影響、価値観との整合性

外部ステークホルダー：

• エンドユーザー：使いやすさ、信頼性、コスト、プライバシー、満足感
• 顧客（B2B）：統合の容易さ、サポート品質、ベンダーの安定性、総所有コスト
• パートナー：収益分配、相互利益、統合の負担、戦略的整合性
• 規制当局：公益、安全性、競争、透明性

統合の原則

共通点を見つける：

1. 共通の目標：すべての役割が最終的に望んでいることは何ですか？（例：会社の成功、顧客満足度）
2. 両立可能な副次目標：進め方が異なっていても、目標が一致するのはどこですか？
3. 共通の懸念：すべての役割が避けたいことは何ですか？（例：評判の低下、セキュリティ侵害）

対立を解決する：

• 段階的な意思決定：「まず X を行い（役割 A の要望を満たす）、次に Y を行う（役割 B の要望を満たす）」（例：パイロットの後に規模を拡大）
• ハイブリッドなアプローチ：複数の視点の要素を組み合わせる（例：フリーミアム＝マーケティング＋財務）
• 制約を創造性につなげる：ある役割の制限を、別の役割の解決策を洗練させるために活用する（例：予算の制約によって優先順位付けを促す）
• リスクの軽減：安全策を講じて懸念に対処する（例：エンジニアリングが技術的負債を懸念 → リファクタリングのスプリントを予定に組み込む）

視点が本当に両立しない場合：

• 意思決定をエスカレーションする：トレードオフを明確に示して、リーダーシップに判断を仰ぐ
• 実験を行う：パイロットでデータを集め、意見をエビデンスに変える
• 意思決定を切り分ける：担当者を分けて複数の意思決定に分割する
• トレードオフを明示的に受け入れる：後から参照できるよう、選択とその理由を記録する

よくあるパターン

パターン 1：構築するか購入するかの意思決定

• 役割：エンジニアリング（制御、カスタマイズ）、財務（TCO）、プロダクト（市場投入までの時間）、法務（ベンダーリスク）、運用（サポート負荷）
• 典型的な緊張関係：エンジニアリングは制御を望み、財務は構築コストの過小評価を懸念し、PM は遅延による機会費用を重視する
• 統合の道筋：購入案をフォールバックとして構築案を残したうえで、購入案をパイロットする、コアを構築して周辺部分を購入する、構築期間に期限を設け購入を代替策とする

パターン 2：機能の優先順位付け

• 役割：PM（ロードマップのビジョン）、エンジニアリング（技術的な実現可能性）、デザイン（UX の品質）、営業（顧客からの要望）、ユーザー（実際のニーズ）
• 典型的な緊張関係：営業は約束したものをすべて実現したいと考え、エンジニアリングはスコープクリープを懸念し、ユーザーはシンプルさを求め、PM は全体のバランスを取る
• 統合の道筋：MoSCoW による優先順位付け（必須／すべき／できれば／対象外）、段階的なリリース、v1 と v2 のスコープ設定

パターン 3：価格戦略

• 役割：財務（利益率）、マーケティング（ポジショニング）、営業（成約率）、顧客（価値の認識）、プロダクト（機能の利用制限）
• 典型的な緊張関係：財務はプレミアム価格を望み、営業は競争力のある価格を望み、マーケティングはシンプルさを望み、プロダクトは価値に基づく料金プランを望む
• 統合の道筋：段階的な価格設定（複数の顧客セグメントに対応）、従量課金（価値と価格を連動）、価格アンカリング（プレミアム＋標準）

パターン 4：組織の変革（例：オフィス勤務への復帰）

• 役割：リーダーシップ（コラボレーション）、従業員（柔軟性）、人事（人材の定着）、財務（不動産コスト）、マネージャー（生産性）
• 典型的な緊張関係：リーダーシップは偶発的な出会いの減少を懸念し、従業員は自律性の喪失を懸念し、財務は埋没費用を重視し、人事は離職を懸念する
• 統合の道筋：ハイブリッドモデル（バランスを取る）、役割に応じた方針（柔軟性を持たせる）、試行期間（データに基づいて判断）、任意参加のインセンティブ（自発性を尊重）

パターン 5：技術的な移行

• 役割：エンジニアリング（技術的な改善）、PM（機能の凍結）、ユーザー（ダウンタイムの可能性）、DevOps（運用リスク）、財務（ROI）
• 典型的な緊張関係：エンジニアリングは長期的なメリットを見込み、PM は短期的なコストを懸念し、ユーザーは混乱を懸念し、財務は ROI の根拠を求める
• 統合の道筋：段階的な移行（リスクを軽減）、まず機能の同等性を確保する（混乱を最小限に抑える）、ROI の予測（投資を正当化する）

ガードレール

藁人形論法のような視点を避ける：

• 役割を戯画化しないでください（例：「財務部門はコスト削減しか考えていない」）
• 相手の視点を好意的に捉え、その見解を最も強く表現するとどうなるかを考えてください。
• 自分のバイアスに反する証拠を探してください。

立場と利害を区別する：

• 立場：相手が望んでいると言うこと（表面的な要求）
• 利害：なぜそれを望むのか（根底にあるニーズ）
• 例：「この機能が欲しい」（立場）のは、「顧客が離脱している」（利害＝顧客維持）のためです。
• 統合は立場ではなく、利害のレベルで行います。

情報の非対称性を認識する：

• 役割によっては、他の役割が持っていない背景情報を持っています（例：法務部門は機密性の高い賠償責任のリスクを把握しています）。
• 前提を明示してください：「法務部門が私たちの知らない情報を持っているなら、この分析は変わる可能性があります」
• 実際の関係者に、相手の視点を踏まえた見立てを検証してもらいましょう。

実際の関係者からの意見に取って代わらない：

• 役割を切り替えて考えるのは、対話の準備のためであり、対話に取って代わるものではありません。
• 意見を集める代わりに使うのではなく、提示する前に提案を検証するために使ってください。
• 関係者へのアクセスが限られている場合や、提案を広く共有する前に磨き上げる場合に最も有効です。

力関係は重要です：

• 意思決定において、すべての視点が等しい重みを持つわけではありません（階層、専門知識、説明責任）。
• 統合では、誰が決定権を持つのかを考慮してください。
• 合意が常に可能、または望ましいとは限りません。

クイックリファレンス

リソース：

• クイック分析：resources/template.md
• 複雑なステークホルダーマッピング：resources/methodology.md
• 品質評価基準：resources/evaluators/rubric_role_switch.json

5 ステップのプロセス：意思決定を定義 → 役割を選択 → 視点に立つ → 緊張関係を明らかにする → 合意を統合する

役割の選択：目標、インセンティブ、制約が異なる役割を 3～6 つ選びます。

統合の原則：共通の目標を見つけ、対立を解決する（順次、ハイブリッド、創造性を生む制約）。両立しない場合は上位者に判断を委ねます。

避けること：藁人形論法のような視点、立場と利害の混同、実際の関係者からの意見に取って代わること