COBOL PARK株式会社 経営企画本部本部長
甲斐 芳和
大学卒業後、株式会社CSK(現SCSK株式会社)に入社。金融事業グループにて大手生損保会社のアプリケーション開発エンジニア、プロジェクトマネージャー、開発課長、開発部長兼サービスマネージャーを歴任。技術開発部長を経て金融システム開発本部の設立を主導し、2024年4月より同本部長付に。その後、SCSKとFPTジャパンホールディングスの合弁会社であるCOBOL PARK株式会社の設立を手掛け、2025年10月より経営企画本部本部長に就任。
2025年6月、「COBOL PARK株式会社」という企業が誕生しました。国内大手SIerのSCSK株式会社と、ベトナム最大手のグローバルIT企業・FPTソフトウェアの日本法人であるFPTジャパンホールディングスの2社によって設立された合弁会社です。
IT業界全体が生成AIやクラウドに沸く中、半世紀以上前に誕生し「レガシーシステム」の象徴ともいえるCOBOLを、あえて社名に冠した狙いと戦略とは、一体何なのでしょうか。
「『COBOLシステムをこのまま守ります』と言っている会社はあまりない。我々は逆張り的に、そこをやり抜くつもりです」
素朴な疑問に対しこう語るのは、同社の経営企画本部長を務める甲斐芳和さんです。
年商1,000億円規模の事業を目指すという同社。どのような勝算があるのか? この時代に「COBOL人材」をどう確保するのか? そして、今からCOBOLを学ぶ若手がいたとして、そのキャリアパスはどうなるのか? 同社の甲斐さんに聞きました。
メインフレームという「水道管」を、全て最新素材にする必要はない?
——初めに、このタイミングで社名に「COBOL」を冠した意図を教えてください。
甲斐:まず、決して「COBOLという言語だけを扱いたい」からこの社名を掲げているわけではない、ということをお伝えさせてください。
我々が目指すのは、日本企業を根底で支え続けている「メインフレーム」とも呼ばれるホストコンピュータのシステムを支え続けることです。
こうしたシステムにはPL/Iやアセンブラといった言語も使われていますが、世間一般に最も認知されている象徴的な言語として、COBOLを社名に据えました。
——メインフレームを支え続ける、ですか。一方で、経済産業省が「DXレポート」において「2025年の崖」(日本でDXが進まない場合年間最大12兆円の経済損失が発生し得るとの予想)と警鐘を鳴らし、レガシーシステムの刷新が急務とされて久しいです。すでに2026年を迎えましたが、現状をどう分析していますか?
甲斐:我々は「メインフレームはなくならないだろう」との予測のもとで、この事業を立ち上げました。
事実、世界的にはメインフレームの売上高は増加傾向です。国内でも大手金融機関や大規模製造業において現役で稼働し続けています。それは、メインフレームでなければ処理しきれない業務が存在するからです。
「古いシステムは悪だ」とする風潮も一部にはありますが、そもそもDXレポートが定義する「レガシーシステム」とは、単に古い技術を指すのではありません。
直近の経産省のレポートでも「メインフレーム等の古い技術や開発手法で構築されたシステムであっても、開発・運用維持保守体制が整備され、デジタル技術の活用やデータ連携が可能で、仕様が明確で継続的な機能改良が可能な適切な作りであれば、レガシーシステムではない」などとその定義が示されています。
――システム基盤そのものの古さよりも、使い勝手やデータ連携、保守体制が重要、ということでしょうか。
甲斐:はい。しかし現実の現場では「2025年の崖」に焦ったのもあり「とにかくシステムをクラウド化しよう、Javaで書き直そう」と非常に難易度の高いプロジェクトが多く立ち上がりました。
結果、途中で開発が頓挫したり、どうしてもクラウドへ移行しきれず、旧環境に「残ってしまったシステム」を抱えてしまったりするケースが後を絶ちません。
なぜこうなるのか? 第一にパフォーマンスの壁があります。銀行の夜間バッチのような莫大な超高速処理は、単一の筐体内で計算が完結するメインフレームの得意分野です。これをモダンなクラウド環境に移行しようにも、クラウドの分散処理では通信ラグで朝までに処理が終わらなかったり、無理に速度を出そうとしてインフラコストが跳ね上がったりしてしまいます。
第二に、言語と人材の壁です。システムをJavaに書き換えても、自社の情報システム部にCOBOLエンジニアしかいなければ、移行後の運用や保守が行き詰まるのは明白です。
結果として移行が頓挫するケースは少なくなく、我々のもとにも「旧環境に取り残されたシステムをどう扱えばいいのか」とのご相談が多く寄せられています。
――技術的な制約や人材面での行き詰まりがモダナイズを阻んでいる、と。
甲斐:そもそも、なんでもモダナイズすればいいわけではないはずです。私見ですが、メインフレームによる基幹システムは、「水道管」のような社会インフラに近い存在だと思うのです。
――水道管?
甲斐:水道管の本来の目的は「品質の良い水を安全に届けること」です。もしも定期的な点検やメンテナンスが行き届いており、漏水などのリスクがない場合、ただ「古いから」という理由だけで、全国の水道管を最新素材に一斉に取り替えたりはしませんよね。
基幹システムも同じで、要件を満たして安定稼働しているのなら、莫大なコストをかけて無理に最新技術ベースへとつくり替える必要はないと考えます。
ただし、水道管を放置すればヒビが入りますよね。
現在のレガシーシステムは、長年の度重なる改修や運用による「ブラックボックス化」と、当時の仕様を知るエンジニアの「高齢化による退職」が重なり、老朽化状態にあります。
そこで、我々がそのメンテナンスを担っていきたいのです。
——とはいえ昨今は「外部ベンダーに任せきり」とするのではなく、「顧客自身でシステムの全容を把握しておきたい」というニーズもあるのでは?
甲斐:そのニーズは間違いなく存在します。ただ「すべての会社にとって、すべてのシステムを完全に把握し、いつでも自社の手で自由に改修できる状態にするのが正解か」というと、それは少し違うと考えています。
お客様が抱える膨大なシステムの中には、自社の強みとなる「競争領域」と、そうでない「非競争領域」が混在しているからです。まずは、この2つを明確に切り分ける必要があります。
――「競争領域」と「非競争領域」?
甲斐:はい。例えばスマホアプリのUI向上や新たな金融商品の開発など、他社との差別化に直結する「競争領域」は、お客様自身でリソースを割き、柔軟に開発すべき部分です。
一方で、裏側で動く「利息計算」や「残高更新」などは、例としてNTTデータさんが地方銀行向けに共同の勘定系システムを提供して示しているように、各社で共通化できる「非競争領域」です。ここに自社の貴重なエンジニアのリソースを割いても、競争力には直結しません。
そこで我々は特に、お客様の手が回っていない「非競争領域のレガシーシステムの保守」をお引き受けしたいと考えています。設計書が失われていても、AIツールでCOBOLのコードからドキュメントを自動生成し、仕様を可視化した上で我々が保守を担います。そうして足元を安定させた上で、ゆくゆくは「残ったシステムを維持し続けるか」「クラウド等へ段階的に移行するか」という出口戦略をご提案してまいります。
――そのような戦略を見据えているのですね。
甲斐:現在の日本の金融業界だけでも、レガシー保守市場は年間約5,000億円規模に上ると試算しています。
ただし、市場内のITベンダーの多くは「古いシステムは捨てて、モダナイゼーションを進めましょう」と提案の軸足を移しています。
一方「お望みなら、COBOLシステムをそのまま守り抜きます!」と宣言している会社はあまりありません。我々はあえてこの逆張り戦略をとり、レガシー市場の約20%にあたる「年間1,000億円規模」のシェア獲得を目指しています。
ベトナムで目にしたのはまさかの「COBOLアカデミー」
——では、パートナーにベトナムのFPT社を選んだ経緯を教えてください。
甲斐:もともと2018年にSCSKとFPTさんはアジア太平洋地域での協業を見据え、ITサービス事業における包括提携を結んでいました。これが前提にあります。
転機はコロナ禍により、セキュリティの厳しい金融機関でもリモート開発が許容されるようになったこと。「リモートができるなら、オフショア開発も一気に進められる」と我々は考えました。
そこで、当時私が所属していたSCSKの金融部門の事業内容を整理すると、扱っている言語の筆頭はJavaで、2番目がCOBOLでした。
「エンジニア人材が潤沢なFPTさんでも、COBOLを扱うのはさすがに難しいだろうなあ」と思いつつ、私はJavaの開発を依頼しようとベトナムへと視察に向かいました。
ところが現地に訪れると、FPTさんから「実は『COBOLアカデミー』というものを運営しておりまして……」と売り込みを受けたんです。
――COBOLアカデミー、ですか?
甲斐:はい。社内でJavaを習得した若手の中から、さらにCOBOLにも取り組んでみたいエンジニアを募り、COBOLエンジニアを育成する教育カリキュラムをつくっていたのです。そうして現在、COBOLやJavaに特化したメインフレーム技術者が大勢いる、と。
――古い言語だからと忌避するどころか、進んでCOBOLを学ぶ人たちがいた?
甲斐:ええ。
FPTさんも社として日本のマーケットを重視しており、DX化に向けた日本企業の支援に力を入れています。そこにおいて、日本でレガシー技術に位置付けられている技術に対応できる人材も必要不可欠なので、COBOLアカデミーが設立されたという経緯があります。
加えて、SCSK内で改めて調査したところ、金融以外のさまざまな産業にもメインフレームが残っていることが分かったので、「これは1部門ではなく、1つの会社として取り組んだ方がいい」との判断から、FPTさんとの合弁会社の設立へと進みました。
そうして生まれたのがCOBOL PARKです。
――そもそも、なぜ基幹システムをめぐり海外のエンジニアと協力していく道を選んだのでしょうか。
甲斐:「労働人口が減りゆくなか、日本のエンジニアだけでレガシーなシステムを守り続ける必要があるのか?」という疑問があったのが大きいですね。
先ほどの利息計算の例のように、非競争領域の根幹は国内どころか世界中どこでも大きく変わりません。
そこで、日本の業務慣習や仕様の背景を読み解く工程などは日本側のエンジニアが中心となって担いつつ、実際の開発や保守にはFPTさんのエンジニアリング力もお借りする。こうしたパートナーシップが必要だと判断しました。
これによって日本側は人材不足の課題を解消しつつ、お客様のビジネスの核となる領域により注力しやすくなります。一方でFPT側のエンジニアにとっても、日本の厳しい品質基準のなかで保守ノウハウを身につけていくと、グローバル企業ですから、世界中のメインフレーム市場へその知見を横展開できるようになります。そのようなメリットが互いにあると考えています。
COBOLを御旗に。「大企業の伝統的採用」とも逆をいきたい
——日本側のエンジニア体制は、どのように構築していく予定ですか?
甲斐:今のところ、SCSKからの出向者が中心です。ただし2026年度からはCOBOL PARK独自の採用ルートを確立する方針です。
ここに、COBOL PARKという単独の会社として設立したメリットの1つがありまして。
――というと?
甲斐:SCSKのような一定の規模がある企業だと、どうしても長年築き上げてきた人事制度やキャリアパスがあるため、採用条件だけを大きく変更するのは容易ではありません。
しかし新会社であるCOBOL PARKなら既存の枠組みに縛られず、ゼロベースで柔軟な制度設計が可能です。
例えば「大卒以上」「〇〇歳以下」のような要件は設けず、働き方はフルリモートを前提とする。そうすることで、地方在住の方や子育て中の方、さらにはシニア層まで、多様な人材に門戸を開きたいと考えております。
——とはいえ、今からあえてCOBOLを学ぼうとする若手や未経験者は、実際に集まるのでしょうか。
甲斐:そこは確かに考慮すべきポイントです。
ただ、COBOLは開かれた「入り口」にもなり得る言語だと思うのです。
――入り口ですか。
甲斐:はい。ご存知の通り、COBOLは手続き型で、かつ比較的シンプルな言語です。ひとつ、私自身のお話をすると、新入社員研修時代にC言語に触れた時、お恥ずかしながらポインタと構造体の理解に苦戦しました。しかし情報処理試験が迫る中、選択言語をCOBOLに切り替えて勉強したところ、1~2か月程度の学習期間で合格できました。それほど、直感的に入りやすい言語だと捉えています。
そして、モダンな言語と比べて仕様が安定しています。
つまりは「ITエンジニアになりたいけれど何から始めればいいか分からない」という方に対して、学歴や職歴を問わず、キャリアの最初のステップとしてCOBOLエンジニアという道を提示する。そして安定した言語として「じっくりと実務に向き合い、システムの構造や業務知識を身につけられる」との訴求を行う。
そのような採用戦略が可能なのではないか? と考えています。
また会社設立を発表した直後から、ベテランのCOBOLエンジニアから「ぜひ働きたいのですが」という問い合わせもいただいています。当然、そうした熟練の技術者たちも積極的に迎え入れる方針です。
このように「COBOL」という言語そのものが、未経験者の入り口としても、ベテランの受け皿としても、採用において強力なフックになるのではないかと思うのです。
――しかし、COBOLを入り口としてスタートしたキャリアが、どうなっていくかも気になります。
甲斐:そこは幅広い選択肢を提供します。
COBOLはあくまで入り口です。重要なのはその実務を通じて身につく、「業務の背景やシステム仕様を読み解く力」です。AIによるコーディングの自動化が進んでいく中、こうした力こそが確かな武器になります。
この力を生かしていただき、他の言語も含め社会インフラを支え続けるシステム開発・保守のスペシャリストとしてのキャリアはもちろん、AIツールも活用しモダナイズの牽引を行うエンジニアとしての道も用意します。また、メインフレームには例えば「35年間の住宅ローンの支払い実績」のような膨大な確定データが眠っています。こうしたデータを生かし、新たなデータビジネスの提案を行うビジネスコンサルタントというルートもあり得ます。FPTさんとの協業によりグローバル案件に関われる機会も提供していきます。
——ベテランのCOBOL技術者たちは、どのような役割を担っていくのでしょうか。
甲斐:長年システムを支えてきた熟練のエンジニアには、現場での保守以外でもその力を発揮していただきたいと思っています。
何十年も稼働しているシステムには、「なぜここにこの謎のパッチが当たっているのか」といった、当時の担当者しか知らない経緯や知見が山のようにあります。彼ら——社内では敬意を込めて「レジェンドエンジニア」と呼んでいます——はそうした背景を知り、いわばお客様以上にシステムを理解している「生き字引」です。
ぜひ未経験のメンターとして、あるいは我々が導入を進めているAI解析ツールの精度を高めるためのアドバイザーとして活躍いただければと考えています。また、ベトナム側の「COBOLアカデミー」のカリキュラム開発にも参画していただくつもりです。日本の複雑な商慣習やシステム独自の歴史など、言語や文化の壁になりがちな暗黙知を現地の若手教育に直接組み込み、国境を越えたスムーズな保守体制を築く狙いもあります。
Anthropicのような「COBOLを書き換える」AIの台頭は脅威か?
——そういえば、COBOLといえば、ちょうど最近(編注:取材当時は2月下旬)のニュースで……。
甲斐:Anthropic社の件ですか?
——はい。米Anthropic社がCOBOLシステムのモダン化を支援するAIの仕組みを発表し、IBM社の株価が一時的に下落するなど大きな話題になりました。こうしたAIの台頭は、COBOL PARK社の事業にとって脅威になりませんか?
甲斐:突っ込まれるだろうなと思っていました(笑)。
結論から言うと、危機やピンチとは捉えていません。もちろん、脅威といえば脅威です。同時に、「むしろチャンス」でもあると捉えています。
確かに、ああいったAIを用いれば、アプリケーションレイヤーの言語をCOBOLからJavaへ自動変換することは容易になるでしょう。
しかし言語を変換できたからといって、お話ししたような「クラウドの分散処理で翌朝までに莫大なバッチ処理が終わるか」というパフォーマンスの壁や「移行後のJavaシステムを誰が保守するのか」という人材の壁が消えるわけではありません。
ビジネスの要件を満たし、安定稼働させるという根本的な課題は依然として残るのです。
——AIはあくまで、1つの道具に過ぎないという捉え方ですか?
甲斐:おっしゃる通りです。そう考えると、Anthropicが開発しているような技術は、我々自身の出口戦略コンサルティングにおいても、強力なツールになります。「この非競争領域のロジックなら、AIツールの活用もして短期間でコードを変換できます。その上で、インフラの最適化やその後の保守までも我々が担保します」と現実的な移行プランを提案しやすくなる。
仮に事業継続の維持・保守という領域そのものがAIによって縮小したとしても、その分、出口戦略やAIを活用したモダナイズ支援の仕事は増える。そのように捉えています。さらに、こうした技術の活用に力を入れるために、今期より「AI推進室」を立ち上げました。出資企業との連携を軸に、AIの専門性を有する技術パートナーとも順次協業を進め、メインフレーム領域におけるAI活用の社会実装を加速していきます。
——最後に、設立から半年が経った現時点での手応えを聞かせてください。
甲斐:金融だけでなく、ガス、電気、物流、自動車と、あらゆる産業でメインフレームは稼働しています。幅広い業種から「エンジニア不足でシステムを維持できないから手伝ってほしい」「モダナイズを進めているが、頓挫した時の保険として残存システムの面倒を見てほしい」など、さまざまなお問い合わせをいただいているところです。
本格的な案件化はこれからですが、設立前までは接点のなかった会社からの問い合わせが増えているのは確かです。
私たちのミッションは、社会インフラと化した技術を守り抜き、お客様に最適な出口戦略を提示すること。「このまま残す」「安全にモダナイズする」「移行期間中の保守を担う」——さまざまな選択肢を用意しながら、日本企業の事業継続と競争力強化を支えていきたいと考えています。
▲なお社名の「PARK」は、FPT社の創業者であるチュオン・ザー・ビン会長が好む言葉で、「多くの人々が協力し合う“集いの場”」との思いが込められているそう
取材・執筆:森 英信
編集:田村 今人
撮影:赤松 洋太

