膨大な情報を参照し、一定の「解」を見つけ出す生成AIは、私たちの日々の仕事を劇的に変えつつあります。デザイナーももちろん例外ではなく、業務の効率化や拡張に挑戦する人も増えたのではないでしょうか。
Goodpatch Blogでも日々、デザイナーの新たな挑戦を記事として取り上げていますが、先日公開して反響があった「Claude Codeでデザインのワークフローを変えたら、役割の境界が融けていった話」について、実際のプロジェクトメンバーに詳しい話を聞くことができました。
今回、お話を伺ったのは、エス・エム・エスのカイポケリニューアルプロジェクトで、実際に生成AIをフル活用しているフロントエンドエンジニアとUIデザイナーの2人。UIデザイナーがいかにして「開発」の領域に越境をしていったのか。
AIを活用した開発体制と生成AI時代における専門職の存在意義について語ってもらいました。個人が仕事の領域を拡大し、職種という概念があいまいになる中、専門職に求められるスキルや仕事の進め方はどう変わるのでしょうか。
＜話し手＞
株式会社エス・エム・エス フロントエンドエンジニア 泉澤さん
Goodpatch UI/UXデザイナー 矢吹
正直、キャリアへの不安もあった──UIデザイナーがフロントエンドの開発に挑戦した理由
──今回は「カイポケ」のリニューアルプロジェクトにおいて、UIデザイナーが生成AIを使いながら、フロントエンドの開発にも挑戦した、というお話を聞かせていただければと思います。先日、Goodpatch Blogでこのエピソードを紹介した記事が話題を集めましたが、今日はよりリアルな話を聞かせてください。今回取り上げるのは、リニューアルプロジェクトの中で開発が進められている「カイポケコネクト」です。早速ですが、泉澤さんはこのプロジェクトの中で、どういった役割を担っているのでしょうか。
エス・エム・エス 泉澤さん：
エス・エム・エスでフロントエンドエンジニアを務める泉澤です。弊社が提供しているカイポケコネクトは、介護/障害福祉事業者向けの経営支援サービスで、私はその中でもケアマネジャー（介護支援専門員）向けの業務支援機能の開発を担当しています。
株式会社エス・エム・エス フロントエンドエンジニア 泉澤さん
──ナスカ（矢吹）さんは、グッドパッチのUIデザイナーとして、このリニューアルプロジェクトに参画しているわけですが、どういう経緯で開発に挑戦することになったのでしょう。
エス・エム・エス 泉澤さん：
きっかけは、タスクの兼ね合いなどで、チームのフロントエンドエンジニアのリソースが一時的に不足したことです。フロントエンドエンジニアの参加する会議を減らすなど、負荷を下げるような調整もしていたのですが、ナスカさんが「私がやりたい」と手を挙げてくれたので、お願いすることにしました。
Goodpatch 矢吹：
当時は、生成AIによってデザイナーの仕事の一部がカバーできると話題になっていたタイミングで。私自身、今後のキャリアを考えて「UIデザイン以外のスキルも必要になるのかな」と危機感を抱いていたんです。開発チームの会議でも、新しいツールや手法に挑戦したいという相談はしていました。
あと、実際に業務においても、ちょっとした画面の修正でも、エンジニアの方に依頼して、レビューを受けて、実装してもらって……と彼らの時間を使わせてしまっているのが申し訳ないと思っていて。ちょうど新規画面のデザインが落ち着いたタイミングでもあったので、フロントエンドエンジニアの皆さんのサポートに入れたらと考えていました。
──なるほど。とはいえ、いきなりデザイナーに開発を頼むというのは勇気がいりますよね。
エス・エム・エス 泉澤さん：
そうですね。カイポケコネクトの開発チームには、挑戦者を応援する文化がありますし、ナスカさんには、ボタン内の文言修正やデザイントークンの変更といった作業をやっていただいた経験もありました。
フロントエンドエンジニアのリソース不足がチームのボトルネックになりかけていたからこそ、目先のコストを払ってでもナスカさんに育ってもらい、中長期的にその不足を解消したい、という判断になりました。
──ナスカさんは、開発をやること自体に対して不安はなかったですか？
Goodpatch 矢吹：
経験があると言っても、当時は意味も分からずにエンジニアの皆さんから言われた指示をそのまま入力するだけだったので……。GitHubを触ったこともなかったですし、ターミナル（コマンドを入力する黒い画面）を見るとアレルギー反応が出るレベルでした（笑）。
エンジニアからのフルサポートを受けて、1PBIの開発に挑戦
──ある意味で「新人」を指導するようなものだったのかもしれませんが、最初はどこから始めたのでしょうか？
エス・エム・エス 泉澤さん：
一言でフロントエンド領域の開発といっても、軽微な修正からバックエンドの接続まで幅が広いです。ナスカさんがどこまでの領域に興味があるのか、そして実際にできるのかを確かめるところから始めようと。
そこで、まずは普段僕らが行っているスクラムでPBI（プロダクトバックログアイテム）を一つ担当してもらい、それを実現するためのタスクに落とし込みながら開発に取り組んでもらいました。分からないことがあったら、僕が都度相談に乗るという形で。
Goodpatch 矢吹：
泉澤さんには、1スプリントにあたる2週間、2人で1つのプログラムの実装を行うペアプログラミング形式で開発を教えてもらいました。
開発のデモンストレーションはGoogle Meetで行って議事録を作る、泉澤さんに教えてもらったショートカットやステップもセッション（作業履歴）に残すなど、全ての作業履歴をClaude Codeに集約しました。こうすればClaude Codeにセッションが残るので、分からないことは何度も確認できますし、自分の癖や間違いやすい部分も指摘してもらえます。
でも最初はClaude Codeの生成が正しいか自分で判断できないので、「コードを変えて、システムが壊れたら怖い」「今はどのブランチで作業しているの？本番環境に書き込まれない？」と、泉澤さんに逐一確認しながらおそるおそる作業していました。
Goodpatch UI/UXデザイナー 矢吹
エス・エム・エス 泉澤さん：
Claude Codeでどこまで開発できるのかも分からなかったですし。毎日2時間くらい一緒にやってましたよね。懐かしいです（笑）。
──うわあ……文字通り「本気」でやったということが伝わってきます。やらなければ分からないとはいえ、特に泉澤さんは他の業務もある中で、よくそこまで付き合ったなと驚きました。
エス・エム・エス 泉澤さん：
先ほどお話ししたように、プロジェクトの状況を考えると、これが成功したときのメリットが大きいというのもそうですし、やる気があるナスカさんがいるなら「賭けてみよう」と思っていました。やるならとことんやったほうがいいので。
Goodpatch 矢吹：
「私が良い結果を出せれば、他のデザイナーにも横展開できる」とは意識していました。エス・エム・エスのようにAIツール活用に意欲的な環境は珍しいので、とてもありがたかったです。
メインステージは「Storybook」 デザイナーが開発に参加し、チームがより多くの価値を生み出せるように
──どこまで生成AIで開発ができるのか、実験したというわけですか。フルサポートの下で開発した結果はどうでしたか？
エス・エム・エス 泉澤さん：
結論から言うと、ナスカさんにはとにかくUIを作ることに集中してもらい、バックエンドとの接続や複雑なロジックの実装は僕たちが行う、という形で担当を分けるのがよさそうだと決まりました。
ナスカさんには、さまざまなUIコンポーネントを開発してもらい、UIのカタログである「Storybook」を整備し、充実させてもらっています。実はそれまでフロントエンドエンジニアは、Figmaでデザインを確認しながらコードを実装する作業に多くの時間と手間がかかっており、確認要素が多いことで、注釈の見落としや実装漏れも少なからず発生していました。この開発体制を、ナスカさんが実装したUIに、エンジニアがロジック（プログラムの処理手順）を定義し、テストをする仕組みに変えました。
──ナスカさんは、具体的にどんなUIを作っているのですか？
Goodpatch 矢吹：
直近では、エラーアラート画面や複数ファイルアップロード画面を開発しました。
介護業界は難解な用語や表現が多く、日本語を無理やり英語に翻訳したようなコードもあるので理解しにくいのですが、今はコードを見れば、ある程度必要となるエラーコードが理解できるようになりました。変数名が日本語で書かれていると安心しますね（笑）。
Figmaを使わずClaude Codeを使ってデザインと開発を一緒に進めたファイルアップロード画面
──なるほど。要するにボタンなどの細かいUIコンポーネントを組み合わせた、より大きな単位での「パーツ」を作っているわけですね。確かに流用できるパーツが増えれば、それだけ開発のスピードも上がりますし、デザインが崩れたり、実装をミスしたりといったリスクも抑えられると。
エス・エム・エス 泉澤さん：
その通りです。さらに、変更前後の見た目を比較できるVRT（ビジュアルリグレッションテスト）も取り入れているので、実装時の差分も検知できるようになっています。実際、ナスカさんが実装するようになってからは「実装したらUIが崩れた」という声や、スプリントレビューでのデザインに関する指摘はほとんどなくなりました。
Goodpatch 矢吹：
それまでの私はデザインレビューの際に、UI崩れやデザインシステムとのズレなどを指摘する、いわば「デザインシステム警察」状態だったのですが（笑）、今は細かいバグや文言の修正程度であれば自分で対応できますし、Figmaのレビューと実装後の挙動確認をまとめて行えるようになりました。
今後は浮いた時間で、ユーザーへのヒアリングやテストに時間をかけたり、理想的な表現を考えたりといった、本質的な価値を考え、作り出す方に時間を使えるようになると感じています。
──結果として、最初に目標としていたフロントエンジニアのリソースの削減というのは達成できたのでしょうか。
エス・エム・エス 泉澤さん：
はい。もちろんナスカさんが実装できるといっても、私たちエンジニアのレビューは必要ですが、UIや簡単な実装をナスカさんに行ってもらい、エンジニアが複雑な実装を担当するように役割を分けたことで、チーム全体としてより多くの価値を生み出せるようになりました。
これまでエンジニアが行ってきた仕様確認、他ポジションとの打ち合わせ、微修正に充てる時間など、メインの開発以外の仕事をナスカさんに任せられるようになったのは大きいです。
新規画面は「Figma」で、既存UIをベースにした開発は「Storybook＋Claude Code」と使い分ける
──簡単な実装ができるようになったことで、デザイナーの担当領域が、デザインから開発の支援まで拡大したんですね。メインで使うツールもFigmaから、StorybookやClaude Codeに変わった感じですか？
Goodpatch 矢吹：
Figmaを使わなくなったのではなく、使うシーンが変わった、と言う方が正しいですね。複雑な新しい画面を作ったり、ゼロからアイデアを生み出したりする際には、やはりFigmaを見ながら議論する方が向いています。新規でデザインしたいときはFigma、既存のUIをベースにした画面を作りたいときはStorybookとClaude Code、という形で使い分けています。
今はFigmaのスクリーンショットをClaude Codeに読み込ませると、カイポケコネクトのデザインシステムにあるコンポーネントを使ったコードを生成してくれるので、そのコードを基に修正して私がStorybookで画面のUIパーツを開発している感じです。
新規画面はイシューシート（Why、What、Howを定義したドキュメント）作成しそのシートを見ながらFigmaでデザインしていくのですが、今はClaude Codeにイシューシートを投げるとその要件に合わせてコンポーネントを組み合わせ、イメージ通りに作成してくれるようになってきました。
実装したプレビューをStorybookで確認し、デザインレビューのスキルを使って足りない状態がないかや、文言チェックを行います。自然言語で指示をしながら調整し、実装とデザインを一緒に進めていますね。
──デザイナーはFigmaで一からデザインを興すのが通例でしたが、Claude Code上にあらゆるデータを集約すると、UIコンポーネントやパーツを組み合わせるという開発スタイルも可能になるわけですね。
Goodpatch 矢吹：
もちろん、UIコンポーネントが重なってしまうケースがあるなど、Claude Codeの生成も完璧ではないので、そういったアンチパターンも整理して知見を貯めているところです。
エス・エム・エス 泉澤さん：
今は、FigmaやNotionにあるコンポーネントのガイドラインも合わせてStorybookに移行する準備をしている最中です。Storybookにこれらを反映できればClaude Codeが内容を読み取ってコードにも反映してくれるので、将来的にはさらに開発効率を上げられると考えています。
──Storybookの内容を充実させることで、開発効率が上がるというループが出来上がっているのは、本当にいい仕組みですね。
Goodpatch 矢吹：
他にも、スプリントの開発計画やタスクを見直すリファインメントでプロトタイプを確認したい時はClaudeを活用しています。Figma Makeでも同様の機能がありますが、Geminiの議事録データを基にClaudeがデザインやコードを生成してくれるので、テキストで書かれたバックログタスクではなく、その場で動くプロトタイプを見ながら開発の優先度やどんな体験を届けるかを検討できるようになりました。
デザインシステムが「デザインハーネス」のカギ 開発や事業のスピードを左右する存在に
──生成AIによってデザインのワークフローが変わるというのは、デザイナーにとってかなり大きな変化ですね。同じようにコーディングの現場にも影響がありそうですが、エンジニアの仕事の仕方も変わっているのでしょうか。
エス・エム・エス 泉澤さん：
正直、生成AIなしの開発はもう考えられません。今は開発の半分以上は生成AIにやってもらっていますね。コーディングだけではなく、要件定義に活用して抜け漏れを失くすなど、広範囲で活用しています。ただAIを使いこなすにも、前提となる知識もそうですし、レビューの体制など、しっかりとした仕組みがないとうまくいかないのかなと考えています。
Goodpatch 矢吹：
確かにそうですよね。ある程度開発の理解が進んでからは、分からないことはClaude Codeに聞いていますが、実装に関してのレビューもGitHubのCopilotに行ってもらっています。
──そうなんですね。コードのレビューも生成AIに助けてもらっていると。
エス・エム・エス 泉澤さん：
フロントエンドのコーディングガイドラインは、フロントエンドエンジニア自身が「このときはこうする」「これはしない」という形で整備・更新しており、それをCopilotのレビュー設定にも反映することで、レビューの精度を一定担保できているんです。
Goodpatch 矢吹：
ガイドラインという観点では、UIの生成に関しても「デザインシステム」というしっかりと土台があるからこそ機能しています。デザインシステムがないと、生成AIはそれらしいコードやデザインは出してきますが、事業ならではの都合やプロダクトの思想などが反映されるわけではないので、「なんか違うんだよね」というアウトプットになってしまいます。
ガイドラインのサンプル
──デザインシステムがいわゆる「デザインハーネス」の役割を果たしてくれるわけですね。デザインシステムやそれを生かせる生成AIの土台があるならば、例えば、別の機能やプロダクトを作るといったときでも、プロトタイプの検証などを含め、事業の立ち上がりそのものまで段違いに早くなるかもしれませんね。
Goodpatch 矢吹：
確かにコンポーネントを組み合わせたプロトタイプからデザイン修正に入れるので、スピードは格段に速くなる可能性はありますね。また、リリース後の機能改修など、エンハンスのスピードも上がります。
例えば、プロダクトバックログにはカスタマーサクセスチームからの改善や改修要望タスクが貯まりますが、エンジニアからすると、リリースに向けたロードマップを優先する都合で開発優先度が低いものになりやすいです。でもデザイナーなど別の職種の人間が開発まで手を回せると、「重要かつ、すぐに開発できそうなもの」を選んでリファインメント時にプランニングに上げて、次のスプリントで対応できるようになるわけです。
エス・エム・エス 泉澤さん：
プロダクト開発において、ナスカさんが実装できるようになったメリットはもちろん大きいのですが、UIの知見があるからこそ、ユーザー視点での改修の優先度が分かる。開発以外の部分でも良い影響が出始めています。
もはや「越境」が前提に？ 生成AI時代は、専門職に求められる役割が変わっていく
──実装まで対応できるデザイナーというのは、キャリアの1つの選択肢になりそうですね。土台作りというのは時間もコストもかかる取り組みだと思いますが、エス・エム・エスでは、なぜここまでできているのでしょうか？
エス・エム・エス 泉澤さん：
AI向けに新しく土台を作ったというより、元からあった文化が転用できた感覚ですね。普段から、仕様の整理や設計判断の背景をドキュメントに残す文化があって、それがそのまま生成AIに読ませる土台になっていました。専門が違う人でも、AIの力を借りて踏み出しやすいのは、その延長だと思います。
Goodpatch 矢吹：
エス・エム・エスは、全社的にAIを活用することに対して意欲的ですよね。デザイナーやQAも情報収集にAIを使用するなど、AI活用が盛んだと思います。
──ありがとうございました。最後に、今回のようにデザイナーがエンジニア業務も兼務するようになる中で、個人が業務範囲を拡大していくことについて、お二人はどう考えていますか？
エス・エム・エス 泉澤さん：
実際、デザイナーの知見を持って開発できるプレイヤーは、これからの時代はとても重宝されると思います。
今までは2つの分野を極めるのに時間がかかるので現実的に難しかったですが、Claude Codeによって門戸が広がりました。逆にエンジニアは開発視点を持ったPO（プロダクトオーナー）も目指せるし、フロントエンドからバックエンドまで、開発領域を広げていくこともできる。生成AI時代は、元々本人が保持していたスキルを掛け合わせて価値を作っていくようになると思います。
Goodpatch 矢吹：
今後デザイナーは、プロジェクトやプロダクトを牽引していくPdMやPOのような存在になると思います。私自身できることが増えて、今までなら時間的な制約で諦めていたこだわりや、エンジニアに遠慮してできなかったUIの細部までこだわれるようになりました。
ツールは日進月歩で進化していくのでキャッチアップは大変ですが、全く経験のない私でもできたので、将来が不安なデザイナーはぜひ越境にチャレンジしてほしいです。
この事例に関するお問い合わせ
本事例に関するご質問やご相談は以下のフォームよりお気軽にお問い合わせください。
開発効率を変革する、デザインシステム構築サポート このような方におすすめです