SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

これまでのWebシステムの歴史とトレンド

業務Webシステムは2010年が転換期だった? HTML5以降の最適化の歴史

これまでのWebシステムの歴史とトレンド 第2回

最適化のメリットとデメリット

 現在のWebシステムは、サーバサイド技術とフロントエンド技術のどちらか一方だけで実現することはないでしょう。また、先ほどは双方が代替可能ではないと述べましたが、利用シーンを限定すればもちろん代替は可能です。そして、その場合はそれぞれのメリット、デメリットが混在することになります。

 先ほどのNext.jsの例のように、あるプログラムに複数の役割が混在していれば、同じ人の作業範囲は自ずと広がっていきます。このような状況は、役割ごとに作業を分担している場合にはデメリットになります。

 例えば、文言だけを変更したい場合や、文字色や背景色だけを変えたいとき、デザイナーがその部分だけ対応することが難しくなります。さすがに、文言を変更するためだけに、JavaScriptやTypeScriptを勉強し、それらの開発環境を用意しなければならないというのは大げさでしょう。

 もちろん、こういった問題はフロントエンド技術が普及する前からありました。しかし、テンプレート技術などによってコードを分離することで、問題はそれなりに軽減されていたのです。よって、先ほどの「HTML上の文言を変えたい」というレベルであれば、解決のための仕組みを作ることは可能です。

 しかし、実際の現場では、ほんの少しだけ処理を変えたいとなっても、役割ごとに厳密に区切られたルールがそれを許さない場合があります。

 例えば「画面上に現在時刻を表示したい」といった要望があり、作業する人が簡単なJavaScript程度なら対応できるとしても、テンプレート技術でJavaScriptの記述ができない、もしくは、特別な別の知識を要するということがあります。このように、ルールの厳格化により、あらかじめ予定された変更でしか対応できないなど、柔軟性が低くなってしまうことがよくあるのです。

 こういった最適化手法は技術だけではなく、組織構造にも影響を及ぼします。

 例えば、先ほどのHTMLやCSSの対応例で言えば、画面側のプログラムを作る人が、マーケター、デザイナー双方の役割を兼務していれば、何も問題が生じません。自分で考え、自分で作業ができるため、むしろ効率的とも言えます。

 しかし、日本におけるIT開発の多くは、プロジェクトチーム自体が仕組み型効率化(=組織の効率化)を前提に構成されます。つまり、組織が職種という役割に最適化されているため、エンジニア兼マーケティング兼デザイナーを担う人はあまりいません。

 そうなると、大きな枠組みとしては、役割を中心にした最適化の方が効率がよいということになるはずです。つまり、組織構造の観点からは、フロントエンド技術を中心にした技術でさまざまなことを実現するような体制よりも、サーバサイド技術を中心にして実現する方が、組織構造による障壁は少ないと言えます。

サーバサイド技術からの延長では実現が難しいWebシステム

 ここまでは、サーバサイド技術を中心にした開発でWebシステムを作るメリットと、同様のシステムをフロントエンド技術を中心に開発した場合の懸念点を示してきました。

 しかし、現在のプロジェクトでは図6のようにサーバサイド側の機能はクラウドなどに置き換えられ、一方でクライアント側で求められる機能は肥大化しつつあります。つまり、サーバサイド技術でできるが、フロントエンド技術で対応するといったことではなく、フロントエンド技術が必須となるシーンが増えてきています。

図6:求める機能の変化による変わる生産性
図6:求める機能の変化による変わる生産性

 その結果として生まれた変化を私たちは日常でも多く目にするようになりました。

 例えば、図7や図8のようなエディタ機能を持つソフトウェアです。これはサーバサイド技術の延長線にある技術では、実現が極めて難しいタイプのアプリケーションです。

図7:Web版のPhotoshop画面の一例
図7:Web版のAdobe Photoshop画面の一例
図8:Google Documentの画面一例
図8:Googleドキュメントの画面一例

 こういったツールは、一般的には図9の構造をとります。複数の部品から構成され、それらの部品をどのようにグルーピングし、いつ、どのタイミングで表示させるかなどのコントロール権は利用者側にあります。

図9:部品中心となるアプリケーション構造の開発
図9:部品中心となるアプリケーション構造の開発

 開発者は最も小さい部品単位から作成していき、それらをグループ化し、さらにグループ化したものをもっと大きなグループ化できるような作りにしていきます。一方、それらをどのように組み合わせて表示し、また、いつどのタイミングで操作するかも含めて利用者側がコントロールします。

 このようなアプリケーションを作る言語やツールには、Reactiveを意味する用語がよく使われているように、ある部品への操作が、他の部品への影響が作用するのが一般的です。

 一方、コンシューマが利用するシステムでもECシステムなどの販売を行うシステムや、情報管理を行う業務系システムでは、画面の使い方や目的を利用者自身が決めるのではなく、あらかじめサービス提供者側、もしくは設計時に決めたルールや見せ方にそって操作していくことになります。そのため、図10のように画面定義をもとに各種機能を開発していきます。

図10:画面中心となるアプリケーション構造の開発
図10:画面中心となるアプリケーション構造の開発

 ここで上げた例は少々極端ですが、サーバサイド技術の延長線(※)ではどのようなWebシステムが苦手で、どのようなWebシステムは得意としているのかの特徴がわかれば、そのために生じるメリット、デメリットもわかりやすくなるはずです。

NOTE:サーバサイド技術の延長線とは

 「サーバサイド技術の延長線」とは、必ずしもサーバサイドで生成するHTMLやCSSだけで動作やUI/UXが決まるものではなく、そのような技術の上にJavaScriptなどでUIを拡張しているようなシステムを意味します。例えば、サーバサイドHTMLと、jQueryでのUI/UXの拡張などはそのようなシステムの典型です。

次のページ
昔のやり方に戻れない理由

この記事は参考になりましたか?

これまでの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編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/21246 2025/04/09 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー