■二年前に受けた某企業の技術研修について

ふと思い立ったので書いてみる。二年前、新卒として某企業の技術研修を受けた。Javaを用いて、自分たちで一つのプロダクトを作るという研修である。技術を推している会社なので研修内容にはかなり期待していた。Spring等のフレームワークの話、JavaとフロントエンドのAngularやReactをどう連携させるか、もしかして自作のフレームワークを作る研修も受けられるかも、などなどの話を入社前にはしていた。実際そうではなかったわけだが。

詳らかに書くことは出来ないが、当時最も憤ったのは研修の成績をどうやって決めるかに関する講師の考え方。中間発表で企画発表を行い、最終発表でプロダクトとしてのレビューを受けて、プレゼン大会を行って成績が決まった。自分はどちらも中くらいの成績だったらしい。

ここで驚いたのが、コード量が成績評価に結び付くということだ。コード量の最適化という意味ではない。フレームワークなどを使ってコード量を減らしてはいけない、フルスクラッチでプロダクトを作れということだった。意味が分からなかった。

評価するためには十分量のコードが必要ということは理解していた。過去の研修で何人かがフレームワークを用いて適当に作ったプロダクトで済ませようとしたエピソードなどを聞かされた。それはわかる。わかるが、そうした怠慢に基づくモチベーションではなくよりよいプロダクトを作るために先人の肩に乗るのは許されるべきではないのか？

Javaによるプロダクトを理解するため、フレームワークを使うとフレームワークが廃れたときに何にもできなくなる、という言葉を何度も聞かされたが、Javaのプロダクトを理解するのならそれこそフルスクラッチを要求するのではなく歴史があるSpringで十分だし、フレームワークを使ったからといって魔法のように自分の望むプロダクトが出来上がるわけもなく、自分で考える部分が大部分を占めることは自明ではないか。むしろ、その考える時間という本質的な部分を確保するためにフレームワークなどの技術を用いるべきではないのか。

Reactを学びたいモチベーションがあり、Java側でなければ、というかReactはフレームワークじゃないし大丈夫だろうと思って実装を進めていた時に講師の方から「フレームワークは認められない」と言われ、食い下がったもののまるで話が通じなかった。結局自分はそこから大きく計画を修正し、適当なプロダクトを作った。モチベーションは地の底に落ちた。そもそもプログラム研修なのに渡されたPCがWindowsで、エクセル地獄だった時点でモチベーションはまるで高くなかったがReactをやるというのがモチベーションになっていた。それも無駄だった。

今年の新人も同様のカリキュラムだという。しかもまだWindows。フレームワークは一切使えない。エクセルでワイヤーフレームを書けという。SIじゃないから大丈夫だろうと思っていたのに、という新人はたくさんいるだろう。配属後もコードを書く時間はどんどん減っていく。自分自身で勉強し、論文や技術書を読み、週末に自分でプロダクトを作る習慣をつけておかないといけない。自衛しないといけない。

そんな不幸な人たちがいればいいのにと思った。

Permalink | 記事への反応(1) | 22:55

ツイートシェア