来期のレガシーシステム刷新プロジェクトの発足通知が届いたら、あなたはまず何を思うか。自分の担当領域にCOBOLの古い資産が含まれていると知ったとき、真っ先に浮かぶのは「もう構文を思い出せない」という不安かもしれない。その直後、日立の記事が目に入る。「COBOL人材が足りない」という通説に異議を唱える内容だ。安心しかけた課長たちが次の一文で止まった。本当に足りないのは、書ける人ではなく統括できる人だという。
flowchart TD
A[通説:人材不足] --> B[実態:統括不足]
B --> C[課長が担う橋渡し]
C --> D[評価されない構造]
足りないのはコードではなく統括#
日立の主張はこうだ。レガシー刷新で本当に必要なのは、COBOLを書ける人材ではない。プロジェクト全体を統括できる人材、アーキテクト、そして数十年分の業務ロジックを理解して次の設計に翻訳できる人材だという。
私が話を聞いてきた課長たちは口を揃えて言う。「COBOLを知らないから任されないと思っていたら、知らないことはそもそも論点ではなかった」と。求められていたのは構文力ではなく、業務とシステムの間に立つ判断力だった。
困難が拡大する理由は翻訳の壁#
日立が引く調査では、レガシーシステム保有企業の61%が刷新工程に困難を感じ、74%はその困難が拡大していると回答している（出典: 日立によるレガシーシステム刷新調査）。技術的な変換作業そのものより、要件の掘り起こしに時間がかかっているという構図だ。
数十年前に書かれたCOBOLには、当時の担当者しか知らない業務判断が埋め込まれている。それを今の言葉に翻訳できる人間が減る一方で、刷新の要求だけは積み上がる。この翻訳役は、日常的に板挟みで要件を通訳してきたプレイングマネージャーとしての課長の仕事とほぼ重なる。
だが評価シートにこの役割は載っていない。載っているのは進捗管理やコスト管理といった、AIに渡しやすい項目のほうだ（仕事の中身の総入れ替え）。
燃料を残す役割の書き直し方#
この役割変化は、あなたが新しくCOBOLを学び直すことでは埋まらない。求められているのは構文ではなく、業務とシステムをつなぐ判断だからだ。
- 評価シートの文言を書き換える 「COBOLが書けない」ではなく「業務ロジックとシステムの橋渡しができる」と、次回の自己評価に明記する。
- 要件の翻訳をAIに一次ドラフトさせる 会議で聞いた業務要件をその場でAIに書き起こさせ、翻訳ドキュメントとして残す。口頭で何度も説明し直す工数を削る。
- 構文の学び直しに時間を割かない 必要なのはアーキテクチャ判断力であって、若手エンジニアと同じ土俵でのコーディング力ではないと割り切る。
技術職からマネジメントに配置転換された人ほど、この判断を後回しにしがちだ（手放す前に計算する燃料コスト）。
逃げの一手#
橋渡し役を担わされても、役職や報酬がそのまま据え置かれる組織もある。その場合は、この役割の実績を社外向けの言葉に翻訳し直しておく。
転職サイトの職務経歴欄に「レガシー刷新の要件翻訳・統括経験」と一行加えておくだけでいい。今すぐ動く必要はないが、市場での値段を知っておく権利は手放さないことだ。
まとめ：足りないのは構文力ではなく翻訳役の値札#
日立が指摘した人材難は、COBOLの読み書きではなく統括と翻訳の不足だ。あなたがすでに日常でやっているその仕事に、まだ正しい値札がついていないだけだ。
本記事は AI が下書きし、管理人が監修しています。
