プロローグ — 設計のロードマップを手に入れる
迷子のエンジニア
ヒロシは画面に映る自分のコードを見て、溜め息をついた。
入社から1年が経った。独学でRuby on Railsを覚え、なんとか実務でも動くものを作れるようになった。でも、何かが足りない気がする。
チームのシニアエンジニア、マイのレビューコメントはいつも同じパターンだった。
「動くけど、もう少し設計を考えてみよう。」 「このクラスの責務が大きすぎる。」 「テストが書きにくいのは、設計の問題かも。」
設計って何だ?どうすれば「良い設計」ができるんだろう……
ヒロシのコードはこんな感じだった。
class UsersController < ApplicationController
def create
user = User.new(params.require(:user).permit(:name, :email, :password))
# メール重複チェック
if User.where(email: params[:user][:email]).exists?
render json: { error: "このメールは既に使われています" }, status: 422
return
end
# パスワードバリデーション
if params[:user][:password].length < 8
render json: { error: "パスワードは8文字以上" }, status: 422
return
end
if user.save
# ウェルカムメール送信
UserMailer.welcome_email(user).deliver_now
# Slackに通知
slack_client = Slack::Web::Client.new
slack_client.chat_postMessage(
channel: "#new-users",
text: "新規ユーザー登録: #{user.email}"
)
# ポイント付与
user.points.create!(amount: 100, reason: "signup_bonus")
render json: { user: user }, status: 201
else
render json: { errors: user.errors }, status: 422
end
end
end400行を超えるコントローラー。ロジックがあちこちに散らばり、テストを書こうとしても何から手をつければいいかわからない。
ロードマップとの出会い
ある日の昼休み、マイが隣に座ってきた。
「ヒロシくん、最近コードに悩んでるよね。ちょっといい?」
マイはホワイトボードに図を描き始めた。
「設計の学び方には順番がある。土台なしに高い建物は建てられないのと同じ。」
マイは続けた。「多くのエンジニアが詰まるのは、コードが動くようになったあと。動くコードと良いコードは違う。そして良いコードから良い設計へ、さらに良いアーキテクチャへ。この旅には地図が必要なの。」
INFO
このロードマップで学ぶこと
設計の力は一日で身につくものではありません。しかし、正しい順序で学べば、確実にステップアップできます。このガイドでは「なぜそれが必要か」を常に問いながら、実際のRailsコードで体験的に学んでいきます。
なぜ設計が重要なのか
「ヒロシくんのコードを例に考えてみよう。」
マイはさっきのコントローラーを指差した。
「このコードが抱える問題は3つある。」
問題1: 変更のコスト
Slackの通知先を変えたいとき、どこを直す?
メール送信のロジックを変えたいとき、どこを探す?
「変更するたびに、このコントローラーを開いて、関係ない部分まで読む必要がある。コードベースが大きくなるほど、変更のコストは爆発的に増える。」
問題2: テストの困難さ
「ユーザー登録のバリデーションだけをテストしたいとき、どうする?Slackに本当に通知が飛ぶかもしれない。メールも。テストのたびにモックを大量に用意しなきゃいけない。」
問題3: 再利用できない
「管理画面からユーザーを作りたいとなったとき?同じロジックをもう一度書くの?それともこのコントローラーをコピペする?」
ヒロシは自分のコードが抱える問題を、初めて言語化して理解した気がした。
# 良い設計への第一歩: 責務を分ける
class UsersController < ApplicationController
def create
result = UserRegistrationService.new(user_params).call
if result.success?
render json: { user: result.user }, status: 201
else
render json: { errors: result.errors }, status: 422
end
end
private
def user_params
params.require(:user).permit(:name, :email, :password)
end
end「これが目指すゴールの一例。コントローラーは入出力だけ。ビジネスロジックはサービスが担う。でも、これだけじゃまだ入り口にすぎない。」
ロードマップの全体像
マイはロードマップの各ステージを説明した。
| ステージ | テーマ | 得られるもの |
|---|---|---|
| Stage 1 | クリーンコード | 読みやすく、変更しやすいコードの基礎 |
| Stage 2 | パラダイム | OOP・関数型・手続き型の使い分け |
| Stage 3 | SOLID原則 | 変更に強いクラス設計 |
| Stage 4 | デザインパターン | 再利用可能な設計の語彙 |
| Stage 5 | アーキテクチャ原則 | コンポーネント間の依存管理 |
| Stage 6 | アーキテクチャスタイル | システム全体の構造 |
| Stage 7 | データベース設計 | データの永続化と検索最適化 |
| Stage 8 | テスト戦略 | 品質を保ちながら変化に強くする |
| Stage 9 | DevOps・CI/CD | 安全で高速なデプロイ |
| Stage 10 | 分散システム | 大規模スケールへの対応 |
「このロードマップは、世界中の優れたエンジニアが試行錯誤して辿り着いた知恵の結晶。一人で発見するには数十年かかるものが、体系的に学べばずっと短い時間で習得できる。」
WARNING
注意: ショートカットはない
各ステージは順番に意味があります。デザインパターンを学ぶ前にSOLIDが必要で、SOLIDを理解するにはOOPが必要です。焦らず、一段ずつ登っていきましょう。
AWSで見るフルスタックの全体像
「インフラの視点からも見てみよう。」
マイはAWSの構成図を描いた。
「フロントエンドのコードも、バックエンドの設計も、インフラの構成も、全部つながっている。フルスタックエンジニアとは、この全体像を理解した上で、どこに問題があるかを診断できる人のこと。」
「一緒に、この旅をしよう。」
ヒロシはノートを開いた。
Stage 1 へ
次の章では、最初の土台「クリーンコード」を学ぶ。
コードが正しく動くことは最低条件。次に問われるのは、人間が読めるかどうかだ。
「コードは機械のために書くのではなく、人間のために書く。」— Robert C. Martin
ヒロシの旅が始まった。