UIデザインにおけるインターフェイスアーキテクトの役割
アーキテクチャ（Architecture）とは一般には建築や建築学を指しますが、コンピューターの世界ではあるシステムの概念や設計思想を「アーキテクチャ」という言葉で分類することがあります。中でもソフトウェアの領域では実装モデルの設計指針や分類、コンポーネントの相互関係、ソフトウェアの構築方法などを定めた一連の構造をそう呼ぶことがあります。
アーキテクト（Architect）とは建築家や（建築）設計士、技術者といった職種を指しますが、コンピューターの世界では「アーキテクト（仕組士）: システムのアーキテクチャを設計する責任がある、人、チーム、あるいは組織」（IEEE 1471）と規定されます。要するに、システムの構造設計に関して責任を持つ役割です。「構造設計の指針を示し、実行する人」と言った方がわかりやすいでしょうか。
このような、構造設計やそれを担う設計士の役割は、当然のようにUIデザインの世界でも求められています。
目次
インターフェイスアーキテクトの役割
ソフトウェア設計の世界には、ITアーキテクト、ソフトウェアアーキテクト、情報アーキテクト（インフォメーションアーキテクト）と呼ばれる職種がすでに存在します。いずれも何かしらの「設計」に関して責任を持つ職種です。
Goodpatchでは、UIデザイナーの役割の一つとして独自に「インターフェイスアーキテクト」を置いています。
【インターフェイスアーキテクト】 Interface Architect
GUIの構造や設計パターン、システムの仕組みに精通しており、アーキテクチャの設計に責任を持つ「UIデザイナー」の一種。GUIに関する概念・設計思想の定義、ドメイン設計、情報アーキテクチャ、UIモデリング、インタラクション設計を中心に、ソフトウェアの“拡張性”を考慮しながらデザインに取り組む。
インターフェイスアーキテクトは分類上は UIデザイナー です。ただし、インターフェイスアーキテクトは一般に知られる「UIデザイナー」とは少し異なる領域を担当します。
UIデザインの構造段階
インターフェイスアーキテクトの役割を説明するためには、有名なJJGの「5段階モデル」を参照するのが良さそうです。ここまで〈構造〉という言葉が何度か登場しましたが、5段階モデルにも構造段階が存在します。
この図はオリジナルの “The Elements of User Experience” とは少し異なる解釈をしていることに留意してください。「Webにおける二つの側面」という視野だけでは本質的なソフトウェアデザインを俯瞰できなくなるため、より抽象化してあります。
これらの段階のうち、構造から表層にかけてがいわゆるUIデザインの領域です。その下の部分、戦略から要件にかけてがいわゆるサービスデザインの領域だろうと考えられます。今回着目するのはUIデザインの領域です。
構造、骨格、表層、それぞれに代表的な役割を当てはめてみると次のようになります。
- 構造：情報設計、モデリングなど、アーキテクチャの設計
- 骨格：ワイヤーフレーム設計、レイアウト設計、状態遷移など、構造を具現化するための骨組みの設計
- 表層：アイコン、タイポグラフィ、色、サウンド、モーションなど、人間の視聴覚に直接関わる設計
UIデザインというとどうしても〈表層〉に寄ったデザインと捉えられがちです。「UIデザイナーは、アイコンやグラフィックス、色、タイポグラフィを整える人」だというのがおそらく世間一般の認識でしょう。ある意味で正しいのですが、しかしこれだけでは「UIの見た目にしか責任を持たない人」となってしまい、その下の段階を担う役割が不在になってしまいます。私たちは〈骨格〉〈構造〉まで含めた範囲が本来のUIデザインの領域で、3つの段階すべてがUIデザイナーの役割であると考えています。
UIデザイナーの役割は、〈構造〉〈骨格〉〈表層〉段階の設計である
これまでの経験から、多くの現場ではこの〈構造〉段階があまり認知されておらず、具体的なデザインの役割が不明瞭で重視されていないか、まったく考慮されていないように感じられることがあります。仮にこの〈構造〉が抜け落ちてしまうと、要件定義からいきなりワイヤーフレームを描く ようなことになります。経験豊富なデザイナーであるならこの技は効果的にはたらくこともあるでしょうが、ほとんどの場面では「画面を描きながら情報構造とレイアウトと画面の状態遷移と色とタイポグラフィを同時に考えなければならない」なんてことになってしまいます。とても効率的とは言えませんし、もしも要件に修正が入って手戻りが発生したとすると、〈骨格〉や〈表層〉の成果をすべて捨てて〈要件〉の段階まで一気に戻らなければなりません。せっかくビジュアル作ったのに……！！
〈構造〉が抜けることで、以降の設計作業が非効率になる、手戻りが発生した場合の巻き戻しが大きすぎ、余計にコストがかかる。戻るにせよ、どこまで戻って良いのかもはっきりしないため、迷いが生じやすくなってしまう。アーキテクチャが定義されないので設計そのものが成り立たず、インタラクティブに作用するUIの設計ではなくただの“お絵かき”になってしまう——。このような〈構造〉を重視しないデザインの進め方にはリスクがあると言えます。
私たちは数多くのデザインの現場に携わってきた経験から、「UIとは表層だけではなく、その基礎設計が大切であること」「構造からデザインしなければ成り立たないこと」「設計の手戻りを想定しながらプロトタイピングの連鎖を回す」というプロセス上の解を導き出しました。インターフェイスアーキテクトの役割は、UIデザインにおける〈構造〉段階を中心にデザインと向き合う、UIにおける基礎設計を担う立場であって、この役割はソフトウェアデザイン業務では不可欠な存在だと考えています。
UIデザインの二面性
私たちは、エンジニアリングがそうであるようにUIデザインにも二面性があると考えています。あえて言うならば、〈フロントサイドUIデザイン〉と〈バックサイドUIデザイン〉です。実際にそのような肩書きを採用しているわけではありませんが、役割の捉え方としてはしっくりくるかと思います。ソフトウェアエンジニアリングの世界ではバックエンドエンジニアがフロントエンドエンジニアを兼務することも稀にありますが、一般には両者は分かれています。なぜなら両領域はあまりにも広すぎるし、考え方や技術の性質、トレンドも大きく異なるからで、専門職を立てて分担・分業するには表裏分けた方が効率的だからです。区別されていた方が専門のエンジニア人材も確保しやすいことでしょう。
同様にUIデザインの領域も「あまりにも広すぎる」のが実際のところですが、世間の認識ではまだ一つの括りで捉えられることの方が多いように感じられます。個人の能力差や作業効率等を考えても、フルスタックにUIデザインのすべてを担える人材はそう多くはないのが現実ですし、プロジェクトが大きくなればなるほど作業の分担が必要になり、必然的に表側と裏側の役割を区別する必要性が生じます。
表側のビジュアルデザイナーに対し、裏側のインターフェイスアーキテクトという表裏一体の組み合わせにより、高品質かつ効率的なUIデザインというものと向き合う準備が整います。
もう一つの背景
現代は “VUCA” の世界と言われます。あらゆるものが複雑で不確実、そして将来どうなるのかその予想がとても難しい世の中です。ITの世界を支配しているプラットフォーマーは毎年のように新しいOSやデバイスを発表し、数年前の技術を置き換えます。去年のトレンドが今年には完全に下火になっていたり、突然の破壊的変化によって既存の常識がすべてひっくり返り、業界丸ごと消えてしまうなんてことも普通にあるわけです。政治、経済、世界情勢、イノベーション、あらゆるものの変動が激しく、それらが単一の領域で起こっているわけでもなく、どこで何がどうなるのか誰にも予測がつかない、そんな世界に私たちは生きています。
一人の人間としては、その変化に闇雲に抗ってもきっと仕方がなく、きちんと対応し得る拡張性と柔軟性を持ち合わせることが “VUCA” の世で求められるスタンスなのだろうと思います。ソフトウェアデザイン、UIデザインという領域ももちろん例外ではなく、デザインもきちんと拡張性を考慮する、環境変化に柔軟に対応する、制作作業は手戻り前提で取り組むといったことが、この世で生き残る術なのでしょう。
不確実性が高いわけですから、ソフトウェアの要件定義をしたら何がなんでもそれを線形に作り上げるのではなく、「手戻り」することを想定して堂々と巻き戻す柔軟性を身につけておくことが大切です。将来を見据えて拡張性を考慮しておくことも必要です。そしてその価値観を受け入れるチームの存在が不可欠でしょう。
Goodpatchでは、失敗を称賛はしませんがいきなり否定することもありません。誰もが失敗するのは当たり前ですし、早く、小さく失敗して「次は間違わないようにする」のが大切だという価値観を持ってデザインに取り組んでいます。
失敗とは、それはある意味で大きな価値なのです。「失敗の知見を得た」と考えれば、それは成功者や未経験者は知らない ナレッジ となるわけです。もしかしたら同じような問題に直面している他のチームの助けとなることもあるでしょう。ロケットの打ち上げにたまたま成功し続けているよりも、一度の打ち上げ失敗事故により潜在的なバグが早く明らかになった方が中長期的には良いと考えることです。
このような、失敗した事例、もちろん成功した事例も含め、メンバー各々がナレッジとして蓄え、次に活かす取り組みを組織全体で推奨しています。
ソフトウェアデザインの対象
GoodpatchではUIデザインもソフトウェアエンジニアリングもまとめて「ソフトウェアデザイン」だと考えています。ソフトウェアという人類史上もっとも複雑な対象の一つをデザインするのだ、という使命は、この領域に関わるすべての人々に共通することなのです。
ソフトウェアデザインの対象は大きく3つのモデルで区別できます。〈実装モデル〉〈脳内モデル〉そして〈表現モデル〉です。
実装モデルはシステムの仕組みに関する構造です。エンジニアリングやそれに関わるデザインはここに当てはまるでしょう。
脳内モデルは人間の心理に関わる構造です。UXやインタラクションデザインにおけるユーザーのメンタルモデルはここに当てはまるでしょう。
表現モデルは二つのモデルに挟まれる形で存在している構造です。すなわち、ユーザーインターフェイス（UI）です。UIはシステムの仕組みをそのまま映し出すことはそうありません。もしそのようなUIがあるとしたら、それはきっとモーダルでとても「使いづらい」ものとなっていることでしょう。UIデザイナーの役割は、ユーザーがソフトウェアの扱い方を理解できるように彼の脳内モデルにうまく投影できるような表現をデザインしてあげることなのです。
GUIの歴史を振り返ってみると、それは本来ソフトウェアの一部であることは明白です。UIデザインを「画面コンセプトの描画」ではなくきちんとソフトウェアデザインとして捉え直す視点が必要です。ソフトウェアデザインはコンピューターの世界にははじめからあったひとつの概念で、UXだとか言われるようになった現代においてもそれはきっと不変であることでしょう。だからこそ、この領域でインターフェイスアーキテクトという役割が大きな価値を発揮するだろうと考えています。
ソフトウェアデザインにおけるインターフェイスアーキテクトの提供価値
インターフェイスアーキテクトの人々がソフトウェアデザインにどう関わるのか、具体的な進め方としてはまずUIにおけるアーキテクチャの設計思想を定めること、次にモデリングを行うことが挙げられます。そしてそれらをUIとして成り立たせるためのインタラクション設計を行うところまでが主な担当領域となります。
（今回はそれぞれの工程の簡単なご紹介にとどめ、具体的な進め方については改めて別の記事でご紹介する予定です。）
設計思想
設計思想は、そのプロダクトをどのようにして成り立たせるのか、ユーザーがどう対話するのか、ユーザーがどのように感じられるのかなどを言葉によって明文化したものです。デザイン言語とも呼ばれることがあります。よく知られるデザイン原則やユーザビリティ原則であったり、デザインガイドラインで示されるデザイン原則を参照しながら、デザインの対象となるものの在り方であったり、そのプロダクトの世界の秩序を保つための設計思想を示します。特にUIに関わる分野の設計思想を中心に構築していきます。
例えば写真コンテンツを多く扱うメディア系アプリケーションを作ろうとするのであれば、UIのビジュアルを控えめにしてコンテンツ主体の設計にするとか、写真が映えるレイアウトを検討するとか、解像度は高い方が良いが読み込み速度とトレードオフ関係になりやすいため、そこをインタラクションでどう解決するのかとか、そういったことを挙げてゆきます。そしてこれら中から本質を指し示すであろうキーワードを抽出し、UIデザインの基本指針をわかりやすい言葉でまとめあげます。
設計思想を定めておくことで、後の工程においてデザインの道標として機能するようになり、少なくとも道は踏み外さないようになるでしょう。デザインの意図を説明する理由としても有効にはたらきますし、デザインの評価を行う際の観点にもなり得ます。
モデリング
モデリングにはいくつかの工程があります。現場によって様々だとは思いますが、Goodpatchのクライアントワークでの代表的なモデリング工程は次のような具合です。
- プロダクトを取り巻く環境の調査と分析
- プロダクトで扱う/現れる概念の定義
- 概念に基づくコンテンツ設計
- 概念に基づくUIの構造設計
- UIのナビゲーション設計
調査と分析
モデリングに取り組むにあたってまずは対象となるプロダクトや取り巻く環境などの調査を行います。すでに形があるプロダクトであれば、まずはそれに触れてみてUIの様相だとか振る舞い方などをよく観察し、課題を洗い出します。ときにはユーザーとデザイナー二つの人格を持つようにし、ユーザーとしてもプロダクトに触れるように心がけます。一方でエキスパートレビューの要領で課題を分析することもあります。そして、形あるUIから裏側のモデルをイメージして描き出す「リバースモデリング」と呼ばれる独自の手法により、そのUIのオブジェクトモデルを描画してから、モデルのどこに課題があるのか、どこに拡張性を持たせられるのかといった検討を行います。
ゼロイチの制作では対象のリバースモデリングは行いませんが、参考にする他のプロダクトをリバースモデリング作業にかけて検討材料にすることがあります。
そのほか、構造段階の前の要件定義をインプットとして取り入れたり、さまざまな環境制約というものをこの段階でも整理しておきます。時には要件の修正を提案することもあります。
これらの分析は以後の作業工程で検討材料として有効活用されます。
概念定義
UIデザインの初期の段階ではまず、ユーザーが触れるUIにはどのような概念が現れるのか、ユーザーや触れる対象となるオブジェクトはどのように存在しているのかをモデル上で明らかにします。その世界そのものの概念から形作ってゆき、次第に具体に着目していくやり方が基本となります。システムの機能やUIの具体的な挙動——形状、触れた時の状態変化、アニメーションの仕方など——を考える作業はずっと後の工程になるでしょう。
概念定義で大切なのは、どのようなドメインがあるのかに着目することです。ドメインとは関わるオブジェクト（ヒトや操作対象物など）の関心事や影響を及ぼす範囲、活動領域、一種の環境だと考えてもらえれば何となく意味は伝わるでしょうか。そこに概念があることはわかっていても、具体的な形として表さない限りは直接触れることができませんから、そのためにもまずは概念をある種のモデルとして表す必要があります。
このようにして「概念モデル」を形作ってゆき、今後行われるであろう全ての作業工程の礎とします。
概念モデルはクラス図記法で描かれることが多く、概念同士の関連性や多重度といった数属性を明らかにします。
概念定義の段階では同時に概念への命名と共通言語を定義する作業も行います。ドメイン駆動設計（DDD）でいうユビキタス言語の醸成、IAでいうところの制限語彙の制定と普及に相当します。ある概念がドメインに現れたならば、それを唯一の呼び名で定め（あるいは別の呼び方を紐づける）、関わる人々全員の共通認識として定着させることを目指します。そこにはデザイナー、エンジニア、ディレクター等役割・職種の違いはありません。関わる全員が共通言語で会話する意識を持つことが大切です。この頃に行われる会議ではきっと『（概念図を見ながら）この部分を○○と呼びましょうかね』なんて会話が行われていることでしょう。
UIの組み立て
概念モデルからUIとして成り立たせるために必要な制約事項を把握します。少なくとも概念の名前、関連、数属性は示せていますから、これらはUIのビュー表現においてどのように作用するのかは、この時点でもすでに見え始めています。例えば、ある概念に着目した際に関連する先の別概念の多重度が 0..n だとしたら、UI上でも「0個＝空表示」と「n個＝一覧表示」が検討できます。
このように具体的なUIのイメージを描かずとも、概念モデルを使えばUI表現の制約を示すことができます。
インタラクション設計
インタラクションデザインとは本来はもっと広い領域におけるデザインの営みです。ヒトとオブジェクトがインターフェイスを介して互いに対話している環境をデザインするのがすなわちインタラクションデザインであると考えられます。そこにUIがあるということはインタラクションが起こり得るということですから、このことはあらゆるレイヤーで考える必要があります。
UIモデリングに続く作業ではよりインタラクションの範囲を絞り、あるドメインの中に現れるであろうオブジェクトとユーザーの対話方法を探ります。オブジェクトがただ存在するだけではUIに触れても何も起きませんから、それらに触れる方法というものを具体的に検討するのです。
プラットフォームやデバイスのフォームファクターなどによる制約や基幹技術を考慮しながら、具体的なUIの形を見据えたインタラクションの方法を検討します。対象がPCであればマウスやキーボードを中心とした操作、スマートフォンであればタッチを中心とした操作を起点としてその入力方法が検討できますし、同時に表示方法も考えることができます。このようにして最小単位から次第にルールを組み合わせていって、インターフェイス固有の／よく知られた表現「イディオム」を構築してゆきます。そのためにも、デザイナーは対象となるソフトウェアの基本的な仕組みや操作方法をよく理解しておく必要があります。ここの設計を間違えると、たとえ“正しいモデル図”を描けていたとしてもなんだかとても使いにくいUIに仕上がってしまうことがあります。
イディオムを構築する際には、それらを支える下の層にもプラットフォーム固有のイディオムが存在している事実を考慮することも重要です。もしもネイティブアプリケーションを設計するのであれば、まずはOSやプラットフォームが定義するイディオムを踏襲するところから考えなければなりませんし、対象ドメインが「日本語話者」ということであるならば、日本の文化をバックグラウンドに持つすべての人々のコンテクストを考える必要があります。
UIデザインのアーキテクチャを設計する
インターフェイスアーキテクトの役割としては、「UIデザインのアーキテクチャを設計する」とまとめられます。
具体的には…
- デザインの設計思想を明らかにし、デザインの道標を示す
- UIに関わる概念やドメインを明らかにする
- UIの構造をモデリングする
- UIに関わるさまざまな技術を検討しながら、インタラクションの方法を設計する
さらに詳しくそれぞれの工程で何をするのかについては、また改めてお話ししたいと思います。
おわりに
Goodpatchのクライアントワークでは概念モデルを描くデザイナー、拡張性を意識した設計をするデザイナー、オブジェクト指向的発想で構造設計を実践するデザイナーが活躍しています。その領域を専門的に担うメンバーもいれば、あるプロジェクトではビジュアル領域、別のプロジェクトではアーキテクチャ領域という具合に、柔軟に役割を切り替えながら実践しているメンバーも在籍しています。このようなチームでデザインに向き合う体制があることはGoodpatchの明確な強みであると確信しています。
もしお困りの案件がございましたら、クライアントワークとしてお受けできるものはぜひこちらのフォームからご依頼ください。そのほか、御社のプロダクトが抱えるデザインの課題分析・フィードバック、UIデザインの分野に関するワークショップや登壇のご依頼なども随時受け付けておりますので、お気軽にお問い合わせください。インターフェイスアーキテクチャからビジュアル、UX、エンジニアリング、そのほかさまざまな領域でご対応いたします。
また、Goodpatchではインターフェイスアーキテクチャをはじめ、UIデザインに関わるさまざまな領域で活躍したいデザイナーも随時募集しております。もしご興味ありましたらこちらから応募くださいませ。お待ちしております。
