cs-marketing-research

CodeSpring のアイデアに関する市場調査

概要

漠然とした製品アイデアを、構築しない、既存のソリューションを利用または統合する、あるいは焦点を絞った切り口を追求する、という判断につなげます。調査は計画上の関門として扱い、重複するものを構築する正当化には使いません。

1. 実現すべき仕事を定義する

• 望ましい成果、対象ユーザー、プラットフォーム、制約を言い換えて明確にします。
• ユーザーが価値を得る瞬間を含め、必要最小限の完全なワークフローを特定します。そのワークフローを特定する前に、機能一覧を調査しないでください。
• API が存在するか、既存のツールでワークフローを自動化できるか、指定されたプラットフォームが重要かなど、判断を左右する未検証の前提を挙げます。

2. 市場と技術の実態を調査する

• 直接的な製品、オープンソースのリポジトリ、プラットフォーム標準の機能、隣接する代替手段を検索します。製品ドキュメント、ソースリポジトリ、リリースノート、ソースコードなどの一次情報を優先します。
• 有力な代替手段ごとに、想定ユーザー、重複する具体的なワークフロー、インタラクションモデル、成熟度を示す情報、ライセンスまたは価格、重要な不足点を記録します。主張されている機能は情報源で確認し、検索結果のスニペットだけに頼らないでください。
• 自動化を提案する前に、関連するプラットフォームや API のドキュメントを確認します。サポートされていない方法、不安定な方法、認証情報をスクレイピングする方法、GUI に注入する方法には注意を促します。
• UI、プログラミング言語、名前が異なるだけで、アイデアを独自のものと呼ばないでください。成果、対象ユーザー、提供経路、統合対象のいずれかを変える場合にのみ、独自の切り口となります。

3. 推奨事項を決める

次のいずれかを選び、明確に示します。

• 構築しない： 既存のソリューションが実現すべき仕事を直接満たします。
• 採用または統合する： 既存のツールを利用し、不足している統合部分またはワークフロー層だけを構築します。
• 独自の切り口を構築する： 代替手段にはない、対象ユーザー、成果、機能を1つずつ絞って定義します。

構築を推奨する場合は、1文でのポジショニング、MVP の範囲、対象外、リスク、判断の根拠となる証拠を示します。一般的な機能比較を羅列するのは避けてください。

4. 判断を CodeSpring に反映する

• CodeSpring を変更する前に、プロジェクトのコンテキスト、関連機能、マインドマップ、PRD、既存のタスクを確認します。可能であれば、適切な既存機能を再利用します。
• 調査日、情報源、判断、検討した代替手段、明示的に除外した範囲を含む、証拠に基づいたマインドマップの注記を追加します。
• 推奨事項が独自の切り口または統合の構築である場合に限り、機能を作成または更新します。ありふれたクローンの機能は作成しないでください。
• MVP の範囲が明確になってから、依存関係を関連付けた小規模なタスクリストを作成します。各タスクには、変更してよい対象、変更してはいけない対象、検証方法を明記します。既存の CodeSpring のタスク規約に従ってください。
• 採用を推奨する場合は、新しいアプリケーションを構築するかのように扱わず、評価または統合のタスクを1件だけ作成します。

出力

次の内容を含む、短い調査メモを返します。

• 判断と確信度。
• 直接的な代替手段と、具体的に重複する点。
• 提案する独自の切り口、または構築しない理由。
• MVP、対象外、主なリスク。
• タスクの順序を含む、実施した CodeSpring の変更。