この記事の概要
2023 年 12 月 16 日に次世代 Web カンファレンス 2023 の Design Technology のセッションでスピーカーを務めました。
そこで話したことや、話そうかと思っていたけど話しきれなかったことを記事にします。
延長戦まで話した後に記載しているので、リアルタイムに話していたことから少し変わっている可能性もありますが、ご了承ください。
なお、他の方の意見を私が勝手にまとめると真意からズレてしまうかもしれないので、ちょっとした引用程度に留めています。
デザインとテクノロジーにおいてどういう関わり方をしているのか？
出自は UI デザイナーです。
最初はモックアップを作るのがメインでしたが、段々とコードも書くようになって、今では両方を行ったり来たりしていると思います。
とは言え、重心はデザインにあるつもりで「デザイナーにしてはテクノロジーに詳しい人」くらいの自認だったりもします。
Design Technology というジャンルは何なのか？
一体何なんでしょうね？
定義らしい定義は分かりませんし、あまり細かく決めようとも思っていません。
このセッションのお誘いいただいたときも「自分はデザインテクノロジストなのか？」という疑問が浮かびました。
そこで改めて世の中の事例を見たら「結構デザインテクノロジストかもしれない」という感想になり、今後名乗っても良いかもしれないな、なんて思っています笑
デザインとテクノロジーは非常に近い領域ですが、確実に溝は存在しています。
その溝を埋めるとプロダクト開発が良く進むと思っていて、こういった心意気そのものがデザインテクノロジストをデザインテクノロジストたらしめるのかもしれません。
デザインという言葉の使い方
私はデザイナーではありますが、普段あまり「デザインを作る」のような用法をしません。
インターネットのあちこちで議論されている現状が示すように、デザインの定義を一意に定めるのは難しいのです。
「ウチのチームにおけるデザイン」とか「このプロジェクトにおけるデザイン」を決めるのが現実的なラインでしょうか。
私はデザインという言葉を使う代わりに、普段はこういう言い回しをします。
- トップページのビジュアルを作ります
- モックアップを作成したので確認してください
- エンティティのアトリビュートに漏れがありそうですね
- データ構造と UI を対応させるとこんな感じになりそうなんですが
要は「デザイン」という言葉では「どこからどこまでを考えて、どこからどこまでを作るのか」を明示できないのです。
「デザインをする」という言葉だけでは、実質何も言っていないのと同じようなものです。
職能の切り分け方、組織運営
人事制度において、職能を分けて、それぞれに役割や給与テーブルを設定して……というやり方が一般的です。
素早く一定の水準で評価できるというメリットもある一方で、名前の無い / つけづらい領域の人を評価できなくなるなどのデメリットもあります。
デザインでもエンジニアリングでも、対象に名前をつけるという行為は非常に重要です。
また、名付ける側が対象を細かく弁別するだけの価値を感じていない場合、大きな括りの名付けしかできません。
（草花に興味のない人は道端に生えている草をまとめて「雑草」と呼ぶ、みたいな話）
デザインテクノロジストが活躍する場を作るとしたら、ボトムアップで頑張るのも大事ですが、人事制度に手を加えられるくらいの上位レイヤーの人の協力も欠かせないと思います。
こういった組織全般の話は延長戦でも非常に盛り上がりました。
話しすぎて、何をどう話したかとか、記憶が朧げです……笑
「デザイナーはエンジニアリングもするべき」とは言われるけど「エンジニアはデザインもするべき」とはあまり言われないのではないか？
ここでも「デザイン」の表現では話が広がりすぎるので「エンジニアはグラフィックや UI もするべき」と言い換えます。
極端な対比ですが、以下の 2 つのものがあったとき、選ばれるのは後者です。
- 見た目は良いが動かない、使えない
- 見た目はダサいが、ちゃんと使える
デザイナーだけの組織では、実際に使えるアプリケーションを作るのはほぼ無理でしょう。
エンジニアだけの組織では、仮に見た目がイマイチであっても、ちゃんと動くものを作れると思います。
言い換えれば、エンジニアはエンジニアリングだけをしていても価値があり、デザイナーはグラフィックや UI だけをしていては価値がないのです。
（もちろんこれは分かりやすく表現するための極端な言い方であり、私自身はデザイナーの意義や価値を信じています。）
余談
このテーマは、ちょうどデザインという言葉の使い方を補足できそうなので例示します。
「見た目はダサいが、ちゃんと使える」状態において、その状態を狙ってやっている（PoC の時期など）であれば、それはそれで良いデザインと言えるでしょう。
設計・計画の通りに成果物のクオリティコントロールをして、狙ったアウトカムを出していると言えそうだからです。
一方で「細部までプロダクトの意匠にこだわる」といったビジョンを掲げている組織が「見た目はダサいが、ちゃんと使える」を作っていたら、それは良くないデザインだと思います。
見た目の良し悪しというより、意図したアウトプットが実現できていないという点で「デザイン」として失敗している感があります。
このように、デザインという言葉を使うと毎回「その話のスコープはどこからどこまで？文脈は？」となってしまいます。
ラベルが大切なのではなく、プロダクトを早く良く作るという気持ちが大切
延長戦での内容も多分に含みます。
今回はデザインとテクノロジーを結びつけるような話ですが、結局は「何をしてでもプロダクト良くする」という気持ちがあるか無いかの話です。
開発職にとってはデザインとエンジニアリングが分かりやすい領域なだけで、セールスでもマーケティングでもサポートでも「自分がやって価値あることは全部やる！」という気持ちを持つ人を増やしたいです。
逆に「私はデザイナーなので」「自分はエンジニアなので」と線を引く人ばかりだと、かけるコスト x と得られる成果 y の関係が a > 1 の対数関数のグラフみたいになると思います。
便利なツールが色々出てきたけど、これによって両者の溝は埋まるのか？
ツールだけでは埋まらないと思います。
「ツールを使ってできること」はかなり進化した気がする一方で、人間たちの適応が追いついていないのではないでしょうか。
変な話、ツールがなかった時代でも、スーパーデザイナーやエンジニアがいれば実現できていたと思います。
あくまでツールによってやり方が整備されたとか、簡単になったとかの状況です。
しかし、例えばAuto layoutを使わずにすべてを絶対配置する人とかもいるので、人間をテクノロジーに適用させるための仕組みは必要なんじゃないでしょうか。
デザインシステムの矮小化
コンポーネントライブラリのことをデザインシステムと呼んでいる気配がありますよね。
それ自体を批判する人もいますが、私はこれ自体は別に良いと思います。
むしろ「同じものを繰り返し作らないようにして、早いデリバリーを心がける」という目的なのであれば、コンポーネントライブラリを作ることを目的にした方が効果的そうです。
そしてデザインシステムをデザインシステムとして機能させたいなら、デザイン原則の方が大事だと思います。
既存の何かを否定するつもりは毛頭ありませんが、デザイン原則が「格好いいステートメント」で終わっている場合も多いと思います。
「この原則があったからこそプロダクトの重要な選択が上手くいった」と言えて、ようやく意味があると言いますか。
場合によっては「デザイン原則を考えていたら、結局会社のミッションやバリューそのものだった」という場合もあるでしょう。
それはそれで良い気づきですし、非常に良い運用ができそうですね。
コンポーネントライブラリの配布
細かい話ですが、コンポーネントライブラリにしても、npmのパッケージとして配布するのって実は無理があるのではないでしょうか。
定期的にアップデートできるとか、セキュリティ対応で急遽アップデートできるとかのチームって、そう多くはないはずです。
しかしそういうのを放置すると、結局ライブラリとして提供しているにも関わらず古いバージョンのものを使っていて、プロダクト群のルックやフィールがチグハグ……というのが起きます。
じゃあどうすれば良いんだと聞かれたら shadcn/ui みたいな仕組みはどうだろう？くらいのふんわりした答えしかないんですが……。
経営戦略とプロダクト開発の同期
更に上記から脱線して、本来は経営戦略をインプリメンテーションやデリバリーに反映させる役割が必要だと思っています。
どちらかと言えば、開発者の意見は「サービス群のブランドを統一してすべて同じ見た目や作りにしたい」だと思います。
しかし、分かりやすい極端な例として、コングロマリット企業においてこれは当てはまりません。
そこまででなくても toC と toB でルックを揃えることはあまり意味を持ちません。
これはもはやデザインテクノロジストの話なのか分かりませんが、少なくとも「開発メンバーだけでやいのやいの言っているだけでは最大効率が出せない領域だってある」ということを考えています。
紙出身のデザイナー
エンジニアサイドから出る「デザイナーが実装にそぐわないモックアップを作りがち」という話。
擁護するわけではありませんが、紙出身の人にとってはああいった作り方が真っ当というか、オンスクリーンのやり方って「手抜き」「サボり」と怒られる世界なんですよね。
A4 なら A4 という決まった矩形の中での 100 点を目指すために、手動での調整をどれだけでもやるような生き方が紙の世界です。
鉤括弧だけフォントを変えるとか、視覚調整のために段落ごとに行間を変えるとか、塗りと線で微妙に明度を変えるとか、いくらでもあります。
ただまあ、だから良いとはなりません。
Web をやるなら Web なりの考え方にシフトする必要はあります。
自分は今、会社でデザイナー組織の長をしていますが、上手くオンボーディングや育成カリキュラムに組み込む必要があるよね、と思っています。
プラットフォームの制限があると、デザイナーの思考は狭まってしまわないか？
狭まることもあるかもしれないけど、あまり心配はしていない。
制約がまったくない状況でものを作ると、無限の選択肢があって判断が鈍重になるとか、よくある話。
逆に適切な制約がある方が、その中でいかに良いものを作るか？と思考が先鋭化されて、結果クオリティが上がることも多いと思う。
テクノロジーを知っているからこそ思考が広がることってある？
例えば Reflective UI などは、テクノロジーへの造詣が深いがゆえに思い浮かび、実現されたようなものだと思います。
技術、どれだけ追いかける？
自分は面白いと思ったら追いかけています。
最新情報が手元に流れてくるようにはしていますが、全部読むかというとそうでもありません。
基本的には無理して追いかけ続ける必要もないと思います。
ただ……
コンドラチェフ波動という 50 年周期ほどの技術革新のサイクルがあります。
この、1 つの波のうちはちょっとした最適化がなされるレベルなのかな？と考えています。
逆に次の波がやってきたら、乗り遅れないためにたくさん勉強する必要はあるのかもしれません。
最近だと AI 関連は 5 つ目の波な感じがしているので、多少意識して追いかけています。
正直 AI 関連って個人的な興味としては薄いのですが、こればかりは大事かな？と思っています笑
ゼネラリストとスペシャリスト
セッション中はゼネラリストとスペシャリストという二項対立でしたが、個人的にはあまりそういう見方自体していません。
スペシャリストがたくさん集まって最終的にゼネラルに考えて進められるチームも素敵ですし、全員ゼネラリストだからこそ半端じゃないオーナーシップを持てるチームも素敵です。
世の中的に、もしくは会社的に評価されやすい進み方はあると思いますが、そういうのを考えるとつまらなくなってくるので、やめています。
UI を作るにあたって
デザインシステムに関連するようなしないような、の話。
多くのデザイナーは表層、骨格、構造を密結合に考えている気がします。
これらはもっと上手く分離できる気がしていて、それが叶えば表層はデザイントークンを入れ替えるだけで大きく変化させられます。
また、Figma データにせよ、API のレスポンスにせよ、json を感じながらモノを作りましょうという話もよくします。
これも、現行サービスにおいて、どこは変えられてどこは変えづらいのか、裏側にあるデータ構造を理解することで勘所が掴めるからです。
スピーカー同士の雑談で出た内容として意外だったのは、バックエンドエンジニアも API を作るにあたって、どんな情報がどう UI として可視化されるか、あまり意識できていないかもということでした。
であれば、最初からそこを意識するだけでも使いやすく分かりやすい UI を構築しやすい可能性はあります。
どのレベル感の人がそうなのかとか、詳しいことまでは分かりませんが、お互いの共通言語として json を使うのはもしかしてアリなのか……？なんて思っています。