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