0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エンジニアに必要なのはデザイン力かもしれない

Posted at

エンジニアに必要なのはデザイン力かもしれない

目次

1. はじめに
2. 本記事におけるデザインの定義
3. AIで短くなったのは書く時間であって感じる時間ではない
4. Figmaセッションで見えたこと
5. エンジニアリングとデザインのパワーバランス
6. BtoBだから地味でいいの誤解
7. これからの“ひとりの勝ち筋”
8. おわりに

1. はじめに

新規事業のPdMとしてプロダクト開発を推進していたとき、チームにはReactなども完全に使いこなすエンジニアがそろっているのに、仕上がるUIだけが 2010年 で止まっていると感じる場面が何度もありました。
BtoBだから少しくらいダサくても大丈夫だろうという考え方ていたのか、あれが限界だったのかはわからないですが(多分限界)、ユーザー体験において確実にマイナスに働くと考えます。
私は外部のデザイナーさんを説得して参画していただき(いわゆるJTC文脈ではこれ自体が難所でした)、そこからようやくプロダクトの“顔つき”が変わっていきました。

2. 本記事におけるデザインの定義

本記事でいう「デザイン」は、 広告やプロモーション用のビジュアル制作などのいわゆる【クリエティブ】 のことではありません。
ここでは、 サービスのUXを高めるための“表現設計” を指します。
対象は次のような「機能が決まった後の見せ方・使わせ方」です。

  • フォントやタイポグラフィ
  • 余白(パディング/マージン)や密度の設計
  • プロダクトのブランドカラー/コントラスト
  • 画面構成(レイアウト、階層、視線誘導)
  • コンポーネントの状態(hover/focus/disabled/error など)とインタラクション

なお、機能の要不要や優先順位の決定は、本記事で扱う「デザイン」の範囲外と位置づけます。

3. AIで短くなったのは書く時間であって感じる時間ではない

生成AIの普及により、要件から雛形コード、テスト、ドキュメントまで一気に生成できるようになりました。
エンジニアリングの難易度は劇的に下がったと感じます。
バイブコーディングのことを言っているのではなく、AWSの設定方法もAIが教えてくれるし、Cursorとかを使ったコーディング体験も初心者に優しくなったと言っています。
私自身もAWSの知識はないですが、GPTと相談しながら臨む環境を構築できました。


一方で、見せ方・使わせ方の設計(フォント、余白、配色、画面構成、状態設計、マイクロインタラクション)は依然として自動化が難しく、デザインの難易度は下がっていません。むしろコードの出力量が増えたぶん、デザイン側の磨き込みが追いつきにくい状況が生まれやすくなっていると感じます。

4. Figmaセッションで見えたこと

この記事を書くきっかけは、AI 開発組織 Summit の Figma Japan さんのセッションでした(https://jp.findy-team.io/conference/ai-dev-org-summit/)。
Figma自体は以前から知っていましたが、UXの表現設計からPoCまでの往復がここまで短くなるとは正直思っていませんでした。条件次第では、従来3か月かかっていた検証を2週間程度で回せる手触りを得ました。
スピードが上がるほど、フォントや余白、配色、画面構成、コンポーネントの状態といった“最初の表現設計”の精度がプロダクト全体に与える影響は大きくなると実感しています。初手の表現設計がよければAIの生産性は良い方向に増幅され、逆であれば悪い方向に増幅されます。


プロダクトの改善を図ろうとしても、デザインのレベルが低ければ「デザインが悪いから使われないのか」「機能が悪いから使われないのか」がわからなくなってしまいます。

5. エンジニアリングとデザインのパワーバランス

  • 生成AIにより エンジニアリングの参入障壁が低下
  • デザイン(=見せ方・使わせ方)は “それっぽさ”を越える微調整と文脈適合が依然としてプロの人の領域
  • 実装の出力量が増えた結果、表現設計の律速が目立つ

この非対称性が続くかぎり、開発のレバレッジは エンジニアリング<<<デザイン(UX表現) へとじわじわ寄っていく可能性が高いと考えます。

こうなってくると、デザインのわかる人がAIを噛ませて実装へ踏み込むことは比較的容易ですが、逆にエンジニアが表現設計の機微に踏み込むには、デザインの文脈に依存する抽象を相当量学ぶ必要があるからです。

6. BtoBだから地味でいいの誤解

BtoBの現場は毎日触れる前提で設計すべきだと考えます。早く終わる・迷わない・ミスしないという価値は、派手さではなく 情報の見せ方・視線誘導・操作の一貫性・マイクロコピーから生まれます。
PdMとして導入と運用に立ち会った経験上、テーブルやフォームの視線移動を短くし、キーボード操作やアクセシビリティを最初から表現設計に含め、重要指標と主要操作をファーストビューに残すだけでも、現場の満足度と継続率は目に見えて変わっていきました。

そもそも、ユーザは「使いにくさ」を明確に言語化はしてくれません。「なんか漠然と使いづらい」という感覚を抱き、ヒアリングすると無理やり捻り出した、「目についたポイント」をあげてくるだけで根本的な改善には到達できないのです。

7. これからの“エンジニアの勝ち筋”

効率化された環境とAIの後押しによって、アイデアから検証、実装、リリースまでの距離は確実に短くなっています。
この流れの中で強いのは、「どう見せ、どう使ってもらうか」を先に決め、Figmaなどで表現設計を素早く試し、実装はAIで寄せていく動き方だと考えます。体験の輪郭が固まっていれば、AIによる実装の加速は素直に効きます。

つまり、昔からよく言われている「体験(デザイン)から作っていく」べきなのです。
AIでデザイン以外が効率化されましたが、デザインがゴミであればAIを使ってサービスを乱立させてもゴミが量産されるだけなのです。

8. おわりに

いまは、エンジニアリングの着手が容易になったぶん、見せ方・使わせ方の基準を先に引く、つまりUXを磨き上げること がますます重要になっていると感じます。フォントと余白、配色、画面構成、コンポーネントの状態——

結局のところ、プロダクトの印象と使い心地を決めるのは表現設計です。エンジニアに必要なのは、やはりデザイン力(見せ方・使わせ方)だと思います。

優れたUXを実現するためのプログラミングであって、プログラムが実行する機能を使わせるためのUXではダメなのだ。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?