【凡人の苦悩】大規模システムって、正直複雑すぎる
最近、
「大規模システムって、そりゃ簡単に変えられないよな……」
と強く実感する場面がありました。
一般論として
「なぜ大規模システムはここまで複雑になるのか」
「その中でエンジニアとして何をキャッチアップすべきか」
を整理してみます。
大規模システム＝機能が多い、だけではない
よくある誤解として、
大規模システム = 画面や機能が多い
と思われがちですが、
本当の難しさはそこではありません。
大規模システムが難しい理由は、
責務が多い
関係者が多い
歴史が長い
この3点が絡み合っていることです。
1つの変更が、連鎖的に影響する世界
小さなアプリなら、
ボタンを変える
APIを1本直す
これで済むことも多いです。
でも大規模システムでは、
通信
認証
課金・決済
ログ
障害検知
他システム連携
などが密結合しています。
その結果、
「ここを直すと、どこが壊れるか分からない」
という状態が生まれます。
なぜリリースまで何年もかかるのか
外から見ると、
「そんなに時間かかる？」
「もっと早くできないの？」
と思われがちですが、
中身を見ると話は変わります。
理由はシンプルで、
既存ユーザーを止められない
既存データを壊せない
既存システムと並行稼働が必要
だからです。
止められない前提で作り替える
これが一番難しい。
「作る」より「壊さない」が最優先になる
大規模システムでは、
新機能を作ること
便利にすること
よりも、
今動いているものを壊さないこと
が圧倒的に優先されます。
そのために、
影響範囲調査
設計レビュー
段階リリース
切り戻し設計
こういった作業が膨大になります。
コードを書く時間より、
考える時間・確認する時間の方が長いことも珍しくありません。
ここでSSOTの話につながる
以前書いたSSOT（Single Source of Truth）の話は、
まさにこの文脈で効いてきます。
大規模システムでは、
仕様書
設計書
実装
運用ルール
このどれかがズレるだけで、
一気に混乱が広がります。
だからこそ、
「どれが正なのか」
を決め続ける必要がある。
SSOTは、
大規模システムを人間が扱えるサイズに保つための知恵
とも言えます。
凡人エンジニアがキャッチアップすべき視点
正直、最初は圧倒されます。
でも、全部を理解しようとしなくていい。
大事なのは、
どこが責務の境界か
どこが変更に弱いか
どこが「触ると危険」か
こうした 構造を見る目 を養うこと。
コード量よりも、
設計思想・分離の仕方 を追う方が学びが大きいです。
複雑さは「悪」ではない
大規模システムが複雑なのは、
無能だからでも、古いからでもありません。
多くの人が
長い時間
真剣に使ってきた
その結果として、
どうしても複雑になる。
だからこそ、
シンプルにする努力
分かりやすくする設計
情報を一元化する思想
これらが、
現場で一番価値を持つのだと思っています。
