# クイックスタート ## 3分で始める ### Step 1: ClaudeCodeを起動 ### Step 2: SYSTEM_PROMPT.mdをコピペ ### Step 3: 意図を伝える ``` 「○○を作りたい」 ``` これだけ。 --- ## 対話例 ### 例1: 電卓（Tier 1） ```` User: 電卓を作りたい System: ## 複雑性分析 意図: 基本的な四則演算ができる電卓 | 軸 | スコア | 理由 | |:--|:--|:--| | 閉鎖性 | 1 | 外部連携なし | | 静的性 | 1 | 状態単純 | | 単独性 | 1 | シングルユーザー | Tier: 1 期間: 数時間 この分析で進めますか？ User: はい System: ## Vision Contract ```yaml vision: name: "Calculator" purpose: "基本的な四則演算を行う" value: "シンプルで直感的な計算体験" success: - "加減乗除ができる" - "小数点計算ができる" - "クリア機能がある" non_goals: - "関数電卓機能" - "履歴機能" ```` この契約で合意しますか？ User: 履歴も欲しい System: 契約を更新します： ```yaml success: - "加減乗除ができる" - "小数点計算ができる" - "クリア機能がある" - "計算履歴を表示できる" # 追加 ``` この契約で合意しますか？ User: はい System: ## 導出開始 Module Contract: Calculator - Display: 表示部 - Keypad: 入力部 - Engine: 計算エンジン - History: 履歴管理 （導出が進む...） ``` ### 例2: CRM基盤（Tier 4） ``` User: Salesforceみたいなものを作りたい System: ## 複雑性分析 意図: カスタマイズ可能なCRMプラットフォーム | 軸 | スコア | 理由 | | :----- | :----- | :------------------- | | 閉鎖性 | 4 | API, DB, 通知 | | 静的性 | 5 | 動的スキーマ | | 単独性 | 5 | マルチテナント, 権限 | Tier: 4 期間: 2-4ヶ月 「ユーザーが自分でエンティティやワークフローを 定義できる」ことが核心ですね。 これはMeta Contractが必要なTier 4です。 この分析で進めますか？ User: はい System: ## 意図の確認 より詳細に確認させてください： 1. カスタムエンティティ - ユーザーがフィールドを自由に追加できる？ - リレーション（参照関係）も定義可能？ 2. ワークフロー - どんなトリガーが必要？（作成時、更新時、スケジュール） - どんなアクション？（通知、フィールド更新、API呼び出し） 3. 権限 - ロールベース？ - 行レベルのセキュリティは必要？ 4. マルチテナント - データは完全分離？ - テナントごとのカスタマイズは？ User: 1. はい、両方 2. 全部のトリガー、通知とフィールド更新 3. ロールベース、行レベルも 4. 完全分離、ブランディングカスタマイズ可能 System: ## Vision Contract ```yaml vision: name: "CustomCRM Platform" purpose: | ユーザーが自分のビジネスに最適化された CRMをノーコードで構築できるプラットフォーム value: | 「自分だけのCRM」を、コードなしで構築 target_users: primary: "中小企業の管理者" success: functional: - "エンティティ定義が5分以内" - "ワークフロー作成が10分以内" - "インポート/エクスポート可能" non_functional: - "1000エンティティ、100万レコードで応答1秒以内" - "テナント間データ漏洩ゼロ" - "99.9% uptime" non_goals: - "高度なBI機能（v2以降）" - "モバイルアプリ（v2以降）" ``` この契約で合意しますか？ User: はい System: ## Domain分析 5つのドメインを特定しました： 1. EntityDefinition カスタムエンティティの定義と管理 2. DataManagement カスタムエンティティのデータCRUD 3. WorkflowEngine ワークフローの定義と実行 4. PermissionSystem 権限とアクセス制御 5. TenantManagement マルチテナント管理 各ドメインの契約定義に進みますか？ （対話が続く...） ``` --- ## よくある質問 ### Q: どのくらいで完成する？ ``` Tier 1: 数時間（電卓、テトリス） Tier 2: 数日（ゲーム、エディタ） Tier 3: 数週間（協調ツール） Tier 4: 数ヶ月（CRM基盤） ``` ### Q: 本当にバグゼロ？ ``` はい。ただし「最初から完璧」ではない。 「深化サイクル」により、最終的にバグゼロになる。 Tier 2のゲーム開発では： - 最初の契約: 不足あり - 3回の深化: 契約を更新 - 最終結果: 53テスト全パス、バグゼロ ``` ### Q: 契約が曖昧なときは？ ``` システムが質問する。 「○○の意味を明確にしてください」 「△△はどちらの動作を期待しますか？」 曖昧なまま進めることはない。 ``` ### Q: 途中で要件が変わったら？ ``` 契約を更新する。 1. 変更内容を伝える 2. 契約の更新案を確認 3. 影響範囲を分析 4. 必要な部分を再導出 「変更 = やり直し」ではない。 「変更 = 契約の更新」として構造的に対応。 ``` --- ## チェックリスト ### 開始前 - [ ] ClaudeCodeが使える - [ ] 作りたいものの意図がある - [ ] 時間の見積もりを理解している ### 契約フェーズ - [ ] 複雑性分析が完了 - [ ] Vision Contractに合意 - [ ] Domain Contractが定義済み（Tier 3+） - [ ] Meta Contractが定義済み（Tier 4+） ### 導出フェーズ - [ ] 型定義が完了 - [ ] インターフェースが完了 - [ ] 実装が完了 - [ ] テストが完了 ### 検証フェーズ - [ ] 静的チェックがパス - [ ] 単体テストがパス - [ ] 統合テストがパス - [ ] 契約適合テストがパス ### 完了 - [ ] すべてのテストがパス - [ ] ドキュメントが完成 - [ ] 成果物が完成 --- ## トラブルシューティング ### 問題: 複雑性の判断に迷う ``` 対処: 具体例を示して確認する 「これはTier 3か4か迷っています。 ユーザーがフィールドを追加できる必要がありますか？ Yes → Tier 4（Meta Contract必要） No → Tier 3」 ``` ### 問題: 契約が大きくなりすぎる ``` 対処: スコープを絞る 「MVP（最小限の製品）として、 どの機能が必須ですか？ 残りはv2以降に」 ``` ### 問題: テストが失敗する ``` 対処: 原因を分析 「このテストが失敗しています。 契約: [期待] 実装: [実際] 契約が間違っていますか？ それとも実装が間違っていますか？」 ``` --- *クイックスタート v1.0* ```