lean-ux-canvas

lean-ux-canvas skill の概要

lean-ux-canvas ができること

lean-ux-canvas skill は、あいまいなプロダクトアイデアを Lean UX Canvas v2 に落とし込むのを助けます。Lean UX Canvas v2 は、ビジネス上の課題、期待する成果、ユーザー、仮説、リスク、そして最小限で有効な実験を1ページで整理するフレーミングツールです。何を作るべきか」から「まず何を学ぶべきか」へ進みたいプロダクトマネージャー、ファシリテーター、デザイナー、そして AI 支援ワークフローに特に向いています。

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

解決策に飛びつく前に、構造化された探索が必要なら lean-ux-canvas skill を使うべきです。ワークショップ準備、ステークホルダーとの認識合わせ、初期のプロダクト設計に強く効きます。一方で、すでに検証済みのバックログがあり、必要なのが実装タスクだけなら、出番は少なめです。

何が違うのか

この skill は、「作る前に学ぶ」ことにかなり強い意志を持っています。リポジトリは Lean UX Canvas をブレスト用のポスターではなく、意思決定のための補助ツールとして扱います。ビジネス課題を定義し、最もリスクの高い仮説を特定し、それを検証できる最小工数の実験を選ぶよう促します。だからこそ、feature request の中に隠れた前提を減らしたいときに、lean-ux-canvas は価値を発揮します。

lean-ux-canvas skill の使い方

インストールして、まず見るべきファイルを確認する

環境に合った lean-ux-canvas の install command を使ってインストールしたら、まず skills/lean-ux-canvas/SKILL.md を読みます。あわせて、プロンプトを投げる前に template.md と examples/sample.md も確認してください。キャンバスの具体的な形と、この skill が求める粒度が、その2つのファイルでわかります。補助スクリプトや reference フォルダはないため、コアの skill ファイルが実質的な唯一の正本です。

実際の文脈を入れてプロンプトする

lean-ux-canvas の使い方は、漠然とした取り組みではなく、具体的な課題を渡したときに最もよく機能します。良い入力には、プロダクト領域、何が変わったのか、誰に影響しているのか、どの指標や行動が重要かを含めます。たとえば、「オンボーディング変更後、trial-to-paid が 18% から 11% に落ちた。セットアップを最後まで終えない enterprise admin 向けに Lean UX Canvas を作ってほしい」は、「オンボーディングの canvas を作って」よりずっと強い入力です。

実践的なワークフローに沿う

lean-ux-canvas の基本的な流れは、ビジネス課題を説明する → 意図する成果を特定する → 主なユーザーセグメントを定義する → 現在の仮説を並べる → 仮説と最もリスクの高い前提を出力させる、です。その後、出力を使って1つの小さな実験を選びます。問題のフレーミングを飛ばしていきなり解決策を求めると、成果やユーザー価値が明確でないため、仮説欄の精度が落ちてしまいます。

最初の実行で頼むべきこと

Skill Authoring やワークショップ支援で lean-ux-canvas を使うなら、まずは埋めた canvas を出力させ、そのあとで短いファシリテーション要約と、優先順位をつけた実験案を依頼します。実現可能性に影響する制約も含めてください。たとえば、期限、ユーザーにアクセスできるか、検証に使えるチャネル、プロトタイプが作れるのか、それともインタビューだけなのか、などです。こうした情報は「least work」セクションの内容を実質的に変え、結果を行動可能なものに保ちます。

lean-ux-canvas skill の FAQ

lean-ux-canvas はワークショップ専用ですか？

いいえ。lean-ux-canvas skill は、個人のプロダクト思考、ステークホルダー向けの事前整理、AI 支援の企画作業にも使えます。ただし、複数人が見て、突っ込み、磨ける共有フレームが必要な場面で最も力を発揮します。

普通のプロンプトと何が違いますか？

普通のプロンプトでもアイデアは出せますが、lean-ux-canvas は、課題、ユーザー、成果、仮説、実験を構造化するよう設計されています。発想不足よりも、前提の曖昧さが本当のリスクになっているときに役立ちます。すでに解決策の道筋が見えているなら、もっとシンプルなプロンプトで十分な場合もあります。

初心者でも使えますか？

はい、状況をはっきり説明できるなら使えます。初心者に必要なのは、canvas の形式よりも具体性です。この skill は、実際のプロダクト文脈が入力に含まれているときに最もよく機能します。抽象的なプロンプトからは、抽象的な仮説しか出てきません。

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

実行計画、仕様書、ロードマップが必要なときは、lean-ux-canvas を使わないでください。洗練された marketing copy や、最終版の UI 文言にも向きません。使うべきなのは、その課題を解く価値があるか、そして何から試すべきかを学びたいときです。

lean-ux-canvas skill を改善する方法

問題の根拠をもっと鋭くする

lean-ux-canvas の出力を最短で良くする方法は、測定可能な根拠を与えることです。コンバージョンの低下、サポート件数、解約の兆候、利用ギャップ、顧客の引用などを入れてください。「ユーザーが混乱している」ではなく、「trial ユーザーの 42% が初回でカレンダー接続に失敗する」のように置き換えます。根拠が具体的になるほど、問題のフレーミングも仮説も良くなります。

ユーザーと成果を具体化する

この skill は、ユーザーセグメントが狭く、成果の記述が観測可能なときに最も強くなります。「SMB アカウントの admin は 5 分以内にセットアップを終える必要がある」は、「ユーザーはもっと簡単な onboarding を望んでいる」より良い表現です。具体化することで、lean-ux-canvas skill がユーザー価値とビジネス成果を混同せずに分けて扱いやすくなります。

最もリスクの高い前提に集中する

lean-ux-canvas の精度を上げたいなら、仮に間違っていたらアイデアが終わる前提は何か、をモデルに名指しさせてください。すると、チームが信じているのが信頼性なのか、理解のしやすさなのか、価値の実感なのか、技術的実現性なのかが見えやすくなります。ここが明確になると、最小工数の実験も選びやすくなります。

canvas からテストへつなげて反復する

最初の出力の後は、次の意思決定に影響する部分だけを見直します。具体的には、問題、成果、ユーザー、そして最もリスクの高い前提です。そのうえで、1つの実験と1つの成功指標を依頼します。こうすると、lean-ux-canvas のワークフローが長い推測文書にならず、きちんと lean なまま進められます。