設計書 & ロードマップ

📋 目次

0. 戦略転換と決定経緯 (2026-05-09 礒貝CEO 決裁)

当初は「LocalStorage プロトタイプ → Notion バックエンドに本番移行」というプランで進めていましたが、世界 78カ国マルチテナント展開・課金・SOC2 までを見据えた結果、自前 SaaS として AWS 上で育てる 方針に転換しました。

検討した 3 パターン

1. 5 フェーズ・ロードマップ

2. 確定アーキテクチャ

3. データモデル (6 テーブル + tenants)

マスター系 2 (employees / projects) + トランザクション系 4 (tasks / daily_reports / time_blocks / leave_requests)。全テーブルに tenant_id (UUID) を Phase 3 で追加し、Postgres Row Level Security で会社単位完全分離します。

4. マルチテナント設計 (Phase 3)

「他社にも貸せる」状態を Phase 3 で達成。tenants テーブル新設 + 全テーブルに tenant_id + Postgres Row Level Security で会社単位完全分離します。tenant_id を後付けで足すと地獄になるため、データモデルの初期段階から織り込み済み。

tenants テーブル(新設)

RLS ポリシーの基本パターン

JWT クレームから tenant_id を取り出し、API ミドルウェア(Edge Function or Lambda)で Postgres セッション変数に設定 → RLS が自動でフィルタする。

-- API リクエスト先頭で実行(JWT から取り出した tenant_id を埋め込む)
SET app.tenant_id = '550e8400-e29b-41d4-a716-446655440000';

-- 各テーブルで RLS を有効化 + ポリシー設定
ALTER TABLE employees ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation_employees ON employees
  USING (tenant_id = current_setting('app.tenant_id', true)::uuid);

-- 結果: 以降の SELECT/UPDATE/DELETE は自動的に
-- WHERE tenant_id = '550e8400-...' でフィルタされる

5. 権限設計

role_level (1/2/3) を employees テーブルに保持。アプリ層 + API 層の両方で検証。RLS だけでは「自分のデータのみ」までしか守れないので、「LV.MIDDLE は他人の電話番号も見える」のような細かい制御は API 層(認可ミドルウェア)で実装します。

6. Postgres DDL (実装用 / Phase 2 Supabase で初期投入)

以下の DDL を Supabase SQL Editor で実行すれば Phase 2 のスキーマが構築されます。Phase 4 で Aurora Serverless v2 に移行する際も pg_dump でそのまま持ち込めます。

-- ===== 拡張機能 =====
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "citext";

-- ===== tenants =====
CREATE TABLE tenants (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  plan TEXT NOT NULL DEFAULT 'free' CHECK (plan IN ('free','starter','business','enterprise')),
  settings JSONB NOT NULL DEFAULT '{}'::jsonb,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- ===== employees =====
CREATE TABLE employees (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  name TEXT NOT NULL,
  kana TEXT,
  role TEXT NOT NULL,
  dept TEXT,
  email CITEXT NOT NULL,
  gmail CITEXT,
  joined_at DATE,
  status TEXT NOT NULL DEFAULT 'active' CHECK (status IN ('active','leave','retired')),
  color TEXT,
  role_level SMALLINT NOT NULL DEFAULT 3 CHECK (role_level IN (1,2,3)),
  cognito_sub TEXT,
  google_calendar_id TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  UNIQUE (tenant_id, email)
);
CREATE INDEX idx_employees_tenant ON employees(tenant_id);

-- ===== projects =====
CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  name TEXT NOT NULL,
  status TEXT NOT NULL DEFAULT 'active' CHECK (status IN ('idea','active','paused','done')),
  lead_emp_id UUID REFERENCES employees(id),
  starts_on DATE,
  due_on DATE,
  color TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- ===== tasks =====
CREATE TABLE tasks (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  title TEXT NOT NULL,
  assignee_emp_id UUID REFERENCES employees(id),
  project_id UUID REFERENCES projects(id),
  priority TEXT NOT NULL DEFAULT 'mid' CHECK (priority IN ('high','mid','low')),
  status TEXT NOT NULL DEFAULT 'todo' CHECK (status IN ('todo','doing','done','blocked')),
  due_start DATE,
  due_at DATE,
  start_time TIME,
  end_time TIME,
  effort_h NUMERIC(5,2),
  progress SMALLINT NOT NULL DEFAULT 0 CHECK (progress BETWEEN 0 AND 100),
  parent_task_id UUID REFERENCES tasks(id),
  related_report_id UUID,
  assigned_by_emp_id UUID REFERENCES employees(id),
  acknowledged_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_tasks_tenant_assignee ON tasks(tenant_id, assignee_emp_id);
CREATE INDEX idx_tasks_due ON tasks(tenant_id, due_at);

-- ===== daily_reports =====
CREATE TABLE daily_reports (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  emp_id UUID NOT NULL REFERENCES employees(id) ON DELETE CASCADE,
  report_date DATE NOT NULL,
  done_today TEXT,
  do_tomorrow TEXT,
  blockers TEXT,
  mood SMALLINT CHECK (mood BETWEEN 1 AND 5),
  submitted_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  UNIQUE (tenant_id, emp_id, report_date)
);
CREATE INDEX idx_reports_date ON daily_reports(tenant_id, report_date);

-- ===== time_blocks =====
CREATE TABLE time_blocks (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  emp_id UUID NOT NULL REFERENCES employees(id) ON DELETE CASCADE,
  title TEXT NOT NULL,
  block_date DATE NOT NULL,
  starts_at TIME NOT NULL,
  ends_at TIME NOT NULL,
  description TEXT,
  project_id UUID REFERENCES projects(id),
  kind TEXT CHECK (kind IN ('work','meeting','travel','break','focus')),
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_blocks_emp_date ON time_blocks(tenant_id, emp_id, block_date);

-- ===== leave_requests =====
CREATE TABLE leave_requests (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
  applicant_emp_id UUID NOT NULL REFERENCES employees(id) ON DELETE CASCADE,
  starts_on DATE NOT NULL,
  ends_on DATE NOT NULL,
  kind TEXT NOT NULL CHECK (kind IN ('paid','sick','special','condolence')),
  reason TEXT,
  status TEXT NOT NULL DEFAULT 'pending' CHECK (status IN ('pending','approved','rejected')),
  approver_emp_id UUID REFERENCES employees(id),
  decided_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_leaves_status ON leave_requests(tenant_id, status);

-- ===== Row Level Security =====
ALTER TABLE employees ENABLE ROW LEVEL SECURITY;
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
ALTER TABLE tasks ENABLE ROW LEVEL SECURITY;
ALTER TABLE daily_reports ENABLE ROW LEVEL SECURITY;
ALTER TABLE time_blocks ENABLE ROW LEVEL SECURITY;
ALTER TABLE leave_requests ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_iso_employees      ON employees      USING (tenant_id = current_setting('app.tenant_id', true)::uuid);
CREATE POLICY tenant_iso_projects       ON projects       USING (tenant_id = current_setting('app.tenant_id', true)::uuid);
CREATE POLICY tenant_iso_tasks          ON tasks          USING (tenant_id = current_setting('app.tenant_id', true)::uuid);
CREATE POLICY tenant_iso_daily_reports  ON daily_reports  USING (tenant_id = current_setting('app.tenant_id', true)::uuid);
CREATE POLICY tenant_iso_time_blocks    ON time_blocks    USING (tenant_id = current_setting('app.tenant_id', true)::uuid);
CREATE POLICY tenant_iso_leave_requests ON leave_requests USING (tenant_id = current_setting('app.tenant_id', true)::uuid);

-- ===== シードデータ(GANECCI テナント)=====
INSERT INTO tenants (id, name, plan)
  VALUES ('00000000-0000-0000-0000-00000000ga01', '株式会社GANECCI', 'enterprise');
-- 以降、employees / projects / etc. に上記 tenant_id を入れて投入

7. 移行手順 (LocalStorage → Supabase → Aurora)

1. Phase 2: Supabase プロジェクト作成 + DDL 実行
   supabase.com で新規プロジェクト → SQL Editor で上記 DDL を流し込む。10分作業。
2. Auth 連携
   Supabase Auth に Google を Provider として追加。signInWithOAuth({ provider: 'google' }) で動く。
   新規ユーザー登録時に employees 行を upsert するトリガーを設定(auth.users → employees マッピング)。
3. app.js のデータ層を Supabase Client に置き換え
   現状: localStorage ↔ loadData() / saveData()
   新規: supabase.from('tasks').select('*') ベースに置換。
   関数シグネチャは温存しつつ実装だけ差し替えるため UI 変更は不要。
4. 初期データ投入(GANECCI 10名 + 6プロジェクト)
   本ひな形 app.js の STAFF / PROJECTS 配列に対応するレコードを INSERT。tenant_id は GANECCI テナントの UUID。
5. Phase 3: tenant_id を JWT クレームに埋め込む
   Supabase Auth Hook(または DB トリガー)で、ログイン時に auth.users.raw_app_meta_data.tenant_id を JWT に追加。RLS が自動で動き出す。
6. Phase 4: AWS CDK で Aurora Serverless v2 + Cognito + Lambda 構築
   Supabase からダンプを取り Aurora に流し込む。Cognito User Pool に Google IdP を追加して JWT クレーム互換にする。
7. Phase 5: Stripe 課金 + SOC2 準備 + マーケサイト
   tenants.plan に応じた機能制限。SOC2 Type 1 監査受審。

8. Google Workspace / Google カレンダー連携

8-1. ID 基盤を Google アカウントに統一

• 各テナントは社用ドメイン(GANECCI なら @ganecci.net)の Workspace アカウントでログイン
• 個人 Gmail でも認証可(employees.gmail でマッチング)
• 当アプリ・Slack・Drive など全てのサービスがこの ID で SSO
• 退職時は Workspace で停止すれば全システムから一括ロックアウト

8-2. Google カレンダーを「真のスケジュール台帳」とする

本アプリの time_blocks はアプリ内で作成するタイムブロック専用。個人の予定は Google Calendar API で取得して 「Google カレンダー = 1次ソース」「アプリ DB = 集計・分析レイヤー」 の役割分担にします。

8-3. 当アプリでの取り込み

Google Calendar API で取得したイベントを当アプリ UI に統合表示。実装は google-auth.js の fetchCalendarEvents(calendarId) / fetchManyCalendars(ids):

• 従業員ポータル: 「🔄 Googleカレンダーから取り込む」ボタンで本人分を取得 → 月間カレンダー・タイムラインに反映
• 管理ダッシュボード: 「🔄 全員のGoogleカレンダーを取り込む」で 10 名分を一括取得 → 各メンバーカードに「Google 予定 (今日)」セクションが表示
• すべて当アプリ内 UI で完結 (iframe 埋め込みなし)

8-4. 招待・共有フロー

詳細手順は 📧 招待・参加フロー を参照。

• ケース A: ganecci.net Workspace アカウント発行 (推奨)
• ケース B: 個人 Gmail で招待 (業務委託向け)
• カレンダー共有設定の手順
• OAuth Client ID 取得手順