グッドビーのフロントエンドクリエイション部が、社内のフロントエンドに対する取り組みをシリーズでお届けしています。第6弾となる今回のテーマは、「デザインシステム」と「コンポーネント指向開発」です。
前回までで、技術選定や開発環境、チームカルチャーについてお伝えしてきました。とはいえ、業務システムの価値は、コードの正しさだけではユーザーに届きません。画面の見た目、操作のしやすさ、情報の見せ方が、そのまま使いやすさになります。
グッドビーは業務システムの開発を専門としながら、デザインにこだわってプロダクトをつくっています。本記事では、デザイナーの意思を実装に反映させながら、開発効率と品質を両立させる取り組みをご紹介します。

デザインにこだわる、業務システム開発会社として

業務システムと聞くと、「機能が動けば十分」「見た目は二の次」というイメージを持たれることがあります。しかしグッドビーが考える使いやすさの最終目標は、「操作マニュアルのいらないシステムデザイン」です。

【業務系システムだからこそストレスフリーなUI・UXを考え抜く】でもお伝えしたとおり、どれほど高性能なシステムでも、使いたい機能の場所が分からなければ、ユーザーはマニュアルを読み込まなければなりません。逆に、見た目が地味でも、業務フローに沿って使い方が想像しやすい画面であれば、スムーズに操作できます。

「使い方のイメージのしやすさ＝使いやすさ」
この考え方は、デザインを仕上げの装飾ではなく、プロダクトの中核として位置づける理由になっています。頻繁に使う機能は目立たせ、滅多に触らない機能は意図的に控えめにする。操作端末に応じてレイアウトを変え、業務フローのヒアリングからデザインを始める。こうしたユーザー目線の設計が、システム会社としてのグッドビーの強みです。
また、業務システムは「完成」がゴールではありません。機能追加や仕様変更が起きても使いやすさを保てるよう、汎用的にデザインする必要があります。画面ごとに一からデザインするのではなく、デザインシステムとコンポーネントという共通の言語でつくっていくアプローチが有効なのです。

デザイナーの意思を、実装に届ける

フロントエンド開発において、デザインと実装のズレは品質問題に直結します。色味が少し違う、余白が統一されていない、ホバー時の挙動がデザインカンプと異なる。こうした差分が積み重なると、デザイナーが意図した体験はユーザーに届きません。
グッドビーでは、デザイン部とフロントエンドチームが密に連携し、デザイナーの意思を実装の段階で失わないことを重視しています。

• デザイン段階から、コンポーネント単位で画面を組み立てる
• 実装前に、Storybook上でデザイン部によるレビューを受ける
• デザインシステムに沿った部品だけを使い、画面を構成する

デザインカンプを見ながら手作業で再現するだけでは、担当者や案件によってブレが生じやすくなります。デザイナーが定義したルールと部品を、コード側でも同じ粒度で持つことで、デザインの意図がチーム全体に継承される状態をつくっています。

デザイン部もデザインシステムでつくる

グッドビーのデザイン部も、案件ごとにバラバラな見た目をつくるのではなく、デザインシステムを前提にデザインしています。
ボタン、入力フィールド、テーブル、モーダル、ナビゲーションなど、画面を構成する要素をあらかじめ部品として定義し、色・タイポグラフィ・余白・状態（通常・ホバー・無効など）のルールを揃えます。新しい画面をつくるときにゼロからレイアウトを考え直す必要が減り、お客様ごとにブランドカラーや要件は変えつつ、操作感の一貫性を保てます。機能追加時にも、既存の部品を組み合わせて素早くデザインできるのも大きなメリットです。

Figma MCPでデザインからコードへの橋を効率化する

デザインシステムを持っていても、デザインツールと実装の間に翻訳コストが残れば、開発スピードは上がりません。グッドビーではFigma MCPを活用し、Figma上のデザイン情報を効率的にコードへ落とし込む取り組みを進めています。
Figma MCPを用いることで、デザインファイルの構造やコンポーネント情報を開発環境に取り込みやすくなります。写経の手間を減らし、コンポーネント名やバリアントの対応関係をデザインとコードで揃えやすくなり、デザイン変更時の差分反映もスムーズになります。
AIに任せきりにするのではなく、デザイナーが定義したルールと構造を、実装の出発点として正確に引き継ぐための補助線として位置づけています。人の判断を置き換えるのではなく、デザインと実装の間にある反復作業を減らすことに価値があると考えています。

Storybookでデザイン部のレビューを開発フローに組み込む

コンポーネント指向開発では、画面全体の完成を待たずに、部品単位で品質を確認できることが大きな利点です。グッドビーではStorybookを導入し、デザイン部によるレビューを開発フローの中に組み込んでいます。
Storybookは、UIコンポーネントをアプリケーション本体から切り離して一覧・操作・検証できるツールです。ボタンの各状態、フォームのバリデーション表示、テーブルの空状態など、実際の画面に組み込む前に、部品ごとの見た目と挙動を確認できます。
デザイン部のレビューをStorybook上で行うことで、「この画面のこの部分」ではなく「このコンポーネントは仕様どおりか」を議論できます。実装の早期段階でデザインのズレを発見し、手戻りを小さくできます。レビュー済みの部品は、複数画面で安心して再利用できます。

コンポーネントを細かくつくる

コンポーネント指向開発の核心は、画面を大きな塊ではなく、意味のある小さな単位に分解することです。
たとえば商品一覧画面をひとつのコンポーネントとして実装するのではなく、ページヘッダー、検索フォーム、データテーブル、ページネーション、確認モーダルのように分解します。分解の粒度はデザインシステムの部品定義と揃えることで、デザインと実装の対応関係も明確になります。
細かくつくることで、変更の影響範囲が限定的になり、部品単位のテストや並行開発がしやすくなり、再利用性も高まります。細かくしすぎると管理コストが上がるため、デザインシステムの粒度と実装のコンポーネント構造を定期的にすり合わせながら、再利用される部品と画面固有の組み合わせのバランスを取っています。

おわりに

「スピードを優先すれば品質が落ちる」「品質にこだわれば開発が遅くなる」という二者択一は、デザインシステムとコンポーネント指向の実践によって、かなりの程度緩和できます。
一度つくった部品とルールは、次の画面・次の機能・次の案件に活きます。デザイン部のレビューをStorybookで早期に回し、Figma MCPでデザイン情報の引き継ぎをスムーズにすることで、実装者は写経ではなく組み立てと調整に集中できます。
デザインと実装が同じ部品・同じルール・同じ言葉でつながっているとき、開発の効率と品質は両立しやすくなります。グッドビーは、デザイナーの意思を尊重しながら、コンポーネントとデザインシステムの土台の上で、お客様の事業成長に寄り添うプロダクトづくりを続けていきます。