無理して SPA を採用しないこと
「ゼロからアーキテクチャを考えるのであればどのような構成を検討しますか？」
これはある企業の面談を受けたときに聞かれたこと。僕は、最低限サーバーサイドのAPIとフロントエンドのSPAを分割する、というようなことを話した。
いま振り返ってこう考えている。それは果たして検討と言えるだろうか？ 意思決定と言えるだろうか？ むしろ惰性に身を任せた思考停止ではないか？
自分への問いかけをこう言い換える。クライアントとサーバーサイドでアーキテクチャを分離するのはたしかに一見綺麗に見える。ただ、 Rails はじめ一般的なウェブフレームワークは、ウェブページを普通にレスポンスできる。そのときわざわざSPAという選択をとるのはなぜか？
考えてみると、特に理由はないような気がする。そのようなアーキテクチャにはしばらく触れていて、それなりに親しんできているという自負もある。にも関わらず、それが妥当だという理由は見つけられなかった。「新しいことをやっている感」が生まれるだけで、本質的にはなにも価値を生んでいないのではないか？ という疑問にうまく答えられない。
ケーススタディ的に、ひとまずありそうなふたつの反対意見を考えてみた。それは以下。
- チームを経営する上で、開発体制としてロールを分割するという判断
- SPAがもたらすUXが「ビジネス上重要」であるという判断
これらはそれぞれ単体では妥当な判断に思われるが、現実にはそうでない場合も少なくない。
まず開発体制として、APIとSPAの責務を分割するという判断について。これ自体は合理的な考え方であるし、ソフトウェアの構造としても、組織の構造としても、綺麗に整理された環境に見えるのも事実である。
しかし経験的には、小さなチームの小さなプロダクトであっても、フロントフレームワークだけはすでに導入されている、という状況は少なくない。ビジネスロジックの実装に加えてフロントの実装にも気を配らなくてはならないわけだから、現場は慢性的に人手不足だ。その開発・保守にあたるリソースを新規募集するにしても、その解決策は本質的には「ブルックスの法則」の通り、不確実性を増大させるだけではないか？
続いてビジネス上の判断として、 SPA で UI/UX を向上させたい、という考えについて。例えばクリエイターの作品であればいわずもがな、ランディングページだとか採用ページなど、伝統的な静的ページであればその判断にいうことはない。
しかしこちらも、プロジェクトの立ち上げ期には当てはまらない。例えばプロトタイピングの段階では、ビジネスロジックの実装と改善が最優先事項であるはず。 UI/UX の問題は、まずは主たる機能が利益を上げられるという事実があって初めて検討されることだろう。
いずれのケースにしても、プロダクトが安定して利益を上げていて、積極的な投資も行われているという前提があって初めて成立する考え方である。そうでない場合、ウェブフレームワークの機能として単体でできることをわざわざ分割して、いたずらに問題を増やすことがあろうか？
以上を踏まえて冒頭の問いかけに立ち返る。
「ゼロからアーキテクチャを考えるのであればどのような構成を検討しますか？」
僕はかつての僕自身の回答を訂正する。開発前の段階から SPA を検討する理由は存在しない。まずは機能が重要であり、機能にフォーカスしなければならない。 そのためにウェブフレームワークを使う。
僕のスキルセットに照らして言えば、 Rails を利用した古典的な構成を第一に検討する。できる限りレールに沿って進める。多少のインタラクティブ性が必要なのであれば、最小限のコンポーネントから始める。結局はそうすることが、総合的な不確実性を封じ込める最善手であると考える。
