うわっ…言語が変わるだけで、人はここまで不安になるのか!? ■社会人6年目、突然の「Java化」 社会人6年目。私は、日本の金融業界の中心を司る巨大企業の基幹システム刷新プロジェクトにいた。これまで長年、COBOLで作り上げられてきた巨大なシステム。その変換先として提示されたのが「Java」だった。 最大時には200人を超える大規模プロジェクト。だが現場に広がったのは期待ではなく、不安だった。 「COBOLしかやってきていない自分たちは、Javaに対応できるのか?」 ■COBOLという“設計至上主義” COBOLは手続き型言語だ。プログラムは上から下へ、順番通りに積み上げる。 一行の文字数、配置、メモリの使い方まで厳密に意識しながら書く。 部品を呼び出すというより、「業務の流れ」をそのままコードに落とし込む。 だからこそ、設計がすべてだった。 設計で全体の順序を完璧に組み立て、それを忠実にコードに写す。 このスタイルに慣れたエンジニアにとって、「自由度の高いJava」は未知の世界に見えた。 ■Javaがもたらした“構造の解放” しかし、実際にプロジェクトが動き出すと、状況は大きく変わった。 Javaはオブジェクト指向をベースに、部品化・再利用・柔軟な構造を許容する。 さらに、メモリ管理の負担も軽減されている。 COBOL時代のように、細かい領域を意識し続ける必要はない。 この“制約の解放”が、現場に新しい風を吹き込んだ。 設計者もプログラマーも、思った以上にスムーズに適応していったのだ。 ■「言語は違えど、本質は同じ」 振り返ると、気づくことがある。 プログラム言語は違っても、「構造を理解し、論理を組み立てる」という本質は変わらない。 実際、Java以降の言語は構造が似ている。 現在主流のPythonやRubyといったスクリプト言語も、オブジェクト指向ベースであり、英語に近い記述で理解しやすい。 つまり、一つの言語で“構造”を理解した人は、次の言語にも応用が効くのだ。 当時のJava移行は、今で言えば「Javaからクラウド(Lambdaなど)への移行」に近いインパクトだった。 それでも、現場は乗り越えた。 ■200人が証明した「進化できる力」 最終的に、この200人規模のプロジェクトは成立した。 COBOLの...
Cobol世代からAI時代へ——学び方が変わる瞬間 うわっ…英語ができないとコードすら書けなくなるのか!? ■「Javaってどう学べばいいの?」という時代 社会人になりたての頃、Cobolをずっと習ってきた先輩たちから、こんなことを聞かれた。 「Javaって、どうやって学べばいいんだ?」 今なら簡単だ。YouTubeを開けば、いくらでも解説動画がある。 だが当時は違った。まだYouTubeはそこまで流行っていなかった。 だから、基本は“本”。 それが唯一の学習手段だった。 ■分厚い本=ステータスだった時代 Javaの日本語の本も確かにあった。 しかし、正直に言えば難しかった。 理解が追いつかない。 読み進めるほどに、自信が削られていく。 そんな中で、多くのエンジニアが持っていたのが、オライリーの分厚い本だった。 あの本を持っていること自体がステータスだった。 「これを読んでいる自分は、できるエンジニアだ」 だが現実は違う。 その分厚さと難解さに、多くの人が挫折していった。 ■答えはシンプルだった——英語で学ぶ では、どうすれば良かったのか。 答えはシンプルだった。 “英語で学ぶ” 最新の情報は、いつも英語から始まる。 だから英語の本を読み漁るしかなかった。 辞書を片手に、一文ずつ理解していく。 正直、かなり難しかった。 それでも、得られるものは大きかった。 ■“システム英語”という武器 そこには、単なる英語以上の価値があった。 「システム特有の言い回し」が身についたのだ。 これは普通の英会話では絶対に学べない。 そもそも、英会話の先生でシステム開発を理解している人はほとんどいない。 日本の開発事情を理解している人もいない。 だからこそ思う。 「システムを英語で学ぶ」のは、非常に合理的な選択だ。 ■今の時代の学び方はどう変わったか では、今の人たちはどうしているのだろうか? YouTube?ネット記事? 確かに、それも正解だ。 だが、もう一歩踏み込める方法がある。 ■日英で学ぶという新しいスタイル 例えば、システム開発について日英両方で発信しているYouTubeを使う方法だ。 同じ内容を、日本語と英語で比較する。 それだけで理解が一気に深まる。 字幕を付けることもできる。 だが、あえて付けない方がいい。 耳と文脈で理解する力が鍛えられるからだ。 ■自分のコンテンツで英...