原則と前提条件
中核的な開発原則
このロードマップは機能や提供日の保証ではありません。これは現在の戦略的方向性を表しており、プロジェクトの進化に応じて調整される可能性があります。
特定のフェーズに入る前に、開発アプローチを導く基本原則と、タイムラインを支える主要な前提条件を確立します。
ノンカストディアル第一
すべての機能はセルフカストディモデルを維持する必要があります：
- ユーザーは常に自分の鍵を制御
- OROKAIはユーザーに代わって取引を実行しない
- すべての操作に「準備と署名」ワークフローが必須
- この原則に違反する機能は、需要に関係なく却下
影響：一部の「利便性」機能は時間がかかるか、不可能な場合があります 例：ユーザーが各取引に署名しない「自動投資」は不可
DEXファーストアーキテクチャ
すべての暗号資産スワップは外部DEXを経由：
- OROKAIはマーケットメーカーや流動性プロバイダーとして機能しない
- オーダーブックや内部取引所機能なし
- ホワイトリストアプローチ（キュレートされたDEX統合）
- 「ベストエグゼキューション」の主張なし（コストを表示、ユーザーが決定）
影響：DEXの流動性と可用性に依存
コンプライアンス・バイ・デザイン
規制コンプライアンスは後付けではなく、アーキテクチャに組み込まれます：
- UI/APIレベルで地理的制限を実施
- パートナー経由の制裁措置スクリーニング（フィアット操作）
- 明確な分離：OROKAI = ソフトウェア、パートナー = 金融サービス
- ライセンスが必要な機能はライセンス取得済みパートナー経由のみ
影響：一部の機能はパートナーシップ/ライセンス確保まで遅延
セキュリティと監査が進捗をゲート
適切なセキュリティレビューなしで機能をローンチしない：
- スマートコントラクト：最低2つの独立した監査
- クリティカルなバックエンド：ペネトレーションテスト + コードレビュー
- 新しい統合：ホワイトリスト審査プロセス
- すべての段階で公開バグバウンティ
影響：監査によりローンチが4～8週間遅れる可能性
反復的リリース戦略
MVPを出荷し、フィードバックを収集し、反復：
- フェーズ1：コア機能のみ（限定スコープ）
- 拡大する前にユーザー行動から学ぶ
- 「完了」は「ローンチされて安定」を意味し、「完璧」ではない
- 将来のフェーズは検証された前提条件の上に構築
影響：初期ユーザーは洗練された最終製品ではなく、基本バージョンを見る
ユーザー主導の優先順位付け
ロードマップは実際の使用状況とフィードバックに基づいて調整：
- ユーザーが機能Xを使用しない場合、機能X+1を構築しない
- ユーザーが機能Yを気に入った場合、関連機能を加速
- コミュニティからの意見（調査、Discord、ガバナンス（有効な場合））
- データ > 意見（使用状況メトリクスが意思決定に情報提供）
影響：ローンチ後にロードマップが大幅にシフトする可能性
OROKAIは、伝統的な金融や規制対象商品と相互作用する機能をローンチする前に、コンプライアンスと規制の明確性を優先します。
主要な前提条件（間違っている場合のリスク）
前提条件1
技術的実現可能性
前提条件：
- マルチチェーン統合は推定タイムライン内で構築可能
- RPC/インデックスインフラストラクチャは10万人以上のユーザーにスケール
- スマートコントラクトは複雑なオーケストレーションを安全に処理可能
- AIモデルは幻覚なしで有用な推奨を提供可能
間違っている場合のリスク：
- タイムライン遅延（書き直しに6～12か月）
- パフォーマンス問題（遅いUX、失敗した取引）
- セキュリティ脆弱性（エクスプロイト、資金損失）
- ユーザー不満（AIが悪いアドバイスを提供 → チャーン）
緩和策：
- アーキテクチャにコミットする前に概念実証テスト
- モジュラー設計（必要に応じてコンポーネントを交換可能）
- 保守的な見積もり（タイムラインを30%パディング）
- 並行開発トラック（1つのコンポーネントでブロックしない）
前提条件2
パートナーの可用性と信頼性
前提条件：
- Stripe/Onramperはフィアットオン/オフランプに対して信頼性が高い
- V Plus Payはスケジュール通りにカード機能を提供
- DEXプロトコル（Uniswapなど）は利用可能で流動性がある
- ブリッジプロトコル（CCTP、Wormhole、LayerZero）は稼働時間を維持
間違っている場合のリスク：
- 機能遅延（私たちが準備できているのにパートナーが準備できていない）
- ユーザーエクスペリエンスの低下（ダウンタイム、失敗した取引）
- 収益への影響（サービスが利用できない場合は手数料を請求できない）
- 評判の損傷（ユーザーはパートナーの問題をOROKAIのせいにする）
緩和策：
- マルチプロバイダー冗長性（Stripe + Onramper、複数のDEX）
- パートナーとの契約SLA
- フォールバックモード（パートナーAがダウンしている場合、パートナーB経由でルート）
- 透明なステータスページ（問題を正直に伝える）
前提条件3
規制の明確性（または十分な曖昧さ）
前提条件：
- ノンカストディアルソフトウェアは主要市場（米国、EU、アジア）で合法のまま
- アフィリエイトプログラムはピラミッドスキームや証券として分類されない
- トークンユーティリティモデルは規制当局に受け入れられる（ローンチされた場合）
- 統合するDeFiプロトコルはコンプライアントのまま
間違っている場合のリスク：
- 特定の管轄区域での強制シャットダウン（それらの地域をジオブロック）
- 法的責任（罰金、執行措置）
- 機能削除（例：アフィリエイトプログラムを無効化する必要がある）
- トークンローンチのキャンセルまたは再構築（第8章が問題になる場合）
緩和策：
- すべての主要管轄区域で法律顧問（米国、EU、シンガポール、日本）
- 保守的なアプローチ（グレーゾーンを避ける）
- 規制対象機能をローンチする前のコンプライアンスゲート
- 規制が変更された場合のモデル転換の柔軟性
前提条件4
市場需要とプロダクトマーケットフィット
前提条件：
- ユーザーは簡素化されたDeFiアクセスを望んでいる（利便性 > 完全な制御）
- ユーザーはオーケストレーション/AI/UXに手数料を支払う（無料ツールを使用するだけではない）
- マルチチェーン集約は価値がある（単一チェーン専門化 vs）
- カードはエンゲージメントと収益を促進（損失リーダーではない vs）
間違っている場合のリスク：
- 低採用（12か月後に1万人未満のユーザー）
- 高いチャーン（ユーザーが一度試して去る）
- 非収益的なユニットエコノミクス（CAC > LTV）
- 転換が必要（中核的な価値提案を変更）
緩和策：
- 小規模なユーザーベースでのMVPテスト（スケール前に検証）
- 柔軟なロードマップ（データに基づいて優先順位をシフト可能）
- ユーザーリサーチ（調査、インタビュー、ユーザビリティテスト）
- 財務滑走路（PMFを見つけるための18～24か月）
このロードマップが何であり、何でないか
このロードマップは以下です
戦略的方向性（どこに向かっているか）
優先順位付けフレームワーク（何が重要か）
依存関係マップ（何が何の前に来る必要があるか）
コミュニケーションツール（チーム、パートナー、ユーザーを整合）
柔軟で適応的（学習に基づいて調整）
このロードマップは以下ではありません
機能や日付の保証
特定の機能へのコミットメント
固定契約（変更する権利を留保）
投資アドバイス（ロードマップの約束に基づいてトークンを購入しないでください）
包括的なリスト（簡潔にするために多くの詳細が省略）
フェーズを理解するための用語
マイルストーン vs デリバラブル
マイルストーン：重要なイベントまたは意思決定ポイント
デリバラブル：特定の機能または出力
関係：マイルストーンは複数のデリバラブルを完了することで達成される