UIの先にある世界へ。フロントエンドから見たバックエンドの必要性

効率化が進むフロントエンド開発、その先に見えた課題

私はこれまで5年弱、フロントエンドエンジニアとしてWeb開発の現場に携わってきました。HTML、CSS、JavaScript、WordPressを中心に、サイト制作の経験を多く積んできました。フロントエンドのデファクトスタンダード（実際によく使用されている標準）といえばReact（またはNext）という程主流になっているので、2023年頃からはReactについても学習を進め、案件にも参画しています。

ここ数年だけ見ても、Material UIやshadcn/ui のようなコンポーネントライブラリが登場しており、ゼロからスタイルを当てなくても整った見た目のUIを手軽に実装できるようになりました。開発効率が大きく向上していると日々感じております。

Reactの登場以降はreact-hook-form のような便利なライブラリも使えるようになり、バリデーションやフォーム管理といった煩雑な処理もスムーズに扱えるようになりました。こういった技術の進化に伴い、フロントエンドの実装はかなり効率化され、スピーディーに形を作ることができるようになったと感じています。

しかし、そうした開発経験を積む中で、ある壁にぶつかることが増えてきました。それは「バックエンドの知識がないと全体を理解できない場面が多い」ということです。Material UIやchakra UIなどで手軽に画面を作れるようになったため、相対的にフロントエンドのみでは価値を見出しにくくなった、とも言えるかもしれません。

実際、フロントエンドだけの引合はあまり多くなく、フロントエンドはReact、バックエンドはJavaのような引合が大半の印象です。現場でも、クライアントからの要望や仕様変更に対応するには、画面部分だけでなく、その裏で動いているロジックやデータの流れも把握しておく必要があると感じています。

フロントだけでは解決できない場面に直面して

アプリケーションの大半は、「フロントからの入力 → バックエンドでの処理 → DBへの保存 → 処理結果の返却 → フロントに表示」という一連の流れで動いています。この全体像が頭の中でつながっていないと、エラーや不具合が発生した際にも、どこに原因があるのかを推測するのが難しくなります。

これまでのプロジェクトでも、画面から送信したデータが意図通りに処理されなかったり、APIがエラーを返してきたりしたときに、原因がどこにあるのか見当がつかず、バックエンド担当のエンジニアに原因調査のヘルプをお願いすることがよくありました。もちろんチームで協力することは大事ですが、自分自身でもっと根本的な原因にアプローチできるようになりたいという気持ちが強くなっていきました。

そこで私は、まずはバックエンドの基礎から学び直してみようと考えるようになりました。過去にJava Silverを受験しましたが力不足のため不合格であり、知識についてもあまり定着したとは言えていない状態です。そのため、まずはPython（Flask）のような比較的優しい言語を使って、APIとDBの連携を理解することを目標に学習を進めています。

Pythonであれば、Flaskなどの軽量なWebフレームワークを使って簡単にAPIサーバーを立ち上げられます。また、PostgreSQLやMySQLといったデータベースとの連携も合わせて学ぶことで、「クライアントからのリクエストがどのように処理され、どのようにDBに保存・取得されるのか」といった、アプリケーションの裏側の流れもより解像度高く見えてくると期待しています。

こうした学びを通して、単なる「画面を作る人」から一歩進んで、「アプリケーション全体の構造を理解し、設計に関われるエンジニア」へと成長したいと考えるようになりました。バックエンドの知識を身につけることで、より広い視点で問題解決ができるようになり、チームへの貢献度も高まるはずです。

サービス全体を見渡せるエンジニアを目指して

最終的には、言語やフレームワークに関係なく、サービス全体の構造を理解し、柔軟に対応できるフルスタックエンジニアを目指していけたらと思っています。もちろん、今後もフロントエンドの技術を磨き続けることは変わりませんが、それに加えてバックエンドの知識や経験も積み重ねていくことで、エンジニアとしての幅を広げていきたいと考えています。