システム開発の現場で、こんな経験はありませんか？
- 「とりあえずユーザー要望をそのまま実装したら、コードがどんどん複雑に…」
- 「気づけば if 文だらけで誰も触れないコードになっていた」
- 「案件ごとにテーブルを追加していたら、DB がカオスになった」
一見するとユーザー要望に応えているようで、実際には「その場しのぎの設計」を積み上げているだけ。
これは短期的には動いても、長期的には負債になってしまいます。
悪い例：要望直列型の実装
例えばこんなケース。
営業からの依頼：
- A社向けに処理を追加してほしい
- B社向けは別ルールで計算してほしい
- C社は特殊だから例外処理を
素直に実装すると…
if (customer == "A") {
...
} else if (customer == "B") {
...
} else if (customer == "C") {
...
}
最初は動きますが、半年後には if 文がさらに10個増えているかもしれません。
DB も案件ごとにカスタムカラムや専用テーブルが乱立し、誰も触りたくない状態に。
これが 要望直列型の実装 です。
図解イメージ（悪い例）
- if/else が肥大化
- 専用処理・専用テーブルが乱立
- 変更時の影響範囲が不明確
良い例：アーキテクチャカタログに落とし込む
優れたエンジニアは、ユーザー要望をそのまま実装するのではなく、
自分の頭の中にある「アーキテクチャカタログ」から最適な要素を選び、汎用的な設計に落とし込みます。
例えば…
- ルールエンジン：顧客ごとの条件を if 文ではなく設定で切り替え可能にする
- ETL パイプライン：複雑なデータ処理を流れとして整理する
- オブジェクト指向設計：責務を分離し、再利用可能にする
- DB 正規化／スキーマ設計パターン：スケールしやすく破綻しないデータ構造を作る
- マイクロサービス：サービス境界を明確にし、ドメインごとに責務を分割する
これらは単なる「知識」ではなく、必要に応じて取り出せる カタログのような存在。
ユーザー要望は、このカタログに照らして整理することで、汎用的で長く生きるシステム設計 に変換できます。
図解イメージ（良い例）
- 要件をカタログの部品へマッピング
- 再利用性・拡張しやすさを確保
- 長期的なスケールと保守性を担保
アーキテクチャカタログとは？
「アーキテクチャカタログ」とは、エンジニアが頭の中に持っている設計パターンや構造の引き出しのことです。
- カタログ ＝ 知識を一覧化したもの
- アーキテクチャ ＝ システムを支える設計の枠組み
つまり、特定のユーザー要望に直結した一回限りの設計ではなく、
多様な要件に対応できる 再利用可能な設計のコレクション を指します。
まとめ
- ユーザー要望をそのまま直列につなげた実装は、必ず負債になる
- エンジニアに必要なのは「アーキテクチャカタログ」を頭の中に持つこと
- そのカタログを使って要件を汎用的な設計に落とし込むことで、長期的に使える美しいシステムが作れる
あなたは、どれだけの アーキテクチャカタログ を持っていますか？
そして、そのカタログをどれだけ 日々の開発に活かせて いますか？