エピローグ — 自分だけのKataを作る

道場を出る日

3ヶ月が経った。タクミは8つのKataを終えた。

最終日、ナオミが言った。「今日で道場は終わり。でも聞いていい？アーキテクチャを"学べた"と思う？」

タクミは少し考えてから答えた。「...いいえ。学び方を学んだ気がします」

ナオミは微笑んだ。「それが正解。アーキテクチャに卒業はない。システムが変わるから、設計も変わる。あなたが今日得たのは"問い続ける習慣"よ」

8つのKataで学んだこと

振り返ってみると、8つのKataを横断する共通の思考パターンがある。

Kata ごとの核心判断

自分だけのKataを作る方法

「次のKataを自分で作るにはどうすればいい？」タクミが聞いた。

ナオミは3つのステップを教えた。

ステップ1: 実際の問題から始める

過去に自分が遭遇した「設計で困ったこと」をリストアップする

例:
- レポート生成が遅すぎて、ユーザーが諦める
- DBの容量が増えすぎて、コストが爆発した
- デプロイするたびにダウンタイムが発生した

ナオミが言った。「良いKataは、あなたが実際に痛みを感じた問題から生まれる。架空の問題より、本物の問題のほうが深く設計できる」

ステップ2: 制約と要件を明確にする

良いKataの要件定義テンプレート:

1. スケール: [ユーザー数 / データ量 / リクエスト数]
2. 整合性: [何の二重処理が許されないか]
3. 可用性: [何時間ダウンしても良いか]
4. コスト: [月額いくらまでか]
5. 開発体制: [何人で何ヶ月か]
6. 将来の変化: [3年後にどう変わる可能性があるか]

ステップ3: 複数の解を比較する

# Kata を書くテンプレート（Markdown）
 
## 課題
[ビジネス要件を物語として記述]
 
## 設計選択肢
| アプローチ | メリット | デメリット | 採用可否 |
|-----------|---------|-----------|---------|
 
## 採用した設計
[判断の理由を書く]
 
## 実装
[コードで示す]
 
## 振り返り
[別の判断をしていたら？]

アーキテクチャ思考の習慣化

「Kata は演習だから、毎日書けるわけじゃない。日常でどう続ける？」

ナオミは5つの習慣を教えた。

習慣1: コードレビューで「なぜ」を問う

コードが動くかどうかではなく、「なぜその設計にしたか」を聞く。

悪いコードレビュー:
「このメソッド名を変えてください」

良いコードレビュー:
「この処理をコントローラーに書いた理由は何ですか？
 サービスオブジェクトにすることも考えましたか？」

習慣2: 障害ポストモーテムを読む

本物の設計判断の失敗から学ぶ。

• AWS のサービス障害レポート
• GitHub のブログのインシデントレポート
• 各社の技術ブログ

習慣3: 設計判断のログをつける

# 設計判断ログ 2024-01-15
 
## 何を決めたか
決済処理を同期処理から非同期Jobに変更した
 
## なぜ決めたか
決済APIのレスポンス時間が3-8秒かかり、ユーザーの待機時間が長い。
タイムアウトエラーも頻発している。
 
## 何を捨てたか
- 即座の決済結果を画面に表示できなくなる
- 決済失敗の通知が遅れる（メールで通知に変更）
 
## 3ヶ月後の評価日
2024-04-15 に振り返る

タクミは言った。「決めたことだけ書くんじゃなくて、捨てたことも書くんですね」

「そう。何を得て何を捨てたか、それがトレードオフの記録よ」

習慣4: 既存システムのアーキテクチャを読む

OSS のコードは最高の教科書だ。

習慣5: 設計を声に出して説明する

「一番成長したのは、設計を人に説明するとき」とタクミは言った。

「そう。説明できない設計は、理解できていない設計。5分で話せなければ、設計が複雑すぎるか、自分が理解できていないかのどちらか」

タクミが自分で作った最初のKata

道場を出た翌週、タクミは自分の仕事から最初のKataを作った。

自作Kata: レポート生成の非同期化

現在の問題: 月次売上レポートの生成に5分かかり、ブラウザがタイムアウトする

制約:

• データ量: 月間100万件の取引データ
• 許容遅延: 15分以内に生成完了（リアルタイム不要）
• 開発: 1名、2週間

設計選択肢:

1. タイムアウトを延ばす（30分に）→ ユーザーが待てない
2. バックグラウンドJobで生成 + 完了メール通知 → 採用
3. 事前生成（定期バッチ） → 最新データが反映されない

採用した設計: Sidekiq Job + ActionCable でリアルタイム進捗通知

# app/jobs/report_generation_job.rb
class ReportGenerationJob < ApplicationJob
  queue_as :reports
 
  def perform(report_id, user_id)
    report = Report.find(report_id)
    report.update!(status: :processing, started_at: Time.current)
 
    # 進捗をリアルタイムに通知
    broadcast_progress(user_id, 0, "集計を開始しています...")
 
    # データ集計（時間がかかる部分）
    data = SalesAggregator.aggregate(
      from: report.period_start,
      to: report.period_end,
      on_progress: ->(percent) { broadcast_progress(user_id, percent, "集計中...") }
    )
 
    broadcast_progress(user_id, 80, "レポートを生成しています...")
    pdf_url = ReportPdfGenerator.generate(data, report)
 
    report.update!(
      status: :completed,
      file_url: pdf_url,
      completed_at: Time.current
    )
 
    broadcast_progress(user_id, 100, "完了しました")
  rescue => e
    report.update!(status: :failed, error_message: e.message)
    broadcast_progress(user_id, -1, "エラーが発生しました")
    raise
  end
 
  private
 
  def broadcast_progress(user_id, percent, message)
    ActionCable.server.broadcast(
      "report_progress_#{user_id}",
      { percent: percent, message: message }
    )
  end
end

「この Kata を書くのに2時間かかりました。でも次に同じような問題が来たときは、30分で判断できる自信があります」

ナオミは言った。「それがKataの目的。判断を身体に染み込ませること」

アーキテクチャの本質

「最後に一つ聞いていい？」とタクミは言った。「アーキテクチャって、何のためにあるの？」

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

「アーキテクチャは、変更のためにある。完璧なシステムを最初から作るためではない。要件が変わったとき、チームが変わったとき、スケールが変わったとき、最小のコストで変更できるようにするための設計よ」

「だから"良いアーキテクチャ"は永遠に正しいわけじゃない。今日の制約の中での最善の判断。そしてその判断を記録し、変化に合わせて更新し続けること」

これからの学び方

次に読むべきもの

自分のKataリストを作る

# 私のKataリスト
 
## 解決済み
- [x] レポート生成の非同期化
- [x] 画像アップロードのPresigned URL化
 
## 次に取り組む
- [ ] APIレートリミットの設計
- [ ] バッチ処理の並列化
 
## いつか解決したい
- [ ] グローバル展開のためのリージョン分散
- [ ] イベントソーシングへの移行

タクミのノート、最後のページ

タクミは道場の最終日、ノートの最後のページにこう書いた。

アーキテクチャの3つの問い

1. 何が制約か（スケール・予算・人員・時間）
2. 何が壊れると致命的か（リスクの優先順位）
3. 変更したいとき、何が難しくなるか（変更コスト）

この3つを問い続ける限り、設計は改善される。

ナオミが最後に言った言葉を書き留めた。

「道場は終わり。でもあなたは毎日、設計の選択をしている。そのたびに"なぜ"を問いなさい。それが、一生続くKataよ」

本書を読み終えた今、あなたのKataを始めよう。 最も良い最初の一歩は、昨日書いたコードに問いかけることだ。

なぜ、その設計にしたのか？