会社は選択肢をくれない
「最近はPythonが流行りらしいですが、うちもPython使いませんか？」 新入社員が会社でこんなことを言えるだろうか？ 不可能だ。
就職前は、使う言語を自分で選ぶことができた。コーディングテスト（AtCoderなど）はPythonが有利だからPythonを使い、Web開発はJavaの求人が多いからJavaを掘り下げた。しかし、いざ就職市場を突破して入った小規模チームの現実は違っていた。
会社の技術スタックは既に決まっていた。レガシーコードはJava (Spring Boot) で動き、画面はJavaScript (Vue.js) で描画され、突然Androidアプリの保守業務が降りかかりXMLとまた別のJavaを触らなければならなかった。
僕は選択した覚えはない。ただ環境（Framework）が僕にその言語を強要しただけだ。最初は、この見知らぬ言語と文法が降り注ぐ状況が怖かった。しかし、手当たり次第にコードを読み書きしているうちに、ある重要な事実に気づいた。
「あれ？ これ、昔勉強したJavaのあの概念と一緒じゃん」
文法は違っても本質は同じ (Concept Transfer)
学生時代、僕はC言語を軽く触った後、Javaをかなり深く掘り下げた。そして就活シーズンになった時、ネットで「コーディングテストはPythonが最強」という話を聞き、初めてPythonの本を開いた。
最初は文法に戸惑ったが、驚くことに数日で適応できた。Pythonが簡単だったからではない。既にJavaを通じて「プログラミングの本質」を知っていたからだ。
- PythonのList：「あれ？ これってJavaのArrayListにStackとQueueの機能を混ぜただけじゃん」
- PythonのDictionary：「これはJavaのHashMapと一緒だ。Key-Valueペアで保存する仕組みだな」
僕がやったのは、新しい言語を「ゼロ」から学んだことではない。頭の中にある「Javaという地図（Map）」に「Pythonという地名」を上書きする作業だった。これを教育学の用語で**「学習の転移 (Transfer of Learning)」**という。言語一つを深く掘り下げておけば、その深さの分だけ他の言語を理解する速度が上がる。
UIも結局はツリー（Tree）構造だ
この経験は、全く異なる領域でも光を放った。 学生時代、小遣い稼ぎで学校のホームページをリニューアルし、HTMLとCSSを触ったことがあった。当時はそれが開発キャリアの役に立つとは思ってもみなかった。
ところが入社後、突然AndroidアプリのUIを修正する仕事が舞い込んだ。AndroidはUIを構成するためにXMLというマークアップ言語を使う。モバイルアプリ開発は初めてで緊張したが、コードを開いてみて笑ってしまった。
<!-- Android XML -->
<LinearLayout orientation="vertical">
<TextView text="Hello World" />
<Button text="Click Me" />
</LinearLayout>
<!-- HTML -->
<div style="display: flex; flex-direction: column;">
<span>Hello World</span>
<button>Click Me</button>
</div>
タグの名前が違うだけで、「親要素の中に子要素を入れ、属性（Attribute）で形を整える」という構造はHTMLと完全に同じだった。DOMツリー構造とボックスモデル（Box Model）を理解していたので、Androidのレイアウトもすぐに自分のものにできた。
フレームワーク、学校では教えてくれなかった
実は言語よりも僕を困惑させたのは「フレームワーク（Framework）」という存在だった。
学校ではC言語の文法、データ構造、アルゴリズム、言語論のような「基礎体力」しか教わらなかった。もちろん「React」や「Spring」という名前を聞いたことがないわけではない。Qiitaで「最近はReact一択だ」という記事を見て、無闇に本屋でReactの本を買ってみたりもした。
しかし、本を半分も読めずに閉じた。一体なぜこんな風にコードを書かなければならないのか理解できなかったからだ。 「いや、普通に関数を作って呼び出せばいいのに、なんでComponentを継承してrender関数の中に入れなきゃいけないの？ なんで制御権が僕にないの？」
その時は知らなかった。「ライブラリ（Library）」と「フレームワーク（Framework）」の決定的な違いを。
- 学校で習ったこと（Library式）：僕がコードを書き、必要な時に道具（関数）を持ってきて使う。（自分の好きにDIYで家を建てる）
- 会社で使うもの（Framework式）：道具（フレームワーク）が僕を呼ぶ。僕は決められた枠にコードを埋め込むだけでいい。（プレハブ住宅を組み立てる）
学校で学んだことが自由にハンマーを振るう方法だったなら、実務のフレームワークは「ハンマーは我々が振るうから、君はこの穴に釘を差し込んでくれ」と強要してくる巨大な工場のようだった。この**「制御の反転 (Inversion of Control)」**の概念を知らないから、本をいくら読んでも宇宙語のように感じられたのだ。
言語を知ればフレームワークが見える
しかし、実務に放り込まれ、無理やりにでもフレームワークを使っているうちに、逆説的な真実に直面することになった。
Spring Bootがいくら複雑な魔法を使っても、結局その中は「Javaコード」でできているという事実だ。
@Autowired のようなアノテーションが魔法のように依存性を注入してくれるが、中身を見れば結局Javaのリフレクション（Reflection）技術を応用したものだ。Vue.jsのリアクティブシステムも、結局はJavaScriptのオブジェクト（Object）とプロパティ監視機能を活用したものだ。
「言語（基礎）が丈夫なら、フレームワーク（応用）の動作原理が見えてくる」
僕は入社初期、SpringのMVC構造が何かも知らずに飛び込んだが、Javaに対する理解があったため、「あ、フレームワークが僕のコードを代わりに実行してくれるんだな。僕はここにあるルール通りにオブジェクトを投げればいいんだ」と素早く適応できた。 もし僕がReactの本を閉じたあの頃に「JavaScriptの基礎」がもっとしっかりしていれば、Reactがなぜあのような形をしているのか理解できたはずだ。
[Tip] どれを学ぶべきか迷子になっている学生への処方箋
「どの言語を勉強すればいいですか？」 技術コミュニティで最も多い質問の一つだ。言語もフレームワークも、必ず一つだけを一生使わなければならないわけではない。しかし逆説的だが、複数を使いこなすためには、最初は**「一つを確実に掘り下げる必要がある」**。
もし今、勉強の方向性が定まらず悩んでいる学生なら、参考書を閉じてすぐに「求人サイト（WantedlyやGreenなど）」を開け。
- 自分が入りたい会社、あるいは気になる会社の求人票（JD）を探す。
- そこに書かれている「技術スタック（言語およびフレームワーク）」を一つ決める。
- そのスタック一つを本当に深く勉強する。
「この会社はSpringを使っていて、あっちの会社はNode.jsを使っているんですが、どうすれば？」 関係ない。何でもいいから一つをちゃんと身につければいい。前述した通り、プログラミングの本質は通じているからだ。Springをマスターした人は、入社後に会社から「Node.jsを使って」と言われてもすぐに適応する。しかし、あれこれ少しずつ味見だけした人は、どんなフレームワークを渡されても底辺からまた彷徨うことになる。
悩む時間に「市場（求人）」が求める技術を一つ選び、深く掘れ。それが最も速い道だ。
[Code Verification] 言語は違ってもメモリは一つだ
言語が違っても、結局コンピュータ内部で起きていることは同じだということをコードで確認してみよう。JavaのArrayListとPythonのlistは文法こそ違うが、メモリを増やす方式（Dynamic Array）は同一だ。
// Java: 容量がいっぱいになると、サイズを1.5倍に増やして引っ越す。
ArrayList<Integer> list = new ArrayList<>();
list.add(1);
// 内部的に配列生成 -> データ追加 -> 容量不足時にさらに大きな配列を生成してコピー
# Python: 容量がいっぱいになると、サイズを約1.125倍 + α 増やして引っ越す。
my_list = []
my_list.append(1)
# 内部動作原理はJavaとほぼ同一（C言語の配列再割り当てロジックを使用）
我々がどんな言語を使おうと、デジタル物流センター（コンピュータ）の作業方式は変わらない。作業員（CPU）と倉庫（メモリ）を使うルールは万国共通だからだ。
終わりに：恐れるな、好奇心を持て
エンジニアとして生きていると、望まない言語やフレームワークを使わなければならない瞬間が必ず来る。その度に「僕はJavaエンジニアだからPythonは嫌だ」と逃げるのか？
言語は宗教ではなく「道具」だ。そしてフレームワークはその道具を使う「作業場」だ。 一つの言語（母国語）を深く掘り下げた経験がある人は、新しい道具を渡されてもすぐに使い方を覚える。
だから、今すぐ会社で見知らぬ技術スタックを強要されても怖がるな。ガワ（皮）が違うだけで、中に入っている中身は君が既に知っているアレと同じはずだから。
これで言語に対する恐怖は消えた。次回の記事からは、コードが生きている本当の世界、**「メモリ（Memory）」**の深淵へと入ってみよう。自分が書いたコードがRAMのどこに刺さり、どう転がっていくのかを知れば、言語の壁はもっと低くなるだろう。