単純なものは単純に

ソフトウェア・アーキテクトは、非常に難しい問題をいくつも解決しますが、比較的簡単な問題を解決することもあります。ここで是非避けたいのは、簡単な問題を複雑に解くことです。それは当たり前だろうと感じるかもしれませんが、実際にはなかなか難しいのです。ソフトウェアを設計する人々は、賢いのです。本当に賢いがゆえに、つい知恵があることをひけらかしたくなるので、簡単な問題を複雑に解くという罠には落ちやすいのです。

ソリューションがあまり巧妙すぎて自意識過剰みたいだと感じたら、手を止めて考えましょう。そのソリューションは、問題にぴったり合っているでしょうか。答えがノーなら、設計のオプションを考え直しましょう。単純なものは、単純なままにするのです。難しい問題が登場すればあなたの能力を示すチャンスはいくらでもありますし、難しい問題はかならず現れます。

だからといって、エレガントなソリューションを実装してはならないと言っているわけではありません。SKUで管理されている商品だけを販売できるシステムを設計しているなら、製品の管理階層をダイナミックに設定できるように設計するのはよくないだろうというだけのことです。

複雑なソリューションによって増えるコストはごくわずかに見えるかもしれませんが、あなたがこれくらいと，思っている額よりも多くなる場合があります。アーキテクチャーレベルで設計を作りすぎると、開発レベルでも同じ問題の多くが発生しますが、負の効果はしばしば何倍にもなります。設計レベルでまずい判断を下すと、実装、メンテナンスが難しくなり、さらに最悪なことに元に戻すのが難しくなります。システムの要件を越える内容のアーキテクチャーのまま先に進んでしまう前に、作ってしまうとそれを取り除くのがどれだけ難しいかを考えましょう。

コストは、問題のソリューションの実装、メンテナンスだけに留まりません。簡単な問題に必要以上に時間を使うと、複雑な問題が現れたときに使える時間が短くなります。アーキテクチャー上の判断ミスのために、突然スコープの肥大化が起きて、プロジェクトに不要なリスクが加わります。誰もそんなことをしないようにすれば、あなたの時間はずっと効率的に使えるはずです。

頭の中で考えたメリットや要件を組み込んだソリューションを正しいと考えたくなることはよくあります。しかし、覚えておきましょう。将来必要になることを推測しても、50%の確率で間違い、49%の確率で大きく間違うのです。

今日のところは、今日の問題を解決しましょう。時間通りにアプリケーションを引き渡し、フィードバックを待つのです。本当の要件はフィードバックに含まれています。設計をシンプルにしておけば、そうでないときと比べて、新しい要件を組み込むのはずっと簡単です。勘が当たって予想した要件が次のリリースで本物の要件になった場合には、ソリューションはすでに頭の中でできあがっています。以前との違いは、今度は本物の要件になったので、実装のために時間を割いてよいということです。あなたは知らず知らずのうちに、仕事を時間通りに完成させることができる上に、勘もよいと評判になるでしょう。