レストランに例える、Webサービスの全体構成【第1回】エンジニア未経験でもわかる、Webサービスの構成

Web・アプリサービスの構成について、レストラン運営を例にして分かりやすく説明します。

「フロントエンド」「バックエンド」「データベース」「インフラ」などの用語は、初めて聞くと難しそうに感じるかもしれません。

そこで今回は、システム構成をレストラン運営にたとえて解説します。

📝 この連載は「レストランのお仕事」を例に、開発の全体像をざっくり紹介できるように作りました。

最初は難しい仕組みまで全部覚える必要はありません。少しずつ成長しながら、「もし将来こういう課題にぶつかった時には、あの話を思い出してね！」というイメージで気楽に読んでいただければOKです。

🏠 1. レストランのホール = フロントエンド

お客様が最初に目にし、メニューを選び、注文する場所です。つまり、Webサイトやアプリの画面＝「ホール」です。

• インテリア（デザイン）→ UI/UX
• メニュー選択・注文 → ユーザーの操作（ボタンのクリック、フォーム入力など）

🤝 2. スタッフ = API

スタッフはお客様（フロントエンド）とキッチン（バックエンド）をつなぐ役割です。

お客様の注文をキッチンに伝え、完成した料理をお客様に運びます。

APIは、データをやり取りする通路です。

• 注文を受け取る → リクエスト（Request）
• 料理を運ぶ → レスポンス（Response）

※ APIの役割は、注文内容（リクエスト）を決まった形式で受け取り、キッチン（バックエンド）に伝える「インターフェース（窓口）」です。

👨‍🍳 3. キッチン = バックエンド

キッチンでは実際に料理（ロジック）を作ります。レシピ（ビジネスロジック）に従って材料（データ）を取り出し、調理して結果を作ります。

• レシピ → サービスロジック
• シェフ → バックエンドサーバー
• 完成した料理 → APIレスポンスデータ（JSONなど）

🧊 4. 冷蔵庫・倉庫 = データベース

キッチンが使う材料を保存しておく場所です。データベース（DB）はサービスに必要なすべてのデータが格納されています。

• 材料取り出し → データの取得（SELECT）
• 材料追加 → データの保存（INSERT）
• 材料入れ替え → データの更新（UPDATE）

💡 全体の流れをまとめると

1. ユーザーがWebサイト（＝レストランホール）にアクセス
2. 画面（UI）でメニュー（機能）を選び、注文（リクエスト）する
3. API（＝スタッフ）が注文内容をバックエンド（＝キッチン）に伝える
4. バックエンドはデータベース（＝冷蔵庫）から材料を出して調理
5. 完成した結果をAPI経由でもう一度フロントエンドに返却
6. ユーザーは画面で結果を確認できる

🍴 サービスが完成するまで

このように、Webやアプリの基本構成はレストラン運営とよく似ています。

• フロントエンドはお客様と接するホール

• APIは注文を運ぶスタッフ

• バックエンドは料理を作るキッチン

• データベース（DB）は材料を保存する冷蔵庫

  この流れで各要素が連携し、1つのサービス（＝レストラン）が成立しています。

次回は、キッチンの中身についてより詳しく解説します。

キッチンの仕事もさまざまですから!