problem-framing-canvas

problem-framing-canvas skill の概要

problem-framing-canvas ができること

problem-framing-canvas skill は、チームが MITRE の Problem Framing Canvas を使って、解決策に飛びつく前にまず問題を定義できるよう支援します。要望があいまいなとき、関係者の意見が割れているとき、あるいはチームが本来とは違う成果指標を最適化していそうなときに特に有効です。

どんな人に向いているか

problem-framing-canvas skill は、散らかった依頼を共有できる問題定義に落とし込みたい PM、デザイナー、リサーチャー、ファシリテーターに向いています。次に何をすべきかの材料が欲しいのであって、単なるアイデア出しでは足りない、という場面では problem-framing-canvas for Decision Support として特に役立ちます。

何が違うのか

この skill は対話的で、しかも良い意味でかなり方針がはっきりしています。Look Inward、Look Outward、Reframe の3段階を通す設計になっているため、バイアスの確認、関係者の見落とし防止、そしてワークショップやロードマップ、発見フェーズの計画に使える最終的な “How Might We” 形式への再定義まで、汎用プロンプトよりしっかり進められます。

problem-framing-canvas skill の使い方

インストールして主要ファイルの場所を確認する

problem-framing-canvas install を行うときは、skill ディレクトリに表示されている repo パスを使い、まず skills/problem-framing-canvas/SKILL.md から読み始めます。続いて template.md で出力の形を確認し、examples/sample.md で完成度の高い canvas がどう見えるかを把握してください。

テーマではなく、実際の問題を渡す

problem-framing-canvas usage が最も力を発揮するのは、症状、状況、意思決定の圧力が具体的に示されているときです。良い入力例は、“Reduce onboarding drop-off for first-time admins in enterprise SaaS, where support tickets show confusion at step 2.” のように、背景まで含んだものです。弱い入力は単に “Improve onboarding.” だけのようなケースです。

3フェーズのワークフローで進める

よい problem-framing-canvas guide 入力は、skill が次の流れで進むための材料になります。

• Look Inward: チームが何を前提にしているか、何を好んでいるか、何を見落としているか
• Look Outward: 誰がその問題を感じているか、いつ起きるのか、誰が対象外になっているか
• Reframe: より鋭い問題定義と、実際に使える HMW 質問

相性のよい依頼フォーマット

canvas の出力は一度でまとめて依頼し、対象ユーザー、事業目標、既知の証拠など、重要な制約があれば一緒に伝えるのが効果的です。たとえば “Use problem-framing-canvas to frame our churn issue for new SMB customers, assuming we only have support logs and product analytics.” のように書くと、skill が抽象化しすぎず、現実に根ざした出力を返しやすくなります。

problem-framing-canvas skill の FAQ

通常のプロンプトより優れているのか？

問題があいまいなら、たいていは yes です。普通のプロンプトだと早い段階でアイデア出しに進みがちですが、problem-framing-canvas はまず問題定義を強制します。症状の解釈をめぐってチームが迷っているときに、ここが最大の価値になります。

どんなときは使わないほうがいいか？

すでに問題が明確で、必要なのが実行計画、コピーライティング、解決策の発想なら problem-framing-canvas は使わないでください。これはフレーミング用の tool であって、実行計画や優先順位付けの framework ではありません。

初心者でも使いやすいか？

はい。canvas の構造自体はシンプルです。ただし、出力の質は入力次第です。初心者が最も価値を得やすいのは、1つの具体的な問題、対象ユーザー、そして少なくとも1つの既知の制約か証拠を持ち込んだときです。

他のプロダクトワークフローとどう組み合わせるか？

ディスカバリーの整理、ロードマップの議論、ソリューションのブレストより前に使うのが最適です。まず問題に対する共通言語をそろえ、そのあとでフレームが明確になってからリサーチ質問、実験設計、アイデア発想へ進めてください。

problem-framing-canvas skill を改善するには

意見だけでなく証拠を渡す

品質を大きく上げる一番の方法は、具体的な入力を入れることです。たとえば、サポートの傾向、ファネルの離脱、顧客の発言、失注理由、観察された行動などが挙げられます。problem-framing-canvas は、症状と根本原因を切り分けられると一気に精度が上がります。

境界条件を明示する

チームに制約があるなら、最初から伝えてください。対象セグメント、期限、プラットフォーム、法務上の制限、事業目標などです。そうした情報があると、skill が何でも解決するような広すぎる framing を避け、実際に使える HMW 質問に落とし込みやすくなります。

よくある失敗パターンに注意する

最も多い失敗は、“We need a better dashboard” や “We need AI automation” のような、解決策の形をした問題文です。problem-framing-canvas skill の出力を改善するには、まずユーザーの痛みと状況を言い直し、そのうえで何が本当に詰まっているのか、何が誤解されているのかを問うのが有効です。

1回、より絞ったフォローアップで詰める

最初の canvas でまだ広いなら、次はより狭くするよう促してください。たとえば “Reframe this for first-time users only,” や “Rewrite the problem using only evidence we can verify this quarter.” のようなフォローアップが有効です。こうした絞り込みは、追加のアイデアを求めるよりも意思決定の質を高めることがよくあります。