AIの進化によって、コードを書く、UIをつくる、体験を設計する——その境界が曖昧になる中で、デザインエンジニアという役割が存在感を増しています。
今回のデザインエンジニア Meetup #6では、AI時代のデザインエンジニアの役割をテーマに、estieのデザインエンジニア3名が、日々の開発で感じている変化や、これからのものづくりの可能性についてカジュアルに語りました。
本記事では、当日の内容の一部をご紹介します。
デザインエンジニア Meetupについて
デザインとエンジニアリングを横断して問題解決を行い、プロダクトのデリバリーやアイデア検証を高速に行うデザインエンジニア。しかし、デザインエンジニアの数はまだ限られており、情報共有の機会も多くはありません。
そこでestieでは、デザインエンジニア同士が知見を共有し、交流を深める場として「デザインエンジニア Meetup」を継続的に開催しています。
今回は、AI時代のデザインエンジニアの役割をテーマに、社内でデザインエンジニアとして活躍する3人が登壇しました。
登壇者紹介
Hikaru：UIの情報設計やインタラクションデザインを得意とし、人間や社会の営みに興味を持つデザインエンジニア。不動産業界向けSaaSの開発や、横断的なデザインシステムの整備にも取り組んでいます。
Kyoncy：フロントエンドを軸に、デザインからバックエンドまで幅広く担当。現在は、昨年末に事業譲渡いただいたダイヤモンドテール事業の開発責任者を務めています。
yamarin：フロントエンドを中心にバックエンドまで担当。エンタープライズ向けの開発を担当しています。
AIを日々の開発でどう使っている？
最初のテーマは、「普段、AIをどう使っている？」です。
Hikaru: ドキュメント整備では、骨子を踏まえた肉付けとレビューをAIに任せています。コーディングでは、Claude CodeでドキュメントをSkillとして活用しながら設計・実装しています。
Kyoncy: デザイン・実装に関わることは全部Claudeに寄せました。ドキュメント作成やExcelなどもClaudeを使っています。ただ、骨子を作るところは自分でやるようにしています。
yamarin: ClaudeとCursorを使い分けています。Claudeは機能開発やリファクタリングなど、実装の実行部隊として使っています。Cursorはバグの原因調査や既存仕様の確認、新しい技術を調べながら実装する時など、試行錯誤しながら進めたい場面で使っています。AIのネガティブな癖を発見したらルールで縛るようにもしています。
3人ともAIを日常的に使っていますが、役割分担の考え方はさまざまでした。設計から実装まで幅広く活用しつつ、人が考える部分とAIに任せる部分を切り分けながら開発していることが印象的でした。
AIで作るとアウトプットはどう？課題があればどう向き合っている？
続いては、AIのアウトプットに対する課題感についてです。
Kyoncy: 前提としてWeb制作がメインなので、完璧なものとは程遠いものが出てくることもあります。
サイトマップやムードボードを作るためのSkillを作ったりすることで多少打率が上がる気がしています。
Hikaru: AIのアウトプットは、情報構造的には正しいけど、UIを操作するうえで配置がおかしい場合もあります。見出しが多すぎたり、同じことを何度も記載したり、UIとして説明的になりすぎることもあるので、一旦いまはCursorで手直ししています。
コーディングについては、粗雑なコードが少しでも存在するだけでそれがさらに増殖するので、いわば“無菌室“を維持することが大事。そのためにリファクタやレビューのSkillを作って、それで潰しています。
デザインの知識を体系化・外在化することも重要になってくると思っています。どのAIモデルでも参照できるように分離しておくと、AIの性能のブレに対するリスクヘッジにもなります。
AIでデザインして、それに対する能動的な修正をかける中で、修正意図（デザインの意図）も文書として蓄積し、AIのアウトプットをより良くするための学習に使うサイクルを作っています。GitHub上に自動でMarkdownとして蓄積されるようにしていて、そのためのツールをClaude CodeのSkillとして社内でも配布しています。
yamarin: 詳しく指示をしない限り、AIは既存の実装を踏襲するので、品質には妥協しないようにしています。
Biome、ESLint、Gritなどを使って、内部品質のためのルールをできる限り厳しくしています。ゆくゆくは、よりアーキテクチャ的な観点から全体を監視できる仕組みを作りたいと思っています。
課題に対するHowの案出しはまだ打率が低いですが、grill meという激詰めされるSkillで曖昧な要件を詰めてからやると、多少打率が上がる気がしています。
この話題では、AIのアウトプットに対してそれぞれ課題を感じており、「現状はルールは厳しいほど良い」という点で3人とも一致していました。最近ではPMがコードを書く場面もあり、品質ルールを整備することはエンジニアやデザイナーのレビュー負荷を下げる意味でも重要という話になりました。
AIと人の実装割合は？
会場からは、「AIと人、それぞれどれくらい実装していますか？」という質問もありました。
yamarin: 場合によりますが、5〜9割くらいはAIです。
Hikaru: 自分もAIの割合がかなり上回っています。Figmaは使わず、もともとコーディングしながらデザインすることが多いのでそれも影響しているかもしれません。
Kyoncy: Figmaはお客様との合意形成のために使うことが多いです。ただ、それをベースにした実装は、理想としては10割AIに任せたいと思っています。
AIの活用度合いはそれぞれ異なりますが、実装フェーズではAIが大きな役割を担うようになってきていることが伝わってきました。
開発の進め方ってどう変わった？
AIを前提とした開発によって、開発プロセスそのものも変わってきています。
Hikaru: チケット管理をするよりもとりあえずプロンプトを投げるなど、根本的に進め方が変わっています。
yamarin: 大筋の設計は自分でやりますが、その後の細かい部分はAIに任せています。チケットを切るのもAI、そのチケットから実装するのもAI、解決策の初期案出しもAIです。チケット管理自体は続けています。エンタープライズ開発ではお客様に消化率を伝える意味でも重要なので。
Kyoncy: チームの規模感から、複数案件が並行して進む環境です。自分が細かく見なくても品質を担保できるようにする必要があり、そのための仕組みをAIも使いながら作っていく進め方がメインになっています。
AIは実装だけでなく、要件整理やチケット作成など開発プロセス全体にも入り始めています。一方で、プロダクトやチームの特性に合わせて進め方を選んでいることも印象的でした。
ソフトウェアエンジニアやPM、チームメンバーとの関わり方は変わった？
AIによって、チーム内での役割分担やコミュニケーションにも変化が出てきています。
Kyoncy: 大きな変化はありませんが、1人で見られる範囲は広がりました。
yamarin: PMやデザイナーにもAIで実装してもらう前提でコミュニケーションを取るようになりました。AIを使いながらチケットを詳しく書けば、仕様がはっきりしているタスクは彼らが進められると思っており、自分はレビューとハーネス作りを担当することが増えています。
Hikaru: 情報設計やUIデザインをソフトウェアエンジニア（with Skills）に任せてみて、自分はデザインレビューや修正を担当しています。分業すると情報が薄まったり落ちたりすることがありますが、それが減った気がしています。
デザイン知識のドキュメンテーションも進めています。それをソフトウェアエンジニアに開発でskillなどとして使ってもらい、エンジニア一人でも新規プロダクトが立ち上げられる状態を目指しています。その結果、別チームの支援もしやすくなっています。
AIを前提にすると、「誰が実装するか」だけでなく、「誰でも進められるようにするにはどうすればいいか」という視点も重要になってきていることが伝わってきました。
PMやデザイナーにも実装を任せてるとのことですが、開発スピードは速くなった？
会場からは、「PMやデザイナーにも実装を任せるようになって、開発スピードは速くなったと感じますか？」という質問もありました。
yamarin: 感じます。例えばPMが初期プロトタイプなどの実装を行うと、本来、新機能の仕様の理解にエンジニアがかけていた時間を削れたりするので。
Hikaru: 感じます。検証したい機能を複数並列で作れたりするので。
ドメイン知識がある人が、そのままデザインも実装もできるようにイネーブリングをすることが、エンジニアやデザイナーにとって一つの道かもしれません。従来はコミュニケーションの中でコンテキストが落ちてしまうこともありましたが、そこもカバーできるようになってきています。
デザインエンジニアの役割・価値はどうなっていくと思う？
最後のテーマは、「AI時代に、デザインエンジニアの役割や価値はどう変わっていくと思いますか？」。
Hikaru: 人間の認知システムなどデザインの専門性と、estieの不動産業界のドメイン知識を掛け合わせて、それを外在化（ドキュメント化）することで、みんながアクセスしやすく活用しやすい状態を作っていく動き方になっていくと思っています。
これからは、ユーザーのメンタルモデルを理解することの重要性が増していくとも思っています。AIの進化自体は速いですが、人間が持つ認知モデルは同じスピードでは変わりません。AIプロダクトを導入しても、スイッチコストを乗り越えられず「使いこなせない」とユーザーが思ってしまうこともあると思っています。だからこそ、どうしたらAIプロダクトが持つ新しい体験に馴染めるようになるのか、人間に対する理解を持つことがデザイン職の役割になっていくのではないでしょうか。
Kyoncy: UIの構築にとどまらず、パフォーマンス最適化も含めて、体験に関わるすべてが責任範囲だと考えています。
yamarin: ユーザー体験を設計するだけではなく、その体験を監視していくことも重要になると思っています。例えばパフォーマンスを常に監視するといったことです。
それと同時に、自分だけができる状態ではなく、他のメンバーも同じ領域をできるようにしていきたいと思っています。それはデザインエンジニアに限りません。
デザインやエンジニアリングに閉じず、できることは何でもやる。そして、もっとお客さんと向き合って課題発見をしていきたいです。
「デザインエンジニア」という言葉から想像する役割は、人によって少しずつ違います。それでも3人とも、AI時代だからこそ人間理解や体験設計、知識の共有など、UIや実装だけではない価値が重要になっていくという点で共通していました。
PRD（プロダクト要求仕様書）は使っていますか？
最後は、会場から寄せられた「PRD（プロダクト要求仕様書）は使っていますか？」という質問です。
yamarin: 作っていないことが多いです。基本はデザイナーと仕様を決めつつ、細かいユーザー体験などはgrill meで決めています。
Hikaru: PMから受け取ることはあります。PRDを引数とするskillを作ったので、受け取った場合はそれを使っています。ユーザーストーリーや既存画面のパス、ユーザーが何を問題と思っているのかを入力として渡すと、それをベースにユーザーの行動や状況を整理して情報設計をしてくれるSkillです。それをベースにUIのパターンを決めていきます。
Kyoncy: 小さく作り込んでいくことが多いので、PRDは使っていません。
開発スタイルはそれぞれ違いますが、固定のドキュメントを作り込むよりも、その場でAIやSkillを活用しながら要件を整理していくという進め方が印象的でした。
おわりに
AIの進化によって、コードを書くことも、UIをつくることも、以前よりずっと身近になりました。
今回のMeetupでは、AIをどう使うかだけでなく、AIを前提にどう開発を進めるのか、品質をどう担保するのか、知識をどう蓄積するのか、そしてデザインエンジニアはどんな価値を発揮していくのかまで、さまざまな視点から議論が交わされました。
デザインエンジニア Meetupは、実践を持ち寄り、知見を共有し、交流を深める場として今後も継続して開催していきます。
ご参加いただいた皆さま、ありがとうございました！
estieではデザインエンジニアを募集中！
estieではデザインエンジニア組織を拡大しており、新たな仲間を募集しています。
少しでもestieに興味を持っていただけた方は、ぜひカジュアルにお話ししましょう！
