この記事はウィルゲート Advent Calendar 2025 4日目の記事です。
こんにちは、ウィルゲート開発室の武田です！
私は設計が好きです。特にアプリケーションアーキテクチャの領域、クリーンアーキテクチャやオニオンアーキテクチャ、ヘキサゴナルアーキテクチャといった美しい理論に惹かれます。きれいに責務が分割されたコードや、美しく整ったレイヤー構造を見ると、それだけで気分が上がるタイプです。
しかし、ある時こんなことがありました。スピードが求められている場面で、美しい設計にこだわりすぎてリリースが遅れてしまったのです。その経験から、「理想の設計こそ正義」という価値観が必ずしも正しくないことに気づきました。
本や登壇で語られる美しい設計の世界は確かに魅力的だし、今も惹かれています。しかし実務では、組織の状況、プロダクトの成熟度、変更頻度などによって、最適な設計は全く変わります。むしろ、そういった条件を踏まえて設計を調整することこそが、ビジネスに対して大きな価値を生むこともあります。
この記事は、そんな気づきをまとめた内容です。
想定読者
- 設計やアーキテクチャ理論が好きなWEBアプリの開発者
- 最近「本に書いてある理想」と「現実のプロダクト開発」のギャップに悩むことがある
ただし話はアプリケーションアーキテクチャに限らず、システムアーキテクチャやインフラアーキテクチャなどにも通じる内容だと思います。
なぜ設計するのか
まず、そもそもなぜ設計をするのかを改めて考えてみます。
設計する理由は、突き詰めると「変更に強いソフトウェアを作るため」です。ビジネスが続く限り、ソフトウェアには変更が発生し続けます。機能追加、改善、不具合修正、技術スタックのアップデート...挙げればキリがありません。
そして、その変更のしやすさはビジネスのスピードに直結します。小さな改善を素早く積み重ねられるか、大きな方向転換をスムーズに実現できるか。これらは、プロダクトの成長スピードを大きく左右します。
つまり、設計の良し悪しは「どれだけ変更を楽にできるか」で決まります。そしてこの「変更」には、頻度や規模、影響範囲などさまざまな側面があります。だからこそ、設計も一律ではなく、状況に応じて調整する必要があるのです。
「美しい設計」への憧れと現実のギャップ
本を読んだり、カンファレンスで登壇者の話を聞いていると、美しい設計が正義のように思えてきます。クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャ...これらの美しい理論に触れると、「自分もこういう設計がしたい」と思うのは自然なことです。
でも、実際のプロダクト開発では、その理想をそのまま適用できないことの方が多いのではないでしょうか。
使い捨てのスクリプトに過剰な設計をするべきではないし、巨大で複雑で今後5年10年続いていくことが分かっているシステムで設計を軽視してしまうのは間違っています。
組織やプロダクトの状況によって、最適な設計は変わるのです。
スピードと割り切りが価値になるケース
たとえば、こんなケースを考えてみます。
新しい機能を素早くリリースして、市場の反応を見たい。とにかくスピード最優先で、まずは動くものを出すことが求められている状況です。あるいは、競合が似た機能をリリースする噂を聞いた。先に出さないとシェアを取られる。このような場面では、スピードが何よりも優先されます。
こういう場合、クリーンアーキテクチャのような重厚な設計を最初から組むのは、むしろビジネスにとってマイナスになることもあります。リリースまでに時間がかかりすぎて、市場のタイミングを逃してしまうかもしれません。それよりも、最低限の責務分離だけを意識して、必要十分な機能を素早く実装する。このようなアプローチが求められる場面も多いです。
ただし、ただ雑に書けばいいわけではない
とはいえ、スピード重視だからといって何も考えずに書くのは違います。
将来変更される可能性が高い部分、たとえば外部サービスとの連携部分。そして、ビジネスロジックのコア部分。こういった重要な部分には、美しい設計から学んだであろう自身の審美眼を小さく適用することが大切です。
柔軟な対応の例：生成AI機能
もう少し具体的な例を挙げてみます。
生成AIを使った機能を、スピード感を持ってリリースする必要があるとします。ただし、一旦のリリース後に、生成AIサービスを別のものに切り替える可能性もあります。
※ 生成AIに依存する機能は、どのモデルを使うかによってその機能の価値が大きく左右されることがあるため。
こういった場合、全体をMVCで簡易的に実装しつつも、生成AIとの接点にだけ腐敗防止層（Anti-Corruption Layer）を設けるという柔軟な対応が考えられます。
つまり、「全体を重厚に設計する」でもなく、「全く設計しない」でもなく、「必要な部分だけに設計を入れる」という判断です。これによって、スピードと将来の変更容易性の両立が図れます。
設計を重視すべきケース
一方で、しっかりと設計を重視すべきケースも存在します。
- 今後も拡張される可能性が高い
- 変更が頻繁に発生することが予想される
- プロダクトにとってビジネスのコアになる部分
- 複雑なロジックで、今後も長く使われ続ける
こういった条件が揃っている場合、丁寧な設計をすることに価値があると思います。
たとえば、こんな例を考えてみましょう。最初はMVCで簡易的に実装してリリースした機能が、ユーザーの反応が予想以上に良かった。機能拡張や改善を繰り返していくことになった。この段階で、特にコアロジック部分の設計を見直す、あるいは作り直すタイミングが来ます。
SaaSプロダクトの料金計算ロジックがその典型例です。最初はシンプルな月額固定料金だけだったものが、従量課金、段階的な料金プラン、割引ルール、複数通貨対応...と次々に要件が増えていきます。こういった部分は頻繁に変更が入り、かつビジネスの根幹を担う機能なので、時間をかけてでもクリーンアーキテクチャのような重厚な設計を適用する価値があります。
ここで重要なのは「プロダクトの成長速度に影響する」から設計するという視点です。
設計という観点でビジネスに貢献する
ここまで見てきたように、設計は「美しさ」を追求するためのものではありません。ビジネスの状況に適合した設計を選択することが、エンジニアとしての価値提供になります。
スピードが求められているときは、軽量な設計で素早く市場に投入する。長期的に育てていく機能やプロダクトには、変更を容易にするためにしっかりとした設計を入れる。
このように、設計の粒度や重さを調整することで、エンジニアはビジネスに大きく貢献できます。そして、この「調整する力」こそが、設計スキルの本質だと私は思います。すべてのコードを完璧に設計することではなく、状況に応じてどこまで設計を行い、どこを割り切るかを判断できることが重要なのです。
最後に
美しい設計が好きだという気持ち、設計に対する審美眼、これら自体は決して悪いものではありません。むしろ、その感覚こそが設計スキルの土台になると考えています。
そして、その感覚を持って設計という手段でビジネスを加速させる事ができる。だからこそ私は設計を好きであり続けたいと思います。
皆さんも、ぜひ一度「設計を調整する」という視点で、自身のプロダクトを見直してみては如何でしょうか。
「ウィルゲート Advent Calendar 2025」、翌日は内藤さんの「爆速コスト削減！成功と失敗のリアル検証記録」です！
