オーバーエンジニアリングが悪い理由と対策
オーバーエンジニアリングとは、プロダクトの設計や開発において、必要以上に複雑にしたり、現時点では不要な機能をあらかじめ組み込んだりすることを指します。
オーバーエンジニアリングが良くない理由は想像できますが、一方で、将来的なことも考慮に入れて設計や開発をすることも大事ではあります。どこまでが必要な考慮で、どこからがオーバーエンジニアリングなのか、それを未定められるようになるのが大事だと思ったので、調べたことを整理してみました。
なぜ悪いのか
オーバーエンジニアリングが悪い理由は、大きく次の3つのようでした。
- 開発期間やコスト、人的リソースの無駄遣いになる
- 保守やデバッグが困難になる
- 予期しないバグや問題が発生する可能性が高くなる
高い性能はそれ自体は問題でなくても、開発コストの増大によってイテレーションのスパンが延び、プロダクトが市場に出るのが遅れ、競争力の低下につながる可能性があります。ユーザーの視点で見ると、不要な機能や性能の追求のために待たされたり、高い料金を支払わされるといったことにつながる可能性があります。
どんな行為がオーバーエンジニアリングと呼ばれるのか
オーバーエンジニアリングを見定める具体的な基準があれば良かったのですが、プロジェクトの要件や目標によって、初期の段階で高いコストを払うことが正当化される場合もあり、「ここから先はやりすぎ」と一概に決めることは難しそうでした。
しかし、次のような行為はオーバーエンジニアリングと指摘されることが多いようです。
- 現時点で必要のない機能やアーキテクチャを組み込む
- 過剰にパフォーマンスを最適化する
- シンプルに解決できる問題を複雑にする
- 想定される利用範囲を超えた耐久性や安定性を持たせる
現時点で必要のない機能やアーキテクチャを組み込む
たとえば、現時点で必要のないマイクロサービスアーキテクチャを導入する、必要のないAPIエンドポイントを作成するなどです。
マイクロサービスは複数の小規模なサービスを組み合わせて1つの大きなアプリケーションを構成する手法ですが、99％のケースで不要だと書かれている記事を読みました。
特に、一刻も早く市場に適合しなければならないスタートアップにとっては、一枚岩のモノリスようにわかりやすいアーキテクチャの方が利益を出しやすいでしょう
出典: https://gigazine.net/news/20211126-overengineering/
過剰にパフォーマンスを最適化する
必要以上のパフォーマンスを追求して、高度なアルゴリズムを使用し、開発期間を伸ばしたり、コードの可読性や保守性を低下させたりする行為です。
パフォーマンスが重要なアプリケーションや複雑なケースではORM（Object-Relational Mapping）を使わずに生のSQLを書くことが適切な場合もありますが、大部分のアプリケーションではORMが提供する利便性がパフォーマンスの微小な改善を上回ることが多いです。
シンプルに解決できる問題を複雑にする
デザインパターンやオブジェクト指向といった複雑な手法を必要以上に適用しようとしたり、小規模でシンプルなアプリケーションを開発するために、学習曲線が急でリソースが余分にかかる複雑なフレームワークを使用するといった行為です。
これらは開発期間とコストを増大したり、保守性や可読性を低下させたりします。また、初学者に理解しにくいコードになる可能性があります。
想定される利用範囲を超えた耐久性や安定性を持たせる
システムのあらゆる部分にバックアップを持つ、想定外のシナリオに過度に対処しようとする、などの行為です。
すべての起こりうるエラーや状態異常に対処しようとすると、開発期間が大幅に増大します。また、そうした対策が増えることで、コードが複雑になり、可読性の低下、バグの特定や新機能の追加が困難になるといった結果につながります。
オーバーエンジニアリングを避けるための方法
次のような考え方や原則が、開発コストの最適化に役立ちそうです。
- MVP (Minimum Viable Product)
- YAGNI (You aren't gonna need it)
- アジャイル開発
MVP (Minimum Viable Product)
MVPは、新しい製品の最小限の機能を持つプロトタイプを早期にリリースするアプローチです。
これによりユーザーからのフィードバックを早く得ることができるので、将来的に予想される要件に基づいて過度な開発を行うのではなく、現時点で必要な機能だけを開発することができるようになります。
YAGNI (You aren't gonna need it)
YAGNIは有名なプログラミング原則で、機能は実際に必要になるまで追加しないほうが良い、という意味です。「あとで使うかもしれない」という予測に基づいて作られた機能は、実際には10%程度しか使われず、90%は無駄になるといわれています。
アジャイル開発
アジャイル開発は、ソフトウェア開発手法のひとつで、小規模で頻繁なリリースを通じて、ユーザーのフィードバックをもとにソフトウェアを継続的に改善することを目的にしています。MVPと同じく、実際のフィードバックに基づいて現在必要なものの開発に専念することができます。
まとめ
オーバーエンジニアリングを防ぐには、現時点でプロダクトに期待されている機能や品質を、正確に理解することが大切なようです。
必要以上にデザインパターンの適用や最適化にこだわらない、といったエンジニア個人レベルで気をつけることも大事ですが、もっと上流工程から見直して、現時点で要求されている機能や品質が何かを検証する仕組みが必要だと感じました。
Discussion