RWA新規事業の構想を3か月でMVP要件へ。私たちが事業・法務・技術をつないだ方法

Netsujo株式会社は、現実資産のトークン化（RWA）を検討する事業者の新サービス構想を、約3か月でMVP（最小限の実用製品）の要件へ整理しました。対象資産、トークンの発行主体、二次流通、法規制、ブロックチェーン方式。互いに影響する論点を整理し、MVPの範囲、技術設計方針、法務対応の優先順位を確定しました。私たちの支援後、案件は開発フェーズへ手戻りなく移行しています。

この案件で私たちが担ったのは、構想の壁打ち、論点整理、技術検証、法務連携、PoC設計、要件定義です。FDE（Forward Deployed Engineer）の仕事に通じるのは、顧客の事業に入り込み、専門家の判断と実装をつなぐ部分です。事業化前の段階で何を決め、誰に決めてもらい、どの検証を先に進めたのか。実際の支援から説明します。

私たちに求められたのは、実装に入るための前提づくりだった

相談当初、事業者はRWA領域での新サービスを構想していました。ただ、提供対象と仕組みが広く、開発ベンダーに発注するための仕様を定められる状態にはありませんでした。

「どの現実資産をトークン化するか」が決まれば、利用者と必要なデータが変わります。「自社が発行するのか、プラットフォームとして提供するのか」でも、事業上の役割と技術設計は変わります。二次流通を含める場合は、さらに確認すべき規制や仕組みが増えます。技術だけで独立して決められる項目が少ない案件でした。

当時、私たちが整理した主な論点は次のとおりです。

この状態で実装方式を先に固定すれば、後から事業上・法務上の条件が変わった際に設計を見直す可能性があります。私たちは、技術選定を急ぐよりも、技術選定の前提を確かめる作業から支援を組み立てました。

構想整理と技術検証を、同じ期間に進めた

私たちが採用したのは、事業オーナーとの壁打ちと技術的な実現可能性の検証を並行して進める方式です。構想について「やること」「今回扱わないこと」の境界を決める一方で、候補となるブロックチェーンやスマートコントラクトの制約を調べました。

法務の検討も並行させました。適用規制を技術側だけで決めることはできません。私たちは法務と連携し、確認が必要な論点とその優先順位を明らかにしました。事業の優先順位は事業オーナーが判断し、技術上の選択肢と制約は私たちが提示する。この分担を土台に、各判断が次の要件へどう影響するかを整理しました。

私たちはこの段階の技術検証を、構想から開発要件へ進むための前提確認として実施しました。完成サービスの稼働や利用効果を確認する仕事は後続工程に位置づけ、法務上の結論を待つ論点と先に進められる検証を分けました。

「法的に可能か・技術的に可能か・事業インパクトがあるか」で評価した

構想を小さくするには、候補の機能を単純に削るだけでは足りません。何を優先するか、誰が決めるか、その理由が必要です。

私たちは各アイデアを、法的な実現可能性・技術的な実現可能性・事業インパクトの3軸で評価する枠組みを用意しました。この枠組みを使って関係者の合意形成を整理し、MVPに含める範囲と後続で検討する範囲を決めました。

例えば、二次流通を含む案について法務上の確認が必要なら、技術検証の結果だけでその機能を確定させることはしません。先に検証できる構成要素は調査し、専門判断を必要とする仕様は担当者の結論を待つ。ここで述べる「二次流通案を保留して比較する」という手順は、私たちがこの案件の論点から整理した他案件向けの適用例です。

この3軸を揃える意義は、会議で結論を出す速さだけにありません。結論を変えるときに、どの前提が変わったのかを説明できることです。法的な条件が変われば技術の候補を見直す。事業上の優先度が変わればMVPの対象を見直す。判断を関連づけておくことで、設計の理由を後続の担当者に渡せます。

私たちが3か月で実現した成果

この案件で私たちは、構想整理からMVP要件定義までを約3か月で進め、次の状態をつくりました。

1. MVPの範囲を確定した。 広がっていた構想を、最初に開発する対象と対象外が判断できる要件へ落とし込みました。
2. 技術設計方針を確定した。 ブロックチェーンの選定とスマートコントラクトの設計方針を整理しました。
3. 法務対応の優先順位を明確にした。 適用規制の論点を整理し、専門確認と事業判断の順序を定めました。
4. 開発工程への移行を成立させた。 要件定義後、案件は開発フェーズへ手戻りなく進みました。3軸の評価枠組みも、事業者側で優先順位を考える材料として残りました。

これらは、私たちが実際に担当して達成した成果です。一方、その後のサービスの売上や利用者数については、今回の支援範囲に結び付く測定値を示していません。私たちの成果は、構想を開発可能な意思決定と要件へ変えたことにあります。

ここでいう約3か月は当該案件の実績です。RWA関連の法的適合性を私たちが保証するものでも、他の新規事業を同期間で完成させる約束でもありません。

この経験をAI・SaaSのFDE型支援にどう使うか

AI・SaaSの顧客導入でも、利用するデータ、外部連携、承認ルール、品質基準が決まらないまま「まず動くものを」と求められることがあります。私たちはRWA案件で実践した判断の整理を、こうした導入の初期工程にも応用できると考えています。

応用する場合は、未決事項を次の5つで管理する方法が有効です。次の表は、今回の経験をもとに私たちが整理した実務上の提案です。

例えば、AIエージェントが社内データを扱う案件なら、データ利用を認める権限者の判断と、読み取り専用で試せる技術検証を分けて進められます。権限が未確定な状態で本番データへのアクセスを拡大する必要はありません。検証結果が揃ったところで、正しい判断者へ次の選択肢を返します。

FDE型の仕事で価値が出るのは、関係者の課題を理解したうえで、決める人が決められる状態をつくり、実装チームに確かな前提を渡すことです。私たちは実際のRWA支援で、その前提づくりから開発フェーズへの接続まで担当しました。

構想の段階から相談いただけます

「新規事業の方向性はあるが開発要件が定まらない」「事業・法務・技術の判断が絡み合っている」という段階から、Netsujo株式会社はご相談を受け付けています。専門的な法的判断は適切な担当と分担し、当社は事業スコープ、技術検証、MVPの要件、開発への受け渡しを具体化します。

まずは今ある構想と、決められていない事項を共有してください。対象範囲と成果物は案件ごとに合意します。

AI導入・業務改善支援 ／ 構想・開発について相談する

---

当社の一次情報： RWA構想の整理と要件定義（支援実績） ／ 開発実績一覧。支援期間、体制、実施範囲、MVP要件確定、開発フェーズへの移行は当社の公開案件記録に基づきます。FDEへの転用方法と表形式の整理は、私たちの実務上の提案です。