why

why skill の概要

why skill は、症状を根本原因の連鎖に変え、さらに実行可能な修正案まで落とし込むための、Five Whys に特化した分析ツールです。UX Audit、プロダクトの不具合、バグ、業務プロセスの崩れなどで why skill が必要なら、「何が起きたか」と「なぜ起きたか」を切り分けるのに役立ちます。

why skill は何のためのものか

why は、「ユーザーが離脱した」「ビルドが失敗した」「チームが締切に間に合わなかった」といった最初の説明が浅い可能性が高いときに使います。この skill は、見えている症状で終わらず、システム的な原因にたどり着くまで分析を前に進めるように設計されています。

どんな人に向いているか

この why ガイドは、フレームワークをゼロから作らずに、構造化された根本原因の掘り下げをしたいオペレーター、アナリスト、エンジニア、UX レビュー担当者に向いています。すでに具体的な問題文があり、それを規律ある手順で検証したい人に適しています。

何が便利なのか

主な価値は、テンポと焦点にあります。再利用しやすいプロンプトの形、標準の深さ、そして原因が本当に症状を説明しているかを確認する検証ステップが用意されているためです。一般的なブレインストーミングが同じ答えをぐるぐる回るだけになりがちな場面では、why の導入価値が高くなります。

why skill の使い方

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

why skill を自分の skills ワークフローにインストールし、曖昧なテーマではなく具体的な症状を添えて呼び出します。たとえば /why checkout conversion fell 18% after the redesign や /why CI failures spike on main branch のように始めるとよいでしょう。

理論ではなく、問題文を渡す

この skill は、1つの観測可能な問題、その問題が現れている文脈、そして分かっている制約を渡したときに最もよく機能します。良い入力例: Mobile users abandon the signup form on step 2 after the new validation rules shipped; analyze root causes in the current UX flow. 悪い入力例: Why is UX bad?

まず重要なソースファイルを読む

まず SKILL.md を読んで分析の流れを把握し、必要に応じて環境に存在する README.md、AGENTS.md、metadata.json、および rules/、resources/、references/、scripts/ フォルダを確認します。この repository では SKILL.md が最重要の情報源なので、最短ルートは、調整に入る前に分析手順と例を先に読むことです。

分析を作業セッションとして進める

why は、症状を述べ、各 “why” に証拠で答え、原因が根本的かつ検証可能になった時点で止める、というガイド付きの連鎖として使います。原因が1つに見えても、無理に一本化せず分岐させるべきです。最後は、症状を隠すのではなく根本原因を取り除く変更案で締めます。

why skill FAQ

why は技術的なデバッグ専用ですか？

いいえ。why skill は、実際の症状を説明できるのであれば、UX Audit、オペレーション、プロダクト、サポート、チームプロセスの問題にも使えます。重要なのは、原因と結果の連鎖で追跡できる問題であることです。

毎回5回分の反復が必要ですか？

必ずしもそうではありません。5回は既定の深さですが、より良い基準は「説明が実行可能で安定した時点で止める」ことです。3ステップで本当に根本原因まで到達しているなら、無理に2回追加してもノイズが増えるだけです。

why は通常のプロンプトと何が違いますか？

通常のプロンプトはアイデアを求めることが多いのに対し、why は規律ある因果関係を問います。根本原因分析、是正アクション、または原因から症状へ逆向きに検証できるレビューが欲しいときに向いています。

どんなときに why を使うべきではありませんか？

発散的なアイデア出し、広い戦略検討、あるいは観測可能な症状がない問題には使わないでください。原因の連鎖を検証できるほど明確に問題を定義できないなら、why skill は浅い推測しか出せません。

why skill を改善するには

症状をもっと鋭く書く

why の出力品質は、最初の1文で大きく決まります。何が壊れたのか、誰が影響を受けたのか、いつ変化したのか、どの環境なのかを入れてください。たとえば After the new onboarding copy, first-time activation dropped on iOS only. は、activation is down よりはるかに良い入力です。

結論ではなく証拠を足す

ログ、ユーザーの発言、ファネルのステップ、スクリーンショット、タイムスタンプ、リリースマーカーなどがあれば一緒に渡します。証拠があると、why は相関と因果を分けやすくなり、最初にもっともらしい説明へ安易に収束するのを防げます。

チェーンを逆向きに検証する

良い why の結果は、根本原因から症状までを逆にたどって説明できるはずです。最後の原因が前のステップを明確に生み出していないなら、実行に移す前に連鎖を見直すか、分岐に分けてください。

見つかった内容を、1つの修正可能な行動に落とす

最良の why の成果は、出荷・文書化・計測のいずれかにつながる変更で終わります。次のアクションは、実際にコントロールできる原因に絞り、その後で skill を再実行して、症状が期待どおりに動くか確認してください。