フロントエンド・バックエンドのソース監査 | 2026年8月12日

ENASシステム全体の機能マップ

ENASはForm、Content Page、顧客、Automation、A/B Testing、Event Tracking、外部Serviceを連携します。

Form Builderが最も複雑な領域

一つの機能がEditor、Preview、Public Form、Embedded Form、顧客Data、Event Trackingにまたがっています。

260の機能・機能グループ

以下のマップは全階層を一度に表示し、規模と依存関係を可視化します。

共通Moduleで拡張

新しいFormタイプは共通Coreから構成し、現行Form Builderを複製しません。

多階層機能マップ

260機能を自由配置のNetworkとして表示します。大きいNodeは重要度または利用度が高く、同じ領域の機能はClusterを形成します。

背景Dragまたは2本指Swipeで移動 · Wheel／PinchでZoom · NodeをDragして配置変更

マップを準備しています…

機能カタログ

領域ごとに機能グループから個別機能まで確認できます。最大領域であるForm Builderを最も詳しく記載しています。

システム横断の業務Flow

一回のForm送信が顧客更新、Tag付与、Automation、外部Service、Report Data作成へ連携します。

先に解決すべきボトルネック

以下は、一つの変更が複数領域へ波及する理由と、UIや技術の置き換えだけでは現行制約を解消できない理由を示します。

Form Builderコアの再構築案

共通責務ごとに分割し、各Moduleの入力、出力、役割を明確にして独立した変更・Testを可能にします。

重要ポイント： Normal、Calendar、Opt-in、Scenarioおよび将来のFormタイプは同じCoreを共有し、各タイプは固有差分だけを追加します。

一回のForm送信はどこを通るか

共通Pipelineにより、Formタイプごとに保存・外部連携方法が分かれることを防ぎます。

多段Formを固定Flowから解放

各StepをForm、Decision、終了Pageとして構成し、回答をJourney全体で保持します。

Core分離後の拡張性

以下の3例は、再利用する部分と新規実装が必要な差分を示します。

旧Systemから新CoreへのMigration

機能群ごとに移行し、新旧結果を比較してから実ユーザーへ有効化します。

Target Architecture

一つのApplicationとしてDeployしながら、独立した業務Moduleへ分割します。UI、CLI、AIは同じApplication Layerを経由します。

原則： AIはDatabaseへ直接Accessしません。すべての操作で権限、Data Validation、Idempotency、Audit Logを適用します。

Event Dataを運用Databaseから分離

ENASにはQuery、Report、Analytics画面を維持します。BrowserからBigQueryへ直接Queryせず、Report APIを利用します。

運用Databaseに保持Project、Form設定、顧客Profile、Booking、Campaign、権限、各種設定。

Analytics Storeに保持Raw Event、標準化Event、Session、集計Data、Retention Policy。

プロダクト投資の観点

この投資に価値がある理由

価値は新しいSource Codeそのものではなく、顧客要望をより速く、安全に、低い変更コストで機能へ変換できることにあります。

現行アーキテクチャを維持した場合、プロダクトはどこで制約を受けるのか

時間とともに蓄積する価値

より良く、拡張しやすくできるか

可能です。責務を明確に分割し、各ModuleをTest可能にし、業務Flow単位で移行することが条件です。技術だけを変えても良いArchitectureにはなりません。

用語解説

Report内の技術用語を業務視点で説明します。

付録：工数見積もり

予算と体制規模を把握するための概算です。Phase別Scheduleの確約ではありません。

総工数見積もり14.000-20.500h

QA／Tester3.100-4.300h

作業グループ別内訳
作業グループ	下限	上限
内訳合計	14.000h	20.100h

根拠・方法

結果はSource Code棚卸し、GitNexus依存Graph、API一覧、主要FlowのTraceに基づきます。Figmaと実Dataの全量確認後に見積もりを再計算します。

根拠となるSource Code

結論の読み方

根拠: Source Code、棚卸し結果、依存Graphから直接確認した事実。
評価: 根拠に基づく技術評価。稼働Systemと実Dataで追加確認が必要です。
提案: Target Architectureと移行方法であり、現行機能ではありません。

見積もりの制約

Figmaの全状態、実Data構造、Event量、Response Time要件、外部ServiceのTest環境は未確認です。

そのため予算策定時には15〜25%の予備を推奨します。