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

版数 1.0（DBレス構成 / 記事埋め込み型デモ）／ 作成日 2026-08-24 ／ 発行 ソウゾウ合同会社 用途 SEO記事「【デモで試せる】Claude Codeでタスク管理システムを自作する方法と費用｜動画つき資料【2026年】」に組み込む実演デモ

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

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

• 実装は「12. 実装タスク」の順に進める。フェーズを飛ばさない。
• 各タスクの括弧内は要件ID。着手前に該当章を読むこと。
• 仕様がここに書かれていない場合は、推測で実装せず質問する。
• スコープ外（3章 Won't have）は、思いついても実装しない。
• 「デモだから」を理由に品質を落とす判断はしない。
• この領域だけの特別ルール：既製ツールの機能を真似しない。 タスク管理は世界中に優れた既製品がある。それを模倣した瞬間、劣化コピーになる。 自作の理由（1章）に紐づかない機能は実装しない。

姉妹プロジェクトとの関係 HIREBASE／RELATE／CASTA／FIELDPIN／KANADE／MIWAKE／KAMIWAZA／KURA／TOKIWA／HIBI／TENKEN に続くシリーズ。並べて「同じテンプレ」と思われた時点で失敗。 特に RELATE / KURA / TOKIWA との差別化に注意。 RELATE＝罫線と等幅数字で表を読ませる（藍）／ KURA＝各行に在庫の水位バー（ティール＋アンバー）／ TOKIWA＝各行に24時間帯（インディゴ＋コーラル）／ HIBI＝1カラム・広い余白・15px本文（墨＋若草）／ TENKEN＝濃い地に巨大な判定ボタン（安全色）／ TSUMU＝カードが主役。角丸12pxの厚みのあるカードが、ボード・リスト・カレンダーの3つのビューを行き来する。（生成りの紙色＋インディゴ、ドラッグの手触りが命） TSUMU だけが「同じデータを3つの見え方で往復する」アプリ。 8章参照。

目次

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

1. プロジェクト概要

背景と目的

タスク管理システムは、世界一競合が多い領域である。無料で使える優れたツールが山ほどある。

それでも毎年、自作の相談が来る。 そして相談者は決まってこう言う。

「いろいろ試したんですが、うちのやり方に合わなくて」

この領域には、最初に共有すべき事実が3つある。

事実①：タスク管理ツールが定着しない原因は、ツールではなく「入力されないこと」

どんなに優れたツールでも、タスクが入っていなければ何も管理できない。 そして現実には、タスクは次の場所に散らばっている。

タスク管理ツールへの入力は「二重作業」に感じられる。 だから入力されない。

タスク管理システムの成否は、機能ではなく「タスクがどれだけ楽に入るか」で決まる。 目標は 依頼から3秒でタスクになること。

事実②：「タスク」は3つの別のものが混ざっている

多くのタスク管理が破綻するのは、性質の違うものを1つのリストに入れるから。

①だけならメモアプリで足りる。②が必要になった瞬間に「システム」が要る。③を手作業でやっている会社は、そこだけで週に何時間も溶かしている。

TSUMU はこの3つを別の機能ではなく、同じタスクの見え方の違いとして扱う。

事実③：同じタスクを、人によって違う見え方で使いたい

• 現場担当は**「自分の今日やること」のリスト**が見たい
• リーダーは**「誰が何を持っているか」のボード**が見たい
• 管理者は**「いつ終わるのか」のカレンダー／ガント**が見たい

別々のツールを使うと、データが分かれて死ぬ。 同じデータを、3つの見え方で往復できることが要件になる。

TSUMU はこの3つの事実を前提に設計する。

プロダクト定義

プロダクトコンセプト

「3秒で積む。3つの見え方で捌く。」

TSUMU はタスクの追加にかかる秒数を計測し、表示する。1行の自然文から期限・担当・案件を切り出し、⌘K からどこでも積める。入れるのが速いから、入る。 そして積まれたタスクは、ボード・リスト・カレンダーを自由に往復する。

デモとしての成功条件

1. 入力が速いことが分かる — 1行入力から期限・担当が自動で切り出され、追加までの秒数が出る
2. 3ビューが同期する — ボードで動かすとカレンダーが変わり、リストで期限を変えるとボードの列が変わる
3. ドラッグの手触りが良い — ボードのD&Dが引っかからない。ここが悪いと全部が安っぽく見える
4. 繰り返しが自動生成される — 完了すると次回分が自動で積まれる
5. 依存関係が見える — 前工程が終わらないと着手できないタスクが分かる
6. ロールで見え方が変わる — 担当者は自分の今日、リーダーはチームのボード
7. リセットできる — 誰が触った後でも初期状態に戻せる

2. アーキテクチャ方針

基本方針

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

なぜこの構成にするか

• LPデモとして最適 — 訪問者は登録もログインもせずに、全機能を即座に触れる
• タスクの中身が外に出ない — 業務内容は機密。データを預からないことが訴求になる
• 開発速度 — 認証・APIの実装が不要になり、入力速度とドラッグの手触りに全時間を投下できる
• 運用コストゼロ — Vercel の静的配信のみ

3ビュー同期の原則（最重要の設計判断）

ボード・リスト・カレンダーは「3つの機能」ではなく、「1つのデータの3つの射影」である。

                    [ Task（唯一のデータ）]
                            │
        ┌───────────────────┼───────────────────┐
        ▼                   ▼                   ▼
   [ ボード ]          [ リスト ]         [ カレンダー ]
   status で列分け      条件で絞り込み      dueDate で配置
        │                   │                   │
   列を移動 →           期限を変更 →        日付をドラッグ →
   status を更新        dueDate を更新      dueDate を更新
        └───────────────────┴───────────────────┘
                            ▼
                  ★ すべて同じ Task を更新する
                  ★ 他のビューに即座に反映される

VIEW-05 が重要。 「ボードでは担当を変えられるが、カレンダーではできない」といった非対称があると、ユーザーはビューを信用しなくなる。

自然文からのタスク生成（事実①への回答）

依頼から3秒でタスクにするために、1行の自然文を解析する。

入力：「田中さん 来週金曜までに A社の見積書作成 #営業」

  ↓ lib/parse/quick-add.ts（ルールベース。AIを使わない）

タイトル：A社の見積書作成
担当   ：田中（メンバー名と一致）
期限   ：来週金曜 → 2026-09-04（相対日付の解決）
案件   ：営業（#タグ）

PRS-04 が重要。 賢く解析しようとして入力を妨げたら本末転倒。解析は「おまけ」であり、タスクが積まれることが本体。

チャット取り込みのシミュレーション（事実①の可視化）

実案件で最も効くのはチャット連携だが、デモではAPIを叩けない。そこで「取り込みの体験」だけを再現する。

「チャットの1メッセージが、そのままタスクになる」体験ができれば、事実①の解決策が伝わる。

差し替え可能性の担保

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

[ コンポーネント ]
        ↓  呼ぶのはこの層だけ
[ lib/repo/*.ts ]   ← 全メソッドを async にしておく
        ↓
[ lib/view/ ]       ← 3ビューへの射影（純粋関数）
[ lib/parse/ ]      ← 自然文解析（純粋関数）
[ lib/recur/ ]      ← 繰り返し生成（純粋関数）
[ lib/graph/ ]      ← 依存関係・進捗（純粋関数）
[ lib/store/*.ts ]  ← Zustand + persist（localStorage）
        ↓
[ lib/seed/*.ts ]   ← 初期データ

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

記事への組み込み

記事内で見せるのは「入れるのがどれだけ速いか」だけに絞る。 これが事実①そのものであり、スクロール中に体験できる唯一のことになる。

永続化の範囲

擬似ディレイ は 150〜400ms。ただしタスクの追加・ドラッグ&ドロップ・ビュー切替・絞り込みは擬似ディレイを入れず、100ms以下とする（ドラッグがもたつくのは、このアプリで最も致命的）。

3. スコープ定義

積む（入力）

捌く（3ビュー）

進める（タスクの中身）

管理する

共通・基盤

対象外（Won't have）

スコープリスク： タスク管理は「あのツールのあの機能が欲しい」が最も出やすい領域。既製ツールの機能を1つずつ足していくと、劣化コピーになって必ず負ける。 自作の価値は「既製ツールにない、自社固有の何か」にしかない（11章）。それが何かを要件定義で確定させることが最重要。 資料PDFの「自作判断シート」はこのために作る。

4. ロールとデモ切替

ロール定義

データスコープの要点

SCP-04 が重要。 「検索したら見えないはずのタスクのタイトルが出た」は、タスク管理では致命的な事故になる（人事案件・M&A案件などが混ざるため）。検索インデックスの段階で除外する。

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

1. 担当者がタスクをクイック追加（「田中さん 来週金曜 A社見積 #営業」）→ リーダーに切替 → チームボードの田中の列に現れている
2. リーダーがボードでカードを別の担当に動かす → 担当者に切替 → 自分の今日のリストから消えている／現れている
3. リストビューで期限を変更 → カレンダービューに切り替えると、その日付に移動している（VIEW-01）
4. カレンダーでカードを別の日にドラッグ → リストの期限が変わっている
5. 繰り返しタスクを完了 → 次回分が自動で生成され、カレンダーの次の日付に現れている
6. 依存関係のあるタスクを、前工程が未完了のまま着手しようとする → 警告が出る
7. 管理者がステータス列を1つ追加 → 担当者に切替 → ボードの列が増えている
8. リーダーが負荷を確認 → 1人にタスクが偏っていることが見え、その場で担当を振り替えられる

3・4・5 が、このデモの核心。 事実②③が体験として成立する瞬間。

デモ切替バー（F-C01）

画面上部に常時表示する固定バー。埋め込みモードでは非表示。

• 現在のロールと氏名・チームの表示、3ロールの切替
• 担当者ロール時：3名から選択（タスクが多い人／期限超過がある人／新人）
• デモ内の現在日時（シードが相対日付のため基準を示す）
• 「デモをリセット」ボタン（確認ダイアログ付き）
• 元記事へ戻るリンク
• 「これはデモです。タスクの内容は送信されません」の明示

デザイン上の扱い： プロダクト本体が生成りの紙色で明るいので、切替バーは濃い墨色の帯にして区別する。

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

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

積む・捌く（担当者）

管理する（リーダー・管理者）

主要フロー

フローA：記事の読者が「積む速さ」を体験する（最重要）

SEO記事を読んでいる
   ↓
記事内の埋め込み（SC-900）
┌──────────────────────────────────────────────────────────┐
│  ＋ タスクを追加                                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │ 田中さん 来週金曜までに A社の見積書作成 #営業        │  │
│  └────────────────────────────────────────────────────┘  │
│  💡 「明日」「来週金曜」「@名前」「#タグ」が使えます        │
│                                                          │
│  例を試す：                                               │
│  [ 明日 請求書を送る ]  [ @佐藤 今週中に資料レビュー ]     │
│  [ 毎週月曜 週次ミーティングの準備 ]                       │
└──────────────────────────────────────────────────────────┘
   ↓
入力すると、打っている最中に解析チップが現れる
   ┌──────────────────────────────────────────────────────┐
   │ A社の見積書作成                                       │
   │ [👤 田中 ×] [📅 9/4(金) ×] [🏷 営業 ×]                │
   └──────────────────────────────────────────────────────┘
   ★ 何が切り出されたかが見える（PRS-02）
   ★ チップの × で解除してタイトルに戻せる（PRS-03）
   ↓
Enter で追加
   ↓  ★ 小さなボードの「未着手」列にカードが積まれる
   ★ 「2.4秒で追加」と控えめに表示される
   ↓
カードを「進行中」にドラッグ
   ↓  ★ 引っかからずに動く。ここの手触りが命
   ↓
「全画面で試す」→ 別タブ
   ↓
SC-010 ボードビュー ── 実データが入ったボード
   ↓
ビュー切替でカレンダーへ ── ★ 絞り込みが維持されたまま切り替わる（VIEW-03）
   ↓  ★ さっき追加したタスクが 9/4 の枠にいる
カードを 9/8 にドラッグ
   ↓
リストビューに切替 ── ★ 期限が 9/8 に変わっている（VIEW-01）
   ↓
ロール切替「リーダー」→ SC-100 チームボード
   ↓  ★ 田中の列にそのタスクがある
SC-101 負荷の可視化 ── ★ 担当の偏りが見える
   ↓
資料ダウンロード or 元記事に戻る

フローB：チャットの依頼が3秒でタスクになる（事実①の解決策を見せる）

SC-030 チャット取り込み（模擬）
┌──────────────────────────────────────────────────────────┐
│  ⚠ これは模擬チャットです。実際のSlack等には接続していません │
│                                                          │
│  #営業チーム                                              │
│  ─────────────────────────────────────────────────────   │
│  佐藤  10:32                                             │
│  田中さん、A社の件、来週金曜までに見積出せますか？          │
│                                    [ タスクにする ]       │
│  ─────────────────────────────────────────────────────   │
│  田中  10:35                                             │
│  了解です。あと請求書の件も今日中にやっておきます           │
│                                    [ タスクにする ]       │
└──────────────────────────────────────────────────────────┘
   ↓
1つ目の「タスクにする」を押す
   ↓  ★ 自然文解析が走り、確認モーダルが開く
   ┌──────────────────────────────────────────────────┐
   │  タイトル：A社の件、見積を出す                     │
   │  [👤 田中 ×] [📅 9/4(金) ×]                        │
   │                                                  │
   │  元メッセージ：佐藤 10:32（リンクを保持します）      │
   │                                                  │
   │  [ キャンセル ]              [ タスクにする ]      │
   └──────────────────────────────────────────────────┘
   ↓
確定
   ↓  ★ タスクが作られ、詳細に元メッセージへの参照が残る（IMP-02）
SC-020 タスク詳細 ── ★ 「チャットから作成（#営業チーム 佐藤 10:32）」
   ↓
SC-050 仕組みの解説
   ★ 「実際の連携では、Slack の Bot やメール転送で同じことができます」
   ★ 実装方式（Webhook / Bot / メール転送）とそれぞれの費用感（IMP-04）
   ↓
★ ここで伝わること：
  「タスク管理が続かないのは、入力が二重作業だから。
   依頼が発生した場所から直接タスクになれば、その問題は消える」

フローC：繰り返しと依存で「段取り」を回す

【管理者】SC-121 テンプレート管理
  「新規案件の初動」テンプレートを作る
  ┌────────────────────────────────────────────────┐
  │ 1. キックオフ日程の調整      起点日 +0日  @営業  │
  │ 2. 要件ヒアリング            起点日 +3日  @営業  │
  │ 3. 見積作成                  起点日 +7日  @PM   │  ← 2 に依存
  │ 4. 提案書作成                起点日 +10日 @PM   │  ← 3 に依存
  │ 5. 提案                      起点日 +14日 @営業 │  ← 4 に依存
  └────────────────────────────────────────────────┘
   ↓
【リーダー】SC-024 テンプレートからの追加
  起点日を「来週月曜」に指定 → プレビューで日付が計算される
   ↓
5タスクが一括生成され、依存関係も張られる
   ↓
SC-013 タイムライン ── ★ 依存が線で結ばれ、順序が見える
   ↓
【担当者】SC-001 今日
  「見積作成」に着手しようとする
   ↓  ★ 警告：「『要件ヒアリング』が未完了です。先に進めますか？」（F-T03）
   ★ ブロックはしない。現実には並行して進むこともあるから
   ↓
─────────────────────────────────────────────────────
【繰り返しの体験】
SC-020 タスク詳細 ──「毎月の請求処理」（繰り返し：毎月25日）
   ↓
完了にする
   ↓  ★ 次回分（翌月25日）が自動生成される（F-T06）
   ★ トースト：「次回分を 9/25 に作成しました」
   ↓
SC-012 カレンダー ── ★ 翌月25日にカードが現れている
   ↓
SC-120 繰り返しタスクの管理
  ★ 定義の一覧、次回生成日、生成履歴が確認できる
  ★ 「もう不要」なら停止できる（過去の記録は消えない）
   ↓
★ ここで伝わること：
  「毎月同じタスクを手で作る作業は、システムがやるべきこと」

6. 機能要件

各要件はテスト仕様書の項目と1:1で対応する。「〜できること」の粒度で、判定可能な形で記述している。

6.1 入力体験（このデモの心臓部）

6.2 3ビューと同期

6.3 一覧・絞り込み・保存ビュー

6.4 タスクの中身

6.5 繰り返し（事実②③への回答）

6.6 チーム管理

6.7 設定・マスタ・分析

6.8 取り込み・デモ基盤

7. データ設計

型定義（lib/types/）

// ---- 組織・メンバー ----
type Team = { id: string; name: string; leaderId: string }
type Member = {
  id: string
  name: string                  // ★ 架空
  nameAliases: string[]         // ★ 「田中さん」「たなか」でも解析できるように（FR-104）
  teamId: string
  role: 'member' | 'leader' | 'admin'
  avatarUrl: string
  color: string                 // ボードの識別色
  isActive: boolean
}

// ---- プロジェクト ----
type Project = {
  id: string
  name: string
  color: string
  memberIds: string[]
  isPrivate: boolean            // ★ メンバー以外に一切返さない（SCP-04）
  startDate?: string
  dueDate?: string
  isArchived: boolean
  // 算出値：progressRate, taskCount
}

// ---- ステータス（ボードの列）----
type Status = {
  id: string
  name: string                  // 未着手 / 進行中 / レビュー / 完了
  color: string
  sortOrder: number
  isDone: boolean               // ★ 完了扱いか（FR-703）
  wipLimit?: number             // ★ WIP上限（FR-702）
}

type Tag = { id: string; name: string; color: string }
type Priority = 'low' | 'normal' | 'high' | 'urgent'

// ---- ★★★ タスク（唯一のデータ。3ビューはこれを射影する）★★★ ----
type Task = {
  id: string
  title: string
  description: string
  // --- 分類 ---
  projectId?: string
  statusId: string              // ★ ボードの列を決める
  priority: Priority
  tagIds: string[]
  // --- 担当と日付 ---
  assigneeId?: string           // ★ チームボードの列を決める
  startDate?: string
  dueDate?: string              // ★ カレンダーの位置を決める
  // --- 構造 ---
  parentTaskId?: string         // 親タスク（サブタスクの場合）
  subtaskIds: string[]
  dependsOnTaskIds: string[]    // ★ 前提タスク（FR-404）
  // --- 繰り返し ---
  recurrenceId?: string         // 繰り返し定義への参照
  generatedFromRecurrence: boolean
  // --- 時間 ---
  estimateMinutes?: number      // ★ 権限で出し入れ（SCP-05）
  actualMinutes?: number
  // --- 完了 ---
  completedAt?: string
  completedBy?: string
  // --- 出所（★ 取り込み元。IMP-02）---
  source: TaskSource
  // --- 添付・コメント ---
  attachmentIds: string[]
  // --- 並び順 ---
  boardOrder: number            // 列内の並び順
  // --- 監査 ---
  createdBy: string
  createdAt: string
  updatedAt: string
  history: TaskChange[]
  // --- ★ 入力の計測（EMB-05, FR-112）---
  addMetrics?: { activeSeconds: number; method: 'quick' | 'form' | 'template' | 'chat' | 'csv'; parsedFields: string[] }
}

type TaskSource =
  | { kind: 'manual' }
  | { kind: 'template'; templateId: string }
  | { kind: 'recurrence'; recurrenceId: string }
  | { kind: 'chat'; channel: string; author: string; postedAt: string; messageId: string }  // ★ IMP-02
  | { kind: 'mail'; from: string; subject: string; receivedAt: string }
  | { kind: 'csv'; importedAt: string }

type TaskChange = { at: string; by: string; field: string; before: unknown; after: unknown }
type Comment = { id: string; taskId: string; memberId: string; body: string; mentionedMemberIds: string[]; createdAt: string }

// ---- ★ 自然文解析の結果（PRS-02）----
type ParseResult = {
  title: string                 // 解析語を取り除いた残り
  matches: ParseMatch[]         // ★ チップとして表示（FR-108）
  // ★ 解析できなくても title は必ず返る（PRS-04）
}
type ParseMatch = {
  id: string
  kind: 'due' | 'start' | 'assignee' | 'tag' | 'priority' | 'recurrence' | 'project'
  rawText: string               // ★ 元の文字列（チップ解除時にタイトルへ戻す。FR-109）
  value: unknown                // 解決後の値（Date / memberId / tagId ...）
  label: string                 // チップの表示（「9/4(金)」「田中」）
  confidence: 'exact' | 'fuzzy' // 曖昧一致は確認を促す
}

// ---- 繰り返し ----
type RecurrenceRule =
  | { type: 'daily'; interval: number }
  | { type: 'weekly'; interval: number; weekdays: number[] }
  | { type: 'monthly_day'; interval: number; dayOfMonth: number }
  | { type: 'monthly_nth'; interval: number; nth: number; weekday: number }
  | { type: 'business_days' }   // ★ 祝日を除く（FR-508）

type Recurrence = {
  id: string
  templateTask: Pick<Task, 'title' | 'description' | 'projectId' | 'statusId' | 'priority'
                          | 'tagIds' | 'assigneeId' | 'estimateMinutes'>
  subtaskTitles: string[]       // FR-509
  rule: RecurrenceRule
  generateMode: 'on_complete' | 'on_due'   // ★ FR-502
  endCondition: { type: 'never' } | { type: 'count'; count: number } | { type: 'until'; date: string }
  generatedCount: number
  nextGenerateDate?: string     // ★ FR-505
  isActive: boolean             // ★ 停止しても過去分は残る（FR-506）
  createdAt: string
}
type RecurrenceLog = { id: string; recurrenceId: string; generatedTaskId: string; generatedAt: string }

// ---- テンプレート（タスクセット）----
type TaskTemplate = {
  id: string
  name: string
  description: string
  items: TaskTemplateItem[]
  createdBy: string
}
type TaskTemplateItem = {
  id: string
  title: string
  description: string
  offsetDays: number            // ★ 起点日からの相対日数（FR-708）
  durationDays?: number
  assigneeId?: string
  assigneeRole?: string         // 「営業」「PM」等、役割で指定して生成時に解決
  statusId: string
  priority: Priority
  tagIds: string[]
  dependsOnItemIds: string[]    // ★ テンプレート内での依存（FR-118）
  subtaskTitles: string[]
  sortOrder: number
}

// ---- ビュー ----
type ViewKind = 'board' | 'list' | 'calendar' | 'timeline'
type SavedView = {
  id: string
  name: string
  ownerId: string
  isShared: boolean             // leader 以上のみ true
  kind: ViewKind
  filters: Filter[]
  groupBy?: 'assignee' | 'project' | 'due' | 'priority' | 'status'
  sort: { field: string; dir: 'asc' | 'desc' }[]
  visibleColumns: string[]      // list のみ
  calendarMode?: 'month' | 'week'
}
type Filter = {
  field: 'assigneeId' | 'projectId' | 'tagIds' | 'statusId' | 'priority' | 'dueDate' | 'isDone'
  operator: 'eq' | 'in' | 'between' | 'isEmpty' | 'isNotEmpty' | 'before' | 'after'
  value: unknown
}

// ---- ★ ビューへの射影（保存しない。lib/view/ で算出）----
type BoardProjection = {
  columns: { statusId: string; name: string; color: string; wipLimit?: number
           ; taskIds: string[]; count: number; isOverWip: boolean }[]
}
type CalendarProjection = {
  mode: 'month' | 'week'
  days: { date: string; taskIds: string[]; isToday: boolean; isHoliday: boolean }[]
  unscheduledTaskIds: string[]  // ★ 期限未設定（FR-213）
}
type TimelineProjection = {
  rows: { taskId: string; startDate: string; endDate: string; laneIndex: number }[]
  dependencies: { fromTaskId: string; toTaskId: string }[]
}

// ---- 算出値（ストアに保存しない）----
type LoadMetrics = {            // FR-603
  memberId: string
  name: string
  openCount: number
  overdueCount: number
  estimateMinutesTotal?: number  // ★ 権限依存（SCP-05）
  deviationFromAvg: number       // ★ 偏りの強調に使う（FR-604）
}
type AttentionItems = {         // FR-605
  overdue: string[]
  stalled: { taskId: string; daysSinceUpdate: number }[]
  unassigned: string[]
  blocked: { taskId: string; blockingTaskIds: string[] }[]
}
type LeadTimeStats = { scope: string; createdToDoneDays: { avg: number; median: number }
                     ; startedToDoneDays: { avg: number; median: number }; sampleCount: number }
// ★ 個人別ランキングは作らない（FR-713）

// ---- 模擬チャット（IMP-01）----
type MockChannel = { id: string; name: string }
type MockMessage = {
  id: string
  channelId: string
  authorName: string
  body: string
  postedAt: string
  convertedTaskId?: string      // タスク化済み
}

// ---- 監査・通知 ----
type AuditLog = {
  id: string
  actorId: string
  action: 'update_status_master' | 'delete_status' | 'update_template' | 'stop_recurrence'
        | 'delete_task' | 'bulk_update' | 'export_csv'
  targetType: string
  targetId: string
  changes: { field: string; before: unknown; after: unknown }[]
  createdAt: string
}
type Notification = {
  id: string
  targetMemberId: string
  kind: 'assigned' | 'due_soon' | 'overdue' | 'mentioned' | 'stalled' | 'recurrence_generated'
  title: string
  body: string
  link: string
  previewMessage?: { channel: 'email' | 'chat'; subject?: string; body: string }  // ★ 送信しない
  readAt?: string
  createdAt: string
}

自然文解析の実装（7章の中核）

// lib/parse/quick-add.ts — ルールベース。AIを呼ばない（PRS-01）
export function parseQuickAdd(input: string, ctx: ParseContext): ParseResult {
  const matches: ParseMatch[] = []
  let rest = input

  // ① 相対日付（FR-103）。長いパターンから順に試す
  const dueRules: [RegExp, (m: RegExpMatchArray) => Date][] = [
    [/来週(月|火|水|木|金|土|日)曜?(?:まで)?(?:に)?/, m => nextWeekWeekday(ctx.now, m[1])],
    [/今週(月|火|水|木|金|土|日)曜?(?:まで)?(?:に)?/, m => thisWeekWeekday(ctx.now, m[1])],
    [/(\d+)日後/,        m => addDays(ctx.now, Number(m[1]))],
    [/明後日/,           () => addDays(ctx.now, 2)],
    [/明日/,             () => addDays(ctx.now, 1)],
    [/今日(?:中)?/,      () => ctx.now],
    [/月末(?:まで)?/,    () => endOfMonth(ctx.now)],
    [/(\d{1,2})\/(\d{1,2})/, m => resolveMonthDay(ctx.now, +m[1], +m[2])],
  ]
  for (const [re, resolve] of dueRules) {
    const m = rest.match(re)
    if (m) {
      const date = resolve(m)
      matches.push({ id: newId(), kind: 'due', rawText: m[0], value: date,
                     label: formatDateLabel(date), confidence: 'exact' })
      rest = rest.replace(m[0], ' ')   // ★ タイトルから取り除く
      break
    }
  }

  // ② 担当（FR-104）。@記法 + 氏名・別名の直接記述
  const mentionMatch = rest.match(/@(\S+)/)
  const nameHit = mentionMatch
    ? findMember(ctx.members, mentionMatch[1])
    : findMemberByAlias(ctx.members, rest)   // 「田中さん」「たなか」
  if (nameHit) {
    matches.push({ id: newId(), kind: 'assignee', rawText: nameHit.rawText,
                   value: nameHit.member.id, label: nameHit.member.name,
                   confidence: mentionMatch ? 'exact' : 'fuzzy' })
    rest = rest.replace(nameHit.rawText, ' ')
  }

  // ③ タグ（FR-105）／④ 優先度（FR-106）／⑤ 繰り返し（FR-107）も同様に抽出

  // ★ 何も解析できなくても、title は必ず返す（PRS-04）
  return { title: rest.replace(/\s+/g, ' ').trim() || input.trim(), matches }
}

ビュー射影の実装

// lib/view/board.ts — 同一の Task から列を組み立てる（VIEW-01, VIEW-02）
export function toBoard(tasks: Task[], statuses: Status[]): BoardProjection {
  return {
    columns: statuses
      .slice()
      .sort((a, b) => a.sortOrder - b.sortOrder)
      .map(st => {
        const ids = tasks
          .filter(t => t.statusId === st.id)
          .sort((a, b) => a.boardOrder - b.boardOrder)
          .map(t => t.id)
        return {
          statusId: st.id, name: st.name, color: st.color, wipLimit: st.wipLimit,
          taskIds: ids, count: ids.length,
          isOverWip: st.wipLimit != null && ids.length > st.wipLimit,   // FR-212
        }
      }),
  }
}

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

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

• 実在企業名・実在人名を使わない。 架空のメンバー名・プロジェクト名で構成する
• タスクのタイトルを「タスク1」のようなダミーにしない。 業種の世界観を持つ実在しそうなものにする（「A社向け提案書の作成」「請求書の発行（8月分）」）。タスク管理のデモはタイトルのリアリティがそのまま説得力になる
• 期限の分布に濃淡をつける。 今日・今週に集中し、来月は疎に。均等分布だとカレンダーが不自然
• 期限超過のタスクを作る（担当者によって数を変える）
• 停滞タスク（7日以上更新なし）を数件作る（FR-605 の実演用）
• 未割当のタスクを数件作る（チームボードの「未割当」列が空だと機能が死ぬ）
• 担当の偏りを作る。 1人に明らかにタスクが集中している状態（FR-604 の実演用）
• 依存関係を持つタスクを10組以上作る。 うち数組は前提が未完了のまま進行中（FR-405 の実演用）
• WIP上限を超えている列を1つ作る（FR-212 の実演用）
• サブタスクを持つタスクを2割程度作る。 進捗率が中途半端なものを含める
• 繰り返しから生成されたタスクを含める（generatedFromRecurrence: true）
• 模擬チャットに、タスク化しやすいメッセージを混ぜる（「〜までに〜お願いします」）。逆にタスクにならない雑談も混ぜる（全部がタスクだと嘘に見える）
• 日付は現在日時からの相対で生成する。固定日付を埋め込まない

ストアとリポジトリ

lib/
├── types/  seed/
├── parse/                      # ★ 自然文解析。純粋関数のみ
│   ├── quick-add.ts            # ★ 7章のコード参照
│   ├── date.ts                 # 相対日付の解決
│   ├── member.ts               # 氏名・別名のあいまい一致
│   └── recurrence.ts           # 「毎週月曜」等の解析
├── view/                       # ★ 3ビューへの射影。純粋関数のみ
│   ├── board.ts  list.ts  calendar.ts  timeline.ts
│   └── filter.ts               # 絞り込み・並び替え・グループ化
├── recur/                      # ★ 繰り返し生成。純粋関数のみ
│   ├── next.ts                 # 次回日付の算出
│   ├── generate.ts             # タスクの生成
│   └── holidays.ts             # 営業日判定
├── graph/                      # ★ 依存関係。純粋関数のみ
│   ├── cycle.ts                # 循環検出（FR-406）
│   ├── blocked.ts              # ブロック中の抽出（FR-407）
│   └── progress.ts             # サブタスクからの進捗率
├── metrics/                    # 負荷・リードタイム・完了率（純粋関数）
├── search/                     # 全文検索（純粋関数）
├── csv/  storage/  query/
├── store/  { session, data, settings, view, ui }
└── repo/                       # ★ コンポーネントが触るのはここだけ
    ├── _delay.ts
    ├── _scope.ts               # ★ データスコープ（SCP-01〜05）
    ├── tasks.ts  views.ts  projects.ts  statuses.ts  tags.ts
    ├── recurrences.ts  templates.ts  comments.ts
    ├── members.ts  metrics.ts  search.ts  mockChat.ts  logs.ts

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

• 全メソッドを async で定義する。中身が同期でも例外なく
• 戻り値は { ok: true; data: T } | { ok: false; error: string } に統一する
• コンポーネントから Zustand ストアを直接参照しない。 読み取りも書き込みもリポジトリ経由
• ビューへの射影を lib/view/ に集約する。 コンポーネントに status === 'doing' のような分岐を書かない（VIEW-02）
• 自然文解析を lib/parse/ に集約し、純粋関数とする（PRS-05）
• 繰り返し生成を lib/recur/ に集約し、純粋関数とする（FR-510）
• lib/parse/ lib/view/ lib/recur/ lib/graph/ lib/metrics/ lib/search/ は純粋関数のみ。 ストア・DOM に依存させず、new Date() を内部で呼ばない
• スコープ適用（_scope.ts）を全メソッドが必ず通す
• 非公開プロジェクトを、検索インデックスの構築段階で除外する（SCP-04, FR-313）
• 派生値（ビュー射影・進捗率・負荷・リードタイム）はストアに保存せず算出する
• タスクの追加・D&D・ビュー切替・絞り込みに擬似ディレイを入れない（FR-115, FR-204）
• D&Dは楽観的更新。 失敗時のみ元の位置に戻す（VIEW-06, FR-211）

8. デザイン要件

アートディレクション

「カードが主役。3つの見え方を、同じカードで往復する」

TSUMU の中心にあるのはカードである。ボードでは列に並び、カレンダーでは日付に置かれ、リストでは行になる。同じタスクが姿を変えて現れることが、このアプリの体験の核。

だから TSUMU のカードは厚みを持つ。角丸12px、わずかな影、掴んだときに持ち上がる。ドラッグの手触りが、このアプリの品質そのもの。

• カードに厚みを与える。 姉妹プロジェクトで唯一、影を積極的に使う
• 生成りの紙色。 付箋・カードの手触りを想起させる、わずかに黄みのある白
• 色は分類のためにある。 プロジェクト色とステータス色。ただしカードを色で埋め尽くさない（左端の帯のみ）
• ドラッグ中は物理的に。 3度傾き、影が濃くなり、置いた場所に吸い付く

姉妹プロジェクトとの差別化（最重要） RELATE / KURA / TOKIWA は「表を読ませる」ので影を使わない。TENKEN は「濃い地に巨大ボタン」。HIBI は「1カラムの文章」。 TSUMU だけがカードに影を落とし、掴んで動かすことを前提にしている。 配色も分ける：RELATE＝藍／ KURA＝ティール＋アンバー／ TOKIWA＝インディゴ＋コーラル／ HIBI＝墨＋若草／ TENKEN＝濃い地＋安全色／ TSUMU＝生成りの紙色＋インディゴ。

カラートークン

:root {
  /* 生成りの紙色。付箋・カードの手触り */
  --paper:      #F6F4EF;   /* ページ背景（ボードの地） */
  --card:       #FFFFFF;   /* カード */
  --card-alt:   #FCFBF8;   /* 列の背景 */
  --line:       #E4E0D6;   /* 罫線 */
  --line-soft:  #EFEBE2;

  --ink-900:    #1A1C21;   /* 見出し・本文 */
  --ink-600:    #565A63;   /* 補助テキスト */
  --ink-400:    #93979F;   /* ラベル・非活性 */

  --primary:    #3B4B9E;   /* 主要CTA・選択状態（インディゴ） */
  --primary-d:  #2C3A7D;
  --primary-50: #EAECF7;

  /* ★ 期限の状態。これ以外の色を期限に使わない */
  --due-overdue: #B23A32;   /* 期限超過 */
  --due-today:   #C07C1E;   /* 今日 */
  --due-soon:    #3B4B9E;   /* 3日以内 */
  --due-later:   #93979F;   /* それ以降（無彩色） */

  /* 優先度（★ 控えめに。左端の細い帯のみ） */
  --pri-urgent: #B23A32;
  --pri-high:   #C07C1E;
  --pri-normal: transparent;   /* ★ 通常は色を持たない */
  --pri-low:    #93979F;

  /* 状態 */
  --done:       #3F7A5C;
  --blocked:    #8A5A9E;   /* 依存でブロック中 */
  --stalled:    #C07C1E;   /* 停滞 */
  --wip-over:   #B23A32;   /* WIP上限超過 */

  /* ★ カードの影（姉妹プロジェクトで唯一、影を使う） */
  --shadow-card:  0 1px 2px rgba(26,28,33,.06), 0 1px 3px rgba(26,28,33,.04);
  --shadow-hover: 0 2px 6px rgba(26,28,33,.10);
  --shadow-drag:  0 12px 28px rgba(26,28,33,.22);   /* ★ 掴んだとき */
}

配色ルール

• カードを色で塗り分けない。 プロジェクト色・優先度は**左端の細い帯（3px）**でのみ表現する
• 通常の優先度は色を持たない（--pri-normal: transparent）。色がついているのは「急ぐもの」だけ
• 期限の色を4段階に固定する。 超過=赤／今日=琥珀／3日以内=インディゴ／それ以降=無彩色
• 完了したカードは彩度を落とし、打ち消し線を入れる。 消さずに残すが、目立たせない

タイポグラフィ

カードのタイトルは14px・行間1.6・2行クランプ。 ボードで一覧するときの可読性と、1列に収まる枚数のバランスがここで決まる。

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

主要コンポーネント仕様

インタラクション要件（ドラッグの手触りが命）

モーション

prefers-reduced-motion: reduce 時は、傾き・拡大・FLIPアニメーションを停止し、位置変化を即時にする。 ただしドロップ位置の挿入ラインは残す（操作の手がかりとして必要）。

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

ライティング規約

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

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

上記以外のライブラリを入れる前に必ず提案し、承認を得ること。特にカレンダーライブラリ、ガントライブラリ、日付解析ライブラリ、全文検索ライブラリの導入は禁止。

カレンダー・ガントを自前で書く理由： 既製ライブラリは自前のデータモデルを持っており、3ビュー同期（VIEW-01）と噛み合わない。さらにD&Dの挙動をライブラリ側に握られると、IX-01（60fps）とIX-05（キーボード代替）を保証できない。自前実装であることがこのデモの価値。

ディレクトリ構成

/
├── CLAUDE.md
├── app/
│   ├── layout.tsx                  # アプリシェル（サイドバー・ヘッダー・デモ切替バー・⌘K）
│   ├── page.tsx                    # SC-001 今日 / SC-900（?embed=1）
│   ├── board/  list/  calendar/  timeline/    # SC-010〜013
│   ├── tasks/[id]/                 # SC-020
│   ├── inbox/                      # SC-030, 031
│   ├── import/  search/  notifications/       # SC-032, 040, 041
│   ├── how-it-works/               # SC-050
│   ├── team/                       # SC-100〜103
│   ├── projects/                   # SC-110, 111
│   ├── admin/                      # SC-120〜160
│   └── dev/components/
├── components/
│   ├── card/                       # ★ 最重要
│   │   ├── TaskCard.tsx            # カード（左帯・タイトル・期限・担当・進捗）
│   │   ├── DragPreview.tsx         # ドラッグ中の見た目
│   │   ├── DropIndicator.tsx       # 挿入ライン
│   │   └── useCardDnd.ts           # dnd-kit のラッパー（キーボード対応込み）
│   ├── views/
│   │   ├── BoardView.tsx  BoardColumn.tsx
│   │   ├── ListView.tsx
│   │   ├── CalendarView.tsx  CalendarCell.tsx  UnscheduledPanel.tsx
│   │   ├── TimelineView.tsx  DependencyLines.tsx
│   │   └── ViewToolbar.tsx         # ★ ビュー切替 + 絞り込み（状態を維持）
│   ├── quick-add/                  # ★ QuickAddInput, ParseChips, SyntaxHint, AddSeconds
│   ├── task/                       # SubtaskList, DependencyPanel, CommentList, HistoryList
│   ├── team/                       # LoadChart, AttentionList, TeamBoard
│   ├── mock/                       # MockChatPanel（★ 模擬である旨の帯を含む）
│   ├── demo/                       # RoleSwitcher, ResetButton, GuideTour, BackToArticle
│   └── layout/
├── lib/
│   ├── types/ seed/ store/ repo/
│   ├── parse/                      # ★ 自然文解析。純粋関数
│   ├── view/                       # ★ 3ビュー射影。純粋関数
│   ├── recur/                      # ★ 繰り返し生成。純粋関数
│   ├── graph/                      # ★ 依存関係。純粋関数
│   ├── metrics/ search/ csv/ storage/ query/ validation/ utils/
├── docs/
│   └── build-or-buy-checklist.md   # 資料PDFの元原稿（自作判断シート）
├── e2e/
└── public/

コーディング規約

• TypeScript strict。any 禁止。やむを得ない場合は unknown + 型ガード
• ファイル名は kebab-case、コンポーネントは PascalCase
• 1ファイル300行を超えたら分割を検討する
• コンポーネントから Zustand ストアを直接参照しない。必ず lib/repo/ 経由
• ビューへの射影を lib/view/ に集約する。 コンポーネントにステータス判定を書かない（VIEW-02）
• lib/parse/ lib/view/ lib/recur/ lib/graph/ lib/metrics/ lib/search/ は純粋関数のみ。 ストア・DOM に依存させず、new Date() を内部で呼ばない
• D&D の状態を Zustand に持たせない。 dnd-kit のコンテキスト内で完結させ、確定時のみリポジトリを呼ぶ（60fps を守るため）
• ドラッグ中に再レンダリングを起こす state 更新をしない
• タスクの追加・D&D・ビュー切替に擬似ディレイを入れない
• 派生値（ビュー射影・進捗率・負荷・リードタイム）をストアに保存しない
• 非公開プロジェクトを、検索インデックスの構築段階で除外する（SCP-04）
• コミットは1タスクごと。メッセージに要件IDを含める 例：feat(parse): 相対日付「来週金曜」の解決を実装 (FR-103)

10. 非機能要件

セキュリティ・プライバシー

運用設計上の注意（この領域固有）

タスク管理システムは容易に監視ツールになる。 HIBI（日報）と同じ配慮が必要。

実案件への転用時の注意（デモ本体の要件ではない。商談で聞かれた際に説明できるよう記録）

① タスク管理は「入力される仕組み」とセットでないと死ぬ。 チャット連携・メール転送・テンプレート・繰り返し——入力の摩擦を下げる仕組みへの投資が、機能追加より効果が高い

② 既製ツールとの併用が現実解になることが多い。 「全社の標準ツールは既製、特定業務だけ自作」という構成は合理的。全部を置き換えようとしない

③ 移行時にデータの持ち出しやすさが問われる。 既製ツールから移すとき、逆に将来また移すとき。CSVエクスポートを最初から持たせておく

④ 非公開プロジェクトの権限設計は、実装前に確定させる。 人事・M&A・懲戒などの案件が混ざると、検索から漏れただけで事故になる

⑤ 通知の設計を誤ると、通知疲れで使われなくなる。 「全部通知する」から始めず、必要最小限から足していく

本デモはデータをサーバーに送信しないため、③④の義務は発生しない。「デモである」旨は画面上に常時明示する

11. 費用設計

記事の主題の半分は「費用」。この章は実装要件であると同時に、記事本文の原稿素材でもある。

タスク管理だけの特殊事情：無料で使える優れた既製品が山ほどある

他のどのテーマよりも、「作らない」選択肢が強い領域。無料枠で十分に使えるツールが複数ある。

だから、この記事で最初に答えるべきは「いくらか」ではなく——

「タスク管理システムを、そもそも自作する必要があるのか」

この問いに正直に答えることが、結果的に信頼を生む。 そして多くの場合、答えは「既製ツールを使うべき」になる。

まず、作らない選択肢を並べる

「既製ツールの無料枠から始めて、限界が来たら考える」が最も合理的なケースが多い。 記事にはこれを明記する。

自作が正当化される5つのケース

②③が、自作の最も現実的な動機。 「タスク管理ツールを作りたい」ではなく、**「うちの業務システムに、タスクの概念を足したい」**という形で来ることが多い。

逆に、①〜⑤のどれにも当てはまらないなら、既製ツールを使うべき。 機能数では絶対に勝てない。

記事に書くべき一文： 「タスク管理システムの自作は、既製ツールに勝つためではありません。既製ツールでは繋げないものを繋ぐためです。」

損益分岐の計算式

既製ツールの年間コスト
  = 月額単価 × 人数 × 12
  ( + オプション：ゲスト・自動化回数・ストレージ )

回収年数 = （開発費 + 運用設計費）÷（既製ツール年間コスト − 自作の年間運用費 − 年間保守費）

ただし②③のケースでは、この計算式が意味を持たない。 既製ツールでは実現できないことをやるのだから、**比較対象は「既製ツール」ではなく「二重入力を続けるコスト」**になる。

二重入力を続けるコスト
  = 1件あたりの転記時間 × 月間件数 × 12 × 時間単価 × 人数

この計算の方が、②③の案件では説得力がある。

最も見落とされる費用：機能追加の圧力

タスク管理は「あのツールのあの機能が欲しい」が最も出やすい領域。 そして——

• ガントチャートが欲しい
• 自動化ルールが欲しい
• ダッシュボードが欲しい
• モバイルアプリが欲しい
• AIで優先度を提案してほしい

これを1つずつ足していくと、既製ツールの劣化コピーになって、しかも保守費だけが積み上がる。

記事に書くべき一文： 「自作したタスク管理システムに機能を足したくなったら、それは既製ツールに戻るべきサインかもしれません。」

TSUMU が3章のスコープリスクで「既製ツールの機能を真似しない」を明記しているのは、この圧力に対する防波堤。 資料PDFの「自作判断シート」も、この会議のために作る。

AI連携は「あとで足す」でよい

「AIでタスクを自動分解したい」「優先度を提案してほしい」は必ず出る要望。だが——

特に速度が問題。 入力中のリアルタイム解析はAPIでは実現できない。ルールベースの方が、この用途では優れている。

Webで足りるか、ネイティブが必要か

タスク管理は、Webで足りる領域。ただしプッシュ通知が論点になる。

判断の目安： 期限通知を重視するなら、チャットツール・LINE公式アカウント・メールへの通知が現実的な代替（アプリ開発より圧倒的に安い）。タスク管理のためにネイティブアプリを作る必要はほぼない。

デモ自体の運用コストを実測して記事に載せる

12. 実装タスク

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

Phase 0 — 基盤と純粋ロジック（4日）

0-1. 初期化

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

0-2. lib/parse/（記事の技術パートの見せ場）

• date.ts：相対日付の解決（今日／明日／明後日／今週◯曜／来週◯曜／N日後／月末／M/D）(FR-103)
• member.ts：@名前 と氏名・別名のあいまい一致（FR-104）
• recurrence.ts：「毎週月曜」「毎月25日」「毎営業日」の解析（FR-107）
• quick-add.ts：統合（7章のコード参照）（FR-102, PRS-01〜06）
• 解析語をタイトルから取り除き、rawText を保持すること（FR-109）
• new Date() を内部で呼ばない。現在時刻は引数で受け取る
• 単体テストを網羅的に書く。以下を必ず含めること：
  • 「来週金曜」が正しい日付に解決されること（週の境界、月跨ぎ）
  • 「田中さん」でメンバーが解析されること（別名一致）
  • 解析できない文字列でも title が返ること（PRS-04・最重要）
  • 解析語がタイトルから取り除かれること
  • rawText からタイトルに戻せること（FR-109）
  • 複数の解析が同時に効くこと（期限 + 担当 + タグ）
  • 解析が 16ms以下で完了すること（NFR-05）

0-3. lib/view/ lib/recur/ lib/graph/（純粋関数）

• view/board.ts：ステータス別の列（7章のコード参照）(FR-201, FR-212)
• view/calendar.ts：日付別の配置 + 未スケジュールの抽出（FR-213）
• view/list.ts / view/timeline.ts
• view/filter.ts：絞り込み・並び替え・グループ化
• recur/next.ts：次回日付の算出（6種のルール）(FR-501)
• recur/holidays.ts：営業日判定（FR-508）
• recur/generate.ts：次回タスクの生成（FR-502, FR-510）
• graph/cycle.ts：依存の循環検出（FR-406）
• graph/blocked.ts：ブロック中の抽出（FR-407）
• graph/progress.ts：サブタスクからの進捗率（FR-402）
• 単体テストを網羅的に書く。以下を必ず含めること：
  • 同一の Task から3ビューが正しく射影されること（VIEW-01）
  • WIP上限の超過判定（FR-212）
  • 期限未設定のタスクがカレンダーの未スケジュールに入ること
  • 繰り返しの次回日付が6種すべて正しいこと（月末・うるう年・営業日の祝日跨ぎ）
  • 依存の循環が検出されること（3階層以上でも）
  • サブタスクの進捗率が正しいこと（0件のときに壊れないこと）

0-4. lib/metrics/ lib/search/

• metrics/load.ts：担当者別の負荷と平均からの偏差（FR-603, FR-604）
• metrics/attention.ts：期限超過・停滞・未割当・ブロック中（FR-605）
• metrics/leadtime.ts：リードタイム（個人別ランキングを作らない）(FR-711, FR-713)
• search/：転置インデックス + 日本語正規化 + ハイライト
• search/index.ts で、非公開プロジェクトをインデックス構築段階から除外すること（SCP-04, FR-313）
• 単体テストを書く。特に非公開プロジェクトが検索に出ないこと

0-5. 型とシード

• lib/types/ に7章の型定義をすべて実装
• lib/seed/ の全ファイル
• タスクのタイトルを、業種の世界観を持つ実在しそうなものにする。ダミー文を1件も残さない（最重要）
• メンバーに別名を持たせる（「田中さん」で解析できるように）
• 非公開プロジェクトを2件、期限超過・停滞・未割当・担当の偏りを作る
• 依存関係を10組以上、うち数組は前提が未完了のまま進行中
• WIP上限を超えている列を1つ作る
• 模擬チャットに、タスク化しやすいメッセージと雑談を混在させる
• 期限の分布に濃淡（今日・今週に集中、来月は疎）
• 日付は現在日時からの相対で生成する

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

• lib/store/{session,data,settings,view,ui}.ts を Zustand + persist で実装
• lib/repo/_scope.ts を最初に実装する（SCP-01〜05）
• lib/repo/ の全モジュール。全メソッド async、Result型、スコープ適用
• スコープの単体テストをこの時点で書く：
  • 担当者が未所属プロジェクトのタスクを取得できないこと（SCP-03）
  • 非公開プロジェクトが、検索を含むあらゆる経路で返らないこと（SCP-04, SEC-07）
  • 見積時間が権限なしで返らないこと（SCP-05）
• 追加・D&D・ビュー切替に擬似ディレイを入れない

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

• app/globals.css にカラートークンを CSS 変数で定義（カードの影3段階を含む）
• tailwind.config.ts から CSS 変数を参照するよう theme を拡張
• フォント（Noto Sans JP / Roboto Mono）を next/font で最適化。期限・件数に tabular-nums
• shadcn/ui を導入し、トークンに合わせて上書き
• アプリシェル（サイドバー折りたたみ、ヘッダー）
• TaskCard.tsx：左帯・タイトル2行クランプ・期限の色分け・担当・進捗バー（8章）
• カードに aria-label（内容の要約）を持たせる（A11Y-05）
• 共通コンポーネント：EmptyState（2種の出し分け）／Skeleton（カード形状・列の高さを確保）
• prefers-reduced-motion の対応（挿入ラインは残す）
• /dev/components にコンポーネントカタログを作成

0-8. デモ基盤

• RoleSwitcher（3ロール + 担当者の3ペルソナ選択）(FR-806)
• デモ切替バー（濃い墨色の帯）+ 「これはデモです。タスクの内容は送信されません」（SEC-02）
• 「デモをリセット」(FR-810)／ロール権限外アクセス時の案内画面（FR-813）
• 元記事リンク・資料ダウンロード（FR-815）

Phase 0 完了チェック

• lib/parse/ lib/view/ lib/recur/ lib/graph/ のテストが全パターン通る
• 「解析できなくても title が返る」がテストで検証済み
• 「同一 Task から3ビューが正しく射影される」がテストで検証済み
• 「非公開プロジェクトが検索に出ない」がテストで検証済み
• 自然文解析が16ms以下
• /dev/components でカードが全パターン正しく表示される

Phase 1 — 入力体験（3日）

• QuickAddInput.tsx：1行入力、Enter で確定、確認ダイアログなし（FR-101）
• ParseChips.tsx：打っている最中に解析チップを表示（FR-108, PRS-02）
• チップの × で解析を取り消し、タイトルに戻す（FR-109, PRS-03）
• SyntaxHint.tsx：記法のヒントを入力欄の直下に常時表示（FR-111, PRS-06）
• 解析できなくても必ず追加できること（FR-110）
• aria-live での解析結果の通知（A11Y-10）
• AddSeconds.tsx：追加秒数を控えめに表示、3秒で消える（FR-112）
• 追加が100ms以下で、その場にカードが現れること（FR-115, NFR-02）
• ⌘K コマンドパレット（cmdk）から追加。画面遷移しない（FR-113）
• 「新しいタスク：〜」が常に先頭候補になること
• 改行区切りの一括追加（FR-114）
• SC-023 詳細フォームでの追加（FR-116）
• SC-024 テンプレートからの追加：起点日の指定、日付の再計算、依存の生成（FR-117, FR-118）
• SC-032 CSVインポート（数式インジェクションの無害化）(FR-119, FR-120, SEC-05)
• ショートカット（N 新規、/ 検索、? 一覧）(IX-08)

Phase 1 完了チェック

• 1行入力で期限・担当・タグが解析され、チップで見える
• 解析を取り消してタイトルに戻せる
• 解析できない入力でも追加できる
• 追加が100ms以下、解析が16ms以下

Phase 2 — 3ビューとD&D（5日・最重要フェーズ）

2-1. カードとD&D基盤

• useCardDnd.ts：dnd-kit のラッパー（キーボード対応込み）
• DragPreview.tsx：3度傾き + --shadow-drag + 拡大1.02（8章）
• DropIndicator.tsx：挿入位置に2pxのライン（IX-03）
• ドラッグ開始判定は移動距離5px（IX-02）
• 端に近づいたときの自動スクロール（IX-04）
• キーボードでのD&D（Space 掴む → 矢印 → Space 置く → Esc 取消）(IX-05, A11Y-03)
• 移動を aria-live で通知（A11Y-09）
• D&D の状態を Zustand に持たせない。ドラッグ中に再レンダリングを起こさない（9章）
• 60fps を実測（NFR-01, IX-01）

2-2. 3ビュー

• BoardView.tsx / BoardColumn.tsx：列幅280px、件数・WIP上限、横スクロール（FR-206, FR-212）
• ListView.tsx：TanStack Table ヘッドレス + 自前UI、仮想スクロール（FR-314）
• 列カスタマイズ・グループ化（FR-307, FR-308）
• CalendarView.tsx：月／週、日付へのD&Dで期限変更（FR-207, FR-214）
• UnscheduledPanel.tsx：期限未設定のサイドバー、日付にドラッグ（FR-213）
• TimelineView.tsx + DependencyLines.tsx：横棒と依存の線（FR-215, FR-216）
• ViewToolbar.tsx：ビュー切替 + 絞り込み。切り替えても絞り込みが維持されること（FR-203, VIEW-03）
• ビュー切替が100ms以下。データを取り直さない（FR-204, NFR-03）
• どのビューからでも期限変更・担当変更・完了ができること（FR-205, VIEW-05）
• リストで期限を変えるとカレンダーに反映されること（FR-208）
• 楽観的更新とロールバック（FR-211）
• SC-001 今日（自分の今日やること）(F-V05)

2-3. 絞り込みと保存ビュー

• 絞り込み条件（FR-301）／URLクエリ同期（FR-302）／チップ表示（FR-303）
• 保存ビュー：絞り込み + ビュー種別 + グループ化 + 表示列（FR-304）
• サイドバーに一覧、件数バッジ、個人／共有の区別（FR-305, FR-306）
• 一括操作 + 確認ダイアログ（FR-309, FR-310）
• SC-040 検索（ハイライト、100ms以下）(FR-311, FR-312)

2-4. 埋め込みモード

• SC-900 埋め込みモード：クイック追加 + 3列の小ボード（FR-817, EMB-04〜08）
• サンプル入力例3つをタップで入力欄に（EMB-06）
• 追加秒数の表示（EMB-05）／カードのD&D（EMB-07）
• アプリ内遷移をしない（EMB-08）
• 初期バンドル 65KB以下を実測（NFR-13）

Phase 2 完了チェック

• フローAが完走する（埋め込みで追加 → D&D → 全画面 → 3ビュー往復）
• ドラッグが60fpsを維持し、引っかからない
• リストで期限を変えるとカレンダーが変わる。カレンダーで動かすとリストが変わる
• ビューを切り替えても絞り込みが維持される
• キーボードだけでカードを移動できる
• カードを100回ドラッグしてもメモリが単調増加しない

Phase 3 — タスクの中身・繰り返し・依存（4日）

3-1. タスク詳細

• SC-020 タスク詳細（全項目）(FR-401)
• サブタスク（チェックリスト）+ 親の進捗率への反映（FR-402）
• サブタスクの並び替え（キーボード対応）(FR-403)
• 依存関係の設定 + 循環の検出（FR-404, FR-406）
• 前提未完了での着手時に警告。ブロックはしない（FR-405）
• コメント + メンション（FR-408）
• 添付ファイル（IndexedDB、Canvas で圧縮）(FR-409)
• 完了を1タップ + 5秒の「元に戻す」（FR-410, IX-10）
• 見積／実績時間（必須にしない）(FR-411, ETH-04)
• 変更履歴（FR-412）／複製（FR-413）／削除 + 取り消し（FR-414）
• カード上のショートカット（E Space Del）(IX-09)

3-2. 繰り返し

• 繰り返しルールの設定UI（6種）(FR-501)
• 完了時／期日到来時の次回生成（FR-502）
• 生成をトーストで通知（FR-503）
• 終了条件（FR-504）
• SC-120 繰り返しタスクの管理：一覧、次回生成日、停止・再開（FR-505, FR-506）
• 停止しても過去に生成されたタスクは消えないこと（FR-506）
• 生成履歴（FR-507）／サブタスクのテンプレート（FR-509）

3-3. テンプレートと取り込み

• SC-121 テンプレート管理（相対日付・担当・依存）(FR-707)
• プレビューで起点日を変えると日付が再計算されること（FR-708）
• SC-030 模擬チャット：「タスクにする」で自然文解析 + 確認モーダル（FR-801, FR-802）
• 元メッセージへの参照を残すこと（FR-803）
• 模擬である旨の帯を常時表示（FR-804, IMP-03）
• SC-031 模擬メール
• SC-050 仕組みの解説（3ビュー同期・自然文解析・実連携の方式と費用感）（FR-805, IMP-04）

Phase 3 完了チェック

• フローBが完走する（模擬チャット → タスク化 → 元メッセージへの参照）
• フローCが完走する（テンプレートから5タスク + 依存 → 依存の警告 → 繰り返しの自動生成）
• 4章「ロールを跨ぐ体験」の5と6が動作する
• 繰り返しを停止しても過去分が消えない

Phase 4 — チーム管理と設定（3日）

4-1. チーム

• SC-100 チームボード：担当者別の列 + 未割当の列（FR-601）
• 担当者列間のD&Dで振り替え（FR-602）
• SC-101 負荷の可視化：タスク数・期限超過・見積合計、平均線と偏りの強調（FR-603, FR-604）
• 文言を「偏りを直すため」にすること（ETH-02）
• SC-102 要対応の抽出：期限超過／停滞／未割当／ブロック中（FR-605）
• 停滞の文言を非難にしないこと（ETH-03）
• 停滞日数の設定（FR-606）
• SC-103 チームの今日（FR-610）
• SC-110 / SC-111 プロジェクト（進捗率、非公開プロジェクト）(FR-607, FR-608)

4-2. 設定・分析

• SC-130 ステータス管理：追加・削除・並び替え・色・WIP上限（FR-701, FR-702）
• 完了扱いの指定（FR-703）
• 変更がボードと全タスクに即座に反映されること（FR-704）
• 削除時に移動先を指定させること（FR-705）
• SC-131 タグ・優先度マスタ（使用件数・未使用の検出）(FR-706)
• SC-140 メンバー・権限管理（FR-709）
• SC-150 完了率・リードタイム分析。個人別ランキングを作らない（FR-710〜713, ETH-01）
• SC-151 通知設定（FR-714）／SC-041 通知センター
• SC-160 CSVエクスポート（FR-715）

Phase 4 完了チェック

• 4章「ロールを跨ぐ体験」の1・2・7・8が動作する
• ステータス列を追加すると、担当者側のボードに即座に反映される
• 個人別ランキングがどの画面にも存在しない
• 負荷の偏りが可視化され、その場で振り替えられる

Phase 5 — 記事統合・仕上げ（3日）

5-1. 記事統合

• 記事側の埋め込みコードを作成し、実際の記事ページで動作確認（EMB-01〜08）
• 埋め込みで「実際に追加できて、解析チップが出て、秒数が出る」ことを複数ブラウザで確認
• 記事の Core Web Vitals を埋め込み前後で比較検証
• 「全画面で試す」カードの設置
• 資料PDF（自作判断シート・損益分岐計算シート）の作成とダウンロード導線
• 元記事リンク・問い合わせ導線
• GA4 イベント設定。add_seconds と parse_hit を必ず含める（EMB-09, EMB-10）
• GA4 にタスクの内容を送っていないことを確認（EMB-11, SEC-03）
• ?embed=1 を noindex に、デモ本体の title / description / OGP（EMB-12）

5-2. 体験の総点検

• 4章「ロールを跨ぐ体験」の8パターンをすべて手動で確認
• 全30画面を開き、空の画面が1つもないことを確認
• タスクのタイトルにダミー文が1件も残っていないことを確認
• 空状態（データ0件／絞り込み0件）の出し分けを確認
• ETH-01〜05 の倫理要件をすべて確認（個人別ランキングがない、非難の文言がない、見積が必須でない）
• PWA / オフライン起動（F-C08）
• ガイドツアーを実装（FR-816）

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

• axe-core を全画面に実行し、Critical / Serious を0件に
• キーボードだけでD&Dが完遂できることを確認（A11Y-03）
• カードのアクセシブルな名前が内容を要約していることを確認（A11Y-05）
• 期限・優先度・ステータスが色のみで伝えられていないことを確認（A11Y-06, A11Y-07）
• スクリーンリーダーでカードの移動と解析結果が読み上げられることを確認
• カレンダーが表としても読めることを確認（A11Y-14）
• フォントサイズ200%での確認（A11Y-15）

5-4. パフォーマンス

• グラフ・CSVを動的import に切り出し、初期バンドルを230KB以下に（NFR-14）
• ドラッグの60fps、追加100ms、ビュー切替100ms、解析16msを実測（NFR-01〜05）
• ボード300枚・カレンダー400枚の描画300ms以下を実測（NFR-07, NFR-08）
• カード100回ドラッグでのメモリ推移を計測（NFR-17）
• Lighthouse で Performance 92 / Accessibility 95（NFR-15）

5-5. 公開と記録

• Playwright で フローA・B・C の E2E（D&Dはキーボード操作で決定的に）
• Vitest：lib/parse lib/view lib/recur lib/graph _scope のカバレッジ85%以上
• /dev/components を本番で非公開に
• Vercel へデプロイ
• add_seconds の分布と parse_hit の内訳の記録を開始（COST-01〜03）
• 解説動画（3分）の収録：1行で追加 → 解析チップ → ボードにカード → カレンダーへ切替 → D&Dで期限変更 → リストで確認 → チャットからタスク化 → 繰り返しの自動生成
• 各フェーズのキャプチャを整理し、記事の「方法」パートの素材にまとめる

合計 22営業日（約4.5週間）／1名専任 + レビュー体制。

工数配分の意図： Phase 2（3ビューとD&D）に5日を割いているのは、このアプリの品質がドラッグの手触りに集約されているから。カクついた瞬間に「作りかけ」に見える。既製のカレンダー・ガントライブラリを使わないと決めた以上、ここに時間を使う。 Phase 0 に4日を割いているのは、lib/parse/ と lib/view/ が全画面に波及するため。特に自然文解析は境界条件（週跨ぎ・月跨ぎ・うるう年）が多く、テストで固めないと後から追えないバグになる。

13. 受入基準

1. 6章の優先度 P1 の要件がすべて実装され、テストで合格していること
2. 5章の主要フローA・B・Cが、エンドツーエンドで完走すること
3. 4章「ロールを跨ぐ体験」の8パターンがすべて動作すること
4. 1行入力から期限・担当・タグが解析され、チップで表示されること
5. チップの × で解析を取り消し、その語がタイトルに戻ること
6. 解析できない入力でも必ずタスクを追加できること
7. 自然文解析が16ms以下で、入力を妨げないこと
8. タスクの追加が100ms以下で、その場にカードが現れること
9. ⌘K からどの画面でもタスクを追加でき、画面遷移しないこと
10. ボード・リスト・カレンダーが同一の Task を射影しており、ビューごとに別データを持っていないこと
11. リストで期限を変更すると、カレンダーとボードに即座に反映されること
12. カレンダーでD&Dすると、リストの期限が変わること
13. ビューを切り替えても絞り込み条件が維持されること
14. ビュー切替が100ms以下で、データを取り直していないこと
15. どのビューからでも、期限変更・担当変更・完了ができること
16. ドラッグ中のフレームレートが60fpsを維持すること
17. D&Dがキーボードだけで完遂でき、移動が読み上げられること
18. WIP上限を超えた列が警告表示されること
19. 繰り返しタスクを完了すると次回分が自動生成され、トーストで通知されること
20. 繰り返しを停止しても、過去に生成されたタスクが消えないこと
21. 依存の循環が検出され、設定できないこと
22. 前提が未完了のまま着手しようとすると警告が出るが、ブロックされないこと
23. テンプレートから複数タスクが依存関係付きで生成され、起点日で日付が再計算されること
24. 模擬チャットからタスクを生成でき、元メッセージへの参照が残ること。模擬である旨が明示されていること
25. ステータス列を追加・削除すると、ボードと全タスクに即座に反映されること。削除時に移動先を指定させること
26. 非公開プロジェクトのタスクが、検索を含むあらゆる経路でメンバー以外に返らないこと
27. 担当者が未所属プロジェクトのタスクを取得できないこと
28. 完了数・リードタイムの個人別ランキングが、どの画面にも存在しないこと
29. 見積時間・実績時間の入力が必須になっていないこと
30. タスクのタイトルにダミー文が1件も存在しないこと
31. タスクの内容が外部に一切送信されていないこと（DevTools と GA4 のイベントで確認）
32. 全30画面のいずれにも空の状態がなく、リアルなデータが表示されていること
33. カードを100回ドラッグしてもメモリが単調増加しないこと
34. 初期バンドルが230KB以下、Lighthouse Performance 92以上であること
35. axe-core で Critical / Serious の指摘が0件であること
36. データアクセスがすべて lib/repo/ を経由し、ビュー射影が lib/view/ に集約されていること
37. 姉妹プロジェクトと並べたときに、明確に別のプロダクトとして見えること（カードの影とドラッグの手触りが効いていること）

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

1. 仕様がこの文書にない場合は、実装せずに質問する。 推測で作らない
2. 既製ツールの機能を真似しない。 自作の理由（1章・11章）に紐づかない機能は実装しない。これがこのプロジェクトで最も重要なルール
3. ドラッグの手触りを最優先する。 60fpsを守れないなら実装を見直す。カクついた瞬間に全部が安っぽく見える
4. 3ビューは同一データの射影。 ビューごとに別データを持たない。射影は lib/view/ に集約する
5. どのビューからでも同じ操作ができること。 ビューによってできることが変わらない
6. 解析は「おまけ」。 賢く解析しようとして入力を妨げない。解析できなくても必ず追加できる
7. AIを呼ばない。 自然文解析はルールベース。入力中のリアルタイム解析はAPIでは実現できない
8. 既製のカレンダー・ガント・日付解析・全文検索ライブラリを入れない。 自前実装であることがこのデモの価値
9. 非公開プロジェクトを、検索インデックスの段階で除外する。 「検索したら見えた」は致命的な事故
10. 完了数・リードタイムで人を評価させない。 個人別ランキングを作らない（ETH-01）
11. 負荷の可視化を「働いていない人を見つける」ために使わせない。 文言で示す（ETH-02）
12. 見積時間の入力を必須にしない。 強制すると数字が嘘になる（ETH-04）
13. 依存の警告でブロックしない。 現実には並行して進むこともある
14. タスクのタイトルにダミー文を残さない。 タスク管理のデモはタイトルのリアリティが説得力になる
15. スコープ外（3章 Won't have）は実装しない。特にAI分解・リアルタイム共同編集・工数原価は範囲外
16. 「デモだから」を理由に品質を落とす判断はしない
17. 姉妹プロジェクトのトークン・コンポーネントをコピーしない。 TSUMU だけがカードに影を落とす