GENIEE RECOMMENDの開発を担当している2年目の中村です。
本記事では、株式会社ジーニーで行っているエンジニア新卒研修であるbootcampで私が担当した講義「バックエンド研修/WebAPIサーバ作成」について紹介します。
ジーニーにおけるbootcampとは
入社2年目のエンジニアが主体となって運営と講義を行い、新卒エンジニアが受講者として参加する研修です。bootcamp全体としての狙いは以下の通りです。
- データサイエンス, 競技プログラミング, アプリ開発などそれぞれ違った経験を持つ新卒が集まっているため、プロダクト開発を行うにあたり必要になりうる知識や技術に幅広く触れ、全体としての底上げを図ること
- チーム開発の経験が浅いメンバーが配属前にチーム開発のフローを経験すること
- 配属前に新卒エンジニア同士で教え合うことで、配属後のスムーズなコミュニケーションに繋げること
- 2年目エンジニアが1年間で学んだ知識の棚卸しを行うことでより深い理解を得ること
BootCamp内での当該講義の位置付け
Webサービスを提供するにあたって、レスポンスにJSONを返す典型的なバックエンドサーバーの活用場所を理解したうえで、OpenAPIを利用したスキーマ駆動の安全な開発方法の紹介と演習を通して、実務で行うバックエンドサーバー実装の一助になることを目標としています。
本講義は、bootcamp全体の流れの中で以下のような位置付けとなっています：
- 前提知識: データベース、フロントエンド技術の基礎を学習済み。また言語については、pythonは全員ある程度使える前提であり、Goは前日に導入を行っている
- 本講義の役割: バックエンドとフロントエンドを繋ぐAPIサーバーの実装方法を習得すること
- 次回以降: 学習した内容を統合してチーム開発でのプロダクト制作に活用
特に、他の講義で学んだ知識を統合的に活用できるよう、データベース連携やフロントエンドとの通信方法についても実践的な演習を通して理解を深める構成としました。
講義概要
この講義は、バックエンドサーバーの役割からWebAPIフレームワークを用いた実装まで、体系的に学習することを目的として、座学と演習を1日(8時間)で行う研修です。章立てとしては以下のような流れで行いました。
1. バックエンドサーバの役割
最初のセクションでは、バックエンドサーバーが必要とされる理由について深掘りしました。単純なCRUDアプリケーションであっても、クライアント側から機密情報（DBアクセス情報、認証情報）を隠す必要性があることを説明し、SQLでは記述しにくい複雑な処理の実装例を紹介しました。また、フロントエンドとバックエンドの疎結合を実現するインターフェースの固定化など、バックエンドサーバーが果たす重要な役割を解説しました。
技術選択の観点では、Google Firebase や Supabase といった Backend as a Service との比較も行い、それぞれのメリット・デメリットを踏まえた判断基準についても触れました。
2. Web API
Web APIのセクションでは、REST API、gRPC、tRPCといった主要なAPI設計スタイルの特徴を比較解説しました。特にREST APIとOpenAPI Specificationの関係性に重点を置き、OpenAPIの仕様書からSwagger UIを使ったGUIでのAPIテスト方法を実演しました。さらに、OpenAPIクライアントライブラリを活用したコード自動生成まで、実務で活用できる一連の流れを体験してもらいました。
3. APIフレームワーク
実装面では、PythonのFastAPIを使用してAPIフレームワークの基本機能を学習しました。ルーティング、パスパラメータ、クエリパラメータといった基本的な機能から始め、リクエスト・レスポンスボディの定義、ヘッダー処理、ミドルウェアの実装まで、WebAPIサーバー開発に必要な要素を段階的に習得できる構成としました。
Pydanticを使ったデータバリデーションの仕組みや、OpenAPIドキュメントの自動生成についても実際に手を動かしながら理解を深めました。発展課題として、前日に学習したGolangを用いて、FastAPIで作ったサーバーと同じ働きをするサーバーをoapi-codegenを使ってOpenAPIからコードを生成するフローも体験してもらいました。
4. アーキテクチャスタイル
アーキテクチャ設計では、3層アーキテクチャとオニオンアーキテクチャの比較を通じて、プロジェクトの規模や要件に応じた設計パターンの選択について学習しました。小規模プロジェクトでは3層アーキテクチャのシンプルさが有効である一方、データの整合性により厳しいルールを課したい場合はオニオンアーキテクチャが適していることを、実例とともに説明しました。
5. シナリオテスト
開発したAPIの品質保証として、k6を使ったシナリオテストの導入を行いました。Testing Trophyの概念を紹介し、統合テストが開発効率と信頼性のバランスに優れている理由を解説することで、実際のプロダクト開発における品質管理の考え方も身につけられる内容としました。
6. 課題演習
座学で学んだ内容を実践する課題演習を実施しました。実際のWebサービスを想定したAPIサーバーの実装をシナリオテスト駆動で行い、その日学んだ知識を統合的に活用する機会を提供しました。
抜粋ハイライト1 ~OpenAPI開発アプローチの比較~
OpenAPIとSwaggerの活用についても、実務での運用を意識した内容としました。手作業でのYAML/JSON作成の大変さを実感してもらった上で、「コードから自動生成したらいいんだ！」という気づきを得られるよう構成しました。ハンドラ駆動とスキーマ駆動の両方のアプローチを紹介し、プロジェクトの特性に応じた選択ができる知識を提供しました。
ハンドラ駆動 （FastAPI）
特徴：
- 実装が先行し、仕様書が後から生成される
- 開発スピードが速い
スキーマ駆動 （oapi-codegen）
特徴：
- 仕様書を起点とした開発
- フロントエンドとバックエンドの並行開発が可能
抜粋ハイライト2 ~アーキテクチャパターンの比較~
アーキテクチャ設計では、3層アーキテクチャとオニオンアーキテクチャの比較を通じて、プロジェクトの規模や要件に応じた設計パターンの選択について学習しました。小規模プロジェクトでは3層アーキテクチャのシンプルさが有効である一方、データの整合性により厳しいルールを課したい場合はオニオンアーキテクチャが適していることを説明しました。
3層アーキテクチャ（レイヤードアーキテクチャ）
特徴：
- シンプルで理解しやすい構造のため、小〜中規模のプロジェクトに適している
- 各層が上位層に依存する一方向の依存関係のためデータベース中心の設計になりがち
オニオンアーキテクチャ
特徴：
- 複雑なビジネスルールを扱うプロジェクトに適している。特にDBのテーブル設計では対応しきれないルールも厳密に対応することができる
- 依存注入など初期の学習コストは高くなりがちだが、ロジックロジックが外部技術（データベース、フレームワーク）に依存しないので保守が用意
講義を行ってみて
本研修の最大の特徴は、「シナリオテスト駆動でWebAPIサーバーを構築する体験」を提供することでした。よくある研修では実装が先行しがちな中で、本研修では最初にk6を使ったシナリオテストを書き、そのテストを通すための実装を行うというアプローチを採用しました。今回の研修ではAIの活用を推進しているので、その点でも振る舞いに関する受け入れ条件を厳密に保つという点で、シナリオテストは推奨される手法の一つです。
またフレームワークについては、FastAPIのように、コードからOpenAPIを作成する手法をハンドラ駆動と呼ぶ一方で、OpenAPIからコードを生成するスキーマ駆動の両方に実際に触れることで、それぞれの良さと大変さを感じて貰えたと思います。ただ、OpenAPIの仕様書の自動生成として、FastAPIを利用しましたが、最近の流行りだと、pythonよりもTypeScriptな気がするので、TypeScriptとzod-openapiの組み合わせでも面白かったと思いますね。
講義スライド
講義スライド全体はこちらです。なお講義の後に課題を行なっていますが、こちらは割愛させていただいております。
参考・関連
firebase
supabase
oapi-codegen
fastapi
zod-openapi
swagger
k6
Discussion