「完璧主義」と「オーバーエンジニアリング」は別物だ：シンプルに設計する極意

完璧を追求することと、必要以上に複雑なものを作り上げる（オーバーエンジニアリング）ことは決して同義ではありません。優れたエンジニアリングとは、無駄を削ぎ落とし、目的に対して最も直感的で効率的なソリューションを選択することから始まります。

「オーバーエンジニアリングとは間違った問題を解くことだ」なんて言い方はしたくないな。考え方自体は合っているかもしれないけれど、実際には存在しない制約や、状況がはっきりしてくれば対処できるはずの課題に対して無理に最適化しようと労力を割いてしまっている場合がある。それが神話的なPMF（プロダクトマーケットフィット）であれ、単に「ユーザーが何を求めているのか理解できたから、それを構築しよう」という段階であれね。

今まで経験した中で最悪の泥沼プロジェクトは、本来の課題はそれなりにうまく解決できているWebアプリだったのに、チームがそのプラットフォーム全体よりもMAUが少ない趣味サイト程度の規模しかないのに、ピタゴラスイッチのような馬鹿げたマイクロサービス構成に時間を費やしていたことだ。間違った問題を解いていたわけじゃない。でも、明らかにオーバーエンジニアリングだったよ！

「完璧を善の敵にするな」という言説に抗うことには大賛成だ。たいていかなり質が悪くて、時に少し悪意すら混じっているようなソフトウェアを正当化するために、この言葉が四六時中使われているからね。自分の仕事に誇りを持とうと必死にがんばっている気の毒なやつらを除けば、そこには何の良いものもない。

ただ、システムを「プロダクト」と見なす考え方には同意しにくい。プロダクト的な思考は有害だよ。ユーザーのゴールとは無関係な目標（典型的には金儲け。時には株主のためにユーザーをひどい目にあわせることも含む）を持つことになるからね。

最高なソフトウェアのほとんどは「プロダクト」ではなく「ツール」のカテゴリーに入るものだ。通常、ユーザー自身が作り、ユーザーが抱える問題を解決することだけを考え、裏に隠れた動機なんて持っていない。

「完璧とは、加えるべきものが何もない時ではなく、取り除くべきものが何もない時に達成される」

• アントワーヌ・ド・サン＝テグジュペリ

「完璧なソリューションを作ろうとしているわけじゃない」という言葉は、オーバーエンジニアリングをなだめたり、ずさんな仕事を推奨したりするために言うものじゃない。

これは、本番環境でめったに起きないようなニッチなエッジケースを指摘して、「提案されたソリューションでは動かない」と主張する特定のタイプのエンジニアによる苦情を先回りして封じるための言葉だ。

「完璧なソリューションを作ろうとしているわけじゃない」というのは、「すべてを網羅できるわけではないことは理解している。要件は90パーセンタイルのユースケースに設定しているんだ」と言っているに等しい。

「ただし、一つ大きな注意点がある。非常に明確な要件セットが必要だ」

新製品リリースのほとんどは、試行錯誤（実際にはユーザーとの対話の継続）を通じて、「製品の要件はどうあるべきか」を探るプロセスそのものだ。成熟した製品でさえ、市場の変化とともに要件が変わることはある。

この現実を自分事として落とし込めているシニアエンジニアほど、混沌とした現実の世界に触れるような領域で完璧主義を反射的に拒絶するのは、まさにこのためだと思う。

同感だ。今まで関わった中で最も悲惨でオーバーエンジニアリングな泥沼プロジェクトのほとんどは、要件を理解できていなかったことが原因だった。

もちろん、始める前にすべての要件を完璧に把握できるとは限らない。実際、私自身も一度モノを作って現実世界に触れさせてみるまでは、本当に要件を理解できていないことがよくある。

だから、たいていは最初のバージョンを捨てて、2番目を作る。すると、2番目は「即座にゴミ箱に投げ捨てたい」とは思わない程度の出来になることが多い。

そして3番目を作る頃には（通常、2番目ができてからしばらく経ってからだが）、かなり良いものになっている。

なぜなら、スタート時点よりも課題や要件をはるかに深く理解できているし、その課題を解決するためにシステムがどうあるべきかも見えているからだ。

完璧になるかって？絶対に無理。静止して不変な宇宙でもない限りね。でも、ある一時点において最適性に近づくことはできる。機能的には、それこそが完璧と同じことだよ。

「複雑すぎる（Over-complicated）」ことと「オーバーエンジニアリング（Over-engineered）」は別物だと思う。

複雑すぎるというのは、機能を詰め込みすぎたり、仕組みや可動部分を増やしすぎたりすること。オーバーエンジニアリングというのは、役に立たないほど要件を大幅に超えてしまうことだ。例えば「ツリーハウスを作ってくれ」と言われたとする。本来なら木材で作れば十分だよね。それをコンクリートと鉄で作れば、もっと頑丈で長持ちするかもしれないけれど、複雑さは増さない（コストは増えるが）。これが「強すぎる」、つまりオーバーエンジニアリング。もしツリーハウスに13部屋、エレベーター、ガラス窓、太陽光発電、水道まで付けたら、それは「複雑すぎる」ことになる。

素晴らしい書き込みだ！完璧を破壊しようとするのではなく、完璧を目指して努力する世界に住みたいね。

私は「完璧」という言葉は汚い言葉だと思う。人の心に有害な影響を与えるからね。

完璧を追い求めると、オーバーエンジニアリングを招くことも多いけど、それ以上に重要なのは、完璧であらねばならないというプレッシャーのせいで細かい議論（バイクシェディング）が多発したり、完璧にならなかった時に感情的な引きずりを感じたりすることだ。

投稿者でさえ、完璧の定義は厳格な要件があって初めて成立すると認めている。さらに一歩進めると、その時は完璧でも、現実は絶えず変化する。アーキテクトとしては、目先の問題だけでなく将来の問題も考えなければならない。そう考えると、特定の状況で完璧なものを作るより、多くのシナリオでうまくいくものを持っている方がずっといい。

より明確な要件、より厳しい制約を設定すれば、ソリューションは自ずとついてくる。そのソリューションこそが、あなたにとって、そのケースにとっての完璧なものだ。

これは「完璧を求めること」に対する少し美化しすぎた解釈じゃないかな。一般的に、完璧を求める姿勢というのは、軸足を残したり将来の決定や試行錯誤の余地を残した大まかな青写真を描くのではなく、細部にこだわりすぎて事前計画に固執することと表現するのが妥当だと思う。思考能力は高いのに、柔軟に動くのではなく「どうすれば一番うまくいくか」を事前シミュレーションすることに泥沼のようにハマってしまうエンジニアは多いよ。