自社開発プロダクト【Voiceek】開発で見えたデザイナーとのうまい連携のしかた

この記事は、Insight Edge Advent Calendar 2025の12日目の記事です！

はじめに

こんにちは、Insight Edgeでエンジニアをしている東です。

この記事では、自社プロダクト Voiceek の開発を題材に、「エンジニアとデザイナーがどうやってうまく協力しているか」を紹介します。

Voiceek（ボイシーク）とは、顧客の声・従業員の声の分析を効率化・高度化できるテキスト分析ツールです。

以前には、UI/UXデザイナー視点の記事もあるので、そちらもぜひご覧ください。

普段からフロントエンドやプロダクト開発をしていると、

デザインの意図が読み切れない
動きや細かい挙動のすり合わせに時間がかかる

といった経験をしたことがある方も多いのではないでしょうか。

Voiceekの開発でも、同じような課題にぶつかりました。また、今回はデザイナーが専任ではなく複数プロジェクトを兼務していたため、プロダクトに対する共通認識が取りづらいという課題もありました。

そこで今回は、

少人数かつ兼務前提のスクラムチームで、どうやってデザイナーと連携しているか
どんなルール設計にしたらスピードと品質を両立できたか
デザイン実装を支えるAIツールの活用法

について書いていきます。

Voiceek開発のチーム体制

エンジニア：3名（私を含む）
デザイナー：2名
プロダクトオーナー（PO）：1名

といった構成で、全員が他プロジェクトと兼務しながらスクラムを回しています。

Voiceek全体としては、基盤開発に加えて顧客ごとのカスタマイズ開発も行っており、時期やフェーズによってチーム構成は変化しながら、プロダクトを成長させています。

関連記事: 少数精鋭チームのプロダクト開発で大事なことを考えてみた

デザイナー連携でぶつかったリアルな課題

今回の開発では、Voiceekの分析結果を「見るだけ」で終わらせず、そこからさらに深掘れるように、対話形式のチャット機能を実装しました。

このチャット機能をデザイナーと連携しながら開発を進める中で、特に次の3つのポイントで課題が見えてきました。

1. 機能の認識合わせの難しさ

チャットボット機能では、

ユーザーにどんな体験を提供したいか
それをどんな技術で実現するか

をそろえておく必要がありました。

そのようなイメージを、デザイナーに短い時間で伝えるのが難しく、「この機能で何を達成したいのか」をそろえるまでに意外と時間がかかりました。

2. 「動き」「ユーザー操作」など見落としがちな仕様のズレ

もう1つ大きかったのが、「動き」に関する解釈のズレです。

Figmaは静的なので、アニメーションやトランジションのニュアンスが定義されない
デザイン時には想定外のユーザー挙動の仕様が決まっていない

チャット画面のようなインタラクティブなUIでは、

ローディングの出し方
メッセージの追加・スクロールの動き

など、細かい部分でユーザー体験がかなり変わります。
ここをすべて事前にFigma上で決め切るのは現実的ではなく、一方で何も決めないと後から大きな手戻りになりがちです。

3. デザインレビュー待ちによる開発フローの停滞

もう1つは、デザインレビューが開発フローのボトルネックになる懸念です。

デザイナーがスポット参加で、レビューにすぐ入れないことがある
レビュー待ちのままタスクがクローズできず、スプリントの終わりが見えづらくなる

といった状況が懸念され、「どこまでを1つのタスクの完了とみなすか」の線引きに苦労しました。

課題解決のための3つのアプローチ

上記のような課題に対して、Voiceekの開発では次の3つのアプローチを組み合わせて対応しました。

1. デザイナーをデイリースクラムに招待して認識ズレを減らす

まず取り組んだのが、デザイナーにもできるだけデイリースクラムに参加してもらうことです。

特に効いていると感じるのは、「デイリーでの短い対話」です。
毎日10〜15分の中で「今ここまでできている」「ここがまだふわっとしている」という認識を合わせることで、結果的に手戻りが減りました。

さらに、「動き」の課題に対しては、デイリースクラムの中で仮実装を見せながら決めていくようにしました。

具体的にいうと、

デザイナーに大まかなイメージをFigmaで作ってもらう
エンジニア側でイメージに沿って仮実装する
デイリースクラムで動いている画面を見てもらい、問題ない点と調整したい部分を一緒に確認する
問題がなければそのまま仕様として確定し、気になるところが出てきた場合はデザイナー側で再検討してもらう

この方法だと、

完璧な仕様が出るまで待たずに、とりあえず前に進める
実際の動きを見ながら議論できるので、認識のズレが少ない
POも巻き込みやすく、意思決定が早い

というメリットがありました。

2.フローの整理でレビュー待ちを防ぐ

次に決めたのが、「デザインレビューをタスクのクローズ条件にしない」というルールです。
基本のフローはとてもシンプルです。

デザイナーがFigmaでデザインを作成
エンジニアが実装
POが確認してOKならタスクをクローズ

タスクフロー

デザインレビューのタイミングについては、エンジニアからデザイナーに対して実装完了後にレビュー依頼をする形を取っています。デザイナーはその依頼を受けて実装画面を確認し、気になる点があればフィードバックします。

ここでポイントなのが、デザイナーによるデザインレビューの扱いです。

デザインレビューは タスクのクローズ条件には含めない
レビューで修正が必要と判断されたら、新しいタスクとして起票
修正は次のスプリント以降で対応する

こうすることで、

「レビューが終わらないとスプリントが終わらない」という状況を避ける
とはいえ、デザイン観点の改善はきちんと別タスクで回し続ける

というバランスを取ることができます。

デザインレビューフロー

デザインレビューをしっかりしつつも、「止める工程」にしないというのが今回の工夫でした。

3. 生成AIツールでデザインから実装への橋渡しを効率化

AIツールの活用も、実装時に大きな助けとなりました。具体的には、Figma MCP と Claude Code を組み合わせています。

この組み合わせによって、実装スピードが大きく向上しました。

Claude CodeからFigma MCPを経由してデザインデータを取得することで、

レイアウトの骨組みとなるコードを、Figmaの構造に近い形で自動生成
余白・サイズ・配色なども、Figmaの指定にかなり近い状態で反映

もちろん細かい調整は必要ですが、「骨組みがすでにできている状態」からスタートできるため、レイアウト調整にかけていた時間を減らし、アプリケーションロジックやアニメーションなどの実装に集中しやすくなりました。

実践して分かった、デザイナー連携の3つの重要ポイント

上記のアプローチを実践する中で、デザイナーとの連携について特に重要だと感じたポイントを3つ紹介します。

1. 高頻度のコミュニケーションを優先する

デザイナーにデイリースクラムへ参加してもらい、毎日少しでも会話するようにしたことで、

イメージの共有が早くなる
仕様の解釈違いが早期に見つかる
手戻りに気付いたときの被害が小さくなる

という効果がありました。

「話す時間を減らしたほうが開発は早く進む」と思いがちですが、実感としてはむしろ逆で、
短くても高頻度で話したほうが、結果的にスピードが出る と感じています。

2. デザイナーの視点を積極的に取り入れる

エンジニアはどうしても、「実装しやすさ」や「パフォーマンス」を優先して考えがちです。一方デザイナーは、「ユーザーがどう感じるか」「この画面の体験は気持ち良いか」を軸に考えてくれます。

エンジニア視点：この実装のほうが早い・シンプル
デザイナー視点：その挙動だとユーザーが迷う・不安になる

といった場面で、デザイナーの意見が入ることで、ユーザー体験としてのバランスが取れるようになりました。

3. 責務分離しつつイメージは共有する

責務の分離自体はとても大事です。

デザインの最終判断はデザイナー
実装方針の最終判断はエンジニア

という線引きは保ちつつも、「お互いの頭の中のイメージ」はできるだけ共有するようにしました。

デザイナーからは、コンポーネントの意図や、ユーザーに持ってほしい感情を言語化してもらう
エンジニアからは、実装上の制約や、他画面との整合性を共有する

この「任せる」と「共有する」のバランスが取れてくると、チームとしてのスピードやクオリティを上げやすいと感じています。

まとめ

ここまで、Voiceekの開発で実践してきた「デザイナーとのうまい連携」を紹介してきました。

毎日5分でもデザイナーと話す時間をつくる
- デイリースクラムに参加してもらう
- 参加が難しければ、短いスタンドアップやSlackハドルなどでもOK
「デザインレビュー待ちで止めない」ルールを決める
- デザインレビューはタスク完了条件に含めず、修正は別チケットで扱う
- 「いつまでに何が決まっていれば実装を進めてよいか」をチームで言語化する
Figmaなどのデザインや実装画面を一緒に触る場をつくる
- Figmaと実装画面の両方を見せながら、「ここはどう感じるか？」「他の案はあるか？」をその場で話す