古いシステムでCOBOLが使われていることは知っていても、「コードは見たことがない」「ベンダー任せで中身を把握できていない」というプロジェクトマネージャーの方は少なくありません。日々の運用は問題なく回っているものの、刷新や外注切り替えの判断を迫られた途端、その“見えなさ”が大きな障壁となります。

COBOL資産は、今なお金融・公共・製造などの基幹システムで使われており、完全に置き換えられることは少ないのが現実です。そして今、多くの企業で問題となっているのが、「中身がブラックボックス化しており、誰も手を出せない」という状態です。

この記事では、COBOLを触ったことがないPMや発注者の方に向けて、「何を見ればいいのか？」「どう判断すればいいのか？」という視点をお届けします。専門的な文法解説ではなく、意思決定に役立つ“見る目”を養うことを目的としています。

この記事はこんな人にオススメ！

COBOL資産を保守・管理しているが、コードの中身がわからず判断に困っている

刷新や外注切り替えの検討にあたり、現状のCOBOL資産をどう評価すべきか知りたい

属人化リスクやブラックボックス状態に不安を感じており、外部パートナーとの連携を視野に入れている

COBOLが使われている資産とは？まず“棚卸し”をしよう

まず最初に重要なのは、「自社のどこにCOBOLが使われているか」を把握することです。COBOLは、販売管理、在庫、受発注、請求、人事給与、財務会計など、企業の根幹にかかわるシステムで使われてきました。中でも、バッチ処理や帳票出力に強みがあり、膨大なデータを一定のルールで処理するような業務に適しています。

とくにCOBOL資産は、RPGやPL/Iなど他のレガシー言語と混在しているケースもあり、「COBOLだけを切り出す」ことが難しいこともあります。まずは既存システム全体の構成図を引っ張り出し、「COBOLで書かれている範囲」を特定することから始めましょう。

加えて、データベースとの接続や外部I/Fの有無、保守ベンダーの体制、変更履歴の有無など、“つながりのある周辺情報”も含めた棚卸しが必要です。コードの詳細は見られなくても、こうした情報の整理だけで「刷新の難易度」や「保守の属人化レベル」がある程度見えてきます。

PMが押さえるべき“3つの見方”

（1）コード構成の見方

COBOLは、基本的に4つの「Division（区分）」で構成されています。

IDENTIFICATION DIVISION：プログラムの名前など
ENVIRONMENT DIVISION：実行環境の定義
DATA DIVISION：データの定義
PROCEDURE DIVISION：処理ロジック

実務上、PMが見るべきは主に手続き部(PROCEDURE DIVISION)です。ここにビジネスロジックが記述されており、「何をどう処理しているのか」がわかります。

COBOLは“自然言語に近い”と言われますが、実際には変数名やコメントの書き方によって読みやすさが大きく変わります。たとえば、「A001」などの無意味な変数名ばかりだったり、コメントが全くないコードは保守性が極端に低いと判断できます。これは「誰が見てもわかる」レベルの観察で可能です。

（2）データ構造の見方

COBOLはデータ定義が明示的で、データ構造を見るだけでもシステムの中身がある程度把握できます。とくに注目すべきは「PIC（ピクチャー句）」という表記です。

PIC X(10) や PIC 9(5)V99 のように書かれており、「文字列なのか（X）、数値なのか（9）、小数点があるのか（V）」といった情報が見て取れます。これによって、「この変数は通貨なのか」「日付なのか」「フラグなのか」などを推測できます。

このデータ構造の視点は、刷新を検討する際のフィールドマッピングやテスト観点としても活用できます。

（3）属人化・ドキュメントの見方

COBOL資産の多くは、「誰が書いたかわからない」「設計書が残っていない」という属人化の壁に直面しています。

まずは、以下の3点を確認しましょう。

  • 最終更新日はいつか？誰が対応したか？
  • バージョン管理はされているか？
  • 仕様書・設計書と実装のズレはないか？

さらに、運用担当者やベンダーに「最近このプログラムを触ったのは誰か？」をヒアリングするだけでも、“活きている資産”か“放置されている資産”かが判断できます。

属人化の度合いを把握することは、保守性だけでなく、事故リスクや再委託判断にも直結するため、可能な範囲で事前確認しておきましょう。

「刷新or維持」の判断で押さえるべき観点

すでに「COBOLは古いから刷新すべきだ」と考えている方も多いかもしれませんが、移行が現実的でないケースは非常に多くあります。
とくに以下のようなシステムは刷新が難航します。

  • ロジックが複雑すぎて仕様が追えない
  • 処理性能やデータ量が代替言語に向かない
  • 周辺業務がCOBOL仕様に最適化されている

また、移行自体が何年もかかる大規模プロジェクトになるケースもあり、「すぐにやる」のは不可能です。そういった場合は、まず以下の判断軸で資産を分類しましょう。

  • 改修頻度が高い？ → 将来の刷新候補
  • 安定運用中で数年改修なし？ → 維持を前提に体制整備
  • データ形式が標準的？ → 他言語との接続性を検討
  • 文書化されている？されていない？

これらを整理することで、「今すぐ刷新すべきか」「当面は維持すべきか」「一部刷新＋一部維持でいけるか」といった現実的な選択肢が見えてきます。

自社で対応が難しい場合は、外部パートナーの検討を

もし、自社内や既存ベンダーだけでCOBOL資産を維持するのが難しいと判断した場合、外部パートナーの活用も視野に入れるべきです。

最近では、ベトナムなどのオフショア企業でも、COBOL人材を育成・確保し、保守チームとして稼働している例があります。
こうした外部体制を活用することで、属人化や高騰する人件費といった課題を緩和することが可能です。

ただし、委託する側がCOBOLの中身を“まったくわかっていない”状態だと、適切な管理や評価ができません。だからこそ、PMが最低限の構造・判断軸を理解しておくことが、円滑な外部委託の第一歩になるのです。

まとめ：PMが“COBOLを読める”必要はない、でも“判断できる”視点は必要

COBOL資産を抱える企業にとって、プロジェクトマネージャーの役割はこれまで以上に重要になっています。COBOLのコードを読んで理解することが目的ではありません。見るべきポイントを押さえ、「現状をどうするか」を判断する視点を持つことが求められているのです。

  • どこにCOBOLが使われているのか？
  • どんな構造・データを持っているのか？
  • 属人化していないか？
  • 刷新すべきか、維持すべきか？

こうした観点を把握し、必要に応じて外部パートナーの力を借りながら、「継続可能なCOBOL資産の運用体制」を整えていくことが、今後の情報システム部門に求められる現実的な対応と言えるでしょう。

COBOL保守に悩む企業のための実践ガイドを公開中。
体制構築の具体策を1冊にまとめました。