プロダクトを単なる画面の集まりとして扱うのをやめると、構築は容易になります。
まずは2つのマップから始めましょう。
- サーフェスマップ（表面の地図）
- システムマップ（システムの地図）
サーフェスマップは、ユーザーが触れるものを示します。
システムマップは、それを機能させる仕組みを示します。
サーフェスはユーザーが見るものです。状態、ルール、統合、証明は、サーフェスを信頼性があり持続可能なものにします。
サーフェスマップ
サーフェスマップは、ユーザー向けのフローを定義します。
SaaSプロダクトの場合、以下が含まれます：
- ホームページ
- サインアップ
- オンボーディング
- ダッシュボード
- 請求管理
- 設定
- レポート
- サポート
内部ツールの場合、以下が含まれます：
- 申請フォーム
- 作業キュー
- 詳細ページ
- 承認パネル
- 管理ダッシュボード
- エクスポート
サーフェスマップは、プロダクトがユーザーに何を求めているかを把握するのに役立ちます。
システムマップ
システムマップは、運用レイヤーを定義します：
- 認証
- ロール
- データモデル
- バックグラウンドジョブ
- 統合
- イベント
- 分析
- 請求管理
- 権限
- エラーハンドリング
- 監査ログ
ここで開発者はしばしばスコープを過小評価します。
ダッシュボードを設計してキューを忘れる。
AIプロンプトを書いて評価を忘れる。
チェックアウトを構築してwebhookのリトライを忘れる。
失敗パスを描く
優れたシステムマップには、問題発生時の対応が含まれます。
例：
- 支払い失敗
- webhookのリトライ
- モデルの拒否
- ユーザーの権限不足
- ソースデータの陳腐化
- 統合のタイムアウト
- 管理者による上書き
- メールのバウンス
失敗パスのないプロダクトは、まだデモに過ぎません。
マップを構築シーケンスに変換する
システムマップが構築順序を決定すべきです。
一般的な順序：
- データモデル
- 認証とロール
- コアワークフロー
- サーフェス
- 統合
- 分析
- 証明とドキュメント
この順序は、派手な画面から始めるよりも地味です。しかし、より耐久性があります。
Academyにとっての重要性
Academyのパスでは、このモデルを直接教えるべきです。
DIY開発者に必要なのは単なるヒントではありません。
アイデアをプロダクトサーフェス、システムマップ、証明ボード、成長ループに変える方法を学ぶ必要があります。
それが「何かを作った」と「システムを構築した」の違いです。
