完璧さはオーバーエンジニアリングではない

完璧さはオーバーエンジニアリングではない 2026-07-19 「完璧なものは作りたくない」「完璧なソリューションは作りたくない」 「完璧」が汚い言葉であるかのように語られるのを、数えきれないほど耳にしてきた。その注意喚起は理解できる――オーバーエンジニアリングはチームを燃え尽きさせるし、人々は完璧さを匂わせるものすべてを同じリスクとして扱うように学んできた。しかし、それは違う。業界は静かにこの二つを混同してきた。 オーバーエンジニアリングとは、間違った問題を解決することだ。それが定義のすべてだ。「気にしすぎ」でもない。「良すぎること」でもない。間違った問題を解決することだ。しばしば善意から、そしてほぼ常に、増え続ける付随的な複雑さとともに。 完璧なソリューションは存在する 私は、完璧なソリューションが存在すると信じている。ただし、大きな注意点がある：非常に明確な要件セットが必要だということだ。テーブル上のすべての制約。それらを十分に絞り込めば、興味深いことが起こる。ただ一つの可能なソリューションしかなくなるのだ。そしてそのソリューションは、やや皮肉なことに、完璧なものとなる。それは、それが唯一適合するものだから完璧なのだ。 新しいプロジェクトを始めよう。利用可能なすべての言語、すべてのツール、すべてのホスティングモデル。あなたはサーバーレスを選ぶ。Pythonは強力な選択肢だ：コンパイルステップなし、ファイルをLambdaにアップロードして出荷。他の誰かにとっては、それは間違った選択肢だ。彼らはPythonを知らないか、パフォーマンスのような異なる要件セットを最適化する必要がある。異なる制約、異なる答え。同じ問題空間、異なる「完璧」。 あるいは、Pythonを選んでWebアプリを構築しているとする。DjangoかFlaskか？どちらでも似たような結果に到達できる。それらは依然として、完全に異なる哲学を持つ異なるツールだ。どちらが勝つか？それは状況による。より明確な要件を設定し、より厳しい制約を設定すれば、ソリューションが続く。そのソリューションは、あなたにとって、そのケースにとっての完璧なものだ。 システムは製品である システムがオーバーエンジニアリングされるとき、その原因はほぼ常に要件にある。そして私は、単なる技術的な要件ではなく、製品としての要件を意味している。ライブラリ、API、内部ツール…これらは「純粋に技術的」であり、製品という考え方の外にあると私たちは偽りがちだ。そうではない。あなたはユーザーがいる。そのユーザーにはニーズがある。あなたはそれらのニーズを適切に対処できるほどよく理解する必要がある。彼らが必要としているのはサービスかもしれない。あるいは、HTTP呼び出しよりもライブラリでより良く提供されるものかもしれない。APIを手渡す代わりに、パッケージを手渡すのかもしれない。ソリューションの形状は、システムを製品として扱い、正直に要件を定義したときにのみ明らかになる。そうすれば、ソリューションが続く。 どうすればわかるか 何かがオーバーエンジニアリングされている最も明確な兆候：なぜ物事がそのように構築されているのかを尋ね始め、「その答えが成り立たない」ときだ。古典的な例。3人のチームが5つのマイクロサービスを保守している。サービスは互いにデータを共有している。それはオーバーエンジニアリングか？彼らが解決しようとしていた問題を突き止める。ほとんどの場合、彼らは間違った問題（またはそれらのうちのいくつかを同時に）を解決していたと結論づけるだろう。 その分割が実際に何をもたらすかを見てみよう。かつてデータベースのハードリファレンス、エンジンがあなたのために強制する外部キーだったものが、今ではフィールドにある緩い文字列IDになっている。データの整合性は失われた。1つのサービスがレコードを削除しても、もう一方のサービスは何も知らず、ぶら下がった参照を保持し、後で、困難な方法でそれを知ることになる。なぜ、すべてが同じドメインの一部であるのに、サービス間にこれほどの儀式が必要なのか？なぜ、それらの整合性チェックを放棄するのか？その交換に何を得たのか？通常：失ったものほど多くない。独立したデプロイ、確かに。しかし、それは実際にあなたが抱えていた問題だったか？3人、1つのドメイン。あなたはテーブルにないスケーリングと所有権の問題を解決し、分散された不整合、運用のオーバーヘッド、そして複数の問題を部分的にしか解決せず、どれも完全に解決せず、それ以外では持たなかったであろう多くの問題をもたらしたことに対して支払ったのだ。それがその特徴だ。エレガンスではない。徹底性ではない。そして、これらのソリューションが悪いということではない。通常、それらは提案された問題に対する正しい答えだ。問題は、それらがあなたが決して抱えなかった問題だったということだ。 正しい要件を集める だから、診断はシンプルだ。たとえ作業がそうでないとしても。オーバーエンジニアリングは、要件収集の失敗だ。それをプロダクトエンジニアリングと呼んでもいい。それは、間違った要件を収集し、それらに対して熱心にエンジニアリングすることの結果だ。完璧さが敵だったことは一度もない。曖昧な要件がそうだった。それらを正しく取得し、すべての制約をテーブルに載せれば、完璧なソリューションはファンタジーではなくなる。それは、残された唯一のものになる。 この議論のビデオ版を作成しました。もし見たいのであれば：完璧さはオーバーエンジニアリングではない。読んでくれてありがとう。