「これは本当に解くべき問題なのか」から「どう納得してもらうか」まで
実際に使っている8つのAI skill

少し前まで、AIは発想出し、既存知識に基づく回答、問題の構造化といった作業を手伝ってくれる存在でしたが、その回答の背後にどんな思考モデルがあるのかは私たちにはわかりませんでした。その思考の筋道や理論に、私たち自身が納得できているのかどうかも。

私たちが「適切だ」と考える理論、プロセス、思考の進め方でAIに問題を扱わせ、その思考プロセスを何度も再現できるようにする——それが私の考えるSkillです。

とはいえ、概念を理解しただけでは私にとってはまだ曖昧なままだったので、実際のプロダクト案件を通じて、Skillが自分たちに何をもたらしてくれるのか、今後どんな場面でクライアントのために活用できるのかを体験してみることにしました。ここでは、どの段階でどのskillを使い、それによってどんな誤った方向を回避できたか、そしてどんな具体的なアウトプットが得られたかを、一つずつ記録していきます。

🧊 第1関門：これは本当に解くべき問題なのか？

クライアントが最初に提示していたプロダクトで解決すべき課題を、sharp-problem-testというskillに投げて検証したところ、判定結果は「NEEDS MORE EVIDENCE（根拠がまだ不十分）」となり、さらに検証すべき方向性が提示されました。

このプロセスがなければ、自分の判断や調査だけでは、AIほど網羅的かつ広い視野で見られていなかったはずです。というのも、自分自身では気づいていなかった点を指摘してくれたからです。私の頭の中ではAsana、Trello、Notionといった汎用ツールを比較対象にしていましたが、このアイデアが実際に向き合うべき競合は、HoneyBookやDubsadoのような、よりワーカー向けの垂直特化型ツールだったのです。競合の見立てを誤れば、その後のポジショニングやデザインもすべてズレていってしまいます。

🔎 第2関門：すでに誰かが解決していないか？

問題の方向性を確認した後の次のステップは、市場ですでに同じことをしている人がいないかを見ることです。この段階ではyushi-competitive-analysisを使い、競合のユーザー数、機能面の切り口、マーケティングの打ち出し方を詳しく分析し、総合的にまとめました。

このレポートが防いでくれたのは、「市場には何もなさそうだ」という思い込みです。レポートには、ある競合がすでに12万人の有料ユーザーを抱えているというデータが示されていました。この数字は同時に2つのことを物語っています。1つは、この顧客層は実際にお金を払う意思があり、問題自体が成立しているということ。もう1つは、これだけのユーザーが存在するにもかかわらず、私たちが重視しているポイントを本当の意味で解決している人がいないということで、むしろ切り口にまだ余地があることが確認できました。

🎯 第3関門：自分の切り口はどこにあるのか？

競合データを踏まえ、切り口を改めてsharp-problem-testに投げてもう一度テストしたところ、今回の判定は SHARP となり、「ワーカー側」という角度に着地しました。

このラウンドで防いでくれたことも非常に具体的でした。当初は「見積書エディター」をこの案件の中核的なセールスポイントにしようと考えていましたが、テスト結果によると、それがもたらす効果はせいぜい1.5〜2倍程度で、差が十分明確とは言えず、他社の既存機能を少し改良した程度にすぎず、目玉となるセールスポイントを支えるには力不足でした。この気づきのおかげで、デザインに着手する前に力の入れどころを変えることができました。

🧭 第4関門：どう検証するか？

切り口が固まった後は、ターゲットユーザーの実際の働き方に関するデータをさらに集め、この仮説を検証する必要があります。この段階ではcustomer-discovery-weekを使い、インタビューガイドの雛形、アンケート、そして実行計画を一度に作成しました。

👥 第5関門：誰に聞くか？

インタビューを行うことが決まった後、最初に具体的に検討すべきは「誰に聞くか」でした。この段階ではclaude-personaを使い、広がりが必要だと判断した軸に沿って、10組のペルソナを作成しました。

例えばこのプロジェクトでは、ターゲットの規模は最初から1〜2人規模の個人事業主・小規模スタジオに絞られており、これは変わりません。一方で業種については幅を広げたかったため、その条件をskillに定義して渡すことで、与えた制約の範囲内でタスクを完成させてもらうことができます。

このステップが防いでくれたのは、最も陥りやすい失敗——自分と似ていて、普段からよく話している同業者ばかりにインタビューしてしまうことです。そうして得られる回答は、往々にして自分の考えのこだまにすぎず、共感しているように聞こえても、実は本当に新しい情報が含まれていません。

📝 第6関門：何を聞くか？

インタビュー対象者が決まったら、次は何を聞くかを決める段階です。この段階ではinterview-guide-builderを使い、7つのリサーチクエスチョン（RQ）と35問のインタビューガイドを作成しました。

インタビューガイドの設計で徹底しているのは、直近の経験から過去の経験へ、具体的な行動から価値観寄りの質問へと進んでいく、いわゆる漏斗（ファネル）型の聞き方で、これはskillを設計する段階ですでに組み込まれているため、そのつど改めて指示し直す必要はありません。

🕳 第7関門：インタビューガイドに抜け漏れはないか？

インタビューガイドが完成したら、まずinterview-simulatorで一度シミュレーションを回し、約350件のやり取りを生成しました。

実際のインタビューでは、生身の人の時間がこのプロセス全体の中で最も貴重なリソースです。もしガイド自体に抜け漏れがあり、実際に着席してインタビューを始めてから質問が的を射ていないことに気づいたとしたら、その時間はそのまま無駄になってしまいます。

✂️ 第8関門：最初のバージョンはどの規模で作るか？

検証がほぼ完了した段階で、いよいよ最初のバージョンの規模を決めるときです。この段階ではslc-or-mvpを使い、MVPか、SLCか、このプロダクトをMVP（学びのために作る実験であり、作り終えたら捨てても誰も惜しまないもの）から始めるべきか、それともSLC（Simple＝シンプル、Lovable＝好きになってもらえるほど使いやすい、Complete＝完結している——本当に使われることを前提に作る、ただし範囲は非常に小さいプロダクト）から始めるべきかを判断しました。

この考え方によって、これまでの議論で出てきた機能をすべて最初のバージョンに詰め込んでしまうことを防げます。感覚に頼るのではなく、より効果的な方法で、どの機能を最初のバージョンに入れるべきかを見極めるのです。

この8つの関門を振り返ると、ここでAI skillが果たしている役割は、「本当に大丈夫か、根拠は十分か」ともう一押し問い直し、絶えずデータを探し、思考を重ね、異なる角度から切り込んでくれることにあります。その判定を本当に受け入れるかどうか、その先へ進むかどうかは、最終的には人間の経験による判断に委ねられています。

今、それぞれの工程は、私たちが得たデータをどう判断すべきかについて、さらに深く掘り下げて考えることができる余地があります。今後も引き続き共有していきます！