← 前へ: Phase 5.8 | 目次 | 次へ: Phase 6.1 →
実行前に共通セットアップと各Phaseの確認手順を確認してください。演習コードはwork/で前のPhaseから引き継ぎます。
このフェーズでは、これまで自分で構築してきたORM（Model / BaseModel）を振り返り、
- どこまでできているのか
- どこが足りないのか
- なぜ本物のORMは複雑なのか
を分析します。
ここでは新しい機能はほとんど実装しません。
代わりに、
「自分で作ったものを壊すように分析する」
ことが目的です。
以下を説明できる状態になること：
- 自作ORMの限界
- ORMが解決している問題の本質
- ActiveRecordの設計意図
- フレームワークの複雑さの理由
- 自作ORMの弱点を具体的に説明できる
- ActiveRecordの機能が「なぜ必要か」説明できる
- ORMのトレードオフを理解できる
- フレームワークを批判的に読める
- Phase 5.8（BaseModel）完了
- 自作ORMが動作している
まずは、自分のORMが何をできるかを整理します。
以下を書き出してください：
- できること
- 例：all / find / where / save / destroy / validation
- できないこと
- 例：複雑なクエリ、関連など
次に、「実装してみると難しそうなこと」を探します。
以下を実現しようとするとどうなるか考えてください：
- 複数テーブルを結合する（JOIN）
- 条件を組み合わせる
- 並び替え（ORDER BY）
- ページネーション
「Queryは思ったより複雑」
以下のようなコードを想像してください：
users = User.all
users.each do |user|
posts = Post.where(user_id: user.id)
end- SQLは何回発行されるか？
- なぜ問題なのか？
「ORMは簡単に見えてパフォーマンス問題を隠す」
以下のケースを考える：
- ユーザー作成
- 投稿作成
途中で失敗した場合どうなるか？
「複数操作は一貫性を保つ必要がある」
ここで初めて本物を見ます。
対象：
- ActiveRecord の Model
save,where,find
以下を観察してください：
- メソッドの多さ
- 内部構造の複雑さ
- 抽象化のレベル
- なぜこんなに複雑なのか？
以下の観点で比較してください：
| 観点 | 自作ORM | ActiveRecord |
|---|---|---|
| 機能数 | ||
| 柔軟性 | ||
| 学習コスト | ||
| 可読性 | ||
| パフォーマンス |
ORMは何を解決しているか？
- SQLを書かなくてよい
- オブジェクトで扱える
しかし同時に：
- パフォーマンスが見えにくい
- 魔法が増える
「便利さと透明性はトレードオフ」
- すべてORMでよいか？
- 生SQLを書くべき場面は？
Railsは何を提供しているのか？
- ただの便利ツールか？
- 設計の集合体か？
以下を振り返る：
- どこで設計が良かったか
- どこで苦しんだか
- どこをもう一度作り直したいか
以下を含めたレポートを作成してください：
user.posts→ どう実装するか？
→ N+1をどう防ぐか？
ORMの理解をまとめる
必要に応じて
- 抽象的でなく具体的に語れているか
- 自作と既存を比較できているか
- トレードオフを理解しているか
- 批判的に考えられているか
→ なぜすごいかを説明する
→ 学習価値は非常に高い
→ 内部構造に踏み込む
このフェーズで得るべき理解は：
フレームワークとは魔法ではなく、 「現実の複雑さを隠すための設計の積み重ね」である
あなたはここまでで：
- HTTPサーバを実装し
- Webフレームワークを構築し
- ORMを自作した
これはつまり：
「Webアプリケーションの構造を自分の言葉で説明できる」
状態です。
この研修の目的は、
- Railsを使えるようになることではなく
- Railsを理解すること
です。
そして最終的には、
「AIが生成したコードの良し悪しを判断できるエンジニアになること」
です。
ここまでの経験が、その基盤になります。