みなさん、Full-Stack TypeScript と呼びませんか！
みなさん、こんにちは！
アセンド株式会社で取締役CTOを務めている丹羽（@niwa_takeru）です。「物流の真価を開き、あらゆる産業を支える」をミッションに、運送会社向けSaaSの開発・提供をしています。また、個人としては今年５月に開催された TSKaigi の運営理事も務めております。
この記事で、みなさんにお伝えしたいことはただ１つ。↓↓↓
「Full-Stack TypeScript という名称に統一しませんか？」
最近、フロントエンドやバックエンド、その他の領域を TypeScript で統一したアーキテクチャを採用する企業やプロダクトが増えています。私たちアセンドでも、フロントからバックエンド、IaC まで TypeScript で統一しており、1日に6回以上のデプロイを実現するなど高い生産性の恩恵を受けています。
これからの技術選定で有力な選択肢の１つとなる TypeScript に統一した構成ですが、ひとつ問題があります。それが名称が統一されていない為に検索性が悪く、知名度が上がりにくい。
そこで、みなさんに改めてご提案です。Full-Stack TypeScript という名称に統一しませんか？
検索性の低下が、知見の一般化を阻害している
フロントエンド、バックエンドともに TypeScript を採用している企業が増えている中で、そのアーキテクチャの呼び方は企業によって様々です。
アセンドでも過去には Full TypeScript Architecture という呼び方をしていましたし、ウェブ検索をしてみても Backend TypeScript という呼び方や、両面TypeScript、全方位TSとも読んでいる例が見受けられます。
名称が統一されていないことでどんな問題が起きているかというと、ウェブ検索をした時に知見が見つかりづらいということです。
実際に、2021年当時に私がアーキテクチャ選定をする際に、TypeScript でフロントエンド・バックエンド統一のメリット・デメリットを検索しようとしました。ただ、LAMPやJamstackのように分かりやすい言葉がないために「React」や「express.js」、「backend typescript」といったキーワードで検索して、フロントやバックエンドの個別領域での知見収集を余儀なくされました。そして、両面で TypeScript を使ったケースでの知見は結局のところ多くは見つけられませんでした。３年経った現在も検索性が悪い状況は変わらないと思います。
素早く知見・ノウハウを検索したいのに、名称が統一されていないということが余計な時間を取らせており、知見の一般化を阻害してしまっています。
この問題を解決するためにも、Full-Stack TypeScript という名称に統一して知見を共有しやすくしたい、これがみなさんへの提案です。
海外での呼び方もFull-Stack TypeScript がポピュラー
Full-Stack TypeScript という名称については、海外での使用例を参考にしています。
Auth0を代表として海外企業でも Full-Stack TypeScript という表現を使っています。日本国内だけではなく、海外とも名称を統一することで、海外企業の文献を参照することができるため、情報の検索性は圧倒的に高まります。
Full-Stack TypeScript が増加している理由は？
そもそも何をもってして Full-Stack TypeScript と呼ぶかという定義に関しては議論の余地がありますが、ミニマムの条件として「フロントエンドとバックエンドで TypeScript で統一していること」と考えます。
アセンドの他にも Full-Stack TypeScript を採用している企業やプロダクトは増えてきています。
特に2020年以降に新規で開発されているプロダクトにおいて、その増加が顕著です。
これは TypeScript や周辺のエコシステムが進化を重ねるてきたことで、フロントエンドだけでなくバックエンドでも十分に開発に耐えうるクオリティになってきたという要因があります。
さらにライブラリ等の充実により、TypeScript での開発の利便性がどんどんと増していっています。
代表的なものでは NestJS、Prisma、最近では Hono などのライブラリを使って TypeScript によるバックエンド開発を行うケースを目にします。
Full-Stack TypeScript のメリット
Full-Stack TypeScript のメリットは、いくつかあります。
- 1人のエンジニアがフロントエンド、バックエンド両方を担当することができ、開発効率が高まる
複数の開発言語を習得する必要がなく、TypeScript にのみ習熟すれば良いという状況は、1人のエンジニアの守備範囲を広げることになります。またフルスタックに開発する中で言語のスイッチングコストを抑えられることは、１度経験すると捨てづらい開発者体験となっています。 - エンジニアリソースの不足に対応できる
これは開発効率向上の裏返しでもありますが、エンジニアリソースが足りない場合にも1人のエンジニアの守備範囲を広げることでリソース不足に対応できます。 - プロダクトエンジニア組織との相性が良い
アセンドが採用している「プロダクトエンジニア」を中心とした開発組織においては、1人のエンジニアが広い領域を担当するため Full-Stack TypeScript との相性が良いです。
同様に1人が広い開発領域を担当するフルスタックエンジニア、フルサイクルエンジニアというポジションを設置している開発組織においても相性が良いです。
アセンドが Full-Stack TypeScript の技術選定の背景を下記の登壇資料にまとめているので、よろしければご覧ください！
おわりに
ということで、みなさん Full-Stack TypeScript と呼びませんか！
この記事を読まれた方、今後は Full-Stack TypeScript と呼んでいただければ嬉しいです！
また、自分も Full-Stack TypeScript で開発しているよー🙋という方は Xに #FullStackTypeScript のハッシュタグをつけてポストし、広めていただけると嬉しく思います！
それでは、みなさん。 Full-Stack TypeScript と呼んでいきましょう！
Discussion