analyse-problem

analyse-problem skill の概要

analyse-problem は何のためのものか

analyse-problem skill は、散らかった課題を、背景、現状、目標状態、真因分析、対策、実行計画、フォローアップまで含む A3 問題整理メモに落とし込むための skill です。Strategic Planning、オペレーション、プロダクト、エンジニアリングで、ブレストではなく、意思決定に使える問題定義が必要なときに最適です。

どんな人にインストール向きか

問題をわかりやすく説明したい、関係者の認識をそろえたい、症状から原因へ整理したい、という場面が定期的にあるなら analyse-problem をインストールする価値があります。インシデントレビュー、業務改善、プロジェクトのボトルネック整理、計画会議などを、再現性のある形式で進めたい人に向いています。

何が違うのか

価値は「AI にもっと文章を書かせること」ではなく、制約をかけることにあります。analyse-problem は、問題を1ページにまとめ、事実と仮説を分け、最後にアクションと検証で締めるようモデルを促します。そのため、Strategic Planning 向けの一般的な analyse-problem プロンプトよりも、意思決定の枠組みが締まった、実務で使いやすい出力になりやすいです。

analyse-problem skill の使い方

インストールして起動する

skills manager から通常のインストール手順で追加し、その後は短い問題文を添えて analyse-problem skill を呼び出します。リポジトリ上の使い方は /analyse-problem [problem_description] で、デフォルトでは任意の problem description と markdown 出力をサポートしています。環境によって skill の割り当て方法が違う場合でも、同じ意図、つまり簡潔で具体的な問題文を渡してください。

skill に渡す入力を正しく整える

良い入力には、問題、範囲、根拠が入っています。たとえば、「今月、enterprise accounts の顧客 onboarding 完了率が18%低下した。原因を分析し、対策を提案してほしい」といった形です。一方で「onboarding を改善して」のような曖昧な入力では、モデルが対象、責任者、成功指標を推測するしかありません。analyse-problem の用途では、次を含めると精度が上がります。

• 症状
• 影響を受けているプロセスやチーム
• データ、事例、時系列情報
• 望ましい結果、または制約

先に読むべき repository の部分

まず SKILL.md を確認し、続いて README.md、AGENTS.md、metadata.json にリンクされた指示や、存在する場合は rules/、resources/、references/、scripts/ などのフォルダを見ます。この repo では主な情報が plugins/kaizen/skills/analyse-problem に集約されているため、余計な構成要素を深追いする必要はあまりありません。

出力をよくするためのプロンプトの整え方

良い analyse-problem のガイド用プロンプトは、A3 の各セクションを埋められるだけの具体性があります。たとえば、
“Use analyse-problem to document why release delays increased in Q2. Include baseline metrics, likely root causes, 3 countermeasures ranked by impact and effort, and a 30-day follow-up plan.”
のように依頼すると、より実用的な結果になります。なぜなら、モデルに整理すべき事実と、支えるべき判断を与えられるからです。単なる一般的な分析を求めるより、ずっと使えるアウトプットになりやすいです。

analyse-problem skill の FAQ

analyse-problem は Strategic Planning 専用ですか？

いいえ。問題を整理し、調査し、アクションを割り当てる必要がある場面なら、プロダクト課題、運用ボトルネック、チームプロセスの不具合、Strategic Planning のレビューまで幅広く使えます。A3 形式自体は汎用的ですが、出力を他者と共有する前提があるときに特に価値が高まります。

普通の prompt と何が違いますか？

普通の prompt でも分析は依頼できますが、analyse-problem skill には再利用できる構造と出力の規律があります。真因、対策、フォローアップを抜け漏れなく、一定の形式で揃えたいときに、この違いが効いてきます。自由記述の説明よりも、実務判断に向いた形でまとまります。

初心者でもうまく使えますか？

はい、入力が具体的であれば使えます。初心者がつまずくのは、たいてい問題が曖昧なときです。観測された症状、範囲、時期、おおまかな目標など、わかっていることをそのまま入れてください。skill は不完全な思考を整理する助けにはなりますが、足りない事実を安全に創作することはできません。

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

簡単な要約、進捗報告、創造的なアイデア出しだけが必要なときは、analyse-problem は向いていません。まだ問題の範囲が安定していない場合も不向きです。その場合は、構造化された分析を求める前に、まず問題定義を固めてください。

analyse-problem skill を改善する方法

結論だけでなく根拠を入れる

品質を最も大きく押し上げるのは、メトリクス、事例、障害の時刻、ユーザーの声、業務メモなどの具体情報です。すでに真因の仮説があるなら、それを事実ではなく仮説として明示してください。そうすることで、分析が仮説の追認ではなく、検証ベースになります。

意思決定に使える出力を求める

analyse-problem では、チームが動ける情報を求めるのが重要です。たとえば、原因の優先順位、原因にひもづいた対策、担当者、依存関係、検証計画などです。Strategic Planning として活かしたいなら、長い説明文ではなく、impact と effort のトレードオフを明示するよう依頼してください。

よくある失敗パターンを避ける

典型的な失敗は、症状の説明に終始して、目標状態の指定が弱いことです。もう一つは、複数の問題を1ページに混ぜ込んでしまうことです。関係のない論点は分け、1つの分析では1つの判断、1人の責任者、1つの測定可能な成果に絞ってください。

最初のドラフトの後に見直す

最初の出力では、欠けているデータ、弱い因果関係、真因と合っていないアクションがないかを確認します。そのうえで、予算、期限、チームの稼働余力、経営層レビュー用の指定フォーマットなど、新しい事実や制約を加えて prompt を磨き直してください。