issue-framinglisted

## Purpose 「何が問題なのか」が曖昧なまま設計・実装へ進むリスクを防ぐ。 相談・課題を構造化して、次のアクションを選べる状態にする。 ## Use When - 新機能・改善・施策の検討初動 - 「なんとなく困っている」状態の言語化 - 要件定義前の���点整理 - 設計前の前提確認 - 壁打ち・ブレインストーミングの初動整理 ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **相談内容**: 何に困っているか、何を決めたいか（自由記述可） - **背景**: なぜ今この問題が浮上したか - **制約**: 時間・予算・技術・組織上の制約（わかる範囲で） - **関係者**: 影響を受ける人・チーム・ユーザー - **期待するアウトプット**: この場で何が決まれば前に進めるか ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: この問題の核心は何か（1〜3点に絞る） 2. **根拠**: その論点をそう判断した理由 3. **リスク**: 放置した場合・誤った判断をした場合の影響 4. **含意**: この論点が示す構造的・中長期的な意味 5. **改善案**: 現実的な対応の選択肢（複数提示） 6. **代替案**: 正攻法以外の選択肢・別の切り口 7. **判断材料**: 次のアクションを選ぶために人間が確認すべき情報 ## Review Lens - **目的妥当性**: この問題を解くことが本当に目的に対して有効か - **範囲の過不足**: 問題を過大に取るか、過小に取っていないか - **中長期リスク**: 短期解決が長期に負債を生まないか - **LAB全体との整合性**: LMS / 自動化基盤 / B2B展開との矛盾がないか - **非エンジニア理解可能性**: 非エンジニアの関係者に説明できるか - **他LLM移植耐性**: Claude 固有の解釈に依存していないか ## Instructions 1. 相談内容を読み、論点候補を3〜5点リストアップする 2. 各論点を「目的」「成功条件」「失敗条件��「制約」の4軸で確認する 3. 最も核心に近い論点を1〜3点に絞る（根拠を添える） 4. リスクを「今すぐ」「3ヶ月後」「1年後」のタイムスパンで整理する 5. 改善案は最低2案、代替案は最低1案を提示する 6. 判断材料を「人間が今すぐ確認できるもの」として具体化する 7. 不明な前提がある場合は、仮定を明示した上で進める（推測で埋めない） ## Guardrails - 推測で仕様を埋めない。前提が不明な場合は「前提: ○○と仮定」と明示する - 解決策を1つに閉じない。必ず複数の選択肢を残す - コスト比較（時間・技術的負債・機会コスト）を省略しない - 「これが正解」と断定しない。判断は人間に委ねる - 実装を勝手に提案・確定しない（この skill は論点整理まで） - 問題の範囲を自分で勝手に狭めない ## LAB Cross-Check 実行結果に対して以下を確認すること。 | 観点 | 状態 | 備考 | |---|---|---| | 自動化フロー | — | 自動化の可否・影響を含んでいるか | | データ / 認証 / ログ | — | データ構造・権限・監査への影響を確認したか | | 実装 / 運用フロー | — | 実装可能性・運用負荷を考慮したか | | 非