AI-First Migration — 10x Faster

JIGS-TMS
Flash → React
マイグレーション

センコーグループ統合物流管理システムのFlash→React移行を、 AIツールチェーン FARE→NEXA で 従来の 10倍以上高速 に実現します。

1,623
.mxml Source Files
281
Flash移行対象
359K
STEP Code
302
Service Pairs

課題 — なぜ今マイグレーションが必要か

Adobe Flashは2020年12月にサポート終了。セキュリティリスクと保守コストが年々増加しています。

現行システム (S-CASH)

Frontend Adobe Flash (Flex/MXML) — EOL
Backend Java (Seasar2) — 安定
Database Oracle (528 tables) — 安定
通信 AMF / BlazeDS — 要置換

放置リスク

  • セキュリティパッチ停止 — 脆弱性への対応不可
  • ブラウザ非対応 — Chrome/Edgeで動作不可の恐れ
  • Flash人材不足 — 保守コスト年々増加
  • 技術的負債蓄積 — 遅延するほどコスト増大

従来手法によるマイグレーションの課題

281
Flash移行対象画面
1,623
.mxmlソースファイル
359K
STEPコード

従来手法では 200〜300人月 規模(18〜20ヶ月)。その間、Flash保守とReact開発の二重コストが発生し続けます。

Fabbi JSC — 会社概要

社名Fabbi Joint Stock Company
所在地ハノイ、ベトナム
人員50名以上のエンジニア
主要市場日本(メイン)、ベトナム
認証P-mark (JIS Q 15001)
言語ベトナム語、日本語、英語

関連実績

Flash/Flex マイグレーション
レガシーシステムのリバースエンジニアリング実績
React / TypeScript
複数のエンタープライズプロジェクト実績
Java バックエンド統合
Spring Boot, RESTful API設計
日本企業ワークフロー
設計書、レビューサイクル、納品プロセス
FARE/NEXA AIツールチェーン
Fabbi独自開発 — 本番運用実績あり
Source Code Deep Analysis

ソースコード分析 — 562の正体

「562画面」はview/フォルダ配下の全.mxmlファイル数。実際の画面構成はメイン画面+サブ画面+共通コンポーネントに分解されます。Fabbiはソースコードから精密に分析しました。

1 ソースコード全体構成 — 1,623 .mxml ファイル

562
view/ (画面ファイル)
481 root + 81 subfolders
34.6%
411
validator/
25.3%
368
module/
21.3%
224
util/validator/
13.8%
80
component/ + skins/
58 + 22

2 562 View ファイルの分類

メイン画面
288
51.2%
サブ画面
89
15.8%
サブフォルダ画面
81
14.4%
業務独立画面
69
12.3%
共通部品・検索・他
35
6.2%
Excel Program ID一致 命名規則で親画面に紐付け 7個のサブフォルダ(ウィザード等) 親不明(ソースコード詳細解析で特定予定) 検索ポップアップ20 + ダイアログ8 + システム4 + 共通3

3 Excel(TMS機能一覧)との照合

308
Flash PC画面 (Excel一覧)
304
ソースコード一致
4
不一致
281
Flash移行対象
23
対象外
ソースのみ(Excel未登録): 173 files
ユニーク画面グループ: 385 groups
グループ平均ファイル数: 1.46 files/group

4 フェーズ別配分 — 機能分類

Phase 1 標準
137
37.2% of in-scope STEP: 170,351
Phase 2a 標準外
57
15.5% of in-scope STEP: 27,460
Phase 2b 住宅・ハウス
174
47.3% of in-scope STEP: 161,351
移行対象合計
281 screens
総STEPコード数 359,162
対象外(未使用) 42 screens (Skip)

※ 画面分類について: 上記281画面はTMS機能一覧(Excel)の機能分類に基づくPC画面(対象外除く)。 ソースコードスキャン(562 .mxmlファイル)とは異なる分類基準のため数値に差異があります。 見積はExcel機能一覧ベースの281画面(Ph1 99 + Ph2a 33 + Ph2b 149)で算出。POC 6画面は無償。

5 画面グループ例 — 1画面 = 複数ファイル

9
配車 (CarDispatch)
STEP: 13,465
CarDispatchView main
CarDispatchEditView
CarDispatchChangeView
CarDispatchBarcodeView
... +5 more sub-views
13
簡易送り状 (SimpleOkurijo)
STEP: 6,371
SimpleOkurijoView main
SimpleOkurijoBillingView
SimpleOkurijoCalendarView
SimpleOkurijoConfirmView
... +9 more sub-views
16
受付 (Uketuke)
ウィザード形式(サブフォルダ)
UketukeCompleteView
UketukeConfirmationView
UketukeInputInfoView
UketukeSelectBuzaiView
... +12 more wizard steps

分析サマリー — 見積りへのインパクト

562
総ファイル数
≠ 画面数
281
Flash移行対象画面数
Phase1(99)+2a(33)+2b(149)
385
画面グループ数
平均1.46 files/group
359K
総STEP数
in-scope only

「562画面」はソースコードスキャン結果(.mxmlファイル数)。TMS機能一覧(Excel)の機能分類に基づく移行対象は281画面(Ph1 99 + Ph2a 33 + Ph2b 149)。対象外除外済み。STEP数ベース+ランク別工数で精密に見積もりました。

システムアーキテクチャ

バックエンド業務ロジック (Java/Oracle) はそのまま維持。通信層をAMF→REST APIに置換し、フロントエンドをFlashからReactへ移行します。

S-CASH Platform Architecture — Fabbi Migration Scope

S-CASH Platform Architecture — Fabbi Migration Scope (purple dashed border)

S-CASH Business Domain Flow — TMS & WMS

S-CASH Business Domain Flow — TMS (8 domains, 3,759 functions) & WMS (6 domains, 382 functions)

現行 (Before)

Flash Client (Flex/MXML) 562 views
↕ AMF / BlazeDS
Java Backend (Seasar2) 302 services
Oracle DB 528 tables

移行後 (After)

React Client (TypeScript) 新規 ~281 screens
↕ REST API (JSON) — 新規構築
REST Controllers 新規追加層
302 endpoints
↕ 既存Service Layer呼び出し
Java Service Layer (Seasar2) 業務ロジックそのまま
302 services
↕ (変更なし)
Oracle DB 528 tables (そのまま)

なぜAMF/BlazeDSをREST APIに置換する必要があるのか

現行システムではFlash ClientとJava Backend間の通信にAMF (Action Message Format)というバイナリプロトコルを使用しています。 このプロトコルはサーバー側のBlazeDSライブラリで処理されていますが、ReactではAMFを使用できません。

AMFを維持できない理由

  • BlazeDS — Apache Attic移管(2017年)、セキュリティパッチ停止
  • JavaScript AMFライブラリ — 存在するが全て開発停止(2017-2020年)、エンタープライズ品質に非対応
  • Seasar2 BlazeDS Adapter — Seasar2自体が2016年EOL
  • バイナリ形式 — デバッグ・監視・テストが極めて困難

REST APIに置換するメリット

  • 標準技術 — HTTP + JSON、全ブラウザ・全端末対応
  • 開発効率 — Postman, Swagger/OpenAPI, DevToolsで即テスト可能
  • 将来拡張 — モバイル対応、外部連携、マイクロサービス化が容易
  • 運用監視 — ログ、トレーシング、パフォーマンス計測が標準

サーバー側の変更範囲

BlazeDS/AMFはサーバー側のServletレイヤーとして動作しています(MessageBrokerServlet → S2AMFEndpoint → S2Adapter → Seasar2 Service)。

移行では、このServletレイヤーをREST Controllerに置換します。302のサービスペアそれぞれにREST endpoint(JSONレスポンス)を作成し、既存のSeasar2 Service Layerをそのまま呼び出します。業務ロジックとDBは一切変更不要です。

移行範囲の明確化

新規構築
React画面
281画面 TSX + Hooks
REST Controllers
302 endpoints (Spring)
JSON DTO
Request/Response型定義
共通部品ライブラリ
senko-common → React
OpenAPI仕様書
全REST API定義書
自動テスト
Vitest + Playwright
修正・改修
Servlet通信層
BlazeDS → REST Dispatcher
データ形式
AMF binary → JSON
セッション管理
BlazeDS → Cookie/Token
Google Maps連携
Flash API → JS API v3
リアルタイム通知
BlazeDS Stream → WebSocket
設定・デプロイ
web.xml + WAR構成変更
そのまま維持
Service Layer (業務ロジック) + DAO + Oracle DB + Batch処理 + 外部連携
廃止
Flash Client + AMF/BlazeDS通信層 + Flash Player依存

技術スタック

React 18+
UI Framework
TypeScript 5.x
Language
Vite 5.x
Build Tool
Tailwind CSS
Styling
React Query
API Client
Zod
Validation
Vitest
Testing
OpenAPI 3.0
API Spec

コード構造マッピング — As-Is → To-Be

ファイル単位の移行対応表。左の各要素が右のどこに対応するかを番号で示します。

廃止 DELETE
修正 MODIFY
維持 KEEP
新規 NEW
書換 REWRITE
1 = 対応関係

As-Is(現行コード構造)

Flash / Flex / Java
jigs-tms-client/ DELETE
├── src/flex/
├── views/ DELETE 562 .mxml 1
├── JBus/ (203 — 運送業務)
├── JPrt/ (96 — 帳票)
├── JMst/ (81 — マスタ)
├── JUkt/ (51 — 受付)
├── JTgc/ (36 — 端末)
├── JImp/ (14 — 取込)
├── JKpi/ (11 — KPI)
├── JSnd/ (8 — 送信)
└── Search/ (20 — 検索)
├── senko-common/ REWRITE 169 files 2
├── control/ (60 — CAdvancedDataGrid等)
├── container/ (19)
├── validator/ (21)
├── formatter/ (9)
├── skins/ (14)
└── event/ (7)
└── services/ DELETE AMF RemoteObject defs
└── build/ DELETE Flash Builder
jigs-tms-server/
├── src/main/java/jp.co.senko.jigs/
├── service/ KEEP 302 pairs (~603) 4
├── dao/ KEEP DBFlute DAO
├── entity/ KEEP DB entities
└── dto/ MODIFY AMF DTOs 5
├── src/main/webapp/WEB-INF/
├── web.xml MODIFY
└── flex/ DELETE BlazeDS configs 6
├── remoting-config.xml
├── services-config.xml
└── messaging-config.xml
├── sql/ KEEP 5,418 files
└── batch/ KEEP 14 BAT/VBS

To-Be(移行後コード構造)

React / TypeScript / REST
jigs-tms-react/ NEW
├── src/
├── pages/ NEW 281 TSX 1
├── JBus/ 203 ← Flash JBus
├── JPrt/ 96 ← Flash JPrt
├── JMst/ 81 ← Flash JMst
├── JUkt/ 51 ← Flash JUkt
├── JTgc/ 36 ← Flash JTgc
├── JImp/ 14 ← Flash JImp
├── JKpi/ 11 ← Flash JKpi
├── JSnd/ 8 ← Flash JSnd
└── Search/ 20 ← Flash Search
├── components/ NEW React Component Library 2
├── data-grid/ ← CAdvancedDataGrid → ag-Grid
├── forms/ ← control/ → React Hook Form
├── layout/ ← container/ → Flexbox/Grid
├── validators/ ← validator/ → Zod
└── formatters/ ← formatter/ → Intl API
├── hooks/ NEW Business logic hooks 3
├── api/ NEW TanStack Query client
├── types/ NEW TypeScript interfaces
└── stores/ NEW Zustand state
├── vite.config.ts, tsconfig.json
└── package.json
jigs-tms-server/ MODIFIED
├── src/main/java/jp.co.senko.jigs/
├── service/ KEEP 302 pairs 4
├── dao/ KEEP DBFlute DAO
├── entity/ KEEP DB entities
├── dto/ MODIFY JSON DTO annotations 5
└── controller/ NEW 302 REST 6
├── JBusController.java
├── JPrtController.java
├── JMstController.java
└── ... (302 endpoints)
├── src/main/webapp/WEB-INF/
├── web.xml MODIFY REST dispatcher
├── flex/ DELETED
└── spring/ NEW REST config
├── sql/ KEEP
└── batch/ KEEP
docs/ NEW
├── openapi/ OpenAPI 3.0 specs
└── design-docs/ 8-sheet 設計書 per screen

対応関係の詳細

1
views/ → pages/
562 MXML → 281 React TSX(Flash移行対象)
2
senko-common/ → components/
169 Flex部品 → React + ag-Grid + Zod等
3
ActionScript → hooks/
画面ロジック → Custom React Hooks
4
service/ → service/(変更なし)
302 service pairs — 業務ロジック完全維持
5
dto/ → dto/(JSON注釈追加)
AMF DTO → @JsonProperty等 annotation追加
6
flex/ configs → controller/ + spring/
BlazeDS XML → REST Controller + Spring config
731+
ファイル廃止
562 views + 169 common
673+
ファイル新規作成
281 pages + 302 controllers
6,000+
ファイル維持
sql + batch + service + dao
~50
ファイル修正
dto + web.xml + configs

コード構造マッピング図(全体図)

Excalidraw
Code Structure Mapping: As-Is → To-Be

段階的アプローチ

POC(無償・6画面)→ Phase 1(標準)→ Phase 2(標準外 + Housing)の3段階で実行します。

無償

POC

6画面(送り状4 + マスタ2)
~2.7人月(54 MD)— 無償
技術検証 + 見積精度向上 + Tier S/A/B/C/D キャリブレーション
Deadline: 2026/3/31

Phase 1

標準 — 99画面
Flash verified: 99画面
4ヶ月
Reactコンポーネントライブラリ構築 + IT/ST
2026/4 — 2026/7

Phase 2a

標準外 — 33画面
Flash verified: 33画面
2ヶ月(Phase 2bと並行)
Phase 1コンポーネント再利用 + IT/ST
2026/8 — 2026/9

Phase 2b

Housing — 149画面
Flash verified: 149画面
3ヶ月(Phase 2aと並行)
Housing専用カスタマイズ + IT/ST(10月末完了)
2026/8 — 2026/10

? なぜ Phase 1 → 2a → 2b に分けるのか — 根拠と効果

Phase 1 を先行する理由
  • 標準画面(99画面)は共通パターンが最多。CRUD/照会/登録/帳票のここでコンポーネントライブラリを構築 → 以降全フェーズの共通資産になる
  • Phase 1完了時点で全体の約35%稼動。早期に業務価値を提供できる
  • AIパイプライン(FARE/NEXA)のキャリブレーションをここで完了 → 2a/2bの見積精度・実行速度が向上
Phase 2a を分ける理由
  • 標準外はカスタムロジックが多く複雑度が高い(受注系・特殊処理)。Phase 1の基盤なしに実施するとリスク大
  • Phase 1コンポーネント再利用で工数 ×0.7(-30%) 削減(学習曲線効果)
  • 33画面・2ヶ月の小規模フェーズ。2bと並行実施でTimelineを圧縮
Phase 2b を最後にする理由
  • Housing 149画面はサブグループ間で類似パターンが極めて多い → Phase 1-2a蓄積を最大活用して工数 ×0.6(-40%) 削減
  • 最多画面数(149)をチームの生産性がピーク時(Phase 1-2a後)に実施 → コスト最小化
  • 2aと並行実施 → 2b完了後すぐにUAT/移行(11月〜)へ移行可能
リスク軽減 POC→Phase 1で手法確立 → 段階コミット
コスト最適 学習曲線効果: 2a -30% / 2b -40%
早期価値 Phase 1完了時点で中核業務画面が稼働
品質担保 各フェーズIT/ST完了後に次フェーズへ進行

POC Scope — 6画面、2モジュール(無償・54 MD)

Module 1: 送り状 Waybill(4画面)
  • • 送り状一覧 — List + Filter + Bulk Ops A
  • • 送り状作成 — 7-step wizard A
  • • 送り状詳細 — Tab detail B
  • • 送り状編集 — Edit wizard B
✓ Prototype 済み — End-to-end CRUD demo
Module 2: マスタ Master(2画面)
  • • ドライバーマスタ — CRUD standard B/C
  • • 得意先マスタ — CRUD + validation B
→ 35%+ 画面と同パターン — velocity 検証

学習曲線のメリット

Phase 1で構築: コンポーネントライブラリ、パイプライン、AI最適化、チーム理解
Phase 2で再利用: ライブラリ60-80%再利用、パイプライン最適化済み → 画面あたり30-40%コスト削減

段階的アプローチ

独自AIツールチェーン FARE→NEXA で、従来手法の10倍以上高速に移行します。

従来手法
200〜300
人月
18〜20ヶ月(大規模チーム必要)
大幅削減
Fabbi AI
AI-Firstアプローチ
< 100
人月
~11ヶ月(チーム8名・Go-Live 1/2027)

Human-in-the-Loop (HITL) — 品質保証

AIは100%自動ではありません。全ての品質ゲートでシニアエンジニアがレビューします。

S (特大)
AI 10-25%
HITL 75-90%
A (大)
AI 30-50%
HITL 50-70%
B (中)
AI 50-70%
HITL 30-50%
C (小)
AI 60-80%
HITL 20-40%
D (特小)
AI 70-90%
HITL 10-30%

FARE → NEXA パイプライン

Fabbi独自の2段階AIツールチェーンが、分析から設計・コード生成まで一貫して自動化します。

F

FARE

Flash Analysis & React Engine

リバースエンジニアリング — Flash構造を高速解析

Input: Flash Source (.mxml, .as)
Parse: 構造解析 (LOCAL)
Output: 画面一覧、部品一覧、複雑度分類
Deterministic + Gemini Enterprise
N

NEXA

Next-gen Expert Analysis & Generation

深層分析+設計書+Reactコード+テストを日本品質基準で自動生成

Input: FARE出力 + 289件の設計書
Analysis: ビジネスロジック抽出 → RD/BD
Output 1: DD (詳細設計書 — 8シート形式)
Output 2: React/TS コード + Unit Tests
LLM Analysis + Metaprogramming + Claude Enterprise

品質ゲートフロー

FARE出力 シニアレビュー NEXA (Analysis) シニアレビュー NEXA (DD) シニアレビュー NEXA (Code) レビュー+テスト 納品物

セキュリティ

3層セキュリティ (インフラ + AIツール + 法的) でソースコードとデータを保護します。

Layer 1: インフラ

  • VDI Farm (ローカルコピー禁止)
  • USB / クリップボード外部転送禁止
  • Site-to-Site VPN (IPSec) + mTLS 1.3
  • MFA + RBAC per developer per module

Layer 2: AIツール

  • 匿名化レイヤー(業務データ除去後にAPI送信)
  • Enterprise API (Zero Retention)
  • 学習に使用されない (ToS保証)
  • 全API呼出しログ記録 (1年保持)

Layer 3: 法的保護

  • NDA(日本法準拠・日本仲裁)
  • 開発者個人NDA
  • IP成果物の即時譲渡
  • DPA (Anthropic + Google)

Fabbi 信頼要素

P-mark (JIS Q 15001) — 取得済み
Enterprise API DPA — Zero Retention
監査証跡 — 全API呼出しログ1年保持

工数見積もり

AI Pipeline(FARE+NEXA)+ Manual QA による見積もり。POCで精度をキャリブレーションします。

🤖

AI Pipeline Cutoff — FARE + NEXA 効率化率

FARE(自動Flash解析)+ NEXA(業務理解支援)パイプラインにより、工数の60%をAI自動化。人的工数(HITL)は40%。

60%
AI自動化率
40%
人的工数 (HITL)
×0.4
工数削減乗数
Rank STEP閾値 手動工数 (MD) AI適用後 (×0.4) Phase 2a (×0.70) Phase 2b (×0.60)
S ≥5,000 70 MD 28 MD 19.6 MD 16.8 MD
A ≥2,000 35 MD 14 MD 9.8 MD 8.4 MD
B ≥1,000 16.25 MD 6.5 MD 4.55 MD 3.9 MD
C ≥400 10 MD 4 MD 2.8 MD 2.4 MD
D <400 5 MD 2 MD 1.4 MD 1.2 MD

※ Phase 2a: 30%学習曲線削減(×0.70)、Phase 2b: 40%学習曲線削減(×0.60)。AI Cutoff適用後の値に乗算。

フェーズ 画面数 作業小計(MD) 管理工数(MD) 合計(MD) 工数(MM) 金額(¥)
POC(6画面 — 無償) 6 44.9 9.2 54.1 2.71 ¥0
Phase 1 — 標準画面(99画面) 99 545.4 54.5 599.9 29.99 ¥14,997,275
Phase 2a — 標準外画面(33画面) 33 100.6 10.1 110.7 5.54 ¥2,768,500
Phase 2b — Housing画面(149画面) 149 455.5 45.6 501.1 25.06 ¥12,528,125
AI (FARE + NEXA) ¥2,827,500
合計 287 1,146.5 119.4 1,265.9 63.29 ¥33,121,400

Fabbi AI 見積もりサマリー

Frontend Only (NONE-BACKEND)
¥33,121,400
1,265.9 MD — 63.29 MM(含 AI ¥2,827,500)
Frontend + API Bridge (WITH-BACKEND)
¥42,336,400
1,747.6 MD — 87.38 MM(含 AI ¥2,827,500)

※ 1人月 = 20人日(MD)。POC 54.1 MD(無償・6画面)は別途。管理工数 10%(POCのみ 20.55%)込み。対象外42画面除外。

スケジュール (Track A — 推奨)

Phase 1で基盤構築 → Phase 2a+2b並行実行(IT/ST 10月末完了)→ UAT 10月〜(IT/ST gối)12月完了 → Go-Live 1/2027

JIGS-TMS マイグレーション Timeline

3月
4月
5月
6月
7月
8月
9月
10月
11月
12月
1月
2026
2027
Fabbi
POC(無償)
6画面
1M
内訳
FARE
DD
Code
Phase 1(標準)
99画面 · 4M
2026/04 → 07
内訳
FARE + 設計(RD/BD/DD)
Code + REST Bridge
IT
Phase 2a(標準外)
33画面 · 2M
2026/08 → 09
内訳
設計
Code+IT/ST
Phase 2b(Housing)
149画面 · 3M
2026/08 → 10
内訳
FARE + 設計
Code + REST
IT/ST
UAT + 移行
Blue-Green Deploy
2026/10 → 12
TDC / センコー
設計レビュー
POC
Ph1
Ph2a+2b
UAT受入テスト
Ph1 UAT
全体UAT + 移行(Blue-Green)
Milestone
Go/No-Go
Ph1完了
IT/ST完了
UAT+移行完了
Go-Live
合計期間
POC 1M
Ph1 4M
Ph2a 2M
Ph2b 3M
UAT+移行 2M
TDC Review/UAT
Milestone
計11ヶ月(2026/03 → 2027/01)

中間成果物・レビュープロセス

品質ゲートフローにTDC様・センコー様のレビューを組み込み、手戻りを最小化します。

品質ゲートフロー(3レーン並行)

Lane 1 Fabbi製造
FARE出力 SR NEXA(Analysis) SR NEXA(DD) SR NEXA(Code) QA 納品
Lane 2 TDCレビュー
DD完了後 → 設計書レビュー(5営業日) Code完了後 → コードレビュー(3営業日) FB反映→納品
Lane 3 センコー確認
UIスタイル承認(初期1回) 業務フロー確認(Phase毎) 画面一覧確認(Phase毎) 月次ステアリング

※ Lane 2はノンブロッキング: Fabbiは次バッチに継続しつつ、TDCフィードバックを納品前に反映。

中間成果物一覧(レビュー対象)

※ 納品物(⑤)とは別。品質確保のためTDC様にレビューいただく中間ドキュメント。

# 中間成果物 種別 数量 判定基準 レビュー担当
1 業務フロー図 既存→確認 1ファイル 維持 / 新規 / 修正 / 削除 TDC + センコー
2 機能要件一覧 既存→確認 1ファイル 維持 / 新規 / 修正 / 削除 TDC
3 画面一覧 既存→更新 1ファイル 維持 / 新規 / 修正 / 削除 TDC + センコー
4 画面遷移図 既存→更新 1ファイル 維持 / 新規 / 修正 / 削除 TDC
5 画面基本設計
(8シートExcel)
再作成/修正 画面毎1ファイル
(~281件)
Flash→React設計変換。修正/新規作成対象画面分。 TDC
バッチ毎~20画面 / 5営業日
6 UIスタイルガイド 新規作成 5画面サンプル カラー・タイポグラフィ・スペーシング・コンポーネント規約 TDC + センコー
初期1回
7 UI Figmaデザイン 新規作成 画面毎1ファイル
(全画面UIリニューアル)
React新UIの画面デザイン。全対象画面分。 TDC
バッチ毎
8 フロントエンドアーキテクチャ 新規作成 1ドキュメント React技術スタック・ルーティング・状態管理・ビルド設定 TDC承認
初期1回
9 API Layerアーキテクチャ 新規作成 1ドキュメント RESTブリッジ設計・認証方式・エラーハンドリング TDC承認
初期1回

※ 上記は中間成果物(レビュー用)。納品物は別途「成果物」セクション参照。

※ 業務フロー図・機能要件一覧は1:1マイグレーションのため原則変更なし。変更がある場合は変更管理として別途協議。

※ Figmaデザインは現行レイアウト踏襲+モダンUI適用。全画面分を作成。

デモ — React移行プロトタイプ

Flash→React移行の実動プロトタイプ。9モジュール・全画面を実装済み。

Login Page

1. ログイン画面 — 412 PC画面(281 Flash移行対象)、6ロール対応

Dashboard

2. ダッシュボード — KPI、チャート、リアルタイムデータ

Master Data

3. マスタ管理 — 81画面、30+マスタ種別、9,800+レコード

Dispatch

4. 配車管理 — 車両×ルート割り当て、ステータス追跡

Waybill

5. 送り状管理 — 24バリアント、本番品質データグリッド

Delivery

6. 配送管理 — リアルタイム追跡、GPS、写真確認

Reports

7. 帳票管理 — 96帳票種別、6カテゴリ

Billing

8. 請求管理 — 請求書ライフサイクル、クレーム管理、EDI

9モジュール一覧

ダッシュ
ボード
受注
管理
送り状
管理
配車
管理
積込
管理
配送
管理
請求
管理
マスタ
管理
帳票
管理

次のステップ

無償POC(6画面:送り状4 + マスタ2)から開始します。
技術検証の結果に基づき、本格移行の精度の高い見積もりを提出します。

Step 1
無償 POC
6画面、送り状4 + マスタ2
Step 2
精度向上見積もり
POCデータに基づく改訂版
Step 3
本格移行開始
Phase 1(標準画面)スタート

Fabbi JSC — AI-Powered Software Development

ハノイ、ベトナム | P-mark (JIS Q 15001) 取得済み