株式会社圓窓　代表取締役
澤 円(@madoka510)

立教大学経済学部卒。生命保険のIT子会社勤務を経て、1997年、日本マイクロソフトに転職、2020年８月に退職し、現在に至る。プレゼンテーションに関する講演多数。琉球大学客員教授。数多くのベンチャー企業の顧問を務める。
著書：『外資系エリートのシンプルな伝え方』（中経出版）／『伝説マネジャーの 世界№1プレゼン術』（ダイヤモンド社）／『あたりまえを疑え。―自己実現できる働き方のヒントー』(セブン＆アイ出版)／『未来を創るプレゼン 最高の「表現力」と「伝え方」 』(プレジデント社)　Voicyアカウント：澤円の深夜の福音ラジオ　オンラインサロン：自分コンテンツ化　プロジェクトルーム

皆さんこんにちは、澤です。

最近、COBOLが熱いですね！
ためしに「COBOL」で検索をかけてみたら、結構ニュースになっています。

基本情報技術者試験で出題されるプログラミング言語からCOBOLが外れてPythonに代わるとか、『AWS Lambda』でCOBOLがサポートされるとか、厚生労働省の勤労統計不正の問題の原因は「COBOLが高齢者しか分からない特殊言語だからだ」と記者会見で発言したとか。

こんなにCOBOLが話題になるのは、ボクが社会人になって初めてではないかと思います。そこで今回は、元COBOLプログラマから見た最近のCOBOLに関する一連の話題についてお話させていただきます。

COBOLプログラマから始まった社会人生活

ボクは社会人になって最初に触れた言語がCOBOLでした。

文系学部卒のボクは、生命保険会社のIT企業に就職して、富士通のメインフレーム上でグループ会社向けの会計システムを開発していました。ボクがCOBOLのプログラマだったのは1992年から1995年までの間。

つまり、誰もがインターネットに接続できるような時代ではありませんでした。使っていた端末も、まだDOSマシンだったと記憶しています。

毎日毎日真っ黒の画面に向かってコードを打っていき、コンパイルをかけて構文エラーを発見し、修正してまたコンパイルして……という開発を繰り返していました。

コンパイルにはかなりの時間を要したので、その間に作業はできません。ネットで調べもの～ということもできないので、COBOLの技術書を読んだりしていました。

いや～～、まったくワクワクしなかったなぁ……という思い出がありますね。

ちなみに、ボクが勤めていた会社はIBMの汎用機も使っていて、そちらでもCOBOLは大活躍。新入社員研修の時は、なんと手書きでコーディングをして、それを「パンチャーさん」という人に渡して打ち込みをしてもらい、打ち込まれたコードを呼び出してデバッグするという今では考えられないようなオペレーションをしていました。

コンパイルをするたびに、膨大な紙が出力されて、それを読んでデバッグするなんてこともやっていました。でも、とにかくその当時にCOBOLでコーディングをすることで、ボクの頭は徐々にですがエンジニア脳にシフトしていきました。

その後、Visual Basicでプログラミングしたり、Lotus Notesの開発言語であるLotus Scriptを使ってアプリケーション開発をしたりもしました。

プログラマとしては、センスのかけらもなくホントにひどいものでしたが、とにかく「コードを書けばプログラムが動くことを体験した」という意味では、COBOLのプログラマ時代が原点です。

COBOL問題の根底にあるものとは？

さて、最近COBOLはずいぶんとやり玉に挙がっていたり、まるで言語そのものが悪者であるかのような扱いを受けていたりします。

「高齢者しか分からない特殊な言語」というような発言がありましたが、これはなかなかパワーワードであるなと思いました。

動いているシステムを移行させることに、たいていの顧客は難色を示します。ITの分からない経営層は「動いてるんだからいいじゃん」といって予算化をしたがりません。

実際の運用や開発をする側からすれば「今と同じことを処理させるためだけに、別の環境に移行するのは面倒くさい」と考えます。
ましてや、今の時点で動いているものが動かなくなったりしたら、それこそユーザー部門から袋叩きにあうのが明白だからです。

ということで、レガシーシステムはひっそりと動き続け、内包されているバグは実際に何かのきっかけで表出するまでは放置されるわけです。

その間に、実際に開発したプログラマも、デバッグができる運用担当者も、その職を離れてしまい、野良システム化がどんどん進んでいきます。これは、COBOLに限らず発生するリスクがあるのは言うまでもありませんよね。

今はバリバリ現役のJavaやC#でコーディングされたプログラムも、10年後はどうなるか分かりません。

「数百億のメインフレームとパソコンで動作するプログラムを一緒にするな」と怒る人などもいそうですが、とりあえず無視しましょう。というのも、そもそも視点が間違っているからです。どんな環境なのか、どんな言語なのかは、システムを長期間使うことといったん切り離して考えなくてはならないからです。

大事なのは、システムマネジメント体制のデザインです。

適切なシステム運用開発のマネジメントをしなければ、どんなシステムも不良債権化します。日本はシステムの運用開発を丸投げにしがちなので、この問題が非常に大きくなりやすい企業がたくさん存在しています。

ITなしではどの企業も経営ができないにもかかわらず、経営トップにはテクノロジー指南役が付いていなかったり、そもそもIT部門の責任者の中にエンジニアのバックグラウンドを持つ人がゼロだったりするわけです。

これでは、健全なシステムマネジメントはできません。システムは、ビジネスプランと完全に一致させた状態で開発させないといけません。

そのためには、経営陣やビジネス企画側はシステムの必要性や将来の運用体制に対して理解を深めておく必要があります。
また、システム側の人たちも、健全な運用をするために必要なリソースを、俯瞰的・長期的にとらえ、予算化をしたり開発・運用のプランを立てたりする必要があります。

経営視点でいえばこれは極めて当たり前の話なのですが、COBOLという一つのフィルターを通すことで、問題が顕在化してきているのかもしれません。

COBOLは長年にわたり、さまざまな大企業の基幹業務を担ってきました。開発と運用に多くの人員が配置され、高い専門性を持ったエンジニアたちが日夜開発と運用をすることで企業の経営を支えていました。

しかし、ここ20年のシステムの移り変わりの速さは、優秀なエンジニアを新しいテクノロジーへと駆り立て、レガシーシステムの運用開発とのリソースの二極化が起きてしまったのではないかと思います。

私の周りには、超優秀なエンジニアがたくさんいますが、40歳オーバーのエンジニアたちの多くは若いころにCOBOLを触っています。

しかし、今では全く違うテクノロジーのスペシャリストをやっていたり、経営を見据えたシステムマネジメント職に就いていたりします。そういう人たちは口をそろえて「今のCOBOL問題は言語のせいではない、マネジメント体制の問題だ」と言っています。

後継者の育成や、キャリアプランの一環としてのCOBOL技術者の配置、経営課題とテクノロジーのマッチング、そういった視点を持ってシステムと向き合わなかった結果が、今回のCOBOL問題に発展したということです。

優秀なエンジニアは、新しいテクノロジーが大好物だったりします。そうすると、一つの言語でずっと仕事をし続けるということは非常につらい状況になります。

優秀なエンジニアがさまざまな言語や開発環境、システムプラットフォームに触れられるようにするのと同時に、安定的にリソース確保ができるようなアウトソーシング体制、さらには常に「アップデート」が前提のシステム開発体制を確立することが必須条件になると思います。

最近は、このような考え方を持つ本物のCIOの方々もどんどん情報発信をしています。

例えば、ボクが尊敬するフジテック社CIOの友岡賢二さんは、COBOLの経験をお持ちで、ずっと事業会社のIT部門で働いておられます。レガシーシステムの重要性を理解しつつ、基幹業務のクラウド移行をどんどん進めるパワフルなCIOとして業界でもとても有名です。

友岡さんのような方のアウトプットには、今後の企業・組織のシステム運用に関わる数多くのヒントが含まれています。

エンジニアの皆さんは、こういった「本物のCIO」がどのような考え方でシステムと向き合っているのか、ぜひ参考にしてみてください。

セブン&アイ出版さんから、私の三冊目となる本が発売されました。
「あたりまえを疑え。自己実現できる働き方のヒント」というタイトルです。
本連載の重要なテーマの一つでもある「働き方」を徹底的に掘り下げてみました。
ぜひお手に取ってみてくださいね。

＞＞詳細はこちら

＞＞要約はこちら　澤円さんが教える働き方のヒント『あたりまえを疑え。』