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

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

### オーバーエンジニアリングの2つの意味

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

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

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

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

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

### 過ぎたるは及ばざるがごとし

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

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

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

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

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

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

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

### ソフトウェアの開発に内在するスケーラビリティへの要求

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

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

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

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

### 自己陶酔型のエンジニアリング

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

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

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

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

### 成功体験がセカンドシステム症候群を誘発する

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

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

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

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

### オーバーエンジニアリングへの誘引が自分の中もあることを自覚する

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

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

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

### 要件の本質、解決すべき問題の本質を捉まえる

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

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

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

### 要件の意味を包括的、長期的に理解する

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

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

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

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

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

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

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

システム開発をしているエンジニアがついやってしまいがちなオーバーエンジニアリング。余計な時間がかかるだけでなく、後々システムにとって負の遺産になることもあります。本記事は、オーバーエンジニアリングとはなにか、オーバーエンジニアリングが生じる原因と、予防策について考えます。

オーバーエンジニアリングとは、成果物に本来求められていない機能を装備させることである

オーバーエンジニアリングが生じる原因には人間的な要素が大きい

オーバーエンジニアリングを防ぐには要件の本質をUXから理解する必要がある

オーバーエンジニアリングとはなにか？なぜ発生し、どうすれば防げるのかを徹底解説！

オーバーエンジニアリングの記事（1ページ目）