まだシステム化していない会社は、
遅れているのでしょうか？
私はむしろ、幸運だと思います。
大企業や金融機関の中には、数十年前に作られたシステムを、今も止められないまま使い続けている組織があります。古いシステムが元気に動いているのではありません。会社や社会の仕事が依存し過ぎて、止めることも、簡単に取り替えることもできないのです。
有り体に言えば、システムがゾンビ化しています。
その象徴として、よく名前が挙がるのがCOBOLです。
しかし、COBOLという古いプログラミング言語そのものが悪いわけではありません。問題は、人間が業務の仕組みを説明できなくなり、コードだけが動き続けていることです。
そして、この問題は過去の話ではありません。
最新のノーコードでも、同じ状態は作れます。
COBOLは、なぜ金融機関の中枢に入ったのか
COBOLは「Common Business Oriented Language」、日本語にすれば「共通事務処理用言語」です。
1959年、コンピュータメーカー、利用企業、米国政府関係者らが参加したCODASYLという組織によって開発が始まりました。当時は、メーカーや機種が変わるとプログラムをそのまま移せないことが珍しくありませんでした。そこで、異なるコンピュータでも利用しやすく、企業の事務処理を共通の形式で記述できる言語が求められたのです。最初の仕様は1960年に公表され、その後1968年に標準化されました。IBMのCOBOL解説、米国国立標準局のCODASYL COBOL資料
COBOLは、科学技術計算よりも、企業の大量の事務処理を得意とします。
顧客番号、口座番号、日付、金額など、決まった形式のデータを「レコード」として扱う。大量のデータを順番に読み、集計し、更新し、帳票を出す。円やドルのような金額を、2進浮動小数点の誤差に任せず10進数として正確に扱う。こうした特徴は、給与計算、請求、保険、年金、予約、そして銀行業務と非常に相性が良いものでした。IBMは現在も、packed decimalを金融計算などで大きな数値を正確に扱う形式として説明しています。
金融機関では、預金、引き出し、振込、利息、手数料、融資、為替、締め処理、帳票作成など、膨大な定型取引を正確に処理する必要があります。そこで、大量処理と安定稼働を得意とするメインフレームと、その上で事務処理を記述するCOBOLの組み合わせが、中枢システムへ深く入り込んでいきました。
COBOLが今日まで残ったのは、役に立たなかったからではありません。
むしろ、よく働き、金融機関の中枢を支えることに成功したからです。
IPAが通信社ロイターの推計として紹介している数字では、COBOLは銀行システムの43％、個人取引の80％、ATMの95％に関係し、世界で約2,200億行のプログラムが稼働しているとされます。数字の定義には幅があるとしても、COBOLが現在も社会基盤を支えていることは間違いありません。IPA「レガシーシステムモダン化と、生き続けるCOBOLのリアル」
COBOLは、いつ「考古学」になったのか
最初に作ったプログラムが、そのまま何十年も残っているわけではありません。
新商品が増える。法制度が変わる。手数料体系が変わる。店舗、ATM、インターネットバンキング、スマートフォンアプリが接続される。他の金融機関や決済網との連携も増える。
そのたびに改修を重ね、例外処理と暫定対応を積み上げた結果、システムは金融機関の業務史そのものになりました。
ところが、コードを書いた技術者は退職します。組織も変わります。委託先も変わります。設計書が更新されなければ、文書と実際の処理が少しずつ離れていきます。そして最後には、なぜその条件分岐が必要なのか、なぜそのデータを翌日へ繰り越すのか、誰も説明できなくなります。
こうなると、システム開発ではありません。
考古学です。
コード、データベース、ログ、帳票、バッチ処理、昔の操作手順、ベテラン社員の記憶を「遺物」として集め、失われた業務仕様を発掘することになります。
COBOLが古いのではありません。
仕様が失われ、COBOLのコードが唯一の史料になっているのです。
反対に、設計の目的、データの意味、判断条件、例外処理、外部システムとの関係、テスト条件まで、現行システムと一致した状態で残っていれば、COBOLから別の技術へ移すことはできます。簡単ではなくても、「変えられない」わけではありません。
IBMも、COBOLの刷新は単なる別言語への翻訳ではなく、データ構造、実行基盤、外部連携、取引の整合性まで含むシステム全体の設計課題だと説明しています。IBM「What Is COBOL?」
つまり、移行を難しくしている根本原因は、COBOLの文法ではありません。
人間が、現在のシステムの意味を失っていることです。
動いているのではない。止められない
金融システムの難しさは、発掘調査のために簡単に止められないことです。
日本の全銀システムは、国内のほぼすべての預金取扱金融機関を接続し、振込や送金をオンラインで処理しています。2018年からは24時間365日稼働となり、2023年実績で年間約20億件、約3,671兆円を取り扱ったとされています。日本銀行掲載「全銀ネットの取組みについて」
もちろん、金融機関のすべてのシステムがCOBOLで動いているわけではありません。しかし金融サービス全体が24時間化したことで、中枢にある古い処理ほど、停止して一気に入れ替えることが難しくなりました。
これは、宇宙空間を飛び続ける人工衛星を、地上から修理するようなものです。
地上へ持ち帰れない。長時間停止できない。設計者はいない。設計図も完全ではない。それでも指令を送り、一部分ずつ動作を確認しながら修理しなければなりません。一つの判断を誤れば、通信そのものが途絶える危険があります。
飛行機にたとえるなら、乗客を乗せて飛び続ける旅客機のジェットエンジンを、一基ずつ止めて修理するような状況です。
だから古いシステムを一度に捨てるのではなく、旧システムを動かしたまま、新旧を並行稼働させ、処理を少しずつ移します。止められないから、複雑な移行になるのです。
最新のノーコードが、なぜCOBOLと似ているのか
ここまで読むと、「それは何十年も前の技術で作ったから起きた問題だ」と思うかもしれません。
しかし、最新のノーコードでも、同じ構造は生まれます。
ノーコードを否定するつもりはありません。試作品を早く作る、受付画面を用意する、情報を集める、小さな業務を自動化する。こうした用途では、ノーコードは非常に優れた道具です。
問題は、社内の誰も理解していない処理によって、会社の仕事が勝手に進むことです。
画面上で部品をつなげれば動く。担当者が設定した自動処理が、顧客へ連絡し、データを書き換え、承認を進め、請求情報を作る。しかし組織として、次の問いに答えられない。
- 何をきっかけに処理が始まるのか
- どの条件で判断が分かれるのか
- どのデータが変更されるのか
- 誰に何の権限があるのか
- 例外が起きたとき、どこまで戻すのか
- そのサービスをやめるとき、別の仕組みへ移せるのか
これでは、仕事は動いていても、人間が業務を管理しているとは言えません。
COBOLは、数十年かけて設計書と担当者を失い、ブラックボックスになりました。
ノーコードは、設計と運用を残さなければ、導入初日からブラックボックスになれます。
Microsoft 365の成熟度モデルでも、未成熟なノーコード／ローコード運用について、「その場で」作られ、設計・構築過程の文書がなく、ソース管理に相当する仕組みもなく、少数の詳しい人へ保守が依存する状態が挙げられています。一方、成熟した運用には、文書化、ソース管理、開発・テスト・本番環境の分離、そしてノーコード・ローコード・プロコードを切り替える判断が必要だとされています。Microsoft 365 Maturity Model
つまり、問題はコードを書くか、書かないかではありません。
組織が仕組みを理解し、責任を持って変更できるかどうかです。
レガシーとは「古いシステム」ではない
レガシーシステムという言葉は、古い言語、古いコンピュータ、古い画面を指すものとして使われがちです。
しかし本質は、古さではありません。
人間が、なぜその処理になるのか説明できない。安全に変更できない。止められない。別の仕組みへ移せない。
その状態になったとき、今日作った最新システムであっても、既にレガシー化は始まっています。
言い換えれば、レガシーシステムとは、古いシステムではありません。
変更と廃止の方法を失ったシステムです。
まだシステム化していない企業は、幸運である
だから、現時点で十分にシステム化していない企業は、それを遅れとだけ考える必要はありません。
過去のデータ形式に縛られていない。何十年分もの例外処理を抱えていない。24時間止められない旧システムもない。失われた仕様を発掘する必要もない。
現在の業務を整理し、生成AI時代に合った仕組みを、最初から設計できます。
ただし、焦って業務を既製SaaSやノーコードへ押し込めば、今から新しいゾンビを作ることになります。
試作、受付、情報収集、画面づくりには、ノーコードを積極的に使えばよいでしょう。一方で、会計、請求、在庫、権限、会社資産を変化させる処理は、誰が読んでも判断根拠を追え、テストでき、移行できる形で設計する必要があります。
重要なのは、すべてをコードにすることでも、すべてをノーコードにすることでもありません。
会社の中に、業務の意味を理解している人間を残すことです。
悪い意味での温故知新にしない
COBOLから学ぶべきなのは、「古い言語を使ってはいけない」という話ではありません。
どれほど優れた技術でも、人間が設計の意味を残さず、仕組みを理解できなくなれば、やがて止められないシステムになるという教訓です。
昔の失敗から学ぶための温故知新が、昔と同じ失敗を最新技術で繰り返す温故知新になってはいけません。
COBOLは、数十年かけて考古学になりました。
ノーコードを、導入初日から考古学にしてはいけないのです。
