家づくりの失敗が教えてくれる、システム設計の“怖さ”
「なんでこの家、住んでみたら使いにくいんだろう？」
こんな話を聞くことがある。玄関が遠い、生活導線が破綻している、日当たりゼロ…せっかくの新築なのに、住んでから気づく。
そしてエンジニアなら、この瞬間うっすら気づくはずだ。
システムも全く同じである。
要件定義や設計を適当に済ませると、稼働後に「なんか使いにくい」「メンテが地獄」「追加機能が入らない」という“住めない家”が爆誕する。
しかし悲しいことに、システム開発ではその失敗をかなりの頻度で見る。むしろ建築より多いかもしれない。壁が透けて見えていても「まあ動くし」で引き渡すこともある。
この記事では、20～30代後半のエンジニアが必ず経験する「設計の後悔ポイント」を、家づくりの例からわかりやすく解説しつつ、どうすれば「住めるシステム」になるのかを掘り下げる。
読み終えるころには、あなた自身の設計が一段レベルアップし、明日の仕事から即改善できるようになるはずだ。
システムも“住む”ものだから、設計が命
結論を先に言うとこうなる。
「システムは住む場所と同じ。設計が悪いと、あとから苦しむのは100%未来の自分だ。」
動くコードを書くのは簡単だが、“長く使えるシステム”を作るには設計が全てである。
家で言えば、柱の位置、窓の向き、水回りの配置のようなもの。完成すると自由に動かせない。
あなたのプロジェクトで設計を軽視しているなら、それは「柱を適当に立てて家を建てよう」としているのと同じである。
それはもう、倒壊待ったなしだ。
壊れた家と壊れたシステムの共通点
1. 住んでみてから問題に気づく
家の設計でよくある失敗がこちらだ。
- 玄関からリビングまでが遠すぎる
- 窓の位置が悪くて昼なのに薄暗い
- コンセントが足りない
- 収納が妙に少ない
これ、システム開発では次のように変換される。
- 画面遷移が複雑でユーザーが迷子になる
- DB設計が悪くて検索が遅い
- ログがなくて障害調査が困難
- 設定項目の拡張性がゼロ
どちらも共通するのは、実際に使われたときに初めて発覚するという点だ。
そして、ユーザー（住人）は言う。
「え、なんでこうなってるの？」
いや、こっちが聞きたい。
2. 設計の“負債”は毎日じわじわ効く
例えば、風呂場への動線が悪い家を想像してみよう。生活するたびに「なんでこんなに遠いんだ…」とストレスが溜まる。
これが3年、10年と続く。設計ミスは一生付きまとう。
システムではこうだ。
- コードがスパゲティで修正のたびにバグが出る
- 設計書と実装の差異が放置される
- 拡張性を無視した作りで追加開発が泥沼化
- テストしづらい構造のせいで品質が安定しない
これもまた、開発者が毎日苦しむ。
仕様変更のたび、過去の自分が呪いをかけてくる。
技術的負債に利息はつかないが、不思議と“精神的利息”は年利30%ぐらいで増える。
3. リフォーム（リファクタリング）は高額になる
家づくりの世界ではこう言われる。
「建てるより直すほうが高い」
壁を壊し、配管を動かし、床を張り替え、電気を引き直して…
あっという間に100万円、200万円コースである。
システムのリファクタリングも同じだ。
- 依存関係が複雑で一部を直すと別の部分が壊れる
- バックエンド・フロント・DBが密結合で手が出せない
- 設計書がないので全容がわからない
- 結局“全面改修”が必要になる
本来1週間で済むはずだった改修が3ヶ月コースになる。
あのとき「まあ動くし」で許した自分を殴りに行きたくなる。
では、どう設計すれば「住めるシステム」になるのか？
1. 未来の住人（ユーザー）を想像する
まず最初に考えるべきは、次の問いだ。
「このシステムを使う人は、どんな毎日を送るだろう？」
これは家の設計で「家族構成・生活導線」を考えるのと同じ。
業務システムなら、入力の回数、一覧の確認頻度、誤操作しやすい箇所など、実務を具体的に想像する必要がある。
同じ画面でも、
- 一日に100回入力する人
- 月に1回しか触らない人
では適切なUIが違う。
ここを同一に扱うと“住みにくい家”になる。
2. 柱（アーキテクチャ）を最初に決める
家を建てる際、最初に決めるのは間取りではなく「構造」である。
木造なのか鉄骨なのか、耐震等級はいくつか、どこに柱を置くか。
ここがブレると、あとで「この部屋広げたい」ができなくなる。
システムも同じ。
最初に決めるべきは、
- アーキテクチャ（MVC、MVVM、Clean Architectureなど）
- 命名規則とディレクトリ構成
- 状態管理の方針
- APIとDBの責務分離
これらは後から変更しづらい柱のようなもの。
ここを曖昧にすると、すべてがグラグラになる。
3. コンセント（拡張ポイント）を多めに用意する
「コンセントもっと付けておけばよかった…」
これは家づくりのよくある後悔ランキング上位である。
システムでも同じ後悔がある。
- 設定項目を外出しにしていない
- カスタマイズを考慮していない
- ログ出力の粒度が固定
- 例外処理がベタ書きされている
後から「もう1つコンセント」「ログをもっと」などの要望が出たとき、柔軟に対応できる構造にしておくことが重要だ。
つまり、拡張の余地を最初から設計することである。
4. 汚れやすい場所（変更が多い場所）は交換可能にする
家で言うと、クロス（壁紙）やカーペットのようなもの。
ここが交換しづらい設計だと、生活の質に直結する。
システムで変更頻度が高い部分はここだ。
- UI
- バリデーション
- 外部API連携
- ビジネスロジックの計算式
これらを疎結合にしておけば、変更時に全体を壊さずに済む。
「よく変わる場所」と「めったに変わらない場所」を分けることは、設計における最重要ポイントである。
5. 設計図（ドキュメント）は“最低限でいいから作る”
家の施工で設計図がなかったらどうだろう？
柱の位置がズレたり、ドアの向きが逆になったり…もうホラーである。
しかしシステム開発では、しれっと「設計書？ ありません！」という現場を見かける。
いや、それは建築基準法に怒られるレベルだ。
最低限必要なのはこれぐらい。
- 画面遷移図
- API仕様書
- データモデル図（ER）
- コンポーネントの責務一覧
“ガチガチのドキュメント”はいらない。
ただし、未来の自分が5分で理解できるものは必須だ。
実例：設計をミスるとこうなる
ここでは、よくある“住めないシステム”の例を紹介する。
1. 変更1つで全画面が壊れるUI設計
共通コンポーネントが全く設計されておらず、ボタンやバリデーションが画面ごとにバラバラ。
ある日「エラーメッセージの色を変更して」と依頼が来ると、全画面を手作業で修正する羽目になる。
これは言うならば、家の照明スイッチが部屋ごとに全く違う位置にあるようなもの。
絶対に混乱する。
2. 1つのテーブルにすべてを詰め込んだDB設計
“全部入りテーブル”にありがちなこと。
- WHERE句が異様に長くなる
- インデックスが効かず検索が遅い
- 更新処理でロック競合する
家でいうなら「収納が1箇所しかなく、全部その中に詰める」状態である。
必要なものが奥に埋もれて取り出せない。
3. 設定がハードコーディングされている
本番環境にデプロイするたびにコードを書き換えるという、涙なしには語れない状態。
家で例えるなら、部屋の温度調整をするたびに壁を壊して配管をいじっている感じである。
まとめ：設計に時間を使う者だけが“住めるシステム”を作れる
本記事で伝えたいポイントは次の通りだ。
- システムは家と同じで、設計が悪いと住めない
- 問題は使い始めてから発覚する
- 負債は毎日ストレスとして積み重なる
- 後から直すほうが何倍も大変
- 未来に備えた設計が最大のコスパを生む
そして何より、
「設計に時間をかけることは、未来の自分を救う行為である。」
もし今日、あなたのプロジェクトで設計に不安を感じているなら、一度立ち止まり、
「この家、本当に住めるのか？」
と自問するところから始めてほしい。
明日からできるアクションは次の通りだ。
- コンポーネント・責務の洗い出しを行う
- よく変わる部分と変わらない部分を分けて整理する
- 画面遷移図・ER図など最低限の設計書を作る
- 依存関係を見直し、疎結合にする
あなたが作るシステムが、クライアントやユーザーにとって「住みやすい家」になりますように。
そして、未来のあなた自身が苦しまないように。
今日から“設計の質”を一段高めていこう。
