WEBエンジニアとしての主軸言語を変更したときの話
概要
年始ということで今年の目標を立てている方もいらっしゃると思いますが、自分の昨年(2022年)の目標の一つに「主軸言語の変更」というのがありました。
ここでいう主軸言語というのは自分にとっては Ruby (on Rails) であり、変更対象の言語の候補としては TypeScript もしくは Python を考えていました。
結果としては実際に2022年中にそれらの言語で実務経験を積んだり、何かものを作ってハンズオンで体験的理解ができたりはしたので自分の中では目標を達成したつもりではいます。
ただ、自己満足に終始せずに事の経緯をこうしてまとめておくことで、他の同業者の方の参考になったり、今後関わる利害関係者から自分の考え方を理解してもらえたりする福利があるのではないかと思い、記事として残すことにしました。
定義
主軸言語:
仮に今自分がアーキテクトとして技術選定をするとしたら採用したいプログラミング言語
開発に用いる割合が最も高い（高くしたい）プログラミング言語
最も得意な言語は何かと聞かれたらその言語と回答できる（したい）プログラミング言語
なぜ主軸言語の変更を検討したのか
主に以下の観点から考えました。
Ruby一本足打法からの脱却することで人材価値を維持・向上させられるから
ローカル（日本）だとRubyの案件は豊富だがグローバルだと大して案件はないから
静的型付けの言語の方がDX(開発者体験)の満足度が高いから
以下、各々に関して掘り下げていきます。
Ruby一本足打法からの脱却することで人材価値を維持・向上させられるから
自分の場合、何で作るかよりも何を作るかを重視しているので特定の言語に固執したり、スキルコレクターのようにとにかく新しい言語をどんどん触ってみたいといった意欲はありませんでした。
ただ、WEBエンジニアとして業務委託の案件を獲得するなり正社員として雇用してもらうなりすることを考えると、主軸言語は一般的に広く採用されている言語であることが好ましいと言えます。
例えばフリーランスエンジニアのエージェントが開設しているポータルサイトや正社員向けの転職サイトなんかは使用している言語で企業の検索・絞り込みができると思います。
そこに "Ruby" なり "TypeScript" なりを指定した結果、ヒットする件数が多ければ多いほどいいのではないかということです。
その点、Ruby の案件は現時点ではかなり多いです。
実際に昨年に営業活動をした際の体感でも Ruby の案件は潤沢にある印象でした。
だったらそのまま Ruby をやっていればいいのではという話にはなりそうですが、やはりダウントレンドに備えることはリスクヘッジとして重要です。
正社員であれフリーランスであれ、労働力を提供する側にいるなら転職であれ失業であれ環境を変える必要性はどうしても生じてしまうと思います。
であれば、Ruby一本足打法よりは他の言語も習熟すれば、リーチできる案件自体が増えてその辺のリスクにも備えることができます。
特に自分の場合、Rubyの実務経験は10年以上あるので単に言語の経験年数を評価尺度とされるようなことがあってもこれ以上箔がつきません。
むしろ、Aという言語で実務経験が5年、Bという言語でも実務経験が5年といった人の方が人材価値は高いように思います。
後者に関しては俗に言う錯覚資産みたいものを形成する効果があるように個人的には思っていますし、他の言語も経験することで一つ上の次元（抽象度）でものを考えられるようになり、結果的に実力が上がることを自身で体験しています。
以上のように、リーチできる案件の母数の増加、多言語習得のシナジーによる人材価値の向上が見込めることが1つ目の理由となります。
ローカル（日本）だとRubyの案件は豊富だがグローバルだと大して案件はないから
以前在籍していた案件でSNSをうまく活用されているエンジニアの方がいて、自分も真似して色々アカウントを作ってみました。
その中で LinkedIn と言うサービスがあります。
日本ではまだ馴染みのないものだと思いますが、海外だとかなりメジャーなビジネスSNSのようです。
年に2回程度ではありますが、このLinkedIn経由で海外の企業（人材会社などではなくスタートアップの創業者）からお誘いを受けることがありました。
本筋からズレるので理由は割愛しますが海外の案件には色々と興味を惹かれることが多いので近年挑戦してみたい気持ちは持っています。
ただ、掲題の通り海外だと日本ほど Ruby を採用している案件はない印象です。
これも前節同様、特定の言語にロックインされず多言語心得があった方がリーチできる案件も相対的に増え、結果的に機会損失を防げると思いました。これが2つ目の理由です。
ちなみにスキルチェンジのターゲットにおいて TypeScript の次善のものとして Python を選びましたが、本節がその主な理由です。
Python は北米で教育などに採用されているメジャーな言語で、世界的な開発者人口は非常に多いと思われます。
機械学習との親和性から日本でも採用している企業も増加傾向にあるように思います。
静的型付けの言語の方がDX(開発者体験)の満足度が高いから
もともとこの記事はGithubのプライベートリポジトリのissueが元ネタなんですが、この節に関してはそのままコピペした方が伝わりやすそうだったので以下に転記します。
静的型付けの言語の方がシステムが堅牢になる
型は最速のテスト
数学的には $${y = f(x)}$$ とすると、 $${x}$$ が独立変数で $${y}$$ が従属変数
それで、 $${x}$$ が取り得る値の集合が定義域だが、プログラミングをする上ではこれが狭い方が好ましい（動きが予測しやすい）
定義域を型指定で絞ったり明示したりすることでそれと関数関係にある値も想定しやすくなり、安全性は高まる
一般的にはこういった変域が狭い方が好ましく、そういうふうに制約できるのが型付けの仕組みである
変数名は嘘をつくけど型は嘘をつかない
Rubyの例だと、実装者が hash のオブジェクトを入れている変数に対して user みたいな名前をつけると first_name や last_name といったプロパティを持つ user のオブジェクトと混同するかもしれないが、型だとそういうことはない
IDE(VSCode)とのインテグレーションで変数にカーソル合わせればすぐ型がわかって罠を回避しやすい
Rubyも静的解析の仕組みは入ってきているようですが、他の静的型付けの言語に一日の長があると思います。
あとnull安全でないことで意図しないバグが混入しやすくてしんどいことは実際ありました。
（DXに関しては当方は言うまでもなく高い方がいいと思っていますが、本筋から逸れるので意見の詳述などは控えます）
なぜターゲットを TypeScript にしたのか
主に以下の観点から考えました。
アップトレンドである
ユニバーサルである
アップトレンドである
既出の通り、案件が潤沢であるかどうか（主軸言語として採用するTypeScriptを採用している企業が多いかどうか）という切り口でみた時に TypeScript は良さそうでした。
昨年の年始時点のデータですが参考にしたのは以下の記事です。
図から世の趨勢は TypeScript にあることが見て取れます。
ユニバーサルである
既知の通り、フロントエンドで採用される言語としては JavaScript 一択です。
近年ではそのスーパーセットとして TypeScript が採用されることが非常に多くなっています。
自分はバックエンドに軸足をおいていますが、参画する案件では大抵フロントエンドも兼務させられます。
であれば、バックエンドもフロントエンドと同じく TypeScript で実装できたら認知負荷を下げられていいのではないかと前々から思っていました。
近年では実際にそういうアーキテクチャが採用されている案件も増えてきているように思えました。
具体的に何をやったか
これに関しては単純で、ただひたすら技術書やオンラインドキュメントをインプットして、とにかくコードを書くということを繰り返しました。
前述したようにほぼ全案件でBE/FEは兼務させられるので、後者においてTypeScript自体は実務経験がありました。
ただ、前節のようにBEでもTypeScriptを書くことがDX向上の観点などから肝要だと思ったので、NestJSなどを用いて小さなWEBアプリを作ったりしながら実践を意識して手を動かし続けました。
作ったものに関してはリポジトリをパブリックにしておけば選考を受ける際に参考情報として提供する一助にもなります。
実際、実務経験がなくても BE に TypeScript や Python を採用している案件から内定をいくつか獲得することができました。
加えて、うち1つの案件はフルタイムで半年ほど継続し開発にも問題なく入れたのでこの結果を持ってして冒頭で述べたように「目標達成」としました。
以上
この記事が気に入ったらサポートをしてみませんか？