SPAはSingle Page Applicationの略になります。よく知られているところでは、キャンペーンページやスマートフォン向けのWebアプリケーションで使われています。

今回は、SPAがどう業務アプリに向いているのか紹介します。これを機に業務システム開発へSPAを適用してくれる方が増えることを期待しています。個人的には2014年から19年までhifive – HTML5企業Webシステムのための開発プラットフォームに関わっていたこともあり、業務システムのWeb化はぜひ推進していきたい分野でもあります。

SPAの特徴

SPAはシングルページ（アプリケーション）のことなので、当たり前ですが1つのHTMLページで構成されています。一度Webページを表示した後は、差分表示に関する情報をサーバーから取得し、それを画面に反映し続けます。

URLが変わらない（パーマネントURLがない）という話も聞きますが、History APIを使えば見た目上のURLを変更できます。むしろどのようなURLであっても /index.html に相当するページを読み込んだり、パスに応じたコンテンツの再表示する方が面倒かも知れません。

通常のWebサイトであればフォーム送信した段階でサーバー側に情報が送られて、処理が実行されます。その結果に応じてHTMLが生成されて、Webブラウザに返却されます。

それに対してSPAの場合はフォーム送信をJavaScriptが行い、結果もJavaScriptで受け取ります。つまりJavaScriptがオフになっている状態では、まず利用できません。

業務アプリ開発に向いている理由

JavaScriptの動作をほぼ固定できる

一般ユーザー向けのWebサイトでSPAで公開する場合、個々の環境におけるJavaScriptの動作にケアする必要があります。最近ではずいぶんWebブラウザ間の差異は減りましたが、それでもGoogle ChromeとSafariで動作の違いは存在します。また、ユーザーによってはJavaScriptをオフにしているケース、機能拡張で何らか制御を行っているケースもあるでしょう。

それに対して業務システムは限られたユーザー向けのシステムであり、動作環境もある程度縛れます。テストも容易になり、動作保証もしやすいでしょう。

データ送受信量を減らせる

業務システムの場合、入力項目が多かったり、一画面に表示する情報量が多いなど、総じて送受信されるデータ量が増えがちです。そうした中でHTMLのヘッダーやフッターなど、不要なデータまで送信しなければなりません。SPAの場合は最初にHTMLを送信した後は、入力情報と画面構成の差分情報だけを送れば済みます。最初に表示されるHTMLも静的なものであるケースが多いので、サーバー負荷は大きくありません。

画面の差分情報はHTMLではなく、JSONでやり取りされることが多いです。そのJSONをWebブラウザで解釈し、画面に反映します。サーバー側で複雑なHTMLを生成する必要がないという点も利点になるでしょう。Webブラウザ側で表示に関する負荷を受け持つことで、サーバー側の負荷を減らす効果があります。

表示が高速

上記のデータ送受信量軽減にもつながりますが、画面の差分情報だけを受け取って表示に反映するため、一般的に表示は高速に行われます。都度JavaScriptやCSSファイルを読み込む必要がないので、余分なネットワーク接続が発生しないのもメリットです。

業務システムでは即応性が求められることが多いので、速く処理が終わることでユーザーストレスは軽減できるでしょう。

クラサバ構成の置き換えに

元々業務システム界隈ではクラサバ構成が当たり前でした。クライアント側でUIを持ち、何らかの通信を通じてサーバー側にデータを送信します。これはVB6の時代から、ActiveXそしてFlexの時代まで変わりません。Webシステムの時代になってサーバー側でUI（HTML）まで作るようになりましたが、SPAはクラサバに近い構成と言えます。

サーバー側にデータの処理や保存、UI生成とすべての責務を押しつけるのではなく、クライアント（Webブラウザ）側に適した処理（UXに関係するところ）を任せると同時にUI生成を任せるのがSPAと言えます。そう考えると、SPAによる業務システム開発は原点回帰に近いかも知れません。

SEOは気にしない

SPAはSEOに弱いと言われることが多いですが、業務システムの場合は気にする必要はないでしょう。認証必須が当たり前ですし、認証が伴うシステムであれば、クローラーにインデックスされる必要はありません。そうした意味でもSPAと業務システム構築は相性が良いのではないでしょうか。

OGPも同様にSPAが弱い分野になりますが、こちらも業務システムの場合、気にする必要はないでしょう。

JavaScriptの機能強化

かつてはJavaScriptの機能が多くなかったり、使い勝手が良くないために大人数での開発に向かないと言った話がありました。現在ではUI上の操作はもちろんのこと、多くのAPIによって多機能なWebアプリケーションが開発できるようになっています。そしてTypeScriptを使うことで型定義が可能になり、堅牢なシステムを多人数で開発するのも問題なくなっています。

向かない分野

ここで注意して欲しいのはすべての業務システムにSPAが向いているという訳ではないということです。例えば以下のようなケースではSPA（というかそもそもWeb）は向いていないでしょう。

• 専用デバイス（内線システムやプリンターなど）との連携が必要
• 大量の入力項目に対してテンキーで高速に操作する

こうしたシステムの場合、専用のドライバーが必要だったり、OSとのより強力な連携が必要なことがあります。この辺りはSPA云々よりも、Webとの相性が悪い分野になるので注意してください。

技術的ハードルについて

かつてのSPAというと、スクラッチで開発したりXMLHTTPで通信して処理すると言ったものでしたが、今はReactやVue.jsなどのフロントエンドフレームワークが充実しています。画面への反映なども複雑ではなく、とても簡単にできます。技術的なハードルが下がっている現在においては、学習コストもさほど高くありません。

技術変遷のメリット

プログラミング言語やフレームワークの変遷はとても速く、5年後には廃れてしまっていることは少なくありません。10年前であればFlexが業務システムで普通に使われていましたが、システムリプレイスに追われた方も多いでしょう。ある技術を選定した結果、技術的なパラダイムシフトによって一気に廃れてしまうリスクは避けたいと考えるのではないでしょうか。

HTMLやWebについてはオープンな技術であり、長い歴史があります。HTML APIについても後方互換性が維持されながらアップデートが行われており、破壊的なアップデートは滅多に行われません。その意味ではHTML/JavaScript/CSSによるシステム開発は中長期的な運用が期待できます。

サーバー側でHTMLを出力する場合、サーバー側のフレームワークや言語の変遷に左右される可能性があるでしょう。外部ライブラリを使っている場合には、そのリスクがさらに高くなります。サーバーとクライアントを分離しておくことで、そのリスクをある程度下げられる可能性があります。

まとめ

従来クラサバでシステム開発を行っていた方であれば、SPAにすることでWebブラウザとサーバーで責務を分担するのは納得しやすいのではないでしょうか。現在はSPAを実現できるフロントエンドフレームワークは多数あり、開発も容易です。

私たちの提供するHexabaseでは業務システム開発に必要なバックエンドを提供しています。フロントエンドフレームワークと組み合わせて、Web業務アプリを開発できます。ぜひお試しください。

法人向けクラウドシステム『Hexabase』