📘

COBOLと業務システムについて

に公開

まえがき

2030年に富士通社がメインフレームより撤退することが決まり(2035年サポートも終了)[1]
オープン化が急がれる中でCOBOLの話をよく聞くようになってきた昨今。
COBOLそのものと、COBOLがよく使用される業務システムについて、今まで触れてこなかった方々がそれらに関するイメージを持てるように記事を作成してみました。

COBOLってなに?

概要

COBOLはCODASYL(コダシル)という機関によってメンテナンスされており、
日本では主に金融機関の基幹システム、大手企業の業務/基幹システム、公官庁などの公共システムなどで使用されています。

特徴を簡潔にまとめると、、
・ 英語に似た構文で記述し、(冗長ではあるが)可読性に優れる
・ データ構造を厳密に定義できるため、固定長データの処理が得意
・ 数値を内部的に10進数で保持できるため、高い計算精度を持つ[2]

これらの特徴とメインフレームの性能とを併せて、大量データの処理を実現しています。

COBOLの種類

CODASYLが標準規格を制定しており、各ソフトウェアベンダーがその規格に準拠したコンパイラや、独自の拡張機能を提供しています。
CODASYLによる標準規格と各ベンダーの製品の一部を紹介します。

①CODASYLによる標準規格 ⇒ リンク参照

②ベンダーの製品(代表例)

製品名 ベンダー 使用可能環境 備考
IBM COBOL IBM社 メインフレーム(IBM製) なし
Micro Focus COBOL マイクロフォーカス社 メインフレーム
UNIX
Linux
Windows etc...
なし
NetCOBOL 富士通社 メインフレーム(富士通製) なし
GnuCOBOL
⇒旧: OpenCOBOL
なし Linux
Windows etc...
オープンソース

業務システムってなに?

概要

企業や組織が日々のビジネス活動(=業務)を効率的かつ正確に遂行するためのシステムです。
そのため、ユーザー層としては事業会社の社内の方々になります。

業務系システムと並んでよく目にするものとして、基幹系システム、情報系システムがあります。

  1. 基幹系システム
    企業の事業活動の根幹となる、必要不可欠な主要業務を処理するためのシステム。
    システムトラブルとなると、事業活動に支障をきたすため、安定性が最高レベルで求められます。

    例)生産管理システム、販売管理システム、在庫管理システム、財務・会計管理システム、
    人事・給与管理システム、銀行の勘定系システム、保険会社の契約管理システム

  2. 情報系システム
    基幹系業務システムに蓄積されたデータを活用、分析し、情報共有、意思決定の支援を行うためのシステム。
    システムトラブルとなると、クリティカルな影響は基幹系システムと比べれば低くなります。

    例)顧客管理システム (CRM)、営業支援システム (SFA)、データ分析ツール (BIツール)

定義的にはこのように分けられるようですが、この記事では基幹系業務のシステム、情報系業務のシステムをいう捉え方をして、まとめて業務システムとして表現することとします。

環境やアーキテクチャ関連

WEB系との対比

システム 動作環境 設計思想 エンドユーザー
業務システム 汎用系
オープン系
モノリシック 事業会社内の受発注担当者など
WEB系システム WEB系 マイクロサービス 不特定多数のサービス利用者

動作環境について

  1. 汎用系
    大型で高性能なコンピューター(メインフレーム)ひとつだけでシステムを構成します。
    メインフレームは専用OSで稼働しており、各JOBのコントロールはJCLというスクリプト言語で制御します。

    ※汎用系というとオフコンなども含まれてしまいますが、ここではメインフレームについて触れています。

  2. オープン系
    複数のサーバーを組み合わせてひとつのシステムを構成します。
    それぞれのサーバーはUNIX、Linux系やWindowsといったOSで稼働し、各JOBのコントロールは主にShell系のスクリプト言語で制御します。

    Shellの種類)bash、sh、zsh、csh、ksh

設計思想について

銀行の勘定系システムや、大手企業の業務システムは歴史が長いことが多く、昔の名残もあってモノリシックの考え方で組まれていることが多いと思います。
近年開発されたものや、システム更改などで見直しを図ったシステムでは、マイクロサービスの思想が組み込まれているものも存在します。

また、アーキテクチャではなく設計時の考え方としては、何の/誰のためのシステムかによってその形は大きく異なります。
また扱うデータの性質(個人情報を含むか、取引先の情報を含むかなど)も重要な要素です。

法的要件
 個人情報保護法、電子帳簿保存法、業界特有の法律(金融業法、製薬(GxP関連)、建設業法など) etc
業界的要件
 業界の自主基準や、すべてが手作業だった昔からあるフォーマット(請求書、契約書、伝票など) etc
企業的要件
 経営方針(システムにどれだけ重きを置くか)、監査基準、社内の運用 etc

さいごに

1エンジニアの業務内容という視点での話になりますが、業務システムを持つ事業会社のスタンスによっても大きく変わります。
事業会社で情報システム部を構えている企業と、SIerなどの企業に委託している企業がありますが、プロジェクトに参画する立場が、事業会社の情報システム部の1メンバーとして参画するのか、もしくはSIer企業の1メンバーとして参画するのかによって、業務内容は異なります。

いずれにせよ、稼働していることが当然であるシステムのため、システムトラブルがあった場合には後日ニュースにその事象が乗ることも珍しくありません。
陽の目を見ることは少ないですが、社会的インフラを支えている責任感と、社会の裏側(悪い意味ではないです笑)を垣間見れる特別感が私は好きで、普段触れる機会がない方にこういう世界もあるということを紹介できればと思い、当記事を作成しました。

脚注
  1. 2025年4月20日現在の情報です。 ↩︎

  2. C言語やJavaに代表される、浮動小数点演算による2進数から10進数の変換誤差が生じない
    [参考]結構、間違ってる"浮動小数"の理解。概数、真数というデータ型 ↩︎

91works Tech Blog

Discussion