RELATE — 要件定義書 兼 Claude Code 実装指示書

版数 1.0（DBレス構成）／ 作成日 2026-08-13 ／ 発行 ソウゾウ合同会社 用途 「爆速アプリ開発」LP 実演デモ ／ 顧客管理システム編

このドキュメントの使い方（Claude Code へ）

これ1枚が、規約・仕様・タスクのすべて。リポジトリ直下に CLAUDE.md として置き、毎回読み込むこと。

• 実装は「11. 実装タスク」の順に進める。フェーズを飛ばさない。
• 各タスクの括弧内は要件ID。着手前に該当章を読むこと。
• 仕様がここに書かれていない場合は、推測で実装せず質問する。
• スコープ外（3章 Won't have）は、思いついても実装しない。
• 「デモだから」を理由に品質を落とす判断はしない。

姉妹プロジェクト HIREBASE との関係 同じ「爆速アプリ開発」LPに並べるデモ。両方を見た人に「同じテンプレで作っている」と思われた時点で失敗。 HIREBASE は求職者に読ませる消費者向けサイト（明朝体・余白・静けさ）。 RELATE は毎日8時間触る業務システム（ゴシック・高密度・キーボード操作）。 8章のデザイン要件は意図的に別方向に振っている。トークンを流用しないこと。

目次

1. プロジェクト概要
2. アーキテクチャ方針 — データベースを持たない
3. スコープ定義
4. ロールとデモ切替
5. 画面一覧とユーザーフロー
6. 機能要件
7. データ設計
8. デザイン要件
9. 技術要件・ディレクトリ構成
10. 非機能要件
11. 実装タスク
12. 受入基準

1. プロジェクト概要

背景と目的

「爆速アプリ開発」LPの見込み客の多くは、Excelとスプレッドシートで顧客・商談を管理している中小企業。SalesforceやHubSpotは高機能すぎて高い、しかしExcelでは限界がある——という層が中心。

この層に対して「あなたの業務に合わせた顧客管理システムを、この価格・この期間で作れます」を示すデモを用意する。求人サイト（HIREBASE）が消費者向けサービスの実装力を示すのに対し、RELATE は業務システムの実装力を示す。

プロダクト定義

プロダクトコンセプト

「入力の手間より、次に何をすべきかを返す。」

多くのCRMは入力項目が多く、現場が入力しなくなって死ぬ。RELATE は入力を最小にし、代わりに「今日やるべきこと」を毎朝返すことを設計の中心に置く。放置されている商談、期限切れのタスク、久しく接触のない顧客を、システム側から提示する。

デモとしての成功条件

1. 触った瞬間に「業務で使えそう」と分かる — 空の画面が1つもなく、リアルな商談データが入っている
2. 速い — 一覧の絞り込み、ステータス変更、活動記録が、待たされずに終わる
3. ロールで見え方が変わる — 営業担当は自分の案件、マネージャーはチーム全体。権限設計ができていることを示す
4. カスタマイズできる — 項目とパイプライン段階を画面上で足せる
5. リセットできる — 誰が触った後でも、初期状態に戻せる

2. アーキテクチャ方針 — データベースを持たない

基本方針

バックエンドとデータベースを持たない。すべてブラウザ内で完結させる。

なぜこの構成にするか

• LPデモとして最適 — 訪問者は登録もログインもせずに、全機能を即座に触れる
• 顧客データを一切預からない — 入力されたデータはブラウザから出ない。デモに自社の顧客リストをCSVで投入して試すこともできる（これは営業上かなり強い）
• 開発速度 — 認証・権限のサーバー実装・マイグレーションが不要になり、UIと操作効率の作り込みに全時間を投下できる
• 運用コストゼロ — Vercel の静的配信のみ

差し替え可能性の担保（重要）

データアクセスは必ず lib/repo/ のリポジトリ層を経由すること。 コンポーネントからストアを直接触らない。

[ コンポーネント ]
        ↓  呼ぶのはこの層だけ
[ lib/repo/*.ts ]   ← 全メソッドを async にしておく
        ↓
[ lib/store/*.ts ]  ← Zustand + persist（localStorage）
        ↓
[ lib/seed/*.ts ]   ← 初期データ

リポジトリの各メソッドは、中身が同期処理でも async で定義し、await で呼ぶ。実案件へ転用する際、リポジトリの実装だけをAPI呼び出しに差し替えれば、UI層は一行も変更せずに済む。

// lib/repo/deals.ts — 中身は同期でも async にする
export async function findDeals(q: DealQuery): Promise<Result<Deal[]>> {
  await delay()
  const deals = useDataStore.getState().deals
  return { ok: true, data: applyScope(filterAndSort(deals, q)) }  // 将来ここがAPI呼び出しになる
}

永続化の範囲

擬似的な非同期を必ず入れること。 リポジトリの各操作に 150〜400ms のディレイを挟み、ローディング状態を実際に見せる。

HIREBASE との差： 業務システムは「速さ」が価値なので、ディレイは HIREBASE（200〜600ms）より短く設定する。一覧の絞り込みなど体感速度が重要な操作は 100ms 以下にする。

3. スコープ定義

顧客・担当者管理

商談（案件）管理

活動・タスク

見積・売上

分析・管理

共通・基盤

対象外（Won't have）

スコープリスク： CRMは「あれもこれも」が最も起きやすい領域。特にワークフロー自動化ビルダーと帳票の自由レイアウト編集は、単体で数週間かかる。要望が出た場合は別フェーズとして見積り、この文書のスコープは変えない。

4. ロールとデモ切替

ロール定義

認証は行わない。ロールはストアの状態として保持し、切替バーから即座に変更できる。

データスコープ（デモの見せ場）

ロールによって同じ画面の表示件数が変わることを、明確に体験させる。

• 営業担当（田中）でパイプラインを開く → 自分の商談 18件
• マネージャーに切替 → 同じ画面がチーム全体の 62件になり、担当者フィルタが出現する
• 管理者に切替 → 全社 140件。設定メニューが出現する

スコープの適用は lib/repo/_scope.ts に集約し、全リポジトリメソッドが必ず通す。コンポーネント側でフィルタしない（実案件でRLSに置き換わる箇所であるため）。

デモ切替バー（F-S01）

画面上部に常時表示する固定バー。

• 現在のロールと担当者名の表示、3ロールの切替
• 営業担当ロール時：3名のメンバーから選択（見え方の違いを体験できる）
• 「デモをリセット」ボタン（確認ダイアログ付き）
• 「これはデモです」の明示

デザイン上の扱い： プロダクト本体のUIとは意図的に別扱い（ダークな帯 + 小さめのタイポ）にし、「アプリの外側にある操作パネル」であることを視覚的に区別する。

ロールを跨ぐ体験（必ず動くようにする）

1. 営業担当で商談を「提案中」→「最終交渉」に移動 → マネージャーに切替 → ダッシュボードの着地見込みが増えている
2. マネージャーが商談の担当者を田中から鈴木に変更 → 田中で見ると一覧から消え、鈴木で見ると現れる
3. 営業担当が活動を記録し「次アクション」を入力 → タスクが自動生成され、今日のタスクに並ぶ
4. 管理者がカスタム項目「導入時期」を追加 → 営業担当の商談詳細に、その項目が出現する

5. 画面一覧とユーザーフロー

全32画面。画面IDはディレクトリ構成と 1:1 で対応させる。

メイン画面

分析画面

設定画面（管理者のみ）

主要フロー

フローA：新規顧客の獲得から受注まで

SC-001 ダッシュボード ── コマンドパレット ⌘K →「顧客を作成」
   ↓
SC-012 顧客の新規作成 ── 会社名入力中に重複候補を検出して警告
   ↓
顧客登録 → SC-011 顧客詳細
   ↓
「商談を作成」→ SC-033（顧客は自動セット済み）
   商談名／金額／確度／予定クローズ日／段階「初回接触」
   ↓
SC-041 活動記録（クイック入力）
   種別「訪問」／内容／次アクション「見積を送付する（3日後）」
   ↓  ★ 次アクションからタスクが自動生成される
SC-050 タスク一覧に「見積を送付する」が期限付きで並ぶ
   ↓
SC-061 見積作成 ── 商品マスタから明細追加 → 自動計算 → PDFダウンロード
   ↓
SC-030 パイプライン ── カードを「提案中」→「最終交渉」へD&D
   ↓
SC-034 受注登録 ── 受注理由・受注日・最終金額
   ↓
SC-102 予実管理に売上として計上される

フローB：マネージャーの週次パイプラインレビュー

【ロール切替：マネージャー】
SC-001 ダッシュボード ── 「要対応商談 7件」（14日以上動きなし）
   ↓
SC-030 パイプライン ── 停滞商談が視覚的にフラグ表示されている
   ↓
停滞している商談を開く → SC-032 商談詳細
   最終活動日、滞留日数、これまでの経緯を確認
   ↓
担当者にタスクを割り当てる（担当：田中、期限：今週金曜）
   ↓
SC-101 担当者別実績 ── メンバーごとの進捗を確認
   ↓
SC-102 予実管理 ── 今月の着地見込みと目標のギャップを確認
   ↓
【ロール切替：営業担当（田中）】
SC-050 タスク一覧に、マネージャーから割り当てられたタスクが並んでいる

フローC：Excelからの移行（CSVインポート）

SC-010 顧客一覧 ──「インポート」
   ↓
SC-014 Step1 ファイル選択（CSVをドロップ）
   ↓
Step2 列マッピング
   CSVの列 → RELATEの項目 を対応付け。自動推測 + 手動修正
   未対応の列は「取り込まない」または「カスタム項目として追加」
   ↓
Step3 プレビュー
   先頭10行の変換結果を表示
   エラー行（必須項目の欠落・形式不正）を件数と理由付きで表示
   ↓
Step4 取込実行
   「エラー行をスキップして取り込む」／「中止する」を選択
   ↓
結果サマリ：成功 142件 ／ スキップ 8件（理由別内訳）
   ↓
SC-010 顧客一覧に反映。取り込んだレコードに「今回インポート」タグが自動付与される

6. 機能要件

各要件は判定可能な粒度で記述している。テスト項目と 1:1 で対応させる。

6.1 ロール・デモ基盤

6.2 一覧・検索・ビュー（業務システムの中核）

6.3 顧客・担当者管理

6.4 商談・パイプライン

6.5 活動・タスク

6.6 見積・商品

6.7 分析・設定

7. データ設計

型定義（lib/types/）

すべての型を先に定義し、これを唯一の真実とする。

// ---- 組織・ユーザー ----
type User = {
  id: string
  name: string
  nameKana: string
  email: string
  avatarUrl: string
  role: 'sales' | 'manager' | 'admin'
  teamId: string
  monthlyTarget: number          // 月次目標（円）
  isActive: boolean
}
type Team = { id: string; name: string; managerId: string }

// ---- 顧客・担当者 ----
type Account = {
  id: string
  name: string
  nameKana: string
  industryId: string
  employeeCount: number | null
  postalCode: string
  prefCode: string
  address: string
  phone: string
  websiteUrl: string
  ownerId: string                // 担当営業。スコープ判定の起点
  status: 'prospect' | 'active' | 'inactive' | 'lost'   // 見込み / 取引中 / 休眠 / 失注
  source: string                 // 獲得経路
  tagIds: string[]
  note: string
  customFields: Record<string, CustomValue>
  lastActivityAt: string | null  // 活動記録時に自動更新
  createdAt: string
  updatedAt: string
}

type Contact = {
  id: string
  accountId: string
  lastName: string; firstName: string
  lastNameKana: string; firstNameKana: string
  department: string
  title: string                  // 役職
  email: string
  phone: string
  mobile: string
  isDecisionMaker: boolean       // 決裁権の有無
  note: string
  createdAt: string
}

// ---- 商談 ----
type Stage = {
  id: string
  name: string                   // 初回接触 / ヒアリング / 提案中 / 最終交渉 / 受注 / 失注
  sortOrder: number
  defaultProbability: number     // 確度の初期値（%）
  requiredFieldIds: string[]     // この段階へ移動する際に必須となる項目
  type: 'open' | 'won' | 'lost'
}

type Deal = {
  id: string
  name: string
  accountId: string
  contactIds: string[]
  ownerId: string
  amount: number
  probability: number            // 0-100
  stageId: string
  expectedCloseDate: string
  closedAt?: string
  closeReason?: { codes: string[]; note: string }   // 受注理由 / 失注理由
  source: string
  productIds: string[]
  tagIds: string[]
  note: string
  customFields: Record<string, CustomValue>
  lastActivityAt: string | null
  createdAt: string
  updatedAt: string
}

// 派生値。ストアには保存せず、リポジトリで算出する
type DealComputed = Deal & {
  stagnantDays: number           // 最終活動からの経過日数
  isStagnant: boolean            // 既定14日以上（FR-308）
  isOverdue: boolean             // 予定クローズ日超過（FR-309）
  weightedAmount: number         // amount * probability / 100
}

// ---- 活動・タスク ----
type Activity = {
  id: string
  type: 'visit' | 'call' | 'email' | 'meeting' | 'other'
  accountId: string
  dealId?: string
  contactId?: string
  ownerId: string
  occurredAt: string
  subject: string
  body: string
  nextAction?: string            // 入力するとタスクが自動生成される（FR-403）
  emailPreview?: { to: string; subject: string; html: string }  // メール送信時（FR-411）
  attachments: { name: string; size: number; objectUrl: string }[]
  createdAt: string
}

type Task = {
  id: string
  title: string
  dueDate: string
  ownerId: string
  assignedById?: string          // 他者から割り当てられた場合
  accountId?: string
  dealId?: string
  activityId?: string            // 自動生成元
  isDone: boolean
  doneAt?: string
  createdAt: string
}

// ---- 見積・商品 ----
type Product = { id: string; name: string; categoryId: string; unitPrice: number; cost: number; unit: string; isActive: boolean }

type Quote = {
  id: string
  quoteNumber: string            // 見積番号（自動採番）
  dealId: string
  accountId: string
  version: number
  title: string                  // 件名
  issuedDate: string
  validUntil: string
  items: QuoteItem[]
  taxMode: 'inclusive' | 'exclusive'
  taxRate: number                // 0.10
  roundingMode: 'floor' | 'ceil' | 'round'
  note: string
  status: 'draft' | 'sent' | 'accepted' | 'rejected'
  createdAt: string
}
type QuoteItem = {
  id: string
  productId?: string
  name: string
  quantity: number
  unit: string
  unitPrice: number
  discountRate: number           // 0-1
  sortOrder: number
}
// 小計・税・合計はストアに保存しない。lib/calc/quote.ts で常に算出する（FR-503）

// ---- カスタム項目・ビュー ----
type CustomField = {
  id: string
  target: 'account' | 'deal'
  label: string
  type: 'text' | 'number' | 'date' | 'select' | 'multiselect' | 'checkbox'
  options?: string[]
  isRequired: boolean
  sortOrder: number
}
type CustomValue = string | number | boolean | string[] | null

type SavedView = {
  id: string
  name: string
  target: 'account' | 'contact' | 'deal' | 'task'
  ownerId: string
  isShared: boolean              // マネージャー以上のみ true にできる
  filters: Filter[]
  visibleColumns: string[]
  sort: { field: string; dir: 'asc' | 'desc' }[]
  createdAt: string
}
type Filter = {
  field: string
  operator: 'eq' | 'contains' | 'gte' | 'lte' | 'between' | 'in' | 'isEmpty' | 'isNotEmpty'
  value: unknown
}

// ---- その他 ----
type Tag = { id: string; name: string; color: string }
type Notification = {
  id: string
  targetUserId: string
  type: 'assigned' | 'task_assigned' | 'due_soon' | 'stagnant' | 'deal_won' | 'deal_lost'
  title: string; body: string; link: string
  readAt?: string
  createdAt: string
}
type AuditLog = {
  id: string
  actorId: string
  action: 'create' | 'update' | 'delete' | 'merge' | 'import'
  targetType: 'account' | 'contact' | 'deal' | 'task' | 'quote' | 'setting'
  targetId: string
  changes: { field: string; before: unknown; after: unknown }[]
  createdAt: string
}
type MonthlyTarget = { id: string; yearMonth: string; scope: 'company' | 'team' | 'user'; scopeId: string; amount: number }

シードデータ（lib/seed/）

シード作成のルール（品質を左右する）

• 実在企業名・実在人名を使わない。 架空のものを使う
• 商談名・活動内容をテンプレの繰り返しにしない。 業種・段階に応じて書き分ける。「〇〇の件」ばかりだと一瞬で作り物だと分かる
• 金額の分布に偏りを持たせる（小口が多く、大口が少ない）。均等分布は不自然
• 日付は現在日時からの相対で生成する。固定日付を埋め込まない
• 活動の頻度に濃淡をつける。よく訪問している顧客と、半年放置の顧客が混在すること
• 停滞商談・期限超過タスク・目標未達の担当者を意図的に配置する。 全部が順調だと、ダッシュボードのアラート機能が動いて見えない
• 受注／失注の理由を分散させ、失注分析のグラフが意味を持つようにする

ストアとリポジトリ

lib/
├── types/          # 上記の型定義
├── seed/           # シードデータ
├── store/
│   ├── session.ts  # 現在のロール、操作中のユーザー
│   ├── data.ts     # accounts / contacts / deals / activities / tasks / quotes ...
│   ├── settings.ts # customFields / stages / tags / products / targets
│   └── ui.ts       # 表示密度、ガイドツアー表示済みフラグ
└── repo/           # ★ コンポーネントが触るのはここだけ
    ├── _delay.ts   # 擬似ディレイ
    ├── _scope.ts   # ★ ロールによるデータスコープ。全メソッドが通す
    ├── accounts.ts  contacts.ts  deals.ts
    ├── activities.ts  tasks.ts  quotes.ts
    ├── views.ts  settings.ts  notifications.ts  reports.ts

リポジトリ層の規約（厳守）

• 全メソッドを async で定義する。中身が同期でも例外なく
• 戻り値は { ok: true; data: T } | { ok: false; error: string } に統一する
• コンポーネントから Zustand ストアを直接参照しない。 読み取りも書き込みもリポジトリ経由
• スコープ適用（_scope.ts）を全メソッドが必ず通す。 ここが実案件でRLSに置き換わる箇所（FR-005）
• 派生値（stagnantDays、weightedAmount、見積の合計）はストアに保存せず、リポジトリ／計算モジュールで都度算出する

// lib/repo/_scope.ts — 実案件では RLS に置き換わる箇所
export function scopeAccounts(accounts: Account[]): Account[] {
  const { role, userId, teamId } = useSessionStore.getState()
  if (role === 'admin') return accounts
  if (role === 'manager') {
    const memberIds = getTeamMemberIds(teamId)
    return accounts.filter(a => memberIds.includes(a.ownerId))
  }
  return accounts.filter(a => a.ownerId === userId)   // sales
}

8. デザイン要件

アートディレクション

「一望できる作業台」

RELATE は毎日8時間開かれる業務システム。読ませる画面ではなく、比べて・選んで・動かす画面。したがって設計の主眼は「一画面に必要な情報がどれだけ収まるか」と「手がどれだけ止まらないか」に置く。

• 数字が主役。 金額・件数・確度・日数を等幅数字で揃え、桁を目で比較できるようにする
• 密度を上げる。 余白でゆったり見せるのではなく、罫線と整列で情報量を担保する
• 色は警告のためにある。 通常状態はほぼ無彩色。停滞・期限超過・目標未達だけが色を持つ
• 手を止めない。 キーボード操作、インライン編集、コマンドパレット、一括操作

HIREBASE との差別化（重要） HIREBASE：明朝体・広い余白・静けさ・読ませる。 RELATE：ゴシック・高密度・等幅数字・操作させる。 トークンを流用しない。並べて見せたときに別のプロダクトに見えること自体が、LPでの説得材料になる。

カラートークン

app/globals.css に CSS 変数で定義し、tailwind.config.ts の theme から参照する。直書きの色指定を禁止する。

:root {
  --ink-900: #16181D;   /* 見出し・本文・数値 */
  --ink-600: #545A66;   /* 補助テキスト */
  --ink-400: #8A909C;   /* ラベル・非活性・罫線上のテキスト */
  --brand-700: #23407A; /* 主要CTA・選択状態 */
  --brand-500: #35589B; /* ホバー */
  --brand-50:  #EBF0F9; /* 選択行・アクティブなビュー */
  --surface:   #F6F6F4; /* ページ背景 */
  --card:      #FFFFFF; /* テーブル・カード背景 */
  --border:    #E3E2DE; /* 罫線 */
  --border-strong: #C9C7C1;  /* テーブルヘッダー下・区切り */

  /* シグナル：これ以外の色を画面に持ち込まない */
  --won:     #2E7D64;   /* 受注・達成 */
  --lost:    #8A909C;   /* 失注（無彩色。赤にしない） */
  --alert:   #C2453B;   /* 期限超過・目標未達 */
  --warn:    #B4741C;   /* 停滞・期限接近 */
}

配色ルール

• 通常状態のテーブル行に色を持たせない。色がついている行は「対応が必要な行」だけ
• 失注は赤ではなく無彩色にする。赤は「今действするべき」の意味に限定する
• 段階（ステージ）に固有色を割り当てない。段階は位置と幅で表現する。6色のバッジが並ぶ画面にしない

タイポグラフィ

本文は13px。 HIREBASE の15pxより小さい。これは業務システムとして情報密度を優先するための意図的な選択であり、代わりに行間とコントラストで可読性を担保する。

レイアウトとスペーシング

主要コンポーネント仕様

インタラクション要件（業務システムの肝）

モーション

全体的に **HIREBASE より短く設定する。**業務システムで待たされる感覚は品質の低さとして受け取られる。 prefers-reduced-motion: reduce 時は全アニメーションを無効化する。

アクセシビリティ（WCAG 2.1 AA）

ライティング規約

9. 技術要件・ディレクトリ構成

技術スタック（固定・勝手に変更しない）

上記以外のライブラリを入れる前に必ず提案し、承認を得ること。

ディレクトリ構成

/
├── CLAUDE.md                  # このファイル
├── app/
│   ├── layout.tsx             # アプリシェル（サイドバー・ヘッダー・デモ切替バー）
│   ├── page.tsx               # SC-001 ダッシュボード
│   ├── accounts/              # SC-010〜014
│   ├── contacts/              # SC-020, 021
│   ├── deals/                 # SC-030〜034
│   ├── activities/            # SC-040
│   ├── tasks/                 # SC-050
│   ├── quotes/                # SC-060〜062
│   ├── reports/               # SC-100〜104
│   ├── settings/              # SC-200〜208
│   └── dev/components/        # コンポーネントカタログ（本番では非公開）
├── components/
│   ├── ui/                    # shadcn/ui プリミティブ
│   ├── table/                 # DataTable, ColumnPicker, FilterBar, BulkActionBar, ViewSidebar
│   ├── domain/                # DealCard, StageBar, ActivityTimeline, TaskRow, MetricCard, QuoteEditor
│   ├── demo/                  # RoleSwitcher, ResetButton, GuideTour
│   └── layout/
├── lib/
│   ├── types/  seed/  store/  repo/   # 7章参照
│   ├── query/                 # 絞り込み・ソート・ビューの適用ロジック
│   ├── calc/                  # 見積計算、着地見込み、転換率、滞留日数
│   ├── csv/                   # インポート（列マッピング・検証）／エクスポート
│   ├── pdf/                   # 見積書テンプレート
│   ├── validation/            # Zod スキーマ
│   └── utils/
├── e2e/                       # Playwright
└── public/

コーディング規約

• TypeScript strict。any 禁止。やむを得ない場合は unknown + 型ガード
• ファイル名は kebab-case、コンポーネントは PascalCase
• 1ファイル300行を超えたら分割を検討する
• コンポーネントから Zustand ストアを直接参照しない。必ず lib/repo/ 経由
• 絞り込み・計算ロジックは lib/query/ と lib/calc/ に置き、コンポーネントに埋め込まない（テスト対象にするため）
• 派生値をストアに保存しない。常に算出する
• コミットは1タスクごと。メッセージに要件IDを含める 例：feat(deals): パイプラインの停滞検出を実装 (FR-308)

10. 非機能要件

実案件への転用時の注意（デモ本体の要件ではない）

将来この構成を実サービスへ転用する場合、以下が追加で必要になる。商談で聞かれた際に説明できるよう記録として残す。

• データスコープはサーバー側（RLS等）で担保する必要がある。 本デモの lib/repo/_scope.ts がその置き換え地点であり、構造上そのまま差し替えられる
• 顧客情報は個人情報保護法の対象。利用目的の明示、安全管理措置、委託先管理、開示・削除請求への対応が必要になる
• CSVエクスポートは情報持ち出しの経路になるため、実運用では権限制御と操作ログが必須
• 本デモは顧客データをサーバーに送信しないため、これらの義務は発生しない。 ただし「デモである」旨は画面上に常時明示する

11. 実装タスク

この順に進める。フェーズを飛ばさない。 完了時は [x] に更新する。

Phase 0 — 基盤とデザインシステム（3日）

0-1. 初期化

• Next.js 15 / TypeScript strict / App Router / Tailwind で初期化
• ESLint / Prettier / husky（pre-commit で lint + typecheck）
• 9章のディレクトリ構成を作成

0-2. 型とシード

• lib/types/ に7章の型定義をすべて実装
• lib/seed/masters.ts / users.ts / stages.ts
• lib/seed/accounts.ts（140社）／contacts.ts（320名）
• lib/seed/deals.ts（140件。停滞・期限超過を意図的に含める）
• lib/seed/activities.ts（900件。頻度に濃淡をつける）／tasks.ts（86件）
• lib/seed/products.ts / quotes.ts / targets.ts
• 商談名・活動内容を業種と段階に応じて書き分ける。テンプレの使い回し禁止
• 日付は現在日時からの相対で生成する

0-3. ストアとリポジトリ

• lib/store/{session,data,settings,ui}.ts を Zustand + persist で実装
• lib/repo/_scope.ts を最初に実装する（FR-005, FR-006）
• lib/repo/ の全モジュールを実装。全メソッド async、擬似ディレイ、Result型、スコープ適用
• lib/calc/ に 滞留日数・加重金額・着地見込み・見積計算 を実装
• スコープとcalcの単体テストをこの時点で書く。後回しにしない

0-4. デザインシステム

• app/globals.css にカラートークンを CSS 変数で定義
• tailwind.config.ts から CSS 変数を参照するよう theme を拡張
• フォント（Noto Sans JP / Roboto Mono）を next/font で最適化。数値に tabular-nums を適用
• タイプスケールをユーティリティクラスとして定義
• shadcn/ui を導入し、トークンに合わせて Button / Input / Select / Checkbox / Dialog / Sheet / Popover / Toast / Badge / Tabs / Tooltip / DropdownMenu を上書き
• アプリシェル（サイドバー折りたたみ、ヘッダー、パンくず）
• 共通コンポーネント：EmptyState（データ0件と絞り込み0件を出し分け）／Skeleton（テーブル行形状）／MetricCard / StatusBadge / TagChip / UserAvatar
• prefers-reduced-motion の全体対応
• /dev/components にコンポーネントカタログを作成

0-5. デモ基盤

• RoleSwitcher（3ロール + 営業担当のメンバー選択）(FR-001, FR-002)
• デモ切替バーを固定配置。プロダクトのトークンとは別扱いのデザイン
• 「デモをリセット」(FR-003)
• ロール権限外アクセス時の案内画面 (FR-008)

Phase 0 完了チェック

• /dev/components で全コンポーネントがトークン通りに表示される
• ロールを切り替えると、リポジトリが返す件数が変わる（スコープのテストが通る）
• リロードしても状態が保持される

Phase 1 — 一覧基盤と顧客管理（4日）

1-1. データテーブル基盤（最重要。ここの品質が全画面に波及する）

• lib/query/ に 絞り込み・ソート・ビュー適用ロジックを実装（テスト付き）
• DataTable（TanStack Table ヘッドレス + 自前UI）。固定ヘッダー、列幅リサイズ
• 列カスタマイズ（表示・非表示・並び替え）(FR-101)
• ソート（複数列対応）(FR-102)
• FilterBar：項目ごとの条件指定 (FR-103)
• URLクエリとの同期 (FR-104)
• ConditionChips：適用条件の表示と個別解除 (FR-105)
• 行選択と BulkActionBar（下からせり上がる）(FR-108, FR-109)
• 取り消し可能な削除トースト (FR-110, IX-06)
• 仮想スクロール (FR-113)
• 密度切替（40px / 32px）(FR-114)
• キーボード操作（↑↓ Enter Space ⌘A）(IX-02)
• インライン編集（Enter Esc Tab）(FR-115, IX-03)

1-2. 保存ビュー

• ViewSidebar：ビュー一覧、件数バッジ、ワンクリック切替 (FR-107)
• ビューの保存・編集・削除。個人／共有の区別（共有はマネージャー以上）(FR-106)

1-3. 顧客・担当者

• SC-010 顧客一覧（上記テーブル基盤を適用）
• SC-011 顧客詳細（インライン編集、タブ構成）(FR-202, FR-206)
• SC-012 顧客の新規作成 + 重複検出警告 (FR-203)
• SC-013 重複マージ（並列比較、項目ごとの選択、関連レコードの引き継ぎ）(FR-204)
• SC-020 担当者一覧 / SC-021 担当者詳細 (FR-205)

1-4. CSV入出力

• lib/csv/ にインポート（列マッピング・検証）／エクスポートを実装
• SC-014 インポート4ステップ（ファイル選択 → 列マッピング → プレビュー → 結果）(FR-207, FR-209)
• 未対応列の「カスタム項目として追加」(FR-208)
• インポートタグの自動付与 (FR-210)
• 数式インジェクションの無害化 (NFR-09)
• エクスポート（現在の絞り込み・表示列のまま、実際にダウンロード）(FR-211)

1-5. グローバル検索・コマンドパレット

• ヘッダーのグローバル検索（種別グループ化）(FR-111)
• ⌘K コマンドパレット（cmdk）(FR-112)
• ショートカット：/ 検索フォーカス、N 新規作成、? 一覧表示 (IX-04, IX-05)

Phase 1 完了チェック

• フローCが完走する（CSVインポート → 一覧に反映）
• 1,000行でも絞り込みが100ms以下、スクロールが60fps
• テーブルがキーボードのみで操作完遂できる
• ロールを切り替えると一覧の件数が変わる

Phase 2 — 商談・パイプライン（4日）

• SC-030 パイプライン（カンバン）。列ヘッダーに件数・合計金額・金額比率のプログレス (FR-302)
• dnd-kit による D&D 段階変更 (FR-303)
• キーボードでの段階変更代替 (FR-304, A11Y-02)
• 段階移動時の必須項目チェックモーダル (FR-305)
• 確度の自動設定と手動上書き (FR-306)
• SC-031 商談一覧（テーブル）。カンバンとの切替で絞り込みを維持 (FR-307)
• 停滞検出（既定14日）の算出とフラグ表示 (FR-308)
• 期限超過フラグ (FR-309)
• SC-032 商談詳細。段階進捗バー、活動タイムライン、タスク、見積 (FR-312)
• SC-033 商談の新規作成（顧客詳細からの遷移で顧客を自動セット）／複製 (FR-313)
• SC-034 受注・失注登録（理由の定型選択 + 自由記述）(FR-310)
• SC-001 ダッシュボード（ロールで表示内容が変わる）(FR-601, FR-602)

Phase 2 完了チェック

• 4章「ロールを跨ぐ体験」の1と2が動作する
• 停滞・期限超過の商談が、ダッシュボードとパイプラインの両方で正しくフラグされる
• カンバンがキーボードのみで操作できる

Phase 3 — 活動・タスク・見積（4日）

3-1. 活動・タスク

• SC-041 活動記録モーダル（一覧・詳細から離れずに記録）(FR-401, FR-402)
• 次アクション入力からのタスク自動生成 (FR-403)
• ActivityTimeline（種別アイコン、日付グルーピング、種別フィルタ）(FR-404)
• SC-040 活動一覧
• SC-050 タスク一覧（期限別グルーピング）(FR-405, FR-406)
• ダッシュボードの今日のタスク・期限超過 (FR-407)
• チェックによる完了と取り消し (FR-408)
• マネージャーによるタスク割当と通知 (FR-409)
• 活動記録時に Account.lastActivityAt / Deal.lastActivityAt を更新する

3-2. メール

• メールテンプレートと差し込み変数の置換 (FR-410)
• 送信内容のプレビューモーダル → 確定で活動履歴に自動記録 (FR-411)

3-3. 見積・商品

• SC-203 商品マスタ (FR-501)
• SC-061 見積作成（明細行の追加・並び替え、商品マスタからの選択）(FR-502)
• lib/calc/quote.ts：行小計・小計・消費税・合計の算出（内税／外税、端数処理）(FR-503, FR-504)
• SC-062 見積プレビュー → @react-pdf/renderer でPDFを生成し、実際にダウンロードできること (FR-505)
• SC-060 見積一覧、商談詳細からの作成 (FR-506, FR-508)

Phase 3 完了チェック

• フローAが完走する（顧客登録 → 商談作成 → 活動記録 → タスク自動生成 → 見積PDF → 受注）
• 4章「ロールを跨ぐ体験」の3が動作する
• 見積PDFが実際にダウンロードでき、レイアウトが崩れていない

Phase 4 — 分析と設定（3日）

4-1. 分析

• SC-100 パイプライン分析（段階別件数・金額、転換率ファネル、平均滞留日数）(FR-603)
• SC-101 担当者別実績（営業担当ロールでは非表示）(FR-604)
• SC-102 予実管理（目標・実績・着地見込み・達成率）(FR-605, FR-311)
• SC-103 失注分析 (FR-606)
• SC-104 活動分析
• 全分析画面の期間指定 (FR-607)

4-2. 設定

• SC-201 カスタム項目（6種の型）(FR-608)
• カスタム項目が詳細画面・編集フォーム・列選択・絞り込みに即座に反映されること (FR-609)
• SC-202 パイプライン段階の編集。変更が既存商談に即座に反映されること (FR-314)
• SC-204 ユーザー・チーム管理 (FR-610)
• SC-205 タグ管理 / SC-206 メールテンプレート / SC-208 目標設定
• SC-207 操作ログ (FR-611)
• 通知センター (FR-612)

Phase 4 完了チェック

• フローBが完走する（マネージャーの週次レビュー）
• 4章「ロールを跨ぐ体験」の4が動作する（カスタム項目の追加が営業担当の画面に反映）

Phase 5 — 仕上げ（3日）

5-1. 体験の総点検

• 4章「ロールを跨ぐ体験」の4パターンをすべて手動で確認する
• 全32画面を開き、空の画面が1つもないことを確認する
• 全画面の空状態（データ0件／絞り込み0件の出し分け）・ローディング・エラー状態を確認する
• ガイドツアーを実装 (FR-009)
• localStorage 容量上限時の警告 (NFR-10)

5-2. アクセシビリティ監査

• axe-core を全画面に実行し、Critical / Serious を0件に
• キーボードのみで全画面を操作完遂する手動確認
• 13px本文のコントラスト比を実測して 4.5:1 以上を確認 (A11Y-01)
• フォントサイズ200%での確認 (A11Y-10)

5-3. パフォーマンス

• PDF・グラフ・CSVを動的importに切り出し、初期バンドルを250KB以下に (NFR-06)
• 1,000行での絞り込み100ms以下、スクロール60fps を実測 (NFR-04, NFR-05)
• Lighthouse で Performance 90 / Accessibility 95 を達成 (NFR-07)

5-4. テストと公開

• Playwright で フローA・B・C の E2E を実装・実行
• Vitest：lib/query lib/calc lib/csv lib/repo/_scope のカバレッジ80%以上
• /dev/components を本番で非公開に
• Vercel へデプロイ
• LP への導線設置（HIREBASE と並べる）
• 各フェーズのキャプチャを整理し、LP掲載用の時系列コンテンツにまとめる

合計 18営業日（約3.5週間）／1名専任 + レビュー体制。 各フェーズ完了時点でプレビューURLと画面キャプチャを残し、「Day 3 でここまで」「Day 7 でここまで」という時系列コンテンツとして LP に掲載する。

工数配分の意図： Phase 1 に4日を割いているのは、データテーブル基盤が全画面に波及するため。ここを雑に作ると、以降の全一覧画面が作り直しになる。逆にここが良ければ、商談・タスク・見積の一覧はほぼ設定だけで完成する。

12. 受入基準

1. 6章の優先度 P1 の要件がすべて実装されていること
2. 5章の主要フローA・B・Cが、エンドツーエンドで完走すること
3. 4章「ロールを跨ぐ体験」の4パターンがすべて動作すること
4. ロールを切り替えると、一覧・ダッシュボード・分析の表示範囲が変わること。かつスコープ判定が lib/repo/_scope.ts に集約されていること
5. 一覧テーブルが、絞り込み・列選択・保存ビュー・一括操作・キーボード操作のすべてに対応していること
6. 1,000行での絞り込みが100ms以下、スクロールが60fpsを維持すること
7. CSVインポートが列マッピングとエラー行表示に対応し、CSVエクスポートと見積PDFが実際にダウンロードできること
8. 全32画面のいずれにも空の状態がなく、リアルなデータが表示されていること
9. リロード後も操作結果が保持され、「デモをリセット」で初期状態に戻ること
10. axe-core で Critical / Serious の指摘が0件であること
11. Lighthouse の基準値を満たすこと
12. データアクセスがすべて lib/repo/ を経由しており、コンポーネントが Zustand ストアを直接参照していないこと
13. HIREBASE と並べたときに、明確に別のプロダクトとして見えること（8章のアートディレクションが実現されていること）

判断に迷ったときのルール

1. 仕様がこの文書にない場合は、実装せずに質問する。 推測で作らない
2. キーボード操作と「空の画面を作らない」は削減対象外。 速度を出すために削らない
3. スコープ外（3章 Won't have）は、思いついても実装しない。特にワークフロー自動化ビルダーと帳票の自由レイアウト編集
4. 「デモだから」を理由に品質を落とす判断はしない
5. コンポーネントからストアを直接触りたくなったら、それはリポジトリ層に足りないメソッドがあるということ
6. HIREBASE のトークン・コンポーネントをコピーしない。 別プロダクトとして設計する