ああっ、気がつけば日本の金融システムの心臓部に手をかけている！ 社会人6年目の私は、少しずつ大きなプロジェクトに参加してきた。最初は数人規模、次第に十数人、そして開発人員が最大八十人規模のチームをリードするまでになった。百人規模でもリードできる自信はあった。しかし、次に待っていたのは最大200人規模のプロジェクト。しかも、対象は日本の根幹を支える金融業界の中心となるシステムだ。このシステムが止まれば、新聞に載るどころの話ではなく、たぶん現場では人の生活や仕事に直接影響が出る。それを意識した瞬間、身震いが止まらなかった。 大規模でも“改善プロジェクト” 200人規模と言っても、大規模プロジェクトとしてはそこまで特異ではない。理由は、これは新規構築ではなく、改善プロジェクトだからだ。最初の構築時は壮絶だったらしいが、私が参加した時にはリリース後で、チームは100人にも満たなかった。 私が指示を受けたのはJavaの構成管理。しかし開発の中心はCobolでの管理が主流だった。Cobolでは管理方法を熟知していたが、Javaでの管理は初めて。サーバの構成、プログラムの構成、どのように本番に載せるか、テストはどう行うか、テスト環境の作り方、設定ファイルの扱い――構成管理の領域は多岐にわたる。プログラム中心で考えてきた私にとって、新しい専門分野への挑戦となった。 構成管理の現場 構成管理担当とは、開発段階から常に話してきた。新人のトレーニングでは、自分で全てやっていたこともある。しかし今回は違う。これは日本を支えるシステムであり、責任の重さが桁違いだ。ミスは許されない。どのサーバに、どの順番で反映するか。テストの順序、バックアップの取り方。すべてを設計し、チームに伝える必要がある。 新しい挑戦と学び このプロジェクトでは、ただコードを書くのではなく、チーム全体の作業効率やリスク管理も意識することが求められる。構成管理という専門分野を深く理解し、現場での判断力を磨くこと。これが次世代のリーダーとしての成長につながると感じた。 百人規模の経験が、200人規模の現場で確実に生きる。自信と緊張が混ざり合う中で、私は初めて「自分が日本を支えている」という実感を持った。 私ならできる！明日から踏み出す
うわっ、日本の根幹が、まだこのコードで動いているなんて——。 社会人6年目。私はすでに5つほどのプロジェクトを経験していた。規模はどれも大きく、100人を超える体制はもはや特別ではない。「これが普通のITプロジェクトだ」と自然に思うようになっていた。周囲も同じだ。関わる案件はどれも社会インフラに近く、失敗が許されないものばかりだった。 そんな環境にいたからこそ、ある日ふとした瞬間に見た光景が、強烈に記憶に残っている。 ■巨大プロジェクトの“当たり前”に潜む違和感 日立製作所という巨大な会社の中で、私は一つの基幹システムの改修プロジェクトに関わっていた。関係者は100人を軽く超え、複数のベンダーが入り乱れ、会議は毎日のように続く。進捗、課題、品質——すべてが緻密に管理されていた。 だが、実際に手を動かす現場に入ったとき、私は思わず息を飲んだ。 画面に並んでいたのは、COBOLのコードだった。 整然と並ぶ英字と数字。長年積み重ねられてきたロジック。その一行一行が、日本の金融や物流、社会の根幹を支えている。 「これが、まだ動いているのか」 それは驚きというより、むしろ“現実”だった。 ■社会インフラを支える見えない技術 COBOLは古い言語だと言われる。しかし、そのシステムは何十年も止まらずに動き続けている。信頼性、安定性、そして実績。どれをとっても圧倒的だ。 だからこそ、簡単には変えられない。 100人規模のプロジェクトが当たり前になる理由も、ここにある。変更一つで影響範囲は膨大に広がり、テストには膨大な時間と人手が必要になる。結果として、プロジェクトは巨大化し、慎重になり、変化は遅くなる。 私はその中で、ある種の矛盾を感じていた。 最先端のITを語りながら、最も重要な部分は“変えられない技術”に依存している。 ■変革はなぜ進まないのか この構造は、日本のITが抱える本質的な課題を示している。 変えたい。でも、変えられない。 効率化したい。でも、リスクが大きすぎる。 だから現場は、巨大な体制と緻密なプロセスで“守る”ことに最適化されていく。 それは間違いではない。むしろ合理的だ。 しかし、その一方で、変革のスピードは確実に鈍る。 私は6年目にして、初めて気づいた。 「プロジェクトの大きさ」や「人数」ではなく、 本当に向き...