なんとなくそう思ってたけど、「過剰設計（オーバーエンジニアリング）」って意外とよくある話なんだよね💭
例えば、簡単に済みそうな仕事やプロジェクトが、むちゃくちゃ複雑になっちゃった経験、ない？わたしはちょっとしたアプリとか作るときに、「もっといいものにしたい！」って思うあまり、気づいたら意味わかんないほど機能増やしてたりして…😳✨
でも、それってただの「欲張り」だけじゃなかったみたい。この記事を読んでみて、ああなるほど、いくつか理由があるんだなって納得したよ🧠
過剰設計が起こる３つの理由
1. 不安からくるあれこれ追加しちゃう魔法
やっぱり「失敗したくない！」って気持ちが強いと、必要以上に安全策を用意しちゃうことが多いんだって。
「あれもできるようにしよう、これも壊れないようにしよう」って、つい完璧主義になっちゃう感じかな💡
で、結果的に複雑で重たくなってしまう…🤔
2. 自分のスキルや知識を証明したい
これはわりと人間らしいところかも。
「自分ってこんなにすごいんだぞ！」って、ついつい機能や技術的な工夫を詰め込みがち🧙♀️✨
でもそれが周りにとっては余計なものだったりして、使いにくくなることもあるらしいよ🥺
3. 要求や目的がはっきりしてない
これが一番多いと思うんだけど、「本当に必要なこと」が分かってないまま作り始めちゃうと、あれもこれも欲しくなってしまうんだって。
たとえば「便利にしたい」ってだけで具体的なゴールがないと、どんどん広がっちゃうよね📌
どんなときに気をつけたらいい？
- 最初に「これだけは絶対必要！」をはっきりさせること
- 自分の気持ち（不安とか自己アピール欲）に気づくこと
- 一旦シンプルに作ってみて、後から改善する余裕を持つこと
これだけで、かなり過剰設計は防げるみたい😆👍
なんか、過剰設計って悪いことばかりじゃなくて、「もっといいものを作りたい」という純粋な気持ちの裏返しでもあるんだな〜って思ったよ🌸
でもやっぱり、ほどほどが一番使いやすいしラクに続けられるんだろうな〜って感じ✨
ちょっと気楽に考えながらモノづくりできたらいいよね💭
はてな
コメント
エイダン
必見の名作、伝説の[Krazamのマイクロサービス解説](https://www.youtube.com/watch?v=y8OnoxKotPQ)。
ハンナ
この記事は「過剰設計はマイクロサービスのせい、シンプルさはモノリシックのせい」って言ってるけど、それは違うよね。
レオ
「履歴書重視の開発」って言葉いいね！ 使わせてもらうよ。 でも本気で言うと、チームに非重要プロジェクトで経験積ませるのは士気アップにもなるし、複雑にして学ぶのも悪くないよね。
グレース
「履歴書映えで設計決める」って言うけど、実際そんな問題大きくないし、普通の開発者はそこまで意識してないよ。 むしろシンプルなコードを書くのは難しいし、業界は理解より速さ重視なんだよね。
クリス
履歴書や流行りに影響されるのは言語やフレームワークくらいで、設計の過剰さとは違うと思う。 多くは要求が曖昧だから「最悪を想定」して全部汎用的にしようとしてるだけで、それは後から変えにくいから今やるしかないんだよね。
レオ
俺にとっては単純に楽しいからだね。 新しいこと覚えて、複雑なものを書ける腕を試せるし。
ロバート
俺が見た過剰設計の多くは「YAGNI」の違反だよ。 例えばプロトタイプで「将来ライセンス機能いるかも」って思って暗号化DLLとか作り込んで、結局そんなの使わなかったケースとかね。 それ外してデプロイがめっちゃ楽になった時、マネージャーも驚いてたよ。
エイダン
あと開発者の退屈からくるのもあるよね。 古い言語でCRUDばっか書いてると、システム設計したくて言語のマニアックな機能試したくなるっていう。
グレース
過剰設計も手抜き設計も根本は「完成の定義」をちゃんと決めてないから起こるんだよね。
リリー
なぜかって？ 新入社員はバランスよく現実的に考える方法を教わってないし、 多くの有名な指南書も現実の制約やトレードオフを知らない人が書いてるから。
リリー
過剰設計は長年の手抜き設計のツケで、 昔はちゃんと動かせなかったからGoogleの設計を真似したけど、 それで逆に悪化しちゃったんだよね。
ジョージ
パフォーマンス評価に書くことが必要だったんだろうね。
レオ
だって楽しいからね。 :)
