システム刷新のプロジェクトを進行するにあたり、
増員のための派遣です。
規模は断然大きいのですが
どこかで経験したパターンのシステム刷新。
伝統のある会社。
COBOLがバンバン動いている。
結論から言うと、脱COBOL・脱固定長ファイルは「技術的には可能」だが、現実には“そのままでは絶対に無理”で、成功するには発想の転換と段階的な戦略が必須。
あなたが感じている「魔改造の積み重ね」「誰も全体像を把握していない」「周辺システムが勝手にDB化」「整合性が怪しい」「トラブル連鎖」──これは日本の大企業の“COBOL資産を20〜40年延命してきた組織”でほぼ共通の症状。
あなたの現場の状況は、むしろ典型的な“限界フェーズ”に入っている。
🎯 まず核心：脱COBOLは「COBOLを書き換えること」ではない
多くの企業が勘違いしているけれど、脱COBOLとは
- COBOL → Java/C#/Python に書き換える
- MF COBOL → 最新COBOLに載せ替える
- 固定長 → 可変長に変える
こういう“技術的な置き換え”ではない。
本質は 「40年積み上げた業務ロジック・データ構造・コード体系を、現代のアーキテクチャに再定義する」 こと。
つまり、
COBOLの書き換えではなく、業務の再構築（リビルド）。
だから、COBOLを捨てるかどうかは副次的で、
本丸は「業務・データの再設計」。
🧨 現状のまま“COBOLを書き換える”のが不可能な理由
あなたの説明から、典型的な「書き換え不能」条件が揃っている。
1. 魔改造の継承 × 魔改造の上塗り
20年前のMF COBOL化で魔改造を温存
→ その後も魔改造を追加
→ もはや誰も理解できない
これはCOBOLの問題ではなく、構造が崩壊している。
2. 固定長ファイルを源泉に周辺が勝手にDB化
- 元データは固定長
- 周辺は勝手にRDBを作り、独自変換
- 整合性が崩壊
- トラブル連鎖
これはデータモデルが死んでいる状態。
3. 属人化で“誰も全体像を把握していない”
COBOLの可読性ではなく、
40年の積み重ねで業務知識がブラックボックス化している。
4. 周辺システムが多種多様で、IFがカオス
- 連携仕様が文書化されていない
- 変換ロジックが散在
- どこが正なのか不明
これはシステムではなく“生態系”。
🧩 では、脱COBOLは現実的か？
✔ 技術的には可能
✖ 現状のままでは絶対に不可能
✔ 正しい戦略を取れば実現できる
つまり、
「COBOLを書き換える」アプローチは失敗する。
「データと業務を再定義する」アプローチなら成功する。
🔧 現実的に成功する企業が取っている戦略
① 固定長ファイルを“神データ”として扱うのをやめる
- データモデルを再定義（正規化）
- コード体系を再設計
- マスタを統合
- データガバナンスを導入
② COBOLのロジックを“移植”ではなく“再設計”する
- 1行1行の移植は地獄
- 業務フロー単位で再構築する
③ 段階的にレガシーを切り離す（Strangler Fig パターン）
- 既存COBOLを生かしつつ、新機能を外側に構築
- 徐々にCOBOLの領域を縮小
- 最後にCOBOLを撤去
④ 周辺システムのIFを統合し、変換ロジックを中央集約
- ESB / API Gateway / ETL基盤を導入
- 変換ロジックを一元管理
⑤ “業務の暗黙知”を形式知化するプロジェクトを先にやる
- COBOL解析より、業務ヒアリングが重要
- 仕様書がないなら作るところから始める
🧭 あなたの現場はどのフェーズか？
あなたの説明から判断すると、現場はレガシー崩壊の最終フェーズにある。
- データモデル崩壊
- 業務知識の喪失
- 周辺システムの乱立
- トラブル連鎖
- 誰も全体像を把握していない
これはCOBOLを捨てるかどうか以前に、システムの“土台”が壊れている。
🔥 結論：脱COBOLは「できる」。ただし“COBOLを書き換える”のではなく“業務とデータを再構築する”ならできる
あなたの直感は正しい。
伝統ある大企業ほどこんな状況に陥っていると思っている
その通り。
そして、成功している企業は
- COBOLを捨てるのではなく
- COBOLに縛られた“古い業務モデル”を捨てている
COBOLは副次的な問題で、
本質は業務・データ・アーキテクチャの再構築。
リンク
ムラゴンブログも書いています。 よければご訪問ください。 日記ですけど。
ヘルメットはレーシングドライバー Juju さんのものです。応援してます。
界隈、いろいろ問題もあるのですけどね。
ランキングバナー
クリックしていただけると嬉しいです。
