エンジニアがWhyを追求したらUIUXデザイナーになった話

こんにちは。自社プロダクトのUIUXデザインなどをしています、長谷川です。

元はシステムエンジニアをしていたのですが、UIUXを仕事にするまでの過程を社内で共有したら思いのほか良いリアクションをいただけたので、記事にしてみました。

私と同じようにUIUXが気になるエンジニアや、エンジニアにデザインの意図を伝えたいデザイナー、エンジニア組織のデザインに不安な方のヒントになれば幸いです。

---
※BIPROGYにおけるUIUXの取り組み全般については、以下の記事でご紹介しています。

https://qiita.com/AyakoKawasaki/items/ef9b1ab95d699020d470

# この記事に書いてあること📜
* なぜエンジニアがUIUXをやろうと思ったか ([きっかけ](#きっかけ：マインドセットの変化🤔💭))
* どうやって転生したか ([具体的な行動](#具体的な行動🏃))
* このキャリアでどんなバリューが出せるのか ([エンジニア出身である強み](#エンジニア出身である強み💪))

### 書いてないこと
* 技術的なTips
* UIUXデザインの具体的な手法やTips
※トレーニングの手法とかはご紹介します

# きっかけ：マインドセットの変化🤔💭

### あれ、なんかHowよりWhyの方が気になるぞ？

エンジニアとしてプロダクトやサービスの開発に関わる中で、「はて、自分が実装しているこの機能は本当に使いたいものなんだろうか」と思い始めたのがきっかけでした。

ビジネスが届けたい価値をプロダクトとして形にする際、その価値がユーザーにどう伝わるのかが十分に設計されていないと、どんなに優れた技術でも無駄になりかねません。
こんなことを考えるうちに、「どう実装するか（How）」よりも、「なぜこれを作るのか（Why）」に興味が移っていきました。

### ビジネスと実装の間に必要なのがデザイン
UXは「戦略」から「表層」までの「5段階モデル[^1]」で表現されますが、
土台にある「戦略」と「要件」はビジネスの文脈を大きく含んでいます。一方で、上層にある「骨格」や「表層」はUI設計に関連し、実装に近い領域です。

![ux5layer.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263154/bd7f952e-8621-063d-fe49-73b9171505f9.png)

そして、これらの階層はすべて「Why」と「Because」の関係で繋がっています。「なぜこのUIなのか」を辿っていくと「戦略」までたどり着き、逆にビジネス的な戦略があるからこそ「表層」のビジュアルデザインまで順に決まっていくという構造です。
つまり、**UXデザインは「なぜこの価値を届けるのか」というビジネス視点と、「どのように形にするのか」という実装視点を橋渡しする役割を果たしている**のです。

これがまさに私の考えたかったことだ！と気付き、UIUXの道を志すきっかけになりました。

# 具体的な行動🏃
UIUX未経験だった私がどのように学びを進めたのかご紹介します。
各手法の詳細やここに記載した以外のやり方など、詳しく書いてある記事やサイト、本がたくさんあるので探してみて下さい。

<font color="#999">
※ 社内的な調整や異動については会社ごとに事情が異なるため割愛します。私の場合は、柔軟な環境だったおかげで実践の機会を得られました。
</font>

### 1. 手を動かす
プログラミング同様、書籍などで基本をインプットしたら、まずは手を動かしてみるのが一番学びになると感じました。

#### 【UIトレース】
まずは写経を行いました。UIの世界では「トレース」と呼ばれます。
既存のアプリやサービスの画面をなぞって、Figmaなどで再現していきます。

地道ですが、細部に注意を払って進めることで、レイアウトや配色、文字サイズがどのように設定されているかといった、デザインの意図を考えるきっかけになります。
また、Figmaの使い方を効率的に学ぶことにもつながりました。

https://note.com/oha_/n/n8bf5624a58b3

UIのトレーニング手法ではありますが、先ほど５段階モデルでご紹介した通り、UIも **「なぜこのレイアウトなんだろう」「なぜこの画面遷移なんだろう」「というかこのアプリはユーザーにどう行動してほしいんだろう」** と考えていくと、自然とUXを意識することになります。

基本的にデザインの理由は一般公開されてないので、こうした疑問の正解にたどり着くことは難しいです。しかし自分なりの仮説を立てて考え続けることで、デザインへの理解が深まると実感しました。

#### 【架空のサービスのデザイン】

次に行ったのは、架空のサービスをゼロからデザインする練習です。
このときも「なぜ」を意識することは重要で、「どんな人が、どんな課題を抱えているのか」を仮定し、その解決策としてデザインを作り上げていきました。仮説が実際に正しいかどうかは重要ではなく、背景に基づいたデザインを作ることが大切です。

ただ、ペルソナ[^2]の解像度が低いと「なぜ」を追求しづらいと思うので、私は自分の趣味を題材にしました。

![ui_sample.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/263154/af1a6b31-530d-454d-e30c-c6a3cb5869db.png "趣味である釣りを題材に架空のアプリをデザインしました。")

### 2. 社外に出る

社内にも知見はたくさんありますが、あえて社外に出ることで自社の取り組みを客観的に振り返る機会が得られました。また、世間のUX動向を知り、新しい視点を持つきっかけにもなりました。

さらに、UI/UXを始めたばかりの人たちとつながる小さなコミュニティも自然と生まれ、情報や意見を交換する場を持つことができたのは大きな財産です。同じような課題や悩みを共有できる仲間の存在が、モチベーションの維持や新たな発見につながりました。

# エンジニア出身である強み💪
現在も模索中ではありますが、私自身が感じている「エンジニア出身であるからこその強み」をいくつかご紹介します。

### 1. 実装の実現性を見据えたデザインができる
フロントエンドで使用される言語やフレームワークの特性を理解しているおかげで、「こういう構造は難しい」とか「この表現なら簡単に実装できる」といったことをあらかじめ見極めることができます。
こうした **初期段階から実現性を意識したデザインができる点** は大きな強みです。その結果、エンジニアとのコミュニケーションがスムーズになり、手戻りのリスクも減少します。

### 2. 技術的な課題に対応しやすい
一見シンプルなデザインに見えても、実装が難しいというケースはよくあるかと思います。
例えば、サーバーとの通信のタイミング、ステート管理、認証の問題などで、意図した画面遷移や動作にならないなど…。

こういう時、技術的な勘所があると「じゃあこういうデータの取り方は実装コスト少ないですか？」「ということは、この画面構成ならいけそうですかね」という感じで、技術面を配慮しながら素早く落とし所を見つけることができます。

### 3. フロントまで作ってからエンジニアに渡せる
実装視点を意識してデザインを考えると、「こういう実装にすればこのデザインを実現できるな」という具体的なイメージが湧くことがあります。

しかし、これまでになかった新しいUIやレイアウトの場合、実装方針まで詳しく伝えるのはコストが高く、仕上がりがデザイナーの意図とずれることも少なくありません。
そのため、**デザイナー自身がフロントの動作まで作り込んで渡すと、結果的にQCDすべての面で向上することがあります**。

### 4. エンジニアとしてデザインの意図を汲み取れるようになる

これはエンジニアとしての視点ですが、デザインスキルを付けておくとエンジニアの立場からでもデザインの意図を汲み取りやすくなります。

デザイナーになるつもりがなくても、本記事で紹介したようなトレーニングを試してみるだけで、デザイナーとのコミュニケーションがぐっとスムーズになります。これだけでも十分に価値があると思います。

# まとめ📌

いかがでしたでしょうか。
キャリアを変える前は不安もあり、一歩を踏み出すのに勇気が必要でしたが、思いのほかエンジニアとしての背景が役立っていることを実感しています。
同じような境遇にある方も、そうでない方も、少しでもヒントになれば幸いです。

[^1]: Jesse James Garrettが著書「[The Elements of User Experience 5段階モデルで考えるUXデザイン](https://www.amazon.co.jp/Elements-User-Experience-5%E6%AE%B5%E9%9A%8E%E3%83%A2%E3%83%87%E3%83%AB%E3%81%A7%E8%80%83%E3%81%88%E3%82%8BUX%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3/dp/4839975981)」で提唱したUXの概念です。
[^2]: サービスやプロダクトの対象となる典型的なユーザー像を、具体的なプロフィールとして表現したものです。具体的なユーザー像を持つことで、チームやステークホルダーとの共通認識を築き、設計の判断基準としても役立ちます。