─フロントエンドMVCフレームワークの活用実例─(藤澤 優) Webシステム開発の最新トレンド 1/3

20180618ec

Webシステムの開発に、新たな手法が導入されつつある。最新のフレームワークを活用することで、ビジネスが要求するスピードに合わせ、Webシステムの構築や改修が可能になってきている。本稿では、Webシステム開発の最新トレンドであるフロントエンドMVCフレームワークについて、導入事例を交え、その効果について解説する。


ITSデザイン事業部 システムエンジニア 課長代理 藤澤 優

フロントエンドMVCフレームワークとは

フロントエンドMVCとは、主にWeb ブラウザ上で動的なアプリケーションを実装するために利用されるプログラミング言語であるJavaScript に、サーバーアプリケーションでよく利用されるデザインパターンのModel -View – Controller(MVC)を組み合わせたものである。このフロントエンドMVC フレームワーク(以下、フロントエンドMVC)をWebシステム開発に採用する動きが活発になってきている。

新しいフレームワークを取り入れ、従来のWebアプリケーションの構造そのものを見直すことで、開発・運用をより効率よく行うことができる。本稿では、フロントエンドMVCについて、従来の開発手法との違いを踏まえ、その導入効果について説明する。

MVC は、従来、サーバーアプリケーションの開発効率向上のために用いられてきた設計思想であったが、この思想がフロントエンドへと移植されている。図1に従来型のMVCフレームワークとフロントエンドMVCの違いを示す。

フロントエンドMVCを適用する最大の理由は、「表示変更を伴う改修に、タイムリーに対応する」ことである。システム運用において表示の変更は要望が多く、またビジネスに合わせてタイムリーな対応が求められる。

料金計算やユーザー管理などの仕組みは、一度構築すれば頻繁に変更することはない。一方でユーザーに情報を提供するインターフェース部分は、Webサイトにおける商品購入の成約率向上やサービスの利用促進のために、さまざまな変更改修のニーズが頻繁に発生する。このように変更点の多い箇所と少ない箇所をシステムの構造上明確に分割し、ビジネスロジックに影響を与えず、一方でインターフェースを効率よく開発できるようにするフレームワークがフロントエンドMVCである。

フロントエンドMVCのフレームワークとして主要なものを表1 に示す。Webサービスをけん引する世界的な企業がフレームワークを開発・提供している点に注目してほしい。提供開始時期を見ると分かるが、ここ数年で開発された比較的新しいフレームワークではあるものの、開発元のWebサービスでは既に自社サイトなどで利用しており、実績のあるフレームワークである。

フロントエンドMVCの導入事例

NRI ネットコムが、フロントエンドMVCの主要なフレームワークのうち、Google 社のAngularを利用し、Web サイトの一部リニューアルを行った事例を紹介する。

リニューアルを行ったWebサイトは、多くの商品をエンドユーザーに提示し、契約へとつなげるサイトである。顧客の契約情報や商品の情報そのものは、これまで大きな変更は必要としていなかった。商品については、ビジュアルが顧客の契約意欲の喚起に直結していたため、Webサイトのデザインリニューアルはこれまでに数回実施されてきた。しかし、例えば、契約成立数の向上を狙った商品のマーケティング施策をサイト上で実施したいといった要望があった場合、1つの変更を画面に反映させるために数カ月かかるなど、ビジネスの期待するスピードに対応できないことが問題となっていた。

主な原因は、アプリケーションの構造にある。画面の表示と商品の管理機能が分割されておらず、画面の一部を変更するとシステム全体への影響があり得るため、前述のような画面の変更要件だけに対応することが難しくなっていた。また新たなサービスの展開時なども、その対応には画面表示と管理機能を合わせて修正する必要があるため、大きなコストがかかっていた。

スピードとコストの問題に対応するため、特に商品をエンドユーザーに提示する部分について容易に改修が行えることを目的に、「フロントエンドMVCの導入」と「サーバー側処理のAPI化」という2つの施策を実施した。

「フロントエンドMVCの導入」については、前節で述べた通り、開発の効率化が狙いである。特に当該サイトは、ビジュアル的な訴求が求められており、画面上でのアニメーションや動画再生などの改善を今後も行う予定があったため、その開発を見越した仕組みが求められていた。

「サーバー側処理のAPI化」については、フロントエンドMVCを生かしつつ、業務ロジックへの影響を完全に分離することが狙いである。フロントエンドMVCの採用で開発効率が上がったとしても、業務ロジックへ影響がある修正は開発現場としては受け入れがたい。一方で、修正内容が業務ロジックに対して全く影響がないことをテストで担保しようとすると、コスト増は明らかである。そこで、システムの構造自体をフロントエンドMVCとサーバー側のAPI処理として明確に分け、変更が頻繁に行われる処理はフロントエンドMVC側へ寄せ、業務として変更が少ない処理は接続用の公開APIへと再配置した。図2が現行システムと新システムの比較である。

お問い合わせ

当社のサービス・製品に関するご相談やご質問、お見積りのご依頼など、こちらからお問い合わせください。