職域を超えるデザイン – AI時代のデジタルプロダクトデザイン戦略
本記事は、AI時代のデジタルプロダクト開発において、デザイナーとエンジニアが職域を超えて連携する具体的な設計戦略とチーム体制の構築方法を解説している。
キーポイント
AI開発における職域融合の必要性
従来の決定論的なソフトウェア開発とは異なり、AIの不確実性（確率的出力）を扱うため、デザイナーとエンジニアの早期かつ継続的な連携がプロダクト品質を左右する。
共創プロセスと共通言語の構築
開発初期段階から双方が関与し、ドメインモデルや評価指標を共有することで、技術制約とユーザー体験のバランスを取れる設計フローが提唱されている。
組織文化とツール活用の重要性
単なるツールの導入ではなく、意思決定の透明性を高め、失敗を許容する組織文化と適切な協働プラットフォームの整備が長期的な競争力につながると指摘している。
AI特性を考慮したプロダクト設計手法
確率的なモデル出力をUI/UXに組み込むため、従来の固定画面設計を見直し、ユーザーへの説明責任と制御可能性を担保するインタラクション設計が必須となる。
影響分析・編集コメントを表示
影響分析
本記事は、AIモデルの性能競争が激化する現代において、いかに人間とシステムの協働を設計するかがプロダクト勝敗の分かれ目であることを示唆している。技術スタックの進化だけでなく、開発プロセスと組織文化の再構築が業界標準となりつつある現状を正確に捉えており、ミドル〜エンタープライズ規模のテック企業におけるプロダクト開発体制の見直しに直接的な示唆を与える。
編集コメント
技術革新そのものよりも、組織体制と開発プロセスの再構築に焦点を当てた実務的な示唆が得られる記事である。AIモデルの性能競争が激化する中、いかに人間とシステムの協働を設計するかが今後のプロダクト勝敗を分ける鍵となる。
AmebaLIFE事業本部のデジタルプロダクトデザインリードの本田です。
今回は、近年我々が取り組んでいるデザイナーの職域越境事例について、少しご紹介したいと思います。
我々のようなデジタルプロダクトの開発に携わる人間にとって今最も欠かせない話題、それはAIです。
私はAmebaLIFEでデザインシステムSpindleを作成、運用しているのですが、デザインシステムの域を超えて技術戦略も考えていることもあって、AIに対して我々はどういう姿勢を取れば良いのか、AIを組み込んだ先にどういう状態が待っているかを想像する責務がありました。
当初から、AIはそれを使うこと自体をゴールせず、結果として何を招くか、という点を注視しなければならないと意識していましたが、そんな中で私がAIによって最も大きく変わるなと予想したのは「業界の価値観」です。
デジタルプロダクトの業界は日進月歩の進化をしています。その過程で、より速く、より正確に、より良いものを提供するための考え方や決まりごとも同時に定まって定石となっていますが、その代表たるものが「職域」です。
我々がデザイナー、エンジニア、PMと職種に区切りをつけているのは、その専門性を先鋭化させてそれぞれの役割を全うし、学習コストや専門性を分掌することで、精度と効率性を高めるためでした。ただ、同時に多職種への介入は難しく、二倍以上の知識や経験値を積まないと、二足のわらじをはくのは困難だったと言えます。
気がつけば自分も「デザイナー」という肩書の下、既成概念として定められた枠組みの中で何ができるかを考え続けてしまっていました。
しかし、AIの台頭によってその壁が打ち破られることになります。学習コストが著しく下がり、AIが汎用的な作業を肩代わりできるようになった結果、デザイナーがコードを書いてもいい時代、エンジニアがデザインをしても良い時代に移り変わりました。
そして、開発ワークフローに明確にAIが組み込まれることによって、AIを主体としたワークフローが生まれ、「誰が何をやるか」は希薄になってきました。これが大きく変わった価値観の部分です。
一方で大局的に変わらない部分もあります。それは良いアウトカムを追求する事です。
人々は本質的に良いアウトカムを求めています。結果に至るまでの過程は、アウトカムという本質的な結果を得るための手段にすぎず、どのような構造であっても良い結果が導かれるのであればそこに至る構造は柔軟であって良いとも言えます。
そのためより良い本質を得るために今までのしがらみを一切合切取り払えるとしたら、我々一人一人は何をすれば良いのか、というところを柔軟かつフラットに、今までの既存概念を再解釈した上で考える必要があります。
職域の越境について
デザイナーとして自らの職域について考えた時、成果物が中間成果物に閉じてしまっていて最終成果物に関与しきれていないことに日々、違和感を感じていました。
勿論、デザイナーとして体験設計やUI設計した意図や狙いはエンジニアの手によって、実装され世の中に流布し、ユーザーの方にわたることで、本懐は達成していると言えるのですが、実際に世の中に流通する最終成果物はコードの集積たるプログラムです。デザイナーとしての私はそこに直接的な介入をすることができませんでした。
他職種にアウトプットを移譲しているがゆえに、コストの高いデザインのこだわりによって開発工数が伸びたり、実装で苦労をかけることはできるだけ避けなければなりません。
そのため、エンジニアの方に意図や仕様が伝わるように、限りなく丁寧なデザイン仕様書をデザインツールで作ることを生業としているところがありました。
しかしながら、それはどこまで丁寧に行っても自分と他人、デザイナーとエンジニアの関係であり、完全にシンクロすることは容易ではありません。
遠慮や配慮やコストの最適化によってクオリティが100ではなく90,95ぐらいになることは多かったと感じています。
それは現場においては最善の判断だったかもしれませんが、プロダクトを受け取るユーザーの方にとっては、最終的なアウトプットが全てあり、そこに責務を持てなければいけないはずです。
ですが、AIの台頭によって、デザイナーでもコードに干渉できると考えた時、その言い訳は全て虚空に消えました。自分で実装して、自分で責任を負うことができることによって打開が可能になったからです。
実践事例(AmebaLIFE事業本部公式サイト)の紹介
ここからは実践事例についてお話します。
私が最初にAIの力で職域を越境した事例が、AmebaLIFE事業本部公式サイトです。
AmebaLIFE事業本部公式サイト
このサイトは、AIが台頭する前に発生した企画であり、従来のワークフロー通り、モックアップでデザインをfixさせたあとにエンジニアの方に全て実装をお願いする想定で考えていました。
しかし、先述した通り、アニメーションの意図をエンジニアの方に正確に伝えるのはなかなかコストがかかる作業ですし、モックアップで作ったデザインデータは、レスポンシブでは作れなかったり、ツールによってプロパティの不足があり、完全なCSSアニメーションの再現にいたらなかったり、パフォーマンスの観点でできることとできないことがあったりと、どんなに綿密に設計したとしても実装時点でアニメーションの修正が発生したり意図と違う挙動をしてしまうことが多発していました。
その後しばらくして、AI活用が進む中でCursorのVisualEditorがリリースされたという報が届きます。
Cursor Browser 向けビジュアルエディタの紹介動画より
実際のコードを元に、ブラウザ上でページを確認しながらデザインの調整を行えるこのツールは、デザイナーが実務でコーディングを行う職域越境の足がかりとしては十分なものでした。
そこから取ったアクションは以下です。
- まずデザインを用意する。この時点で情報設計は完了し、Document構造として破綻がない状態を確定させる。
- そのデザインをもとに、エンジニアの方に環境構築、技術選定、たたき台としてデザインを起こしてもらう。この時点ではアニメーションはほぼついておらず、要素の並びとスタイルだけ概ねあたっている状態。
- そのファイルをデザイナーである自分に譲ってもらう。
- デザイナーである自分が、Cursorでスクロールアニメーション、Hoverアニメーション、スタイルの調整、レスポンシブの調整など、一通りコード修正を行う。
- エンジニアの方に戻し、コードレビューをしてもらい差分をマージ。
デザイナーとして日々思っていたのは、やはりモックアップでデザインを見た時と実機で見た時には明確に差がある、ということです。モック上で見たデザインが完璧だと思っても、いざ実機で確認するとmarginが広すぎたり、文字が小さすぎたりと、大抵の場合引っかかるところが多いです。
これまでは、後からのデザイン修正は正直場を混乱させかねないため、修正は最小に抑えるために配慮していた点が多く、本番環境での違和感も見過ごしている箇所が多かったのですが、今回は自分で見つけた粗は自分で拾うだけです。
思う存分リテイクを自分にかけました。hoverのアニメーションも最初はシンプルなフェードイン・フェードアウトを想定していたのですが、実機で触れてみた結果、ちょっとした遊び心を加えたくなったのでカーソルの位置を取得してそこから広がるようなアニメーションを追加したりしました。
ボタンのHoverアニメーション
自分で責任を負うことによってどんなにコストの高いデザインやわがままも言えるということで、クオリティに妥協しない姿勢を体現できました。ここの開発体験は素晴らしかったと言えます。
自分で手を動かす以上、他者への遠慮でクオリティを妥協する必要がなくなります。もちろんスケジュールやパフォーマンスの制約はありますが、その範囲の中で納得いくまで詰められる自由さはデザイナーが等しく体験すべきだなと思いました。
また、About Usページのメインビジュアルでも使われているラインのアニメーションでも、デザイナーならではの意地を詰め込みました。
About Usページにかかる曲線(通称LIFE line)
この線の軌跡は、SVGアニメーションで描画しているのですが、線がくるっと一回転するところで色が交差しているため、シンプルに実装でグラデーションを乗せると最後の結び目の部分の色の重なりが再現できません。
そこで、SVGのパスの軌跡を変化する座標郡として捉え、Xの値が負に転じるタイミングでパスをカットし、3本の線の描画を連続させることで「線の交差」を実現しました。
線を3セクションに分割する
しかし、この状態だと今度はアニメーションがスムーズにかかりません。
このパスの軌跡は、全体にEasingCurveがかかっており、3本の線を連続でアニメーションさせるにあたってはEasingCurveを分断する必要があります。3本の線はそれぞれ長さも異なるので、そのまま同じDurationを当て込むと、長いパスは速く、短いパスはゆっくりうごいてしまい、ぎこちないアニメーションになってしまいます。
そこで、ベジェ曲線の長さを近似計算してもらって、それにあわせて全体のeasingをパスごとにdurationで分割し、プロットしてもらうことで、断片的なパスに対して連続的なスムーズなアニメーションを付与することができるようになりました。
考え方
複数パスは 見た目・都合（グラデーションの切り替えなど）で分割しているが、「一本の線が描かれていく」体験は1本のタイムラインで表現する。
そのため 全体の進み（0→1）を1つだけ用意し、イージングも その1本にだけかける。各パスは「全体の進みのうち、自分の区間だけを担当」し、区間の幅は 実パスの長さの比率にする。こうすると 技術的には分割アニメーション、知覚的には連続の一本になる。
手法
各パスの getTotalLength() で長さを取り、合計に対する 開始・終了の割合（0〜1） を配列にしておく。
requestAnimationFrame で経過時間から 線形の t を出し、easeOutCubic(t) で globalProgress にする。
各フレームで、各パスについて globalProgress が自分の区間内なら 区間内で 0→1 に正規化した値を pathProgress とし、それに応じて stroke-dashoffset だけ更新。区間外は 0 または 1 で固定。
トリガーは IntersectionObserver（ビューに入ったら totalDuration 秒のループを1回）。
要するに 「一本の進捗」を長さ比例でパスに割り振り、各パスは dash で自分の担当分だけ描く」 ようにした。
こういう細かいこだわりは、デザイナー自身でコーディングまで担えるからこそやり切れた部分だと言えます。
一方で、全てをデザイナーだけで完遂することはまだできないとも感じています。
まず、コードレビューは当然エンジニアの方にお願いしています。AIの書いたコードには、簡単な問題がよく見られます。悩んだ時に!importantを使って無理やり解決しようとする、tokenを使わずに色をハードコードする、共通化できそうな関数を共通化しない、CSSで作れそうなところにもJSを入れて実装してしまう…など。デザイナーとして、できるだけAIがどのようなことをしようとしているのか、自ら意図を確認した上で実装しているのですが、コードの最適化に関してはまだレビューが必要です。
また、今回の事例の場合、ブラウザの環境によるレンダリングのバグがあったのですが、それも最終エンジニアの方の助けを得なければ解消しませんでした。Safariのみでアニメーションのフレームレートが著しく落ちる事例が発生し、あまりにも原因が分からずかなり時間を費やしてAIに検証させたのですが最後までわからずさじを投げた件があったのですが、エンジニアの方にヒアリングしてみたところ、レンダリングコストが高い要素が二重に重なっている部分が原因であると仮説を立ててくれ、それに則って原因と思われる箇所を取り除きスムーズに動くようになったことがありました。経験による仮説立てはやはりエンジニアの方にお世話になったポイントでした。
さらに、DOM設計、技術選定、CMSの管理や繋ぎ込みもエンジニアの方に前提お願いしています。将来的な拡張性や保守性を意識した最適なベース設計は、知識なく行うとリスクを孕むことになります。
保守運用の部分、最後の守りの部分はどんなにAIが発達しても丸投げというわけには行きません。そこはどこまで行っても専門の方にお願いする領域なのかなと思っています。
感想
繰り返しになりますが、このプロジェクトで職域を越境したことで、デザイナー目線での開発体験はかなり向上しました。
自分で自分に無理を言うことによってクオリティに妥協する余地をなくすということもそうですし、単純にコミュニケーションコストが減り、それぞれの職種がそれぞれの専門領域に向き合えるということにおいてもより本質的なワークフローだったのかなと思います。
そして何より、自分自身で実装を行うことで、今までどれだけめんどくさいことをお願いしていたのか身をもって体感することになります。いくらAIに任せられると言っても、思い通りにできることは3回に1回ぐらい、それでも十分ですが、上手くいかなった時はかなり頭を回転させる必要があります。
どの要素がレイアウトを崩しているのか把握するため、デバッグ用に要素に色をつけてみたりとか、怪しい箇所を片っ端から削除して問題を特定したりとか、ブラウザの仕様を調べたりとか、どうしても上手くいかない場合は他の手段を再考したりとか、コーダーとしての思考に切り替えデバッグモードに入らなければいけないことが多々ありました。
また、この件を通じてCSSのプロパティもだいぶ覚えたり、ViewTransitionの仕様を把握したりと、コーディングの知識も必要に応じて覚えながら取り組まなければいけないということがあり、よくも悪くもしっかり職域を越境するコストは払わなければいけないということも感じました。
それでも、越境がより本質的な開発を実現するという確信を得られたのは大きな収穫でした。現在進行中の他プロジェクトでは自らGitHub上でプロジェクトを管理し、PRを出してエンジニアの方にレビューいただくという、エンジニアリングのワークフローに則って作業しており、職域が溶けている感覚を日々痛感しています。（こちらでも少し触れていますコードとデザインを自由に行き来する ー Figma MCP × AIエージェントがもたらしたSpindle開発フローの変化）
果たしてこれからのデザイナーという職域がどこにどう広がっていき定着していくのか、まだ確信めいたことを言うことはできませんが、自分なりに未来のデザイナー像を目指してあれこれ試してみようと思っています。
原文を表示
AmebaLIFE事業本部のデジタルプロダクトデザインリードの本田です。
今回は、近年我々が取り組んでいるデザイナーの職域越境事例について、少しご紹介したいと思います。
我々のようなデジタルプロダクトの開発に携わる人間にとって今最も欠かせない話題、それはAIです。
私はAmebaLIFEでデザインシステムSpindleを作成、運用しているのですが、デザインシステムの域を超えて技術戦略も考えていることもあって、AIに対して我々はどういう姿勢を取れば良いのか、AIを組み込んだ先にどういう状態が待っているかを想像する責務がありました。
当初から、AIはそれを使うこと自体をゴールせず、結果として何を招くか、という点を注視しなければならないと意識していましたが、そんな中で私がAIによって最も大きく変わるなと予想したのは「業界の価値観」です。
デジタルプロダクトの業界は日進月歩の進化をしています。その過程で、より速く、より正確に、より良いものを提供するための考え方や決まりごとも同時に定まって定石となっていますが、その代表たるものが「職域」です。
我々がデザイナー、エンジニア、PMと職種に区切りをつけているのは、その専門性を先鋭化させてそれぞれの役割を全うし、学習コストや専門性を分掌することで、精度と効率性を高めるためでした。ただ、同時に多職種への介入は難しく、二倍以上の知識や経験値を積まないと、二足のわらじをはくのは困難だったと言えます。
気がつけば自分も「デザイナー」という肩書の下、既成概念として定められた枠組みの中で何ができるかを考え続けてしまっていました。
しかし、AIの台頭によってその壁が打ち破られることになります。学習コストが著しく下がり、AIが汎用的な作業を肩代わりできるようになった結果、デザイナーがコードを書いてもいい時代、エンジニアがデザインをしても良い時代に移り変わりました。
そして、開発ワークフローに明確にAIが組み込まれることによって、AIを主体としたワークフローが生まれ、「誰が何をやるか」は希薄になってきました。これが大きく変わった価値観の部分です。
一方で大局的に変わらない部分もあります。それは良いアウトカムを追求する事です。
人々は本質的に良いアウトカムを求めています。結果に至るまでの過程は、アウトカムという本質的な結果を得るための手段にすぎず、どのような構造であっても良い結果が導かれるのであればそこに至る構造は柔軟であって良いとも言えます。
そのためより良い本質を得るために今までのしがらみを一切合切取り払えるとしたら、我々一人一人は何をすれば良いのか、というところを柔軟かつフラットに、今までの既存概念を再解釈した上で考える必要があります。
職域の越境について
デザイナーとして自らの職域について考えた時、成果物が中間成果物に閉じてしまっていて最終成果物に関与しきれていないことに日々、違和感を感じていました。
勿論、デザイナーとして体験設計やUI設計した意図や狙いはエンジニアの手によって、実装され世の中に流布し、ユーザーの方にわたることで、本懐は達成していると言えるのですが、実際に世の中に流通する最終成果物はコードの集積たるプログラムです。デザイナーとしての私はそこに直接的な介入をすることができませんでした。
他職種にアウトプットを移譲しているがゆえに、コストの高いデザインのこだわりによって開発工数が伸びたり、実装で苦労をかけることはできるだけ避けなければなりません。
そのため、エンジニアの方に意図や仕様が伝わるように、限りなく丁寧なデザイン仕様書をデザインツールで作ることを生業としているところがありました。
しかしながら、それはどこまで丁寧に行っても自分と他人、デザイナーとエンジニアの関係であり、完全にシンクロすることは容易ではありません。
遠慮や配慮やコストの最適化によってクオリティが100ではなく90,95ぐらいになることは多かったと感じています。
それは現場においては最善の判断だったかもしれませんが、プロダクトを受け取るユーザーの方にとっては、最終的なアウトプットが全てあり、そこに責務を持てなければいけないはずです。
ですが、AIの台頭によって、デザイナーでもコードに干渉できると考えた時、その言い訳は全て虚空に消えました。自分で実装して、自分で責任を負うことができることによって打開が可能になったからです。
実践事例(AmebaLIFE事業本部公式サイト)の紹介
ここからは実践事例についてお話します。
私が最初にAIの力で職域を越境した事例が、AmebaLIFE事業本部公式サイトです。
AmebaLIFE事業本部公式サイト
このサイトは、AIが台頭する前に発生した企画であり、従来のワークフロー通り、モックアップでデザインをfixさせたあとにエンジニアの方に全て実装をお願いする想定で考えていました。
しかし、先述した通り、アニメーションの意図をエンジニアの方に正確に伝えるのはなかなかコストがかかる作業ですし、モックアップで作ったデザインデータは、レスポンシブでは作れなかったり、ツールによってプロパティの不足があり、完全なCSSアニメーションの再現にいたらなかったり、パフォーマンスの観点でできることとできないことがあったりと、どんなに綿密に設計したとしても実装時点でアニメーションの修正が発生したり意図と違う挙動をしてしまうことが多発していました。
その後しばらくして、AI活用が進む中でCursorのVisualEditorがリリースされたという報が届きます。
Cursor Browser 向けビジュアルエディタの紹介動画より
実際のコードを元に、ブラウザ上でページを確認しながらデザインの調整を行えるこのツールは、デザイナーが実務でコーディングを行う職域越境の足がかりとしては十分なものでした。
そこから取ったアクションは以下です。
- まずデザインを用意する。この時点で情報設計は完了し、Document構造として破綻がない状態を確定させる。
- そのデザインをもとに、エンジニアの方に環境構築、技術選定、たたき台としてデザインを起こしてもらう。この時点ではアニメーションはほぼついておらず、要素の並びとスタイルだけ概ねあたっている状態。
- そのファイルをデザイナーである自分に譲ってもらう。
- デザイナーである自分が、Cursorでスクロールアニメーション、Hoverアニメーション、スタイルの調整、レスポンシブの調整など、一通りコード修正を行う。
- エンジニアの方に戻し、コードレビューをしてもらい差分をマージ。
デザイナーとして日々思っていたのは、やはりモックアップでデザインを見た時と実機で見た時には明確に差がある、ということです。モック上で見たデザインが完璧だと思っても、いざ実機で確認するとmarginが広すぎたり、文字が小さすぎたりと、大抵の場合引っかかるところが多いです。
これまでは、後からのデザイン修正は正直場を混乱させかねないため、修正は最小に抑えるために配慮していた点が多く、本番環境での違和感も見過ごしている箇所が多かったのですが、今回は自分で見つけた粗は自分で拾うだけです。
思う存分リテイクを自分にかけました。hoverのアニメーションも最初はシンプルなフェードイン・フェードアウトを想定していたのですが、実機で触れてみた結果、ちょっとした遊び心を加えたくなったのでカーソルの位置を取得してそこから広がるようなアニメーションを追加したりしました。
ボタンのHoverアニメーション
自分で責任を負うことによってどんなにコストの高いデザインやわがままも言えるということで、クオリティに妥協しない姿勢を体現できました。ここの開発体験は素晴らしかったと言えます。
自分で手を動かす以上、他者への遠慮でクオリティを妥協する必要がなくなります。もちろんスケジュールやパフォーマンスの制約はありますが、その範囲の中で納得いくまで詰められる自由さはデザイナーが等しく体験すべきだなと思いました。
また、About Usページのメインビジュアルでも使われているラインのアニメーションでも、デザイナーならではの意地を詰め込みました。
About Usページにかかる曲線(通称LIFE line)
この線の軌跡は、SVGアニメーションで描画しているのですが、線がくるっと一回転するところで色が交差しているため、シンプルに実装でグラデーションを乗せると最後の結び目の部分の色の重なりが再現できません。
そこで、SVGのパスの軌跡を変化する座標郡として捉え、Xの値が負に転じるタイミングでパスをカットし、3本の線の描画を連続させることで「線の交差」を実現しました。
線を3セクションに分割する
しかし、この状態だと今度はアニメーションがスムーズにかかりません。
このパスの軌跡は、全体にEasingCurveがかかっており、3本の線を連続でアニメーションさせるにあたってはEasingCurveを分断する必要があります。3本の線はそれぞれ長さも異なるので、そのまま同じDurationを当て込むと、長いパスは速く、短いパスはゆっくりうごいてしまい、ぎこちないアニメーションになってしまいます。
そこで、ベジェ曲線の長さを近似計算してもらって、それにあわせて全体のeasingをパスごとにdurationで分割し、プロットしてもらうことで、断片的なパスに対して連続的なスムーズなアニメーションを付与することができるようになりました。
考え方
複数パスは 見た目・都合（グラデーションの切り替えなど）で分割しているが、「一本の線が描かれていく」体験は1本のタイムラインで表現する。
そのため 全体の進み（0→1）を1つだけ用意し、イージングも その1本にだけかける。各パスは「全体の進みのうち、自分の区間だけを担当」し、区間の幅は 実パスの長さの比率にする。こうすると 技術的には分割アニメーション、知覚的には連続の一本になる。
手法
各パスの getTotalLength() で長さを取り、合計に対する 開始・終了の割合（0〜1） を配列にしておく。
requestAnimationFrame で経過時間から 線形の t を出し、easeOutCubic(t) で globalProgress にする。
各フレームで、各パスについて globalProgress が自分の区間内なら 区間内で 0→1 に正規化した値を pathProgress とし、それに応じて stroke-dashoffset だけ更新。区間外は 0 または 1 で固定。
トリガーは IntersectionObserver（ビューに入ったら totalDuration 秒のループを1回）。
要するに 「一本の進捗」を長さ比例でパスに割り振り、各パスは dash で自分の担当分だけ描く」 ようにした。
こういう細かいこだわりは、デザイナー自身でコーディングまで担えるからこそやり切れた部分だと言えます。
一方で、全てをデザイナーだけで完遂することはまだできないとも感じています。
まず、コードレビューは当然エンジニアの方にお願いしています。AIの書いたコードには、簡単な問題がよく見られます。悩んだ時に!importantを使って無理やり解決しようとする、tokenを使わずに色をハードコードする、共通化できそうな関数を共通化しない、CSSで作れそうなところにもJSを入れて実装してしまう…など。デザイナーとして、できるだけAIがどのようなことをしようとしているのか、自ら意図を確認した上で実装しているのですが、コードの最適化に関してはまだレビューが必要です。
また、今回の事例の場合、ブラウザの環境によるレンダリングのバグがあったのですが、それも最終エンジニアの方の助けを得なければ解消しませんでした。Safariのみでアニメーションのフレームレートが著しく落ちる事例が発生し、あまりにも原因が分からずかなり時間を費やしてAIに検証させたのですが最後までわからずさじを投げた件があったのですが、エンジニアの方にヒアリングしてみたところ、レンダリングコストが高い要素が二重に重なっている部分が原因であると仮説を立ててくれ、それに則って原因と思われる箇所を取り除きスムーズに動くようになったことがありました。経験による仮説立てはやはりエンジニアの方にお世話になったポイントでした。
さらに、DOM設計、技術選定、CMSの管理や繋ぎ込みもエンジニアの方に前提お願いしています。将来的な拡張性や保守性を意識した最適なベース設計は、知識なく行うとリスクを孕むことになります。
保守運用の部分、最後の守りの部分はどんなにAIが発達しても丸投げというわけには行きません。そこはどこまで行っても専門の方にお願いする領域なのかなと思っています。
感想
繰り返しになりますが、このプロジェクトで職域を越境したことで、デザイナー目線での開発体験はかなり向上しました。
自分で自分に無理を言うことによってクオリティに妥協する余地をなくすということもそうですし、単純にコミュニケーションコストが減り、それぞれの職種がそれぞれの専門領域に向き合えるということにおいてもより本質的なワークフローだったのかなと思います。
そして何より、自分自身で実装を行うことで、今までどれだけめんどくさいことをお願いしていたのか身をもって体感することになります。いくらAIに任せられると言っても、思い通りにできることは3回に1回ぐらい、それでも十分ですが、上手くいかなった時はかなり頭を回転させる必要があります。
どの要素がレイアウトを崩しているのか把握するため、デバッグ用に要素に色をつけてみたりとか、怪しい箇所を片っ端から削除して問題を特定したりとか、ブラウザの仕様を調べたりとか、どうしても上手くいかない場合は他の手段を再考したりとか、コーダーとしての思考に切り替えデバッグモードに入らなければいけないことが多々ありました。
また、この件を通じてCSSのプロパティもだいぶ覚えたり、ViewTransitionの仕様を把握したりと、コーディングの知識も必要に応じて覚えながら取り組まなければいけないということがあり、よくも悪くもしっかり職域を越境するコストは払わなければいけないということも感じました。
それでも、越境がより本質的な開発を実現するという確信を得られたのは大きな収穫でした。現在進行中の他プロジェクトでは自らGitHub上でプロジェクトを管理し、PRを出してエンジニアの方にレビューいただくという、エンジニアリングのワークフローに則って作業しており、職域が溶けている感覚を日々痛感しています。（こちらでも少し触れていますコードとデザインを自由に行き来する ー Figma MCP × AIエージェントがもたらしたSpindle開発フローの変化）
果たしてこれからのデザイナーという職域がどこにどう広がっていき定着していくのか、まだ確信めいたことを言うことはできませんが、自分なりに未来のデザイナー像を目指してあれこれ試してみようと思っています。