ゲームエンジニアが Web バックエンドに挑戦した 3 か月 - Todo リスト API 演習で学んだ設計と実装の勘所 -

はじめに

私はもともとゲームエンジニアリングの領域でキャリアを積んできました。これまで扱ってきたのは Unity や C++ を使ったリアルタイム制御やサウンド寄りの実装であり、 Web アプリケーションや REST API の設計については体系的な学びの経験がありませんでした。

現職に合流する段階で、業務のなかで Web 領域のスキルが求められることはわかっており、必要な学習機会を希望しました。そこで社内の先輩エンジニアの協力のもと、 「バックエンドエンジニア育成計画」 という取り組みをスタートしました。

この取り組みでは、TypeScript + Express + Prisma + MySQL という技術スタックを用い、「Todo リスト API」を題材に設計から実装まで一通りを経験しました。実装したコードに対して、先輩エンジニアから日々レビューを受けながら学習を進める形をとりました。

この記事では、その 3 か月間の育成プロジェクトを振り返りながら、特に印象に残った設計上の勘所や、ゲームエンジニア視点で気付きのあったポイントをまとめます。同じようにバックエンド領域へチャレンジする方の参考になれば幸いです。

学習プロセスについて

取り組みの概要

• 演習テーマ：Todo リスト API の設計と実装
• 技術スタック：TypeScript + Express + Prisma + MySQL
• 期間：約 3 か月
• 進め方：
  • 会議：隔週 1 回
  • Notion でレポート提出：週 1 回
  • レビュー：最頻で 1 日 1 回（GitHub ベース）
  • プルリクエストと Notion で学習記録を蓄積

学習方法として特に良かったと感じているのは、「ただコードを書く」のではなく、必ず コードレビューを通じてフィードバックを得る という点です。このプロセスを通じて、たとえば 「バリデーション設計の粒度」 や 「命名」 「RESTful の考え方」 など、設計や実装の具体的な選択肢とその背景理由について理解を深めることができました。

ゲームエンジニア時代から、他者からのレビューを受けてコードを良くしていくことの効果は強く実感しており、この育成計画でも同様にレビューを通じた改善を重視しました。

得られた知見

この育成計画を通じて、Web バックエンド領域における設計・実装の基礎的な考え方について理解を深めることができました。ここでは、特に印象に残ったポイントをいくつか挙げます。

バリデーション設計の粒度と責任分担

リクエストを受け取る API 側でどこまで入力値を検証するべきか、またエラー時にはどのような情報を返すべきかという設計方針について学びました。

バリデーションエラーの内容は、単に「バリデーションエラー」というメッセージを返すだけでは不十分であり、「どの項目に、どういう問題があるか」 を具体的に示すことが重要であると教わりました。

下記のように、責任の分担について、どこまでを API 側で担い、どこからをデータベース制約とするのかを意識的に設計する視点を持てるようになりました。

• 「アプリケーション層で検証するもの」
• 「データベース側で守らせるべき制約」
• 「二重にチェックすべきかどうか」

特に、ゲーム開発の経験からは「クライアント側でしっかりチェックしていればよい」と考えてしまいがちでしたが、不正なデータがサーバーに直接入る可能性を意識することが大切であると認識を改めました。

命名と設計の粒度

クラス名、関数名、API 名といった命名について、レビューを通じて多くの指摘を受けました。

特に、以下のような点を意識するようになりました。

• 「役割が曖昧な名前を避ける」
• 「名付けによって利用者の理解を助ける」
• 「不要に抽象化しすぎない」

また、設計の粒度についても、「この関数は何を責務として持つべきか」 「どこまでを 1 つのエンドポイントにまとめるべきか」といった考え方を整理できたと考えています。

RESTful 設計とリソース指向の考え方

「RESTful であるとはどういう状態か」という点について、単なる URL の形や HTTP メソッドの選び方以上に、 「そのエンドポイントが何のリソースを表しているのか」 を意識して設計する必要があると理解しました。

またレビューの中で、「エンドポイントの名前や HTTP メソッドが、そのリソースの意図を適切に表現できているか？」 といった点を何度も問い直す機会となりました。

HTTP ステータスコードについても、使い方そのものは知っていましたが、「どういう状況で 404 を返すべきか」 や 「204 No Content の採用基準」 など、曖昧になりがちな境界部分を設計上どう整理するかについて議論する機会があり、API の使い手から見て一貫性のある設計を意識することができました。

外部ライブラリ活用と「自前で作らない」判断

ゲーム開発においては「自分で書いたほうが理解しやすい」 「外部に依存しないほうが安心」という感覚を持っていましたが、 Web 開発においてはその考え方が必ずしも適切ではない場面が多いことを学びました。

具体的には、下記のような方針によって、コードの可読性や保守性を高められることを経験しました。

• バリデーション処理を自作するのではなく zod などのライブラリを活用する
• Prisma を用いた ORM により SQL 文を直接書かずにスキーマ管理する

「車輪の再発明」を避けるという判断基準についても、実装を通じて感覚がつかめるようになってきたと感じています。

今後への活用

この育成計画を通じて得た知見は、現職での Web API 開発に限らず、今後のさまざまな業務に活かせると考えています。

特に、自分がもともと関わってきたゲーム開発の領域でも次のような場面で、今回学んだ「設計上の責任分担」や「リソース指向の考え方」が応用できると感じています。

• サーバーサイドとのデータ連携
• ツール開発や運用系の仕組みづくり
• 外部サービスとのインテグレーション

また、これまでの経験では「動けばよい」という観点で設計や実装を進めがちだった部分についても、「なぜこの設計を選ぶのか」 「どこにリスクがあるのか」を意識的に考える習慣が身につきはじめています。

設計の選択肢について、以下のような判断を今後も説明できる形で積み重ねていきたいと考えています。

• 自前で作るか、ライブラリを使うか
• どこまで汎用化するべきか
• バリデーションやエラーハンドリングをどの層に持たせるべきか

今回の取り組みはあくまで基礎的な演習に過ぎませんが、このプロセスを通じて得た設計観や問題意識が、今後の開発実務における判断の質を支える土台となることを期待しています。

今後は、実際の業務で扱う API 設計やデータ連携の実装にも積極的に関わり、設計レビューの場でも今回学んだ観点を持ち込んでいきたいと考えています。

おわりに

本記事では、ゲームエンジニアとしてのバックグラウンドを持つ自分が、社内の育成機会を通じて Web バックエンド領域の設計・実装について学んだプロセスを振り返りました。

自分ひとりで書籍やチュートリアルを進めるだけでは得られなかった観点や設計上の判断基準について、日々のコードレビューを通じて具体的に掘り下げることができたのは、先輩エンジニアの丁寧なフィードバックのおかげです。

特に、今回の取り組みでは「正しく動くコードを書く」だけでなく、次のような点を重視する姿勢を学ぶことができました。

• その設計を選ぶ理由を説明できること
• 他の人が読み、使い、保守することを考慮すること

この育成計画に時間を割いてくださった社内の皆さまに、あらためて感謝いたします。今後もレビューを通じて継続的に学びを深めながら、自律的に設計判断ができるよう取り組んでいきたいと考えています。