明日もデザインで食べていこう！［26］デザイナーはサーバサイドとフロントエンドとうまく会話するべきだ
── 秋葉秀樹 ──

●現場では古い考えのディレクタが意外と多く感じられた
フロントとサーバサイドへの理解度

分かりやすい例でいうとお問い合わせフォーム。「確認ボタン」が押された後、未入力がないか？　半角のところ、全角が混ざっていないか？　など行う「バリデーション」という作業が必ずといっていいほど入りますよね。

5年ほど前の多くのサイトでは、サーバーサイドのプログラムで処理をしていたように思えます。例えばPHPなどを使ったものですね。

しかしここ近年では、フロント側でバリデーションを行うことが今や多くなりました（統計は取っていません。あくまで僕の現場仕事の経験からです）。JavaScriptを使って行うので、画面遷移がいらないからユーザ側からしても瞬時にミスが分かりやすくなるのです。

状況によって、JavaScriptでHTMLを追加したり削除したり変更したりが出来るので、ユーザがフォームに何か文字を入力したタイミングで「NG」とかの文字を表示することなども可能です。

しかし、フロントばかりで処理をしてしまうとブラウザ側に色々な負担がかかりやすくなり、果てにはユーザにイライラ感をつのらせてしまいます。場合によっては、PHPなどのサーバーサイドプログラムに処理を任せた方が安定する、という考え方をいかに上手に切り分けるか？　が、ポイントになってくるケースもあるようです。

「この部分はJavaScriptで処理をするけど、ここの部分はPHPに処理をお願いしてデータを返してもらおう」と、どこでどちらのプログラムに処理をお願いするか？　を上手に設計することが、ユーザに向けてももちろん、制作現場を円滑に動かす、ひとつの重要な要素になっていることを感じています。

ちょっと前は、サーバーサイドでPHP、最近ではRubyで開発している現場に、僕がフロントエンドで入ったとき思ったことですが、いまだにサーバサイドの有利な部分とフロント側で行った方がいい部分を、最初の設計の中でしっかり切り分けていなくて、後で大変になっている現場もあるようです。

●UIに関わるデザイナーは必ず理解するべき
「イベントドリブン」という考え

これは実際、本業のエンジニアさんから出た言葉なんですが、「サーバーサイドと、フロントのイベントドリブンへの理解が出来てないプロジェクトが多すぎて、最近問題になってきている」という問題提起。

【MEMO】「イベントドリブン（イベント駆動）」とは、ユーザが何かアクションを起こすのを待機させている状態のなかで、「ユーザがボタンを押す、文字を入力する」など、ユーザのキッカケ（イベント）をもとにプログラムを処理（駆動）させることを主に言います。JavaScriptはこれが得意ですね。

プロジェクトマネージメント役が、このあたりを理解しないでプロジェクトを進めて、後で仕様変更していて大変になっている現場を最近よく目にします。「このボタンが押されたときに、処理をサーバに渡すのか？　フロントに渡すのか？」という設計はもとより、一旦フロントに渡してサーバに投げる、という方法もあり、そのへんで「出来ること、出来ないこと、やったほうがユーザフレンドリーだ」という判断は、フロントエンドとサーバーサイドのエンジニアも含めてしっかりとした「話し合い」が必要です。

●プログラマ同士だけの会話ではもはや成り立たない
Webサイトやアプリ制作事情

フロントエンドとサーバーサイド上でうまくやり取りを行うには、プログラマ同士の会話だけでは意味がありません。理由は単純で、プログラムへ処理を渡すタイミングはユーザの何らかの行動が多く、それはデザインから大きく問題が関わってきます。

デザイン（とくにWebやインターフェイスデザイン）とは、色やカタチだけではなく、ユーザによってインプットされるすべての行動の窓口を設計することを意味します。

もうひとつ付け足す言い方をすると、プログラムに処理を渡せるデザインでないと、それはデザインの役割を果たしていない、ということになります。

つまり、HTMLの構造がシステムに影響するので、Webデザイナーは、システムエンジニアや全体を設計する人としっかり会話が出来ないと「修正」が発生します。この修正は大規模なシステム開発になるほど、危険をはらむことはいうまでもありません。

●ビジュアルデザイナーももっとシステム設計に参加すべき

これはもうデザイナーとしての僕は当然と考えています。デザイナー的に「これは使いやすいし、見た目もいいぞ！」と自身を持って提案して採用されたインターフェイスデザイン。しかし、状況によって内部でどのような事が行われているか、理解しないとハマりやすいケースもあります。

たとえば、ボタンが押された時、フロントからサーバに処理を投げて、返事が戻ってくる間、そのボタンはもちろん、他のUIに対してロックをかける、つまり無効化しないといけないケースがあったりします。それがユーザに対し、「押せそう」に見えるのはNGだったりします。

さらにこのレイアウトがフロント側、あるいはサーバから帰ってきた値をもとに、どう変化していくのか、を理解する必要があるのです。

システム全体に目を通すのはとても大変ですし、量によっては無理が生じます。ですが、自分が受け持つデザインのインターフェイスの一つ一つは「どう処理されるのか」を理解しておきながらデザインを起こす必要は今後もっと増え続けていくでしょう。

【あきば・ひでき】
hidetaro7@gmail.com
< http://www.akibahideki.com/blog/
>

テクニカルディレクター・デザイナー。DTP黎明期からグラフィックデザインを学び、東京都営団地下鉄など交通広告を多数手がける。同時に音楽活動も活発に行い、西日本半全国ツアーなどを展開、某専門学校のテーマソングを作詞作曲、編曲から楽器全てを演奏してレコーディングするなど、マルチなクリエイティブ活動も。最近では東京と大阪の教育施設などで講師業をも務める。HTML CSS JavaScript Flash ActionScript 3DCG Movie DTP GraphicDesign...多種スキルを持つ。Web標準技術だけに執着せず、全てのメディアで説得力のある表現にチカラを注ぎたい、そんな仕事をしたい。