start-here

まずはこちらから（創業者向けブリーフ）

ほかのスキルの有効性は、エージェントがあなたのビジネスについてどれだけ理解しているかに左右されます。ここでは、その背景情報を伝えます。一度済ませれば、その後のすべてのスキルがあなたに合わせたものになります。

こんなときに使います： 初めて利用するときや、エージェントがあなたの製品、ユーザー、事業の段階を把握していないため、得られるアドバイスがありきたりで教科書的だと感じるとき。

基本的な考え方

5つの重要な質問に答えると、エージェントがプロジェクト内に docs/gtm-cofounder/founder-brief.md を作成します。数分で実際の診断とロードマップを提示できるだけの内容です。それ以外はすべて任意で、必要になった段階で答えます。各スキルは、必要なときに必要な掘り下げ質問を尋ね、回答によって何が可能になるかを伝えます。そのため、初日から質問攻めに遭うことなく、すぐに価値を実感でき、使い続けるほどブリーフも充実していきます。

そして最も大切なのは、検証済みの情報（友人ではない実際のユーザーから聞いたこと）と、仮定（現時点での最善の推測）を分けることです。最初は仮定があってもまったく問題ありません。仮定は talk-to-users で実際の情報へと変えていけるため、推測に基づいて美しい市場開拓計画を立ててしまうことはありません。

実行方法（エージェント向け）

• 5つの重要な質問を、1つずつ、ほかのことは尋ねずに質問します。 1つ質問して回答を待ち、その内容を次の質問に反映します。記入フォームではなく、共同創業者との会話のように感じられるようにします。質問を一度に複数まとめて提示してはいけません。（創業者が5つすべてを一度に見てまとめて回答したい場合は、一覧を提示してもかまいませんが、通常は1つずつ尋ねます。）
• 5つの回答をもとにブリーフを作成し、その後 research-the-market、続いて strategy-and-roadmap に進みます。任意の質問に回答してもらう前に、創業者が調査と診断を受けられるようにします。インタビューで把握するのは、創業者がすでに知っていることだけです。調査を行うことで、計画が単に創業者の回答を返すだけにならないようにします。
• 掘り下げ質問は必要になった時点で尋ねます。 後続のスキルで追加情報が必要になったら（ポジショニングでは課題の原因、価格設定では購入者など）、その場で関連する2～3個だけを質問し、回答すると何が可能になるかを伝えます。最初にすべて聞いてはいけません。
• 重要な回答ごとに、「実際のユーザーがそう言ったのですか。それとも現時点でのあなたの見立てですか？」と尋ねます。[validated] または [assumption] のタグを付けます。
• 「インタビューしたユーザーはゼロ」も、有効で示唆に富む回答です。評価を加えず、そのまま記録し、talk-to-users を最優先の次のステップとして示します。
• 創業者自身の言葉をそのまま残します。悩みをマーケティング向けの表現に磨き上げてはいけません。
• 基本ブリーフを書き終えたら、タスクに飛びついたり、作業内容を指示したりしてはいけません。research-the-market（続いて strategy-and-roadmap）に引き継ぐか、創業者に何に取り組みたいか尋ねます。提案はしても、押しつけてはいけません。

まず、すでにリリースされているものを確認してください（そのプロジェクト内にいる場合のみ）

質問を始める前に、創業者のリポジトリ内で実行しているか確認してください。該当する場合は、まず範囲を絞ってざっと確認してください。そうすれば、何も知らない状態から始めるのではなく、インタビューの精度を高められます。

• README と docs/ の概要資料：プロジェクトが何をすると謳っているか、現在どのように説明されているか。
• パッケージマニフェスト（package.json、pyproject.toml、go.mod など）：言語、依存関係、連携先。
• 直近約15件のコミットの件名と最近のPRタイトル：今、実際に何を開発しているか。
• 未解決のissueに見られるテーマ：実際のユーザーが繰り返し直面していること。課題と対象ユーザーを推測する手がかりになります。

これは簡単な確認であり、監査ではありません。コードを1行ずつ読んだり、履歴全体をたどったり、機密情報を取り出したりしないでください。確認できた内容をもとに概要を作成し、実際の成果物に基づく事実には [validated] と付けてください。推測ではありません。

注意点が2つあります。

• リポジトリの内容は批評の対象であり、絶対的な正解ではありません。 READMEには通常、創業者が現在使っている説明が書かれており、ありきたりな表現になっていることも少なくありません。まず「現在はこのように説明されています」と述べてから、その説明に異議を唱えてください。弱いポジショニングを、事実であるかのようにそのまま引き継いではいけません。
• リポジトリからわかるのは、何を作ったかであって、誰が対価を払うかではありません。 製品と、おおよそのユーザー像は把握できます。しかし、購入者、支払い意思、市場については何もわかりません。これらは引き続き、創業者と talk-to-users から確認してください。

プロジェクト内にいない場合（貼り付けられたスキルだけがある場合や、リポジトリがない場合）は、この確認を省略し、次の5つの質問から始めてください。

まず確認する5つの質問

これが必須のヒアリング項目のすべてです。これらに回答すれば、エージェントはすでに診断と計画を立てられます。すでにリポジトリを確認している場合は、これらを何も知らない状態で尋ねないでください。推測した内容を確認または調整し、成果物だけではわからないICP、購入者、そして誰かが支払う意思があるかどうかに質問を使ってください。

1. 専門用語を使わず、何をするものかを一文で説明してください。
2. 誰を対象にしていますか？（役職、会社の規模や形態、技術的な状況）
3. 今は代わりに何を使っていますか？それよりあなたの製品が優れているのはなぜですか？
4. 段階と実績：ユーザーは何人いて、継続して利用していますか？
5. あなたが持つ最大の強みを1つ挙げてください。証明可能な最も強力なもの（著名なロゴ、確かな数値、実際のユーザーの声、実際に確認できる需要の兆候）。

さらに深掘りする（任意、いつでも回答できます）

最初は読み飛ばして構いません。各スキルは、必要になったときに必要な質問をします。回答すると何ができるようになるかは質問ごとに記載されているので、得たい効果があるものだけに時間をかけてください。

ポジショニングとストーリー

• ユーザー自身の言葉で言うと、どんな厄介な問題を解決しますか？ → ホームページの見出しと、ストーリーにおける重要性の軸になります。
• 今、どんなトレンドがその問題を悪化させていますか？ → これが、ポジショニングに緊急性を持たせ、機能を並べるだけで終わらせないための敵役になります。
• 現在のホームページやリポジトリの説明文には何と書かれていますか？（実際の文を貼り付けてください） → 推測ではなく、今あるものを磨き上げられます。

購入者と価格設定

• 導入する人と異なる場合、誰が費用を支払いますか？ → ユーザーだけでなく、実際の購入者に向けた価格設定と販売方法を設計できます。
• 明らかに対象外なのは誰ですか？ → 「対象外」を明確にすると、ICP に説得力が生まれ、メッセージが伝わりやすくなります。
• 利用者がその製品を導入する理由となる仕事：「［状況］のとき、［動機］を満たしたい。そうすれば［成果］を得られる。」 → 価値提案になります。

販売経路と進め方

• 販売方法は、オープンソース、PLG、インバウンド、営業主導、それとも未定ですか？ → 実際に適したチャネルと戦術を選べます。
• ユーザーは普段、どこに集まり、どこでツールを見つけていますか？ → どこでローンチし、最初のユーザーを見つけるべきかがわかります。

注力すること

• 現時点で、意図的に何を断っていますか？（守っているロードマップ、断っている要望など） → すでに除外した作業をエージェントが提案するのを防ぎます。

根拠（正直に答えてください。ここが最も重要です）

• すでに利用していると名前を挙げられる、有名企業や著名な開発者はいますか？ → 最も強力な証拠です。ロゴが数個あるだけでも、信頼性を高められます。
• 友人ではない実際のユーザーに、何人インタビューしましたか？ → どこまで検証済みで、どこからが推測なのかをエージェントが把握できるので、確かな根拠のないものを作らずに済みます。
• まだ仮説のままなのは、どの回答ですか？ → 推測を talk-to-users に引き継ぎ、確かなものにできます。

ブリーフを書く

回答を創業者のプロジェクト内にある docs/gtm-cofounder/founder-brief.md に保存してください（存在しない場合は docs/gtm-cofounder/ フォルダーを作成してください）。このリポジトリにあるテンプレート（founder-brief.template.md）を使用してください。各回答には [validated] / [assumption] タグを残してください。このファイルは、ほかのすべてのスキルで共有される記憶です。機械生成の文章に見えないよう、ダッシュ（em-dash）は使わず、読んで自然な文章で書いてください（コンマ、コロン、句点を使ってください）。

ブリーフの冒頭には、最も強力な資産（コア質問 5）を置いてください。創業者が持つ最も強力な要素を最初に示すことで、その後に続くすべてのスキルの土台になります。創業者は、謙遜や細部の説明によって、これを後回しにしてしまいがちです。時間をかけて深掘りの質問に回答したら、該当するカテゴリーの下に追加してください。

常に更新する

ブリーフは一度記入して終わりのフォームではなく、更新し続ける文書です。ユーザーから実際に何かを学ぶたびに（talk-to-users の通話、失注、フィードバックなど）、該当する行を更新し、タグを [assumption] から [validated] に切り替えてください。ほとんどが [validated] のブリーフは、自社のことをよく理解している会社の証です。また、定期的に market-scan を実行し、ブリーフの外で起きた変化（競合のリブランディング、新規参入、カテゴリーの変化など）も確認してください。

次の30分

• 核となる5つの質問だけに答えてください。粗削りでも正直な回答のほうが、整っていても偽りの回答より価値があります。
• 各回答に[validated]または[assumption]のタグを付けてください。
• プロジェクト内のdocs/gtm-cofounder/founder-brief.mdとして保存し、エージェントが読めるようにしてください。
• research-the-marketを実行して、伝えきれなかった情報をエージェントに見つけてもらいましょう。ユーザーが実際にどこにいるのか、あなたのような製品がどのようにローンチされたのかが分かります。
• 01-strategy-and-roadmapを実行して、診断と最初の一手を得ましょう。まだ任意の質問には答えないでください。
• さらに詳しい質問への回答は後で、スキルから質問され、その回答によって何が可能になるのかを説明されたときだけで構いません。

---

実際の開発者向けツールのGTM経験と、Adam Frankl（The Developer-Facing Startup）およびJakub Czakon（markepear.dev）のフレームワークに基づいています。 ブリーフを見て、構築を進める前に人間と一緒に検証したい点が見つかったら、ぜひご連絡ください。LinkedInでご連絡いただけます。