えっ、コードを書く前に“言語そのもの”を日本企業が握っていた世界があったのか!? ■社会人6年目、初めて知った衝撃 社会人6年目、システムの現場に深く入り込んだときだった。 私はそれまで、プログラム言語は“誰かが作ったものを使うもの”だと思っていた。 Javaにはサポート会社があり、Sun Microsystemsが方針を決める。 Pythonにもルールがあり、コミュニティが進化をリードする。 つまり、「言語は世界のどこかが決めるもの」。 そう信じて疑わなかった。 だが、日立に入って初めて、その前提が崩れる。 ■日立が“COBOLを作っていた”という事実 有名なプログラム言語であるCOBOL。 金融、基幹システム、社会インフラ——日本の根幹を支えてきた言語だ。 そのCOBOLを、日立が作り、リードしていた時代があった。 協議会を作り、仕様を整え、改善を重ねる。 まるで今のPythonやJavaのように、「ルールそのもの」を握っていた。 これは単なる利用者ではない。 “言語の設計者”としての立場だ。 ■メインフレームと一体化した言語戦略 当時の主戦場は、汎用機——メインフレーム。 巨大な1台のサーバーに、すべてを詰め込む時代だ。 このメインフレームを導入する際、 単なるハードウェアでは終わらない。 プログラム実行基盤も含めて、ひとつの“完成されたシステム”として提供される。 そして、その中核にあるのがCOBOLだった。 つまり、メインフレームを導入する＝COBOLで作る。 言語は選択肢ではなく、“前提条件”だったのだ。 ■IBMと戦った日本企業の意地 世界ではIBMがメインフレーム市場を席巻していた。 その巨大な牙城に、日本企業は真正面から挑んでいた。 日立は、その中で単なるハード競争では終わらない戦いを選ぶ。 ハードを作り、基盤を作り、 そして、その上で動く言語まで作る。 つまり、“スタック全体”で戦っていた。 メインフレームに入っているCOBOL。 そのCOBOL自体も進化させていく。 オリジナルのCOBOLをベースにしながら、 実運用に合わせて改善を重ねる。 この一連の動きは、まさにプラットフォーム戦略そのものだ。 ■言語を握るということの意味 言語を作るということは、単なる...
動くシステムはある。でも未来のJava版をどう描くか？ ああっ、まるでパズルのピースが逆さまに飛んでくるようだ！ 私が任されたのは、金融システムのCobolからJavaへの変換プロジェクトでの構成管理だ。 すでにCobolで動いているシステムがあり、設計書も残っている。 だが、それを最新のJava設計書に書き換え、プログラムとして組み上げなければならない。 多様なチーム、複雑な利害 プロジェクトには、日立製作所を1次受けとして、5社ほどの2次受けが参加していた。 各社、Cobolが分かるエンジニア、Javaが分かるエンジニア、そして金融分野に精通した設計者を揃えている。 優秀な2次受けベンダーの方々からの圧も相当で、緊張感は増すばかりだ。 Cobolの常識とJavaの自由度 Cobolの世界では、プログラムの作り方や書く環境はほぼ決まっている。 構成管理といえば、ソースの管理だ。 見出し部、環境部、データ部、手続き部などを決め、各チームの書き方を揃えるのが定石だった。 しかし、Javaとなると話は複雑になる。 書き方のルールだけでなく、パッケージ基準やソース構成、オブジェクト指向を活用した共通クラス構成まで考慮する必要がある。 設計書からDebug、バージョン管理まで まず着手したのは、Java設計書の整理だ。 Cobol設計書を参照しつつ、Javaのクラス構成やパッケージ体系に落とし込む作業。 各チームがバラバラに動くと、後々のDebugやテストで混乱する。 だからこそ、Debug順序も先に決めておく。 構成管理の肝は、バージョン管理だ。 Javaのように複雑な環境では、少しのずれが全体の破綻につながる。 GitやSVNを使い、各チームのコミットルールを統一する。 コミット単位、ブランチ戦略、マージ方針まで細かく定め、2次受け全体で共有する。 学びと挑戦の統合 一方で、Cobol時代の常識は無視できない。 既存の環境・手続き・データ部は大きな制約条件だ。 それを踏まえつつ、Javaのモダンな書き方を適用する。 オブジェクト指向の利点を活かし、共通クラスやライブラリの再利用も進める。 毎日の会議では、5社の代表者が設計書とコードの違いを詰める。 Cobol出身者の意見、Javaエン...