前回、Webシステム、特にバックエンド側を中心とした業務Webシステムの技術は、10年前にゴールを迎えたのではないかという問題提起をしました。もちろん、これに対して異論を唱える方もいるはずです。そして実際には、用途ごとに異なる「Webシステム」が存在しているのが現状だと思います。その中で筆者は前回、「つなぐ技術」を活用することで、現場で直面する課題に対応しやすくなるはずだと提案しました。これを受けて、今回はシステムとシステムをつなぐ具体的な方法を紹介します。
対象読者
- これまでのWebシステムの進化や成長についてを知りたい方
- 今のWebシステムと昔のWebシステムの違いを知りたい方
- 人材や背景に応じたシステム設計を行いたいと思っている方
バックエンドとフロントエンドという分け方は古い?
第1回と第2回の記事において、意図的にWebシステムをバックエンド、フロントエンドという分け方をしていました。これは、人材を募集・採用する場合においても同様に、ポジションを分けるのが一般的です。
図1(左)のように、その領域でできることをするというレベルが、前回筆者が示した10年前のシステムだと考えられます。しかし、近年はUXやユーザー体験を高めることが重視されるようになり、フロントエンド技術とバックエンド技術が密に連携することで(図1の右)、結果としてフロントエンドエンジニアはサーバーの領域もカバーするようになってきています。
このように現在のWebシステムは、単なるバックエンドとフロントエンドという役割分担から進化し、UIとユーザーに届ける価値をつなぐ「エクスペリエンスレイヤー」と、ビジネスロジックやデータ処理といった「バリュー(価値創造・管理)レイヤー」の二層構造へ移行しています。
例えば、ECサイトでは、商品表示や購入処理を行うUI部分と、在庫管理や決済処理といった業務処理の間に、レコメンド機能やパーソナライズされた情報提供といった付加価値を行うケースも多いです。こういったケースでは、フロントエンドやバックエンドという単純な分け方ができなくなっています。
つまり、今後のWebエンジニアに求められる要求をより反映すると、バックエンドエンジニアとフロントエンドエンジニアという分け方よりも、「エクスペリエンスレイヤー」エンジニア、「バリューレイヤー」エンジニアという分け方になってくるはずです。
「つなぐ技術」とは
前述のように、Webアプリケーションの開発において、リッチなユーザーインターフェース(UI)の要求が高まり、フロントエンド技術が高度化するにつれて、その担当領域も広がる傾向が見られます。
一見すると、これはフロントエンド技術がサーバー技術の役割を侵食しているようにも捉えられかねません。実際、既存のフロントエンド技術者は、ユーザー体験(UX)を提供する「エクスペリエンスレイヤー」を深くカバーする必要性が増しています。従来のシステム構造だけを見ると、相対的にサーバーサイド技術者が担当する領域が狭まっているように感じるかもしれません。
特に図2(左)が示すように、以前の開発では、ビジネスロジックの本質的な機能と、単なるユーザー補助的な機能との境界線が曖昧なまま実装が進むことが少なくありませんでした。
しかし、本来、「エクスペリエンスレイヤー」とビジネスロジックやデータ処理を担う「バリューレイヤー」は明確に分離されている方がよいでしょう。そして、その分離を実現し、両レイヤーを連携させるために重要なのが、図2(右)に示した「つなぐ技術」です。
そもそもバリューレイヤーが提供する機能は、複数のインターフェース(エクスペリエンスレイヤー)を通じて利用される可能性があります。
例えば、ECサイトのバリューレイヤー(在庫管理、決済処理など)は、Webブラウザだけでなく、スマートフォンアプリやチャットボット、さらには音声アシスタントといったさまざまな「エクスペリエンスレイヤー」からアクセスされる可能性があります。
また、昨今では、企業の枠を超えて「バリューレイヤー」の機能を提供するSaaSが普及しているのも特徴です。
こういったトレンドに対応するために、横断するレイヤーを柔軟に連携させることは不可欠です。具体的には、REST APIやGraphQLといった標準的なAPIを通じて、異なる技術スタックやプラットフォーム間でデータや機能を共有する仕組みが重要になります。
API化(マイクロサービス化)を進める
「エクスペリエンスレイヤー」と「バリューレイヤー」を明確に分離する第一歩は、既存のバックエンドシステムが提供する機能をAPI化することです。
ここで言うAPIとは、単なる機能の呼び出しインターフェースという広い意味ではなく、REST API、JSON-RPC、GraphQLといったHTTP(HTTPS)などのプロトコルを用いてリクエストとレスポンスの形式で構築されるものを指します。
なぜなら、APIを通じて機能を公開することで、各機能が独立した小さなサービスとして分割・管理しやすくなるからです。こういったシステム連携を進めることは、同時にバックエンドシステムのマイクロサービス化の流れにもつながります。
もっとも、実際のAPIを公開するに際には、どのような方法でAPIを実装するかという課題も生じます。そこで以下では、こういったAPIを提供するマイクロサービス群を補完し、より効率的な連携を実現するための方法について紹介していきます。
この記事は参考になりましたか?
- これまでのWebシステムの歴史とトレンド連載記事一覧
-
- Webシステムを「つなぐ技術」で、より成長できるシステムを作る~API化から生成AIとの連...
- 業務Webシステムは2010年が転換期だった? HTML5以降の最適化の歴史
- Webはどんどん複雑になっている? これまでのWebシステムのトレンドを振り返る
- この記事の著者
-
WINGSプロジェクト 小林 昌弘(コバヤシ マサヒロ)
< WINGSプロジェクト について> 有限会社 WINGSプロジェクト が運営する、テクニカル執筆コミュニティ(代表 ...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
-
山田 祥寛(ヤマダ ヨシヒロ)
静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるLaravel実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
