Digital Heroes: Guide to IT World

うわっ…言語が変わるだけで、人はここまで不安になるのか!? ■社会人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を使う方法だ。 同じ内容を、日本語と英語で比較する。 それだけで理解が一気に深まる。 字幕を付けることもできる。 だが、あえて付けない方がいい。 耳と文脈で理解する力が鍛えられるからだ...

うわっ…コードを書いていないのに、プロジェクトが崩壊する!? ■Cobol時代にはなかった“新たな難しさ” かつてCobol中心の時代、システムは比較的シンプルだった。構成も閉じた世界で管理され、外部依存は限定的だった。しかし、Javaへの移行とともに、ある領域が一気に難しくなった。それが「構成管理」、特にライブラリ管理である。 ■Javaの進化が生んだ“自由と混乱” Javaは極めて拡張性が高い言語だ。豊富な標準機能に加え、世界中の開発者が機能をパッケージやクラスとして公開している。これにより、ゼロから作らなくても高度な機能を簡単に取り込めるようになった。これは生産性の飛躍的向上を意味する。 だが同時に、「どれを使う？」という新たな判断が発生した。     ■パッケージ選定という意思決定の重さ 各パッケージは、世界中の優秀なエンジニアが作り込んだものだ。設計も品質も高く、使わなければ開発規模は膨大になる。だが、選択を誤れば、システム全体に影響を及ぼす。 しかも、必要な機能は複数のパッケージで実現できる場合も多い。どれを選ぶかは、単なる技術選定ではなく、プロジェクトの将来を左右する経営判断に近い。 ■最大のリスクは“見えないセキュリティ” 問題はセキュリティだ。このパッケージ、本当に信じていいのか？変なコードが仕込まれていないか？安全性は？安定性は？ 情報が限られる中、ネットを検索し、仕様を読み、過去の実績を調べる。かつてはSun Microsystemsの情報を読み漁りながら判断することもあった。しかし、それでも確信は持てない。 ■終わらないアップデートとバージョン地獄 さらに難しいのは、これらのパッケージが常に進化していることだ。アップデートは頻繁に行われ、新機能や修正が追加される。だが、複数のパッケージを組み合わせると、バージョンの整合性が問題になる。 あるパッケージを更新すると、別のパッケージと互換性が崩れ、動かなくなる。逆に更新しなければ、セキュリティリスクが高まる。このトレードオフは、現場に重い意思決定を突きつける。 ■それは“迷宮の入り口”だった こうして、構成管理は単なる管理作業ではなくなった。技術、セキュリティ、運用、将来性——あらゆる要素を考慮する複雑な意思決定プロセスへと変わったのだ。 そして...

うわっ…気づけばどのプロジェクトにも“中国チーム”がいるじゃないか！ ■5つを超えると見えてくる“空気” プロジェクトを1つ、2つと経験しているうちは、個別最適の違いしか見えない。だが、5つ以上回してくると、明らかに「共通の構造」と「チームの空気」が見えてくる。誰が主導し、どこが詰まり、どこで一気に進むのか。そのパターンは驚くほど似ている。 そして、ある事実に気づく。なぜか、どのプロジェクトにも中国チームが必ず入っているのだ。     ■チーム体制には“型”がある いくつかのプロジェクトを横断して見ていくと、チーム体制には明確なパターンが存在する。特に、日本チームと中国チームの役割分担は、意図されたかのように分かれている。 ■日本チームの特徴——分業と複雑性 日本チームは、管理者とエースが明確に分かれているケースが多い。管理者は年配のベテラン、エースは30代前半。役割ははっきりしているが、意思決定や実装スピードはどうしても遅くなりがちだ。 さらに、日本チームは複雑な機能を任されることが多い。業務知識の蓄積があるため、仕様の深い理解や例外処理が必要な領域を担当する。結果として、「難しいが進まない」構造になりやすい。 ■中国チームの特徴——一点集中と圧倒的量 一方、中国チームはまったく異なる。管理者とエースが同一人物、いわば“スーパーマン”が中心にいる。その人物は日本語も堪能で、ブリッジ役を一手に担う。 その周囲を固めるのは20代前半の若手メンバー。彼らの日本語はまだ発展途上だが、手を動かすスピードと量は圧倒的だ。中国チームは、比較的シンプルだが作業量が膨大な機能を担当することが多く、「とにかく進む」。 ■業務知識は誰が持つのか 当初、業務知識は日本チーム側に集中していた。複雑な仕様理解や顧客対応が求められるためだ。しかし、プロジェクトが進むにつれて、中国チームのスーパーマンがその知識を吸収し始める。 すると何が起きるか。スピードと理解が融合し、プロジェクトの推進力が一気に変わる。 ■違いを“楽しめるか”が成否を分ける こうして見ていくと、日本チームと中国チームは対立構造ではなく、補完関係にあることが分かる。 ・日本：複雑性と品質 ・中国：スピードと量 この違いをストレスと捉えるか、強みと捉えるかで、プロジェクトの...

うわっ…巨大組織の心臓が、こんなに小さいなんて誰が想像できるだろうか！ ■社会人6年目、想像していた「大組織」 社会人6年目。私は、日本の金融業界の中心を支える基幹システムのプロジェクトにアサインされた。 規模は200人超。複数ベンダーが参画し、名だたる企業が並ぶ。 「これは完全に、大組織での分業戦だな」 そう思っていた。日立のプロパーも多数入り、重厚なマネジメント体制が敷かれている——はずだった。     ■びっくりするほど“小さい本体” しかし、現場に入って目にした光景は、まったく違っていた。 机の一列に並ぶ、たった6人。 部長はそこにはいないが、その席の横に、課長、主任3人、担当2人。 この6人が、すべてを回していた。 周囲には確かに人がいる。 ベンダーは4社、それぞれ平時でも20名以上。 開発ピーク時には、テスト要員も含めて200人を超える。 だが、意思決定と全体制御は、この6人に集約されていた。 「本体は、ここか…」 その瞬間、プロジェクトの構造が一気に見えた。 ■構成管理チームという“中枢神経” そんな中、私は新たに切り出された構成管理チームを任された。 理由は明確だった。Java化による構成の複雑性。 だが、すぐに気づく。 これは単なる「構成を管理する仕事」ではない。 各チームごとに開発スタイルが違う。 ビルド方法、ブランチ戦略、リリース手順——すべてがバラバラ。 つまり、必要なのは統制ではなく「調整」だった。 ■本当の仕事は“すり合わせ” 構成管理とは、コードを管理することではない。 チーム同士の前提を揃え、衝突を防ぎ、全体最適に導くこと。 4社のベンダー、それぞれの文化。 20人単位のチームが複数動く中で、わずかなズレが致命傷になる。 私は、構成を通じてそれを繋ぐ役割だった。 「ここ、どう合わせます？」 その一言が、プロジェクト全体のスピードを変える。 ■6人が200人を動かす理由 なぜ6人で回るのか。 答えはシンプルだ。 ・意思決定が速い ・構造を理解している ・全体を俯瞰できる 人数ではない。 構造と役割が、すべてを決める。 そして、その中に「調整役」が組み込まれていること。 これが、巨大プロジェクトを動かす本質だった。 ■身震いした責任と、...

えっ、プログラミング言語の“完成形”が日本にあっただと!? ■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そのものを作り、 その上で動く言語まで設計し、 さらに“人にとって分かりやすい形”に整える。 このレベルの要素技術を内製できるエンジニア集...