オーバーエンジニアリングとは

オーバーエンジニアリングとは、気をきかせたつもりがありがた迷惑になるような過剰なエンジニアリングのことです。また、シンプルに組み立てることができず無用に複雑にしてしまうエンジニアリングを指すこともあります。

日本語版のウィキペディアには「オーバーエンジニアリング」の項目はありませんが、英語版では次のように定義されています。

「オーバーエンジニアリングとは、製品を、その用途に必要な以上に頑丈にしたり、多くの機能を装備させること。あるいは、ある機能を装備するために不必要に複雑、非効率な設計することである」

つまり、製品に過剰な性能を与えること、あるいはある機能を持たすめの設計(システム開発)で、最短コースではなく遠回りをしてしまうことがオーバーエンジニアリングです。

自転車のタイヤに時速100㎞に耐える性能は必要ないし、独身寮に置く電子レンジに「煮込み機能」や「パン焼き機能」は無用の長物です。

エンジニアリングの場合、同じ機能があるのなら、できるだけシンプルなロジックで書かれたコードが望まれます。

日常の使用ではオーバーエンジニアリングと思われていた機能が災害時には役に立った、ということもあります。セキュリティに関してはオーバーエンジニアリングが起きにくいと言えるかもしれません。しかし、そんなケガの功名がいつも生じるわけではありません。

自転車のタイヤが時速100㎞で壊れなくても不都合はないし、独身寮の電子レンジに煮込み機能が付いていても別に邪魔にはなりません。大は小を兼ねるのです。それにもかかわらず、オーバーエンジニアリングが「過ぎたるは及ばざるがごとし」と言われるのはなぜでしょうか。

最も分かりやすい理由は、オーバーしている分だけ時間とコストがかかっているからです。それはユーザーにとっては「高い価格」につながるし、メーカーには「競争力の低下」をもたらします。

システム開発における不必要に複雑なロジックは、オーバーエンジニアリングというより、エンジニアリングの失敗です。見た目では問題なく機能しているようでも、それがシステムの脆弱性になったり、バージョンアップの際に手間やコストがかかる原因になります。

趣味で行なうプログラミングにオーバーエンジニアリングという概念はないかもしれませんが、仕事・企業活動においては常に「過不足ないエンジニアリング」が求められます。

オーバーエンジニアリングが生じる原因

エンジニア・クライアント・ユーザーそれぞれにデメリットが大きいオーバーエンジニアリングがしばしば生じるのは、エンジニアリングも人間の行為で、ヒューマンな要因が深く関わっているからです。

スケーラビリティ（scalability）とは、例えばユーザーが1万人から100万に増えても適応できるような拡張性のことです。エンジニアはシステム開発をするときに、スケーラビリティを過剰に追求する傾向があります。

しかし、「将来はこんな機能が役に立つはずだ」とか「この機能ではここも拡張可能にしておいて方が良い」という発想は、オーバーエンジニアリングを生む大きな要因です。

とくに日本人は「おもてなしの精神」が豊かなので、「不足」を心配するあまりに実装内容が過剰になりがちなメンタリティを持っています。

「今のところは、とりあえずこれで間に合う」がもっとも妥当なシステム開発と言えます。現在、自分あるいはプロジェクトが抱えていない問題を解決するコードを書く必要はないのです。

要件をコードに落とし込むときに、なにかアイディアが浮かぶと、ついそれを実装したくなる誘惑にかられませんか？

「オレもなかなかやるじゃないか」と思う瞬間があるのはプログラミングの醍醐味ではありますが、「なんてオレは賢いのだろう」という自己陶酔は抑制しないと、いたるところでオーバーエンジニアリングが生じます。

ドキュメンタリー映画を作るときに、効果音楽をドラマチックにしたり、有名俳優をフューチャーしたりするのは逆効果です。自己陶酔型のエンジニアリングでは、このようなフューチャリング(過剰な機能の追加)が生じがちです。

システム開発中に「こんなこともできる」「あんなこともできる」というアイディアが浮かんだとしても、それは別のプロジェクトに活用すべきアイディアかもしれません。

最初のシステム開発では「コンパクトに、シンプルに」という自制心が働いたとしても、それが成功して「次のバージョンを」というときにやりすぎてしまうのがセカンドシステム症候群です。

ファーストバージョンの成功は開発者に自信を与え、ステークホルダー(利害関係者)にセカンドバージョンへの期待を抱かせます。このような勢いに乗ったムードの中でオーバーエンジニアリングを自制するのは、簡単ではありません。

オーバーエンジニアリングを避けるには

エンジニアリングという仕事にやりがいを感じている人、創造性がある仕事だと思っている人ほど、オーバーエンジニアリングに陥りがちです。それを避けるには、次のような注意が必要です。

オーバーエンジニアリングが生じる原因にはヒューマンな要素が大きいので、エンジニアは「気をつけないと自分もやってしまう」という自覚を持つ必要があります。

とくに、「できるエンジニア」だという自己肯定感は、自己陶酔型のエンジニアリングを誘引しやすいので、自制しなければいけません。

成功体験でチームや会社のムードが盛り上がっているときも、セカンドバージョンの設計でオーバーエンジニアリングが生じやすいので、警戒が必要です。

オーバーエンジニアリングを防ぐには、心構えだけでなく、要件の本質的な意味を理解することが必要です。言い換えるなら、「なぜこの要件があるのか」をUI(ユーザー・インターフェース)、UX(ユーザー・エクスピアリエンス)の視点で深く捉える必要があります。

また、 YAGNI（You ain't gonna need it）の原則では、実際に必要となるまでは余計な機能は追加しない方がよいとされます。要件の本質、必要性がユーザー目線で明確化されれば、複数の想定されるソリューションのどれを選ぶべきかは、ある程度絞られてくるはずです。

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

個々の要件の意味を、プロジェクト(あるいは製品)の全体像から理解すること、さらに、できるだけ長期的な観点から理解することがオーバーエンジニアリングを防ぐことにつながります。

これは個人の心構えや努力だけでは限度があるので、プロジェクト全体、企業全体の意思統一と見通しが必要です。

要件の理解、ソリューションの選択が、課題の全体像から離れるほどオーバーエンジニアリングが生じやすく、プロジェクトのあちこちでそれが生じるほど、成果物は将来に向けて厄介な問題を抱え込むことになります。

オーバーエンジニアリングかどうかの分かりやすい基準はない

ここまで述べてきたように、オーバーエンジニアリングがヒューマンな問題である以上、あるソリューションがオーバーエンジニアリングかどうかの客観的で分かりやすい基準はありません。

また、あるソリューションがオーバーエンジニアリングかどうかは、セカンドシステムをどの程度視野に入れておくかによっても、判断が異なってきます。

このように単純明快な対処策がないのがオーバーエンジニアリングなので、エンジニアに求められるのは、要件の意味をUX視点で繰り返し問い直しながら、過不足ないエンジニアリングを心がけることです。