ROI Case File No.376 | 'Skyline Logistics Inc.'s Ticking Time Bomb of Unsupported Software'

Chapter 1: The Ticking Time Bomb of Unsupported Software—3 Months and 8 Million Yen per Modification

The day after resolving Globex Corporation's OODA case, a consultation arrived regarding core system screen reconstruction. Volume 30, "The Pursuit of Reproducibility," Case 376 tells the story of ensuring reproducibility through Record-Check-Do.

"Detective, our system is a ticking time bomb. The supply system's development framework reached end-of-support in 2024. But we're still using it. And last month, users requested a screen modification: 'Add planned order quantity to the inventory confirmation screen.' But the estimate came to 8 million yen and 3 months. For adding just one field."

Kenta Yamada, IT Director of Skyline Logistics Inc. from Kawasaki, visited 221B Baker Street with an exhausted expression. In his hands were design documents for the supply system built 15 years ago (5 paper binders), and in stark contrast, a screen reconstruction proposal titled "Framework Migration Proposal 2026."

"We are a logistics company. 2,800 employees. Annual revenue of 48 billion yen. We operate domestic logistics core systems. But our development framework is unsupported. And we want to reconstruct screens, but we don't know which company to ask."

Skyline Logistics Inc.'s Current State: - Founded: 1978 (logistics company) - Employees: 2,800 - Annual revenue: 48B yen - Systems: Supply system, delivery system, warehouse management system, etc. - Issues: Unsupported development framework, high screen modification costs, black-boxed system

Deep crisis permeated Yamada's voice.

"The supply system's current state is as follows: Development framework: Struts 1.x (end-of-support 2013). Development language: Java 6 (end-of-support 2013). Database: Oracle 10g (end-of-support 2013). All have been unsupported for over 10 years. However, the backend business logic works fine. The problem is only the screens."

Supply System Configuration:

System Scale: - Screen count: 280 screens - Backend APIs: 1,200 - Database tables: 850 tables - Development start: 2010 - Last major revision: 2015

Using Departments: - Logistics Management: 120 people - Warehouse Management: 80 people - Procurement: 60 people - Total: 260 people

Screen Modification Reality:

Case 1: Add Field to Inventory Confirmation Screen (December 2025) - Request: Add "Planned Order Quantity" column - Estimate: 8M yen, 3 months - Breakdown: - Current state investigation (Struts 1.x code analysis): 1.5M yen, 2 weeks - Design: 2M yen, 3 weeks - Development: 3M yen, 6 weeks - Testing: 1.5M yen, 3 weeks

Case 2: Add Search Condition (August 2024) - Request: Enable search by "Expected delivery date" - Estimate: 6.5M yen, 2.5 months - Result: Postponed due to budget constraints

Case 3: Change Button Placement (November 2023) - Request: Move "Register" button to bottom of screen - Estimate: 1.8M yen, 3 weeks - Result: Postponed due to budget constraints

Yamada sighed deeply.

"There's another problem. We don't have a fixed vendor. Each system uses different vendors, and we move for modifications each time. And we don't know which company to ask. We went to exhibitions, but couldn't judge which companies are good. And since the current framework is unsupported, writing modules creates black boxes."

Chapter 2: The Illusion of Complete Screen Replacement—Chaos Without Records

"Yamada-san, do you believe that replacing all screens at once will solve all problems?"

My question left Yamada looking confused.

"Isn't that the case? I thought migrating all screens to the latest framework would reduce modification costs."

Current Understanding (Complete Replacement Approach): - Expectation: Migrate all screens to latest framework - Problem: No records, unclear priorities

I explained the importance of ensuring reproducibility through Record-Check-Do.

"The problem is thinking 'replace all screens at once.' RCD—Record, Check, Do. First accurately record the current state, check it, and execute. By running this cycle, we achieve reproducible phased reconstruction. Don't change all screens at once—reconstruct high-priority screens first."

⬜️ ChatGPT | Catalyst of Concepts

"Don't replace all screens. Thoroughly implement RCD for Record-Check-Do, and reconstruct priority screens first"

🟧 Claude | Story Alchemist

"Systems are always 'labyrinths that have lost past memories.' Recording is the first job"

🟦 Gemini | Compass of Reason

"Run the RCD cycle. Execution without records is gambling. Execution without checking fails"

The three members began their analysis. Gemini displayed the "RCD Cycle" on the whiteboard.

RCD Cycle: 1. Record: Accurately record the current state 2. Check: Verify and evaluate recorded content 3. Do: Execute based on verification results 4. Return to Record: Record execution results and proceed to next cycle

"Yamada-san, let's start by accurately recording the current state."

Chapter 3: Phase 1—Record to Visualize Current State

Step 1: Create Screen Registry (2 weeks)

Recording Items: - Screen ID, screen name, function overview - Using department, monthly access count - Last update date, modification history - Technology stack (framework, libraries) - Backend API dependencies

Recording Method: - Digitize existing design documents (5 paper binders) - Aggregate access counts with log analysis tools - Interview each department (usage frequency, importance)

Screen Registry (Partial Extract):

280 Screen Classification: - High frequency/High importance: 45 screens (16%) - High frequency/Low importance: 30 screens (11%) - Low frequency/High importance: 55 screens (20%) - Low frequency/Low importance: 150 screens (54%)

Step 2: Record User Requests (2 weeks)

Record Past 3 Years of Modification Requests:

Request Classification: - Add/modify fields: 28 (47%) - Add search conditions: 18 (30%) - Change screen layout: 10 (17%) - Other: 4 (6%) Total: 60 requests (past 3 years)

Critical Discovery: - Of 60 requests, only 12 (20%) were implemented - Remaining 48 (80%) postponed due to budget constraints - Requests concentrated on specific screens (S001, S002, S004) (45% overall)

Step 3: Record Technology Stack (1 week)

Current Technology Stack:

Frontend:

Struts 1.x (end-of-support 2013) JSP + JSTL jQuery 1.8 (released 2013) Backend:

Java 6 (end-of-support 2013) Spring 2.5 (released 2009) Oracle 10g (end-of-support 2013) Black-Boxing Reality: - Of 5 developers, 3 have already left - Remaining 2 don't understand details - Few comments (5% of all code), low readability - Many discrepancies between design documents and implementation (approximately 30%)

Chapter 4: Phase 2—Check to Determine Priorities

Step 4: Screen Priority Evaluation (1 week)

Evaluation Axes: - Axis A: Monthly access count (1-5 points) - Axis B: Number of user requests (1-5 points) - Axis C: Business impact (1-5 points) Determine priority by total score

Priority Top 10:

Phase 1 Target: Top 10 screens (3.6% of all 280 screens)

Step 5: Technology Selection Verification (2 weeks)

Candidate Frameworks:

Option 1: React + TypeScript (SPA type) - Advantages: Modern, high development efficiency, rich ecosystem - Disadvantages: High learning cost, backend API modifications required - Estimate: 1.8M yen per screen

Option 2: Thymeleaf (Server-side rendering type) - Advantages: Low learning cost, high affinity with existing Java code - Disadvantages: Slow screen transitions, difficult to create modern UI - Estimate: 1.2M yen per screen

Option 3: Vue.js + Spring Boot (Hybrid type) - Advantages: Medium learning cost, minimal backend modifications - Disadvantages: Design complexity - Estimate: 1.5M yen per screen

Judgment from RCD Perspective: - Record: Existing backend APIs work fine (recorded) - Check: Should minimize backend modifications (verification result) - Do: Reconstruct frontend only (execution policy)

Decision: Adopt Option 3 (Vue.js + Spring Boot) - Reason: Utilize existing backend APIs, enable phased migration

Chapter 5: Phase 3—Phased Do (Execution)

Months 1-2: Pilot Screen (S001) Reconstruction

S001 (Inventory List) Reconstruction:

Record: - Record screenshots of current Struts 1.x screen - Video record user operation flows - Create backend API specifications

Check: - Reflect user request (add planned order quantity column) - UI designer creates mockup - User review conducted (5 warehouse management staff)

Do: - Develop new screen with Vue.js + TypeScript - Utilize existing backend API (no modifications needed) - Testing: Unit test, integration test, UAT

Development Period: 2 months Development Cost: 1.5M yen

Month 3: Effect Measurement and Feedback

KPI 1: Development Cost - Before (Struts 1.x modification): 8M yen - After (Vue.js new development): 1.5M yen - Reduction rate: 81%

KPI 2: Development Period - Before: 3 months - After: 2 months - Reduction rate: 33%

KPI 3: User Satisfaction - Survey conducted (120 warehouse management staff) - "Improved operability": 102 (85%) - "Improved display speed": 95 (79%) - "Requests reflected": 108 (90%)

Critical Discovery: - Vue.js reconstruction is cheaper and faster than Struts 1.x modification - Extremely high user satisfaction - No backend API modifications needed, minimizing risk

Months 4-12: Sequential Reconstruction of Top 10 Screens

Reconstruction Schedule: - S001: Months 1-2 (complete) - S004: Months 4-5 - S002: Months 6-7 - S012: Months 8-9 - S008: Months 10-11 - Remaining 5 screens: Month 12-next March

Annual Effects (10 screen reconstruction):

Development Cost Reduction: - Before: 8M yen × 10 screens = 80M yen (if Struts 1.x modification) - After: 1.5M yen × 10 screens = 15M yen (Vue.js reconstruction) - Reduction: 65M yen

Maintenance Cost Reduction: - Security risk response for unsupported framework: 8M yen/year - New framework maintenance: 2M yen/year - Reduction: 6M yen/year

User Productivity Improvement: - Screen operation time: Average 25% reduction - Target users: 260 people - Annual time saved: 260 × 1 hour/day × 25% × 240 days = 15,600 hours - Personnel cost reduction: 15,600 hours × 3,500 yen = 54.6M yen/year

Total Annual Effects: - Development cost reduction: 65M yen (first year only) - Maintenance cost reduction: 6M yen/year - Productivity improvement: 54.6M yen/year First year total: 125.6M yen Following years: 60.6M yen/year

Investment: - 10 screen reconstruction: 15M yen - Project management: 3M yen - Total initial investment: 18M yen

ROI: - (125.6M - 0) / 18M × 100 = 698% - Payback period: 18M ÷ 125.6M = 0.14 years (1.7 months)

Chapter 6: Detective's Diagnosis—Ensuring Reproducibility Through Record-Check-Do

That evening, I contemplated the essence of the RCD cycle.

Skyline Logistics Inc. held the illusion of "replacing all screens at once." But changing all 280 screens at once involves enormous risk and cost.

With the RCD cycle, we first thoroughly Recorded: 280 screen registries, 60 user requests, complete technology stack. With Check, we identified the priority Top 10 and selected technology. With Do, we reconstructed the pilot screen (S001) and measured effects.

What's important is that execution without records is gambling. Accurately record the current state, check it, and execute. By running this cycle, we achieved reproducible phased reconstruction.

Development cost per screen reduced 81% (8M yen → 1.5M yen), 10 screens achieved annual effects of 125.6M yen, ROI of 698%, payback in 1.7 months.

"Don't replace all screens. Thoroughly implement RCD for Record-Check-Do. By accurately recording the current state, checking priorities, and executing in phases, reproducible modernization emerges."

The next case will also depict a story of reproducibility that begins with recording.

"RCD—Record, Check, Do. Execution without records is gambling. Accurately record the current state, check it, and execute. A phased approach creates true reproducibility"—From the Detective's Notes

Related Files