$0・14日・ソースコード100%譲渡 — フルプロダクション製品を14日で出荷するための5つのエンジニアリング判断

25-4.png

TL;DR

Fluxez では、創業者の 最初のプロジェクトを $0 で、14日 で、ソースコード100% を顧客のGitHubに譲渡する形
で出荷しています。MVPでもプロトタイプでもなく、認証・課金・ダッシュボード・モバイルUI・テスト・デプロイすべて揃ったフルプロダクション製品です。

これはマーケティング記事ではなく、エンジニアリング記事です。$0 / 14日 / 100%譲渡 を技術的に成立させている5つの設計判断
を解説します。どれか1つでも欠けるとモデル全体が崩壊する、という構造を持っています。

---

制約のスタック

3つのトップレベル制約が、コードの1行1行を支配しています。

制約	強制されること
$0	営業・スコープ調整・プリセールスに使える工数はゼロ
14日	直接的な価値提供以外の工数はゼロ
100%譲渡	デリバラブルの中にプロプライエタリなコードを含められない

3つともビジネス上の決断に見えますが、実際にはエンジニアリングの判断に直接降りてきます。

---

判断 1: Day 0 のスキーマロック — 14日 が強制する

伝統的なエージェンシーでは、データモデルはプロジェクト中に進化します。スプリント1でスキーマを切り、スプリント3でリファクタし、スプリント5でプロ
ダクションデータをバックフィルする。これは6ヶ月のタイムラインでは動きますが、14日では絶対に動きません。

なので、Day 0 にスキーマをロックします。コードを1行も書く前です。

-- Day 0 の成果物: 完成したスキーマとマイグレーション
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email CITEXT UNIQUE NOT NULL,
  hashed_password TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE workspaces (...);
CREATE TABLE memberships (...);
CREATE TABLE billing_accounts (...);
-- すべて1パスで

なぜ Day 0 か。それ以降のすべての決定 — APIコントラクト、ORMモデル、型生成、シードデータ、結合テスト — はスキーマに依存している からです。Day 7
 にスキーマが動くと、最低2日分のやり直しが発生します。14日予算の14%が消えます。

強制しているのは規律ではありません。カレンダーです。

---
判断 2: AI は機械的作業、人間は判断的作業 — 14日 が強制する

シニアエンジニア + モダンなAIツール の組み合わせは、3年前と比較して 約4〜6倍速く出荷できる
ようになりました。社内で約100プロジェクトを通して計測した実測値です。ただし、この高速化は均一に分布していません。

機械的な作業は速くなります:
- ボイラープレート
- 型定義
- スキャフォールディング(コントローラ・ルート・サービス)
- CRUD ハンドラ
- 基本的なユニットテスト
- マイグレーションファイル
- シードデータ

判断的な作業は、相変わらず以前と同じ速度です:
- スキーマ設計
- 認証モデル
- 権限境界
- セキュリティレビュー
- 障害モード設計
- パフォーマンスエッジケース

なので、デリバリーモデルをこの分離に合わせて構築しました。AIが機械的作業を生成し、シニアエンジニアがレビューして受け入れ、人間の時間は判断的作
業に使う。

Day 1-2:   スキーマ・認証・セキュリティ設計 (シニア、AI不使用)
Day 3-7:   スキャフォールド・CRUD・型 (AI生成、エンジニアレビュー)
Day 8-10:  ビジネスロジック・エッジケース (シニア、AI支援)
Day 11:    パフォーマンス・セキュリティパス (シニア、AI不使用)
Day 12:    QAフリーズ、新機能追加なし
Day 13-14: 仕上げと出荷

この分離を逆にする — 人間が退屈な作業をやって、AIに判断的な作業をやらせる — と、モデルは Day 4 で崩壊します。

---
判断 3: バニラスタックのみ — 100%譲渡 が強制する

Day 14 に コードの100%が顧客のGitHubに移る のなら、自社製のプロプライエタリなフレームワークに依存したものは1つも出荷できません。
出荷した瞬間に「譲渡」は嘘になります。顧客は、我々しかメンテできないコードベースを抱えることになる。

なので、スタックは意図的に退屈です:

バックエンド:   Node.js / TypeScript (Express or Fastify)
データベース:   PostgreSQL + Drizzle ORM
フロントエンド: Next.js + Tailwind + shadcn/ui
認証:           Lucia / NextAuth / Clerk (顧客が選択)
決済:           Stripe
ホスティング:   Vercel / Railway / Fly.io (顧客のアカウント)
CI:             GitHub Actions (リポジトリ内にコミット)
IaC:            Terraform or docker-compose (リポジトリ内)

このリストに 無いもの に注目してください: 自社CMS、独自管理画面ジェネレータ、社内ORMラッパー、「Fluxez SDK」のようなもの — 一切ありません。Day 
15 から世界中のどのシニアエンジニアでもリポジトリをクローンしてメンテを引き継げる。 これが100%譲渡の意味です。

制約に見えますが、解放でもあります。社内のどのエンジニアも、学習コストなしでプロジェクト間を移動できるからです。

---
判断 4: 受付時点でスコープを型付け — $0 が強制する

$0 ということは、将来の仕事で取り返せないプロジェクトでは、すべてが赤字 ということです。モデルが生き残るためには、Day 1 
の前にスコープを正確に型付け する必要があります。

文字通り TypeScript のファイルを使います:

// project_intake.ts
type ProjectScope = {
  product: 'B2B SaaS' | 'B2C App' | 'Internal Tool' | 'Marketplace';
  auth: 'email_password' | 'magic_link' | 'oauth';
  payments: 'stripe_subscriptions' | 'stripe_one_time' | 'none';
  data_complexity: 'simple_crud' | 'multi_tenant' | 'event_sourcing';
  ui_surfaces: ('web' | 'mobile_web' | 'admin_dashboard')[];
  integrations: ExternalIntegration[];  // 最大3つ
  out_of_scope: string[];  // 明示的に書き出し、署名
};

type ExternalIntegration =
  | 'stripe'
  | 'sendgrid'
  | 'twilio'
  | 'segment'
  | 's3'
  // クローズドな enum — "other" は存在しない

この クローズドな enum は意図的です。「既存のベンダーの API と独自の OCR パイプライン統合を追加できますか?」はスコープオプションではありません
。受付プロセスでは、リクエストを型付けされた選択肢のいずれかに整形するか、丁寧にプロジェクトを断ります。

これは官僚主義ではありません。$0 がスケールするための唯一の方法です。
伝統的なエージェンシーはスコープクリープを変更指示で吸収します。我々はできません。なので、型レベルで可能性を排除します。

---
判断 5: Day 12 = QA専用フリーズ — 14日 が強制する

最後のエンジニアリング判断は、説明は最も短く、実行は最も難しい: Day 12 以降、新機能追加禁止。

Day 12 09:00 — 機能フリーズ。新しいコードパスを追加するPRはリジェクト。
Day 12-13   — QA、エッジケーステスト、セキュリティパス、パフォーマンスチェック。
Day 13 18:00 — コードフリーズ。これ以降はクリティカルなバグ修正のみ。
Day 14 09:00 — プロダクション デプロイ。引き渡し開始。

このフリーズなしでは、すべてのプロジェクトが Day 14 朝のパニックで終わります。前夜11時に「最後にもう1機能」追加したせいでデプロイが壊れる、とい
うお決まりのパターン。我々が以前働いていたエージェンシーでこの失敗モードを何度も見てきました。 だからフリーズをカレンダーに組み込みました。

当たり前に聞こえますが、当たり前ではありません。多くのエージェンシーはこれをやりません。
課金モデルが最後の追加を報酬してしまうからです。我々のモデルにはそもそも課金がないので、この問題が発生しません。

---
制約が互いを強化し合う

面白いのは、3つのトップレベル制約が互いを強化していることです。

- $0 → 営業チーム削除 → エンジニアリング予算解放 → 14日 が現実的になる
- 14日 → スキーマロック + AI支援機械作業 → エンジニアリング工数低下 → $0 が生存可能になる
- 100%譲渡 → バニラスタック強制 → Day 15 以降にどのエンジニアでも雇える → 顧客にとってリスクが下がる → 信頼が成立 → モデルが回る

1つでも外すと、他の2つが崩壊します。

$0 + 14日, 譲渡なし    →  顧客がロックイン → 信頼崩壊 → モデル死亡
$0 + 100%譲渡, 14日なし →  緊急性なし → エンジニアリング工数膨張 → $0 死亡
14日 + 100%譲渡, $0なし →  営業パイプライン復活 → 売上の25-40%流出

これが、個別ではなく組み合わせの上に作られた最初のソフトウェア会社
と我々が言っている理由です。個別では、それぞれ達成可能です。組み合わせには、会社全体をその周りに再編成することが必要になります。

---
Fluxez を使わなくても役立つこと

これはピッチではありません。この5つの判断は、2026年の任意のエンジニアリング組織にとって有用なパターンだと思っています:

1. コードを書く前にスキーマをロックする。 下流のリファクタはすべて税金。
2. 機械的作業と判断的作業を分離する。 AIが前者、人間が後者。逆ではない。
3. 譲渡できるバニラスタックを出荷する。 プロプライエタリなインフラは顧客が将来払う技術的負債。
4. スコープを型付けする。 受付フォームに「その他」があるなら、スコープクリープで赤字になる。
5. 出荷48時間前にハードフリーズを強制する。 「最後にもう1機能」は Day 14 のインシデント予備軍。

$0 モデルを運用しなくても、これらは役立ちます。

---
創業者の方へ (もし読んでいたら)

もしあなたが創業者でこの記事を読んでいるなら — Fluxez の最初のプロジェクトは本当に無料です。 14日、フルプロダクション製品 (MVP
ではない)、ソースコード100%があなたのGitHubに譲渡されます。プロジェクト #2 以降は標準レートで有料 (レートはプロジェクト #1
開始前に提示)。カードなし、契約なし、サプライズなし。

→ fluxez.com!