「最初からあれもこれも取り入れよう」←これ、バッドプラクティスです

アプリやシステムを作るときに
「こんな機能があれば便利だよなー」
「流行りのKubernetesを絶対使うぜ」
などと、特にユーザーに価値を与えないのに無駄な機能や設計を目指してしまう経験は皆さんにもあると思います。
今回はそんなオーバーエンジニアリングの話をします。

「今日の技術」で何か分からないことやご意見・ご要望・ご感想があればどどっとお寄せください！
コメントはとても励みになりまし、筆者のさらなる深い理解や説明力へのフィードバックにもなります！
何よりあなたが分からないことは他の人も分からない可能性が高いので、コメントで補足できるようになります✨

オーバーエンジニアリングって？

「無駄に複雑に作り込む」ことをいいます。
システムやアプリを作り始めた当初はそういう複雑な設計が必要だと思って作るのですが、その設計が誤っていたり後から不要になったりして、何の価値も生まない無駄に複雑なものになるのです。

具体的にいうと？

例えばTODOアプリを考えてみましょう。
一番最初に必要となる本質的な機能は、TODOアイテムをリストアップして完了のチェックボタンを押すことだけなのです。
しかしTODOアイテムとしてファイルを添付できるようにしたり、サブタスクを作れるようにしたりするとオーバーエンジニアリングとなりえます。

別の例を挙げましょう。
過剰な設計フレームワークを導入してしまうこともオーバーエンジニアリングです。
たった100行程度のコードので出来上がるプログラムに対してヘキサゴナルアーキテクチャのような重量級の設計手法を用いてしまうと、コストばかりがかさんでしまいます。

他にもあります。
アプリをデプロイするのにAWSのlambdaを使って簡単に提供する方法もありますし、Kubernetesを使って大量のリクエストにも耐えられる設計にすることもできます。
しかし市場投入開始の段階でそこまでリクエストが来ないのであれば、まずは素早く動かすことを優先しましょう。
Kubernetesでの方法はオーバーエンジニアリングです。

注意していただきたいのですが、ここで挙げたオーバーエンジニアリングの例を未来永劫取り入れるなと言っているわけではなく、まだそのときでないと言っているだけなのです。
まずは小さく、素早く、Fail Fastでいきましょう。

オーバーエンジニアリングを避けるための2つの質問

次の2つの問いに答えてみましょう。

• ユーザーに価値を提供するか？

• 物事を簡単にするか？

両方がNOであればオーバーエンジニアリングの可能性が高いです。
本当に今行うべき設計・実装なのかをもう一度検討してみましょう。