# TaskFlow PRD（プロダクト戦略ドラフト）

**プロダクト名**: 社内タスク管理SaaS「TaskFlow」
**作成目的**: 3ヶ月以内・開発3名という制約下で、MRR前年比150%成長に寄与するMVPの意思決定を固定するための戦略PRD

---

## 0. 前提整理（事実 / 推測 / 不足情報）

まず、入力情報を「事実」「推測（PMとして置いた仮の前提）」「不足情報」に分けて明示する。この区分を無視して先に進めると、誤った土台の上に計画を積み上げることになるため、最初に固定する。

**事実（入力で確定している情報）**
- 対象市場: 20〜100名規模のスタートアップ
- 事業目標: MRR前年比150%成長
- 競合・代替手段: Asana、Notion、Trello
- 制約条件: 開発チーム3名、3ヶ月以内にリリース

**推測（★ 入力に明示がないため、本PRDで置いた前提。妥当性は要検証）**
- ★1 TaskFlowは完全新規ローンチではなく、既にβ版または少数の初期顧客を持つ既存プロダクトであり、3ヶ月以内のリリースは「主要機能を揃えた正式版リリース」を指す、と解釈する（「前年比」成長という表現は比較対象となる過去実績の存在を前提とするため）。
- ★2 開発3名という体制から、この期間中に専任セールス・CS組織を新設する余地はなく、成長はPLG（プロダクト主導型・セルフサーブ）を主軸にせざるを得ない、と仮定する。
- ★3 20〜100名という対象は「Trelloでは物足りなくなり、Asanaは高機能すぎ／高額、Notionは自由度が高すぎて崩壊し始める」規模帯として扱う（後述の戦略仮説の根拠）。

**不足情報（本PRDでは埋められず、後段「不足情報」「確認事項」に回すもの）**
- 現在のMRR実績・顧客基盤の有無、開発チームの職能内訳、営業/CS体制の有無、想定単価・課金モデル、コンプライアンス要件（SOC2等）の有無

以降のセクションは、上記の事実と★の前提を土台に組み立てる。★の前提が崩れた場合、選択肢比較・判断基準の結論も再検証が必要になる。

---

## 1. 戦略仮説

### 中心仮説
**「20〜100名規模のスタートアップは、Trello（軽すぎる）とAsana（重すぎる／高い）とNotion（自由すぎて崩壊する）の間に落ちる“隙間”にいる。TaskFlowは、その隙間を『部門を横断したタスクの詰まりを自動で見える化する』という単一の強みで埋める、乗り換えコストの低い専用ツールとして勝つ」**

### 判断理由と前提
- **なぜこの規模帯か**: 20名未満は1つのボード（Trello的な運用）で十分回る。100名を超えると情シス・購買プロセスが発生しAsana/Notion Enterpriseの導入コストが正当化されやすくなる。20〜100名は、部署が分化し始め（営業/開発/CS等）タスクが部門をまたぐようになる一方、専任の業務改善担当や情シスがまだいないため、ツールの複雑さそのものが導入障壁になる、最も「隙間」が大きい帯だと考える（★推測。裏付けとなる定量データは未取得）。
- **なぜ全方位機能競争をしないか**: 開発3名・3ヶ月という制約で、Asana/Notionと機能網羅性で戦うのは物理的に不可能。分散した工数は「どれも中途半端」に終わり、差別化を失う。したがって「1つの強い理由で乗り換えてもらう」ワンポイント突破戦略を取る。
- **なぜPLG前提か**: セールス組織がない前提（★2）では、大企業向けの高単価・長期商談型ビジネスは成立しない。無料トライアル→セルフサーブ課金→バイラル（招待経由の拡大）という成長ループを組まない限り、150%成長は再現性を持たない。

### 検証すべき前提（未検証のまま進めると失敗する可能性が高いもの）
1. 「部門横断のタスクの詰まりが見えない」ことが、20〜100名の実際の顧客にとって**購買意思決定を動かすほどの痛み**であるか（「あったら便利」レベルに留まる可能性がある）。
2. Trello/Asana/Notionからの**乗り換えコスト**（データ移行、チームの学習コスト）を、ワンクリックインポート程度で本当に下げきれるか。
3. PLGループ（招待によるチーム内拡散）が、タスク管理という「チーム全員が使わないと機能しない」プロダクト特性上、自然発生するか（単独ユーザーでは価値を感じにくいプロダクトのため、初期の巻き込みが難しい可能性がある）。

---

## 2. 選択肢比較

3ヶ月・3名という制約の中で、MVPのスコープをどう定義するかについて、3つの選択肢を比較する。

| 選択肢 | 内容 | 3ヶ月/3名での実現可能性 | 差別化の強さ | MRR成長への寄与 | 主なリスク |
|---|---|---|---|---|---|
| **A. 単一機能特化型** | タスク管理の基本機能（一覧/カンバン/期限）＋「依存タスクの遅延自動検知＋Slack通知」1機能に全工数を投下 | 高（スコープが小さく3ヶ月で品質を詰められる） | 高（明確に語れる1つの理由がある） | 中〜高（PLGで語りやすいが、単体では大企業の意思決定を動かしにくい） | 機能が刺さらなかった場合の代替案がない |
| **B. 汎用オールインワン型** | Asana/Notionに近い汎用機能（カスタムフィールド、ドキュメント、ガントチャート等）を薄く広く実装 | 低（3ヶ月/3名では主要機能すべてが中途半端になる可能性が高い） | 低（「劣化Asana」にしかならない） | 低（差別化がなければ既存ツールからの乗り換え理由が価格以外になくなり、価格競争に陥る） | スコープ肥大化による遅延、品質低下 |
| **C. 特化機能＋移行支援ハイブリッド（推奨）** | Aの単一機能（詰まり検知）に加え、Trello/Asana/Notionからの**ワンクリックインポート**を組み合わせ、「強み」と「乗り換えの摩擦解消」の両方を用意 | 中〜高（インポート機能は各社エクスポート形式への対応が必要で、Aより工数増だが3ヶ月内に収まる規模） | 高（強みだけでなく乗り換え障壁も下げるため、実際の切り替え行動に繋がりやすい） | 高（「機能が刺さる」ことと「実際に移行する」ことの両方を満たす） | インポート精度が低いと初回体験を損なう |

### 捨てる選択肢
- **選択肢B（汎用オールインワン型）は明確に捨てる。** 理由: 3名・3ヶ月という制約下での汎用機能競争は、Asana/Notionという資金力・開発リソースで劣る相手との消耗戦になり、差別化ゼロで価格競争に巻き込まれる。これは事業目標（150%成長）に対して最も再現性の低い選択肢である。
- SSO/SCIM、監査ログ等のエンタープライズ機能は、100名規模の一部で需要はあるが、MVPスコープからは意図的に外す。理由: 20〜100名の主要な意思決定者にとって必須要件ではなく、実装工数（3名体制の相当割合）に対してMVP段階でのMRR寄与が低い。
- ネイティブモバイルアプリはMVPから外す。理由: PC/Web中心のタスク管理という利用実態に対し、3ヶ月での実装優先度が低い。

---

## 3. 判断基準

選択肢Cを選ぶにあたり、以下の基準で評価した。今後スコープを見直す際も、この基準に立ち返ることを推奨する。

1. **実現可能性フィルタ（必須／Go-No-Go）**: 3ヶ月・3名で「品質を落とさず」完成できるか。これを満たさない選択肢は他の評価軸に関わらず却下する。
2. **差別化の言語化可能性**: 営業トーク・LPのファーストビューで「なぜTrello/Asana/Notionではなくこれなのか」を1文で説明できるか。
3. **乗り換えコストの低減度**: 既存ツールからの移行障壁（データ、学習コスト）をどれだけ下げられるか。差別化機能があっても移行障壁が高ければ導入は進まない。
4. **PLG適合性**: セールス組織を持たない前提（★2）で、セルフサーブでの契約・拡大が成立する設計か。
5. **継続利用・NRR（ネットレベニューリテンション）への接続**: 単発導入で終わらず、チーム拡大に伴ってシート数・利用範囲が広がる構造になっているか（150%成長は新規獲得だけでは達成が難しく、既存顧客の拡大が必要という前提に立つ）。

この基準に照らすと、選択肢Aは基準2・4は満たすが基準3（乗り換えコスト低減）が弱く、選択肢Cが基準1〜5をバランス良く満たす。

---

## 4. リスク

| リスク | 可能性 | 影響度 | 内容 | 対策 |
|---|---|---|---|---|
| **スコープ肥大化による遅延** | 高 | 高 | 「詰まり検知」だけでは寂しく感じ、開発中に機能を足したくなる誘惑が働きやすい | 本PRDのMVPスコープ（2章の選択肢C）をリリース基準として固定し、追加要望はすべて「次バージョン行き」のバックログに退避する。機能凍結日を残り3週間の時点で設定する |
| **差別化機能が刺さらない** | 中 | 高 | 「タスクの詰まり検知」が“あったら便利”レベルに留まり、購買の決め手にならない可能性 | 実装着手前にターゲット顧客5〜10社への価値検証（プロトタイプ／Fake door test）を実施し、Go/No-Goを判定する（5章参照） |
| **競合の後追い機能追加** | 中 | 中 | Asana・Notionが同種の依存関係アラート機能を追加する可能性 | 機能単体ではなく「乗り換えの手軽さ（インポート）＋ニッチな業務理解」の組み合わせで防御する。大手は汎用性維持のため深いニッチ機能への投資優先度が相対的に低いと想定 |
| **PLGループが機能しない** | 高 | 高 | タスク管理は「チーム全員が使って初めて価値が出る」ため、単独ユーザーの初期体験だけでは招待が起きにくい | オンボーディングで「最初のタスクに同僚を招待する」導線をコアフローに組み込み、招待完了率を最重要初期指標としてトラッキングする |
| **インポート機能の精度不足** | 中 | 中 | Trello/Asana/Notionのデータ構造差により、移行後にタスクの階層・担当者が欠落し、初回体験を損なう | インポート対象をβ版では1〜2サービスに絞り（5章の意思決定事項）、精度を優先する。全対応は後続フェーズに回す |
| **3名体制のバス係数リスク** | 低〜中 | 高 | 3名という小人数体制で、離脱・体調不良等が発生すると3ヶ月納期に直接影響する | ドキュメント化・コードレビューの徹底、単一障害点（特定人物しか触れない領域）を作らない体制を初期から意識する |

---

## 5. 次の意思決定

以下は、このPRDを土台に**人間（プロダクトオーナー／経営）が今後3〜12週間で下すべき意思決定**を時系列で並べたものである。抽象論で終わらせず、いつまでに・何のデータを見て決めるかを明示する。

| タイミング | 意思決定事項 | 判断に必要な材料 |
|---|---|---|
| Week 1 | 20〜100名という対象の中で、狙う業種・職能をさらに1つに絞るか（例: 受託開発会社の複数クライアント管理／SaaS自社開発チーム等） | 既存の問い合わせ・商談履歴の業種内訳（不足情報。存在すれば分析、なければヒアリングで代替） |
| Week 1〜2 | 「詰まり検知」機能の価値検証（Go/No-Go） | ターゲット顧客5〜10社へのプロトタイプヒアリングまたはFake door testの結果 |
| Week 2 | 課金モデルの確定（シート課金／フラット料金／年間契約の有無） | PLG前提でのセルフサーブ課金実装（Stripe等）が3ヶ月スコープに収まるかの技術見積もり |
| Week 3 | インポート機能の初期対応先を1サービスに絞る（Trello優先／Asana優先／Notion優先） | 各社のエクスポートAPI・データ形式の技術調査結果 |
| リリース直後（Week 12） | オンボーディング内の「招待導線」のコンバージョン目標値の設定 | 類似PLG SaaSのベンチマーク（社内に実績がなければ業界公開値を参照） |
| リリース後 Week 12〜16 | 150%成長の内訳を「新規獲得」「既存アップセル」「解約率改善」のどの比率で狙うか再設計 | リリース後4週間分の実績データ（新規契約数・既存拡大・チャーン） |

---

## 重要な前提・不足情報・確認事項

- **重要な前提**:
  - ★1 TaskFlowは既存プロダクト（β版または少数の初期顧客あり）の正式リリースであり、完全新規ローンチではないと仮定した。
  - ★2 開発3名体制のため、専任セールス・CS組織は存在せず、成長戦略はPLG（セルフサーブ）を主軸にすると仮定した。
  - ★3 20〜100名という対象規模帯を「Trelloでは物足りず、Asana/Notionでは重すぎる／崩壊しやすい隙間」として戦略仮説の中心に据えた。
  - MVPスコープは「単一の差別化機能（詰まり検知）＋移行支援（インポート）」に意図的に絞り、汎用機能競争（選択肢B）は明確に捨てた。

- **不足情報**:
  - 現在のMRR実績値・既存顧客数・顧客属性（新規ローンチか否かの判断材料）
  - 開発チーム3名の職能内訳（フロントエンド／バックエンド／デザイナー／QAの有無）
  - 営業・カスタマーサクセス体制の有無（PLG前提が妥当かどうかの判断材料）
  - 想定単価・課金モデルについての社内合意状況
  - セキュリティ・コンプライアンス要件（SOC2、SSO必須の商談があるか等）の有無
  - 技術スタックの制約（既存システムとの互換性要件）

- **次に人間が確認すべきこと**:
  1. 現在のMRR実績とその内訳（新規顧客／既存アップセル）はどうなっているか。150%成長は新規獲得と既存拡大のどちらを主軸にする想定か。
  2. 開発チーム3名の職能構成（フロントエンド／バックエンド／デザイナー）はどうなっているか。デザイン・QAリソースは別途確保されているか。
  3. セールス・カスタマーサクセス体制は存在するか、それとも完全PLG（セルフサーブ）前提で進めるべきか。
  4. 20〜100名スタートアップの中で、特に狙いたい業種・職能（受託開発／SaaS自社開発／エージェンシー等）はすでに決まっているか。
  5. 価格帯・課金モデル（シート課金／フラット料金／年間契約）について、社内で既に方向性の合意はあるか。