こんにちは。
プロダクトマネージャー兼エンジニア兼UIUXデザイン推進担当として越境気味に働いている照山です。
みなさんは「UI/UX」という言葉を聞いて、反射的に誰の顔を思い浮かべるでしょうか？
多くの人は、Figmaを巧みに操るデザイナーの顔を思い浮かべるはずです。
「ユーザーインターフェース（UI）」
「ユーザーエクスペリエンス（UX）」
言葉の響きからして、見た目や使い勝手、感性に関わる領域であることは間違いありません。
だからこそ、「それはデザイナーの領分であり、エンジニアやPMが口を出すのは野暮だ」 開発現場には、そんな空気が漂っていないでしょうか。
しかし、エンジニアとして、マネージャとしてサービス・プロダクトづくりに長く関われば関わるほど、ある違和感が湧き上がってきます。
「UI/UXは、本当にデザイナーだけの仕事なのか？」
もっと言えば、顧客の要件を最初に定義するPMや、システムが動くリアリティ（制約）を誰よりも知っているエンジニアこそ、UI/UXの設計プロセスのど真ん中にいるべきではないのか？
この問いは、単なる役割分担や「仲良くやろう」という精神論の話ではありません。
生成AIが当たり前に存在する2020年代後半において、プロダクト開発における「価値の作り方」そのものが構造的に変化していることに起因する帰結です。
今回は、アドベントカレンダーという機会を借りて、
「なぜ今、エンジニアとPMがUI/UXに越境すべきなのか」
「AI時代におけるBTC（Business/Technology/Creative）人材とは何か」
について、少し解像度を上げて言語化してみたいと思います。
「分業」というシステムが、プロダクトを歪めてきた歴史
まず、私たちが無意識に受け入れている開発の前提を疑うところから始めましょう。
ソフトウェア開発は長らく、高度な「分業」によって支えられてきました。
- PM： 「何を作るか（What）」を定義し、進行管理をする
- デザイナー： 「どう見えるか（How）」を具現化する
- エンジニア： 「どう動かすか（Implementation）」を実装する
- マーケター： 「どう売るか（How to sell）」を考える
この分業システムは、確かに効率的でした。
それぞれの専門家が自分の領域に閉じて、深掘りすることで、生産性とクオリティを担保してきたのです。
工業化社会のモデルをそのままソフトウェア開発に持ち込んだ成功体験と言えるでしょう。
しかし、プロダクトが複雑化し、ユーザーの目が肥えた現在、この分業システムの「負の側面」が無視できないレベルで肥大化しています。
その最大の弊害が、職種間の「翻訳コスト」と「情報の劣化」です。
PMの頭の中にあった「顧客の課題」が、ドキュメントになる過程で少し削ぎ落とされる。
そのドキュメントを読んだデザイナーがUIを作る過程で、PMの意図とは少しズレた解釈が混じる。
出来上がったデザインを見たエンジニアは、「この挙動は今のDB設計だとパフォーマンスが出ない」と悩みつつ、納期に追われて無理やり実装する。
この伝言ゲームの結果、何が生まれるか。
「誰も意図していなかった、顧客にとっての価値を最大化したいという目標からズレてしまったプロダクトやサービス」です。
さらに深刻なのは、分業が組織の中に「見えない境界線」を引いてしまうことです。
「画面の使い勝手が悪いのは、デザイナーのセンスの問題だ」
「要件が決まらないのは、PMの優柔不断のせいだ」
「実装が遅いのは、エンジニアの技術力不足だ」
こうして、本来は「ユーザーに価値を届ける」という共通のゴールを持っていたはずのチームが、いつの間にか「自分の担当範囲を守る」ことに必死になる。
UI/UXは、このセクショナリズムの犠牲に最もなりやすい領域です。
なぜなら、UI/UXとは「ビジネス要件（Why）」と「技術的制約（How）」と「表現（Look）」が交差する交差点そのものだからです。
本来、職種をまたいで扱われるべき「不可分な領域」を、無理やり分業構造に押し込めたことで、プロダクト開発が歪んでしまうのです。
AIが「専門性の壁」を溶解させた
「分業の弊害なんて、昔から言われていることじゃないか」
そう思われるかもしれません。
しかし、ここ数年で状況は一変しました。言うまでもなく、生成AIの登場です。
AIは、これまで専門家にしか扱えなかった領域への参入障壁を、劇的に引き下げました。専門性の「独占」が終わったのです。
これまでは、エンジニアがデザインの意図を理解しようと思えば、デザインの基礎理論から学ぶ必要がありました。
しかし今は、UIのスクリーンショットをAIに投げれば、レイアウト、フォント、配色などの意図を即座に解説してくれます。
逆に、デザイナーが実装のリアリティを知ろうとした時、以前ならエンジニアにおそるおそる質問する必要がありました。
しかし今は、Figmaで作ったデザインをコードに変換し、「このUIを実現するのに無理がある箇所はあるか？」とAIに問えば、レンダリングコストやデータ構造の矛盾を指摘してくれます。
PMやマーケターがSQLを知らなくても自然言語でデータを抽出できるし、手書きのメモからプロトタイプを生成できる。
つまり、「特定の領域は、その専門家に丸投げしないと何もできない」という前提が崩れたのです。
細かい作業はAIが高速に補助してくれます。
その結果、人間が担うべき役割は、「作業」から「判断」へ、そして「前後の工程への関与」へとシフトせざるを得なくなりました。
これは、エンジニアにとっては大きなチャンスであり、同時にプレッシャーでもあります。
「コードだけ書いていればいい」時代は終わり、「コードによってどんな体験を生み出すか」まで責任範囲が広がったことを意味するからです。
デザイナーは、すでに「越境」し始めている
このパラダイムシフトにいち早く気づいているのは、実はデザイナーたちかもしれません。
UIUXの現場で最先端を走るデザイナーの話を聞くと、彼らの関心が「ビジュアルのクオリティ」だけに留まっていないことが分かります。
AIが単純作業を代替し、例えば基本的なログイン画面などをゼロから制作したり、複雑な画面のレイアウト構造のバリエーション出しなども提案してくれるおかげで、彼らの脳のリソースが空きました。
その空いたリソースで、彼らはどこに向かっているか？
「ビジネス」と「エンジニアリング」への越境です。
「この画面遷移を作ることで、KPIであるCVRはどう変化するのか？」
「このリッチなアニメーションは、Reactのコンポーネント設計として再利用可能なのか？」
「バックエンドのAPIレスポンスを待つ間、ユーザーの不安を取り除くスケルトンスクリーンはどうあるべきか？」
彼らはすでに、ただの「絵作り」の人ではありません。
顧客の期待、エンドユーザーの体験価値、ビジネスの数字まで鑑みて、実装のフィジビリティ（実現可能性）を考慮した設計を提案しようとしています。
ここで、私たちエンジニアやPMは考えなければなりません。
「デザイナーがこちら側に歩み寄っているのに、私たちは彼らの領域に歩み寄らなくていいのか？」と。
デザイナーだけが越境し、エンジニアやPMが「それは自分の仕事じゃない」と壁を作ったままであれば、パワーバランスは不均衡になります。何より、プロダクトとしての強度が上がりません。
UI/UXは「要件」と「実装」と「価値」の変換装置
少し視点を変えて、そもそも「UI/UXデザインとは何か」を再定義してみましょう。
優れたプロダクトには、必ず以下の3つの文脈が統合されています。
- Business（ビジネス）： 顧客の課題は何か？ どうやって収益を上げるか？
- Technology（テクノロジー）： 技術的に何が可能か？ 運用コストやパフォーマンスは？
- Creative（クリエイティブ）： ユーザーはどう感じるか？ 使い心地は？
この3つは、放っておくと互いに矛盾し合います。
ビジネス側は「画面にあらゆる情報を詰め込みたい」と言い、
エンジニアは「処理が重くなるからシンプルにしたい」と言い、
デザイナーは「余白を活かした情緒的な体験にしたい」と言う。
この矛盾を調停し、一つの形としてユーザーに提示するのがUI/UXデザインです。
つまり、UI/UXデザインとは、ビジネスの論理とエンジニアリングの論理を、ユーザーが使いやすい・使いたいと思える形に「変換・翻訳」するプロセスです。
この変換作業を、デザイナー一人に押し付けるのはあまりに酷ではないでしょうか？
ビジネスの深い文脈を把握していないデザイナーに「いい感じの画面にして」と頼んだり、DBの構造を知らないデザイナーに「サクサク動く画面にして」と頼むのは、構造的に無理があります。
だからこそ、ビジネスを知るPMと、技術を知るエンジニアが、UI/UXデザインのプロセスに積極的に参画しなければならないのです。
BTC人材という「新しい標準」へのアップデート
この構造を説明する上で、「BTC人材」というキーワードに触れておきたいと思います。
Business、Technology、Creative。この3つの領域を統合できる人材のことです。
誤解してほしくないのは、BTC人材とは「全ての領域のプロフェッショナルになれ」という意味ではないということです。
そんなことは物理的に不可能ですし、目指すべきでもありません。
「自分のコアとなる専門性（軸足）を持ちながら、隣接する2つの領域の言語を理解し、橋渡しができる人」を指します。
エンジニアなら：技術（T）を軸足に持ちつつ、ビジネス（B）の数字の意味を理解し、クリエイティブ（C）の原則を踏まえて実装できる。
PMなら：ビジネス（B）を軸足に持ちつつ、技術（T）的な実現可否の勘所を持ち、クリエイティブ（C）のプロトタイプで対話できる。
UI/UXは、まさにこのBTCの中心に位置する概念です。
もしあなたがエンジニアなら、エラーメッセージ一つとってもUI/UXに関与できます。
「System Error: 500」と表示するのは、技術的には正解ですが、UI/UXとしてはNGです。
ユーザーが何をしていいかわからない（ビジネス機会の損失）からです。
ここで、「通信が不安定です。しばらく待ってから再読み込みしてください」と表示し、リトライボタンを置く。
これは、技術（エラーハンドリング）とクリエイティブ（マイクロコピー）とビジネス（離脱防止）を統合した、立派なUI/UXの仕事です。
他にも読みやすくデザインガイドラインに従った文字サイズや行間にし、エラーという意味を持たせた色やアイコンで表現するなども考えられます。
「UI/UXはデザイナーの仕事」と切り捨ててしまうエンジニアは、このエラーメッセージの価値に気づけません。
逆に、ここに関与できるエンジニアは、コードの品質だけでなく、プロダクトの価値そのものを高めることができます。
結論：なぜ今、“UI/UXは全員の仕事”になるのか
ここまでの話を整理すると、UI/UXを「全員で」扱うべき理由は以下の3点に集約されます。
分業の限界：従来の分業スタイルはコミュニケーションコストを高め、プロダクトの体験を分断させてしまった。「伝言ゲーム」をやめて、全員が同じテーブルで話せる必要がある。
AIによる越境の容易化：専門的なツールや知識の習得コストがAIによって劇的に下がった。「作れないから関わらない」という言い訳は通用しなくなり、誰もがプロトタイピングや検証に関与できるようになった。
統合の必要性（BTC）：プロダクトの価値は、ビジネス・技術・クリエイティブの統合地点に生まれる。その統合地点こそがUI/UXであり、誰か一人の手には負えない複雑さを持っている。
越境するチームこそ最強
最後に、これからのチームのあり方について触れておきたいと思います。
AI時代に最も高いパフォーマンスを発揮するのは、個々の領域だけに特化したスーパースターが集まったチームではなく、職種を越えて「つながる力」を持ったチームだと思います。
PMが、AIを使ってざっくりとしたワイヤーフレームを描き、要件を視覚的に伝える。
エンジニアが、そのワイヤーを見て「この体験を実現するには、今のAPIだとレスポンスが遅くなるから、先にデータをプリフェッチしよう」と、体験ベースで技術選定をする。
デザイナーが、技術的な制約を理解した上で、「それなら、読み込み中はこういうアニメーションで見せれば体感速度は落ちない」と提案する。
そして、全員でプロトタイプを触りながら、「ここは使いにくい」「ここは気持ちいい」と意見を出す。
これらがシームレスに行われたとき、プロダクトは初めて「切れ目のない、一つの体験」としてユーザーに届くのではないでしょうか。
「越境」とは、自分の専門性を捨てることではありません。
自分の専門性を核にしながら、その価値を最大化するために外側に手を伸ばすことです。
そして、エンジニアやPMが手を伸ばす先として、UI/UXは最も効果的で、面白い領域だと思っています。
明日からできる、小さな一歩
この記事を読んでいただいたエンジニアやPMの方で、もし少しでも「越境してみようかな」と思っていただけたなら、今日からできる小さなアクションがあります。
Figmaのリンクを開いてみる：
デザイナーからもらった画面デザインを見るときに、なぜそのボタンがそこにあるのか、左右の余白と上下の余白が異なるのはなぜか、レイアウトの必然性？などを考えてみてください。
優れたデザイナーは感性ではなく根拠に基づいて画面デザインをしています。
普段使っているアプリ画面でも同じように考えることはできます。
AIに「なぜ？」と聞いてみる：
良いと思ったサービスのスクリーンショットを取って、ChatGPTやGeminiやClaudeに投げてみてください。「なぜこのボタンはここにあるのか？」「画面構成についてUIUXデザイン上の意図を解説して」と聞けば、驚くほど論理的な解説が返ってきます。
それをチームの雑談で共有するだけで、UIの視座は上がります。
「エラー」を「対話」と捉え直す：
例外処理のコードを書くとき、「これはシステムのエラー」ではなく、「ユーザーとの対話が失敗した状態」と捉え直してみてください。ユーザーにどんな言葉をかければ安心するか？ それを考えることは、立派なUXデザインです。
UI/UXは、決してデザイナーだけの領域ではありません。
私たちエンジニアやPMがそこに踏み込み、AIを相棒にしながら、職種の壁を越えて議論する。そうやって作られたプロダクトやサービスが、これからの時代の「標準」になっていくはずです。
ネクストスケープでは、そんな「越境する開発」を楽しんでいければと思っています。
