個人でゼロからWebアプリケーションを開発したことがある方は、利用する技術スタックの選択に頭を悩ませた経験があるのではないでしょうか。このとき、「興味があって、挑戦してみたい」とか「得意な技術でパフォーマンスが出しやすい」といった理由で、プログラミング言語やフレームワークを選んだとします。開発の目的にもよりますが、その選択の良し悪しが取り返しのつかない問題に発展することは、ほとんどないでしょう。

　いっぽうで、ある程度の規模の大きなアプリケーションをチームで開発する場合は、複雑な事情が絡んできます。アーキテクチャ上の問題点がアプリケーション開発の序盤で明らかになることは稀であり、開発を進めていくことで初めて、問題の源泉がアーキテクチャにあると気づくことが少なくありません。Webアプリケーションの開発プロジェクトでは、開発の手戻りによる工数増加、開発効率の低下によるスケジュール遅延、開発体験の悪化によるメンバーのモチベーション低下などの問題が起きます。また、リリース後も、品質の悪化による不具合の発生ならびに運用負荷の増加など、さまざまな形でコストとして跳ね返ってきます。

　普段はあまり意識しないかもしれませんが、アプリケーション開発作業は、多くの選択肢であふれています。プログラミング言語に始まり、フレームワーク、ライブラリー、ミドルウェア、インフラ構成、モジュールの分割、実装方式など、有名なものからそうでないものまで、それぞれ無数の選択肢があります。さらにそれらの組み合わせまで考え始めると、同じ要件を満たすアプリケーションでも、無限といってもいい実現方法が考えられます。

　アーキテクチャ設計とは、このように何も決まっていない状況で、設計や実装の前提となるルールを決める作業です。アーキテクチャの定義は人によってさまざまですが、ここでは、アプリケーションを開発する際に守るべきルールやポリシーを指すものとします。

　適切に設計されたアーキテクチャは、開発チームにとっては、いい意味での制約となります。アーキテクチャ設計の大きな目標は、実装方式に適切な制約を設けることで、アプリケーション開発を取り巻くカオスを最小化すること。そして、将来における技術的負債の発生を抑え、アプリケーションの品質とチームの生産性を、ともに高い水準で維持することです。

　この章では、Nuxt.jsやFirebaseがどのような特性を持っていて、どのようなプロジェクトでの利用に向いているのかを解説します。