昨年#deisui_html_radioに出たときのカンペです。 下書き供養します。
用意してたカンペ #
@8845musign のこれまで #
Webを始めたきっかけ #
中学生のときにホームページ作成を少しだけかじりました。好きな漫画のイラストを載せるサイトを作っていた黒歴史です。いまでも覚えていますが、足跡カウンターが2000くらいしか回っていませんでした。
その後ずっとしばらくWebには触れずに、再度Webを再開したのは就活がきっかけです。大学は総合大学の工業デザイン学科で学んでいて、そのままデザイナーになりたかった。でもデザイナーとしてグラフィックのスキルが絶望的に無かった。
幾つかグラフィック系の求人を受けたが撃沈。そもそも、大学時代にやっていたのが仕組みのデザインだったので、ポートフォリオを見せた瞬間にダメだったと思います。
そこで少し立ち止まり、IT系は理系/文系構わず人材を集めていたことを思い出して、Webデザイナーなら間口は広かろうということでチャンレンジして受かりました。
これまでの仕事（言える範囲で） #
デザインからプログラミング、ちょっとインフラまで、広く浅く。デザインはペライチだったりバナーだったり単発モノが少し、プログラミングは主にフロントエンドでJavaScriptを中心に書いていた。
Webに興味を持ったきっかけ #
Webに興味を持ったきっかけは、去年アクセシビリティもくもく会とCSSもくもくに出たこと。
Webの仕様を読み込むことでWebのプラットフォームとしての間口の広さがとても好きになった。
アクセシビリティは知れば知る程、自分がユーザに大して無知で有ることを思い知らされるとともい、Webがオープンであろうということがわかる例えばWordPressはパブリッシングの民主化というコンセプトがあるが、Webはもっと懐が広い、エンジニアではない人が普通にHTMLやCSS、JSを書く。誰でも書けるところが魅力的。
今の仕事（グラフィックしないデザイナーとは） #
今の会社はフロントエンドエンジニアとして応募し、CSSを全部まかせてくれと言って入りました。
ただ入った当初は、会社の規模に大してデザイナーさんが一人しか当時はおらずにあきらかにリソース不足だと感じていました。ワイヤーをアーキテクトが書き、コーディングの段階でデザインの検討をやっている状態でした。
僕はサービス開発に関わるデザイナーは開発の中心にいて欲しいと思っていて、「デザイナ雇ってくれ！」と言い続けていました。
ただ僕が要求したデザイナー像はビジュアルはもちろん戦略からしっかり考えられる人、はっきりってUI/UXデザイナー欲しいみたいな絵に書い餅のような要求だった。当然そんな都合のいい人がいるわけがなく、採用募集をかけても人は来ない。結局「じゃあお前やれよ」と言われてデザイナーになることになりました。
僕がデザイナーになってからも、元のデザイナーさんはそのままデザインを続けました。僕より速くて旨い。そんな中で僕が何をすべきか悩んだ結果、まずは一旦エンジニアが本来やるべき開発に注力するため、デザイン作業の大部分を巻き取ることに焦点をおいたのです。
今やっていることをざっと列挙すると次のようなものがあります（どれも浅く、です）。
- システム設計のMTGから顔を出して直接要件を把握すること
- ワイヤーを書くこと
- 実際のコーディングを想定してビジュアルに調整をいれること
- ツールのアップデートを行うこと（FireworksからXDに移行した） FireworksとPowerPonitで行われていた作業指示によるコミュニケーションロスをXDに一本化することで減らそうと動いています。
- ユーザビリティテストなどの検証フェーズをプロセスに組み込むこと
- ビルド環境を整えること
- デザインコンセプトを立てること
- たまにコードを見て実装上の改善点を指摘すること
- 最終的なデザイン調整をコードから行うこと
一番大きな仕事だと思っているのはデザインコンセプトを明確にする作業です。コンセプトのブレは、その後のあらゆる工程に大して影を落とします。僕はこれをたまたま実装されていたコードを読んでいて、似たようなUIに複数の実装が散らばっている状態から見て理解しました。
列挙された内容を見ると、上流から下流までまんべんなくちょこちょこやっている状態です。個人的にはデザインスキルをもったシステムアーキテクトと定義して動いている。デザイナーでもエンジニアとしてでもなく「デザインスキルをもった設計者」として動いている。ただ、こんな感じに好き勝手やっていると、
チームの人が横内に何を頼んでいいか最初は困って、一回自分の作業プロセスをドキュメントに起こしてプレゼンした。デザイナーというよりはディレクターがやっているような職域に近く悩んだ時期もあったが、今は少しづつ機能しだしてきて納得して取り組めてきた。
デザイナーと（フロントエンド）エンジニア #
月末のイベントについて #
デザイナーとエンジニアの協業というとてもニッチなテーマに焦点を当てた勉強会。
デザイナーとエンジニアのすれ違い、いっつもある「デザイナーと上手くやるための」みたいな記事があがると「そんなのデザイナーがやれよ」みたいな趣旨の、とても厳しいコメントが付くことが毎回あった。僕なりに心を痛めたり、時には反論をあげたりしてたけど、逆にそういうコメントを書くエンジニアさんもデザイナー起因で上手く行かないことがあったんじゃないか。
お互いのコンテキストを理解しないまま、意見を言うだけでは何も進まないんじゃないか、まずは話がしたい。お互いにどういう問題を抱えていて今後どうなっていきたいかを話したい。登壇される方々はそれぞれ、自分の考えをしっかり持って、活躍されている方々ばかりだと思う。絶対に良い話が聞ける。でも、それだけじゃなくて、参加される方々全員が主役だと思って欲しい。話を聞いて、質問を沢山なげて、懇親会で思いっきり語っていって欲しい。
デザインの定義 #
「デザイン」の定義が非常に曖昧で、「組織デザイン」「コミュニケーションデザイン」「UXデザイン」色んな所に「デザイン」という言葉が出て来る。
ではWebにおける「デザイン」とは何を指すのか？絵を創るのか戦略を創るのか、それともコーディングをするのだろうか。
自分はデザインはもっとビジュアルよりに回帰したほうが良いと考えている。
「デザイン」と名前がついている領域はデザインだけの専売特許ではない。デザインが解決しようとしている領域は実は同じように開発でも解決しようとしている領域。例えば情報設計、フロントのマークアップでもやるし、バックエンド側でもドメインの分析と言うか立ちでクラス図としてアウトプットしたりする。一緒にできるなら一緒にやればいいし、任せられるなら任せてもいい。問題は共有し合えば良い。
デザインが一番やらないといけないことは「形作ること」、ツールを使っても紙を使っても、HTMLを書いてもいいけど、今一度ものを作ってみせることを中心に据えたほうが良いんじゃないかと思っている。会社の、チームの人がいろんなことを考えたり話し合っている中で、とにかくデザイナーは書くこと、ホワイトボードにMTGの内容をまとめたり、さささっと紙でプロトタイプを創る、ツールでより具体的にかつ多面的に考慮がされた形を作っていくこと、それがデザインのやるべきことなんじゃないか。アシストをするだけでもいい。
僕は色や形といったものは「デザイン要素」と読んでいて、デザイン要素をつかった活動すべてがデザインに当たると思っているけど、デザインを使わずに戦略だったり、難しいアルゴリズムを書いたりは無理にやらなくても良いと思う。
一番デザインの価値が発揮できるやり方をとりたい。
お互いの話し方や考え方に「ズレ」はあるのか #
協業スタイル僕はデザインという機能をチームに持たせようと思っている。個人に依存したデザインが破綻する様を僕自身たくさん見てきたし、自分がデザインしたものが、自分がいなくなることで破綻してしまったこともある。
そうならないためにはデザインをチームのナレッジや文化として定着させればよいのではないか。デザインをスキルとして捉える、チームのすべての人が大なり小なりデザイン力を持っていて、デザイナーはそれをつなげればいい。話すことで僕の頭の中のデザインは周りに伝染する、そしてそれぞれが勝手にデザインを考え出す。そして最後にはプロセスに落とし込むということをやりたい。
プロセス化を進めるのは一番最後、エモくなるかもしれないがまず話すことから始めている。
フロントエンドはデザインしない？ #
もちろんしていいと個人的には思う。Webを一番知っているのは実際に実装をおこなっているフロントエンドエンジニアのはずで、もっとデザインにたいして提案して欲しい。Webは一つのデザインランゲージ言えるのではないか？ランゲージを一番喋るのはフロントエンド
デザイナーはフロントエンドしない？してもいいと思う。チームや状況に寄って変わるとは思う。デザイナーが思う視点からWebを見ることで解決できる方法が発見されることがある。タイポグラフィなんかはデザイナーの視点がなければWebでの進化はありえないし、それを一番上手く使えるのはデザインをしているデザイナーであってもよいのでは。
デザイン仕事を奪い合う？ #
ひらく？閉じる？デザインの解決すべき仕事は何なのかを考えたときに、僕の今の状況では、あまりにも対象がでかすぎる。
僕は取り組むべき事業ドメインインついて専門家では確実にないし、それらについて一つ一つ紐解いていくには時間がいくらあっても足りない。崩して周りと一緒に崩していくしかない。デザインいう仕事があるのではなくて、解決すべき課題がまずあり、それをチームが持っているスキルをどう組み合わせて解決していくかになると思う。
そういう意味でとにかくデザインをオープンにしておきたい。
「デザインシステム」は協業のための糸口になるか？ #
デザインシステムの持つ役割には２つの側面があると考えています。
- ある特定の問題をシステマチックに解決するための手段
- デザイナーのモノの見方もしくは考え方を明文化することでデザインをチーム全体の共通言語とするための仕組み
前者は効率、後者は共感です。デザインシステムについて、「デザインファイルをこう作る」「CSSをこう設計するという」という効率化に基づく説明が個人的には多いように感じます。ただデザインシステムの本質は、後者の共感を作ることにあるのではないでしょうか。
システムを「あるプロセスの集合体」と考えると、デザインシステムには様々な背景を持ったプロセスが束ねられるはずです。 それらはマーケティングにおける戦略であったり、特定技術の組み合わせ方であったり、デザインにおけるルールを表したモノであったりします。 （後者2つだけ、であったら僕はそれは単にスタイルガイドであると思います。）
多方面の要素を含むためには、デザイナーだけではなく、すべてのステークホルダーが協調してシステムを作りあげる必要があります。 協調のためにはプロトコルがいります。全員が理解できる言葉で語り、意志をまとめていかなければなりません。
ただエンジニアからみたデザイン、ビジネスサイドから見たデザインは理解が難しい面もあります。 それを細かい粒度に分けることで、理解できるレベルに分解してから検討をすすめるのがAtomic Designという考え方だと思います。
Atomic Designのワークフローではデザインを5段階に分け、それぞれ個別に段階を追って検討していきます。 デザインカンプを見て、正しいデザイン批評をするということは誰にでも簡単にできることではありません。 それには知識や経験がなければ出来ない場合もあります。
デザインの構成要素をバラバラに分解したときに批評にたいするハードルは低くなります。「この色は想定されるユーザにとって適切だろうか？」「この構造は正しく情報の優先度ができているのか」なら十分
そう意味でAtomic Designは技術的なフレームワークではなくあくまで戦術の一つであり、「今何について議論すべきか」を明らかにするものだと思います。
デバイスの多角化によりもたらされた、より高い効率性を生み出すためのモジュール指向の設計という側面だけでなく、我々がどうデザインと向き合えばよいのか？を教えてくれる側面があるのではないでしょうか。
なのでAtomic Designを実際に制作や開発に入れるかは別として、その思想を学ぶことは協業にたいしていくつもの知見をもたらしてくれると思います。
デザインシステムは業務ドメインを反映したものになるはずでBootstrapなどのような「汎用的な問題を解決するため」にはならないはず。Aというサービスのために作成したデザインシステムはBというサービスには使えない。
そこにはクリエイティビティがあって、「システムによって表現が制限される」ようなことはおこらないのではないか。 「デザインシステムをつくるのはコストがかかる」というのは確かにわかる、でも根本的にそこに関わる人を変えなければアウトプットの向上はおこらないか、ならば愚直に取り組んで見る価値があるのではないかというのが僕の考え。