はじめに
Day 6 でダッシュボードの実装を行いました。今回は 6 日間の振り返りをしていきます。
前回はこちら。
| 日程 | テーマ | 内容 |
|---|---|---|
| Day 1 | 環境構築 | Next.js + TypeScript セットアップ |
| Day 2 | Cursor × Figma MCP 連携設定 | Cursor で Figma デザインを読み込めるようにする |
| Day 3 | デザイン分析・精査 | AI がトークン/コンポーネント提案 → 人間が精査 |
| Day 4 | Tokens Studio登録 | AI の提案をトークンとして登録 |
| Day 5 | シンプルなコンポーネント実装 | Button, Input, Card など基本部品を実装 |
| Day 6 | ダッシュボード完成 | 全コンポーネント統合・完成 |
| ☆ Day 7 | 完結・まとめ | 6日間の体験総括 |
6 日間の学びと気づき
言語化の必要性
AI は人間のように「背景から意図を察する」ことができません。これはこのコースを通じて何度も感じました。
特に実装フェーズでは、Figma のデザインを見ながら 〇〇のコンポーネントを作ってください とだけ伝えるのと、色は primary（#6366f1）で、padding は md、ホバー時は opacity を 0.8 に下げてください と詳細に伝えるのでは、出力が全く違いました。
また、最初のうちは、AI が過去のコンテキストから背景情報を読み取ってくれるだろうと思っていましたが、何度もデザインの修正などをしたり自分の考え方も変わったりしていったので、AI には都度新しい情報を伝えなければ自分が意図していたものとは乖離して、結果やりとりが増えるなと思いました。
実務でも言語化するというのを怠らずにやっていきたいと改めて感じました。
実装を想定した構造的デザイン作成
デザインが作れていれば、実装はすぐに進むだろうと思っていましたが、Figma MCP で AI にデザインを読ませた時に、どういうものかを理解することはまだできても、そこから実装にすぐに至ることはできませんでした。図形を重ねただけのデザインから構造を読み取りにくいことに気づきました。
意図を言語化することは AI を使う上で大切だとは思いますが、デザインにおいても何を実装すべきかが明確になるような構造的デザインを作ることが大切だと気づきました。
デザインシステムは必要なのか？
今回はなんちゃってデザインシステムのような形式でやってみました。正直個人でやる分にはかなり冗長なやり方だったとは思います。ただ、せっかくなら実務に活かせないかと思い、学習目的でやってみました。
やってみて感じたこととしては、例えば画像から再現する程度であれば Figma を介さずとも AI から読み取らせてやるのはありかと思いました。
ただ、継続的に開発していったり、統一性が必要になるという場面では、デザインシステムというルールを作っておけば、人間にも AI にも基準となるので、実装時の揺らぎが少なくなったり、レビュー時のガードレールにもなりうると感じました。
最後に
昨今 AI が当たり前のように使われるようになっています。今回やったやり方以外にも開発のやり方はたくさんあると思うので、取り残されないように模索していきたいと思います。