はじめに

エンジニアとデザイナーが協力してひとつのプロジェクトへ立ち向かおうとしているときに、なぜかデザイナーとの話が噛み合わないなと感じることはないでしょうか。たとえば、「部品の使いまわしを意識して作ってね」と前もってデザイナーに伝えたにもかかわらず、渡されたものには自由奔放なデザインが展開されていて苦労した、といった経験です。

筆者はUIデザイナーというデザインを提供する側の職域を担当していますが、過去を振り返ってみると、そういった場面を思い出すことが容易にできます（あのときはすまんかった……）。

この記事は、デザイナーとの協業で話が噛み合わないと感じたことがあるエンジニア向けの記事です。

普段デザイナーが画面を作るときに、どんな視点から情報を観察して、それらをどのように画面上に組み立てていっているのかを知ることで、「なるほど、だから噛み合わないことがあるのか」と単に納得するのに役立つかもしれません。

あるいは、次に噛み合わない場面が発生したときには、デザイナーが見ている視点の違いを理解した上で、相手側の視点にも歩み寄り、同時にエンジニア側の視点にも理解を示してもらうこともできるかもしれません。

この記事は、そのように、お互いに歩み寄れるような協業が達成されることを望んで書いたものです。

対話が噛み合わないことの根底には、互いが「何を大事にしているのか」や「どんなゴールを目指しているのか」が見えにくいという問題があるように思います。

それらを事前に知っておくと「なぜ自分の要望を受け入れてくれないのか」「なぜ相手からそんな提案が出てくるのか」が理解できるようになり、結果として相手の視点を許容できたり、ある部分で譲歩してみようと思える瞬間が出てきます。さらに、自分の観点だけでなく相手の観点も取り込んで、より良い落としどころを提案できるようにもなるはずです。

そうしてお互いが納得できる形で意見をすり合わせられると、ただの「デザインの擦り合わせ」や「実装の妥協」ではなく、ひとつのプロジェクトを一緒に作り上げているという実感が持てるでしょう。結果として、デザイナーとエンジニアがお互いの知見を活かし合い、協業をより良いものへ発展させることに繋がりそうです。それが本記事の狙いでもあります。

情報を取り巻く4つの観点

そもそも、なぜデザイナーと実装担当者の間で話が噛み合わないのでしょうか？

ひとつのものを作るにあたり、専門領域が異なるから分業しているだけで、「デザイン」と「実装」を意図的に噛み合わないようにしようとしているはずはありません。

筆者は、このズレが生じる原因が、デザイナーとエンジニアがそれぞれの専門領域で「重要視している対象」が異なっているためだと考えています。

では、両者がそれぞれ重要視しているものとは一体何なのでしょうか。これを紐解くために、まずはアプリケーションで扱うデータや情報が、どのような観点で整理されるのかを、次の「4つのモデルの分類」として示してみました。

• データモデル、実装モデル
• レスポンス用の表現モデル
• 表示用の表現モデル
• メンタルモデル

これらは、アプリケーションが扱う情報を、特定の視点に基づいて抽象化したものです。メンタルモデル側に近づけば、より人間的な視点でもって情報を取り扱う必要があります。逆にデータモデル側に近づけば、より機械的で厳密なものとなります。

これらのモデルは取り扱う情報の特性に合わせて、特定のモデルでしか取り扱わないというわけではなく、ひとつの情報を各モデルの視点から見ることができます。

次項で各モデルそれぞれを簡単に解説します。

データモデル・実装モデル：機械的

アプリケーションを内部構造から見つめる視点です。たとえばデータベースのスキーマやプログラムのクラス設計など、「機械的・厳密にデータを管理する」ことが最優先されます。ここでは重複や矛盾のない情報の扱い方が求められ、大規模化した際の拡張性も考慮して設計されます。

レスポンス用の表現モデル：やや機械的

サーバーとクライアント間のデータ受け渡しを効率よく実現するための視点です。たとえばJSONやXMLといったフォーマットに、アプリケーションが扱いやすいよう変換するのが主な役割となります。ここでは通信量やパースのしやすさ、拡張性などが重要視され、返却されるデータ構造を適切に設計することがポイントとなります。

表示用の表現モデル：やや人間的

画面やUI上で情報を「どのような見た目で」「どのように配置するか」を考える視点です。フォントサイズや色、配置、余白などデザイン上の要素が重視され、ユーザーがストレスなく情報を読み取れるかが焦点となります。

メンタルモデル：人間的

最も人間寄りの視点であり、ユーザーが「その情報をどう理解し、どんな意味や価値を見出しているのか」を探究します。利用者それぞれのタスクや心理的な背景を踏まえ、自然でわかりやすい使い方を提案することが目的です。

機械的な視点と人間的な視点

前節で解説した4つのモデルは、さらに機械的な視点と人間的な視点の2つに大きく分けて考えることができます。

たとえば「ユーザー名」という情報を例に挙げながら、それぞれの視点の違いを見ていきましょう。

機械に寄り添った視点

まず「データモデル・実装モデル」の観点では、ユーザー名は各ユーザーに紐づいた文字列情報として厳密に取り扱われます。データベースへ格納され、user_nameといったカラム名や、バックエンド側の変数・クラスプロパティとして定義されるイメージです。データの重複や矛盾を排除するためにデータベースのスキーマを整え、拡張性や保守性を意識しながら実装されます。

次に「レスポンス用の表現モデル」の観点に移ると、先ほどのデータベースに保存されているユーザー名を、クライアント（ブラウザ側のアプリケーション）が扱いやすい形式に変換する必要が出てきます。たとえばJSONフォーマットで{"userName":"Taro"}のように返すことで、クライアント側では受け取ったデータをそのまま画面に反映させやすくなります。この段階では、通信量やレスポンス速度、また拡張性といった要素が意識されます。

概ねここまでが機械に寄り添った視点と言って良いでしょう。情報を正確にやり取りし、重複や矛盾をなくすためにデータベースの設計やAPIのフォーマットを整え、プログラム内で扱いやすい形式へ変換していくプロセスが、エンジニアの主たる関心ごととなります。

ユーザー名のような単純な情報であっても、大規模化や運用を考慮して、拡張性や保守性を担保しながら整然と管理することが、エンジニアとして重視されるポイントと言えるでしょう。

人間に寄り添った視点

続いて「表示用の表現モデル」では、画面上でユーザー名をどのように表示するかが課題となります。文字サイズやフォント選定、配置のバランスなどが重要視され、全体のレイアウトや各種ガイドラインとの整合性も考慮しながらデザインされます。ユーザーが素早く情報を認識できるように大きめのサイズで配置したり、プロフィール画像やステータスと並べて表示したりといった、人間側の視点から最適化を図ります。

最後に「メンタルモデル」の観点では、ユーザーがその名前をどのような意味合いで使い、どう認識しているのかに焦点が当たります。SNSであれば本名ではなくニックネームを設定することで、プライバシーやオンライン上でのアイデンティティを守る場合もありますし、サービスによっては実名登録が求められることもあります。「自分の呼び名」や「他者にどう呼ばれたいか」といった、ユーザー自身の心理や目的、利用シーンに寄り添った判断がされます。

この2つが人間に寄り添った視点と言えます。デザイナーの立場から見ると、ユーザーが画面をどのように見て、どう感じるか、そしてどんな心理的・状況的背景のもとで操作するのかを第一に考えながら設計・調整を行うのが大きなポイントになります。それは、視覚的なレイアウトや操作のしやすさだけでなく、ユーザーの多様な行動パターンや感情を想定し、その体験をより豊かにするための工夫が求められる作業であり、こうした点が、人間に寄り添った視点の特徴と言えるでしょう。

まとめ：会話が噛み合わない原因

このように、ひとつの「ユーザー名」という情報であっても、どの視点で扱うかによって人間寄りの視点から機械寄りの視点まで大きく変化していきます。機械側の視点では、情報の重複や矛盾を排除し、汎用性が高く厳密に扱えるようにすることが優先されます。

一方、人間側の視点に近づくにつれ、情報は利用者の行うタスクや状況に合わせて柔軟に形を変え、ユーザーが対峙している場面に最適化しようとします。

デザイナーが目指すのは、一人ひとりの利用者が抱える目的や手順に合わせて、最適な導線やアプローチを個別的にオーダーメイドで設計することです。

一方で、エンジニアは汎用的に情報を扱えるように整合性や拡張性を重視します。つまり、同じ情報であっても、機械の視点では重複なく厳密に管理できる形式が求められる一方、人間の視点では個々の状況に溶け込む使いやすさが優先されるわけです。

こうした「何を重視しているか」の違いこそが、デザイナーとエンジニアが同じ情報を見ながら対話していても、そこにズレを発生させる原因だと筆者は考えています。

次回は、デザイナーを理解するために、デザイナーの視点をより具体的に探ります。また、エンジニアとデザイナーがすれ違いを起こさないために、エンジニアがデザイナーにどのような働きかけができるか考えてみましょう。