Vol.807元COBOLプログラマから見た、最近の「COBOL狂騒曲」に関する考察【連載:澤円】2019.01.30TwitterLINEFacebookHatena日々新たな技術が生まれるのと同じように、エンジニアの働き方やキャリア形成のあり方も刷新され、新たな潮流が出来つつある。トレンドをキャッチアップし、多様化する選択肢の中から自分の進むべき道を決めるのは難しい。IT子会社勤務を経て、1997年、外資系大手テクノロジー企業に転職、現在に至る。くのベンチャー企業の顧問を務める。世界No1プレゼン術』(ダイヤモンド社)/『あたりまえを疑え。皆さんこんにちは、澤です。Lambda』でCOBOLがサポートされるとか、厚生労働省の勤労統計不正の問題の原因は「COBOLが高齢者しか分からない特殊言語だからだ」と記者会見で発言したとか。こんなにCOBOLが話題になるのは、ボクが社会人になって初めてではないかと思います。そこで今回は、元COBOLプログラマから見た最近のCOBOLに関する一連の話題についてお話させていただきます。COBOLプログラマから始まった社会人生活ボクは社会人になって最初に触れた言語がCOBOLでした。文系学部卒のボクは、生命保険会社のIT企業に就職して、富士通のメインフレーム上でグループ会社向けの会計システムを開発していました。ボクがCOBOLのプログラマだったのは1992年から1995年までの間。誰もがインターネットに接続できるような時代ではありませんでした。使っていた端末も、まだDOSマシンだったと記憶しています。毎日毎日真っ黒の画面に向かってコードを打っていき、コンパイルをかけて構文エラーを発見し、修正してまたコンパイルして......という開発を繰り返していました。コンパイルにはかなりの時間を要したので、その間に作業はできません。ネットで調べもの~ということもできないので、COBOLの技術書を読んだりしていました。いや~~、まったくワクワクしなかったなぁ......という思い出がありますね。時は、なんと手書きでコーディングをして、それを「パンチャーさん」という人に渡して打ち込みをしてもらい、打ち込まれたコードを呼び出してデバッグするという今では考えられないようなオペレーションをしていました。コンパイルをするたびに、膨大な紙が出力されて、それを読んでデバッグするなんてこともやっていました。その当時にCOBOLでコーディングをすることで、ボクの頭は徐々にですがエンジニア脳にシフトしていきました。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」がどのような考え方でシステムと向き合っているのか、ぜひ参考にしてみてください。最新書籍『あたりまえを疑え。自己実現できる働き方のヒント』(セブン&アイ出版)セブン&アイ出版さんから、私の三冊目となる本が発売されました。自己実現できる働き方のヒント」というタイトルです。本連載の重要なテーマの一つでもある「働き方」を徹底的に掘り下げてみました。お手に取ってみてくださいね。澤円さんが教える働き方のヒント『あたりまえを疑え。転職サイトtypeは株式会社キャリアデザインセンターによって運営されています。