自社のシステムがCOBOLで書かれていると分かったとき、多くの方が最初に心配するのは「もう扱える会社が残っていないのではないか」という点だと思います。検索してみても出てくるのは技術者向けの単価の話か、移行サービスの宣伝ばかりで、発注する側が知りたい「で、今どこに頼めるのか」には答えてくれません。
先に結論をお伝えすると、扱える会社はまだあります。国の機関が公開している調査では、COBOLは実際の開発案件で2番目に多く使われている言語です。ただし、探し方と伝え方を間違えると「対応できません」と断られます。そして本当に引き受け手を狭めているのは、言語そのものではなく動かしている環境のほうです。この記事では、言語ごとの実情、環境という制約、そして問い合わせのときに何を伝えるかを整理します。会社の見極め方や移行方式そのものは別の記事に譲ります。
この記事のポイント
- COBOLは実際の開発案件で2番目に多い言語で、この6年で割合はほとんど変わっていない
- 引き受け手を狭めるのは言語よりも、メインフレームやオフコンという稼働環境のほう
- 同じ古い言語でもCOBOLとDelphiでは案件数が50倍近く違う。ひとくくりにしない
- 問い合わせでは言語名だけでなく、行数・稼働環境・目的をセットで伝える
目次
レガシーシステムの言語は本当に頼めないのか
まずは事実の確認から始めます。ここを飛ばして「もう無理だろう」と決めつけると、まだ取れる選択肢を自分で捨てることになります。数字を見てから、本当の制約がどこにあるのかを切り分けていきます。
COBOLは今も2番目に多い開発言語
IPAが公開しているソフトウェア開発分析データ集2022には、実際の開発プロジェクトで使われた言語の集計が載っています。2016年度から2021年度の6年間、有効回答1,476件の内訳はこうなっています。
| 開発言語 | 件数 | 割合 |
|---|---|---|
| Java | 626件 | 42.4% |
| COBOL | 240件 | 16.3% |
| Visual Basic.NET | 137件 | 9.3% |
| C# | 112件 | 7.6% |
| C | 83件 | 5.6% |
COBOLは2番目です。しかも同じ資料には、2014年度から2019年度と比べてあまり差はないと書かれています。つまりこの数年で急激に消えているわけではありません。加えて、開発プロダクトの種別では改修・保守が51.5%を占めていて、新規開発の29.1%を大きく上回っています。今の開発現場の仕事の半分は、既にあるものに手を入れる作業だということです。
ただし、この数字の読み方には注意が必要です。このデータを提供しているのはインテック・SCSK・NTTデータ・TIS・富士通・日立製作所など、大手のソフトウェア開発ベンダ35社です。したがって正確には「大手SIerが手がける案件ではCOBOLが2番目に多い」であって、地域の中小開発会社も同じ比率とは限りません。それでも、扱っている会社がまとまった数で存在することの裏付けにはなります。
制約になるのは言語より稼働環境
では何が引き受け手を狭めているのか。私の経験では、言語よりも動かしている環境のほうが効いてきます。同じ資料のアーキテクチャの集計では、メインフレームが12.8%を占めています。決して少なくはないのですが、ここが対応可否の分かれ目になります。
COBOLという言語自体を読める技術者は、実は思ったほど珍しくありません。文法は素直で、経験のある技術者なら数週間で読めるようになります。難しいのはその周りです。メインフレームやオフコン固有のジョブ制御、専用の帳票出力、独自の文字コード、テスト環境をどう用意するか。この部分は書籍で学べるものではなく、その環境を触った経験がないと手が出せません。
だから問い合わせるときに「COBOLです」とだけ伝えると、相手は環境が分からないので慎重な返事しかできません。逆に「Windowsサーバー上のCOBOLです」と伝えられれば、対応できる会社の数はかなり増えます。同じCOBOLでも、汎用機の上か、オープン系に載せ替え済みかで、話がまったく変わるということです。
言語ごとに事情はかなり違う
もうひとつ押さえておきたいのが、「古い言語」とひとくくりにしないことです。先ほどの調査で見ると、同じ資料の中でも案件数には大きな開きがあります。
| 言語 | 調査での件数 | 発注側から見た状況 |
|---|---|---|
| COBOL | 240件 | 対応できる会社は探せば見つかる |
| Visual Basic.NET | 137件 | 技術者は多いが旧VB6からの移行は別問題 |
| PL/I | 4件 | 対応先が非常に限られる |
| Delphi | 5件 | 対応先が非常に限られる |
COBOLとDelphiでは案件数が50倍近く違います。同じ「レガシー言語」と呼ばれていても、探せば見つかるものと、本当に相手が限られるものがあるということです。自社の言語がどちら側かによって、動き方の緊急度は変わります。
特に注意したいのが、表計算ソフトのマクロや簡易データベースで作られた業務ツールです。言語としては新しくても、作った本人しか分からない状態になっていれば、引き受けてくれる会社を探すのはCOBOL以上に難しくなります。社内に読める人がいなくなる問題そのものへの備えは、レガシーシステムの人材不足はどうする？退職前に決めることで整理しています。
単価が上がる前提で考える
今すぐ頼めるとしても、費用が今のままとは限りません。対応できる技術者の高齢化が進んでいるため、単価は上がる方向に動きます。ここは断定できる数字がないので、構造だけ押さえておいてください。
単価が上がる理由はシンプルで、供給が減る一方で需要が消えないからです。動いているシステムは止められないので、保守の仕事はなくなりません。人が減れば、残った人の時間の取り合いになります。しかも高齢の技術者が引退すると、その分は新しく供給されにくい構造です。
発注側としてやっておきたいのは、保守契約を更新するタイミングで「今後2〜3年の単価の見通し」を聞いておくことです。値上げの打診が来てから慌てるより、先に想定を共有しておいたほうが判断の時間を作れます。なお、AIで変換すれば安く済むのではという期待については、効く工程と効かない工程がはっきり分かれるので、レガシーシステムの移行にAIは使える？安くなる工程と限界のほうで整理しています。
レガシーシステムの言語を扱える会社の探し方
ここからは実際の探し方です。検索して上位に出てくるのは移行サービスの会社ばかりなので、それ以外の系統も含めて当たり先を広げると見つかりやすくなります。
どこに残っているかを知る
対応できる会社は、大きく4つの系統に分かれます。それぞれ得意なことも費用感も違うので、自社の目的に合うところから当たってください。
ひとつ目は大手SIerです。先ほどのデータが示すとおり、案件としては一定量を持っています。ただし小規模な保守だけを頼むと単価は高くなりがちです。ふたつ目は移行を専門にしている会社で、検索で最初に出てくるのはたいていこの系統です。作り替えを前提にした提案が中心になります。
みっつ目が見落とされやすいのですが、地域の中小開発会社です。長く同じ業種のシステムを手がけてきた会社には、その環境を触れる人が残っていることがあります。全国区の検索では出てきにくいので、地元の商工会議所や取引先の紹介から辿るほうが早いこともあります。よっつ目は現行のベンダーで、範囲を絞れば残ってくれる可能性があります。会社そのものの見極め方は、レガシーシステムの刷新は誰に頼む？開発会社の選び方で整理しています。
問い合わせで最初に伝えること
探し方と同じくらい大事なのが、伝え方です。「COBOLのシステムの保守をお願いできますか」だけでは、相手は判断できないので曖昧な返事になります。次の情報をセットで伝えると、可否の返事が具体的になります。
問い合わせのときに伝える情報
- 言語と、動かしている環境（汎用機・オフコン・Windowsサーバーなど）
- おおよその規模（プログラム本数、分かれば行数）
- 今も現行ベンダーが保守しているか、すでに止まっているか
- 設計書が残っているか、どの程度残っているか
- 頼みたいのは維持なのか、作り替えなのか、まず調査だけなのか
いちばん効くのは最後の項目です。「維持したい」のか「作り替えたい」のかで、話を聞くべき会社が変わります。ここを伝えずに問い合わせると、相手は自社の売りたいサービス側で提案してくるので、噛み合わないやり取りが続くことになります。
規模については、正確な行数が分からなくても構いません。「画面が何本、帳票が何種類、バッチ処理が何本」という粒度でも、相手は工数の当たりを付けられます。分からない場合は、その旨をそのまま伝えたほうが早いです。
維持と作り替えのどちらが安いか
頼める先が見つかったとして、次に来るのが「このまま維持するのと作り替えるのと、どちらが得なのか」という問いです。ここは単純な計算で当たりを付けられます。
比べるのは、年間の保守費用にあと何年使うかを掛けた金額と、作り替えにかかる費用です。たとえば保守が年300万円で、あと8年使うつもりなら2,400万円。作り替えが3,000万円なら維持のほうが安く見えます。ただしこの計算には2つ足すものがあります。ひとつは単価上昇分で、後半になるほど保守費は上がります。もうひとつは、その間に業務を変えられないことで失う機会です。
逆に、あと3年で建て替える予定の建物に大規模な修繕をしないのと同じで、残す年数が短いなら維持で十分です。判断が割れるのは残り5〜10年のときで、このレンジでは単価上昇と機会損失をどう見るかで結論が変わります。なお金額はあくまで考え方の例なので、実際の判断は個別の見積もりで確認してください。
それでも見つからないときの選択肢
何社か当たっても引き受け手が見つからない場合もあります。特にPL/IやDelphiのように対応先が限られる言語では起こりえます。その場合に取れる手が3つあります。
ひとつ目は、頼む範囲を狭めることです。全面的な保守は断られても、障害が起きたときのスポット対応だけなら受けてもらえることがあります。ふたつ目は、現行ベンダーに時間単価で残ってもらう形です。年間契約より相手の負担が軽いので、交渉の余地が出ます。
みっつ目は、保守で粘るのをやめて移行を前倒しする判断です。引き受け手が見つからないという事実そのものが、そのシステムの寿命を示しています。無理に延命するより、動いているうちに移すほうが安全です。複数社に同じ条件で対応可否を聞くなら、RFI（情報提供依頼書）テンプレートを使うと、体制や実績を同じ様式で確認できます。
レガシーシステムの言語についてよくある質問
- Q. COBOLを扱える会社はもう無いのですか？
- A. あります。IPAの調査では、COBOLは実際の開発案件で2番目に多い言語（1,476件中240件・16.3%）で、この6年間で割合はほとんど変わっていません。ただしデータの提供元は大手SIer中心なので、地域の中小開発会社も同じ比率とは限りません。探し方を変えれば見つかる、という程度に受け止めてください。
- Q. 言語より環境のほうが問題というのはどういう意味ですか？
- A. COBOLの文法自体は素直で、経験のある技術者なら比較的短期間で読めるようになります。難しいのは汎用機やオフコン固有のジョブ制御、専用帳票、独自の文字コード、テスト環境の用意です。ここは経験がないと手が出せないため、同じCOBOLでもWindowsサーバー上で動いていれば対応できる会社は大きく増えます。
- Q. 保守の単価はこれからどれくらい上がりますか？
- A. 断定できる数字はありませんが、上がる方向に動く構造にあります。対応できる技術者が引退で減る一方、動いているシステムの保守需要は消えないためです。保守契約の更新時に「今後2〜3年の単価の見通し」を確認しておくと、値上げの打診が来てから慌てずに済みます。
- Q. 問い合わせるとき、行数が分からなくても大丈夫ですか？
- A. 大丈夫です。画面が何本、帳票が何種類、バッチ処理が何本という粒度でも、相手は工数の当たりを付けられます。分からない項目は分からないと伝えたほうが早く、そのうえで現行調査から始める提案が返ってくることもあります。
- Q. 表計算ソフトのマクロで作った業務ツールも同じ扱いですか？
- A. 言語としては新しくても、作った本人しか分からない状態なら難易度はCOBOL以上になることがあります。仕様が文書化されておらず、業務の前提も本人の頭の中にあるためです。むしろこちらのほうが引き受け先を探しにくいので、担当者が在職しているうちに手を打つことをおすすめします。
