こんにちは！TECH Street編集部です！
2022年11月17日（木）に開催した、 「UXエンジニア・デザインエンジニア勉強会」のイベントレポートをお届けします。ITテクノロジーに関する様々な職種やテーマをピックアップして「他社・他の人ってどうしているの？」を学ぶ、TECH Streetコミュニティ恒例の事例・知見共有勉強会。今回はUXエンジニア（UXE）・デザインエンジニアのキャリアや知見を共有しあう勉強会を開催いたしました。
登壇者はこちらの方々
金子広大／パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部 第2グループ エンジニア
藤田 智也／THECOO株式会社 エンジニア
鍜治本 碧／エキサイト株式会社 SaaS・DX事業部 UI/UXデザイナー
まずは金子さんの登壇レポートをご覧ください。
小さなデザインシステム設計のナレッジシェア
金子：まずは私が所属する組織についてのご説明です。
パーソルキャリアではテクノロジー本部に所属していますが、Tech×Creatibeのコラボレーションを推進するデザイナーの会である｢UXDIG｣に参加しています。社内勉強会を開催しながら、成果物を共有したり社内プロジェクトにも参加したり様々な活動を行っています。
そしてUXDIGとして取り組んでいる社内プロジェクトが「MIRAIZ」です。
「MIRAIZ」の概要説明
「MIRAIZ」は自分にとって理想の“はたらく”の実現をサポートするセルフキャリアマネジメントツールで、現状はβ版がリリースされています。製品版をリリースするために鋭意開発中です。
このツールには４つのサービスがあり、開発体制もサブプロジェクトを４つ同時に回すという凄まじい体制になっています。
「MIRAIZ」のプロジェクト体制について
サブプロジェクト内にUI/UXデザイナーがアサインされているので、各々が最善と考えるUXを実現する必要がありますが、サブプロジェクト同士連携することが重要です。「MIRAIZ」として一貫した世界観を実現するために、共通項となるデザインツールやデザインコンポーネントが必要となりました。そこで「MIRAIZ」では「Material UI」を導入いたしました。
「Material UI」とは
「Material UI」はGoogle社が提唱している「Material Design」をベースに開発されたReact用のUIコンポーネントライブラリです。
本プロジェクトでも統一されたUIを複数人で作成できるように、最低限のルールや仕様をドキュメント化して作業効率を上げるために、Maerial
Designをベースにデザイン領域における最低限の「デザインルール」を作成しました。
デザイナー領域：最低限の共通ルール
それぞれのルールを紹介します。
【Button】
特に複数のデザイナーが関わっている時に重要なのは役割とヒエラルキーです。
どういう時に、どのスタイルを使うか定めないとカオスなことになるため、様々なルールを設定して補強しています。例えば右図/下の赤の”アラート“ボタンが、乱発されないように明確なルールを定めています。
【Color】
複数のデザイナーが関わる場合、放置しておくとカラーがどんどん増えていきます。
用途を定めて一貫性をもたせたほうが良いため、ルールで記載する項目も定めました。
実際にプロジェクト内で、カラー定義にないものがFigmaにあったときは、デザイナーに都度質問する流れにしていました。
【Layout】
拠り所のないサイズ・配置を極力無くす仕組みとしてルールを導入しました。
【Device対応】
対応対象外のタブレット端末でも対応しているように見える設計をしました。
このように各サブプロジェクトで認識の齟齬が生じないように、先行してルールを策定しました。
エンジニアリング領域：共通ルールとTheme
エンジニアの方であればピンとくる方もいらっしゃるかもしれませんが、エンジニアリング領域ではこれまで紹介したような共通ルールをThemeに反映させるようにいたしました。
それによって、システム全体のデザインのデフォルトの値を編集することが可能となりました。
Ｔｈｅｍｅによって
・不要なコードの記述量が減り全体的に工数が減る
・デザインの統一感・再現性が高まる
・色の設定などが煩雑になりづらい
などの作用が期待できます。ただ懸念点として
・強力過ぎてコンポーネントの値などで、どこに影響を及ぼすか把握しづらい
という副作用もあります。
そこで「デザイナーと合意」をもとにしたThemeの設定は「すべてが正になる」としました。多少強引な手口かもしれませんが、懸念していた「影響の範囲」を把握するための有効な手だてとなっています。よってThemeを作るうえではデザイナーとのコミュニケーションは必須です。
・最初に「ColorScript」と「色彩の定義」を見せればよかった
・他コンポーネントでも、Muiに併せて「全体的なデザインの同意」を取れる部分はありそう
・まとめてスプレッドシートにおいて問診票のようにしたら、デザイナーとエンジニアの工数削減が可能
などまだまだ改善の余地はあるのかなと思っております。
エンジニアリング領域：Atomic Designについて
ここでクイズ！つぎのコンポーネントはいくつの集合体だと思いますか？
私の答えは「2」ですが、「1」だと言われても反論できない状態になります。また「1」だと主張しても「2」の人の反論に回答できないと思っています。と言うのもIconButton はIconのコンポーネントに依存しているので、単体では成立しないからです。明確ではないため、チームメンバー間でもお互いの「普通」が衝突して、膨大なコミュニケーションコストが発生いたします。そこで取り入れたのが「Atomic Design」。
Atomic Designとは、パーツ単位でUIデザインを設計する手法のことです。
メンバー間でのコンポーネントの粒度間に共通認識が作れるので、コミュニケーションが円滑に取れるというメリットがあるのですが、一方で各単位の厳密な定義がされていないため分類時に議論が発散しがちというデメリットがあります。（特にAtoms,molecules,organisms）
そこで代わりになる分割単位を考えることにしました。
代わりになる分割単位を考える
考慮すべき条件として
・要素数で考えるのはあきらめる
・Atomsが多すぎる問題にも対応したい
・エンジニアだけが理解できるのはアウト（共通言語であるべき）
Atomsは「Mui（デザインフレームワーク）のリストに載っているもの」で考えてみました。
代わりになる分割単位の紹介：Atoms編
Muiをベースに上記大項目と小項目で構成しました。
代わりになる分割単位の紹介：Organisms編
DBの情報を使用することが前提になっているものとし、デザイナー/エンジニアどちらも共通言語として使えるようにしました。
代わりになる分割定義についてまとめると以下の通りです。
どこにも入らないようであれば、話し合いで解決することにしています。
運用してみて
良かった点としては
・境界線について質問がほとんどなくなる
・「ピクセルパーフェクト」を目指すのではなく「デザイナーの意図を反映させる」ことができた
・共通コンポーネントとして切り出せた。
一方で、まだまだ改善の余地もあります。
同じものでも見る立場が変われば見え方が変わります。
「相手の立場になって考える」はデザイナー経験がないと難しい部分があるので、今回のプロジェクトでは「別の立場から見ると違うものがある」ことを意識しました。どう見えているかはその都度、確認が必要ですが、違うものが見えていることを、受け入れて認めて理解することが重要です。
皆さんがデザインシステムを考える際にはぜひ念頭に置いてみてください。
続いては藤田さんの登壇レポートです。
チームで取り組んだWebフロントエンドのアップデート
藤田：このLTでお伝えしたいことは…Webフロントエンドのモダナイズです！
今回は我々が取り組んだ手法をご紹介いたします。Webフロントエンドに関わるみなさんの今後の参考になれば幸いです！
デザインシステムの導入
デザインシステムとは一般的に、企業のビジョンやブランド・アイデンティティなどから「良いデザイン」を定義するデザイン原則などのドキュメント、それらを具体的にデザイン・実装するためのUIパターンやコンポーネントなどを備えた一連のリソースのことを指していて、私たちは以下の４つが構成要素であると定義しています。
【ブランド・アイデンティティ】は製品の目指す方向性やビジョン、雰囲気、使っているロゴやカラーなどブランドを構成しているデザイン的な要素を明確化したもの。
それらのブランド・アイデンティティをプロダクトに落とし込んでいくときに使用するインターフェースガイドラインが【スタイルガイド】
【パターンライブラリ】はエンジニア寄りのもの。スタイルガイドを実際にアプリケーションに組み込んで実装・運用する際につかうコード。それらのテストやドキュメンテーションを、うまく運用し、更新するための仕組みが【運用のための仕組み】です。
実際に使っているデザインシステムの色の定義
テキストについての定義
デザインシステムを導入するべきか？
そもそも、デザインシステムの利点は“デザイン”にそれぞれ名前をつけて、エンジニアとデザイナーのあいだでコミュニケーションコストが削減されることです。
よって複数のエンジニア・デザイナーのやり取りが発生するプロジェクトなどには非常に有用です。
ただ小規模チームで単一のサービスを開発しているケースや、そもそも小規模なプロジェクトの場合は前途の利点が活かされないため不要と考えられます。
エンジニア視点では、再利用できるコンポーネントライブラリがあらかじめ定義されているので、新しく何かを作るときも1つ1つ作らなくても良いという利点もあります。
※デザイントークンとは、そのデザインで使われている色やスペースの大きさなど、そのデザインを構成する最小構成単位のこと。
以上の利点から「デザインシステムを導入しよう」という結論になった場合、デザインシステムと密接に関わっているのがコンポーネント駆動開発（ＣＤＤ）です。
右図がまさにコンポーネントを作っていく様子ですが、この開発手法にも４つの利点があります。
品質
1つ1つの構成単位や、それを組み合わせたコンポーネントがそれぞれテストされているので、それぞれの品質が高められている状態であれば、それを組み合わせた最終的な成果物の品質も高まっていきます。
耐久性
1つ1つのコンポーネントが疎結合に作られていて、且つ、そのコンポーネントごとのテストが実施されていれば、最終的なページで何かバグが起こったとしてもトレースが可能です。
開発速度
コンポーネントを組み合わせて作っているので、他のところで使われているコンポーネントは簡単に再利用ができ、それによって開発速度が上がります。
開発効率
コンポーネントをあらかじめインターフェースを定めて、且つ、疎結合に作っていけば、数人のエンジニアがそれぞれ違うコンポーネントを同時に作っていても、同時並行で進められます。
実際に私たちはこの3ステップで行いました↓
Storybookの導入
「StoryBook」とはUIコンポーネントをストーリーという単位で管理できるソフトウェアです。
・コンポーネント単位で見た目・動作確認が可能
・ドキュメント作成
上記のような利点があります。
導入までは何ができるか、どう使うとよいかを検討し、後述のChromaticと組み合わせて運用することで効果が出てきます。
Chromaticの導入
Chromaticは“Storyを簡単に公開できる“という利点の他に
・UIテストで実装ミスを発見できる
・UIレビューで変更の承認ができる
というメリットもあります。
導入までの流れとしては上記利点でできることを調査したのち、GitHub Actionを実装し、実際に動作を確認してみました。
今までのような、全部作ってから｢これ違う！｣といった手戻り作業の無駄がなくなり効率的なワークフローが実現可能になりました。
その他
そのほかには
・テスト
・リンター、フォーマッター
・TypeScript
・Vue3
これらはまだ完全ではありませんが実施中です。
まとめ
StorybookとChromaticを導入しつつCDDで開発することで開発体験の向上が可能です。デザイナー、エンジニア、PMといったステークホルダーを巻き込んで効率的なワークフローを構築することが重要です。今後、みなさんが開発環境を更新する役に立てば幸いです。
最後に鍜治本さんの登壇レポートです
SaaSのUIができるまで
鍜治本：そもそもSaaSとは「Software as a Service」の略でありソフトをダウンロードしなくてもブラウザで使えるツールの総称で、GoogleドキュメントやSlack
など、なじみのあるSaaSではないでしょうか。
私は所属するエキサイト株式会社SaaS・DX事業部においてデザイナーを担当しています。
本セッションでは
・デザイナーがどのようなことをしているのか
・エンジニアとの連携やプロダクトにどんな影響を与えているのか
という理解から「デザイナーとはこんな生き物なのか」というのを知っていただき、デザイナーのいないチームにとって、UI/UXを高めるTIPSにつながれば幸いです。
学生時代は卒業研究で＜プロダクト初心者に向けたプロトタイピングマニュアル＞に取り組むなどUI/UXに関するキャリアを歩んできましたが、エキサイトで働きながらデザインするUI/UXは制作物などの自由度ベクトルが大きく異なると実感しています。
学生時代は表面的な自分の仮説ありきの設計で、見た目の完成度を挙げていれば何とかなりました。ただ、仕事ではエンジニアに渡す設計図でもあるため、ピクセル単位でズレがないようにしています。また、大衆が認識しやすいディティールにもこだわり、組織に還元できるように工夫もしています。
では実際の業務について、SaaS・DX事業部が手掛けるクラウド経営管理ソフト【KUROTEN】をつかって説明していきます。
UIが出来上がるまで
ではUIが出来上がるまでの大まかなフローを見ていきましょう。
進め方としては以下の3ステップです。
➀方針や仕様の議論と大まかなスケジュールをたてる
②裏側の設計とUIの設計を同時進行
③設計図をフロントへユーザーテストも実施
フローごとの詳細
➀…まずはＰｄｍの方針や技術面で実現可能かどうかを、開発ロードマップを立てて、担当者を割り当てながらスケジューリングします。
②…詳細な仕様を詰めながらバックエンドも走り出し、同時にUI設計も着手。
どんなUIがいいかを検討しUIを組み立てて、形にしていきます。
③…設計したUIをフロントとバックエンドとすり合わせ、合間に認識のズレがないかテストします。
具体的にはFigmaのプロトタイプ機能を使って、表現に問題がないか、分かりにくくなっていないかを調べたりします。
また設計する上では
・ユーザーがやりたいことをきちんと達成できているか
→合間に確認していき、具体化のブレがないかを確かめる
・仕様ベースで体験の妥協をしていないか
→デザイナー/エンジニアを含めてどうやったら目的の操作を達成できるか突き詰める
・既存のUIやコンポーネントと大きな差がないか
→初めて触る人が違和感なく操作できるか
・エンジニアに渡すときに見えにくくないか、振り返ったときにわからなくならないか
→Figmaに描き示す方法を統一する、またプラグインなど駆使してサイズ表記をする
主に以上の４つに注意して、設計に取り組んでいます。
デザイナーの仕事とプロダクトへの関わり方
SaaS事業部のデザイナーはクリエイティブ全般に関わりながらUI/UXを高めるように、業務フローの中で積極的にエンジニアと関わっていき、齟齬が内容をすり合わせながらFigmaなどのツールを駆使してわかりやすくなるように突き詰めています。
今回の内容で少しでも皆様にTIPSにつながればと思います。
まとめ
いかがだったでしょうか。
普段なかなか知る機会がない、UXエンジニア（UXE）・デザインエンジニアの知見を垣間見ることができました。少しでも皆様のお役にたてればうれしいです。
質問コーナー
iPhoneのデザイン（UXデザイン）についてどう思いますか？
金子：UI/UXは良いと思うのですが、スマホ慣れしていない人（ガラケーからようやく買い替えた人とか、初めてスマホを持つ子供とか）は年々分かりにくくなっているでしょうね。
専用コンポーネントと、汎用コンポーネント（Atomic Design）をどう考えるのかについては聞きたいです
金子：汎用がAtom、専用がOrganismに当たるかなと思います。ドメインモデルが入っているところが「専用」になるという考えです。
ルール策定は何かを参考にされましたか？気を付ける点なんかのアドバイスもいただければと
金子：エンジニアとして気を付けたのは「テーマの項目を確認→コレとコレがあると嬉しいを投げる」それを基盤に作っていきました。「あまりルールをつけすぎない」というのも気を付けています。
TechとCreativeのギャップをどう埋める？どんなキャリアを歩んできたの？ まさにこのテーマについて聞いてみたいです！
金子：最後のスライドの「話し合いが大事」。話し合い、ここを諦めないこと。ギャップは埋まると信じて話す。エンジニア側はとっつきづらい人が多かったりします…私はエンジニアとして、共通言語を使い、難しい言葉はなるべく使わないよう意識しています。
デザインのルールは、見直し頻度はどの程度でしょうか？流行り・時代背景に左右されるような内容はルールに含めないとか...？？
鍜治本：流行りで一回上がったものだと、ニューモーフィズムの例とか良さそうですね。流行を取り入れる方針は、結局浸透しなかった時にマイナスの負債だらけになってしまうので、安易にUIには入れないようにしています。逆に、消耗品に近いイベントサムネなどのグラフィックはどんどん新しいあしらいを取り入れるようにしています。
デザイン関連って、広報担当と喧嘩になることとかありますか？（経験あり）
鍜治本：広報担当の方とはまだありませんね笑
デザイン組織がない企業“あるある”ですが、デザイナー＝作ってくれる人というイメージが強く、我々が意図して形作ったものと相手方の考えている事柄がズレて、すり合わせが大変な時はあったと思います。やはり対話で綿密に方向を確認していくのが大事そうですね。
デザイン関連の一番のこだわり、テック関連の一番のこだわり 聞いてみたいです
デザイナー回答：デザイン関連では、複雑すぎるルールは避けるようにしていました。明快で汎用性が高いことを心がけています。
金子：とにかく「安く早く良く」プロダクトを仕上げることです。（吉野家の安い早い美味いですね）
納期を守りつつ、後の運用にも迷惑をかけず、ユーザーにも良いものを届けたいです。
デザイナー部署と開発部署のコミュニケーションの上手いコツはありますか？
金子：相手を尊重することかと思います。意見を尊重する、人として尊重することを大事にしています。あと、同じ日本語でも、使用する言語が異なることを受け入れることが大事かと思います。
大学時代の勉強分野で学んだことなのですが、同じ日本人でも住んでいる場所や文化で言葉や成り立ちは変わります。原宿の若者と秋葉原のディープなオタクでは、住んでいる場所は近くても、だいぶ異なる会話の形態になります。そういった部分を尊重することが大事かと。
THECOOさん、いくつかあるサービスって、デザインチームは別ですか？体制なんかも気になります。なんとなく各サービスのロゴ的に雰囲気が異なるのかな？と思ったので。
藤田：デザインチームを別にもっているわけではないです。担当者が変わり、使われる用途（サービス）によって雰囲気が変わっています。
藤田さんはテック寄り・・・ですか？まだお若いかなと思ったので、デザイン関連でのこの先のキャリアについて思いがあれば聞いてみたいなーって
藤田：テック寄りです。
プロダクトの最終的な価値や届けられるものがデザインに左右されることを実感しています。エンジニアとしてプロダクトを作っていく中で、デザイナーの意思をくみ取っていたり、デザインのことも意識できるような、キャリアを積んでいきたいと思っています。
StorybookにしてもChromaticにしても、こういうのを選ぶ、導入ってどこが検証・判断する感じですか？デザインチームがどんどん独断で月進める感じですか？
藤田：チームの中で、いい案を見つけた人が提案。チームとしても「いいね」となったら取り組む、という流れです。独断で取り組むのではなく、実際の運用やプロダクトへの導入はチーム全体で取り組んだ方が良いと思います。
Figmaのようなデザインシステムでもモック作れるかと思いますが、Chromaticでモック作成するメリットってなんでしょうか？
藤田：デザインシステムを作るうえで、３つの確認箇所があります。なかでも一番大事なのはStorybook。実際に動くものに近いモックが作れるので、Storybookを簡単に公開できるChromaticでモック作成しています。
デザイン→エンジニアリングのリレーを実施するうえでのシステム構成・バリエーションにおいて参考にした企業や事例はありますか？
藤田：pixivのテックブログを読みました。ZOZOの記事も参考にしたような気がします。様々な企業の記事を積極的に読んで情報収集しています。
Figmaのようなデザインシステムでもモック作れるかと思いますが、Chromaticでモック作成するメリットってなんでしょうか？
藤田：デザインシステムを作るうえで、３つの確認箇所があります。なかでも一番大事なのはStorybook。実際に動くものに近いモックが作れるので、Storybookを簡単に公開できるChromaticでモック作成しています。
1人で担当されている？！大変じゃないですか？！上司は？！決裁権限は？！
鍜治本：上司にあたる人がプロダクトマネージャーです。仲良くやっています。決裁権限を全て持っていませんが、細かいディテールなどはデザイナー側で握っているかもしれません。一人でやっているのを気にかけてもらっています。
UXデザインの道を選んだのはなぜですか？どういう意識で取り組んで、どういう意識に変わりましたか？
鍜治本：元々UIUXをやるぞ！というのを考えていたわけではありません。チームで何かを成し遂げたいという想いが強く、ターゲットの為に何かを作りたい・やってみたいという欲求が漠然とありました。
学生時代からUI/UXに携わられた経験が既に相当レアな感じがありますが。UIUXへの関心のきっかけや、学生時代もUIUXの関連スキルを高めようとされたのはどういった動機があったのでしょうか？
鍜治本：学生時代にグループで何かをやるというのは経験してきました。そういう時の算段を考えたりすることが刺激になりました。
良いUIUXの引き出しを積むにあたり、どういった経験が効果的でしたか？
鍜治本：色んな人に見てもらう、触ってもらうことが大切です。「作ってみましたが、どうでしょう？」のフィードバックをどんどんもらってさらに磨き上げるのが良いのかなと思います。
デザイナー側がエンジニアリングに近い部分を理解されるような取り組みなどは行われていたりしますか？（たとえばOOUIとか、HTMLの文書構造を意識するとか）
鍜治本：実はHTMLやCSSを全く知りません...!ただ、分からないのでエンジニアさんに分担してもらっていてその分自分ができる分野に力を入れて取り組んでいます。
最近は検証ツールを開いてみたり、色味やテキストサイズ・位置の指示のCSSと睨めっこしてみたりしています。
画面上のデザインというとUIの要素が強いイメージを持ちますが、UXのデザインとしてはどういった業務に取り組まれていますか？
鍜治本：ユーザーにインタビュー調査を企画しました。普段会計に近い分野で、ターゲットはExcelやスプレッドシートのヘビーユーザーですので、作業を動画撮影させてもらい、逐一動作を聞きながら言語化するエスノグラフィもしました。
Figma / FigJam で愛用プラグインはございますか？
鍜治本：Spacing Manager：指定していたスペーサーを表示・非表示できる
Redlines：高さや幅などの数値を赤線で表示してくれるサイズ表示系のプラグインが愛用です。
UIの作成や改善におけるインプットとして、ユーザー観察/インタビューなどで得られた定性的なデータがイメージされますが、ユーザーの行動ログなど定量的なデータの分析はされていますか？定量データ利活用の余地・可能性はありそうですか？
鍜治本：まだ定量のデータ集めが追い付いていない状態です。まだ手が回っていないのですが、今後はそういうところも組み込んでいきたいです。
UXデザイン系で過去イチきつかった経験、みなさんに聞いてみたいです
金子：最近は昔に比べたら楽になったなと思っています。Figmaがとても便利
渡されたのがパワポだけというのが辛かった経験でしたね。
藤田：仕事関係だとあまりないです。
個人開発だとはじめに作っていたものから大幅にピボットしました。それをやっていくときにFigmaなど使わず自分の頭よりにしていたのでデザインが崩壊していくという経験がありました…
鍜治本：配属されて半年くらい経った時に初めてゼロからUIを担当した、営業向けの「KUROTEN.for Sales」というプロダクトを担当した時が大変でした。企業が取り扱っている商材を管理したり、確度と呼ばれる指標みたいなものを数値化して売上予想を立てたりできるのですが、自分が知らなかった分野なのも相まって、仕様をイチから理解しながら作っていくのが大変でした。
イベントレポートは以上となります！
次回のレポートもお楽しみに♪
