フロントエンドとバックエンド

なぜ分かれているのか

Webアプリケーションは、大きく2つの領域に分かれます。

graph LR
    subgraph フロントエンド
        A[ブラウザ/アプリ]
    end
    subgraph バックエンド
        B[サーバー]
        C[(データベース)]
    end
    A <-->|HTTP/API| B
    B <--> C

この分離には理由があります：

• セキュリティ：重要なデータや処理をサーバー側で管理
• パフォーマンス：重い処理をサーバーで、軽い処理をクライアントで分担
• 保守性：画面と処理を分けることで変更しやすくなる

フロントエンド技術

基本技術（必須）

どのフロントエンド開発でも使う基本技術です。

フロントエンドフレームワーク

現代の開発では、JavaScriptのフレームワークを使うことが一般的です。

SPAとMPA

フロントエンドには大きく2つのアーキテクチャがあります。

graph TB
    subgraph "SPA（Single Page Application）"
        S1[初回: HTML+JS一括取得]
        S2[以降: APIでデータのみ取得]
        S3[画面切替: JSで書き換え]
    end
    subgraph "MPA（Multi Page Application）"
        M1[毎回: サーバーでHTML生成]
        M2[画面切替: ページ遷移]
    end

バックエンド技術

サーバーサイド言語とフレームワーク

バックエンドの開発言語は多様です。現場によって使う技術が異なります。

データベース

バックエンドはデータベースと連携してデータを管理します。

詳細は データベースの基礎 を参照してください。

フルスタックフレームワーク

フロントエンドとバックエンドを一つのフレームワークで開発できるものもあります。

主なフルスタックフレームワーク

Next.jsの例

Next.jsでは、同じプロジェクト内でフロントエンドとAPIを開発できます。

my-app/
├── app/                    # フロントエンド（React）
│   ├── page.tsx           # トップページ
│   └── users/
│       └── page.tsx       # ユーザー一覧ページ
├── app/api/               # バックエンド（API）
│   └── users/
│       └── route.ts       # ユーザーAPI
└── package.json

graph LR
    subgraph Next.js
        F[フロントエンド
React コンポーネント]
        B[バックエンド
API Routes]
    end
    F -->|fetch| B
    B --> DB[(データベース)]

実際の業務パターン

現場では、様々な開発パターンがあります。自分がどのパターンで開発するのか把握しましょう。

パターン1: フロントエンドのみ開発

graph LR
    subgraph 担当範囲
        A[フロントエンド]
    end
    subgraph 別チーム/外部
        B[既存API]
    end
    A -->|API呼び出し| B

特徴：

• 既存のAPIを使って画面を作る
• API仕様書を読んで連携する
• 画面設計・UIに集中できる

よくある現場：

• 大規模プロジェクトで分業している
• 外部サービスのAPIを利用する
• モバイルアプリ開発

パターン2: バックエンドのみ開発

graph LR
    subgraph 別チーム
        A[フロントエンド]
    end
    subgraph 担当範囲
        B[API開発]
        C[(データベース)]
    end
    A -->|API呼び出し| B
    B --> C

特徴：

• API設計・実装に集中
• データベース設計も担当することが多い
• API仕様書を作成する側

よくある現場：

• マイクロサービス開発
• 複数クライアント（Web・モバイル）向けAPI
• データ処理・バッチ処理

パターン3: フロントエンドもバックエンドも開発

graph LR
    subgraph 担当範囲
        A[フロントエンド]
        B[バックエンド]
        C[(データベース)]
    end
    A --> B
    B --> C

特徴：

• 機能全体を一人（または少人数）で担当
• 画面からデータベースまで一貫して理解
• 小回りが利く

よくある現場：

• スタートアップ・ベンチャー
• 小規模チーム
• 社内ツール開発

パターン4: フルスタックフレームワークで一体開発

graph LR
    subgraph fullstack["担当範囲（Next.js/Rails等）"]
        A[画面]
        B[API/コントローラ]
        C[モデル/DB]
    end
    A --> B --> C

特徴：

• 一つのフレームワークで完結
• 開発環境がシンプル
• チーム全員が同じ技術スタック

よくある現場：

• Webサービス開発
• プロトタイプ開発
• 中小規模のプロジェクト

技術選定の背景を理解する

なぜその技術が選ばれているか

現場で使われている技術には理由があります。

技術の組み合わせ例

よくある技術スタックの組み合わせです。

まとめ

覚えておくべきこと

1年目にやるべきこと

• 自分の現場がどのパターンか把握する
• 使われている技術スタックを確認する
• 担当範囲（フロント/バック/両方）を明確にする
• 技術選定の理由を先輩に聞いてみる

関連ページ

• コードを読む基礎
• コードを書く基礎
• データベースの基礎
• API仕様書の読み方