フロントエンド/バックエンドエンジニアはもう古い?これからのエンジニア像と開発手法

フロントエンド/バックエンドエンジニアはもう古い?これからのエンジニア像と開発手法

フロントエンド/バックエンドエンジニアはもう古い?これからのエンジニア像と開発手法

はじめに

皆さん、こんにちは!島袋です。この記事では、従来の「フロントエンドエンジニア」と「バックエンドエンジニア」という区分けが時代遅れになりつつあり、これからの時代は「プロダクトエンジニア」という視点が重要になってくるという話をしていきます。最新のアーキテクチャの話なども含みますので、最後まで読んでいただけたら嬉しいです!

エンジニアの分類:時代遅れの区分け

従来、エンジニアの分類は、大きく分けて以下のようになっていました。

  • フロントエンドエンジニア: ユーザーインターフェース(UI)とユーザーエクスペリエンス(UX)を担当
  • バックエンドエンジニア: サーバーサイドのロジックとデータベースなどを担当
  • インフラエンジニア: サーバーやネットワークなどのインフラ環境を構築・管理
  • SRE(Site Reliability Engineer): システムの安定性と信頼性を確保
  • ネイティブアプリエンジニア(iOS/Android): iOSやAndroid向けのネイティブアプリ開発

特にフロントエンドとバックエンドの役割分担は、APIを境界線として明確に分けられていました。しかし、この区分けは、近年の技術進化によって、もはや時代遅れになりつつあると考えています。

バックエンドエンジニアの役割の変容

バックエンドエンジニアの役割は、会社によって認識が異なります。

  • API層から後方全てを担当する定義
  • API層とバックエンドアプリケーション層までを担当する定義。それ以降はインフラエンジニアが担当する定義

しかし、この記事では、フロントエンドエンジニアとアプリケーション層のバックエンドエンジニアを分ける必要性が今後なくなっていくと主張します。

プロダクトエンジニア/アプリケーションエンジニアの台頭

フロントエンドエンジニアとアプリケーション層のバックエンドエンジニアを統合する役割として、プロダクトエンジニア、もしくはアプリケーションエンジニアという呼称が適切だと考えます。その理由は、以下の通りです。

フロントエンドフレームワークの進化とサーバーサイド機能の増加

フロントエンドフレームワークの進化が、この変化を加速させています。特に、Next.jsの進化は顕著です。

Next.jsの進化とサーバーサイド機能の強化

以前は、Next.jsはpagesルーターという開発手法でしたが、現在はappルーターが登場しています。 appルーターでは、サーバーサイドでできることが飛躍的に増えました。

  • getStaticProps、**getServerSideProps**などのサーバーサイドプロップス取得機能の強化
  • APIルート機能の拡充
  • React Server Componentsの登場:Reactコンポーネントの中にサーバーサイドロジックが組み込まれる

これにより、サーバーサイドで処理できる範囲が大幅に拡大し、従来バックエンドで行っていた処理をフロントエンドで完結できるようになってきています。

サーバーサイド機能の増強例:データベースクエリ

具体的には、データベースクエリもReact Server ComponentsやServer Actionsから行うことが増えてきています。これによって、ユーザーエクスペリエンス(UX)と開発者エクスペリエンス(DX)の両方が向上しています。

従来の開発手法の限界

従来の開発手法では、

  1. バックエンドエンジニアがバックエンドアプリケーションとRESTful APIやGraphQL APIを開発します。
  2. フロントエンドエンジニアがRESTful APIやGraphQL APIを叩いてフロントエンドを構築します。

この手法は、もはや非効率的です。

RPC(Remote Procedure Call)の重要性

そこで注目したいのが、**RPC(Remote Procedure Call)**です。簡単に言うと、関数を作成し、フロントエンドから呼び出す仕組みです。

私は、RESTful APIやGraphQLよりもRPCの方が将来性が高いと考えています。その理由は、効率が良く、既存のコードもそのまま利用できるなど、多くのメリットがあるからです。

サーバーアクションなどもまさにRPCの一種です。 サーバーサイドの機能を積極的に活用することで、バックエンドアプリケーション層での処理が不要になるケースが増えています。

バックエンドアプリケーション層の縮小

つまり、バックエンドのアプリケーション層はほとんど不要になると私は考えています。

フロントエンドとバックエンドの垣根を超える必要性

これからの時代、バックエンドエンジニアはフロントエンドアーキテクチャを理解する必要があり、逆にフロントエンドエンジニアはバックエンドの知識を学ぶ必要があります。フロントエンドフレームワークがバックエンドまで浸透してきているからです。お互いが歩み寄ることが重要です。

エンジニアの分類:これからの姿

従来のフロントエンドエンジニアとバックエンドエンジニアという区分けは、廃止すべきです。

代わりに、以下の役割分担が適切だと考えます。

  • プロダクトエンジニア/アプリケーションエンジニア: フロントエンドとバックエンドのアプリケーション層までを担当
  • プラットフォームエンジニア: インフラ、SRE、共通ライブラリなどを担当

VercelとFDI(Framework-Defined Infrastructure)

Vercelが提供するプラットフォームは、この考え方を後押ししています。Vercelは、FDI(Framework-Defined Infrastructure)という概念を採用しており、フレームワーク側がインフラ構成を決定します。

Next.jsを使用していれば、サーバーアクションやReact Server Components、ルートハンドラーなどを利用することで、必要となるインフラ構成が自動的に決定されます。

プラットフォームエンジニアの役割

プラットフォームエンジニアは、以下のような役割を担います。

  • 認証基盤やログ基盤などの社内共通基盤の整備
  • CI/CDパイプラインの整備
  • 手作業で行っていたタスクの自動化
  • 複数のプロダクトで共通して利用するライブラリの開発
  • ミドルウェアの開発

まとめ:技術進化とエンジニア像の変容

技術の進化によって、アプリケーション開発に必要な工程が短縮・簡素化されつつあります。そのため、細かな役割分担は不要になりつつあります。

これからの時代は、

  1. フロントエンドとバックエンドのアプリケーション層まではプロダクトエンジニアとして担当
  2. それ以降のインフラ関連はプラットフォームエンジニアとして担当

という役割分担が主流になるでしょう。

ただし、大規模なトラフィックを扱うアプリケーションの場合、独自のインフラを構築した方がトータルコストが安くなるなど、メリットがある場合もあります。

オンラインサロンのご紹介

今回紹介した内容は、私が運営するオンラインサロンで3年ほど前からずっと議論し、実践してきたものです。オンラインサロンに参加されている方は、これらのトレンドを実感されていることと思います。

AIの台頭など、今後エンジニアのキャリア戦略をどのように歩むべきか、具体的な議論も行なっていますので、興味のある方はぜひご検討ください。

おわりに

この記事では、エンジニアの役割分担の変遷と、これからのエンジニア像について解説しました。 ご不明な点やご意見があれば、コメント欄でご質問ください。