10年越しで理解した『アナリシスパターン』― なぜ"わかりにくい設計"が最強の仕様変更耐性を生むのか

はじめに

これまで読んできた技術書の中で、最も感銘を受けた一冊を挙げるとしたら、私は迷わずマーティン・ファウラーの『アナリシスパターン』を選びます。

ただし、この本を「最も感銘を受けた」と言えるようになるまでには、実に10年以上の歳月がかかりました。最初は挫折し、実務で再会しても全く歯が立たず、有識者に教わっても理解できませんでした。それでもある瞬間、すべての疑問が一気に繋がった――今回はその体験を、実務で出会った具体例とともに振り返ってみたいと思います。

1. 2003年、読書会での挫折

私が『アナリシスパターン』を手に取ったのは2003〜2004年頃のことです。当時、業界内で高く評価されていたこともあり、購入して読書会まで開きました。

しかし、結果は惨敗でした。何度読んでも腹落ちしませんでした。「知識レベル」「操作レベル」――まるで暗号のような言葉が並んでいました。

正直なところ、当時の私はこう思っていました。

なんであえてこんな分かりづらい設計にするのだろう？　具体的に設計した方が、よっぽど分かりやすいシステムになるはずなのに。

読書会のメンバーも同様で、議論は深まらないまま、いつしか本は本棚の奥にしまわれることになりました。

2. 10年後、プロジェクトでの再会と衝撃

それから約10年後。私はドメイン駆動設計（DDD）のプロジェクトに参画することになりました。

普段であれば、テーブル構成を見ればある程度その業務内容を推測できます。テーブル名やカラム名から「これは受注に関するテーブルだな」「これは在庫管理だな」と当たりをつけられるからです。

ところが、このプロジェクトのテーブルやクラスは、抽象度が高すぎて全く読み解けませんでした。具体的な業務用語がほとんど登場せず、「資源」「移動」といった抽象的な言葉ばかりが並んでいたのです。

長年の経験が全く通用しない感覚。これは正直、衝撃でした。

3. 有識者のレクチャーでも理解できなかった

さすがにこのままでは仕事にならないので、プロジェクトの有識者からレクチャーを受けることにしました。

しかし――それでも理解できませんでした。しかもこれは私だけの話ではなく、他のプロジェクトメンバーも同じ状況でした。丁寧に説明を受けても、「なぜこの設計にする必要があるのか」という核心の部分が、どうしても腑に落ちないのです。

レクチャーというインプット型の学習だけでは、このパターンの本質には届かない。今振り返ると、そう感じます。

4. 疑問が一気に繋がった瞬間

転機が訪れたのは、要件定義書とデータモデルを地道に突き合わせていた時でした。

「なぜあえてこんな分かりづらい設計にするのだろう？」という、最初に抱いた疑問と向き合いながら作業を続けるうち、あるとき、いろいろな疑問が一気に繋がりました。

気づいたのは、次のようなトレードオフの存在です。

• 具体的な設計：分かりやすいシステムになる。ただし、仕様変更のたびにコードを具体的に修正する必要がある
• 抽象的な設計：一見分かりにくい。しかし、仕様変更に圧倒的に強くなる

この二つは、どちらが正しいという話ではなく、トレードオフの関係にあったのです。そして、このトレードオフを最も分かりやすく体感させてくれたのが、次に紹介する「資源」の抽象化という考え方でした。

5. ビール輸送に見る「資源」の抽象化

例えば、缶ビールをトラックで輸送するとき、次のような階層構造になっているとします。

• トラック（輸送・設備資源）
  • パレット（荷役・循環資源）
    • 段ボール箱／ケース（梱包・在庫資源）
      • 缶ビール（350ml／500ml）（商品・単品）

一見すると、これらはまったく別の物です。トラックと缶ビールを同じ概念で扱うなんて、直感的には不自然に感じるかもしれません。

しかし、これら全てを 「資源」という一つの抽象概念 で捉え直すとどうなるでしょうか。

ここに新しく「マルチパック（6本パック）」という商品を追加したくなったとします。具体的な設計であれば、新しい商品区分ごとにテーブルやコードを追加する必要が出てくるかもしれません。しかし、すべてを「資源」として抽象化しておけば、マルチパックもまた一つの資源として扱えます。つまり、コードを1行も変更することなく、データを追加するだけでこの仕様変更に対応できるのです。

このことに気づいた瞬間、10年来のすべての疑問が解けたような感覚がありました。「知識レベル」とは、この"資源とは何か"というルールや種類を定義する層であり、「操作レベル」とは、実際に起きた事実（このトラックにこのパレットが積まれた、等）を記録するだけの層だったのです。また、このモデルに基づいた実装もかなりシンプルになりました。

ちなみに、最初に面食らった「移動」という言葉も、こう考えるとすんなり繋がります。「移動」とは、パレットからトラックへ、あるいはトラックから倉庫へと、資源が場所や保有者を変えるたびに記録される、まさに操作レベルの中心にある事実そのものです。

このビール輸送の例を「知識レベル」と「操作レベル」に整理すると、次のようになります。

• 知識レベル（ルールや構造の定義）
  • 資源の種類（トラック、パレット、ケース、缶ビール、マルチパック）
  • 包含関係のルール（ケースには缶ビールが24本入る、等）
• 操作レベル（日々の事実の記録）
  • どのトラックに、どのパレットが載せられたか
  • A倉庫からB倉庫へ、どの資源が移動したか

新しい商品（マルチパック）が増えたときは、「知識レベル」にデータとして新しい資源の種類を定義するだけで済みます。「操作レベル」の「移動する」という処理ロジックやテーブル構造には1行も手を加える必要がありません。

6. 実務で実感した効果

この考え方を理解してからは、実務でも次のような効果を実感しました。

• 実装の統一化：資源という共通の抽象概念で扱うことで、似たような処理をパターンごとに個別実装する必要がなくなった
• 仕様変更への圧倒的な強さ：新しい種類の資源が追加されても、コード変更ではなくデータ追加で対応できる場面が非常に多かった

最初は「わかりにくい」としか思えなかった設計が、理解した瞬間から「圧倒的に強い」設計に見えてくる。この逆転体験こそが、アナリシスパターンの真骨頂だと思います。

まとめ

『アナリシスパターン』との付き合いは、2003年の挫折から数えると実に20年以上になります（理解に至ったのはその半分の10年後でした）。この経験から、私が得た教訓は次の一つです。

抽象度の高いパターンほど、最初は理解しにくい。しかし、理解できたときのリターンは計り知れない。

有識者のレクチャーを受けても分からなかったものが、要件定義書とデータモデルを自分の手で突き合わせる中で、ある日突然繋がる。これは、知識として「教わる」ことと、経験として「腹落ちする」ことの違いなのかもしれません。

もし今、抽象的な設計に「なぜこんな分かりづらい作りにするんだ」と感じている方がいたら、それは理解の途中段階にいるだけかもしれません。諦めずに、実際のデータや要件と向き合い続けてみることをお勧めします。