Digital Heroes: Guide to IT World

えっ、プログラミング言語の“完成形”が日本にあっただと!? ■COBOLだけではなかった 社会インフラを支える巨大システム。その裏側で、日立はCOBOLを手掛け、協会もリードしながら、日本国内で確固たる地位を築いていた。 しかし、本質はそこでは終わらない。 彼らは“言語”だけでなく、もっと根本的なものに手を伸ばしていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■システムの核に踏み込む サーバを作る。これは分かりやすい。 だが、システムを構築する上で絶対に避けて通れないものがある。 それがDB、データベースだ。 世界を見渡せば、MicrosoftのSQL Server、IBMのDB2、OracleのOracle。 主要なDBはほぼ海外製品が席巻していた。 その中で、日立は挑戦していた。 それがHiRDB。 ■言語の“さらに内側”へ HiRDBは、Cosminexusなど日立のシステム基盤と連携するDBだ。 だが本当に驚くべきはそこではない。 そのHiRDBを操作するためのSQL、つまり“DBを動かす言語”まで、日立は自ら設計していた。 しかもその名称は、あえてのSQL。 ややこしいが、これはHiRDB専用のSQLである。 ■なぜ独自SQLが必要なのか 実務でDBを触るとすぐに気づく。 同じSQLでも、DBごとに微妙に構文が違う。 「あれ？」 「なんでこう書くんだ？」 そう思いながら、例外的なルールを覚えていく。 それが現場の現実だ。 ■“癖がない”という価値 だが、DBを極めた分析屋たちはこう言っていた。 「HiRDBのSQLが一番癖がない」 構文が整っている。 規則性がある。 理解しやすい。 つまり、最も“自然に使える言語”だった。 Oracleでも、SQL Serverでも、どこかで違和感に出会う。 だがHiRDBは違う。 その違和感を排除する方向で設計されていた。 ■技術の深さと広がらなかった理由 残念ながら、HiRDBは世界的に広く普及したとは言えない。 しかし重要なのはそこではない。 DBそのものを作り、 その上で動く言語まで設計し、 さらに“人にとって分かりやすい形”に整える。 このレベルの要素技術を内製できるエンジニア集...

 えっ、コードを書く前に“言語そのもの”を日本企業が握っていた世界があったのか!? ■社会人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エン...

ああっ、気がつけば日本の金融システムの心臓部に手をかけている！ 社会人6年目の私は、少しずつ大きなプロジェクトに参加してきた。最初は数人規模、次第に十数人、そして開発人員が最大八十人規模のチームをリードするまでになった。百人規模でもリードできる自信はあった。しかし、次に待っていたのは最大200人規模のプロジェクト。しかも、対象は日本の根幹を支える金融業界の中心となるシステムだ。このシステムが止まれば、新聞に載るどころの話ではなく、たぶん現場では人の生活や仕事に直接影響が出る。それを意識した瞬間、身震いが止まらなかった。     大規模でも“改善プロジェクト” 200人規模と言っても、大規模プロジェクトとしてはそこまで特異ではない。理由は、これは新規構築ではなく、改善プロジェクトだからだ。最初の構築時は壮絶だったらしいが、私が参加した時にはリリース後で、チームは100人にも満たなかった。 私が指示を受けたのはJavaの構成管理。しかし開発の中心はCobolでの管理が主流だった。Cobolでは管理方法を熟知していたが、Javaでの管理は初めて。サーバの構成、プログラムの構成、どのように本番に載せるか、テストはどう行うか、テスト環境の作り方、設定ファイルの扱い――構成管理の領域は多岐にわたる。プログラム中心で考えてきた私にとって、新しい専門分野への挑戦となった。 構成管理の現場 構成管理担当とは、開発段階から常に話してきた。新人のトレーニングでは、自分で全てやっていたこともある。しかし今回は違う。これは日本を支えるシステムであり、責任の重さが桁違いだ。ミスは許されない。どのサーバに、どの順番で反映するか。テストの順序、バックアップの取り方。すべてを設計し、チームに伝える必要がある。 新しい挑戦と学び このプロジェクトでは、ただコードを書くのではなく、チーム全体の作業効率やリスク管理も意識することが求められる。構成管理という専門分野を深く理解し、現場での判断力を磨くこと。これが次世代のリーダーとしての成長につながると感じた。 百人規模の経験が、200人規模の現場で確実に生きる。自信と緊張が混ざり合う中で、私は初めて「自分が日本を支えている」という実感を持った。 私ならできる！明日から踏み出す

うわっ、日本の根幹が、まだこのコードで動いているなんて——。 社会人6年目。私はすでに5つほどのプロジェクトを経験していた。規模はどれも大きく、100人を超える体制はもはや特別ではない。「これが普通のITプロジェクトだ」と自然に思うようになっていた。周囲も同じだ。関わる案件はどれも社会インフラに近く、失敗が許されないものばかりだった。 そんな環境にいたからこそ、ある日ふとした瞬間に見た光景が、強烈に記憶に残っている。 ■巨大プロジェクトの“当たり前”に潜む違和感 日立製作所という巨大な会社の中で、私は一つの基幹システムの改修プロジェクトに関わっていた。関係者は100人を軽く超え、複数のベンダーが入り乱れ、会議は毎日のように続く。進捗、課題、品質——すべてが緻密に管理されていた。 だが、実際に手を動かす現場に入ったとき、私は思わず息を飲んだ。 画面に並んでいたのは、COBOLのコードだった。 整然と並ぶ英字と数字。長年積み重ねられてきたロジック。その一行一行が、日本の金融や物流、社会の根幹を支えている。 「これが、まだ動いているのか」 それは驚きというより、むしろ“現実”だった。 ■社会インフラを支える見えない技術 COBOLは古い言語だと言われる。しかし、そのシステムは何十年も止まらずに動き続けている。信頼性、安定性、そして実績。どれをとっても圧倒的だ。 だからこそ、簡単には変えられない。 100人規模のプロジェクトが当たり前になる理由も、ここにある。変更一つで影響範囲は膨大に広がり、テストには膨大な時間と人手が必要になる。結果として、プロジェクトは巨大化し、慎重になり、変化は遅くなる。 私はその中で、ある種の矛盾を感じていた。 最先端のITを語りながら、最も重要な部分は“変えられない技術”に依存している。 ■変革はなぜ進まないのか この構造は、日本のITが抱える本質的な課題を示している。 変えたい。でも、変えられない。 効率化したい。でも、リスクが大きすぎる。 だから現場は、巨大な体制と緻密なプロセスで“守る”ことに最適化されていく。 それは間違いではない。むしろ合理的だ。 しかし、その一方で、変革のスピードは確実に鈍る。 私は6年目にして、初めて気づいた。 「プロジェクトの大きさ」や「人数」ではなく、 本当に向き...

うわっ、終わったはずの戦場に、また呼び戻されるなんて ■支援のはずが、踏み込めない違和感 あのプロジェクトは、支援として入った現場だった。同期が苦しんでいる。だから助けたい——そう思って動いていた。 だが現実は違った。手を出そうとすると、どこかで止まる。 「そこは依頼範囲外です」 「契約上、難しいですね」 まるで見えない壁があるようだった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■組織をまたぐと“お金”が発生する構造 大企業では、組織間の支援にも明確なルールがある。 プロジェクトに必要な人員を計画し、その分の人件費を依頼元に請求する。 依頼元が顧客から収益を得ていれば、そこから支払われる。 もし得られていなければ、戦略案件として赤字覚悟で進める。 つまり、支援ですら“コスト”として管理される。 これは冷たい仕組みに見えるかもしれない。 だが、いくつかの企業を見てきた今なら言える。 この仕組みは、むしろ健全だった。 ■支援の終わりは、突然に ある日、判断が下った。 「依頼元からの予算が尽きた。撤退する」 あっけなかった。 我々の部隊は、そのプロジェクトから外れることになった。 残るのは、元の部署。 それが、本来の姿だった。 彼らは、自分たちでできると信じて仕事を取り、プロジェクトを立ち上げた。 しかし回らなかった。 だから、我々が支援に入った。 だが、お金がなければ、支援は続けられない。 ■残された責任 その後どうするか。 リスケするのか、顧客と再交渉するのか。 それは、依頼した部署の責任になる。 企業として一枚岩ではないのか？ そう感じる瞬間もあった。 正直に言えば、もっとできたと思っている。 あのとき、もう一歩踏み込めていたら——。 だが、上の判断は明確だった。 そして、次の指示が来た。 ■次のプロジェクトは、同じ場所だった 次の案件。 それは、日本の証券業界のど真ん中にある会社の基幹システム。 そして、その開発拠点は—— 前のプロジェクトで、必死に戦っていた場所だった。 また、同じ場所。 だが、役割は違う。 状況も違う。 あのときの悔しさが、胸に残っている。 ■ビジネスにおける“支援”の本質 この経験から見えたことがあ...