industry-problem-framing

業界課題の定義

曖昧なビジネス課題を、調査およびパイロット実施が可能な研究開発課題に変換します。

目的は、解決策を早まって検討することを防ぐことです。「AIを使って業務を改善する」といった曖昧な依頼は、手法を提案する前に、具体的な意思決定、ワークフロー、指標、必要なエビデンスへと落とし込む必要があります。

このスキルを使用する場面

次の場合にこのスキルを使用します。

• ユーザーが明確でないビジネス上または業界上の課題を抱えている場合。
• ステークホルダー間で、課題の意味について意見が分かれている場合。
• ユーザーがアイデアを出したいものの、表面的なアイデアの羅列は避けたい場合。
• 次のステップが文献検索、ソリューション設計、またはパイロット計画である場合。
• ユーザーが社内向けの研究開発課題定義メモを必要としている場合。

ユーザーがすでに明確な課題を持ち、論文に裏付けられた手法を求めている場合は、代わりに publication-grounded-solution-design を使用してください。

ワークフロー

1. 元の課題の記述を記録する

ユーザーの課題をそのまま書き出し、次の項目を抽出します。

• 分野と事業部門。
• 現在のワークフロー。
• ユーザーと意思決定者。
• 課題点。
• 制約。
• 既知のデータソース。
• 提案されている解決策（ある場合）。
• なぜ今この課題が重要なのか。

この段階では、表現を改善しないでください。まず曖昧さをそのまま保ちます。

2. 実際の意思決定またはワークフローを特定する

業界の研究開発課題の多くは、意思決定またはワークフローの変更に関するものです。

次の点を確認します。

• 現在、誰が意思決定を行っていますか？
• どの情報を使っていますか？
• 意思決定の後にどのようなアクションが取られますか？
• どのような失敗が大きな損失につながりますか？
• モデル／システムが誤っていた場合、何が起こりますか？
• 目標は、自動化、優先順位付け、説明、推奨、モニタリング、インサイトの創出のどれですか？

課題を次の1つ以上に分類します。

• 予測。
• ランキングまたは優先順位付け。
• 異常検知。
• セグメンテーション。
• 推奨または次善アクション。
• 情報抽出。
• 意思決定支援。
• プロセスマイニング。
• 因果効果の測定。
• 予測。
• 最適化。
• ナレッジマネジメント。
• 人間の生産性向上支援。

3. ステークホルダーとインセンティブを整理する

各ステークホルダーについて、次の項目を記録します。

ステークホルダー	課題	望ましい成果	制約	起こりうる対立

該当する場合は、業務、リスク、コンプライアンス、法務、データ、製品、エンジニアリング、現場のユーザーを含めます。

4. 課題点を仮説に変換する

反証可能な仮説を作成します。

If we [intervention], then [target metric] improves for [population/process] because [mechanism], compared with [baseline].

例：

• 高リスクの案件を手動レビューのために優先順位付けすれば、低価値の案件を早い段階で除外できるため、調査担当者が1時間あたりに処理する真陽性の件数が増えます。
• 苦情対応時に類似する解決済み案件を検索できれば、担当者が検証済みの解決パターンを再利用できるため、平均対応時間が短縮します。

5. ビジネス指標と技術指標を分ける

ビジネス指標は、その取り組みが重要かどうかを示します。技術指標は、システムが機能するかどうかを示します。

例：

• ビジネス：レビュー済み案件あたりのコスト、解決までの時間、リスクを一定にした場合の承認率、不正損失、顧客離反、NPS、SLA 遵守率。
• 技術：precision@k、一定の作業量における再現率、キャリブレーション、AUC、レイテンシ、抽出 F1、ハルシネーション率、人間の受容率。

すべての技術指標をビジネス上の意思決定に結び付けます。アクションに影響しない指標は除外します。

6. データとエビデンスの要件を特定する

次の項目を列挙します。

• 利用可能なテーブル／文書／ログ。
• ラベルまたは代理指標。
• 観測期間。
• リークのリスク。
• プライバシーまたはコンプライアンス上の制約。
• 分析単位。
• 対象範囲。
• データの更新頻度。
• 統合方法。

次の要因によって課題が阻まれているかどうかを明記します。

• ラベルの不足。
• 信頼性の低い正解データ。
• アクションログの欠如。
• 担当者が不明確。
• 成功を測定できない。
• コンプライアンス上の制約。
• サンプルサイズの不足。
• 行動の非定常性。

7. 検索の方向性を示す

定義した課題を、文献検索の手がかりに変換します。

• 分野に関する用語。
• 手法に関する用語。
• ベンチマークに関する用語。
• 類似した課題の形を持つ隣接分野。
• 否定的な結果や限界に関する検索クエリ。

これにより、publication-grounded-solution-design または literature-triangulation への引き継ぎが可能になります。

出力形式

# Industry problem framing: [short title]

## Raw problem

## Clarified problem statement
For [stakeholder/process], improve [decision/workflow/outcome] by using [available signals/interventions], subject to [constraints], measured by [business and technical metrics].

## Stakeholder map
| Stakeholder | Pain | Desired outcome | Constraint | Possible conflict |
|---|---|---|---|---|

## Decision/workflow analysis
- Current workflow:
- Decision point:
- Failure modes:
- Cost of errors:
- Human-in-the-loop needs:

## Candidate hypotheses
1. If ..., then ..., because ..., compared with ...

## Metrics
- Business metrics:
- Technical metrics:
- Guardrail metrics:

## Data and feasibility
- Available data:
- Labels/proxies:
- Leakage risks:
- Compliance/privacy constraints:
- Blockers:

## Literature and precedent search directions
- Domain queries:
- Method queries:
- Adjacent-domain analogues:
- Limitation queries:

## Recommended next step

品質基準

適切な枠組みでは、何を検索し、何を測定し、手法を提案する前に何を明確にすべきかが明らかになります。