Djangoをゼロから再学習する：HTTPから始める学習ロードマップ

年末になると、自然と過去一年を振り返る時期になります。 私にとって毎年必ず浮かぶテーマが一つあります。それは 「Djangoを本当に学んでいたのか？」 という問いです。

DjangoとDjango REST Framework（DRF）を使い始めてから数年が経ち、大小のプロジェクトを経験してきました。 今では少なくとも次のように言えるようになりました。

「どこがどのように動作しているのか、以前よりは確実に感覚が掴める。」

もちろんまだ知らないことは山ほどありますが、今では過去の自分や、Djangoを始めたばかりの開発者に 「この順序で学べばずっと迷わない」 と伝えられるくらい整理できました。

この記事は、そのような背景で書いた Djangoをゼロから再学習する際の個人的ガイド です。 年末の回顧として読むのもよいですが、いつ読んでも有効な Django学習の基準点 になればと願っています。

1. Djangoは結局HTTPを扱うフレームワーク

Commandbox 광고

とても当たり前のことに思えるかもしれませんが、Djangoを最初に学ぶときはこの事実を忘れがちです。

DjangoはUIをレンダリングするか、JSON APIだけを返すかに関わらず、根本的には HTTPリクエストを受け取り、HTTPレスポンスを返す ことが本質です。

  • クライアント（ブラウザ、アプリ、他のサーバ）がHTTPリクエストを送る。
  • Djangoがそのリクエストを受け取り、適切に処理する。
  • そしてHTTPレスポンス（HTML、JSON、ファイル、エラー等）を返す。

私たちがよく思い浮かべるDjangoの要素は次の通りです。

  • URLConf
  • View（FBV/CBV）
  • Template
  • ORM
  • Middleware
  • Authentication / Permission
  • DRFのSerializer、ViewSet、Router…

これら全ては実際には 「HTTPリクエストをうまく受け取り、処理し、返す」ためのツール」 に過ぎません。

Djangoに初めて触れたとき、この観点を見失うと、フレームワークはすぐに 「魔法の箱」 のように感じられます。

「とりあえずこう使えばいいんだって…使うけど、どうしてこう動くのかが分からない。」

この状態が長く続くと、いつの間にかフレームワークに引きずられ始めます。

2. 華やかな機能より先に「なぜそうするのか」を理解しよう

Djangoを最初に学ぶと、よく目に入る機能は次のようなものです。

  • ログイン/会員登録、ソーシャルログイン
  • 権限/認可処理
  • キャッシュ設定
  • 非同期タスク（Celery等）
  • 各種ミドルウェアと設定値

これらは確かに後で 必要になる機能 です。 問題は、あまりに早く 深掘りしてしまうことにあります。

ある時、こういう疑問が湧きます。

「でもなぜこうしなければならないの？」

この質問に答えられないままコードを積み重ねると、

  • エラーを直しても残念な気持ちが残る
  • 構造を変えようとするたびにフレームワークに足を引っ張られる
  • Google検索の答えをそのまま貼り付けて「とりあえず動くから先に進む」モードになる

そこで過去の自分や、Djangoを始めたばかりの開発者に最初に言いたいことはこれです。

「機能より先に、ウェブの動作原理とHTTPの流れを理解しよう。」

3. HTTPの流れを理解するとDjangoの外側まで見える

Commandbox 광고

Djangoを「透明に」扱いたいなら、HTTPプロトコルの基本的な流れを飛ばすことはできません。

少なくとも次のことを直接触って理解すると良いでしょう。

  • リクエストはどんな構造を持つか
  • URL、メソッド（GET/POST/PUT/DELETE…）、ヘッダー、クエリストリング、ボディ
  • レスポンスは何を基準に決定されるか
  • ステータスコード（200/400/404/500…）、ヘッダー、ボディ（JSON/HTML等）
  • ブラウザは何をキャッシュし、サーバは何を気にするか

簡単な例を挙げてみましょう。ターミナルで次のリクエストを送ってみます。

curl -X GET "http://localhost:8000/articles/1/" -H "Accept: application/json"

このリクエスト一つにHTTPのコアがすべて詰まっています。

  • どのURLへ（/articles/1/）
  • どのメソッドで（GET）
  • どのヘッダーを含めて（Accept: application/json）
  • 何を返してほしいか（JSON）

この流れが頭に描き始めると、Djangoの外側も一緒に見えてきます。

  • なぜnginxで特定のパスをDjangoへプロキシするのか
  • gunicorn/uWSGIなどのWSGIサーバがどんな役割を果たすのか
  • Djangoはどこまで責任を持ち、どこからは他の層の仕事なのか

この段階に到達すると、Djangoはもはや 「分からない魔法」 ではなくなります。 「HTTPリクエストを処理するためにこの程度の構造が必要だ」 というイメージが自然に浮かびます。

そしてそのときに気づくのです。

Djangoの各種便利機能は本質ではなく、付随機能です。 本質（HTTPとウェブの動作原理）を理解すれば、付随機能は自然に追随します。

4. 最初のプロジェクトはシンプルに、FBVで始めよう

image of dev who is developing web service with Django

Django入門時に、私は次のようなアプローチを最もおすすめします。

最初のプロジェクトは意図的にシンプルに、Function-Based View（FBV）で。

可能であれば次の条件を満たすようにしましょう。

  • 認証/権限を最小限に実装したアプリ
  • 管理ページや設定が複雑でない構造
  • 関係が単純なモデル（例：記事、コメント程度）
  • 「素敵な構造」より「動作フロー」を感じられる機能を中心に

例えば、非常にシンプルな記事一覧/詳細をFBVで実装してみましょう。

# views.py
from django.http import JsonResponse
from .models import Article

def article_detail(request, pk):
    article = Article.objects.get(pk=pk)
    data = {
        "id": article.id,
        "title": article.title,
        "content": article.content,
    }
    return JsonResponse(data)

この一つのビューにDjangoのコアフローがすべて詰まっています。

  1. request オブジェクトを引数に受け取る。
  2. URLから渡された pk でORMを通じてデータを取得する。
  3. Python辞書を作成し
  4. それをHTTPレスポンス（JSON）で包む。

このプロセスを一行ずつ追いながらデバッグすると、

  • URLConfがどのようにビューに結びつくか
  • request オブジェクトにどんな情報が入っているか
  • ORMが実際にどんなSQLを発行するか
  • レスポンスがどのようにJSONに変換されるか

すべてが目に入ってきます。

特にこの段階で Django ORMを落ち着いて習得しておくと、 その後どんな規模のプロジェクトでも 大きな資産 になります。

5. 次は速やかにCBVとDRFへ移行しよう

ここまでFBVで「HTTP–View–ORM–Response」フローを体で覚えたら、 次のプロジェクトではためらわずに CBVとDRFを積極的に使う段階 へ移行することをおすすめします。

Djangoの真の力、DRFの真の便利さはこの時点から実感できます。

CBVとDRFは次の価値を提供します。

  • 繰り返しパターンを減らす 再利用可能な構造
  • プロジェクト全体を貫く 一貫したパターン
  • 役割が分離された 明確な責任
  • URL/Serializer/ViewSet/Permissionが絡み合う 拡張可能な設計

例えば、同じ機能をDRFに移すと次のようになります。

# views.py (DRF)
from rest_framework.viewsets import ReadOnlyModelViewSet
from .models import Article
from .serializers import ArticleSerializer

class ArticleViewSet(ReadOnlyModelViewSet):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer

そしてルーターだけ登録すれば。

# urls.py
from rest_framework.routers import DefaultRouter
from .views import ArticleViewSet

router = DefaultRouter()
router.register(r'articles', ArticleViewSet, basename='article')

urlpatterns = router.urls

これで：

  • /articles/
  • /articles/{id}/

といったエンドポイントが自動で動作します。

FBVでHTTPフローを十分に理解した状態なら、CBV/DRFのこうした魔法のような動作も結局こう見えるのです。

「あ、結局その中でも同じHTTPリクエスト/レスポンスフローが回っているんだ。 ただ共通パターンをクラスでうまく抽象化しているだけだ。」

この認識の差が重要です。 CBV/DRFを 「暗記すべき文法」 と捉えると終わりなく混乱しますが、 「既に知っているHTTP処理過程をうまく抽象化したツール」 と見るとずっと速く吸収できます。

そして分からない、理解できない部分があれば、時にはDjangoのソース内部に入ってその構造を覗き見ると良いでしょう。

6. Django学習順序を再整理すると

過去の自分や、今Djangoを始めた開発者に、私は次のように学習順序を提案します。

  1. ウェブとHTTPの基本理解 - ブラウザ–サーバ間のリクエスト/レスポンスフロー - HTTPメソッド、ステータスコード、ヘッダー、クッキー、セッション概念 - 簡単な curl または Postman でリクエスト送信
  2. Django基礎：FBVで一周 - URLConf–View–Template–ORM の基本フローを覚える - 認証/権限なしで動く小さなプロジェクトを完走 - ORMでCRUDを直接実装してみる
  3. Django ORM、Adminを少し掘り下げる - モデル設計、関係（ManyToOne、ManyToMany等）、クエリ最適化を試す - Adminでデータ管理しながらモデル構造に慣れる
  4. CBVへ移行 - Generic ViewでCRUDを再実装 - Mixin、継承構造を見て「パターン抽象化」を体感
  5. DRFでAPIプロジェクトを作る - Serializer、ViewSet、Router、Permission、Authentication 基本 - FBV/CBVで作った機能をDRFで再設計
  6. その後に「華やかな機能」へ - 認証/認可、スロットリング、ページネーション、フィルタ - キャッシュ、非同期タスク、デプロイ、スケーリング等

重要なのは、段階ごとに「なぜこうするのか」を自分で説明できる ことです。 「こうすればいい」と言われるのではなく、「HTTPとウェブの構造だからこうするのが自然」 という感覚まで持つことが目標です。

7. まとめ：フレームワークを暗記しないで、ウェブを理解しよう

最後に、過去の自分や、今Djangoを始めた開発者に必ず残したい言葉があります。

フレームワークを暗記しないで、 ウェブがどう動くかを理解しよう。

Djangoはその理解を助ける素晴らしいツールに過ぎません。

この観点を失わなければ：

  • Djangoのバージョンが変わっても
  • Flask、FastAPI、Node、Spring など他のウェブフレームワークに出会っても
  • 新しいアーキテクチャやクラウド環境に触れても

常に同じ基準で質問できるようになります。

  • 「このシステムはHTTPをどう扱っているのか？」
  • 「どこでどんな責任を持っているのか？」
  • 「この抽象化は結局どんなリクエスト/レスポンスパターンを隠しているのか？」

その基準があれば、特定のフレームワークに縛られず、どんな環境でも揺るがないウェブ開発者へ成長できると信じています。