余計な「念のため」でプロジェクトが死に至る「オーバーエンジニアリング」の問題とは？

日本に「過ぎたるは及ばざるがごとし」ということわざがあるように、海外のソフトウェア開発現場でも製品が必要以上に複雑化してしまう「オーバーエンジニアリング」という現象がしばしば問題になります。そんなオーバーエンジニアリングの原因や影響、防止方法について、ボイスチェンジャーアプリの開発会社・Voicemodで主任プロダクトマネージャーを務めるシモン・ムニョス氏が解説しました。

Overengineering can kill your product - Mind the Product
https://www.mindtheproduct.com/overengineering-can-kill-your-product/

ソフトウェアエンジニアとしての経験を持つプロダクトマネージャーのムニョス氏によると、「ありもしない問題を解決するためのコードやデザイン」と形容されることもあるオーバーエンジニアリングは、開発力不足よりも多くのプロジェクトを頓挫させてきた危険な問題とのこと。そこでムニョス氏は、オーバーエンジニアリングの原因、影響、予防方法を以下のようにまとめました。

◆オーバーエンジニアリングが起きる原因
オーバーエンジニアリングは、未知の「万が一」に備えて製品を将来性のあるものにしようとする時に発生します。その「万が一」が起きることはほとんどないにもかかわらず、「時間の浪費」や「プロジェクトの複雑化」といった問題は、プロジェクトが終わる時まで負担になり続けます。

オーバーエンジニアリングが発生するもう1つの原因は経験不足にあります。一般的に、経験豊富なほどオーバーエンジニアリングになりにくいといわれていますが、それは「熟練したエンジニアになるころには、嫌と言うほどオーバーエンジニアリングを経験してしまっているから」とのことです。

以下は、エンジニアの経験とコードの複雑さの関係を表す学習曲線です。経験が浅いエンジニアは、まず単純なコードを書いてプログラミングします。やがて、オブジェクト指向やデザインパターンといった複雑な手法を身につけてそれを生かすチャンスを探し始めますが、不必要な複雑さに悩まされた後再びシンプルなコードに戻ってくる、というのが多くのエンジニアが経験するパターンなのだそうです。

◆オーバーエンジニアリングの影響
オーバーエンジニアリングは、具体的には次の2つの問題を引き起こします。1つは「開発コストの増大」です。プロダクトが複雑化すると開発コストや開発時間が増えて、イテレーションのスパンも延びます。さらに、複雑なコードはテストや修正が困難なので、「メンテナンスコスト」もかさむことになります。これがもう1つの問題です。

ムニョス氏は、オーバーエンジニアリングの事例として「マイクロサービス」を挙げました。マイクロサービスとは、複数の小規模なサービスを組み合わせて1つの大きなアプリケーションを構成する手法のこと。ビジネス環境の変化が速くなったことで、単一のアプリケーションとして構築されたモノリシックアーキテクチャでは対応が難しくなったことを背景に台頭したマイクロサービスですが、ムニョス氏は「私がマイクロサービスをオーバーエンジニアリングの例として取り上げたのは、99％のケースで不要だからです。特に、一刻も早く市場に適合しなければならないスタートアップにとっては、一枚岩のモノリスようにわかりやすいアーキテクチャの方が利益を出しやすいでしょう」とコメントしています。

by 'No Matter' Project

また、ユーザーがまだほとんどいないのに複雑なインフラ設定をしたり、将来同じことを繰り返すのを恐れて不適切なタイミングで最適化を行ったりしてしまう「Premature optimization(早すぎる最適化)」も、オーバーエンジニアリングの典型例とのことです。

◆オーバーエンジニアリングを防ぐ方法
ムニョス氏によると、オーバーエンジニアリングを防ぐ最善の方法は「エンジニアを真のプロダクトエンジニアにすること」だとのこと。具体的には、エンジニアに日々の業務に関与させてそれぞれの取り組みの理由を理解してもらったり、ユーザーとのセッションに参加させてユーザー目線を身につけさせたりしてプロダクトマネージャーのスキルを身につけてもらうことで、オーバーエンジニアリングが起きにくくなるそうです。

また、問題をしっかり定義して曖昧さを排除すると、エンジニアが万が一に備え過ぎてオーバーエンジニアリングに陥るリスクが減ります。適切な定義には、サービスレベル目標(SLO)やサービスレベル指標(SLI)を使った目標設定を行うといいそうです。

ムニョス氏は、オーバーエンジニアリングならないためのエンジニア向けのアドバイスとして、「『これはユーザーが今直面している問題の解決に役立つのか？』『今やる必要があるのか？』を自問してみてください。そうすると、万が一に備えたシナリオがオーバーエンジニアリングのリスクをはらんでいるかどうかを判断することができます」と述べました。

また、エンジアを雇用しようとしているスタートアップの創業者には「すでにほかの会社で経験を積んだシニアエンジニアを優先的に採用するといいと思います。面接では、つらかった経験やそれにどう対処したかを尋ねて、過去の修羅場をくぐった時の傷跡を探しましょう。そうした質問に対して、技術的なソリューションよりユーザー目線やシンプルさを重視する姿勢を見せた人を選ぶのがコツです」と勧めました。

◆オーバーエンジニアリングへの戒めになる格言
ムニョス氏は最後に、オーバーエンジニアリングに陥らないための格言を、以下の3つ紹介しました。

・YAGNI原則
YAGNI原則とは「You ain't gonna need it(そんなの必要ない)」の頭文字をとった略語で、「機能は実際に必要となるまでは追加しないのがよい」とする原則を表しています。

・KISSの原則
KISSの原則とは、「Keep it simple stupid(シンプルで愚直にする)」の略で、不必要な複雑さを避けてできるだけ簡潔な設計を心がけるよう呼びかけるものです。

・Worse is better
「Worse is better」は直訳すると「悪いことは良いことだ」となりますが、実際には「選択肢が少ないほど望ましい」という意味とのこと。ムニョス氏は「言い換えれば、この言葉は製品にとって不可欠な機能を維持して、複雑化につながりかねない無駄な要素の追加を防止することです」と説明しています。