mybook

プロローグ — 設計のロードマップを手に入れる

迷子のエンジニア

ヒロシは画面に映る自分のコードを見て、溜め息をついた。

入社から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
end

400行を超えるコントローラー。ロジックがあちこちに散らばり、テストを書こうとしても何から手をつければいいかわからない。

ロードマップとの出会い

ある日の昼休み、マイが隣に座ってきた。

「ヒロシくん、最近コードに悩んでるよね。ちょっといい?」

マイはホワイトボードに図を描き始めた。

Loading diagram...

「設計の学び方には順番がある。土台なしに高い建物は建てられないのと同じ。」

マイは続けた。「多くのエンジニアが詰まるのは、コードが動くようになったあと。動くコードと良いコードは違う。そして良いコードから良い設計へ、さらに良いアーキテクチャへ。この旅には地図が必要なの。」

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 3SOLID原則変更に強いクラス設計
Stage 4デザインパターン再利用可能な設計の語彙
Stage 5アーキテクチャ原則コンポーネント間の依存管理
Stage 6アーキテクチャスタイルシステム全体の構造
Stage 7データベース設計データの永続化と検索最適化
Stage 8テスト戦略品質を保ちながら変化に強くする
Stage 9DevOps・CI/CD安全で高速なデプロイ
Stage 10分散システム大規模スケールへの対応

「このロードマップは、世界中の優れたエンジニアが試行錯誤して辿り着いた知恵の結晶。一人で発見するには数十年かかるものが、体系的に学べばずっと短い時間で習得できる。」

WARNING

注意: ショートカットはない

各ステージは順番に意味があります。デザインパターンを学ぶ前にSOLIDが必要で、SOLIDを理解するにはOOPが必要です。焦らず、一段ずつ登っていきましょう。

AWSで見るフルスタックの全体像

「インフラの視点からも見てみよう。」

マイはAWSの構成図を描いた。

Loading diagram...

「フロントエンドのコードも、バックエンドの設計も、インフラの構成も、全部つながっている。フルスタックエンジニアとは、この全体像を理解した上で、どこに問題があるかを診断できる人のこと。」

「一緒に、この旅をしよう。」

ヒロシはノートを開いた。

Stage 1 へ

次の章では、最初の土台「クリーンコード」を学ぶ。

コードが正しく動くことは最低条件。次に問われるのは、人間が読めるかどうかだ。

「コードは機械のために書くのではなく、人間のために書く。」— Robert C. Martin

ヒロシの旅が始まった。