プロローグ — アーキテクチャ道場へようこそ

道場の扉を開いた日

4月の月曜日、タクミは会社の人事異動で「技術推進室」に配属された。 前職ではRailsアプリのCRUDを書き続けて3年。コードを書くことは得意だが、「なぜそう設計するのか」を問われると言葉に詰まる日々が続いていた。

技術推進室の室長、ナオミは画面越しに静かに言った。

「タクミさん、あなたはコードの書き方を知っている。でも、私が教えたいのは"判断の仕方"よ。アーキテクチャとは、選択の連続なの」

# タクミが最初に見たコード — シンプルに見えるが、何かが足りない
class PostsController < ApplicationController
  def create
    @post = Post.new(post_params)
    if @post.save
      redirect_to @post
    else
      render :new
    end
  end
end

ナオミはこのコードを見て言った。「このコードに何が欠けているか、わかる？」 タクミは答えられなかった。バリデーション？認証？それとも別の何か？

「欠けているのは"問い"よ。なぜ、このアーキテクチャを選んだのか、という問い」

アーキテクチャ Katas とは

Katas（型） は武道の練習法に由来する言葉だ。同じ動作を繰り返すことで、身体に判断を染み込ませる。アーキテクチャ Katas も同じ発想だ。

Kata の構造

各 Kata は次の4段階で進む。

• 要件定義: ビジネス要件を明確にする。「何人が使うか」「どんな失敗が許されないか」
• 設計判断: トレードオフを検討する。スケーラビリティ vs シンプルさ、コスト vs 可用性
• 実装例: Rails と AWS で具体的に示す
• 振り返り: 「別の判断もあったのでは？」と問い続ける

なぜ Katas が必要か

ナオミはホワイトボードに数字を書いた。

設計の決定は、開発コストの 80% に影響する

「最初のアーキテクチャ選択は、後から変えるのがとても難しい。でも、その選択を練習する場がない。だから Kata が必要なの」

アーキテクチャの判断軸

良いアーキテクトは、次の問いを常に持っている。

道場の全体像

本書で扱う Kata は以下の8つだ。

レベルの流れ: Kata 1 はシンプルなモノリスから始まる。進むにつれ、分散システムの複雑さと向き合うことになる。

学び方のルール

ナオミはタクミに3つのルールを告げた。

ルール1: 先に答えを考える

「私が課題を出したら、まず自分で設計を考えなさい。本を読む前に。正解を求めるのではなく、自分の判断を持つこと」

ルール2: トレードオフを言語化する

「なぜその選択をしたか、必ず言葉にする。"良さそうだから"は答えじゃない。"スケーラビリティより開発速度を優先したから"と言える設計者になりなさい」

ルール3: 振り返りを続ける

「実装した後、必ず問いなさい。"別の選択をしていたら？"。これが経験を知識に変える唯一の方法よ」

タクミの最初の問い

「ナオミさん、良いアーキテクチャって何ですか？」

ナオミは少し間を置いて答えた。

「良いアーキテクチャとは、変更コストが最も安いアーキテクチャよ。今日の要件に完璧に応える設計ではなく、明日の変更を安く受け入れられる設計。それを目指しなさい」

環境準備

各 Kata を手を動かしながら学ぶために、以下を準備しておこう。

# Rails のセットアップ
gem install rails
rails new kata_app --database=postgresql
cd kata_app
 
# 必要な gem（各 Kata で追加）
bundle add redis
bundle add aws-sdk-s3
bundle add elasticsearch-model

AWS の環境については、AWS CLI と適切な IAM ロールが必要だ。各 Kata で具体的な設定を示す。

まとめ

「さあ、最初の Kata を始めましょう」とナオミは言った。「最も基本的な課題から。でも、シンプルに見えるほど、奥が深い」

タクミは手元のノートに書いた。

今日の学び: アーキテクチャとは選択の連続。選択には必ず理由が必要。

次の章では、Kata 1「ブログプラットフォーム」に取り組む。Rails の scaffold から始まり、「なぜモノリスなのか」を問い続ける。