見えない複雑さを甘く見ると、システムも組織も壊れる

Jul 04, 2026

1 min read

0 views

72%

「これで十分」は、たいてい一番危ない

ある日突然、名前が変わる。会社が分割される。別の法人が登場する。関係者の顔ぶれは増え続けるのに、全体像はますます見えなくなる。外から見れば一つの案件でも、中に入ると実体は分散し、責任は拡散し、誰が何を持っているのか分からなくなる。

この現象は、いわゆる企業犯罪や詐欺の世界だけに限らない。ソフトウェアの世界でも、似たことが起きる。最初は「シンプルで速そう」に見える設計が、あとから整合性を失い、変更に弱くなり、誰も全貌を把握できない構造へと変わっていく。複雑さを消したつもりが、ただ見えなくしただけ、ということがある。

そして厄介なのは、見えなくなった複雑さは、だいたい最後に請求書を持ってくることだ。

複雑さは消えるのではない。管理されるか、隠蔽されるかのどちらかだ。

データベース選びは、技術選定ではなく「複雑さの所在」を決める行為

NoSQLを使うべきか、RDBMSを使うべきか。この問いはしばしば「どちらが新しいか」「どちらが速いか」「どちらがトレンドか」で雑に語られる。しかし本当に問うべきなのは、複雑さをどこに置くのかだ。

RDBMSは、整合性、結合、正規化、マイグレーションといった複雑さを、データベースの側に引き受けさせる。これは面倒に見えるが、実はかなり重要な設計思想だ。複数のテーブルにまたがる関係を明示し、制約を張り、クエリで意図を表現できる。つまり、複雑さを「見える形」に固定する。

一方、NoSQLやオブジェクトストレージは、うまく使えば強力だが、クエリの自由度や整合性の保証を自動では与えてくれない。そこで必要になるのは、アプリケーション側で複雑さを抱え込む能力だ。非正規化したデータの更新漏れ、マイグレーション時の変換、関連情報の同時更新、検索要件の増加。これらをコードでさばくなら、相応の設計力と運用力が要る。

ここでよくある失敗は、**「必要ないものを削った」のではなく、「あとで必要になる複雑さの置き場所を決めずに外へ押し出した」**だけなのに、あたかも洗練されたように見えてしまうことだ。これは、整理整頓ではなく、押し入れに突っ込むのに近い。部屋は広く見えるが、探し物は永遠に見つからない。

「本当に必要か？」が雑に使われると、議論は浅くなる

「本当にそれ必要なの？」という問いは、たしかに便利だ。無駄を削るのに役立つし、過剰設計を防ぐこともある。だがこの問いは、使い方を間違えると一気に価値が落ちる。なぜなら、必要性の議論は、前提と仮説があって初めて意味を持つからだ。

たとえば「本当にSQLが必要か？」と問う前に、次のことを詰める必要がある。

データの関係は一対一か、一対多か、多対多か
更新整合性はどのレベルまで必要か
将来の検索条件は増えるのか
監査や履歴、ロールバックは必要か
マイグレーション頻度はどれくらいか

これらを無視して「不要では？」とだけ言うのは、議論というより空気の支配に近い。しかも、そういう発言はしばしば「本質を突いている感」をまとっているので厄介だ。実際には、本質を突いているのではなく、本質を考えるための材料を捨てているだけかもしれない。

この構図は、企業や組織の不透明化とも似ている。名前を変え、会社を分け、関係を複雑にすると、外から「本当に何が起きているのか」を問われても答えにくくなる。問いを封じる方法は、必ずしも反論することだけではない。答えに必要な前提を散らばらせることでも、十分に問いを無力化できる。

複雑さは、議論の質も、責任の所在も、両方を曖昧にする。

Web開発でRDBMSを理解することは、単なる知識ではなく「現実把握力」

Webアプリケーション開発において、RDBMSの理解が圧倒的に重要なのは、RDBMSが古いからでも、伝統的だからでもない。現実の多くの業務システムが、関係性と整合性を中心に成り立っているからだ。

在庫、注文、ユーザー、権限、請求、配送、ログ、契約。これらは単なる「データの箱」ではない。互いに関係し、条件付きで更新され、過去との整合性が求められ、時には監査可能でなければならない。ここでSQLを読めない、実行計画を見られない、正規化と非正規化の意味が曖昧、となると、システムの根っこを見誤る。

たとえば検索が遅いとき、フロントエンドの描画やアプリコードの最適化に飛びつく前に、まずクエリとインデックスを疑うべきだ。これは単なる効率論ではない。ボトルネックがどこにあるかを判別できないと、どれだけ頑張っても問題の本体に触れられないからだ。

実行計画を読めない状態は、地図を見ずに渋滞の原因を探すようなものだ。道路工事なのか、信号制御なのか、そもそも別ルートを走るべきなのか。見えていないまま感覚で車線変更を繰り返せば、遅くなるだけでなく、事故も増える。

ここで重要なのは、RDBMSを使えと言っているのではなく、関係性を扱う発想を身につけろということだ。たとえ最終的に別のストレージを選んでも、SQL的な思考、つまり「制約を明示し、関係をたどり、更新の波及を見積もる」感覚がなければ、設計は薄くなる。

真に危険なのは、壊れていることではなく、壊れ方が見えないこと

不正な組織や危ういプロジェクトが怖いのは、単に悪意があるからではない。全体像が見えなくなるように構造化されているからだ。関係者が増え、役割が分かれ、法人がまたぎ、名前が変わると、責任の追跡が難しくなる。その結果、何が起きているかを説明できる人がいなくなる。

ソフトウェアも同じだ。非正規化が進みすぎたデータ、ドキュメントにない暗黙のルール、誰も触れられないクエリ、実行計画を見ないまま積み上がった最適化の失敗。これらはすべて、システムの状態を説明不能にする。

ここに共通するのは、「見えないものは管理できない」という原則だ。管理できないものは、いずれ事故る。事故ったとき、当事者はたいてい「そんなつもりではなかった」と言う。しかし問題は意図ではなく、構造にある。

だから本当に大事なのは、最新技術を追うことでも、複雑さを根性で吸収することでもない。複雑さを増やすなら、それがどこに現れ、どう観測され、誰が責任を持つのかまで設計することだ。これがないと、便利そうに見える選択肢ほど危ない。

Key Takeaways

「簡単そう」は危険信号になりうる。 何かを削った結果、見えない場所に複雑さを押し込んでいないか確認する。
技術選定は複雑さの配置決め。 RDBMSかNoSQLかではなく、整合性、検索、更新、監査の責任をどこに持たせるかで考える。
「本当に必要か？」には前提が要る。 必要性を議論する前に、データ関係、更新頻度、将来要件を明文化する。
実行計画を見られないなら、最適化の議論を始めない。 ボトルネックの観測なしに改善しても、的外れになりやすい。
説明できない複雑さは、将来の障害になる。 人が理解できる形で構造化されていないものは、運用のどこかで必ず破綻する。

では、何を基準に設計すべきか

一つの実践的な基準は、**「後から説明できるか」**だ。今の選択が、半年後の自分や別チームに説明可能か。なぜこのデータは正規化されているのか。なぜこの一部だけ非正規化しているのか。なぜこの更新はアプリ側でなくDB制約に委ねたのか。説明できるなら、少なくとも構造は生きている。

もう一つの基準は、**「失敗がどこに現れるか」**だ。RDBMSなら制約違反として早めに失敗しやすい。NoSQLでは、失敗が遅れてアプリの整合性崩壊として現れることがある。どちらが優れているかではなく、どちらの失敗様式を受け入れるのかを理解することが重要だ。

そして最後に、**「最適化の前に観測できるか」**を問うべきだ。見えないものは改善できない。実行計画、クエリ時間、更新経路、データの依存関係。これらが見えれば、議論は感想戦ではなく、現実に基づく作業になる。

結局のところ、システム設計も組織設計も同じ問いに行き着く。複雑さを消したいのか、それとも扱える形にしたいのか。 前者はたいてい幻想で、後者だけが本当の設計だ。

見た目がシンプルなものほど、裏で誰かが必死に複雑さを肩代わりしている。そこを見抜けるかどうかで、技術者としての成熟度は大きく変わる。沈黙して動いている仕組みは美しいが、説明不能な沈黙はいつか破綻する。だからこそ、私たちが鍛えるべきなのは、流行の技術を追う腕前ではない。複雑さを隠すのではなく、見える形で引き受ける力なのだ。