Figma のデザインデータをそのまま Devin に渡せば最速で MVP が作れる...？
生成 AI に「タスク管理アプリをつくって」などと指示すればある程度整った UI 付きでプロトタイプが完成するわけですが、デザインレスはやはり難しいと感じます。
例えば、以下の理由です。
1. 複雑な UX やアニメーションの実装
2. 一貫したUI設計
- 開発後期のデザインシステムの整理
3. コミュニケーション
- 他部署との合意形成
- 仕様の曖昧さをつぶす
ただ、デザインの役割や粒度は変えてもよいと思うので、今回は Figma のデザインテンプレートをもとに Web アプリをつくって再現性や保守性の評価をしてみました。
Figma と Devin の連携
1. Figma
Figma の設定画面からアクセストークンを取得します。
Settings→Security→Personal access tokens→Generate new tokenと進んでいけば OK です。
2. Devin
続いて、Devin で手に入れたキーを追加します。
Settings→Secrets→Add secretと進めていけば OK です。
Devinを複数人で使っている場合には注意しましょう
開発開始
こちらの健康管理アプリの Figma デザインを使いました。(@jblezi)
ファイル情報やリポジトリにアクセスしつつ、MVP をつくっていきます。
以下の環境でフロントエンドMVPを生成してください。
【Figmaファイル情報】
- File ID: sXXXXXXXXXXXXXXXXN
【GitHubリポジトリ】
- https://github.com/yutowac/health-tracking
- feature/health-tracking-ui ブランチを作成し、作業内容をPush後、PRを出してください。
【出力ルール】
- React + TypeScript + Tailwind CSS
- Zustandで状態管理
- Figmaのカード/セクション/ボタンはAtomic Designに従い、src/components配下に整理
- ダミーデータで構成、イベントは空関数
とりあえずゴリゴリつくってもらい完成を待ちます。
再現性
デザイン再現度
左がDevinのつくったアプリで、右が元のデザインデータです。
見た目の再現度はそこそこ高いですね。右上の芋虫のアイコンも頑張って再現してます。各コンポーネントがパツパツに配置されているところは気になります。
カラートークンは Figma にほぼ一致していました。
Figma のデータと数値レベルで差異が目立ったものは以下です。
- 余白が10pxくらい違っていた
- セクション間のスペーシングにバラつきがある
機能面
デザインデータでは次のように動作の様子をページにしています。
したがって、画面遷移は自動で推測してつくっています。
「検索すると登録した薬を見る」ことができたり、「追加ボタンから情報を登録」することができるといった機能となりました。
当然ですが、この辺りはデザインデータや Devin への指示の方で明確にするとよいですね。
モバイル対応
Tailwind のレスポンシブブレークポイント（sm:, md:, lg:）はほぼ未使用でした。
アクセシビリティ
alt 属性や aria-label が一部入っており、完全に無視しているわけではありませんが、インタラクティブ要素の多くにラベルがなく、スクリーンリーダー視点では十分とは言えません。
保守性
保守性の例としていろいろな観点を列挙してみました。
| 観点 | 項目 | 評価の例 |
|---|---|---|
| 実行速度 / 最適化 | 不要なリレンダや状態管理がないか | 状態がuseState 乱立になってないか |
| 状態管理の整合性 | Zustand などで状態が整理されてるか | 状態が親→子に明示的に流れているか |
| ファイル構成 | - 機能ごと / ドメインごとに整理されているか |
src/components/Button.tsx ではなく src/features/button/Button.tsx のように意図が明確か |
| 命名規則 | - ファイル名 / コンポーネント名 / クラス名が一貫性あるか |
CardItem.tsx / CardItemList.tsx などの区別が明確か |
| 分離・責務 | - UI/ロジックが分離されているか - ビジネスロジックがフックや store に移動されているか |
useEffect に直接 API を書いてしまうなど |
| 再利用性 | - 汎用化されたコンポーネント（Button, Modal など）になっているか | 同じようなボタンが複数箇所でコピペされているか |
| テストの有無 | - ユニットテストが含まれているか（重要なロジック・ユーティリティに対して） |
utils/formatDate.tsなどはテストがあるか |
実行速度 / 最適化
フロントエンドだけですが、体感的にはパフォーマンスの問題はほぼなかったです。
状態管理の整合性
ドメインデータ（ユーザー、予約、薬、症状、実績など）は基本的に Zustand に集約されており、Atomic Design のコンポーネントには props 経由でデータを渡しているため、全体的な方向性は良いです。
ファイル構成
atoms / molecules / organismsによる Atomic Design ベースの構成が明確で、MVPとしては整理されています。
命名規則
コンポーネント・ファイル・Props インターフェースの命名は一貫していて、役割も名前から推測しやすい状態です。
分離・責務
こちらは微妙です。App.tsxが「ルーティング、画面遷移履歴、画面レンダリング、イベントハンドラ」を全て抱えていました。
再利用性
ボタンやカードなどの UI パーツは Atom/Molecule として再利用可能に作られています。
テスト有無
ユニットテスト・コンポーネントテストは現時点では存在していません。これは指示分に含めないと厳しいですね。
これらの観点を Devin で指示しなおすと...
多少は良くなりましたね。
