はじめまして。株式会社PRUMでエンジニアをしている ひとみ です。
日々、プログラミング学習や実務の中で、つまずきやすいポイントや
考え方を整理して発信しています。
PRUMについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト
その“親切な設計”、たぶん無駄です
― エンジニアがハマる「やりすぎ問題」
はじめに
こんな経験、ないでしょうか。将来を考えて拡張しやすく設計した。
汎用性も意識した。綺麗にまとまっている。なのにレビューでこう言われる。
「今はそこまでいらないです」「シンプルでいいです」
技術的には間違っていないはずなのに、なぜか戻される。
結論はシンプルで、「やりすぎ」です。
エンジニアがやりがちな落とし穴
エンジニアは、将来に備えることが良い設計だと考えがちです。
拡張性を持たせる、共通化する、抽象化する。どれも間違っていません。
ただし、それらはすべて「コスト」とトレードオフです。
- 抽象化すれば理解コストが上がる
- 共通化すれば影響範囲が広がる
- 拡張性を持たせれば実装量が増える
過剰品質とは、必要以上に作り込みすぎることです。使われない拡張性や未来前提の設計がこれにあたります。
つまり、良かれと思ってやっていることが、実は未来の負債になる可能性があります。
ここで重要なのは、「正しいかどうか」ではなく「今必要かどうか」です。
IT戦略がやっていること
IT戦略という言葉は難しく聞こえますが、やっていることはとてもシンプルです。
それは、「どこまでやるか」を決めることです。すべてを作るのではなく、
必要なところまでで止める。その判断軸を持つことがIT戦略です。
IT戦略とは、技術そのものではなく「どの技術をどこまで使うか」を決める考え方です。作る力ではなく、選ぶ力とやめる力に近い概念です。
判断の軸を具体化する
では、どうやって「止めるか」を判断するのか。
現場では、次の3つに集約できます。
1. 今使われるか
この機能は、リリース直後に使われるか。YESなら作る価値がある。
NOなら後回しでいい。ここを曖昧にすると、「誰も使わない機能」
が増えていきます。
2. 不確実性の高さ
その仕様はどれくらい確定しているか。仕様変更の可能性が高いもの
に対して、重い設計を入れるのはリスクです。不確実な領域ほど、
シンプルに作る。これが結果的に、変更コストを下げます。
3. 変更コスト
後から変えるのが大変かどうか。
- DB設計 → 後から変えにくい
- UIやロジック → 比較的変えやすい
変えにくい部分にはしっかり設計を入れ、変えやすい部分はシンプルにする。
MVP（Minimum Viable Product）とは、最小限の機能で作るプロダクトのことです。完璧さよりも「まず使われること」を優先する考え方です。
よくある設計との違い
よくあるのは、「将来こうなるかもしれない」という前提で設計を
広げるパターンです。しかし実際には、その未来は来ないか、
別の形でやってきます。結果として、使われない設計だけが残る。
一方で良い設計は、「今の要件にフィットしている」状態を重視します。
未来は予測するのではなく、「変えられる状態にしておく」ことで対応します。
まとめ
エンジニアの仕事は
どこまで作るかを決めること
やることを増やすよりも、やらないことを決める
これができると、設計の質は一気に上がります。
作り込みたくなったときほど、一度立ち止まってみてください。
それ、本当に今必要ですか？
PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ コーポレートサイト
エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト