COBOLを含むレガシーシステムの見直しでは、「現行を維持するか、全面刷新するか」という二択で議論されがちです。しかし、基幹システムには長年の業務ルール、外部連携、バッチ、帳票、例外処理が蓄積されています。システム全体を一括で判断しようとすると、影響範囲と費用を見通せず、計画が止まりやすくなります。
現実的な準備は、システムを機能や処理の単位に分け、「そのまま維持する」「保守性を改善する」「段階的に刷新する」「廃止・統合する」に仕分けることから始まります。
この仕分けには、技術の新旧だけでなく、業務上の重要性、変更頻度、障害リスク、知識の残り方、他システムとの依存関係を考慮する必要があります。本記事では、COBOL資産を機能単位で整理し、維持体制とモダナイゼーション計画を並行して進める方法を解説します。
現行COBOLをすぐに刷新できない場合でも、保守体制の構築、知識移転、仕様整理から準備できます。
COBOLサービス資料をダウンロードする
全面維持・全面刷新の二択では進みにくい
業務影響が大きく、一度に切り替えられない
基幹システムは、会計、契約、請求、在庫、顧客、決済など複数業務とつながっています。全面刷新では、機能開発だけでなく、データ移行、外部連携、並行稼働、利用部門の教育、障害時の切り戻しまで考えなければなりません。
現行仕様が分からず、新システムの要件を決められない
設計書が古い、改修履歴が残っていない、担当者の記憶に依存している場合、刷新対象の要件を正しく定義できません。現在動いている処理をすべて新システムへ移すと、不要になった業務まで再現する恐れがあります。
「古い技術」という理由だけでは優先順位を説明できない
経営や業務部門に対して刷新投資を説明するには、技術的な古さだけでなく、事業リスク、保守コスト、変更の遅さ、障害影響を示す必要があります。機能ごとに課題と効果を整理すると、段階的な投資判断がしやすくなります。
刷新を待つ間にも保守体制は必要
計画策定と移行には時間がかかります。その間に担当者が退職したり、現行ベンダーとの契約が終了したりすれば、刷新前に業務継続が難しくなります。モダナイゼーション準備と、現行を安全に維持する体制づくりは同時に進める必要があります。
最初に資産を5つの単位へ分ける
システム全体を一つの箱として捉えるのではなく、調査・判断できる単位へ分解します。
1. 業務機能
受注、請求、入金、在庫引当、契約更新など、利用者や業務部門から見た機能です。各機能について、利用部門、利用頻度、業務上の重要性、代替手段を整理します。
2. オンライン処理・バッチ処理
画面操作で実行される処理と、夜間・月次などで動くバッチを分けます。バッチは実行順序、前後関係、再実行条件、締め時間などが重要です。
3. データ
主要ファイル、テーブル、コード体系、履歴、保存期間、個人情報の有無を整理します。複数機能が同じデータを参照している場合、機能単位の刷新でもデータ層の依存を考慮しなければなりません。
4. 外部連携
他システム、金融機関、取引先、ファイル転送、API、帳票、周辺ツールとの連携です。連携先の変更可能時期、仕様管理者、障害時の影響を確認します。
5. 運用・保守作業
監視、ジョブ実行、データ補正、問い合わせ、障害対応、リリース、バックアップなど、人が行う作業も資産の一部です。システムを刷新しても、運用ルールを引き継がなければ業務は安定しません。
この5単位を一覧化すると、「どの機能がどのデータ・バッチ・外部連携・運用に依存しているか」を確認する土台になります。
機能単位で評価する5つの軸
軸1：業務上の重要性
停止した場合の売上、顧客、法令、決算、サプライチェーンへの影響を確認します。重要性が高い機能は、刷新優先度が必ず高いとは限りません。安定して動いているなら、まず保守体制を強化し、十分な検証期間を確保する判断もあります。
軸2：変更頻度と事業要求
制度改定、商品追加、顧客要望、組織変更のたびに改修が必要な機能は、変更のしやすさが重要です。改修に長期間かかる、影響調査が毎回大きい、テスト範囲を決められない場合は、改善・刷新の優先候補になります。
軸3：技術・運用リスク
利用している基盤、ミドルウェア、開発環境、ジョブ管理、バックアップ、監視などの状況を確認します。技術者不足、障害復旧の難しさ、テスト環境の不足、手作業の多さも含めて評価します。
「COBOLだから危険」と一律に判断するのではなく、その機能を継続的に保守できる人・環境・手順があるかを見ることが重要です。
軸4：仕様と知識の可視化状況
現状と一致する仕様書があるか、ソースコードを読める人がいるか、業務ルールや例外を説明できる人がいるかを確認します。
知識が特定担当者に集中している機能は、刷新の前にヒアリングと文書化を優先します。仕様が分からないまま刷新へ進むと、要件漏れや不要機能の再実装につながります。
軸5：依存関係と分離のしやすさ
他機能とデータや処理が密接に結びついている場合、単独で切り離すことは困難です。逆に、外部インターフェースが明確で独立性の高い機能は、段階刷新の候補になります。
依存関係を見る際は、プログラム呼び出しだけでなく、共有ファイル、共通マスター、バッチ順序、手作業での受け渡しも含めます。
4つの方針に仕分ける
評価結果をもとに、各機能を次の4つへ仮分類します。これは最終決定ではなく、調査と合意形成を進めるための整理です。
1. 維持する
業務上重要で、現在は安定しており、変更頻度が低い機能です。すぐに刷新するより、保守担当の複線化、手順書整備、監視改善、テスト環境確保を優先します。維持は「何もしない」ことではありません。安全に維持できる体制とナレッジをつくる投資が必要です。
2. 保守性を改善する
機能自体は残すものの、調査工数や手作業が多い領域です。仕様・処理フローの整理、テストの再利用、ログや監視の改善、手作業の標準化・自動化、担当者知識のチーム移管などにより、将来の刷新準備も進められます。
3. 段階的に刷新する
変更頻度が高い、事業要求へ対応しにくい、独立性が比較的高い機能は、段階刷新の候補です。参照系画面、帳票、外部向けインターフェースなど、境界を定義しやすい領域から切り出す方法があります。実際の適否は依存関係とデータ整合性を調査して判断します。
4. 廃止・統合する
利用頻度が低い、代替業務がある、重複機能が存在する場合は、新システムへ移さず廃止・統合する選択肢があります。利用者が少ないことだけでなく、法令上の保存、監査、過去データ参照、外部契約への影響を確認します。
仕分け表に残したい項目
機能ごとの判断を表にまとめると、経営・業務・IT・ベンダー間で議論しやすくなります。
- 機能名と業務目的
- 利用部門・責任者
- 利用頻度
- 停止時の影響
- 変更頻度
- 主なプログラム・バッチ
- 利用データ
- 外部連携
- 現行担当者
- 仕様書の有無と信頼度
- 主な保守課題
- 暫定方針
- 方針の根拠
- 次に必要な調査
重要なのは、判断できない項目を空欄にせず「未確認」と記録することです。未確認事項がそのまま調査計画になります。
仕様整理を刷新プロジェクトの前工程にする
COBOL資産の仕様整理では、コードから処理を抽出するだけでなく、業務上の意味と将来の要否を確認します。
コード・ジョブ・データから現状を可視化する
プログラム一覧、呼び出し関係、バッチフロー、入出力ファイル、テーブル、外部連携を整理します。AIを調査補助として使える場面もありますが、抽出結果は技術者が確認します。
担当者から判断理由を聞き取る
なぜその処理が必要か、どの例外が現在も使われているか、障害時にどう対応するかは、コードだけでは分かりません。退職・異動前にヒアリングし、用語集、FAQ、運用手順として残します。
業務部門と要否を判断する
技術的に存在する機能が、将来も必要とは限りません。業務部門が、維持・変更・廃止の判断へ参加する必要があります。
スマラボでは、COBOL保守体制の構築、担当者退職前の知識移転、既存ベンダーからの段階的移管、将来の刷新判断資料の整備を支援しています。
レガシー・COBOL維持体制構築を見る
維持体制と刷新準備を並行する
モダナイゼーション計画が完成するまで、現行システムは動き続けます。次の取り組みを並行すると、刷新前のリスクを抑えやすくなります。
保守担当を複線化する
特定担当者だけが対応できる状態を避け、レビュー、問い合わせ、障害対応をチームで分担します。
段階的な知識移転を行う
最初からすべてを引き継ぐのではなく、定型作業、問い合わせ、軽微な改修、障害対応など、範囲を分けて移管します。並行稼働で確認しながら、担当範囲を広げます。
改修のたびに資料を更新する
調査結果をその場限りにせず、機能一覧、データ定義、テスト、運用手順へ反映します。日常保守がそのまま刷新準備になります。
現行と新環境の境界を明確にする
段階刷新では、どちらのシステムが正となるか、データ同期、障害時の切り戻し、運用責任を明確にします。技術移行だけでなく、業務運用を設計します。
まとめ：まず「判断できる単位」へ分解する
COBOL資産の見直しは、全面維持か全面刷新かを先に決めるのではなく、機能・処理・データ・外部連携・運用の単位へ分解することから始めます。
評価する主な軸は次の5つです。
- 業務上の重要性
- 変更頻度と事業要求
- 技術・運用リスク
- 仕様と知識の可視化状況
- 依存関係と分離のしやすさ
そのうえで、「維持」「保守性改善」「段階刷新」「廃止・統合」に仮分類し、判断根拠と未確認事項を残します。
刷新を検討している場合でも、現行保守を止めることはできません。担当者の知識を文書化し、継続できる保守体制を確保しながら、機能単位で将来の選択肢をつくることが重要です。