“正しい設計”が、現場では不正解になることがある

エンジニアとして仕事をしていると、正しい設計というものを知り始める。

• 責務は分ける。

• 依存は整理する。

• デザインパターンに沿わせる。

• 将来の拡張に備える。

もちろん、どれも大事だ。

私もその手の設計論を軽んじる気はない。
むしろ知らないまま実装するのは普通に危ないと思っている。

ただし、ここに落とし穴がある。

エンジニアが考える“理論上正しい設計”が、
そのまま実務上の正しい設計になるとは限らない。

正しい設計を、わざと崩す

以前、とあるシステムでインフラ構成を考えていたときのことだ。

理想だけで言えば、役割ごとにサーバーを分けたほうがよかった。

あるいはサーバーレスに寄せる。
少なくとも、もう少し構成を分離したほうが、保守性は上がる。
将来の変更にも強くなる。
運用面でも見通しは良くなる。

設計として考えるなら、そちらのほうが“正しい”。

だが、実際にはそうしなかった。

一つのサーバーに、かなり無理やり全部を押し込んだ。

理由は単純で、インフラ費用を守る必要があったからである。

きれいに分ければ分けるほど月額費用は上がる。
顧客が許容できる金額を超える。

それならどうするか。

設計を歪めるしかない。

もちろん、気持ちは悪い

この判断に、設計者として何も思わなかったわけではない。

「サーバーレスにできれば、もっと素直なのに」
「せめてインスタンスを分ければ、後から楽なのに」
「保守費用まで含めるなら、今の構成は本当に得なのか」

そういうことはもちろん考えた。

そして実際、後から保守する人は困ったと思う。

汎用的な知識だけでは追えないこのプロジェクト独自のサーバー構成を、
一度頭に入れ直さなければならない。

ぶっちゃけ後任者にはこう思われただろう。

なんだこのクソ設計は。

分かる。
私でも背景を知らずに入ったら、そう思う。

でも、その“クソ設計”は誰の都合で生まれたのか

ここで厄介なのは、
その設計が単純に技術者の怠慢で生まれたわけではないことだ。

• 予算がある。

• 顧客の希望がある。

• 運用の引き継ぎ先が自社とは限らない。

• 保守を別会社に任せる前提で、妙な制約が乗ってくることもある。

エンジニアとしては納得しにくい。

それでも、
第三者がいるビジネスでは、納得していなくても飲み込むしかない判断がある。

ここを飛ばして
「本来はこう設計すべきだった」
と語るのは簡単だ。

簡単だが、だいぶ無責任でもある。

案件は技術の展示会ではない。
顧客のお金で作るものだ。
こちらが美しいと思う構造が必ずしも売れるわけではない。

“正しい設計”という言葉は、条件を隠すと乱暴になる

設計論でよくあるのが、

• それは分離すべき

• その責務の持たせ方はおかしい

• 将来を考えるならこの形しかない

• その構成は保守性が低い

という話である。

言っていること自体は、だいたい正しい。

ただし、それはしばしば
制約がない世界の話になっている。

あるいは、
顧客都合が存在しない世界の話になっている。

理論上は正しい。
それでも現場では、その理論をそのまま通せない。

だからこそ、
設計を評価するときには「これは美しいか」だけでなく、

• なぜこうなったのか

• 何を守るために何を捨てたのか

• 誰の要望が強く効いているのか

• どこまでが技術判断で、どこからが事業判断なのか

まで見ないといけない。

背景を知らずに設計だけ見て文句を言う輩は
プロ野球の監督の采配に文句を言う居酒屋のおっさんのようなものだ。

現場で問われるのは、正解を唱える力ではない

上流工程に関わり始めた頃は、
どうしても“正しい設計”に惹かれやすい。

特に現場だけでなく座学として勉強をしている優秀なエンジニアほどそうなる。

知識が増えると、目の前のプロダクトの設計の粗も見える。
現場で動いているものに対して、
「もっときれいにできるのに」と思う機会も増える。

ただ、その段階で一度立ち止まったほうがいい。

その設計は、
本当に誰も考えずにそうなったのか。

それとも、誰かが考えた結果として、
あえてその形に落ちているのか。

現場では、正しいことを知っている人より、
正しさをどこまで曲げるか判断できる人のほうが強い。

予算を無視しない。
顧客を無視しない。
運用者を無視しない。
そのうえで、技術的な破綻をできるだけ抑える。

面倒だが、これが実務でいう設計である。

“なんだこの設計は”と思ったときに

新しいプロジェクトに入ると、
理解しづらい設計に出会うことがある。

そのとき、すぐに切り捨てるのは気持ちいい。

「責務が混ざっている」
「構成が汚い」
「なんでこうしたんだ」

そう言いたくなることもある。

実際、本当に雑なだけの設計もある。
そこは否定しない。

ただ、もしその背景に

• 価格を抑える必要があった

• 顧客の運用条件があった

• 他社保守前提の都合があった

• 当時の契約やスケジュールの制約があった

という事情を前提とするなら見え方は変わる。

その設計は、
技術的には不格好でも、案件としては生き残るための形だったのかもしれない。

きれいな設計を語る前に、汚れる理由を見たい

私は、正しい設計そのものを否定したいわけではない。

むしろ知識として持っておくべきだと思う。
デザインパターンも、責務分離も、アーキテクチャの定石も、
知らなければ話にならない。

でも、現場ではそこから先がある。

その正しさを、
どの制約の中で、
どこまで守れて、
どこを諦めるのか。

設計は、教科書の模範解答を出す競技ではない。
予算も、顧客も、将来の保守もまとめて抱えたうえで、
一番マシな着地点を探す仕事である。

きれいな理屈は大事だ。
ただし、
現場で本当に必要なのは、何とかして目標を達成することだと思う。