エンジニアからプロダクトデザイナーへ、同じプロダクトで。

実顧客を抱えたプロダクトが、初期UIの限界に近づいていた。

株式会社リセは、日本の法務チーム向けにAI契約書レビューを提供するリーガルテックスタートアップ。参画時点でプロダクトには実顧客と相応の複雑性があり、UIは機能追加の中で有機的に成長していた一方で、Vueのコードベースは「足す」より「進化させる」方が難しい状態だった。

FEエンジニアとして実装に従事しながら、より大きなレバレッジはチームがUIや意思決定をどう形作るかという上流にあると見えてきた。この気付きが、ロールをプロダクトデザインとPdMへ移していった。

画面単位の改善だけでは、チームの速度は戻らない。

表面的にはプロダクトは動いていたが、内部では4つの要因がチームを継続的に遅らせていた。

• 共有コンポーネント層が存在しない。各機能が「同じ」ボタンやモーダルの独自バリエーションを抱えていた。
• デザインとコードの乖離。Figmaは数か月前の状態を反映し、エンジニアとは「プライマリボタン」の定義にズレがあった。
• トークンシステムの不在。色・スペーシングがハードコードされ、テーマ変更が数十ファイルに波及していた。
• AI機能の拡張。新規AI機能ごとにUIパターンが必要だが、「サジェスト」「レビュー状態」「確信度」の共通語彙がなかった。

プロダクトを止めずに、共通語彙とUIスタックを作り直す。

「全部書き直すために手を止める」選択肢はなかった。各ステップが、前よりリリース可能なプロダクトを残すことを条件にした。

共通言語としてAtomic Designを導入

コードに手を入れる前に、チームにはUIを語る共通言語が必要だった。Atomic Designを思想ではなく語彙として導入。Atom・Molecule・Organismが揃うと、デザイナーとエンジニアが同じ名詞でUIを語れるようになり、既存UIは再利用可能なパーツへ整理されていった。

Raw → Semantic の二層トークンを設計

Rawトークンはブランドのプリミティブ（hex / pxの値）を、Semanticトークンは意図（この色は何を意味するか）を表現。コンポーネントはSemanticトークンのみを参照するため、ダーク/ライトモードやブランド調整、アクセシビリティ対応は1レイヤーで完結する。

Vue → Next.js移行の軸をデザインシステムに置く

移行は常にリリース可能なフェーズに分割。新規機能はNext.jsで、レガシーVueはフィーチャーフラグの裏で画面単位に移行。共通UIプリミティブは社内パッケージとして切り出し、両スタックが同じコンポーネントを共有できるようにした。フレームワークではなくデザインシステムを移行の軸に置いたのが意思決定の核だった。

機能コードではなく、プロダクトデザインをリードする

基盤が安定するに従い、ボトルネックは「どう作るか」から「何を、なぜ作るか」に移った。新規プロダクト面ではプロダクトデザイナー + PdMとして、要件定義・Figmaデザイン・デザインシステム運用、実装フェーズでの伴走までを担当。直接機能コードを書く機会は減ったが、エンジニアリングのバックグラウンドはコンポーネント・状態・トークンの粒度設計、そして「Figmaが他者の手でそのまま実装可能なコードに落ちる」設計に効き続けている。

基盤づくりは、プロダクトデザインの仕事へつながった。

• デザイナーとエンジニアが共通言語を持つように。UIに関する会話が「なんか違う」から、特定のAtomとトークンの議論に変わった。
• テーマ・ブランド変更が1レイヤーの編集で済む。ダークモード、アクセント調整、アクセシビリティ対応が全コンポーネントに波及しない。
• プロダクト面は拡大し続けている──新しいAIワークフローを含めて──保守負荷を比例的に増やすことなく。

Figmaが、そのまま実装の会話に入れる状態を作る。

このプロジェクト以降、デザインの完成度は画面の見た目だけでは判断しない。コンポーネントの粒度、状態の持ち方、トークンの命名、実装時に迷う余白がどれだけ減っているかまで含めて設計と捉えている。エンジニアとしての経験は、デザインをコードへ翻訳するためではなく、最初からコードに落ちる構造で考えるために使っている。