ROI事件ファイル No.376｜『Skyline Logistics社のサポート切れという時限爆弾』

第一章:サポート切れという時限爆弾——修正に3ヶ月、費用800万円

Globex CorporationのOODA事件が解決した翌日、今度は基幹システムの画面再構築に関する相談が届いた。第三十巻「再現性の追求」の第376話は、記録・確認・実行で再現性を担保する物語である。

「探偵、我々のシステムは、時限爆弾です。供給システムの開発フレームワークが、2024年にサポート終了しました。しかし、まだ使い続けています。そして、先月、ユーザーから画面修正の要望が出ました。『在庫確認画面に発注予定数を追加してほしい』。しかし、見積もりは800万円、期間3ヶ月。たった1つの項目追加なのに、です」

Skyline Logistics社 のIT部長、川崎出身の山田健太は、疲弊しきった表情でベイカー街221Bを訪れた。彼の手には、15年前に構築された供給システムの設計書(紙ファイル5冊)と、それとは対照的に「Framework Migration Proposal 2026」と記された画面再構築の提案書が握られていた。

「我々は、物流企業です。従業員2,800名。年商480億円。国内物流の基幹システムを運用しています。しかし、開発用フレームワークがサポート切れです。そして、画面の再構築を行いたいのですが、どの企業に依頼すればいいか分かりません」

Skyline Logistics社の現状: - 設立:1978年(物流企業) - 従業員数:2,800名 - 年商:480億円 - システム:供給システム、配送システム、倉庫管理システムなど - 問題:開発フレームワークサポート切れ、画面修正コスト高、ブラックボックス化

山田の声には深い危機感があった。

「供給システムの現状は以下の通りです。開発フレームワーク:Struts 1.x(2013年サポート終了)。開発言語:Java 6(2013年サポート終了)。データベース:Oracle 10g(2013年サポート終了)。全て、10年以上前にサポートが切れています。しかし、バックエンドのビジネスロジックは問題なく動いています。問題は画面だけです」

供給システムの構成:

システム規模: - 画面数:280画面 - バックエンドAPI:1,200個 - データベーステーブル:850テーブル - 開発開始:2010年 - 最終大規模改修:2015年

利用部門: - 物流管理部:120名 - 倉庫管理部:80名 - 調達部:60名 - 合計:260名

画面修正の実態:

Case 1:在庫確認画面への項目追加(2025年12月) - 要望:「発注予定数」列を追加 - 見積:800万円、3ヶ月 - 内訳: - 現状調査(Struts 1.xのコード解析):150万円、2週間 - 設計:200万円、3週間 - 開発:300万円、6週間 - テスト:150万円、3週間

Case 2:検索条件の追加(2024年8月) - 要望:「納品予定日」で検索できるようにしたい - 見積:650万円、2.5ヶ月 - 結果:予算不足で見送り

Case 3:ボタン配置の変更(2023年11月) - 要望:「登録」ボタンを画面下部に移動 - 見積:180万円、3週間 - 結果:予算不足で見送り

山田は深くため息をついた。

「さらに問題があります。ベンダーが固定されていません。各システムで依頼先が異なっており、都度改修に動いています。そして、どの企業に依頼すればいいか分かりません。展示会にも行きましたが、どの会社が良いか判断できませんでした。そして、現状のフレームワークがサポート切れなので、モジュールを書くとブラックボックス化してしまいます」

第二章:全画面一括リプレイスという幻想——記録がない混沌

「山田さん、全ての画面を一括でリプレイスすれば、全ての問題が解決すると思っていますか?」

私の問いに、山田は戸惑った表情を見せた。

「えっ、そうではないのですか? 最新のフレームワークに全画面を移行すれば、修正コストも下がると思っていました」

現在の理解(一括リプレイス型): - 期待:全画面を最新フレームワークに移行 - 問題:記録がなく、優先順位も不明

私は、記録・確認・実行で再現性を担保する重要性を説いた。

「問題は、『全画面を一括でリプレイスする』という考えです。RCD——Record、Check、Do。記録、確認、実行。まず現状を正確に記録し、確認し、実行する。このサイクルを回すことで、再現可能な段階的再構築を実現します。全画面を一度に変えるのではなく、優先度の高い画面から順に再構築します」

⬜️ ChatGPT｜構想の触媒

「全画面リプレイスするな。RCDで記録・確認・実行を徹底し、優先画面から再構築せよ」

🟧 Claude｜物語の錬金術師

「システムは、いつも『過去の記憶を失った迷宮』だ。記録することが最初の仕事」

🟦 Gemini｜理性の羅針盤

「RCDサイクルを回せ。記録なき実行は博打だ。確認なき実行は失敗する」

3人のメンバーが分析を開始した。Geminiがホワイトボードに「RCDサイクル」を展開した。

RCDサイクル: 1. Record(記録):現状を正確に記録する 2. Check(確認):記録内容を検証・評価する 3. Do(実行):確認結果に基づき実行する 4. Record(記録)に戻る:実行結果を記録し、次のサイクルへ

「山田さん、まず現状を正確に記録することから始めましょう」

第三章:Phase 1——Record(記録)で現状を可視化する

ステップ1:画面台帳の作成(2週間)

記録項目: - 画面ID、画面名、機能概要 - 利用部門、月間アクセス数 - 最終更新日、修正履歴 - 技術スタック(フレームワーク、ライブラリ) - バックエンドAPI依存関係

記録方法: - 既存の設計書(紙ファイル5冊)をデジタル化 - ログ解析ツールでアクセス数を集計 - 各部門にヒアリング(利用頻度、重要度)

画面台帳(一部抜粋):

280画面の分類: - 高頻度・高重要度:45画面(16%) - 高頻度・低重要度:30画面(11%) - 低頻度・高重要度:55画面(20%) - 低頻度・低重要度:150画面(54%)

ステップ2:ユーザー要望の記録(2週間)

過去3年間の修正要望を記録:

要望の分類: - 項目追加・変更:28件(47%) - 検索条件追加:18件(30%) - 画面レイアウト変更:10件(17%) - その他:4件(6%) 合計:60件(過去3年間)

重要な発見: - 60件の要望のうち、実施されたのは12件(20%)のみ - 残り48件(80%)は予算不足で見送り - 特定の画面(S001、S002、S004)に要望が集中(全体の45%)

ステップ3:技術スタックの記録(1週間)

現状の技術スタック:

フロントエンド:
  - Struts 1.x (2013年サポート終了)
  - JSP + JSTL
  - jQuery 1.8 (2013年リリース)

バックエンド:
  - Java 6 (2013年サポート終了)
  - Spring 2.5 (2009年リリース)
  - Oracle 10g (2013年サポート終了)

ブラックボックス化の実態: - 開発担当者5名のうち、3名は既に退職 - 残り2名も詳細は把握していない - コメントが少なく(全コードの5%)、可読性が低い - 設計書と実装が乖離している箇所が多数(約30%)

第四章:Phase 2——Check(確認)で優先順位を決定する

ステップ4:画面の優先順位評価(1週間)

評価軸: - A軸:月間アクセス数(1-5点) - B軸:ユーザー要望の件数(1-5点) - C軸:ビジネス影響度(1-5点) 合計点で優先順位を決定

優先順位Top 10:

Phase 1の対象:Top 10画面(全280画面の3.6%)

ステップ5:技術選定の確認(2週間)

候補フレームワーク:

Option 1:React + TypeScript(SPA型) - メリット:モダン、開発効率高い、エコシステム豊富 - デメリット:学習コスト高い、バックエンドAPI改修必要 - 見積:1画面あたり180万円

Option 2:Thymeleaf(サーバーサイドレンダリング型) - メリット:学習コスト低い、既存Javaコードと親和性高い - デメリット:画面遷移が遅い、モダンなUIが作りにくい - 見積:1画面あたり120万円

Option 3:Vue.js + Spring Boot(ハイブリッド型) - メリット:学習コスト中程度、バックエンド改修最小限 - デメリット:設計の複雑性 - 見積:1画面あたり150万円

RCDの観点から判断: - Record:既存バックエンドAPIは問題なく動作(記録済み) - Check:バックエンド改修を最小化すべき(確認結果) - Do:フロントエンドのみ再構築(実行方針)

決定:Option 3(Vue.js + Spring Boot)を採用 - 理由:既存バックエンドAPI活用、段階的移行可能

第五章:Phase 3——Do(実行)を段階的に行う

Month 1-2:パイロット画面(S001)の再構築

S001(在庫一覧)の再構築:

Record(記録): - 現状のStruts 1.x画面のスクリーンショット記録 - ユーザー操作フローを動画記録 - バックエンドAPIの仕様書作成

Check(確認): - ユーザー要望(発注予定数列追加)を反映 - UIデザイナーがモックアップ作成 - ユーザーレビュー実施(倉庫管理部5名)

Do(実行): - Vue.js + TypeScriptで新画面開発 - 既存バックエンドAPIを活用(改修不要) - テスト:単体テスト、結合テスト、UAT

開発期間:2ヶ月 開発費用:150万円

Month 3:効果測定とフィードバック

KPI1:開発コスト - Before(Struts 1.x修正):800万円 - After(Vue.js新規開発):150万円 - 削減率:81%

KPI2:開発期間 - Before:3ヶ月 - After:2ヶ月 - 削減率:33%

KPI3:ユーザー満足度 - アンケート実施(倉庫管理部120名) - 「操作性向上」:102名(85%) - 「表示速度向上」:95名(79%) - 「要望が反映されている」:108名(90%)

重要な発見: - Vue.jsでの再構築は、Struts 1.x修正より安価・高速 - ユーザー満足度が極めて高い - バックエンドAPI改修不要で、リスク最小化

Month 4-12:Top 10画面の順次再構築

再構築スケジュール: - S001:Month 1-2(完了) - S004:Month 4-5 - S002:Month 6-7 - S012:Month 8-9 - S008:Month 10-11 - 残り5画面:Month 12-翌年3月

年間効果(10画面再構築):

開発コスト削減: - Before:800万円 × 10画面 = 8,000万円(Struts 1.x修正の場合) - After:150万円 × 10画面 = 1,500万円(Vue.js再構築) - 削減額:6,500万円

保守コスト削減: - サポート切れフレームワークのセキュリティリスク対応費用:年間800万円 - 新フレームワークの保守費用:年間200万円 - 削減額:600万円/年

ユーザー生産性向上: - 画面操作時間:平均25%短縮 - 対象ユーザー:260名 - 年間削減時間:260名 × 1時間/日 × 25% × 240日 = 15,600時間 - 人件費削減:15,600時間 × 3,500円 = 5,460万円/年

合計年間効果: - 開発コスト削減:6,500万円(初年度のみ) - 保守コスト削減:600万円/年 - 生産性向上:5,460万円/年 初年度合計:1億2,560万円 次年度以降:6,060万円/年

投資: - 10画面再構築:1,500万円 - プロジェクト管理:300万円 - 初期投資合計:1,800万円

ROI: - (1億2,560万円 - 0円) / 1,800万円 × 100 = 698% - 投資回収期間:1,800万円 ÷ 1億2,560万円 = 0.14年(1.7ヶ月)

第六章:探偵の診断——記録・確認・実行で再現性を担保する

その夜、RCDサイクルの本質について考察した。

Skyline Logistics社は、「全画面を一括でリプレイスする」という幻想を持っていた。しかし、280画面全てを一度に変えるのは、リスクも費用も膨大だ。

RCDサイクルで、まずRecord(記録)を徹底した。画面台帳280枚、ユーザー要望60件、技術スタックを全て記録した。Check(確認)で優先順位Top 10を特定し、技術選定を行った。Do(実行)でパイロット画面(S001)を再構築し、効果を測定した。

重要なのは、記録なき実行は博打だということだ。現状を正確に記録し、確認し、実行する。このサイクルを回すことで、再現可能な段階的再構築を実現した。

1画面あたりの開発コストは81%削減(800万円 → 150万円)、10画面で年間1億2,560万円の効果、ROI 698%、投資回収1.7ヶ月を実現した。

「全画面リプレイスするな。RCDで記録・確認・実行を徹底せよ。現状を正確に記録し、優先順位を確認し、段階的に実行することで、再現可能な近代化が生まれる」

次なる事件もまた、記録から始まる再現性の物語を描くことになるだろう。

「RCD——Record、Check、Do。記録なき実行は博打だ。現状を正確に記録し、確認し、実行せよ。段階的アプローチが、真の再現性を生む」——探偵の手記より

関連ファイル